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, workstations, 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:

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

• Although both use directories, the other objects in an NIS+ namespace are tables and groups, not files.
• The NIS+ namespace is administered only through NIS+ administration commands (listed in Table 2-4 on page 29) or graphical user interfaces (GUIs) designed for that purpose (Administration Tool); it cannot be administered with standard UNIX file system commands or GUIs.
• The names of UNIX file system components are separated by slashes (/usr/bin), but the names of NIS+ namespace objects are separated by dots (Wiz.Com.).
• The "root" of a UNIX file system is reached by stepping through directories from right to left (/usr/src/file1), while the root of the NIS+ namespace is reached by stepping from left to right (Sales.Wiz.Com.).

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:"

A namespace can have several levels of directories:

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. Any NIS+ directory that stores NIS+ groups is named groups_dir. Any directory that stores NIS+ system tables is named org_dir.

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 Engineering Division.

Domains

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

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. Take the Wizard Corporation from Chapter 2 as an example. As you recall, at one point it had a Sales Division and an Engineering division. To support those divisions, its NIS+ namespace would most likely be arranged into three major directory groups, with a structure that looked like this:

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

Part 2 of this manual describes how to configure domains.

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:

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:

This connection between the server and the directory object is established during the process of setting up a domain. Although instructions are provided in Part 2, 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 2.4-based workstation can be an NIS+ server. The software for both NIS+ servers and clients is bundled together into the Solaris 2.4 release. Therefore, any workstation that has the Solaris 2.4 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 workstation 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 workstation 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:

The master server of the root domain is called the root master server. A namespace has only one 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 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 timestamps.

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 timestamp 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 timestamp 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 timestamp:

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 timestamp from a replica that is before its earliest timestamp 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 with a "Server Busy - Try Again" message.

Clients

An NIS+ client is a workstation 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 workstation into an NIS+ table does not automatically make that workstation an NIS+ client. It simply makes information about that workstation available to all NIS+ clients. That workstation cannot request NIS+ service unless it is actually set up as an NIS+ client.

Conversely, making a workstation an NIS+ client does not enter information about that workstation into an NIS+ table. It simply allows that workstation to receive NIS+ service. If information about that workstation 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:

How does the client know which server that is? By a simple method of trial and error. Beginning with its home server, the client tries 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.

The Coldstart File and Directory Cache

When a client is initialized, it is given a coldstart file. The coldstart 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 coldstart file contains the directory object of the client's home domain.

A coldstart file is used only to initialize a client's directory cache. The directory cache, managed by an NIS+ facility called the cache manager, stores the directory objects that enable a client to send its requests to the proper servers.

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 Name Services Administration Guide.) Here is a simplified example:

Domain	Directory Name	Supporting Server	IP Address
Wiz.Com.	Wiz.Com.	RootMaster	129.44.1.1
Sales.Wiz.Com	Sales.Wiz.Com.	SalesMaster	129.44.2.1
Eng.Wiz.Com.	Eng.Wiz.Com.	EngMaster	129.44.3.1
Intl.Sales.Wiz.Com.	Intl.Sales.Wiz.Com.	IntlSalesMaster	129.44.2.11

To keep these copies up-to-date, each directory object has a time-to-live 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 Name Services Administration Guide. 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 coldstart file provides the first entry in the cache. Therefore, when the client sends its first request, it sends the request to the server specified by the coldstart file. If the request is for access to the domain supported by that server, the server answers the request.

If the request is for access to another domain (for example, Sales.Wiz.Com.), 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.

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. See Chapter 5, "Understanding the Name Service Switch," for details.

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 workstation as a server (as described in Part 2 of this manual), 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:

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

Server	Supports	Belongs to
RootMaster	Wiz.Com.	Wiz.Com.
SalesMaster	Sales.Wiz.Com.	Wiz.Com.
BigSalesMaster	Big.Sales.Wiz.Com.	Sales.Wiz.Com.
SmallSalesMaster	Small.Sales.Wiz.Com.	Sales.Wiz.Com.
EngMaster	Eng.Wiz.Com.	Wiz.Com.

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+ Name Expansion" on page 53.

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:

The fully-qualified names for all the objects in this namespace, including NIS+ principals, are summarized in Figure 3-1 on page 50.

Figure 3-1 Fully-Qualified Names of Namespace Components

For Domains A fully-qualified domain name is formed from left to right, starting with the local domain and ending with the root domain. For example:

Wiz.Inc.	Wiz.Com.
Sales.Wiz.Inc.	Sales.Wiz.Com.
Intl.Sales.Wiz.Inc.	Intl.Sales.Wiz.Com.

The first line above shows the name of the root domain. The root domain must always have at least two labels and must end in a dot. The second label can be an Internet domain name, such as Com. The second and third lines above show the names of lower-level domains.

For Directory Objects 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)

groups_dir.Eng.Wiz.Com. (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:

lowest_dir.lower_dir.low_dir.MyStrangeDomain.Com.

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+ Name Expansion" on page 53).

For Tables and Groups Fully-qualified table and group names are formed by starting with the object name and appending the directory name, followed by the Fullyqualified 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:

admin.groups_dir.Wiz.Inc....admin.groups_dir.Wiz.Com.

admin.groups_dir.Sales.Wiz.Inc. admin.groups_dir.Sales.Wiz.Com.

hosts.org_dir.Wiz.Inc.	hosts.org_dir.Wiz.Com.
hosts.org_dir.Sales.Wiz.Inc.	hosts.org_dir.Sales.Wiz.Com.

For Table Entries 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=value,column=value,...],table-name

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

[addr=129.44.2.1,name=pine],hosts.org_dir.Sales.Wiz.Com. [addr=129.44.2.2,name=elm],hosts.org_dir.Sales.Wiz.Com. [addr=129.44.2.3,name=oak],hosts.org_dir.Sales.Wiz.Com.

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 Name Services Administration Guide.

For NIS+ Principals NIS+ principal names are sometimes confused with secure RPC netnames. Both types of names are described in the security chapter in Name Services Administration Guide. 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:

olivia.Sales.Wiz.Com. ( NIS+ principal name )

unix.olivia@Sales.Wiz.Com ( 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 Symbols 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 ol'yeller, type ol"'"yeller). To include white space (as in John Smith), use double quotes within single quotes, like this:

'"John Smith"'

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

"Software.Big.Sales.Wiz.Com." domain).

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:

The NIS_PATH variable accepts a 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:

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