Updating and Modifying Existing Maps
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, while the auto_master map changes
little, if at all.
As mentioned in Default NIS Maps, the default location of the default NIS maps is
on the master server in /var/yp/domainname, where domainname is the name of
the NIS domain. When you need to update a map, you can use
one of two updating procedures, depending on whether or not it is a
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
How to Update Maps Supplied With the Default Set
Use the following procedure for updating maps supplied with the default set.
- Become a superuser 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
The make command then updates your map according to the changes you made
in its corresponding file. It also propagates the changes among the other servers.
Maintaining Updated Maps
The following sections describe additional procedures after you have completed updating maps that
are supplied with the default set.
Propagating an NIS Map
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.
Note - 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.
Using cron for Map Transfers
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
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.
Note - If your master server runs rpc.yppasswdd with the default -m option, then each
time someone changes their yp password, the passwd daemon runs make, which rebuilds
the passwd maps.
Using Shell Scripts With cron and ypxfr
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 6-1 shows the default ypxfr_1perday shell script.
Example 6-1 ypxfr_1perday Shell Script
# ypxfr_1perday.sh - Do daily yp map check/updates
# set -xv
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.
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 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.
Directly Invoking ypxfr
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.
Logging ypxfr Activity
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
# 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.
Modifying Default Maps
To update a nondefault map, you must do the following.
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, 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. makedbm(1M) fully describes this command.
Using makedbm to Modify a Non-Default Map
There are two different methods for using makedbm to modify maps if you do
not have an input file:
Redirect the makedbm -u output to a temporary file, modify the file, then use the modified file as input to makedbm.
Have the output of makedbm -u operated on within a pipeline that feeds into makedbm. This is appropriate if you can update the disassembled map with either awk, sed, or a cat append.
Creating New Maps from Text Files
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
The mymap map now exists on the master server in the directory homedomain. To
distribute the new map to slave servers run ypxfr.
Adding Entries to a File-Based Map
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.
Creating Maps From Standard Input
When no original text file exists, create the NIS map from the keyboard
by typing input to makedbm, as shown below (end with Control-D).
ypmaster# cd /var/yp
ypmaster# makedbm -homedomain-/mymapkey1 value1 key2 value2 key3 value3
Modifying Maps Made From Standard Input
If you later need to modify the map, you can use makedbm to disassemble
the map and create a temporary text intermediate file. To disassemble the map
and create a temporary file, type the following.
% 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 the following.
# 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.
Whether you use the Makefile in /var/yp or some other procedure the goal is
the same. Anew pair of well-formed dbm files must end up in the
maps directory on the master server.