SunSolve Internal


Infodoc ID   Synopsis   Date
21041   General NIS+ Stabilization and Maintainence   25 Oct 1999

Description Top

General NIS+ Stabilization and Maintainence.
--------------------------------------------

The procedures listed below will fix many minor NIS+ issues without
disrupting your NIS+ environment or affecting any users.  Unless the
NIS+ master server has drastic problems, these are safe to run on any
NIS+ host (master/replica/client) virtually anytime.

0) Feel free to kill name service cache daemon (nscd):

	# /etc/init.d/nscd stop

1) To bypass and clear any NIS+ cache problems kill nis_cachemgr
   and remove the cache files associated with this process.  They are
   recreated automatically if nis_cachemgr is restarted.  You may or
   may not have all of the files listed.

	# kill [PID-nis_cachemgr]
	# rm /var/nis/NIS_SHARED_DIRCACHE
	# rm /var/nis/.NIS_PRIVATE_DIRCACHE
	# rm /var/nis/.pref_servers

2) To make sure all of the servers (master and replicas) are synced up
   and have the same information stored, checkpoint all directory objects.
   It is recommened to always nisping in this order for a number of reasons.
   One reason to use this order is that org_dir typically contains the
   majority of modifications thus will take the longest time.  A nisping can
   load a server process enough to temporarily prevent additional nispings
   while the first completes.  (NOTE: "domainname" is the name of the domain
   the server serves.  It is not necessarily the domain it is a client of).
   This procedure should also be done every note via a cronjob.

	master# /usr/lib/nis/nisping -C `domainname`.
	master# /usr/lib/nis/nisping -C groups_dir.`domainname`.
	master# /usr/lib/nis/nisping -C org_dir.`domainname`.

   You should also checkpoint (nisping -C) any custom directory objects
   you have created.  `nisls` or `cat /var/nis/data/serving_list` will
   list all directory objects served.

3) To verify the checkpoint succeeded look at the output as well as the nislog.
   The number of updates remaining in the log should be equal to the number
   of directory objects for that domain.  This is typically 3 (domainname, 
   groups_dir, org_dir).

	master# /usr/sbin/nislog | head -4
	NIS Log printing facility.
	NIS Log dump :
	        Log state : STABLE.	<====== Confirm it is STABLE
	Number of updates    : 3	<====== Confirm number of updates

4) To be absolutely certain, compare the output of `nisping -u` for each
   directory object across all servers.  The timestamps should be the
   same on each server.  The timestamps for each directory object, however
   most likely will not be the same.

	master# /usr/lib/nis/nisping -u nisplus.lab.net.
	Last updates for directory nisplus.lab.net. : 
	Master server is master.nisplus.lab.net.
       		Last update occurred at Fri Oct  8 11:06:34 1999

	Replica server is replica.nisplus.lab.net.
	        Last Update seen was Fri Oct  8 11:06:34 1999

	master# /usr/lib/nis/nisping -u groups_dir.`domainname`.
	Last updates for directory groups_dir.nisplus.lab.net. : 
	Master server is master.nisplus.lab.net.
	        Last update occurred at Fri Oct  8 11:06:38 1999

	Replica server is prozac.nisplus.lab.net.
	        Last Update seen was Fri Oct  8 11:06:38 1999

	master# /usr/lib/nis/nisping -u org_dir.`domainname`.
	Last updates for directory org_dir.nisplus.lab.net. : 
	Master server is master.nisplus.lab.net.
	        Last update occurred at Fri Oct 22 14:05:25 1999

	Replica server is replica.nisplus.lab.net.
	        Last Update seen was Fri Oct 22 14:05:25 1999

   Compare...

	replica# /usr/lib/nis/nisping -u nisplus.lab.net.
	Last updates for directory nisplus.lab.net. : 
	Master server is master.nisplus.lab.net.
       		Last update occurred at Fri Oct  8 11:06:34 1999

	Replica server is replica.nisplus.lab.net.
	        Last Update seen was Fri Oct  8 11:06:34 1999

	replica# /usr/lib/nis/nisping -u groups_dir.`domainname`.
	Last updates for directory groups_dir.nisplus.lab.net. : 
	Master server is master.nisplus.lab.net.
	        Last update occurred at Fri Oct  8 11:06:38 1999

	Replica server is prozac.nisplus.lab.net.
	        Last Update seen was Fri Oct  8 11:06:38 1999

	replica# /usr/lib/nis/nisping -u org_dir.`domainname`.
	Last updates for directory org_dir.nisplus.lab.net. : 
	Master server is master.nisplus.lab.net.
	        Last update occurred at Fri Oct 22 14:05:25 1999

	Replica server is replica.nisplus.lab.net.
	        Last Update seen was Fri Oct 22 14:05:25 1999


5) If any checkpoint was not successful it may simply be that the server
   process (rpc.nisd) is busy.  Wait a while (sometimes up to 1 hour) and
   try again.  If still it fails most likely the master or the replica has
   a credential problem.

6) Now that the namespace is synced up across all servers we can continue
   with the stabilization.  To guarantee all hosts are contacting the correct
   NIS+ servers using the correct public key we update the NIS_COLD_START file.
   The root master is done slightly different.

	  rootmaster# /usr/sbin/nisinit -c -H 127.0.0.1
	
	othernisplus# /usr/sbin/nisinit -c -H [IP-of-master]

	NOTE: The [IP-of-master] is the IP address of the master server for the
	domain that host is a client of, not the domain that host serves (if
	the host is a server host).  The only exception are server hosts in the
	root domain, because they *are* clients of the domain they serve.

7) Update /etc/.rootkey to guarantee the unencrypted private key stored in
   that file is the most recent for the host.  If you do not know the
   current secureRPC password (possibly different from the login password)
   for this host you will not be able to do this step.  If this client does
   have a credential problem you will then have to re-initialize the client
   from scratch.

	# keylogout -f
	# keylogin
	
	NOTE: If the command above fails because you do not know the
	secureRPC password for this host simply restart the keyserv
	process to recredentialize the machine.  The keyserv process will
	read the /etc/.rootkey file when it starts.  As long as this client
	host does not have a credential problem it will be fine.

	# keylogin -r

8) To clear any cached up information stored in rpc.nisd's memory kill and
   restart it on all the servers.  Start with the master and then do the
   replicas.  Do them one at a time so as to not disrupt the namespace.
   To play it safe make sure rpc.nisd does not have any child processes
   spawned, indicating it may still be updating its objects, before doing this.

	server# kill [PID-of-rpc.nisd]
	server# /usr/sbin/rpc.nisd

9) At this point you should be all set.  You can restart nis_cachemgr and
   nscd if you killed it, too.

	# /usr/sbin/nis_cachemgr
	# /etc/init.d/nscd start

10) If the above procedures did not fix your NIS+ problem you may have a
    more troublesome issue.  Possibly a credential problem, *bad* replica,
    table corruption or something else.  Some other SunSolve documents that
    you may find useful are SRDB 19155, 10941 and Infodoc 17726.

Top

SunWeb Home SunWeb Search SunSolve Home Simple Search

Sun Proprietary/Confidential: Internal Use Only
Feedback to SunSolve Team