To change the master server for a selected map, you first 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.
For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.
newmaster# cd /var/yp
If this is not the case, edit the Makefile now. For this example, add an entry for a map called sites.byname.
newmaster# make sites.byname
Make sure that you comment out the section of the Makefile that made the sites.byname map so that it is no longer made there.
First, disassemble a copy of the sites.byname file by using the ypcat command. Then, run 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 as shown.