JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Naming and Directory Services (NIS+)
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Name Service Switch

Part II NIS+ Setup and Configuration

2.  NIS+: An Introduction

About NIS+

What NIS+ Can Do for You

How NIS+ Differs From NIS

NIS+ Security

Solaris 1 Release and NIS-Compatibility Mode

NIS+ Administration Commands


NIS+ Setup and Configuration Preparation

NIS and NIS+

NIS+ Files and Directories

Structure of the NIS+ Namespace

NIS+ Namespace Directories

NIS+ Domains

NIS+ Servers

How NIS+ Servers Propagate Changes

NIS+ Clients and Principals

NIS+ Principal

NIS+ Client

NIS+ Cold-Start File and Directory Cache

An NIS+ Server Is Also a Client

NIS+ Naming Conventions

NIS+ Domain Names

NIS+ Directory Object Names

NIS+ Tables and Group Names

NIS+ Table Entry Names

NIS+ Host Names

NIS+ Principal Names

Accepted Name Symbols in NIS+

NIS+ Name Expansion

NIS+ NIS_PATH Environment Variable

Preparing the Existing Namespace for NIS+

Two NIS+ Configuration Methods

3.  NIS+ Setup Scripts

4.  Configuring NIS+ With Scripts

5.  Setting Up the NIS+ Root Domain

6.  Configuring NIS+ Clients

7.  Configuring NIS+ Servers

8.  Configuring an NIS+ Non-Root Domain

9.  Setting Up NIS+ Tables

Part III NIS+ Administration

10.  NIS+ Tables and Information

11.  NIS+ Security Overview

12.  Administering NIS+ Credentials

13.  Administering NIS+ Keys

14.  Administering Enhanced NIS+ Security Credentials

15.  Administering NIS+ Access Rights

16.  Administering NIS+ Passwords

17.  Administering NIS+ Groups

18.  Administering NIS+ Directories

19.  Administering NIS+ Tables

20.  NIS+ Server Use Customization

21.  NIS+ Backup and Restore

22.  Removing NIS+

23.  Information in NIS+ Tables

24.  NIS+ Troubleshooting

A.  NIS+ Error Messages

About NIS+ Error Messages

Common NIS+ Namespace Error Messages

B.  Updates to NIS+ During the Solaris 10 Release

Solaris 10 and NIS+



How NIS+ Differs From NIS

The Network Information Service Plus (NIS+) differs from the Network Information Service (NIS) in several ways. NIS+ has many new features, and the terminology it uses for concepts similar to NIS is different. Look in the Glossary if you see a term you don't recognize. The following table gives an overview of the major differences between NIS and NIS+.

Table 2-1 Differences Between NIS and NIS+

Flat domains – no hierarchy
Hierarchical – data stored in different levels in the namespace
Data stored in two column maps
Data stored in multi-column tables
Uses no authentication
Uses DES authentication
Single choice of network information source
Name service switch – lets client choose information source: NIS, NIS+, DNS, or local /etc files
Updates delayed for batch propagation
Incremental updates propagated immediately

NIS+ was designed to replace NIS. NIS addresses the administration requirements of client-server computing networks prevalent in the 1980s. At that time client-server networks did not usually have more than a few hundred clients and a few multipurpose servers. They were spread across only a few remote sites, and since users were sophisticated and trusted, they did not require security.

However, client-server networks have grown tremendously since the mid-1980s. They now range from 100-10,000 multi-vendor clients supported by 10-100 specialized servers located in sites throughout the world, and they are connected to several “untrusted” public networks. In addition, the information client-server networks store changes much more rapidly than it did during the time of NIS. The size and complexity of these networks required new, autonomous administration practices. NIS+ was designed to address these requirements.

The NIS namespace, being flat, centralizes administration. Because networks in the 1990s require scalability and decentralized administration, the NIS+ namespace was designed with hierarchical domains, like those of DNS.

For example, Figure 2-1 shows a sample company with a parent domain named doc, and two subdomains named sales and manf.

Figure 2-1 Example of NIS+ Hierarchical Domains

Diagram shows example hierarchical domain

This design enables NIS+ to be used in a range of networks, from small to very large. It also allows the NIS+ service to adapt to the growth of an organization. For example, if a corporation splits itself into two divisions, its NIS+ namespace could be divided into two domains that could be administered autonomously. Just as the Internet delegates administration of domains downward, NIS+ domains can be administered more or less independently of each other.

Although NIS+ uses a domain hierarchy similar to that of DNS, an NIS+ domain is much more than a DNS domain. A DNS domain only stores name and address information about its clients. An NIS+ domain, on the other hand, is a collection of information about the machines, users, and network services in a portion of an organization.

Although this division into domains makes administration more autonomous and growth easier to manage, it does not make information harder to access. Clients have the same access to information in other domains as they would have had under your umbrella domain. A domain can even be administered from within another domain.

The principal NIS+ server is called the master server, and the backup servers are called replicas. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables. Tables store information in NIS+ the way maps store information in NIS. The principal server stores the original tables, and the backup servers store copies.

However, NIS+ uses an updating model that is completely different from the you used by NIS. Since at the time NIS was developed, the type of information it would store changed infrequently, NIS was developed with an update model that focused on stability. Its updates are handled manually and, in large organizations, can take more than a day to propagate to all the replicas. Part of the reason for this is the need to remake and propagate an entire map every time any information in the map changes.

NIS+, however, accepts incremental updates. Changes must still be made on the master server, but once made they are automatically propagated to the replica servers and immediately made available to the entire namespace. You don't have to “make” any maps or wait for propagation.

Details about NIS+ domain structure, servers, and clients, are provided in NIS+ Domains, NIS+ Servers, and NIS+ Clients and Principals, respectively.

An NIS+ domain can be connected to the Internet through its NIS+ clients, using the name service switch (see Example 1-1). The client, if it is also a DNS client, can set up its switch configuration file to search for information in either DNS zone files or NIS maps – in addition to NIS+ tables.

NIS+ stores information in tables instead of maps or zone files. NIS+ provides 16 types of predefined, or system, tables:

Graphic shows 16 types of NIS+ system tables

Each table stores a different type of information. For instance, the hosts table stores information about machine addresses, while the passwd table stores information about users of the network.

NIS+ tables provide two major improvements over the maps used by NIS. First, you can search an NIS+ table by any column, not just the first column (sometimes referred to as the “key”). This eliminates the need for duplicate maps, such as the hosts.byname and hosts.byaddr maps used by NIS. Second, you can access and manipulate the information in NIS+ tables at three levels of granularity: the table level, the entry level, and the column level. NIS+ tables – and the information stored in them – are described in Chapter 10, NIS+ Tables and Information.

Yon can use NIS in conjunction with NIS+ under the following principles and conditions: