NIS machine types

There are three types of NIS machines:

• master server

• slave server

• client

NIS servers

By definition, an NIS server is a machine with a disk storing a set of NIS maps that it makes available to network hosts. The NIS server does not have to be the same machine as the file server, unless, of course, it is the only machine on the network with a disk.

NIS servers come in two varieties, master and slave. The machine designated as NIS master server contains the master set of maps that are updated as necessary. If you have only one NIS server on your network, designate it as the master server. Otherwise, designate the machine you think will be best able to propagate NIS updates with the least performance degradation.

You can designate additional NIS servers on your network as slave servers. A slave server has a complete copy of the master's set of NIS maps: Whenever the master server's maps are updated, it propagates the updates among the slave servers. The existence of slave servers allows the system administrator to distribute evenly the load implied in answering NIS requests. A stylized representation of the relationships among master, slaves, and clients is shown in ``Relationships among master, slave and client machines'' where the arrows represent the possible client-server binding at any one time.

Relationships among master, slave and client machines

A server may be a master in regard to one map and a slave in regard to another. However, randomly assigning maps to NIS servers can cause administrative confusion. You are strongly urged to make a single server the master for all the maps you create within a single domain. The examples in this part assume that one server is the master for all maps in the domain.

NIS clients

NIS clients run processes that request data from maps on the servers. Clients do not care which server is the master in a given domain, since all NIS servers have the same information. The distinction between master and slave server only applies to where you make the updates.

NIS binding

NIS clients get information from the NIS server through the binding process. Here is what happens during NIS binding:

1. A program running on the client (that is, a client process) needing information that is normally provided by an NIS map asks ypbind for the name of a server.

2. ypbind looks in the file /var/yp/binding/domainname/ypservers to get a list of the servers for the domain (see the section ``Setting up an NIS domain'').

3. ypbind initiates binding to the first server on the list. If the server does not respond, it tries the next, and so on until it finds a server or exhausts the list.

4. ypbind tells the client process which server to talk to. The client then forwards the request directly to the server.

5. The ypserv daemon on the NIS server handles the request by consulting the appropriate map.

6. ypserv then sends the requested information back to the client.

To find out which NIS server is currently providing service to a client, use the ypwhich(1nis) command:

ypwhich hostname

where hostname is the name of the client. If no hostname is mentioned, ypwhich defaults to the local host (that is, the machine on which the command is issued).

ypbind and subnetting

NIS clients can broadcast to find available NIS servers on the same subnet. Since broadcasts are only local subnet events that are not routed further, there must be at least one domain server (master or slave) on the same subnet as the client for broadcasting to work. The domain servers themselves may exist throughout different subnets since domain map propagation works across subnet boundaries. In a subnet environment, one common method is, if possible, to make the subnet router an NIS domain server. This allows it to serve clients on either subnet interface. For more information, see ``Setting up NIS clients for broadcasting''.