ypfiles(4) ypfiles(4)NAME ypfiles - the Network Information Service (NIS) database and directory structure DESCRIPTION ypfiles, the Network Information Service (NIS, formerly called ``Yellow Pages''), is a network look-up service that uses a database of dbm files in the directory hierarchy at /etc/yp. A dbm database consists of two files, created by calls to the dbm(3X) library package. One has the filename extension .pag and the other has the filename extension .dir. For instance, the database named hst.nm is implemented by a pair of files, hst.nm.pag and hst.nm.dir. A dbm database served by NIS is called an NIS ``map.'' An NIS ``domain'' is a named set of NIS maps. Each NIS domain is implemented as a subdirectory of /etc/yp containing the map. Any number of NIS domains can exist. Each domain can contain any number of maps. No maps are required by the NIS look-up service itself, although they may be required for the normal operation of other parts of the system. There is no list of maps that NIS serves; if the map exists in a given domain and a client asks about it, 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 /usr/lib/crontab on each server. More information on this topic is in ypxfr(1M). Each NIS map should contain two distinguished key-value pairs. The first key is YP_LAST_MODIFIED, having as a value a ten-character ASCII order number. The order number should be the time in seconds at which the map was built. The second key is YP_MASTER_NAME, with the name of the NIS master server as a value. makedbm generates both key-value pairs automatically. A map that does not contain both key- value pairs can be served by 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 an NIS master server to a slave server. 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 by means of ypxfr(1M) to avoid potential byte-ordering problems among NIS servers running on computers with different architectures and to minimize the amount of disk space required for the dbm January 1992 1
ypfiles(4) ypfiles(4)files. You can initially set up the NIS database 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 executing /etc/yp/Makefile. All vendor-supplied maps have entries in /etc/yp/Makefile; if you add an 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), rpcinfo(1M) ypinit(1M), ypmake(1M), yppoll(1M), yppush(1M), ypserv(1M), ypxfr(1M) in A/UX System Administrator's Reference Chapter 4, ``Setting Up the Network Information Service,'' in A/UX Network System Administration Appendix E, ``NIS Protocol Specification'' in A/UX Network Applications Programming 2 January 1992