Readdressing a NIS+ root master server

2007-12-25 9:36:00

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)

Comments

Got something to say?

You must be logged in to post a comment.