ypfiles(4)                        NFS R4.11                       ypfiles(4)


NAME
       ypfiles - the Network Information Service database and directory
       structure

DESCRIPTION
       The Network Information Service (NIS) network lookup service uses a
       distributed, replicated database of dbm files contained in the
       /etc/yp directory hierarchy on each NIS server.  A dbm database
       consists of two files, created by calls to the ndbm(3C) 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 an NIS map.  An NIS domain
       is a subdirectory of /etc/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 system administrator's (i.e., user with
       appropriate privilege; see NOTES, below) 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 YPLASTMODIFIED, 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 YPMASTERNAME, 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 YP, 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, 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
       /etc/yp/Makefile.  All maps supplied with this OS have entries in
       /etc/yp/Makefile; if you add an NIS map, 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
       /etc/yp
       /etc/yp/Makefile

SEE ALSO
       makedbm(1M), rpcinfo(1M), ypinit(1M), ypmake(1M), yppoll(1M),
       yppush(1M), ypserv(1M), ypxfr(1M), dbm(3X), appropriateprivilege(5).

NOTES
       On a generic DG/UX system, appropriate privilege is granted by having
       an effective UID of 0 (root).  See the appropriateprivilege(5) man
       page for more information.

       On a system with DG/UX information security, appropriate privilege is
       granted by having one or more specific capabilities enabled in the
       effective capability set of the user. See the capdefaults(5) man
       page for the default capabilities for this command.


Licensed material--property of copyright holder(s)