This chapter contains a general description of the SGI implementation of the Sun Microsystems network information service NIS. It provides an overview of NIS, an explanation of the NIS client-server model, and an introduction to NIS domains and NIS maps.
This chapter contains these sections:
NIS is a network lookup service that provides a centralized database of information about the network to systems participating in the service. The NIS database is fully replicated on selected systems and can be queried by participating systems on an as-needed basis. Maintenance of the database is performed on a central system.
The purpose of NIS is to make network administration more efficient by reducing the risk of error and the time required to perform redundant file management tasks. For example, maintaining the /etc/hosts database on a large network might require creating a script to automatically copy the /etc/hosts file from a central system to all systems on the network. It also requires setting up the appropriate access permissions on each system to enable this file transfer; this is a redundant and time-consuming process. By contrast, on networks using NIS, maintaining the /etc/hosts database requires modifying a single file, typically /etc/hosts, on a single system.
On many networks, a number of information sources are available to provide information to network applications. For this reason, most applications have a standard lookup rule for finding the information they need. Starting with IRIX 6.5, the default lookup order is specified in the /etc/nsswitch.conf file.
NIS can service networks with approximately 1000 systems. Larger networks can be organized into multiple NIS service areas, or domains.
NIS is an application layer service that can be used on any network using the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) for transport layer services. NIS also relies on remote procedure call (RPC) for session layer services and external data representation (XDR) for presentation layer services. Because the NIS application adheres to these standard network protocols, it is portable and works with a variety of vendors' platforms.
The network protocols TCP and UDP provide the services required to transport messages on the same system or between remote systems. TCP provides reliable, connection-oriented transport. UDP provides unreliable, connectionless transport. TCP and UDP are protocols that are widely accepted and used in the network environment, making them the logical choices for NIS and several other network applications.
RPC and XDR are services that bridge the gap between the transport layer services and the network application. They provide the functionality required to build distributed applications and resolve operating system and hardware architectural differences.
RPC provides a message passing scheme. It allows information to be passed between procedure calls that do not reside in the same address space. The address space can be located on the same system or it may reside on a remote system. In the NIS application, RPC enables client and server processes on local or remote systems to access the NIS database. NIS users are not aware that the procedure calls are occurring between two different systems.
XDR translates differences that can occur between machine architectures. It allows remote procedure calls and/or an application to interpret an RPC message independent of machine architecture. In the NIS application, XDR services allow systems from multiple vendors access to an NIS database located on any vendor's system. RPC and XDR are not exclusive to NIS. RPC and XDR are industry standards and are used in a variety of distributed network applications.
Figure 1-1 illustrates the NIS software implementation in the context of the Open Systems Interconnect (OSI) model.
An NIS client is a process running on a system that requests data from an NIS database. An NIS server is a process running on a system that provides data from the NIS database . The terms client and server designate both processes and systems: a system is considered a client when requesting NIS data, and it is considered a server when providing NIS data. A system can function as a client and a server simultaneously.
Sometimes client requests are handled by NIS servers running on the same system, and sometimes they are serviced by NIS servers running on a different system. If one NIS server system fails, client processes obtain NIS services from another. In this way, the NIS service remains available even when an NIS server system goes down.
NIS servers, each of which contains a copy of the NIS database, are divided into two groups: master servers and slave servers. A master server is the system on which NIS databases are originally created and maintained. A slave server is a system that holds a duplicate copy of the database. A server may be a master server with respect to one database and a slave server with respect to another.
The master server makes updated database information available to slave servers by a process known as propagation. Propagation ensures the consistency of database information between the master server and its slave servers.
The NIS database is composed of a group of files known as maps. Maps are created with NIS tools that convert input files (usually standard ASCII files) to files in database record format (see the mdbm(3B) man page). Since data in mdbm format is faster to find than ASCII data, using mdbm files increases NIS performance.
Each NIS map has a map name that programs use to access it. Any program using an NIS map must recognize the format of the data it contains.
Maps are composed of keys and values. A key is a particular field in the map that the client must specify whenever it queries the map; a value is an attribute of the key that is returned from the query. For example, in the map called hosts.byname, the keys are the names in individual systems, and the values are the ip-address,hostname lines, similar to those in /etc/hosts.
At steady state, maps throughout the network contain consistent information. In this state, a client query receives the same answer to the query, regardless of which server responds to it. This consistency of information allows multiple servers to operate on a network, increasing the availability and reliability of the NIS service.
An NIS domain is a collection of systems using the same NIS database. To participate in the NIS service, a system must belong to an NIS domain.
Figure 1-2 shows the basic layout for the systems in Building 1 and a domain called eng.
The domain eng consists of the master server, one slave server, and three clients. One system on the network does not participate in NIS at this time but may be included in the domain at a later date.
The NIS databases are contained in subdirectories of the NIS home directory /var/ns/domains. These subdirectories are named for the domain whose database they contain. For example, in Figure 1-2, both servers contain the database for the eng domain in a subdirectory named /var/ns/domains/eng.
The Internet is a registered organization of wide area networks originally funded by DARPA (U.S. Defense Advanced Research Projects Agency). It is organized into domains, machines grouped into networks that are given names to identify them clearly. In the Internet naming scheme, commercial businesses in the United States are given names that end in .com (sgi.com is one such), educational institutions use .edu, and governmental organizations use domain names ending in .gov.
Domains within an organization are organized on the same grouping principle. For example, in a business with the Internet domain name of dender.com, two separate NIS domains might be finance and engineering, which would use the domain names .finance and .eng, respectively. If you subdivided dender.com this way, the NIS domain name of engineering would be eng.dender.com, and the NIS domain name of finance would be finance.dender.com.
Often the Internet domain name is used as the basis for the NIS domain, a useful practice, but not required. You can use some other NIS domain name, but you should understand fully about domain names and their interaction with other aspects of name service before doing so. For further details on domains, refer to IRIX Admin: Networking and Mail.
Complex networks that require large NIS databases, approximately 1000 systems or more, should be evaluated for multiple NIS domains. Factors that should be considered when determining whether to have multiple domains are network complexity and server availability. In addition, on networks where dynamic conditions make database synchronization difficult, multiple domains can make NIS more reliable and easier to maintain. NIS domains are not constrained by the topology of the network. Systems in the same NIS domain are not necessarily on the same local area network. For administrative or organizational reasons, it may make sense to configure large networks as separate NIS domains such as eng and finance.
Figure 1-3 illustrates the organization of Building 1 and Building 2 local area networks into two domains, eng and finance.
The master and slave server for the eng domain both contain a database of information for the eng domain in /var/ns/domains/eng, and the master and slave server for the finance domain both contain a copy of the database for the finance domain in /var/ns/domains/finance. Notice that one system in the Building 1 local area network belongs to the finance domain and is the master server for the finance domain. (Chapter 2, “Preparing to Manage NIS”, contains detailed information on multiple NIS domains.)