Once you have one or more NIS servers running ypserv, you can set up NIS clients that query them. Make sure you do not enable NIS on any clients until you have at least one NIS server up and running. If no servers are available, the host that attempts to run as an NIS client will hang.
To enable NIS on a client host, first set up the nsswitch.conf file:
newclient# cp /etc/nsswitch.nis /etc/nsswitch.conf
Set up the domain name:
newclient# domainname bedrock
newclient# domainname > /etc/defaultdomain
newclient# /usr/sbin/ypinit -c
You will be prompted for a list of NIS servers. Enter the servers in order of proximity to the client.
Kill (if necessary) ypbind, and restart it:
newclient# ps -ef | grep ypbind
Once NIS is running, references to the basic administrative files are handled in two fundamentally different ways, depending on how nsswitch.conf is configured:
- The NIS database replaces some files. Local copies of replaced files (ethers, hosts, netmasks, netgroups, networks, protocols, rpc, and services) are ignored as soon as the ypbind daemon is started (to enable NIS).
 The netgroups file is a special case. Netgroups are only meaningful when NIS is running, in which case the netgroups map (rather than the file) is consulted. The netgroups file is therefore only used to build the netgroups map; it is never “consulted” in its own right.
- Some files are augmented, or appended to, by NIS. Files that are appended, or augmented, by NIS are consulted before the NIS maps are queried. The default/etc/nsswitch.conf file for NIS has these appended files: aliases, auto_*, group, passwd, services, and shadow. These files are read first, and if an appropriate entry isn’t found in the local file, the corresponding NIS map is consulted. For example, when a user logs in, an NIS client will first look up the user’s login name in the localpasswd file; if it does not find anything that matches, it will refer to the NIS passwd map.
Although the replaced files aren’t consulted once NIS is running, they shouldn’t be deleted. In particular, the /etc/hosts file is used by an NIS client during the boot process, before it starts NIS, but is ignored as soon as NIS is running. The NIS client needs a “runt” hosts file during the boot process so that it can configure itself and get NIS running. Administrators usually truncate hosts to the absolute minimum: entries for the host itself and the “loopback” address. Diskless nodes need additional entries for the node’s boot server and the server for the diskless node’s /usr filesystem. Trimming the hosts file to these minimal entries is a good idea because, for historical reasons, many systems have extremely long host tables. Other files, like rpc, services, and protocols, could probably be eliminated, but it’s safest to leave the files distributed with your system untouched; these will certainly have enough information to get your system booted safely, particularly if NIS stops running for some reason. However, you should make any local additions to these files on the master server alone. You don’t need to bother keeping the slaves and clients up to date.
This is from book <Managing NFS and NIS, Second Edition>