Troubleshooting NIS Issues
The following information describes how to debug issues with the Network Information Service (NIS) (pronounced "niss" in this guide). Before attempting to debug a NIS server or client problem, review Chapter 5, About the Network Information Service in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS.
This section contains the following topics:
Troubleshooting NIS Binding Issues
-
Messages saying that the ypbind daemon cannot find or communicate with a server.
-
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 messages at all.
The following are common symptoms of NIS binding problems:
Troubleshooting sues That Affect a Single NIS Client
If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. However, if many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers. See Troubleshooting Issues That Affect Multiple NIS Clients.
-
ypbind daemon not running on the client
One client has problems, but the other clients on the same subnet are operating normally. On the problem client, run the ls –l command on a directory that contains files that are owned by many users (such as /usr), including files that are not in the client /etc/passwd file. If the resulting display lists file owners who are not in the local /etc/passwd file as numbers rather than names, the NIS service is not working on the client.
These symptoms usually indicate that the client's ypbind process is not running. Verify whether the NIS client services are running as follows:
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 and become the root role, then start the NIS client service as follows:
client# svcadm enable network/nis/domain client# svcadm enable network/nis/client
-
Missing or incorrect domain name
One client has problems and other clients are operating normally, but the ypbind daemon is running on that client. In this case, the client might have an incorrectly set domain.
Run the domainname command on the client to determine which domain name is set:
client# domainname example.com
Compare the output with the actual domain name in the /var/yp directory on the NIS master server. As shown in the following example, the actual NIS domain is shown as a subdirectory in the /var/yp directory:
client# 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 that is displayed in the output of the domainname command on the NIS client is not the same as the server domain name that is listed as a subdirectory in the /var/yp directory, the domain name in the config/domain property of the nis/domain service is incorrect. Reset the NIS domain name. For instructions, see How to Set a Machine’s NIS Domain Name in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS.
Note - The NIS domain name is case-sensitive. -
NIS Client not bound to server
If your domain name is set correctly and the ypbind daemon is running, yet commands still hang, make sure that the client is bound to a server by running the ypwhich command. If you have just started the ypbind daemon, then run the ypwhich command. You might need to run the ypwhich command several times. Typically, the first time you run the command, it reports that the domain is not bound. The second time you run the command, it should proceed normally.
-
No NIS server available
If your domain name is set correctly and the ypbind daemon is running, but you receive messages indicating the NIS client cannot communicate with the server, check the following:
-
Does the client have a /var/yp/binding/domainname/ypservers file that contains a list of servers to bind to? To view the selected NIS servers, use the svcprop –p config/ypservers nis/domain command. If not, run the ypinit –c command to specify which servers this client should bind to, in order of preference.
-
If the client does have a /var/yp/binding/domainname/ypservers file, are there enough servers listed, in case one or two servers become unavailable? To view the selected NIS servers, use the svcprop –p config/ypservers nis/domain command. If not, add additional servers to the list by running the ypinit –c command.
-
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 systems 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. For information, see Working With NIS Maps in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS.
-
Is the name service switch set up to check the system's local hosts file, in addition to NIS? For more information, see Chapter 2, About the Name Service Switch in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS.
-
Is the name service switch set up to check files first for services and then rpc?
-
-
ypwhich displays are inconsistent
If you run the ypwhich command several times on the same client, the resulting display varies because the NIS server changes. This behavior 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 the point when all clients receive an acceptable response time from the NIS servers. As long as the client receives the NIS service, it does not matter where the service comes from. For example, one NIS server can receive NIS services from another NIS server on the network.
-
What to do when NIS server binding is not possible
In extreme cases where local server binding is not possible, use the ypset option with the ypbind command to temporarily allow binding to another NIS server on another network or subnet, if available. Note that to use the –ypset option, you must start the ypbind daemon by using either the –ypset or –ypsetme option. 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 in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS.
Caution - For security reasons, using the –ypset or –ypsetme option is not recommended. Only use these options for debugging purposes under controlled circumstances. Using the –ypset or –ypsetme option can result in serious security breaches. While the daemons are running, anyone can alter NIS server bindings, which can permit unauthorized access to sensitive data. If you must start the ypbind daemon by using either of these options, kill the ypbind process after you have corrected the problem, then restart it without specifying these options. Restart the ypbind daemon as follows:
# svcadm enable -r svc:/network/nis/client:default
See the ypset(1M) man page. -
ypbind daemon crashes
If the ypbind daemon crashes almost immediately each time you start it, look for a problem in the svc:/network/nis/client:default service log. Check for the presence of the rpcbind daemon as follows:
% ps -e |grep rpcbind
If the rpcbind daemon is not present, 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 the rpcbind daemon on the problematic client from a system that is functioning normally.
Run the following command from a functioning system:
% rpcinfo client
If the rpcbind daemon on the problematic system is fine, the following output is displayed:
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 ...
If no addresses are displayed (your system will have different addresses), the ypbind daemon was unable to register its services. Reboot the system and run the rpcinfo command again. If the ypbind processes are there and they change each time you attempt to restart the NIS service, reboot the system, even if the rpcbind daemon is running.
The following are common NIS issues that affect a single client:
Troubleshooting Issues That Affect Multiple NIS Clients
If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. See Troubleshooting sues That Affect a Single NIS 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 rpc.yppasswdd command 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.
-
NIS Server malfunction
Make sure the NIS 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 NIS 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.
-
Check the ypxfr log output. See Example 21, Logging ypxfr Command Output.
-
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.
If the servers and routers are functioning properly, proceed as follows:
-
-
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 NIS 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 rtmapper 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 tcp 732 ypserv 100004 2t 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).
The following are common NIS issues that can affect multiple clients:
-
If a particular slave server has problems updating the maps, log in to that slave 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.
Note - When you have resolved the problem, turn off logging by removing the log file. If you forget to remove it, the file continues to grow without limit. -
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.