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.
