The NIS database lookup service uses a database of dbm, btree, or hash files in the /var/yp directory hierarchy. A dbm database consists of two files created by calls to the dbm(3) library package. One has the filename extension .pag and the other has the filename extension .dir. For instance, the database named hosts.byname, is implemented by the pair of files hosts.byname.pag and hosts.byname.dir. A btree or hash database consists of a single file created by calls to the dbminit(3) function. A btree file has the filename extension .btree. A hash file has the extension .hash.
A dbm database served by NIS is called an NIS map. A NIS domain is a named set of NIS maps. Each NIS domain is implemented as a subdirectory of /var/yp containing the maps. The number of NIS domains that can exist is unlimited. Each domain can contain any number of maps.
The NIS maps are not required by the NIS lookup service, although they may be required for the normal operation of other parts of the system. The NIS lookup service serves all maps. If the map exists in a given domain and a client asks about it, NIS will serve it. There is, however, a set of default maps that the NIS service serves. The files representing these maps are listed in this description under Files.
For a map to be accessible consistently, it must exist on all NIS servers that serve the domain. To provide data consistency between the replicated maps, an entry to execute the ypxfr command periodically should be made in the /var/spool/cron/crontab/root file on each slave server. More information on this topic is in ypxfr(8). An entry in the /var/spool/cron/crontab/root file must not exist, either on a NIS master server or on a pure NIS client machine.
The NIS maps should contain two distinguished key-value pairs. The first is the key YP_LAST_MODIFIED, whose value is a 10-character ASCII order number. The order number should be the UNIX time in seconds when the map was built. The second key is YP_MASTER_NAME, with the name of the NIS master server as a value. The makedbm(8) command generates both key-value pairs automatically. A map that does not contain both key-value pairs can be served by the NIS, but the ypserv process will not be able to return values for ``Get order number'' or ``Get master name'' requests. In addition, the values of these two keys are used by ypxfr(8) when it transfers a map from a master NIS server to a slave.
Before they can be properly accessed, the NIS maps must be initially set up for both masters and slaves by using the ypsetup(8) function. Further, NIS maps must be generated and modified only at the master server location. Copies of the master server NIS maps can then be transferred to the slave servers using the ypxfr(8) function. If ypxfr is unable to determine a map's location, or if it is unable to determine whether the local copy is more recent than the master copy, extra command line switches must be set when it is executed.
After the server databases are set up, the contents of some maps may change. In general, some ASCII source version of the database exists on the master. This version should be changed with a standard text editor. The update is incorporated into the NIS map and is propagated from the master to the slaves by running /var/yp/Makefile. All maps must have entries in /var/yp/Makefile. If an NIS map is added, the /var/yp/Makefile must be edited to support the new map. The makefile uses makedbm(8) to generate the NIS map on the master, and yppush(8) to propagate the changed map to the slaves. The yppush(8) command is a client of the map ypservers, which lists all of the NIS servers.
Commands: makedbm(8), rpcinfo(8), ypmake(8), yppoll(8), yppush(8), ypserv(8), ypsetup(8), ypxfr(8).
Functions: btree(3), dbm(3), hash(3), ndbm(3). delim off