Managing NFS and NIS, 2nd Edition - Mike Eisler [36]
Map naming
ASCII files are converted into DBM files by selecting the key field and separating it from the value field by spaces or a tab. The makedbm utility builds the .dir and .pag files from ASCII input files. A limitation of the DBM system is that it supports only one key per value, so files that are accessed by more than one field value require an NIS map for each key field. With a flat ASCII file, you can read the records sequentially and perform comparisons on any field in the record. However, DBM files are indexed databases, so only one field — the key — is used for comparisons. If you need to search the database in two different ways, using two fields, then you must use two NIS maps or must implement one of the searches as a linear walk through all of the records in the NIS map.
The password file is a good example of an ASCII file that is searched on multiple fields. The getpwnam( ) library call opens the password file and looks for the entry for a specific username. Equal in popularity is the getpwuid( ) library routine, which searches the database looking for the given user ID value. While getpwnam( ) is used by login and chown, getpwuid( ) is used by processes that need to match numeric user ID values to names, such as ls -l. To accommodate both access methods, the standard set of NIS maps includes two maps derived from the password file: one that uses the username as a key and one that uses the user ID field as a key.
The map names used by NIS indicate the source of the data and the key field. The convention for map naming is:
filename.bykeyname
The two NIS maps generated from the password file, for example, are passwd.byname (used by getpwnam( )) and passwd.byuid (used by getpwuid( )). These two maps are stored on disk as four files:
passwd.byname.dir
passwd.byname.pag
passwd.byuid.dir
passwd.byuid.pag
The order of the records in the maps will be different because they have different key fields driving the hash algorithm, but they contain exactly the same sets of entries.
Map structure
Two extra entries are added to each NIS map by makedbm. The master server name for the map is embedded in one entry and the map's order, or modification timestamp, is put in the other. These additional entries allow the map to describe itself fully, without requiring NIS to keep map management data. Again, NIS is ignorant of the content of the maps and merely provides an access mechanism. The maps themselves must contain timestamp and ownership information to coordinate updates with the master NIS server.
Some maps are given nicknames based on the original file from which they are derived. Map nicknames exist only within the ypwhich and ypmatch utilities (see Section 13.4) that retrieve information from NIS maps. Nicknames are neither part of the NIS service nor embedded in the maps themselves. They do provide convenient shorthands for referring to popular maps such as the password or hosts files. For example, the map nickname passwd refers to the passwd.byname map, and the hosts nickname refers to the hosts.byname map. To locate the password file entry for user stern in the passwd.byname map, use ypmatch with the map nickname:
% ypmatch stern passwd
stern:passwd:1461:10:Hal Stern:/home/thud/stern:/bin/csh
In this example, ypmatch expands the nickname passwd to the map name passwd.byname, locates the key stern in that map, and prints the data value associated with the key.
The library routines that use NIS don't retain any information from the maps. Once a routine looks up a hostname, for example, it passes the data back to the caller and "forgets" about the transaction. On Solaris, if the name service cache daemon (nscd) is running, then the results of queries