Chapter 4. System Management Using NIS

4.1.1. Dividing a network into domains

The number of NIS domains that you need depends upon the division of your computing resources. Use a separate NIS domain for each group of systems that has its own system administrator. The job of maintaining a system also includes maintaining its configuration information, wherever it may exist.

Large groups of users sharing network resources may warrant a separate NIS domain if the users may be cleanly separated into two or more groups. The degree to which users in the groups share information should determine whether you should split them into different NIS domains. These large groups of users usually correspond very closely to the organizational groups within your company, and the level of information sharing within the group and between groups is fairly well defined.

A good example is that of a large university, where the physics and chemistry departments have their own networked computing environments. Information sharing within each department will be common, but interdepartment sharing is minimal. The physics department isn't that interested in the machine names used by the chemistry department. The two departments will almost definitely be in two distinct NIS domains if they do not have the same system administrator (each probably gets one of its graduate students to assume this job). Assume, though, that they share an administrator -- why create two NIS domains? The real motivation is to clearly mark the lines along which information is commonly shared. Setting up different NIS domains also keeps users in one department from using machines in another department.

Conversely, the need to create splinter groups of a few users for access to some machines should not warrant an independent NIS domain. Netgroups are better suited to handle this problem, because they create subsets of a domain, rather than an entirely new domain. A good example of a splinter group is the system administration staff -- they may be given logins on central servers, while the bulk of the user community is not. Putting the system administrators in another domain generally creates more problems than the new domain was intended to solve.

4.1.2. Domain names

Choosing domain names is not nearly as difficult as gauging the number of domains needed. Just about any naming convention can be used provided that domain names are unique. You can choose to apply the name of the group as the NIS domain name; for example, you could use history, politics, and comp-sci to name the departments in a university.

If you are setting up multiple NIS domains that are based on hierarchical divisions, you may want to use a multilevel naming scheme with dot-separated name components:

cslab.comp-sci

staff.comp-sci

profs.history

grad.history

The first two domain names would apply to the "lab" machines and the departmental staff machines in the computer science department, while the two .history domain names separate the professors and graduate students in that department.

Multilevel domain names are useful if you will be using an Internet Domain Name Service. You can assign NIS domain names based on the name service domain names, so that every domain name is unique and also identifies how the additional name service is related to NIS. Integration of Internet name services and NIS is covered at the end of this chapter.

4.1.3. Number of NIS servers per domain

The number of servers per NIS domain is determined by the size of the domain and the aggregate service requirements for it, the level of failure protection required, and any physical network constraints that might affect client binding patterns. As a general rule, there should be at least two servers per domain: one master and one slave. The dual-server model offers basic protection if one server crashes, since clients of that server will rebind to the second server. With a solitary server, the operation of the network hinges on the health of the NIS server, creating both a performance bottleneck and a single point of failure in the network.

Increasing the number of NIS servers per domain reduces the impact of any one server crashing. With more servers, each one is likely to have fewer clients binding to it, assuming that the clients are equally likely to bind to any server. When a server crashes, fewer clients will be affected. Spreading the load out over several hosts may also reduce the number of domain rebindings that occur during unusually long server response times. If the load is divided evenly, this should level out variations in the NIS server response time due to server crashes and reboots.

There is no golden rule for allocating a certain number of servers for every n NIS clients. The total NIS service load depends on the type of work done on each machine and the relative speeds of client and server. A faster machine generates more NIS requests in a given time window than a slower one, if both machines are doing work that makes equal use of NIS. Some interactive usage patterns generate more NIS traffic than work that is CPU-intensive. A user who is continually listing files, compiling source code, and reading mail will make more use of password file entries and mail aliases than one who runs a text editor most of the time.

The bottom line is that very few types of work generate endless streams of NIS requests; most work makes casual references to the NIS maps separated by at most several seconds (compare this to disk accesses, which are usually separated by milliseconds). Generally, 30-40 NIS clients per server is an upper limit if the clients and servers are roughly the same speed. Faster clients need a lower client/server ratio, while a server that is faster than its clients might support 50 or more NIS clients. The best way to gauge server usage is to watch for ypbind requests for domain bindings, indicating that clients are timing out waiting for NIS service. Methods for observing binding requests are discussed in Section 13.4.2, "Displaying and analyzing client bindings".

Finally, the number of servers required may depend on the physical structure of the network. If you have decided to use four NIS servers, for example, and have two network segments with equal numbers of clients, joined by a bridge or router, make sure you divide the NIS servers equally on both sides of the network-partitioning hardware. If you put only one NIS server on one side of a bridge or router, then clients on that side will almost always bind to this server. The delay experienced by NIS requests in traversing the bridge approaches any server-related delay, so that the NIS server on the same side of the bridge will answer a client's request before a server on the opposite side of the bridge, even if the closer server is more heavily loaded than the one across the bridge. With this configuration, you have undone the benefits of multiple NIS servers, since clients on the one-server side of the bridge bind to the same server in most cases. Locating lopsided NIS server bindings is discussed in Section 13.4.2, "Displaying and analyzing client bindings".