|
|
The configuration information managed with NIS is typically stored in ASCII files when NIS is not in use. NIS master servers convert the information into NIS maps for storage and transfer by NIS programs.
Each NIS map is an ndbm database. An ndbm database consists of a pair of files that are created by calls to the ndbm(NS) library package. One file contains a directory (that is, a bitmap of indices accessed by a hash table); the other file contains data. Because of the non-ASCII file structure imposed by ndbm, you must use NIS tools (such as ypxfr and yppush) to transfer maps from one machine to another.
The use of maps to manage data permits NIS to add a timestamp and the identity of the source (that is, the name of the host serving as the master). A host uses the timestamp to determine if the contents of the map it is receiving are newer than data it already has. The identity of the master allows a nonmaster server to request an immediate update.
NIS maps are created when an NIS master server is initialized or as needed using NIS commands. When an NIS master server is being initialized, the initialization process creates the maps listed in the file /etc/yp/YP_MAP_X_LATE. These maps are propagated to nonmaster servers when these servers enter multiuser mode for the first time after being initialized as NIS servers. Additional maps can be created on the master server at any time using the procedures described in ``Creating NIS maps''.
The /etc/yp/YP_MAP_X_LATE file contains a complete listing of active NIS maps. The most common entries are hosts, group, passwd, and ypservers, although all standard and nonstandard maps (that is, created by you) must be listed here if you wish NIS to serve them. The format of this file is described on the ypmapxlate(NF) manual page.
The maps listed in YP_MAP_X_LATE get created when NIS is initialized by executing ypinit(NADM) or mkdev nis. You must list all the maps you need in YP_MAP_X_LATE before your system is initialized. If you add new maps after initialization, they need not be listed in YP_MAP_X_LATE to be made functional; however, because NIS consults YP_MAP_X_LATE when propagating maps, new maps must be listed here for them to be propagated using yppush(NADM), ypxfr(NADM), or other NIS utilities. For this reason, we recommend that you keep YP_MAP_X_LATE up-to-date on your master server.
Although slave and copy-only servers do not propagate maps and hence do not consult YP_MAP_X_LATE, we recommend that you keep this file current on nonmaster servers to simplify NIS administration.
YP_MAP_X_LATE also contains NIS aliases for NIS maps; aliases may be used by all NIS servers. If you have a system on your network that cannot handle long map names (that is, longer than 14 characters), you can add an alias to YP_MAP_X_LATE, showing a shortened alias for the map. If you have additional aliases to include in YP_MAP_X_LATE, add them before configuring NIS.
Propagating a map means moving it from place to place, generally from the NIS master server to an NIS slave or copy-only server. Initially, the map is moved at system startup. Maps are not propagated to clients because clients request map information from servers rather than storing the maps themselves.
After you initialize an NIS nonmaster server, ypxfr(NADM) transfers updated maps from the master server. The ypxfr command can be run in the following ways:
You can capture ypxfr's transfer attempts and results in the logfile /usr/adm/nislog. If this file exists, results are appended to it. You are responsible for limiting the size of this file. To turn off logging, remove or rename this file. Refer to the ypxfr(NADM) manual page for more information about the logfile.
Methods for transferring updated maps are described in the following sections.
Maps have differing rates of change; for instance, protocols.byname might not change for a long time, but passwd.byname might change several times a day in a large organization. You can set up root's crontab(C) entries to run ypxfr periodically at a rate appropriate for any map in an NIS database. The ypxfr program contacts the master server and transfers the map only if the master's copy is more recent than the local copy.
To avoid a crontab entry for each map, group several maps into a shell script that can be run from a single crontab script file. Each shell script should contain maps with approximately the same characteristics. The following suggested groupings, mnemonically named, can be found in /etc/yp: ypxfr1phr (hourly), ypxfr1pdy (once daily), and ypxfr2pdy (twice daily). If the rates of change are inappropriate for a particular environment, you can easily modify or replace these shell scripts. The following crontab entries will call the scripts:
0 * * * * /etc/yp/ypxfr1phr 0 0 * * * /etc/yp/ypxfr1pdy 0 0,12 * * * /etc/yp/ypxfr2pdy
Run the same shell scripts at each NIS slave and copy-only server in the domain; do not run them from the master server. Alter the time of execution from one server to another to prevent the checking from impeding the master server. To transfer the map from a particular server, rather than the master server, use the -h option to ypxfr from within the shell script. You can check and transfer maps having unique change characteristics by explicit invocations of ypxfr within crontab.
See also:
To use the interactive approach, run ypxfr as a command. Typically, this is done only in exceptional situations: for example, when setting up a temporary NIS server to create a test environment, when transferring a new NIS map, or when quickly updating an NIS server that was out of service.
The ypxfr command is also invoked by ypserv when the yppush(NADM) command is run on the NIS master server. yppush enumerates the NIS map ypservers to generate a list of NIS servers in the domain and sends a ``Transfer Map'' request to each named NIS server. The ypserv command spawns a copy of ypxfr, invoking it with the -C flag, and passes it the information needed to identify the map and call back the initiating yppush process with a summary status.
See also: