Managing NFS and NIS, 2nd Edition - Mike Eisler [230]
There's a moral to this story: you should rarely need to know the Ethernet address of a workstation, but it does help to have them recorded in a file or NIS map. This problem was solved with a bit of luck, because the machine generating incorrect replies had a different manufacturer, and therefore a different Ethernet address prefix. If the incorrectly configured machine had been from the same vendor, we would have had to compare the Ethernet addresses in the ARP table with what we believed to be the correct addresses for the machine in question.
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