The following sections describe additional procedures after you have completed updating maps that are supplied with the default set.
After a map is changed, the Makefile uses yppush to propagate a new map to the slave servers (unless NOPUSH is set in the Makefile). It does this by informing the ypserv daemon and sending a map transfer request. The ypserv daemon on the slave then starts a ypxfr process, which in turn contacts the ypxfrd daemon on the master server. Some basic checks are made (for example did the map really change?) and then the map is transferred. ypxfr on the slave then sends a response to the yppush process indicating whether the transfer succeeded.
The config/local_only property of the svc:/network/rpc/bind service must be set to false. Otherwise, the NIS master cannot transfer the updated version of NIS master map to the NIS slave server by using the yppush command.
Occasionally, maps fail to propagate and you must to use ypxfr manually to send new map information. You can choose to use ypxfr in two different ways: periodically through the root crontab file, or interactively on the command line. These approaches are discussed in the following sections.
Maps have different rates of change. For example, some maps might not change for months at a time, such as protocols.byname among the default maps and auto_master among the non-default maps. However passwd.byname can change several times a day. Scheduling map transfer by using the crontab command enables you to set specific propagation times for individual maps.
To periodically run ypxfr at a rate appropriate for the map, the root crontab file on each slave server should contain the appropriate ypxfr entries. ypxfr contacts the master server and transfers the map only if the copy on the master server is more recent than the local copy.
As an alternative to creating separate crontab entries for each map, you might prefer to have the root crontab command run a shell script that periodically updates all maps. Sample map-updating shell scripts are n the /usr/lib/netsvc/yp directory. The script names are ypxfr_1perday, ypxfr_1perhour, and ypxfr_2perday. You can modify or replace these shell scripts to accommodate your site requirements. The following example shows the default ypxfr_1perday shell script.
Example 3 ypxfr_1perday Shell Script#! /bin/sh # # ypxfr_1perday.sh - Do daily yp map check/updates PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH export PATH # set -xv ypxfr group.byname ypxfr group.bygid ypxfr protocols.byname ypxfr protocols.bynumber ypxfr networks.byname ypxfr networks.byaddr ypxfr services.byname ypxfr ypservers
This shell script updates the maps once per day, if the root crontab is executed daily. You can also have scripts that update maps once a week, once a month, once every hour, and so forth. However, be aware of the performance degradation that is implied in frequently propagating the maps. For more information, see the crontab(1) man page.
Run the same shell scripts as root on each slave server configured for the NIS domain. Alter the exact time of execution from one server to another to avoid bogging down the master.
If you want to transfer the map from a particular slave server, use the –h machine option of ypxfr within the shell script. Here is the syntax of the commands you put in the script.
# /usr/lib/netsvc/yp/ypxfr –h machine [ –c ] mapname
Where machine is the name of the server with the maps you want to transfer, and mapname is the name of the requested map. If you use the –h option without specifying a machine, ypxfr tries to get the map from the master server. If ypserv is not running locally at the time ypxfr is executed, you must use the –c flag so that ypxfr does not send a clear current map request to the local ypserver.
You can use the –s domain option to transfer maps from another domain to your local domain. These maps must be the same across domains. For example, two domains might share the same services.byname and services.byaddr maps. Alternatively, for more control you can use rcp or rsync to transfer files across domains.
The second method of invoking the ypxfr command is to run it as a command. Typically, you do this only in exceptional situations – for example, when setting up a temporary NIS server to create a test environment or when trying to quickly get an NIS server that has been out of service consistent with the other servers.
The transfer attempts and results of ypxfr can be captured in a log file. If a file called /var/yp/ypxfr.log exists, results are appended to it. No attempt to limit the size of the log file is made. To prevent it from growing indefinitely, empty it from time to time by typing the following.
# cd /var/yp # cp ypxfr.log ypxfr.log.old # cat /dev/null > /var/yp/ypxfr.log
You can have crontab execute these commands once a week. To turn off logging, remove the log file.