Managing NFS and NIS, 2nd Edition - Mike Eisler [41]
Before retrying the NIS RPC that timed out, the client process (again, within some low-level library code) must get the domain rebound. Remember that ypbind keeps track of its current domain binding, and returns the currently bound server for a domain whenever a process asks to be bound. This theory of operation is a little too simplistic, since it would result in a client being immediately rebound to a server that just caused an RPC timeout. Instead, ypbind does a health check by pinging the NIS server before returning its name for the current domain binding. This ensures that the server has not crashed or is not the cause of the RPC failure. An RPC timeout could have been caused when the NIS packet was lost on the network or if the server was too heavily loaded to promptly handle the request. NIS RPC calls use the UDP protocol, so the network transport layer makes no guarantees about delivering NIS requests to the server — it's possible that some requests never reach the NIS server on their first transmission. Any condition that causes an RPC to time out is hopefully temporary, and ypbind should find the server responsive again on the next ping. ypbind will try to reach the currently bound server for several minutes before it decides that the server has died.
When the server health check fails, ypbind broadcasts a new request for NIS service for the domain. When a binding is dissolved because a host is overloaded or crashes, the rebinding generally locates a different NIS server, effecting a simple load balancing scheme. If no replies are received for the rebinding request, messages of the form:
NIS server not responding for domain "nesales"; still trying
appear on the console as ypbind continues looking for a server. At this point, the NIS client is only partially functional; any process that needs information from an NIS map will wait on the return of a valid domain binding.
Most processes need to check permissions using UIDs, find a hostname associated with an IP address, or make some other reference to NIS-managed data if they are doing anything other than purely CPU-bound work. A machine using NIS will not run for long once it loses its binding to an NIS server. It remains partially dead until a server appears on the network and answers ypbind 's broadcast requests for service. The need for reliable NIS service cannot be stressed enough. In the next chapter, we'll look at ways of using and configuring the service efficiently.
Chapter 4. System Management Using NIS
We've seen how NIS operates on master servers, slave servers, and clients, and how clients get map information from the servers. Just knowing how NIS works, however, does not lead to its efficient use. NIS servers must be configured so that map information remains consistent on all servers, and the number of servers and the load on each server should be evaluated so that there is not a user-noticeable penalty for referring to the NIS maps.
Ideally, NIS streamlines system administration tasks by allowing you to update configuration files on many machines by making changes on a single host. When designing a network to use NIS, you must ensure that its performance cost, measured by all users doing "normal" activities, does not exceed its advantages. This chapter explains how to design an NIS network, update and distribute NIS map data, manage multiple NIS domains, and integrate NIS hostname services with the Domain Name Service.
NIS network design
At this point, you should be able to set up NIS on master and slave servers and have a good understanding of how map changes are propagated from master to slave servers. Before creating a new NIS network, you should think about the number of domains and servers you will need. NIS network design entails deciding the number of domains, the number of servers for each domain, and the domain names. Once the framework has been established, installation and ongoing maintenance of the NIS servers is fairly