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+



NIS+ Servers

Every NIS+ domain is supported by a set of NIS+ servers. The servers store the domain's directories, groups, and tables, and answer requests for access from users, administrators, and applications. Each domain is supported by only one set of servers. However, a single set of servers can support more than one domain.

Illustration shows breakdown of NIS+ domain served by servers

Remember that a domain is not an object but only refers to a collection of objects. Therefore, a server that supports a domain is not actually associated with the domain, but with the domain's main directory:

Illustration shows master and replica servers

This connection between the server and the directory object is established during the process of setting up a domain. One thing is important to mention now: when that connection is established, the directory object stores the name and IP address of its server. This information is used by clients to send requests for service, as described later in this section.

Any Solaris platform based machine can be an NIS+ server. The software for both NIS+ servers and clients is bundled together into the release. Therefore, any machine that has the Solaris Release 2 software installed can become a server or a client, or both. What distinguishes a client from a server is the role it is playing. If a machine is providing NIS+ service, it is acting as an NIS+ server. If it is requesting NIS+ service, it is acting as an NIS+ client.

Because of the need to service many client requests, a machine that will act as an NIS+ server might be configured with more computing power and more memory than the average client. And, because it needs to store NIS+ data, it might also have a larger disk. However, other than hardware to improve its performance, a server is not inherently different from an NIS+ client.

Two types of servers support an NIS+ domain: a master and its replicas:

Diagram shows master and replica servers

The master server of the root domain is called the root master server. A namespace has only you root master server. The master servers of other domains are simply called master servers. Likewise, there are root replica servers and regular replica servers.

Both master and replica servers store NIS+ tables and answer client requests. The master, however, stores the master copy of a domain's tables. The replicas store only duplicates. The administrator loads information into the tables in the master server, and the master server propagates it to the replica servers.

This arrangement has two benefits. First, it avoids conflicts between tables because only one set of master tables exists; the tables stored by the replicas are only copies of the masters. Second, it makes the NIS+ service much more available. If either the master or a replica is down, another server can act as a backup and handle the requests for service.

How NIS+ Servers Propagate Changes

An NIS+ master server implements updates to its objects immediately; however, it tries to “batch” several updates together before it propagates them to its replicas. When a master server receives an update to an object, whether a directory, group, link, or table, it waits about two minutes for any other updates that may arrive. Once it is finished waiting, it stores the updates in two locations: on disk and in a transaction log (it has already stored the updates in memory).

The transaction log is used by a master server to store changes to the namespace until they can be propagated to replicas. A transaction log has two primary components: updates and time stamps.

Diagram shows transaction log stucture under master and replica servers connecting

An update is an actual copy of a changed object. For instance, if a directory has been changed, the update is a complete copy of the directory object. If a table entry has been changed, the update is a copy of the actual table entry. The time stamp indicates the time at which an update was made by the master server.

After recording the change in the transaction log, the master sends a message to its replicas, telling them that it has updates to send them. Each replica replies with the time stamp of the last update it received from the master. The master then sends each replica the updates it has recorded in the log since the replica's time stamp:

Diagram shows clients accessing objects in namespace

When the master server updates all its replicas, it clears the transaction log. In some cases, such as when a new replica is added to a domain, the master receives a time stamp from a replica that is before its earliest time stamp still recorded in the transaction log. If that happens, the master server performs a full resynchronization, or resync. A resync downloads all the objects and information stored in the master down to the replica. During a resync, both the master and replica are busy. The replica cannot answer requests for information; the master can answer read requests but cannot accept update requests. Both respond to requests with a Server Busy - Try Again or similar message.