recover public cred in NIS+

admins attempted to update system's root password and private keys, not the public keys for the system. The public key was updated on the NIS+ master with the "nisclient -co" command. Once the public key is updated on the NIS+ master, encrypted communication immediately fails between the replicas and all the clients. Communication works fine from the replicas to the clients. Our solution was to get all the replicas and clients to realize the public key change, which was re-NIS-ing all the servers. That is a boat load of work. There may be another option, use/review at your own risk, In the lab it was found that there seems to be way to recover the public key. In perhaps a roundabout way. It appears that the NIS+ master applies updates to its memory loaded copy of the NIS+ db and writes the updates to a file, in the format /var/nis/data/<tablename>.log. The update does not appear to immediately be applied to the <tablename> file until all or at least some replicas can have the update applied as well. Since the public key update broke communication immediately, the update would stay in the log file. The update is not applied to the cred table file, even on the master. So to stop the NIS+ process, delete the log file, restart NIS+, is like having the update never applied.

How we seemed to recover to the pre-public key DB level.
Stop nis processes on the NIS+ master.
recover the /etc/.rootkey file
delete the file /var/nis/data/cred.org_dir.log
restart NIS+ and other processes on the NIS+ master
rpc.nisd, nis_cachemdr, rpc.nispasswdd, keyserv, nscd, autofs nfsclient, crond
After this all communication is restored from the replicas and clients to the NIS+ master