If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. See Troubleshooting NIS Issues That Affect a Single Client. However, if several NIS clients are failing to bind properly, the problem most likely exists on one or more of the NIS servers.
The following are common NIS issues that can affect multiple clients:
rpc.yppasswdd considers a non-restricted shell that begins with r to be restricted
To resolve this problem, do the following:
Create a /etc/default/yppasswdd file that contains a special string: "check_restricted_shell_name=1".
If the "check_restricted_shell_name=1" string is commented out, the r check does not occur.
Network or servers unreachable
NIS can hang if the network or NIS servers are so overloaded that the ypserv daemon cannot receive a response back from the client's ypbind process within the timeout period. NIS can also hang if the network is down.
Under both of these circumstances, every client that is 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 the ypserv daemon, 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 to determine if the server is reachable.
NIS daemons not running
If the servers are up and running, try to find a client that is behaving normally and run the ypwhich command on it. If the ypwhich command does not respond, kill it. Then, become the root role on the NIS server and check whether the NIS process is running as follows:
# ptree |grep ypbind 100759 /usr/lib/netsvc/yp/ypbind -broadcast 527360 grep yp
If neither the ypserv daemon (NIS server) nor the ypbind daemon (NIS client) daemons are running, restart them as follows:
Restart the NIS client service as follows:
# 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 is probably hung and should be restarted.
On the server, restart the NIS service as follows:
# svcadm restart network/nis/server
Servers have different versions of a NIS map
Because NIS propagates maps among servers, occasionally you might find different versions of the same map on various NIS servers that are on the network. This version discrepancy is normal and acceptable if the differences do not last too long.
The most common cause of map discrepancy is when normal map propagation is prevented. For example, a NIS server or router that is located between NIS servers is down. When all NIS servers and the routers between them are running, the ypxfr command should succeed.
If the servers and routers are functioning properly, proceed as follows:
Check the ypxfr log output. See Example 3–1.
Check the svc:/network/nis/xfr:default log file for errors.
Check the control files (crontab file and yupxfr shell script).
Check the ypservers map on the master server.
ypserv process crashes
When the ypserv process crashes almost immediately and does not stay up even after repeated activations, the debugging process is virtually the same as the debugging process for 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, run the following command 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
In the previous example, the following four entries represent the ypserv process:
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 system. If there are entries, deregister the service from rpcbind before restarting ypserv. For example, you would deregister the service from rpcbind as follows:
# rpcinfo -d number 1 # rpcinfo -d number 2
where number is the ID number that is reported by rpcinfo (100004 in the preceding example).
If a particular slave server has problems updating the maps, log in to that server and run the ypxfr command interactively.
If the command fails, a message about why it failed is displayed to enable you to fix the problem. If the command succeeds, but you suspect it has occasionally failed, create a log file on the slave server to enable the logging of messages as follows:
ypslave# cd /var/yp ypslave# touch ypxfr.log
The output of the log file resembles the output of the ypxfr command when you run it interactively, with the exception that each line in the log file is time stamped. If you notice unusual ordering in the timestamps that is because it shows each time that the ypxfr command was actually run. If copies of ypxfr ran simultaneously but took differing amounts of time to finish, each copy might write a summary status line to the log file in a different order than when the command was run. 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 that 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 listed, the slave server still operates perfectly as a server, but yppush does not propagate map changes to the slave server.
Update the maps on a broken slave server.
If the NIS slave server problem is not obvious, you can perform a workaround while debugging the problem by using the scp or ssh command. These commands copy a recent version of the inconsistent map from any healthy NIS server.
The following example shows how to transfer the problem map:
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
In the previous example, the * character has been escaped in the command line so that it will be expanded on ypmaster instead of locally on ypslave.