ypfiles(4) UNIX System V ypfiles(4)
NAME
ypfiles - the Network Information Service (NIS) database and directory
structure
DESCRIPTION
The NIS network lookup service uses a distributed, replicated database of
dbm files contained in the /var/yp directory hierarchy on each NIS
server. A dbm database consists of two files, one has the filename
extension .pag and the other has the filename extension .dir. For
instance, the database named publickey, is implemented by the pair of
files publickey.pag and publickey.dir.
A dbm database served by the NIS is called a NIS map. A NIS ypdomain is
a subdirectory of /var/yp containing a set of NIS maps. Any number of NIS
domains can exist. Each may contain any number of maps.
No maps are required by the NIS lookup service itself, although they may
be required for the normal operation of other parts of the system. There
is no list of maps which NIS serves - if the map exists in a given
domain, and a client asks about it, the NIS will serve it. 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 run ypxfr periodically should be made in the privileged user's
crontab file on each server. More information on this topic is in
ypxfr(1M).
NIS maps should contain two distinguished key-value pairs. The first is
the key YP_LAST_MODIFIED, having as a value a ten-character ASCII order
number. The order number should be the system 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. makedbm(1M) 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. See
ypserv(1M). In addition, values of these two keys are used by ypxfr when
it transfers a map from a master NIS server to a slave. If ypxfr cannot
figure out where to get the map, or if it is unable to determine whether
the local copy is more recent than the copy at the master, extra command
line switches must be set when it is run.
NIS maps must be generated and modified only at the master server. They
are copied to the slaves using ypxfr(1M) to avoid potential byte-ordering
problems among NIS servers running on machines with different
architectures, and to minimize the amount of disk space required for the
dbm files. The NIS database can be initially set up for both masters and
slaves by using ypinit(1M).
After the server databases are set up, it is probable that the contents
of some maps will change. In general, some ASCII source version of the
database exists on the master, and it is 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, see
10/89 Page 1
ypfiles(4) UNIX System V ypfiles(4)
ypmake(1M). All Sun-supplied maps have entries in /var/yp/Makefile; if a
NIS map is added, edit this file to support the new map. The makefile
uses makedbm(1M) to generate the NIS map on the master, and yppush(1M) to
propagate the changed map to the slaves. yppush is a client of the map
ypservers, which lists all the NIS servers. For more information on this
topic, see yppush(1M).
FILES
/var/yp
/var/yp/aliases
/var/yp/Makefile
SEE ALSO
makedbm(1M), ypinit(1M), ypmake(1M), yppoll(1M), yppush(1M), ypserv(1M),
ypxfr(1M), dbm(3), publickey(4)
Page 2 10/89