NIS Binding Problems

Symptoms of NIS Binding Problems

Common symptoms of NIS binding problems include the following.

• Messages saying that ypbind can't find or communicate with a server

• Messages saying that server not responding

• Messages saying that NIS is unavailable

• Commands on a client limp along in background mode or function much slower than normal

• Commands on a client hang. Sometimes commands hang even though the system as a whole seems fine and you can run new commands

• Commands on a client crash with obscure messages, or no message at all

NIS Problems Affecting One Client

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.

ypbind Not Running on Client

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. Verify whether the NIS client services are running.

client# svcs \*nis\*
STATE          STIME    FMRI
disabled       Sep_01   svc:/network/nis/domain:default
disabled       Sep_01   svc:/network/nis/client:default

If the services are in a disabled state, log in as root or assume an equivalent role, and start the NIS client service.

client# svcadm enable network/nis/domain
client# svcadm enable network/nis/client

Missing or Incorrect Domain Name

One client has problems, the other clients are operating normally, but ypbind is running on the problem client. The client might have an incorrectly set domain.

On the client, run the domainname command to see which domain name is set.

client7# domainname
example.com

Compare the output with the actual domain name in /var/yp on the NIS master server. The actual NIS domain is shown as a subdirectory in the /var/yp directory.

client7# ls -l /var/yp
-rwxr-xr-x 1 root Makefile
drwxr-xr-x 2 root binding
drwx------ 2 root example.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. Reset the NIS domain name as shown in How to Set a Machine's NIS Domain Name.

Client Not Bound to Server

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).

No Server Available

If your domain name is set correctly, ypbind is running, and you get messages indicating that the client cannot communicate with a server, this might 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 ypinit -c.

• Do the selected NIS servers have entries in the /etc/inet/hosts file? To view the selected NIS servers, use the svcprop -p config/ypservers nis/domain command. If these hosts are not in the local /etc/inet/hosts file, add the servers to the hosts NIS maps and rebuild your maps by running the ypinit -c or ypinit -s command as described inWorking With NIS Maps.

• Is the name service switch set up to check the machine's local hosts file in addition to NIS? See Chapter 2, Name Service Switch (Overview) for more information on the switch.

• Is the name service switch set up to check files first for services and rpc? See Chapter 2, Name Service Switch (Overview) for more information about the switch.

ypwhich Displays Are Inconsistent

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 becomes stable 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 can get its own NIS services from another NIS server on the network.

When Server Binding is Not Possible

In extreme cases where local server binding is not possible, use of the ypset command can 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 more information, see the ypbind(1M) man page.

# /usr/lib/netsvc/yp/ypbind -ypset

For another method, see Binding to a Specific NIS Server.

---

Caution - For security reasons, the use of the -ypset and -ypsetme options is not recommended. Only use these options for debugging purposes under controlled circumstances. Use of the -ypset and -ypsetme options can result in serious security breaches because while the daemons are running, anyone can alter server bindings, causing trouble for others and permitting unauthorized access to sensitive data. If you must start the ypbind daemon with these options, after you have fixed the problem you must kill the ypbind process and restart it again without those options. To restart the ypbind daemon, use SMF as follows: # svcadm enable -r svc:/network/nis/client:default

---

ypbind Crashes

If the ypbind daemon crashes almost immediately each time it is started, look for a problem in the svc:/network/nis/client:default service log. Check for the presence of the rpcbind daemon by typing the following:

% ps -e |grep rpcbind

If rpcbind is not present or does not stay up or behaves strangely, check the svc:/network/rpc/bind:default log file. For more information, see the rpcbind(1M) and rpcinfo(1M) man pages.

You might be able to communicate with rpcbind on the problematic client from a machine operating normally. From the functioning machine, type the following:

% rpcinfo client

If rpcbind on the problematic machine is fine, rpcinfo produces the following output:

    program    version    netid    address    service    owner
...
    100007    3    udp6      ::.191.161          ypbind     1
    100007    3    tcp6      ::.135.200          ypbind     1
    100007    3    udp       0.0.0.0.240.221     ypbind     1
    100007    2    udp       0.0.0.0.240.221     ypbind     1
    100007    1    udp       0.0.0.0.240.221     ypbind     1
    100007    3    tcp       0.0.0.0.250.107     ypbind     1
    100007    2    tcp       0.0.0.0.250.107     ypbind     1
    100007    1    tcp       0.0.0.0.250.107     ypbind     1
    100007    3    ticlts    2\000\000\000       ypbind     1
    100007    2    ticlts    2\000\000\000       ypbind     1
    100007    3    ticotsord 9\000\000\000       ypbind     1
    100007    2    ticotsord 9\000\000\000       ypbind     1
    100007    3    ticots    @\000\000\000       ypbind     1
...

Your machine will have different addresses. If the addresses 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 the NIS service, reboot the system, even if the rpcbind daemon is running.

NIS Problems Affecting Many Clients

If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. See NIS Problems Affecting One Client. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers.

rpc.yppasswdd Considers a Non-Restricted Shell That Begins With r to Be Restricted

1. Create /etc/default/yppasswdd that contains a special string: "check_restricted_shell_name=1".

2. If the "check_restricted_shell_name=1" string is commented out, the 'r' check will not occur.

Network or Servers Are Unreachable

NIS can hang if the network or NIS servers are so overloaded that the ypserv daemon cannot receive a response back to the client ypbind process within the timeout period. NIS can also hang if the network is down.

Under these circumstances, every client on the network experiences the same or similar problems. In most cases, the condition is temporary. The messages usually go away when the NIS server reboots and restarts ypserv, when the load on the NIS servers or the network itself decreases, or when the network resumes normal operations.

Server Malfunction

Make sure the servers are up and running. If you are not physically near the servers, use the ping command.

NIS Daemons Not Running

If the servers are up and running, try to find a client machine behaving normally, and run the ypwhich command. If ypwhich does not respond, kill it. Then log in as root on the NIS server and check if the NIS process is running by typing the following:

# ptree |grep ypbind
100759 /usr/lib/netsvc/yp/ypbind -broadcast
        527360 grep yp

If neither the ypserv (NIS server) nor the ypbind (NIS client) daemons are running, restart them by typing the following:

# svcadm restart network/nis/client

If both the ypserv and ypbind processes are running on the NIS server, then run the ypwhich command. If the command does not respond, the ypserv daemon has probably hung and should be restarted. While logged in as root on the server, restart the NIS service by typing the following:

# svcadm restart network/nis/server

Servers Have Different Versions of an NIS Map

Because NIS propagates maps among servers, occasionally you might find different versions of the same map on various NIS servers on the network. This version discrepancy is normal and acceptable if the differences do not last for more than a short time.

The most common cause of map discrepancy is that something is preventing normal map propagation. For example, an NIS server or router between NIS servers is down. When all NIS servers and the routers between them are running, ypxfr should succeed.

If the servers and routers are functioning properly, check the following:

• Check the ypxfr log output. See Logging ypxfr Output.

• Check the svc:/network/nis/xfr:default log file for errors.

• Check the control files. See Check the crontab File and ypxfr Shell Script.

• Check the ypservers map on the master server. See Check the ypservers Map.

Logging ypxfr Output

If a particular slave server has problems updating maps, log in to that server and run the ypxfr command interactively. If the command fails, it indicates why it failed, and you can fix the problem. If the command succeeds, but you suspect it has occasionally failed, create a log file to enable the logging of messages. To create a log file, type the following on the slave.

ypslave# cd /var/yp
ypslave# touch ypxfr.log

This creates a ypxfr.log file that saves all output from ypxfr.

The output resembles the output ypxfr displays when run interactively, but each line in the log file is time stamped. (You might see unusual ordering in the timestamps. That is okay – the timestamp tells you when ypxfr started to run. If copies of ypxfr ran simultaneously but their work took differing amounts of time, they might actually write their summary status line to the log files in an order different from that which they were invoked.) Any pattern of intermittent failure shows up in the log.

Check the crontab File and ypxfr Shell Script

Inspect the root crontab file, and check the ypxfr shell script it invokes. Typographical errors in these files can cause propagation problems. Failures to refer to a shell script within the /var/spool/cron/crontabs/root file, or failures to refer to a map within any shell script can also cause errors.

Check the ypservers Map

Also, make sure that the NIS slave server is listed in the ypservers map on the master server for the domain. If it is not, the slave server still operates perfectly as a server, but yppush does not propagate map changes to the slave server.

Workaround to Update Maps on a Broken Slave Server

If the NIS slave server problem is not obvious, you can perform a workaround while you debug the problem, by using the scp or ssh command to copy a recent version of the inconsistent map from any healthy NIS server. The following shows how to transfer the problem map:

ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain

The * character has been escaped in the command line, so that it will be expanded on ypmaster, instead of locally on ypslave.

ypserv Crashes

When the ypserv process crashes almost immediately and does not stay up even with repeated activations, the debugging process is virtually identical to that described in ypbind Crashes. First, run the following command to see if any errors are being reported:

# svcs -vx nis/server

Check for the existence of the rpcbind daemon as follows:

# ptree |grep rpcbind

Reboot the server if you do not find the daemon. Otherwise, if the daemon is running, type the following and look for similar output:

% rpcinfo -p ypserver

% program     vers     proto     port     service
100000    4    tcp    111    portmapper
100000    3    tcp    111    portmapper
100068    2    udp    32813    cmsd
...
100007    1    tcp    34900    ypbind
100004    2    udp    731    ypserv
100004    1    udp    731    ypserv
100004    1    tcp    732    ypserv
100004    2    tcp    32772    ypserv

Your machine might have different port numbers. The four entries representing the ypserv process are the following:

100004     2     udp     731     ypserv
100004     1     udp     731     ypserv
100004     1     tcp     732     ypserv
100004     2     tcp     32772     ypserv

If there are no entries, and ypserv is unable to register its services with rpcbind, reboot the machine. If there are entries, de-register the service from rpcbind before restarting ypserv. To de-register the service from rpcbind, on the server type the following.

# rpcinfo -d number 1
# rpcinfo -d number 2

where number is the ID number reported by rpcinfo (100004, in the preceding example).