Changing a Map's Master Server

To change the master server for a selected map, you first have to build the map on the new NIS master. Since the old master server name occurs as a key-value pair in the existing map (this pair is inserted automatically by makedbm), copying the map to the new master or transferring a copy to the new master with ypxfr is insufficient. You have to reassociate the key with the new master server name. If the map has an ASCII source file, you should copy this file to the new master.

How to Change a Map's Master Server

1. On the new master, become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

2. Change directories.

   newmaster# cd /var/yp

3. The Makefile must have an entry for the new map before you specify the map to make. If this is not the case, edit the Makefile now, using a map called sites.byname.

4. To update or remake the map, type the following.

   newmaster# make sites.byname

5. If the old master remains an NIS server, remote log in (rlogin) to the old master and edit Makefile. Make sure you comment out the section of the Makefile that made sites.byname so that it is no longer made there.

6. If sites.byname only exists as an ndbm file, remake it on the new master by disassembling a copy from any NIS server, then running the disassembled version through makedbm.

   newmaster# cd /var/yp newmaster# ypcat sites.byname | makedbm -domain-/sites.byname

   After making the map on the new master, you must send a copy of the new map to the other slave servers. Do not use yppush, because the other slaves will try to get new copies from the old master, rather than the new one. A typical method for circumventing this is to transfer a copy of the map from the new master back to the old master. To do this, become superuser, or assume an equivalent role, on the old master server and type the following.

   oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster sites.byname

   Now it is safe to run yppush. Any remaining slave servers still believe that the old master is the current master and will attempt to get the current version of the map from the old master. When clients do so, they will get the new map, which names the new master as the current master.

   If this method fails, you can log in as root on each NIS server and execute the ypxfr command shown above.