Managing NFS and NIS, 2nd Edition - Mike Eisler [25]
Because NIS enforces consistent views of files on the network, it is suited for files that have no host-specific information in them. The /etc/vfstab file of filesystems and mount points, for example, is a terrible candidate for management by NIS because it's different on just about every machine. Files that are generally the same on all hosts in a network, such as /etc/passwd and /etc/hosts, fit the NIS model of a distributed database nicely.
In addition to managing configuration files, NIS can be used for any general data file that is accessed on one or more key fields. In a later chapter, we will discuss how to use NIS to manage your own site-specific databases.
This discussion of networking services starts with NIS because it provides the consistency that is a prerequisite for the successful administration of a distributed filesystem. Imagine a network in which you share files from a common server, but you have a different home directory and user ID value on every host. The advantages of the shared filesystem are lost in such a loosely run network: you can't always read or write your files due to permission problems, and you don't get a consistent view of your files between machines because you don't always end up in the same home directory. We'll start with a brief description of the different roles systems play under NIS, and then look at how to install NIS on each type of machine.
Masters, slaves, and clients
NIS is built on the client-server model. An NIS server is a host that contains NIS data files, called maps. Clients are hosts that request information from these maps. Servers are further divided into master and slave servers: the master server is the true single owner of the map data. Slave NIS servers handle client requests, but they do not modify the NIS maps. The master server is responsible for all map maintenance and distribution to its slave servers. Once an NIS map is built on the master to include a change, the new map file is distributed to all slave servers. NIS clients "see" these changes when they perform queries on the map file — it doesn't matter whether the clients are talking to a master or a slave server, because once the map data is distributed, all NIS servers have the same information.
Before going any further, let's take a quick and simple look at how this works. Figure 3-1 shows the relationship between masters, slaves, and clients.
Figure 3-1. NIS masters, slaves, and clients
Consider the hosts NIS map, which replaces the /etc/hosts files on individual systems. If you're familiar with Unix adminstration, you know that this file tells the system how to convert hostnames into IP (internet) addresses. When a client needs to look up the internet address of some system, it would normally read the hosts file. If NIS is running, however, the client bypasses its hosts file, and instead asks an NIS server (either a master or a slave server — it doesn't make any difference) for the information it needs.
Now the other side of the coin: you've added a system, and need to modify the hosts NIS map. You only modify the hosts file on the "master server" — remember, the master server knows the "truth" about the network.[1] Once you've made your changes, you can rebuild the NIS database (i.e., the NIS maps) on the master server. The master server then distributes new versions of the NIS maps to the slave servers, which now provide the updated information to the NIS clients.
With the distinction between NIS servers and clients firmly established, we can see that each system