System Administration Guide: Naming and Directory Services (NIS+)

Chapter 2 NIS+: An Introduction

This chapter provides an overview of the Network Information Service Plus (NIS+).

Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available as of the Solaris 9 release. For more information, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and visit NIS+ End-of-Feature (EOF) Announcement FAQ.

About NIS+

NIS+ is a network naming service similar to NIS but with more features. NIS+ is not an extension of NIS. It is a new software program.

The NIS+ naming 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.

NIS+ enables you to store information about machine addresses, security information, mail information, Ethernet interfaces, and network services in central locations where all machines 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. 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.

Solaris clients use the name service switch (/etc/nsswitch.conf file) to determine from where a machine will retrieve network information. Such information may be stored in local /etc files, NIS, DNS, or NIS+. You can specify different sources for different types of information in the name service switch. A complete description of the switch software and its associated files is provided in Chapter 1, Name Service Switch.

What NIS+ Can Do for You

NIS+ has some major advantages over NIS:

Within the security system described in NIS+ Security, you can control a particular user's access to an individual entry in a particular table. This approach to security helps to keep the system secure and administration tasks to be more broadly distributed without risking damage to the entire NIS+ namespace or even to an entire table.

The NIS+ hierarchical structure allows for multiple domains in your namespace. Division into domains makes administration easier to manage. Individual domains can be administered completely independently, thereby relieving the burden on system administrators who would otherwise each be responsible for very large namespaces. As mentioned above, the security system in combination with decentralized network administration allows for a sharing of administrative work load.

Even though domains may be administered independently, all clients can be granted permission to access information across all domains in a namespace. Since a client can only see the tables in its own domain, the client can only have access to tables in other domains by explicitly addressing them.

Incremental updates mean faster updates of information in the namespace. Since domains are administered independently, changes to master server tables only have to be propagated to that master's replicas and not to the entire namespace. Once propagated, these updates are visible to the entire namespace immediately.

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:

NIS+ Security

NIS+ protects the structure of the namespace, and the information it stores, by the complementary processes of authorization and authentication.

If the principal possesses an authentic (valid) credential, and if the principal's request is one that the principal is authorized to perform, NIS+ carries out the request. If either the credential is missing or invalid, or the request is not one the principal is authorized to perform, NIS+ denies the request for access. An introductory description of the entire NIS+ security system is provided in Chapter 11, NIS+ Security Overview.

Solaris 1 Release and NIS-Compatibility Mode

NIS+ can be used by machines running NIS with Solaris 1 or Solaris 2 software. In other words, machines within an NIS+ domain can have their nsswitch.conf files set to nis rather than nisplus. To access NIS+ service on machines running NIS, you must run the NIS+ servers in NIS-compatibility mode.

NIS-compatibility mode enables an NIS+ server running Solaris software to answer requests from NIS clients while continuing to answer requests from NIS+ clients. NIS+ does this by providing two service interfaces. One responds to NIS+ client requests, while the other responds to NIS client requests.

This mode does not require any additional setup or changes to NIS clients. In fact, NIS clients are not even aware that the server that is responding isn't an NIS server – except that an NIS+ server running in NIS-compatibility mode does not support the ypupdate and ypxfr protocols and thus it cannot be used as a replica or master NIS server. For more information on NIS-compatibility mode, see Setting Up NIS+ Servers.

Two more differences need to be pointed out. First, instructions for setting up a server in NIS-compatibility mode are slightly different than those used to set up a standard NIS+ server. Second, NIS-compatibility mode has security implications for tables in the NIS+ namespace. Since the NIS client software does not have the capability to provide the credentials that NIS+ servers expect from NIS+ clients, all their requests end up classified as unauthenticated. Therefore, to allow NIS clients to access information in NIS+ tables, those tables must provide access rights to unauthenticated requests. This is handled automatically by the utilities used to set up a server in NIS-compatibility mode, as described in Part 2. However, to understand more about the authentication process and NIS-compatibility mode, see Chapter 11, NIS+ Security Overview.

If you wish to set the NIS-compatibility mode option to persist across reboots, you must modify the /lib/svc/method/nisplus file, as shown in NIS+ and the Service Management Facility.

NIS+ Administration Commands

NIS+ provides a full set of commands for administering a namespace. The table below, summarizes them.

Note –

Most of the command line administrative tasks associated with the NIS+ service are managed by the Service Management Facility (SMF). For details about using SMF with NIS+, see NIS+ and the Service Management Facility. For an overview of SMF, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Table 2–2 NIS+ Namespace Administration Commands




Creates credentials for NIS+ principals and stores them in the cred table. 


Adds information from /etc files or NIS maps into NIS+ tables.


Optionally configure Diffie-Hellman key length. 


Backs up NIS directories. 


Starts the NIS+ cache manager on an NIS+ client. 


Displays the contents of NIS+ tables. 


Forces service to checkpoint data that has been entered in the log but not checkpointed to disk. 


Changes the group owner of an NIS+ object. 


Changes an object's access rights. 


Changes the owner of an NIS+ object. 


Changes an NIS+ object's time-to-live value. 


Initializes NIS+ principals. 


Lists an NIS+ object's default values: domain name, group name, machine name, NIS+ principal name, access rights, directory search path, and time-to-live. 


Searches for entries in an NIS+ table. 


Creates or destroys an NIS+ group, or displays a list of its members. Also adds members to a group, removes them, or tests them for membership in the group. 


Initializes an NIS+ client or server. 


Creates a symbolic link between two NIS+ tables. 


Displays the contents of NIS+ transaction log. 


Lists the contents of an NIS+ directory. 


Searches for entries in an NIS+ table. 


Creates an NIS+ directory and specifies its master and replica servers. 


Changes password information stored in the NIS+ passwd table. (Rather than using nispasswd, you should use passwd or passwd -r nisplus.)


Forces a replica to update its data from the master server. 


Populates the NIS+ tables in a new NIS+ domain. 


Specifies the order in which clients are to seek NIS+ information from NIS+ servers. 


Restores previously backed up NIS+ directories and can also be used to quickly bring online new NIS+ replica servers. 


Removes NIS+ objects (except directories) from the namespace. 


Removes NIS+ directories and replicas from the namespace. 


Shell script used to set up a new NIS+ server. 


Creates org_dir and groups_dir directories and a complete set of (unpopulated) NIS+ tables for an NIS+ domain.


Lists the contents of the NIS+ shared cache maintained by the NIS+ cache manager. 


Reports statistics and other information about an NIS+ server. 


Creates or deletes NIS+ tables, and adds, modifies or deletes entries in an NIS+ table. 


Reports the current state of the NIS+ namespace. 


Updates the public keys stored in an NIS+ object. 


Changes password information stored in the NIS+ Passwd table. Also administers password aging and other password-related parameters. 


The NIS+ application programmer's interface (API) is a group of functions that can be called by an application to access and modify NIS+ objects. The NIS+ API has 54 functions that fall into nine categories:

NIS+ Setup and Configuration Preparation

Before configuring your NIS+ namespace, you must:

NIS and NIS+

Both NIS and NIS+ perform some of the same tasks. NIS+, however, allows for hierarchical domains, namespace security, and other features that NIS does not provide. For a more detailed comparison between NIS and NIS+, see How NIS+ Differs From NIS.

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

NIS+ Files and Directories

Table 2–3 lists the UNIX directories used to store NIS+ files.

Table 2–3 Where NIS+ Files Are Stored





All machines 

NIS+ user commands 


All machines 

NIS+ administrator commands 


All machines 

NIS+ daemons 


All machines 

NIS+ shared libraries 


NIS+ server 

Data files used by NIS+ server 


NIS+ server 

NIS+ working files 


NIS+ client machines 

Machine-specific data files used by NIS+ 

Caution – Caution –

Do not rename the /var/nis or /var/nis/data directories or any of the files in these directories that were created by nisinit or any of the other NIS+ setup procedures. In the Solaris 2 release, the /var/nis directory contained two files named hostname.dict and hostname.log. It also contained a subdirectory named /var/nis/hostname.

Starting with the Solaris 2.5 release, the two files were named trans.log and data.dict, and the subdirectory was named /var/nis/data. The content of the files was also changed, so these files are not backward compatible with earlier releases. Thus, if you rename either the directories or the files to match the Solaris 2.4 patterns, the files will not work with either the Solaris 2.4 release or the current version of the rpc.nisd daemon. Therefore, do not rename either the directories or the files.

Note –

With the Solaris platform, the NIS+ data dictionary (/var/nis/data.dict) is now machine independent. This allows you to easily change the name of an NIS+ server. You can also now use the NIS+ backup and restore capabilities to transfer NIS+ data from one server to another. See Chapter 21, NIS+ Backup and Restore.

Structure of the NIS+ Namespace

The NIS+ namespace is the arrangement of information stored by NIS+. The namespace can be arranged in a variety of ways to suit the needs of an organization. For example, if an organization had three divisions, its NIS+ namespace would likely be divided into three parts, one for each division. Each part would store information about the users, machines, and network services in its division, but the parts could easily communicate with each other. Such an arrangement would make information easier for the users to access and for the administrators to maintain.

Although the arrangement of an NIS+ namespace can vary from site to site, all sites use the same structural components: directories, tables, and groups. These components are called NIS+ objects. NIS+ objects can be arranged into a hierarchy that resembles a UNIX file system. For example, the illustration below shows, on the left, a namespace that consists of three directory objects, three group objects, and three table objects; on the right it shows a UNIX file system that consists of three directories and three files:

Diagram compares UNIX file system with NIS+ namespace

Although an NIS+ namespace resembles a UNIX file system, it has five important differences:

NIS+ Namespace Directories

Directory objects are the skeleton of the namespace. When arranged into a tree-like structure, they divide the namespace into separate parts. You may want to visualize a directory hierarchy as an upside-down tree, with the root of the tree at the top and the leaves toward the bottom. The topmost directory in a namespace is the root directory. If a namespace is flat, it has only one directory, but that directory is nevertheless the root directory. The directory objects beneath the root directory are simply called “directories”:

Diagram shows multiple levels of directories under one

A namespace can have several levels of directories:

Diagram shows directory structure using NIS+

When identifying the relation of one directory to another, the directory beneath is called the child directory and the directory above is called the parent directory.

Whereas UNIX directories are designed to hold UNIX files, NIS+ directories are designed to hold NIS+ objects: other directories, tables and groups.

Each NIS+ domain-level directory contains the following sub-directories:

Technically, you can arrange directories, tables, and groups into any structure that you like. However, NIS+ directories, tables, and groups in a namespace are normally arranged into configurations called domains. Domains are designed to support separate portions of the namespace. For instance, one domain may support the Sales Division of a company, while another may support the Manufacturing Division.

NIS+ Domains

An NIS+ domain consists of a directory object, its org_dir directory, its groups_dir directory, and a set of NIS+ tables.

Diagram shows NIS+ directory structure with 3 major directory

NIS+ domains are not tangible components of the namespace. They are simply a convenient way to refer to sections of the namespace that are used to support real-world organizations.

For example, suppose the DOC company has Sales and Manufacturing divisions. To support those divisions, its NIS+ namespace would most likely be arranged into three major directory groups, with a structure that looked like the following diagram.

Figure 2–2 Example NIS+ Directory Structure

Diagram shows 3 NIS+ domains

Instead of referring to such a structure as three directories, six subdirectories, and several additional objects, referring to it as three NIS+ domains is more convenient.

Figure 2–3 Example NIS+ Domains

Diagram shows servers serving NIS+ domains

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

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.

NIS+ Clients and Principals

NIS+ principals are the entities (clients) that submit requests for NIS+ services.

NIS+ Principal

An NIS+ principal may be someone who is logged in to a client machine as a regular user or someone who is logged in as superuser (root). In the first instance, the request actually comes from the client user; in the second instance, the request comes from the client machine. Therefore, an NIS+ principal can be a client user or a client machine.

(An NIS+ principal can also be the entity that supplies an NIS+ service from an NIS+ server. Since all NIS+ servers are also NIS+ clients, much of this discussion also applies to servers.)

NIS+ Client

An NIS+ client is a machine that has been set up to receive NIS+ service. Setting up an NIS+ client consists of establishing security credentials, making it a member of the proper NIS+ groups, verifying its home domain, verifying its switch configuration file and, finally, running the NIS+ initialization script. (Complete instructions are provided in Part 2.)

An NIS+ client can access any part of the namespace, subject to security constraints. In other words, if it has been authenticated and has been granted the proper permissions, it can access information or objects in any domain in the namespace.

Although a client can access the entire namespace, a client belongs to only one domain, which is referred to as its home domain. A client's home domain is usually specified during installation, but it can be changed or specified later. All the information about a client, such as its IP address and its credentials, is stored in the NIS+ tables of its home domain.

There is a subtle difference between being an NIS+ client and being listed in an NIS+ table. Entering information about a machine into an NIS+ table does not automatically make that machine an NIS+ client. It simply makes information about that machine available to all NIS+ clients. That machine cannot request NIS+ service unless it is actually set up as an NIS+ client.

Conversely, making a machine an NIS+ client does not enter information about that machine into an NIS+ table. It simply allows that machine to receive NIS+ service. If information about that machine is not explicitly entered into the NIS+ tables by an administrator, other NIS+ clients will not be able to get it.

When a client requests access to the namespace, it is actually requesting access to a particular domain in the namespace. Therefore, it sends its request to the server that supports the domain it is trying to access. Here is a simplified representation:

Illustration shows clients accessing server in
domainIllustration shows clients accessing server

How does the client know which server that is? By trial and error. Beginning with its home server, the client tries first one server, then another, until it finds the right one. When a server cannot answer the client's request, it sends the client information to help locate the right server. Over time, the client builds up its own cache of information and becomes more efficient at locating the right server. The next section describes this process.

NIS+ Cold-Start File and Directory Cache

When a client is initialized, it is given a cold-start file. The cold-start file gives a client a copy of a directory object that it can use as a starting point for contacting servers in the namespace. The directory object contains the address, public keys, and other information about the master and replica servers that support the directory. Normally, the cold-start file contains the directory object of the client's home domain.

A cold-start file is used only to initialize a client's local directory cache. The directory cache is managed by an NIS+ facility called the cache manager. The cache manager stores the directory objects that enable a client to send its requests to the proper servers. The information obtained from the client's cold-start file is downloaded into a file named NIS_SHARED_DIRCACHE in /var/nis.

Illustration shows cold-start file initializing client's
directory cache

By storing a copy of the namespace's directory objects in its directory cache, a client can know which servers support which domains. (To view the contents of a client's cache, use the nisshowcache command, described in nisshowcache Command.) Here is a simplified example:

Domain Name and Directory Name are the same 

Supporting Server 

IP Address





To keep these copies up-to-date, each directory object has a time-to-live (TTL) field. Its default value is 12 hours. If a client looks in its directory cache for a directory object and finds that it has not been updated in the last 12 hours, the cache manager obtains a new copy of the object. You can change a directory object's time-to-live value with the nischttl command, as described in nischttl Command. However, keep in mind that the longer the time-to-live, the higher the likelihood that the copy of the object will be out of date; and the shorter the time to live, the greater the network traffic and server load.

How does the directory cache accumulate these directory objects? As mentioned above, the cold-start file provides the first entry in the cache. Therefore, when the client sends its first request, the request goes to the server specified by the cold-start file. If the request is for access to the domain supported by that server, the server answers the request.

Illustration shows client accessing server specified
by cold-start file

If the request is for access to another domain (for example,, the server tries to help the client locate the proper server. If the server has an entry for that domain in its own directory cache, it sends a copy of the domain's directory object to the client. The client loads that information into its directory cache for future reference and sends its request to that server.

Illustration shows server sending copy of directory object
to its own domainIllustration shows server sending copy of directory object
to its own domain

In the unlikely event that the server does not have a copy of the directory object the client is trying to access, it sends the client a copy of the directory object for its own home domain, which lists the address of the server's parent. The client repeats the process with the parent server, and keeps trying until it finds the proper server or until it has tried all the servers in the namespace. What the client does after trying all the servers in the domain is determined by the instructions in its name service switch configuration file.

Over time, the client accumulates in its cache a copy of all the directory objects in the namespace and thus the IP addresses of the servers that support them. When it needs to send a request for access to another domain, it can usually find the name of its server in its directory cache and send the request directly to that server.

An NIS+ Server Is Also a Client

An NIS+ server is also an NIS+ client. In fact, before you can set up a machine as a server, you must initialize it as a client. The only exception is the root master server, which has its own unique setup process.

This means that in addition to supporting a domain, a server also belongs to a domain. In other words, by virtue of being a client, a server has a home domain. Its host information is stored in the Hosts table of its home domain, and its DES credentials are stored in the cred table of its home domain. Like other clients, it sends its requests for service to the servers listed in its directory cache.

An important point to remember is that – except for the root domain – a server's home domain is the parent of the domain the server supports:

In other words, a server supports clients in one domain, but is a client of another domain. A server cannot be a client of a domain that it supports, with the exception of the root domain. Because they have no parent domain, the servers that support the root domain belong to the root domain itself.

For example, consider the following namespace:

Diagram shows servers as client and server in different

The chart lists which domain each server supports and which domain it belongs to:



Belongs to 





NIS+ Naming Conventions

Objects in an NIS+ namespace can be identified with two types of names: partially-qualified and fully qualified. A partially qualified name, also called a simple name, is simply the name of the object or any portion of the fully qualified name. If during any administration operation you type the partially qualified name of an object or principal, NIS+ will attempt to expand the name into its fully qualified version. For details, see NIS+ Naming Conventions.

A fully qualified name is the complete name of the object, including all the information necessary to locate it in the namespace, such as its parent directory, if it has one, and its complete domain name, including a trailing dot.

This varies among different types of objects, so the conventions for each type, as well as for NIS+ principals, is described separately. This namespace will be used as an example:

Diagram shows example namespace

The fully qualified names for all the objects in this namespace, including NIS+ principals, are summarized below.

Figure 2–4 Fully-Qualified Names of NIS+ Namespace Components

Diagram shows FQDNs for the namespace

NIS+ Domain Names

A fully qualified NIS+ domain name is formed from left to right, starting with the local domain and ending with the root domain: (root domain) (subdomain) (a third level subdomain)

The first line above shows the name of the root domain. The root domain must always have at least two elements (labels) and must end in a dot. The last (right most) label may be anything you want, but in order to maintain Internet compatibility, the last element must be either an Internet organizational name (as shown below), or a two or three character geographic identifier such as .jp for Japan.

Table 2–4 Internet Organizational Domains




Commercial organizations 


Educational institutions 


Government institutions 


Military groups 


Major network support centers 


Nonprofit organizations and others 


International organizations 

The second and third lines above show the names of lower-level domains.

NIS+ Directory Object Names

A directory's simple name is simply the name of the directory object. Its fully qualified name consists of its simple name plus the fully qualified name of its domain (which always includes a trailing dot):

groups_dir (simple name) (fully qualified name)

If you set up an unusual hierarchy in which several layers of directories do not form a domain, be sure to include the names of the intermediate directories. For example:

The simple name is normally used from within the same domain, and the fully qualified name is normally used from a remote domain. However, by specifying search paths in a domain's NIS_PATH environment variable, you can use the simple name from remote domains (see NIS+ NIS_PATH Environment Variable).

NIS+ Tables and Group Names

Fully qualified table and group names are formed by starting with the object name and appending the directory name, followed by the fully qualified domain name. Remember that all system table objects are stored in an org_dir directory and all group objects are stored in a groups_dir directory. (If you create your own NIS+ tables, you can store them anywhere you like.) Here are some examples of group and table names:

NIS+ Table Entry Names

To identify an entry in an NIS+ table, you need to identify the table object and the entry within it. This type of name is called an indexed name. It has the following syntax:


Column is the name of the table column. Value is the actual value of that column. Tablename is the fully qualified name of the table object. Here are a few examples of entries in the hosts table:


You can use as few column-value pairs inside the brackets as required to uniquely identify the table entry.

Some NIS+ administrative commands accept variations on this syntax. For details, see the nistbladm, nismatch, and nisgrep commands in Part 2.

NIS+ Host Names

Host names may contain up to 24 characters. Letters, numbers, the dash (-) and underscore (_) characters are allowed in host names. Host names are not case sensitive (that is, upper and lower case letters are treated as the same). The first character of a host name must be a letter of the alphabet. Blank spaces are not permitted in host names.

Note –

Dots (.) are not permitted in host names. For example, a host name such as doc.2 is not permitted. Dots are not allowed in host names even if they are enclosed in quotes. For example, `doc.2' is not permitted. Dots are only used as part of a fully qualified host name to identify the domain components. For example, is a correct fully qualified host name.

Domains and hosts should not have the same name. For example, if you have a sales domain you should not have a machine named sales. Similarly, if you have a machine named home, you do not want to create a domain named home. This caution also applies to subdomains. For example, if you have a machine named west you don't want to create a subdomain.

NIS+ Principal Names

NIS+ principal names are sometimes confused with Secure RPC netnames. However, one difference is worth pointing out now because it can cause confusion: NIS+ principal names always end in a dot and Secure RPC netnames never do. The following list provides examples.

NIS+ principal name

Secure RPC netname

Also, even though credentials for principals are stored in a cred table, neither the name of the cred table nor the name of the org_dir directory is included in the principal name.

Accepted Name Symbols in NIS+

You can form namespace names from any printable character in the ISO Latin 1 set. However, the names cannot start with these characters: @ < > + [ ] - / = . , : ;

To use a string, enclose it in double quotes. To use a quote sign in the name, quote the sign too (for example, to use o'henry, type o”'”henry). To include white space (as in John Smith), use double quotes within single quotes, like this:

`”John Smith”`

See NIS+ Host Names for restrictions that apply to host names.

NIS+ Name Expansion

Entering fully qualified names with your NIS+ commands can quickly become tedious. To ease the task, NIS+ provides a name-expansion facility. When you enter a partially qualified name, NIS+ attempts to find the object by looking for it under different directories. It starts by looking in the default domain. This is the home domain of the client from which you type the command. If it does not find the object in the default domain, NIS+ searches through each of the default domain's parent directories in ascending order until it finds the object. It stops after reaching a name with only two labels. Here are some examples (assume you are logged onto a client that belongs to the domain).

Diagram shows examples of name extentions

NIS+ NIS_PATH Environment Variable

You can change or augment the list of directories NIS+ searches through by changing the value of the environment variable NIS_PATH. NIS_PATH accepts a list of directory names separated by colons:

setenv NIS_PATH directory1: directory2: directory3 ...


NIS_PATH=directory1: directory2: directory3 ...;export NIS_PATH

NIS+ searches through these directories from left to right. For example:

Diagram shows expansion of mydir and hosts.org_dir into
respective FQDNs

Like $PATH and $MANPATH, the NIS_PATH variable accepts the special symbol, $. You can append the $ symbol to a directory name or add it by itself. If you append it to a directory name, NIS+ appends the default directory to that name. For example:

Diagram shows NIS_PATH for sales.doc, manf.doc and

If you use the $ sign by itself (for example, org_dir.$:$), NIS+ performs the standard name expansion described earlier: it starts looking in the default directory and proceeds through the parent directories. In other words, the default value of NIS_PATH is $.

Note –

Keep in mind that additions and changes to your NIS_PATH may increase the number of lookups that NIS+ has to perform and thus slow down performance.

Preparing the Existing Namespace for NIS+

If an NIS domain already exists at your site, you can use the same flat domain structure for your NIS+ namespace. (You can change it later to a hierarchical structure.) Read Chapter 4, Configuring NIS+ With Scripts before you start your transition from NIS to NIS+ for important planning and preparation information. The NIS+ scripts enable you to start NIS+ with data from NIS maps. Chapter 4, Configuring NIS+ With Scripts shows you how to use the NIS+ scripts to create an NIS+ namespace from either system files or NIS maps.

In order for the scripts to run smoothly, however, you must prepare your existing namespace (if you have one) for conversion to NIS+. These preparations are described fully in Chapter 4, Configuring NIS+ With Scripts.

For reference, key preparations are summarized below:

Caution – Caution –

In the Solaris 2 release, the /var/nis directory contained two files named hostname.dict and hostname.log. It also contained a subdirectory named /var/nis/hostname.

When you install NIS+ for the Solaris 2.5 release, the two files are named trans.log and data.dict, and the subdirectory is named /var/nis/data. In the Solaris 2.5 release, the content of the files has also been changed, so these files are not backward compatible with the files in earlier releases. Thus, if you rename either the directories or the files to match the Solaris 2.4 patterns, the files will not work with either the Solaris 2.4 or the Solaris 2.5 version of the rpc.nisd daemon. Therefore, do not rename either the directories or the files.

Two NIS+ Configuration Methods

The rest of this part of the guide describes two different methods of configuring an NIS+ namespace:

Note –

If you use the NIS+ command set, you must also make sure that each machine using NIS+ for its naming service has the correct nsswitch.conf file in its /etc directory as described in Chapter 1, Name Service Switch. If you use the NIS+ configuration scripts on a given machine, this step is performed for you.

See Chapter 22, Removing NIS+ for information on how to remove an NIS+ directory or domain, an NIS+ server, or the NIS+ namespace.