15.2. Renegade NIS server
A user on our network reported that he
could not log into his
workstation. He supplied his username and the same password
he'd been using for the past six months, and he consistently
was told "Login incorrect." Out of frustration, he
rebooted his machine. When attempting to mount NFS filesystems, the
workstation was not able to find any of the NFS server hosts in the
hosts NIS map, producing errors of the form:
nfs mount: wahoo: : RPC: Unknown host
There were no error messages from
ypbind, so it
appeared that the workstation had found an NIS server. The culprit
looked like the NIS server itself: our guess was that it was a
machine masquerading as a valid NIS server, or that it was an NIS
server whose maps had been destroyed. Because nobody could log into
the machine, we rebooted it in single-user mode, and manually started
NIS to see where it bound:
Single-user boot
# /etc/init.d/inetinit start
NIS domainname is nesales
Starting IPv4 router discovery.
Starting IPv6 neighbor discovery.
Setting default IPv6 interface for multicast: add net ff00::/8: gateway fe80::a00:20ff:fea0:3390
# /etc/init.d/rpc start
starting rpc services: rpcbind keyserv ypbind done.
# ypwhich
131.40.52.25
We manually invoked the
/etc/init.d/inetinit
startup script to initialize the domain name and configure the
routing. We then invoked the
/etc/init.d/rpc
script to start
ypbind. Notice that
ypwhich was not able to match the IP address of
the NIS server in the
hosts NIS map, so it
printed the IP address. The IP address belonged to a gateway machine
that was not supposed to be a NIS server. It made sense that clients
were binding to it, if it was posing as an NIS server, since the
gateway was very lightly loaded and was probably the first NIS server
to respond to
ypbind requests.
We logged into that machine, and verified that it was running
ypserv. The domain name used by the gateway was
nesales -- it had been brought up in the
wrong domain. Removing the
/var/yp/nesales
subdirectory containing the NIS maps and restarting the NIS daemons
took the machine out of service:
# cd /var/yp
# rm -rf nesales
# /usr/lib/netsvc/yp/ypstop
# /usr/lib/netsvc/yp/ypstart
We contacted the person responsible for the gateway and had him put
the gateway in its own NIS domain (his original intention). Machines
in
nesales that had bound to the renegade server
eventually noticed that their NIS server had gone away, and they
rebound to valid servers.
As a variation on this problem, consider an NIS server that has
damaged or incomplete maps. Symptoms of this problem are nearly
identical to those previously described, but the IP address printed
by
ypwhich will be that of a familiar NIS
server. There may be just a few maps that are damaged, possibly
corrupted during an NIS transfer operation, or all of the
server's maps may be corrupted or lost. The latter is most
probable when someone accidentally removes directories in
/var/yp.
To check the consistency of various maps, use
ypcat to dump all of the keys known to the
server. A few damaged maps can be replaced with explicit
yppush operations on the master server. If all
of the server's maps are damaged, it is easiest to reinitialize
the server. Slave servers are easily rebuilt from a valid master
server, but if the master server has lost the DBM files containing
the maps, initializing the machine as an NIS master server
regenerates only the default set of maps. Before rebuilding the NIS
master, save the NIS
Makefile, in
/var/yp or
/etc/yp, if you
have made local changes to it. The initialization process builds the
default maps, after which you can replace your hand-crafted
Makefile and build all site-specific NIS
maps.
 |  |  |
| 15. Debugging Network Problems |  | 15.3. Boot parameter confusion |
