If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers (see "NIS Problems Affecting Many Clients").
One client has problems, but other clients on the same subnet are operating normally. On the problem client, run ls -l on a directory, such as /usr, that contains files owned by many users, including some not in the client /etc/passwd file. If the resulting display lists file owners who are not in the local /etc/passwd as numbers, rather than names, this indicates that NIS service is not working on the client.
These symptoms usually mean that the client ypbind process is not running. Run ps -e and check for ypbind. If you do not find it, log in as superuser and start ypbind by typing:
One client has problems, the other clients are operating normally, but ypbind is running on the problem client. The client may have an incorrectly set domain.
On the client, run the domainname command to see which domain name is set.
Client#7 domainname neverland.com
Client#7 ls /var/yp... -rwxr-xr-x 1 root Makefile drwxr-xr-x 2 root binding drwx------ 2 root doc.com ...
If the domain name returned by running domainname on a machine is not the same as the server domain name listed as a directory in /var/yp, the domain name specified in the machine's /etc/defaultdomain file is incorrect. Log in as superuser and correct the client's domain name in the machine's /etc/defaultdomain file. This assures that the domain name is correct every time the machine boots. Now reboot the machine.
The domain name is case-sensitive.
If your domain name is set correctly, ypbind is running, and commands still hang, then make sure that the client is bound to a server by running the ypwhich command. If you have just started ypbind, then run ypwhich several times (typically, the first one reports that the domain is not bound and the second succeeds normally).
If your domain name is set correctly, ypbind is running, and you get messages indicating that the client cannot communicate with a server, this may indicate a number of different problems:
Does the client have a /var/yp/binding/domainname/ypservers file containing a list of servers to bind to? If not, run ypinit -c and specify in order of preference the servers that this client should bind to.
If the client does have a /var/yp/binding/domainname/ypservers file, are there enough servers listed in it if one or two become unavailable? If not, add additional servers to the list by running yppinit -c.
If none of the servers listed in the client's ypservers file are available, the client searches for an operating server using broadcast mode. If there is a functioning server on the client's subnet, the client will find it (though performance may be slowed during the search). If there are no functioning servers on the client's subnet can solve the problem in several ways:
If the client has no server on the subnet and no route to one, you can install a new slave server on that subnet.
You can make sure your routers are configured to pass broadcast packets so that the client can use broadcast to find a server on another subnet. You can use the netstat -r command to verify the route.
If there should be a route, but it is not working, make sure that the route daemon in.routed/in.rdisc is running. If it is not running, start it.
For reasons of security and administrative control it is preferable to specify the servers a client is to bind to in the client's ypservers file rather than have the client search for servers through broadcasting. Broadcasting ties up the network, slows the client, and prevents you from balancing server load by listing different servers for different clients.
Do the servers listed in a clients ypservers file have entries in the /etc/hosts file? If not, add the servers to the NIS maps hosts input file and rebuild your maps by running yppinit -c or ypinit -s as described "Working With NIS Maps".
Is the /etc/nsswitch.conf file set up to consult the machine's local hosts file in addition to NIS? See Chapter 2, The Name Service Switch for more information on the switch.
Is the /etc/nsswitch.conf file set up to consult files first for services and rpc?
When you use ypwhich several times on the same client, the resulting display varies because the NIS server changes. This is normal. The binding of the NIS client to the NIS server changes over time when the network or the NIS servers are busy. Whenever possible, the network stabilizes at a point where all clients get acceptable response time from the NIS servers. As long as your client machine gets NIS service, it does not matter where the service comes from. For example, an NIS server machine may get its own NIS services from another NIS server on the network.
In extreme cases where local server binding is not possible, use of the ypset command may temporarily allow binding to another server, if available, on another network or subnet. However, in order to use the -ypset option, ypbind must be started with either the -ypset or -ypsetme options.
For security reasons, the use of the -ypset and -ypsetme options should be limited to debugging purposes under controlled circumstances. Use of the -ypset and -ypsetme options can result in serious security breaches because while they are operative anyone can then alter server bindings causing trouble for others and permitting unauthorized access to sensitive data. If you must start ypbind with these options, once you have fixed the problem you should kill ypbind and restart it again without those options.
If ypbind crashes almost immediately each time it is started, look for a problem in some other part of the system. Check for the presence of the rpcbind daemon by typing:
% ps -ef | grep rpcbind
If rpcbind is not present or does not stay up or behaves strangely, consult your RPC documentation.
You may be able to communicate with rpcbind on the problematic client from a machine operating normally. From the functioning machine, type:
% rpcinfo client
If rpcbind on the problematic machine is fine, rpcinfo produces the following output:
program version netid address service owner ... 100007 2 udp 0.0.0.0.2.219 ypbind superuser 100007 1 udp 0.0.0.0.2.219 ypbind superuser 100007 1 tcp 0.0.0.0.2.220 ypbind superuser 100007 2 tcp 0.0.0.0.128.4 ypbind superuser 100007 2 ticotsord \000\000\020H ypbind superuser 100007 2 ticots \000\000\020K ypbind superuser ...
Your machine will have different addresses. If they are not displayed, ypbind has been unable to register its services. Reboot the machine and run rpcinfo again. If the ypbind processes are there and they change each time you try to restart /usr/lib/netsvc/yp/ypbind, reboot the system, even if the rpcbind daemon is running.