This chapter contains a general description of the Silicon Graphics 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. Typically, the default lookup order is NIS first, DNS (BIND) second, then the appropriate local files.
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 or User Datagram Protocol 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 comprised 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 (dbm(3B)). Since data in dbm format is faster to find than ASCII data, using dbm 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; values are attributes of the key returned from the query. For example, in the map called hosts.byname, the keys are the names of individual systems, and the values are their Internet addresses. A query on the system triangle might return the value 192.0.2.5.
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/yp. 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/yp/eng.
NIS domains can be organized to coincide with domains of the Internet, a registered organization of wide area networks originally funded by DARPA (U.S. Defense Advanced Research Projects Agency). In the Internet naming hierarchy, a domain name is comprised of a stream of names separated by dots. For example, eng.widgets.com is an Internet domain. This could also be the name of the NIS domain.
Some administrators name their NIS domains with simple names and the Internet domain names separated with dots, for example, eng for the NIS domain name and eng.widgets.com for the Internet domain name. Using this naming scheme, the two domains can be easily distinguished. Other administrators prefer to have the NIS and Internet domain names coincide. This is strictly a matter of choice; there is no explicit relationship between NIS and Internet domains. However, to avoid confusion, choosing one of these two naming schemes is recommended. (See the IRIX Advanced Site and Server Administration Guide for details on Internet domains.)
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/yp/eng, and the master and slave server for the finance domain both contain a copy of the database for the finance domain in /var/yp/finance. Notice that one system n 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.)