ypfiles(4)

NAME
     ypfiles - the NIS database and directory structure

DESCRIPTION
     The network information service (NIS) uses a database of dbm(3B) files in
     the directory hierarchy at /var/yp.  A dbm database consists of two
     files, created by calls to the dbm 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 dbm database served by
     the NIS is called a 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 map.  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,
     entries to run ypxfr periodically exist in /usr/spool/cron/crontabs/root
     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 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. 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. 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, you must set extra command line
     switches when you run it.

     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/ypmake.  ypmake executes
     the file /var/yp/Makefile and logs its activity in /var/yp/ypmake.log.
     /var/yp/Makefile contains entries for all supplied maps; if you add a NIS
     map, edit this file to support the new map.  The makefile uses makedbm to
     generate the NIS map on the master, and yppush 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).

SEE ALSO
     makedbm(1M), ypinit(1M), ypmake(1M), ypxfr(1M), yppush(1M), yppoll(1M),
     ypserv(1M), rpcinfo(1M), dbm(3B)