20.5 NIS in a Cluster

Network Information Service (NIS) is another client/server-based mechanism whereby data can be effectively distributed among network nodes. One common use of NIS is to distribute the /etc/passwd file among multiple network nodes so that a password changed on one node is effectively distributed to all nodes. The master server will be responsible for distributing copies of the database files (think password file) to the slave servers (if any). The NIS clients request information from the servers and are fed the data as they request it. The clients do not have copies of the database files. The slave servers have a copy of the file sent down to them from the master server.

A cluster can be an NIS client, NIS slave server, or an NIS master server. This service does not have the same level of flexibility as NFS in a cluster. You cannot have some members serving and others functioning as clients. All members must use the same NIS domain name. This means that you can't set up NIS such that half the cluster serves one domain, and the other half serves another domain. If NIS was configured at the time of cluster creation, the cluster will come up with NIS functioning. You can also configure NIS after the cluster is up using nissetup (8). On other members, use "/sbin/init.d/nis start". For master server, slave server, or client, the general sequence to configure NIS is to use nissetup on one member and then manually start up NIS on all other members.

The NIS server map transfer daemon (ypxfrd (8)) controls activities where the master server sends information to the slave servers (yppush (8)), or where the slave servers request data from the master server (ypxfr (8)). The ypxfrd (8) is multi-instance and active on all members. The rpc.yppasswdd (8) also exists on all members of a master server cluster but is single-instance. In other words, only one instance of rpc.yppasswdd is functioning at a time in the cluster but not implemented as a CAA.