After you have installed NIS, you might discover that some maps require frequent updating while others never need to change. For example, the passwd.byname map can change frequently on a large company's network. On the other hand, the auto_master map changes little, if at all.
When you need to update a map, you can use one of two updating procedures, depending on whether it is a default map or not.
Maps included with an application purchased from a vendor
Maps created specifically for your site
Maps created from a nontext file
The following sections explain how to use various updating tools. In practice, you might decide to only use them if you add nondefault maps or change the set of NIS servers after the system is already up and running.
Use the following procedure for updating maps supplied with the default set.
Become root on the master server.
Always modify NIS maps only on the master server.
Edit the source file for the map you want to change, whether that file resides in /etc or in some other directory of your choice.
Type the following:
# cd /var/yp# make mapname
To update a nondefault map, you must:
Create or edit its corresponding text file.
Build (or rebuild) the new or updated map. There are two ways to build a map:
Use the Makefile. Using the Makefile is the preferred method of building a non-default map. If the map has an entry in the Makefile, simply run make name where name is the name of map you want to build. If the map does not have a Makefile entry, try to create one following the instructions in "Modifying and Using the Makefile".
Use the /usr/sbin/makedbm program. (The makedbm man page fully describes this command.)
Redirect the makedbm -u output to a temporary file, modify the file, then use the modified file as input to makedbm.
To create new maps, you can use one of two possible procedures: the first method uses an existing text file as input; the second uses standard input.
Assume that a text file /var/yp/mymap.asc was created with an editor or a shell script on the master. You want to create an NIS map from this file and locate it in the homedomain subdirectory. To do this, type the following on the master server:
# cd /var/yp # makedbm mymap.asc homedomain/mymap
Adding entries to mymap is simple. First, you must modify the text file /var/yp/mymap.asc. (If you modify the actual dbm files without modifying the corresponding text file, the modifications are lost.) Then run makedbm as shown above.
ypmaster# cd /var/yp ypmaster# makedbm - homedomain/mymapkey1 value1 key2 value2 key3 value3 ypmaster#
% cd /var/yp % makedbm -u homedomain/mymap > mymap.temp
The resulting temporary file mymap.temp has one entry per line. You can edit this file as needed, using any text editor.
To update the map, give the name of the modified temporary file to makedbm by typing the following:
% makedbm mymap.temp homedomain/mymap % rm mymap.temp
Then propagate the map to the slave servers, by becoming root and typing:
# yppush mymap
The preceding paragraphs explained how to use makedbm to create maps; however, almost everything you actually have to do can be done by ypinit and Makefile unless you add nondefault maps to the database or change the set of NIS servers after the system is already up and running.
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 above procedure will not work for newly created maps that do not yet exist on the slave servers. New maps must be sent to the slave servers by running ypxfr on the slaves.
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 instance, some might not change for months at a time, such as protocols.byname among the default maps and auto_master among the nondefault maps; but passwd.byname can change several times a day. Scheduling map transfer using the crontab command allows 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 fit your site requirements. Example 19-1 shows the default 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, but be aware of the performance degradation implied in frequently propagating the maps.
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.
/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 should be the same across domains. For example, two domains might share the same services.byname and services.byaddr maps. Alternatively, you can use rcp, or rdist for more control, to transfer files across domains.
The second method of invoking ypxfr 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:
# cd /var/yp # cp ypxfr.log ypxfr.log.old # cat /dev/null > /var/yp/ypxfr.log