test

Solaris Naming Administration Guide

Chapter 1 Introduction to Name Services

This chapter provides an overview describing what namespaces and naming services are and what they do. (Other names for name services are network information services and directory services.) This chapter then briefly describes the four Solaris naming services: DNS, NIS, FNS, and NIS+.

Directions for setting up NIS+, NIS, DNS, and FNS namespaces are contained in Solaris Naming Setup and Configuration Guide. See Glossary for definitions of terms and acronyms you don't recognize.

What Is a Name Service?

Name services store information in a central place that users, workstations, and applications must have to communicate across the network such as:

Without a central name service, each workstation would have to maintain its own copy of this information. Name service information may be stored in files, maps, or database tables. Centrally locating this data makes it easier to administer large networks.

Name services are fundamental to any computing network. Among other features, a name service provides functionality that:

A network information service enables workstations to be identified by common names instead of numerical addresses. This makes communication simpler because users don't have to remember and try to enter cumbersome numerical addresses like "129.44.3.1."

For example, take a simple network of three workstations named, pine, elm, and oak. Before pine can send a message to either elm or oak, it must know their numerical network addresses. For this reason, it keeps a file, /etc/hosts or /etc/inet/ipnodes, that stores the network address of every workstation in the network, including itself.

Graphic

Likewise, in order for elm and oak to communicate with pine or with each other, they must keep similar files.

Graphic

Addresses are not the only network information that workstations need to store. They also need to store security information, mail data, information about their Ethernet interfaces, network services, groups of users allowed to use the network, services offered on the network, and so on. As networks offer more services, the list grows. As a result, each workstation may need to keep an entire set of files similar to /etc/hosts or /etc/inet/ipnodes.

As this information changes, administrators must keep it current on every workstation in the network. In a small network this is simply tedious, but on a medium or large network, the job becomes not only time-consuming but nearly unmanageable.

A network information service solves this problem. It stores network information on servers and provides it to any workstation that asks for it:

Graphic

The workstations are known as clients of the server. Whenever information about the network changes, instead of updating each client's local file, an administrator updates only the information stored by the network information service. This reduces errors, inconsistencies between clients, and the sheer size of the task.

This arrangement, of a server providing centralized services to clients across a network, is known as client-server computing.

Although the chief purpose of a network information service is to centralize information, another is to simplify network names. For example, assume your company has set up a network and connected it to the Internet. The Internet has assigned your network the network number of 129.44.0.0 and the domain name doc.com. Your company has two divisions, Sales and Manufacturing (Manf), so its network is divided into a main net and two subnets, one for each division. Each net has its own address:

Graphic

Each division could be identified by its network address, as shown above, but descriptive names made possible by name services would be preferable:

Graphic

So, instead of addressing mail or other network communications to 129.44.1.0, they could be addressed simply to doc. Instead of addressing them to 129.44.2.0 or 129.44.3.0, they could be addressed to sales.doc or manf.doc.

Names are also more flexible than physical addresses. While physical networks tend to remain stable, the organizations that use them tend to change. A network information service can act as a buffer between an organization and its physical network. This is because a network information service is mapped to the physical network, not hard-wired to it.

For example, assume that the doc.com network is supported by three servers, S1, S2, and S3, and that two of those servers, S1 and S3, support clients:

Graphic

Clients C1, C2, and C3 would obtain their network information from server S1. Clients C4, C5, and C6 would obtain it from server S3. The resulting network is summarized in Table 1-1. (The table is a generalized representation of that network but does not resemble an actual network information map.)

Table 1-1 Representation of doc.com Network

Network Address 

Network Name 

Server 

Clients 

129.44.1.0 

doc 

S1 

 

129.44.2.0 

sales.doc 

S2 

C1, C2, C3 

129.44.3.0 

manf.doc 

S3 

C4, C5, C6 

Now assume that you create a third division, Testing, which borrowed some resources from the other two divisions, but did not create a third subnet. The physical network would then no longer parallel the corporate structure:

Graphic

Traffic for the Test Division would not have its own subnet, but would instead be split between 129.44.2.0 and 129.44.3.0. However, with a network information service, the Test Division traffic could have its own dedicated network:

Graphic

Thus, when an organization changes, its network information service can simply change its mapping:

Graphic

Now clients C1 and C2 would obtain their information from server S2; C3 and C4 from server S4; and C5 and C6 from server S3.

Subsequent changes in your organization would continue to be accommodated by changes to the "soft" network information structure without reorganizing the "hard" network structure.

Solaris Name Services

The Solaris operating environment provides the following name services:

Most modern networks use two or more of these services in combination. When more than one service is used, they are coordinated by the nsswitch.conf file which is discussed in Chapter 2, The Name Service Switch.

DNS

DNS, the Domain Name System, is the name service provided by the Internet for TCP/IP networks. It was developed so that workstations on the network could be identified with common names instead of Internet addresses. DNS performs naming between hosts within your local administrative domain and across domain boundaries.

The collection of networked workstations that use DNS are referred to as the DNS namespace. The DNS namespace can be divided into a hierarchy of domains. A DNS domain is simply a group of workstations. Each domain is supported by two or more name servers: a principal server and one or more secondary servers. Each server implements DNS by running a daemon called in.named. On the client's side, DNS is implemented through the "resolver." The resolver's function is to resolve users' queries; to do that, it queries a name server, which then returns either the requested information or a referral to another server.

/etc Files

The original host-based UNIX naming system was developed for stand-alone UNIX machines and then adapted for network use. Many old UNIX operating systems and machines still use this system, but it is not well suited for large complex networks.

NIS

The Network Information Service (NIS) was developed independently of DNS and has a slightly different focus. Whereas DNS focuses on making communication simpler by using workstation names instead of numerical IP addresses, NIS focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information about workstation names and addresses, users, the network itself, and network services. This collection of network information is referred to as the NIS namespace.

NIS namespace information is stored in NIS maps. NIS maps were designed to replace UNIX /etc files, as well as other configuration files, so they store much more than names and addresses. As a result, the NIS namespace has a large set of maps (see "NIS Maps").

NIS uses a client-server arrangement similar to DNS. Replicated NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, they have backup, or slave servers. Both master and slave servers use the NIS information retrieval software and both store NIS maps. For more information on NIS Architecture, see "NIS Architecture".

See Part IVAdministering NIS for more information about NIS and how to administer it.

NIS+

The Network Information Service Plus (NIS+) is similar to NIS but with many more features. NIS+ is not an extension of NIS. It is a new software program.

The NIS+ name service is designed to conform to the shape of the organization that installs it, wrapping itself around the bulges and corners of almost any network configuration. Unlike NIS, the NIS+ name space is dynamic because updates can occur and be put into effect at any time by any authorized user.

NIS+ enables you to store information about workstation addresses, security information, mail information, Ethernet interfaces, and network services in central locations where all workstations on a network can have access to it. This configuration of network information is referred to as the NIS+ namespace.

The NIS+ namespace is hierarchical, and is similar in structure to the UNIX directory file system. The hierarchical structure allows an NIS+ namespace to be configured to conform to the logical hierarchy of an organization. The namespace's layout of information is unrelated to its physical arrangement. Thus, an NIS+ namespace can be divided into multiple domains that can be administered autonomously. Clients may have access to information in other domains in addition to their own if they have the appropriate permissions.

NIS+ uses a client-server model to store and have access to the information contained in an NIS+ namespace. Each domain is supported by a set of servers. The principal server is called the master server and the backup servers are called replicas. The network information is stored in 16 standard NIS+ tables in an internal NIS+ database. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables. Changes made to the NIS+ data on the master server are incrementally propagated automatically to the replicas.

NIS+ includes a sophisticated security system to protect the structure of the namespace and its information. It uses authentication and authorization to verify whether a client's request for information should be fulfilled. Authentication determines whether the information requester is a valid user on the network. Authorization determines whether a particular user is allowed to have or modify the information requested. See Chapter 6, Security Overview for a more detailed description of NIS+ security, and Chapter 8, Administering NIS+ Keys for information on administering NIS+ security.

FNS

FNS, the Federated Naming Service, supports the use of different autonomous naming systems in a single Solaris environment. FNS allows you to use a single, simple naming system interface for all of the different name services on your network. FNS conforms to the X/Open federated naming (XFN) specification.

FNS is not a replacement for NIS+, NIS, DNS, or /etc files. Rather, FNS is implemented on top of these services and allows you to use a set of common names with desktop applications.

See Part VAdministering FNS for more information about FNS and how to administer it.