This document describes promoting a root replica to be a root master.
This will only work if both the root master and the root replica are up
and running.
If the root master is not available this procedure will not work. In
this case it is strongly advised that the root master is restored from
backups. Otherwise it will be necessary to rebuild the NIS+ name space
from text copies of the tables. Text copies can be managed using
nisaddent(1M).
_______________________________________________________________________________
Preparation
_______________________________________________________________________________
Before you perform the procedure below, you should make sure:
1. The root master and root replica are up.
2. Make sure the proposed new root master has modify permissions on
the directory objects. A normal NIS+ environment would have all
NIS+ servers in an "admin" group. All important objects like
directories would then normally have "admin" as the group owner
and sufficient permissions to modify the object.
The nischgrp(1), nisgrpadm() and nischmod(1) commands can
be used to fix this.
3. Follow these steps on the root master. Note that it may be
necessary to wait between each nisping as servers may not respond
to further nispings while handling the previous one. Progress of
the nisping can be monitored using 'nisping -u'.
# nisping org_dir.`domainname`.
# nisping groups_dir.`domainname`.
# nisping `domainname`.
# nisping -C org_dir.`domainname`.
# nisping -C groups_dir.`domainname`.
# nisping -C `domainname`.
4. Verify the checkpoints have completed on the the root master and
replica. This can be done using nislog(1M) to see if there are any
updates left on the transaction log.
5. Do a system back up on the root master and replica.
This will make sure you have valid backups of your NIS+ servers
should anything go wrong.
6. Read through the following procedure completely and make
sure there are no questions regarding any of the steps.
7. If there are still questions remaining it is recommended that
this procedure is abandoned and further assistance found.
_______________________________________________________________________________
Procedure
_______________________________________________________________________________
1. On the root master, make the root replica the master of
the root domain.
rootmaster# nismkdir -m <rootreplica> <domainname>
This updates the root.object and the cold start file on the master
server. This is *not* propagated to the replicas due to bugs
4172969 and 4172980.
2. Check the contents of the cache on the root master server.
rootmaster# nisshowcache -v
This should confirm that the cold start file has been updated on
the master.
3. On the root master and all the root replicas, kill rpc.nisd and
nis_cachemgr. Please check step 4 as this requires remote copying
of files between servers. If the server names and IP addresses are
not in local files it will be necessary to either add them or to
copy the files in advance to a separate location on the server
first. Do not perform step 4 before step 3 as this will overwrite
the root.object and NIS_COLD_START while NIS+ is still running.
rootmaster# ps -e | grep nis
rootmaster# kill <rpc.nisd-PID> <nis_cachemgr-PID>
rootreplica# ps -e | grep nis
rootreplica# kill <rpc.nisd-PID> <nis_cachemgr-PID>
4. Copy the root.object and cold start file from the old root master
to the old replica server.
oldrootreplica# rcp oldrootmaster:/var/nis/data/root.object /var/nis/data
oldrootreplica# rcp oldrootmaster:/var/nis/NIS_COLD_START /var/nis
Repeat this step on any other root replica servers.
5. Restart rpc.nisd and nis_cachemgr on the old replica server.
oldrootreplica# /usr/sbin/rpc.nisd
oldrootreplica# /usr/sbin/nis_cachemgr -i
The old root replica should now be the new root master. Restarting
nis_cachemgr with the '-i' flag is *very* important.
Repeat this step on any other root replica servers.
6. On the new root master server, check the contents of the cache.
newrootmaster# nisshowcache -v
This should show that the new root master server is indeed the
master of the root domain.
7. Type the following on the new root master to modify the
subdirectories of the root domain.
newrootmaster# nismkdir -m <newrootmaster> org_dir.`domainname`.
newrootmaster# nismkdir -m <newrootmaster> groups_dir.`domainname`.
8. All clients of these servers will, in time, update their directory
caches. There are situations where this may not happen (bug
4084813) or there is a need to get the client updated quickly. In
which case the directory cache can be reinitialised on a client as
follows:
a. Kill nis_cachemgr.
root-client# ps -e | grep nis
root-client# kill <nis_cachemgr-PID>
b. Obtain a new cold start file from the new root master server.
root-client# nisinit -c -H <newrootmaster>
c. Restart nis_cachemgr.
root-client# /usr/sbin/nis_cachemgr -i
9. Change the ownership of the directory objects from the
oldrootmaster to the newrootmaster.
newrootmaster# nischown newrootmaster.`domainname`. `domainname`.
newrootmaster# nischown newrootmaster.`domainname`. org_dir.`domainname`.
newrootmaster# nischown newrootmaster.`domainname`. groups_dir.`domainname`.
At this point, the old root master is no longer serving requests and
the new root master is running.
You can stop here and restart the old root master as a new root replica
by just starting rpc.nisd and nis_cachemgr.
oldrootmaster# /usr/sbin/rpc.nisd
oldrootmaster# /usr/sbin/nis_cachemgr -i
However, if you swapped your root master and root replica, you probably
want to remove the old root master for some type of service, so remove
the old root master from the database tables. Remember, that the old
root master will still be in the admin group.
newrootmaster# nisrmdir -fs <oldrootmaster> groups_dir.`domainname`.
newrootmaster# nisrmdir -fs <oldrootmaster> org_dir.`domainname`.
newrootmaster# nisrmdir -fs <oldrootmaster> `domainname`.
Although the NIS+ directories are now owned by the new root master, the
objects they contain may still be owned by the old master. Though this
is mostly cosmetic and unlikely to cause problems it may be confusing.
It is simple to change the ownership on an object by object basis.
Alternatively, a simple shell script could be used to fix them all. A
Bourne shell example might look like this:
domain=`domainname`
for dir in org_dir groups_dir
do
for obj in `nisls $dir.$domain | tail +2`
do
nischown newrootmaster.$domain. $obj.$dir.$domain.
done
done
This should only be treated as an example and should not be used
verbatim. Bear in mind that other directories may exist in the NIS+
domain in addition to groups_dir and org_dir, eg ctx_dir.
Please note, these steps are based on the Workshop Portion of the
SA-385 "NIS+ System Administration with Workshop" text released January
1997. It does work and it is recommended that these steps be followed
accurately.