Managing NFS and NIS, 2nd Edition - Mike Eisler [102]
In the client's root filesystem, modify its hosts file and boot scripts to reflect the new hostname: # cd /export/root/newname/etc
# vi hosts
# vi hostname.*[0-9]*
# vi nodename
# vi /etc/net/*/hosts
In Solaris, the hostname is set in a configuration file with the network interface as an extension; for example: hostname.hme0. It is essential that the host's name and IP address in its own hosts file agree with its entries in the NIS map, or the machine either boots with the wrong IP address or doesn't boot at all.
Aside from shutting the client down, the remainder of this operation could be automated using a script that takes the old and new client names as arguments. The number of changes that were made to NIS maps should indicate a clear benefit of using NIS: without the centralized administration, you would have had to change the /etc/ethers and /etc/bootparams files on every server, and update /etc/hosts on every machine on the network.
Troubleshooting
When diskless clients refuse to boot, they do so rather emphatically. Shuffling machines and hostnames to accommodate changes in personnel increases the likelihood that a diskless machine will refuse to boot. Start debugging by verifying that hostnames, IP addresses, and Ethernet addresses are all properly registered on boot and NIS servers. The point at which the boot fails usually indicates where to look next for the problem: machines that cannot even locate a boot block may be getting the wrong boot information, while machines that boot but cannot enter single-user mode may be missing their /usr filesystems.
Missing and inconsistent client information
There are a few pieces of missing host information that are easily tracked down. If a client tries to boot but gets no RARP response, check that the NIS ethers map or the /etc/ethers files on the boot servers contain an entry for the client with the proper MAC address. A client reports RARP failures by complaining that it cannot get its IP address.
Diskless clients that boot part-way but hang after mounting their root filesystems may have /etc/hosts files that do not agree with the NIS ethers or hosts maps. It's also possible that the client booted using one name and IP address combination, but chose to use a different name while going through the single-user boot process. Check the boot scripts to be sure that the client is using the proper hostname, and also check that its local /etc/hosts file agrees with the NIS maps.
Other less obvious failures may be due to confusion with the bootparams map and the bootparamd daemon. Since the diskless client broadcasts a request for boot parameters, any host running bootparamd can answer it, and that server may have an incorrect /etc/bootparams file, or it may have bound to an NIS server with an out-of-date map.
Sometimes when you correct information, things still do not work. The culprit could be caching. Solaris has a name service cached daemon, /usr/sbin/nscd, which, if running, acts as a frontend for some databases maintained in /etc or NIS. The nscd daemon could return stale information and also stale negative information, such as a failed lookup of an IP address in the hosts file or map. You can re-invoke nscd with the -i option to invalidate the cache. See the manpage for more details.
Checking boot parameters
The bootparamd daemon returns a fairly large bundle of values to a diskless client. In addition to the pathnames used for root and swap filesystems, the diskless client gets the name of its boot server and a default route. Depending on how the /etc/nsswitch.conf is set up, the boot server takes values from a local /etc/bootparams, so ensure that local file copies match NIS maps if they are used. Changing the map on the NIS master server will not help a diskless client if its boot server uses only