ypbind error message

[Andrew Kaplan]

Hi there --

I am trying to set up an NIS client on a Fedora Core 12 64-bit system. The ypbind daemon is running via the /etc/init.d/ypbind script. However, whenever I run the ypwhich command, the following error message appears on-screen:

[root@XiO_04 yp]# ypwhich
ypwhich: Can't communicate with ypbind

The client has been configured so the domain is set, and the client will broadcast for the first available nis server. The client is on a subnet where there is one nis slave server, which is running Fedora Core 2 32-bit.

One thought that came to mind concerning this problem is the following: Could the wide disparity between the two distros be a cause for the error message?

[Steven Schweda · Accepted solution]

> I am trying to set up an NIS client [...]

How, exactly?

> [...] The ypbind daemon is running via the
> /etc/init.d/ypbind script. [...]

Is ypbind actually running, or do you merely
believe that it ought to be running?

man ps

A Google search for the error message led to,
for example:

http://docs.sun.com/app/docs/doc/805-4036/6j3r3qb96?a=view

ypwhich: can't communicate with ypbind

Cause

This message from the ypwhich(1)
command indicates that the NIS binder
process ypbind(1M) is not running on
the local machine.


> The client has been configured so the
> domain is set, [...]

Showing an actual "domainname" command with
its actual output might be more persuasive
than offering your opinion with no actual
evidence to justify it.

> [...] and the client will broadcast for the
> first available nis server.

Your opinion again, or did you observe some
actual behavior?

> [...] Could the wide disparity between the
> two distros [...]

Seems unlikely. Generally speaking, NIS is
NIS.

[Andrew Kaplan]

We are looking at the possibility of the following two items that might be the cause for the problem:

1. The hostname of the client had an underscore as part of its name.

2. The NetworkManager daemon was running in the background.

When we renamed the client without the underscore as part of its hostname, and turned off NetworkManager, the ypwhich command and, by extension, ypbind daemon appeared to run without issue.

Your thoughts?

[Andrew Kaplan]

My colleagues and I were able to solve the problem. Here is the solution.

1. Verify, and change if necessary, the hostname does not contain any forbidden characters as part of its name.
2. Deactivate and disable the NetworkManager daemon from running on the system. This utility has been known to cause domain authentication problems.
3. Make sure the /etc/nsswitch.conf file has a line that reads as follows:

hosts: files nis dns