• Choose a category
• All
• Classic-Fiction

Client only

This is typical of desktop workstations, where the system administrator tries to minimize the amount of host-specific tailoring required to bring a system onto the network. As an NIS client, the host gets all of its common configuration information from an extant server.

Server only

While the host services client requests for map information, it does not use NIS for its own operation. Server-only configuration may be useful when a server must provide global host and password information for the NIS clients, but security concerns prohibit the server from using these same files. However, bypassing the central configuration scheme opens some of the same loopholes that NIS was intended to close. Although it is possible to configure a system to be an NIS server only, we don't recommend it and don't cover it in this book.

Client and server

In most cases, an NIS server also functions as an NIS client so that its management is streamlined with that of other client-only hosts.

It is possible to limit the scope of NIS to a few files that are changed infrequently, such as the /etc/protocols file, but doing so defeats the purpose of using NIS and greatly increases the cost of network management. Once NIS is running, it will be used by all system library functions that refer to maps (files) under NIS control. As mentioned in Section 2.3 it is possible to configure a client to get map or file information for a particular database from either NIS, files, or both.

Now that we have this client-server model for the major administrative files, we need a way to discuss where and when a particular set of files applies to a given host. It is much too simple-minded for a single set of files to apply to every host on a network; a reasonable system must support different clusters of systems with different administrative requirements. For example, a group of administrative systems and a group of research systems might share the same network. In most cases, these two clusters of systems don't need to share the same administrative information. In some cases, sharing the same administrative files might be harmful.

To allow an administrator to set different policies for different systems, NIS provides the concept of a domain. Most precisely, a domain is a set of NIS maps. A client can refer to a map (for example, the hosts map) from any of several different domains. Most of the time, however, any given host will only look up data from one set of NIS maps. Therefore, it's common (although not precisely correct) to use the term "domain" to mean "the group of systems that share a set of NIS maps." All systems that need to share common configuration information are put into an NIS domain. Although each system can potentially look up information in any NIS domain, each system is assigned to a "default domain," meaning that the system, by default, looks up information from a particular set of NIS maps. In our example, the research systems would, by default, look at the maps in the research domain, rather than the maps from the accounting domain; and so on.

It is up to the administrator (or administrators) to decide how many different domains are needed. In Chapter 4, we will give some rules-of-thumb for deciding how many domains are needed. Lest you think this is terribly complex, we'll tell you now: many networks, possibly even most small networks, can get by with a single domain. We will also take a closer look at the precise definition of an NIS domain.

* * *

[1] Remember: when you want to make a global change to the network, you must modify the file on the master server. Global changes made to slave servers or clients will, at best, be ignored.

Basics of NIS management

Now that we have laid a conceptual foundation, let's look at how to set the machinery in motion. Basic NIS management involves setting up NIS servers and enabling NIS on client hosts. Server management includes three tasks:

Installing a new NIS environment, building both master and slave servers.