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 Chapter 26, Transitioning from NIS to NIS+.
you can use NIS in conjunction with NIS+ under the following principles and conditions:
Servers within a domain. While you can have both NIS and NIS+ servers operating in the same domain, doing so is not recommended for long periods. As a general rule, using both services in the same domain should be limited to a relatively short transition period from NIS to NIS+. If some clients need NIS service, you can run NIS+ in NIS compatibility mode as explained in Chapter 26, Transitioning from NIS to NIS+.
Subdomains. If the master server of your root domain is running NIS+, you can set up subdomains whose servers are all running NIS. (If your root domain master server is running NIS, you cannot have subdomains.) This might be useful in situations where you are moving from NIS to NIS+. For example, suppose your enterprise had separate, multiple NIS domains, possibly at different sites. Now you need to link them all together into a single, hierarchical multi-domain namespace under NIS+. By first setting up the root domain under NIS+, you can then designate the legacy NIS domains as sub-domains that continue to run NIS until it is convenient to switch them over to NIS+.
Machines within a domain.
If a domain's servers are running NIS+, individual machines within that domain can be set up to use either NIS+, NIS, or /etc files for their name service information. In order for an NIS+ server to supply the needs of an NIS client, the NIS+ server must be running in NIS-Compatibility mode as described in Chapter 26, Transitioning from NIS to NIS+.
If a domain's servers are running NIS, individual machines within that domain can be set up to use either NIS or /etc files for name services (they cannot use NIS+).
NIS+ Files and Directories
Table 2-3 lists the UNIX™ directories used to store NIS+ files.
Table 2-3 Where NIS+ Files are Stored
Directory | Where | Contains |
|---|---|---|
/usr/bin | All machines | NIS+ user commands |
/usr/lib/nis | All machines | NIS+ administrator commands |
/usr/sbin | All machines | NIS+ daemons |
/usr/lib/ | All machines | NIS+ shared libraries |
/var/nis/data | NIS+ server | Data files used by NIS+ server |
/var/nis | NIS+ server | NIS+ working files |
/var/nis | NIS+ client machines | Machine-specific data files used by NIS+ |
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 Solaris Release 2.4 and earlier versions, the /var/nis directory contained two files named hostname.dict and hostname.log.
It also contained a subdirectory named /var/nis/hostname. Starting with Solaris Release 2.5, 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 and they are not backward
compatible with Solaris Release 2.4 or earlier. Thus, if you rename either
the directories or the files to match the Solaris Release 2.4 patterns, the
files will not work with either the Solaris 2.4 Release
or the current version of rpc.nisd. Therefore, you should
not rename either the directories or the files.
Note - With the Solaris operating environment, 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:
Although an NIS+ namespace resembles a UNIX file system, it has five 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 or graphical user interfaces designed for that purpose, such as the Solstice AdminSuite tools; 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 (doc.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.doc.com.).
Because NIS+ object names are structured from left to right, a fully qualified name always ends in a dot. Any NIS+ object ending in a dot is assumed to be a fully qualified name. NIS+ object names that do not end in a dot are assumed to be relative names.
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. 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.
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.
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 this:
Figure 2-2 Example NIS+ Directory Structure
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
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. 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 operating environment 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:
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.