With a bit more digging it seems that the rpc registration is somehow failing.

#rpcinfo -p | grep ypbind

Returns nothing, but it should return something like

100007 2 udp 620 ypbind 100007 1 udp 620 ypbind 100007 2 tcp 623 ypbind 100007 1 tcp 623 ypbind

This even though the ypbind process is running.

/etc/inti.d/ypbind waits after starting the ypbind daemon, so I put an rpcinfo -p call within the wait loop. The RPC registered ypbind programs sometimes show up the first time through the wait loop (not always), but are always gone by the next iteration. It seems that ypbind is briefly able to register with rpc, but then something is failing. Nothing pertinent is being written to any of the logs in /var/log. /var/log/messages contains a bogus ypbind start success message, but nothing else.

My RPC expertise is limited, so I would appreciate any suggestions.

Martyn

On 2011-09-30, at 15:42 , Martyn Klassen wrote:

I am having no luck getting NIS to work on a clean install of CentOS 6. It seems to be an issue with ypbind.

I have simple /etc/yp.conf which explicitly sets the server

domain myDomain server myServer

The service seems to start okay

#service ypbind start Starting NIS service: [OK] Binding NIS service: … [OK]

But when I try to use any of the yp services, like ypwhich

#ypwhich ypwhich: Can't communicate with ypbind

This is usually blamed on ypbind not running, but ypbind is confirmed to be running

#ps -ef | grep ypbind root 3033 1 0 15:11 ? 00:00:00 /usr/sbin/ypbind

ypcat also does not work

#ypcat netgroup No such map net group. Reason: Can't bind to the server which serves this domain

I have double checked that the server is running

#rpcinfo -u myServer ypserv program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

The domain name seems to be set correctly as well

#domainname myDomain

I have tried disabling iptables and selinux, but that has no effect. I am probably missing something obvious, but NIS has never given me these issues before.

Any suggestions on what might be the culprit?

Martyn