 |
» |
|
|
|
This section lists the following common problems encountered
with NIS and suggests ways to correct them. If You Receive an NIS
"Server Not Responding" Message | |
Issue the /usr/sbin/ping(1M)
command on the NIS client to make sure the NIS server is up and
is reachable on the network. If the ping
command fails, either the server is down, or the network has a problem.
If the server is down, reboot it, or wait for it to come back up.
For information on troubleshooting network problems, see Installing
and Administering LAN/9000 Software. To boot your NIS client without waiting for the server to
come up, boot the client in single user mode, set NIS_CLIENT=0
in the /etc/rc.config.d/namsvrs
file, then boot your client the rest of the way up. Issue the domainname
command (with no arguments) on both the NIS server and the NIS client
to check whether their domain names are the same. If they are different,
log in as root to the NIS client and issue the following command
to change its domain name: Issue the ps -ef
command on the NIS server to check whether ypserv
is running. If it is not, follow these steps: In the /etc/rc.config.d/namesvrs
file on the NIS server, make sure the following variables are set: Issue the following command to start up the NIS
server: /sbin/init.d/nis.server start |
Make sure an NIS server exists on the same subnet
as the NIS client. The client broadcasts its bind request, and it
binds to the first server that responds to the request. Broadcasts
do not cross gateways or routers, so the server must be on the same
subnet as the client in order to receive the bind request. If you cannot configure an NIS server
on the same subnet as your NIS clients, see “To Bind an NIS Client
to a Server on a Different Subnet”.
If a User Cannot Log
In | |
If the user has recently
changed passwords, ask the user to try logging in with the old password.
If the user can log in using the old password, follow these steps: Issue the ps -ef
command on the NIS master server to make sure the yppasswdd
daemon is running. If it is not, issue the following command to
start all the NIS server processes: /sbin/init.d/nis.server start |
Check the cron
scripts on the slave servers to make sure transfers of the passwd
map from the master server are frequent enough. Once per hour is
usually frequent enough, but frequent map transfers may cause too
much network traffic. You might want to schedule map transfers for
late at night, and advise users to make their password changes just
before they go home.
Issue the following command on the NIS client to
determine which master server supplies the passwd
map to the client: /usr/bin/ypwhich -m passwd |
If the server does not respond, see “If You Receive an NIS
"Server Not Responding" Message”. If the ypwhich
command returns the name of the NIS master server, log in as root
to the master server and make sure the user has an entry in its
/etc/passwd file.
Then, issue the following commands on the master server to generate
the NIS passwd
database from the /etc/passwd
file and push it to the NIS slave servers: cd /var/yp
/usr/ccs/bin/make passwd |
Issue the domainname
command (with no arguments) to make sure the client's default
domain is the domain served by the NIS master server. If it is not,
log in as root to the NIS client, and issue the following command
to change its domain name: Issue the following command to check whether the
NIS client has an entry in the passwd
database on the NIS server to which it is bound: /usr/bin/ypmatch username passwd |
If the client has no entry in the passwd
database, issue the following command on the NIS server to which
the client is bound: This command transfers the passwd
database from the NIS master server to the server where you issue
the command. If the user's NIS client is bound to a
slave server, make sure the slave server is listed in the NIS master
server's ypservers
database. Follow these steps: Issue the following command on the NIS client to determine
which server the client is bound to: Log into the NIS master server, and issue the following
command: Issue the following command on the NIS master server
to write the contents of the ypservers
database to a temporary file: /usr/sbin/makedbm -u ypservers > tempfile |
If the NIS slave server is not listed in tempfile,
use a text editor to add it, and then issue the following command
to rebuild the ypservers
database: /usr/sbin/makedbm tempfile ypservers |
Make sure the NIS escape entry in the /etc/passwd
file on the client does not have an asterisk
in the password field. On HP systems, the NIS escape entry in the
/etc/passwd file
should be
If You Receive an "Unknown
Host" Message | |
Issue the following commands
to trace a lookup of the unknown host: nslookup
> set swtrace
> hostname |
The trace will indicate which name services (BIND, NIS, or
/etc/hosts) were
queried and in what order. If your host is not performing lookups
the way you want, see Chapter 5 “Configuring the Name Service Switch”
for instructions on configuring the Name Service Switch. Type exit to exit from nslookup. Issue the following command on the NIS client to
determine which master server supplies the hosts
map: /usr/bin/ypwhich -m hosts |
If the server does not respond, see “If You Receive an NIS
"Server Not Responding" Message”. If the ypwhich
command returns the name of the NIS master server, log in as root
to the master server and make sure the unknown host is listed in
its /etc/hosts
file. Then, issue the following commands on the master server to
generate the NIS hosts
database from the /etc/hosts
file and push it to the NIS slave servers: cd /var/yp
/usr/ccs/bin/make hosts |
Issue the domainname
command (with no arguments) to make sure the client's default
domain is the domain served by the NIS master server. If it is not,
log in as root to the NIS client and issue the following command
to change its domain name: Issue the following command to check whether the
unknown host is listed in the hosts
database on the NIS server to which the client is bound: /usr/bin/ypmatch hostname hosts |
If the host is not listed in the hosts
database, issue the following command on the NIS server to which
the client is bound: This command transfers the hosts
database from the NIS master server to the server where you issue
the command. If the NIS client is bound to a slave server, make
sure the slave server is listed in the NIS master server's
ypservers database.
Follow these steps: Issue the following command on the NIS client to determine
which server the client is bound to: Log in as root to the NIS master server and issue
the following command to change to the directory where the domain
databases reside: On the NIS master server, issue the following command
to write the contents of the ypservers
database to a temporary file: /usr/sbin/makedbm -u ypservers > tempfile |
If the NIS slave server is not listed in tempfile,
use a text editor to add it, and then issue the following command
to rebuild the ypservers
database: /usr/sbin/makedbm tempfile ypservers |
If an NIS Client Cannot
Bind to a Server | |
If NIS commands return any of the following messages, ypcat: can't bind to an NIS server for domain domainname
ypmatch: can't match key.
reason: can't communicate with ypbind
ypwhich: clntudp_create error RPC_PROG_NOT_REGISTERED |
then ypbind
is not running on the client. Issue the following command to start
all the NIS client processes: /sbin/init.d/nis.client start |
If NIS Returns Incorrect
Information | |
Issue the following command
on the NIS client to determine which master server supplies the
appropriate NIS map: /usr/bin/ypwhich -m mapname |
If the server does not respond, see “If You Receive an NIS
"Server Not Responding" Message”. Log in as root to the NIS master server, and issue
the following command to check the contents of the appropriate NIS
map: /usr/bin/ypcat -k mapname |
If the map contents are not correct, edit the ASCII file from
which the map is generated. Then issue the following commands to
regenerate the map and push it to the slave servers: cd /var/yp
/usr/ccs/bin/make mapname |
Issue the domainname
command (with no arguments) to make sure the client's default
domain is the domain served by the NIS master server. If it is not,
log in as root to the NIS client, and issue the following command
to change its domain name: Issue the following command on the NIS client to
check the contents of the map on the NIS server to which the client
is bound: /usr/bin/ypcat -k mapname |
If the contents are not correct, log in as root to the server
that serves the NIS client, and issue the following command: This command transfers the map from the NIS master server
to the server where you issue the command. If the NIS client is bound to a slave server, make
sure the slave server is listed in the NIS master server's
ypservers database.
Follow these steps: Issue the following command on the NIS client to determine
which server the client is bound to: Log in as root to the NIS master server and issue
the following command to change to the directory where the domain
databases reside: On the NIS master server, issue the following command
to write the contents of the ypservers
database to a temporary file: /usr/sbin/makedbm -u ypservers > tempfile |
If the NIS slave server is not listed in tempfile,
use a text editor to add it, and then issue the following command
to rebuild the ypservers
database: /usr/sbin/makedbm tempfile ypservers |
Make sure the slave servers have cron
scripts that schedule regular updates of the map.
|
Printable version
