Advanced NIS server administration (Managing NFS and NIS, 2nd Edition)

4.3. Advanced NIS server administration

Once NIS is installed and running, you may find that you need to remove or re arrange your NIS servers to accommodate an increased load on one server. For example, if you attach several printers to an NIS server and use it as a print server, it may no longer make a good NIS server if most of its bandwidth is used for driving the printers. If this server is your master NIS server, you may want to assign NIS master duties to another host. We'll look at these advanced administration problems in this section.

4.3.1. Removing an NIS slave server

If you decommission an NIS slave server, or decide to stop running NIS on it because the machine is loaded by other functions, you need to remove it from the ypserver map and turn off NIS. If a host is listed in the ypservers map but is not running ypserv, then attempts to push maps to this host will fail. This will not cause any data corruption or NIS service failures. It will, however, significantly increase the time required to push the NIS maps because yppush times out waiting for the former server to respond before trying the next server.

There is no explicit "remove" procedure in the NIS maintenance tools, so you have to do this manually. Start by rebuilding the ypservers map on the NIS master server:

master# cd /var/yp 
master# ypcat -k ypservers | grep -v servername\ 
      | makedbm - /var/yp/`domainname`/ypservers

The ypcat command line prints the entries in the current ypservers map, then removes the entry for the desired server using grep -v. This shortened list of servers is given to makedbm, which rebuilds the ypservers map. If the decommissioned server is not being shut down permanently, make sure you remove the NIS maps in /var/yp on the former server so that the machine doesn't start ypserv on its next boot and provide out-of-date map information to the network. Many strange problems result if an NIS server is left running with old maps: the server will respond to requests, but may provide incorrect information to the client. After removing the maps and rebuilding ypservers, reboot the former NIS server and check to make sure that ypserv is not running. You may also want to force a map distribution at this point to test the new ypservers map. The yppush commands used in the map distribution should not include the former NIS server.

4.3.2. Changing NIS master servers

The procedure described in the previous section works only for slave servers. There are some additional dependencies on the master server that must be removed before an NIS master can be removed. To switch NIS master service to another host, you must rebuild all NIS maps to reflect the name of the new master host, update the ypservers map if the old master is being taken out of service, and distribute the new maps (with the new master server record) to all slave servers.

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.


4.2. Managing map files		4.4. Managing multiple domains