Chapter 1. Understanding NIS
Prev |  | Next

## Chapter 1. Understanding NIS

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:

- “ About NIS”

- “ NIS Portability”

- “Client-Server Model”

- “Server Hierarchy”

- “NIS Maps”

- “NIS Domains”

## About NIS

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 Portability

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.

Figure 1-1. NIS Software Implementation

## Client-Server 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.

## Server Hierarchy

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.

## NIS Maps

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.

## NIS Domains

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`.

Figure 1-2. Basic NIS Domain

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.

### NIS Domains and Server Directories

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`.

### NIS and Internet Domains

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.

### Multiple NIS 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.

Figure 1-3. Multiple NIS Domains

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.)

Prev | Table of Contents | Next
About This Guide |  | Chapter 2. Preparing to Manage NIS