4.3. Advanced NIS server administrationOnce 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 serverIf 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:
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.master# cd /var/yp master# ypcat -k ypservers | grep -v servername\ | makedbm - /var/yp/`domainname`/ypservers
4.3.2. Changing NIS master serversThe 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:
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.#! /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
Copyright © 2002 O'Reilly & Associates. All rights reserved.