Managing NFS and NIS, 2nd Edition - Mike Eisler [49]
Here are the steps used to change master NIS servers:
Build the new master host as a slave server, initializing its domain directory and filling it with copies of the current maps. Each map must be rebuilt on the new master, which requires the NIS Makefile and map source files from the old master. Copy the source files and the NIS Makefile to the new master, and then rebuild all of the maps — but do not attempt to push them to other slave servers:newmaster# cd /var/yp
newmaster# rm *.time
newmaster# make NOPUSH=1
Removing all of the timestamp files forces every map to be rebuilt; passing NOPUSH=1 to make prevents the maps from being pushed to other servers. At this point, you have NIS maps that contain master host records pointing to the new NIS master host.
Install copies of the new master server's maps on the old master server. Transferring the new maps to existing NIS servers is made more difficult because of the process used by yppush: when a map is pushed to a slave server via the transfer-map NIS RPC call, the slave server consults its own copy of the map to determine the master server from which it should load a new copy. This is an NIS security feature: it prevents someone from creating an NIS master server and forcing maps onto the valid slave servers using yppush. The slave servers will look to their current NIS master server for map data, rather than accepting it from the renegade NIS master server.
In the process of changing master servers, the slave servers' maps will point to the old master server. To work around yppush, first move the new maps to the old master server using ypxfr:oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster -f passwd.byuid
oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster -f passwd.byname
oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster -f hosts.byname
...include all NIS maps...
The -h newmaster option tells the old master server to grab the map from the new master server, and the -f flag forces a transfer even if the local version is not out of order with the new map. Every NIS map must be transferred to the old master server. When this step is complete, the old master server's maps all point to the new master server.
On the old master server, distribute copies of the new maps to all NIS slave servers using yppush:oldmaster# /usr/lib/netsvc/yp/yppush passwd.byuid
oldmaster# /usr/lib/netsvc/yp/yppush passwd.byname
oldmaster# /usr/lib/netsvc/yp/yppush hosts.byname
...include all NIS maps...
yppush forces the slave servers to look at their old maps, find the master server (still the old master), and copy the current map from the master server. Because the map itself contains the pointer record to the master server, transferring the entire map automatically updates the slave servers' maps to point to the new master server.
If the old master server is being removed from NIS service, rebuild the ypservers map.
Many of these steps can be automated using shell scripts or simple rule additions to the NIS Makefile, requiring less effort than it might seem. For example, you can merge steps 2 and 3 in a single shell script that transfers maps from the new master to the old master, and then pushes each map to all of the slave servers. Run this script on the old master server:
#! /bin/sh
MAPS="passwd.byuid passwd.byname hosts.byname ..."
NEWMASTER=newmaster
for map in $MAPS
do
echo moving $map
/usr/lib/netsvc/yp/ypxfr -h $NEWMASTER -f $map
/usr/lib/netsvc/yp/yppush $map
done
The alternative to this method is to rebuild the entire NIS system from scratch, starting with the master server. In the process of building the system, NIS service on the network will be interrupted as slave servers are torn down and rebuilt with new maps.
Managing multiple domains
A single NIS server may be a slave of more than one master server, if it is providing service to multiple domains. In addition, a server may be a master for one domain and a slave of another. Multimaster relationships are set up when NIS is installed on each of the master servers. In the