pushing of NIS maps fails with RPC failure message

[Kirk Reindl]

Hello,
I've inherited an Enterprise that is currently running NIS. We are trying to eliminate NIS with ldap, but that isn't moving too fast.

Recently I was tasked with eliminating our NIS master (server A) as this server was scheduled for decommission and "promoting" one of two slave servers (server B or server C) to be the master NIS server. I decided to make server B the new Master and server C would simply remain the only slave in the NIS domain.

The project was ultimately performed by a colleague of mine as I was called out of town. Here is the setup as it exists today, currently, after the project was “done”:

server A (old NIS master) --This Server is bye, bye --wheeled out of our datacenter.

server B (former slave server) --This is the guy we "promoted" to be the master.
HPUX 11.11
RP8400
Sept 2005 patches loaded

server C (former slave server) --We did nothing with this guy. He just stayed a slave. In fact, because we previously had two slaves in our production NIS domain, we're not entirely sure he worked to begin with.
HPUX 11.11
N4000
Sept 2005 patches loaded

The problem:

I noticed that some of the clients in this production domain (bgerp is the domainname) were not getting updated (IE, I couldn't login with the credentials I know I gave) when I was creating new user accounts in SAM on Server B. SAM was like “okay I need to push the maps”, so I said go for it. SAM pushed the maps and didn't say a thing.

Well the commonality was that the clients that weren't updating are "binding" or bound to slave server (server C)

So I don't know much about NIS but I started to troubleshoot, and I created another bogus account on the NIS master (server B), but this time I pushed the maps at the command line (ypmake--From the NIS master.)

Look what I'm getting:


ServerB # /var/yp/ypmake

For NIS domain bgerp:

Building the passwd map(s)... passwd build complete.
Pushing the passwd map(s): passwd.bynameStatus received from ypxfr on ServerC:
Failed - ypxfr had an RPC failure
passwd.byuidStatus received from ypxfr on ServerC:
Failed - ypxfr had an RPC failure

The group map(s) are up-to-date.
The hosts map(s) are up-to-date.
The networks map(s) are up-to-date.
The rpc map(s) are up-to-date.
The services map(s) are up-to-date.
The protocols map(s) are up-to-date.
The netgroup map(s) are up-to-date.
The aliases map(s) are up-to-date.
The publickey map(s) are up-to-date.
Building the netid map(s)... netid build complete.
Pushing the netid map(s): netid.bynameStatus received from ypxfr on ServerC:
Failed - ypxfr had an RPC failure

The auto_master map(s) are up-to-date.

ypmake complete: no errors encountered.

ServerB#

Thanks in advance for any direction. I award points.
Kirk

[Peter Nikitka]

Hi,

exchanging the NIS master is a not-so-standard task. There is a complete description how to do that, look into

http://docs.hp.com/en/5991-1154/index.html

Take into account, that the name of the NIS master is kept in all maps served by this master: a change of the name of the server progagating a NIS map will make NIS slaves drop that map because of security reasons.

mfG Peter

[Steven E. Protter]

Shalom,

I would be willing to bet that the old master is probably in one or more of the slaves /etc/rc.config.d/namesvr files

There are probably errors in the log files of the servers that would be helpful.

Ideally, the last system I'd de-commission is the NIS master, I'd swing the rest of the building into LDAP or ADS(ew windows) authenticaiton first. When the NIS master is no longer used, then decommission. I recommend this approach after solving this problem.

I think the answer is in the configuration files and there will be helpful error messages in the /var/adm/syslog/syslog.log file of the systems.

SEP

[MarkSyder · Accepted solution]

See my rather lengthy summary in http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1012414

where I went through the same process. I hope it helps you.

Mark Syder (like the drink but spelt different)

[Steven Schweda]

It's been a long time since I had to do this,
but as I (dimly) recall, a fairly easy way to
de-confuse the NIS servers is to run ypinit
(with appropriate options) on everyone. As I
(very dimly) recall, it asks for a list of
the servers, and that's your big chance to
omit any which are now gone. As I (even more
dimly) recall, there's a file somewhere
(perhaps somewhere in or under /var/yp) which
contains the list of servers, but note that
"man ypfiles" says:

*** No ASCII source exists for the ypservers database. It is
created from responses provided by the user of ypinit on the
master NIS server, and it has no matching ypservers.time
file.

"man ypinit" is also worth reading. My (dim)
recollection is that ypinit is safer than it
sounds. Just make sure that the new master
actually has good master (ASCII) source
files for all the maps.

[Kevin Wright]

you should re-run ypinit -s on you new slave box to redefine the new master.

[Dave Olker]

Kirk,

Are you still experiencing problems or have any of the above suggestions worked for you? If not, please tell us what the current situation is so we'll know what kind of assistance to offer.

Thanks,

Dave

[Kirk Reindl]

My apologies, I've been sent in a different direction now and can't test/entertain these suggestions at the moment. Thanks all who responded