I first asked about this on 07Jan97 and published a summary
on 08Jan97. (This list is fast!) I said then that I wasn't
sure we would go through with the readdress and promised
to send a second summary if we did and if I remembered.
Well, we did (and I did :-) so here it is.
We took the naive approach to readdressing our server even though
it invalidates all user passwords. (The reason, based on
my dim understanding of NIS+, is that the passwords are encrypted
with a key that is somehow derived from the NIS+ server's IP
address. Change the address and you lose the encryption key.)
The switch went mostly well but we had a few problems. One workstation
that apparently had been getting routing information from the
NIS+ server refused to boot after the switch. We had moved the
NIS+ server to another subnet and the client didn't know how to
reach it. A "route -f add" fixed that.
Another problem: Our alternate server stubbornly insisted that the
NIS+ master server was at its old address. We fixed this by
removing the alternate server's /var/nis files and rebooting.
(Repeated attempts to solve the problem with "nisping -C" failed.)
I think this latter problem caused another problem we
encountered just after the switch. People's userids and
passwords worked only sometimes. This is just
a wild theory but for what it's worth: I think that some
of the NIS+ queries went to the master and succeeded while
others went to the alternate and failed. If I'm right, this
is a real "gotcha." Make sure all alternates are up to date
before allowing anyone to login.
-- Jim Stern -- Views here are my own, not Northrop Grumman's. (El Segundo, CA)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:46 CDT