YPFILES(4)                                                          YPFILES(4)


NAME
     ypfiles - the NIS database and directory structure

DESCRIPTION
     The network information service (NIS) uses a database of mdbm(3B) files
     in the directory hierarchy at /var/ns/domains.  A mdbm database consists
     of a files created by calls to the mdbm library package.  Typically these
     have a name ending in .m For instance, the database named hosts.byname,
     is implemented by the file hosts.byname.m . A mdbm 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/ns/domains 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. makemdbm(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 nsd 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
     mdbm 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/mdbm_parse and logs its activity in /var/yp/ypmake.log.
     /var/yp/mdbm_parse contains functions for all supplied maps; if you add a


     NIS map, edit this file to support the new map.  The script uses 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
     makemdbm(1M), ypinit(1M), ypmake(1M), ypxfr(1M), yppush(1M), yppoll(1M),
     nsd(1M), rpcinfo(1M), mdbm(3B), nis(7P)


                                                                        Page 2