YPFILES(4-SVR4) RISC/os Reference Manual YPFILES(4-SVR4)
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 con-
tained in the /var/yp directory hierarchy on each NIS
server. A dbm database consists of two files, created by
calls to the ndbm(3) library package. One has the filename
extension .pag and the other has the filename extension
.dir. For instance, the database named publickey, is imple-
mented by the pair of files publickey.pag and publickey.dir.
A dbm database served by the NIS is called a NIS map. An
NIS domain 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 superuser'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 NIS_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 NIS_MASTER_NAME, with the name of the NIS mas-
ter 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
Printed 11/19/92 Page 1
YPFILES(4-SVR4) RISC/os Reference Manual YPFILES(4-SVR4)
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
ypmake(1M). All maps supplied with this OS have entries in
/var/yp/Makefile; if an NIS map is added, edit this file to
support the new map. The makefile uses makedbm(1M) to gen-
erate 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), rpcinfo(1M), ypinit(1M), ypmake(1M),
yppoll(1M), yppush(1M), ypserv(1M), ypxfr(1M), dbm(3),
ndbm(3M), publickey(4)
Page 2 Printed 11/19/92