YPFILES(4)							    YPFILES(4)

NAME    [Toc]    [Back]

     ypfiles - the NIS database	and directory structure

DESCRIPTION    [Toc]    [Back]

     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



									Page 1






YPFILES(4)							    YPFILES(4)



     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    [Toc]    [Back]

     makemdbm(1M), ypinit(1M), ypmake(1M), ypxfr(1M), yppush(1M), yppoll(1M),
     nsd(1M), rpcinfo(1M), mdbm(3B), nis(7P)


									PPPPaaaaggggeeee 2222