ypfiles - Network Information Service (NIS) database and directory struc-
The NIS database lookup service uses a database of dbm/ndbm, btree, or hash
files in the /var/yp directory hierarchy. A dbm/ndbm database consists of
two files created by calls to the dbminit(3) function. 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 con-
sists of a single file created by calls to the dbopen(3) function. A btree
file has the filename extension .btree; a hash file has the extension
A dbm/ndbm 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 informa-
tion 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 mas-
ter 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 addi-
tion, 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 mas-
ter 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).