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

Part II NIS+ Setup and Configuration

This part describes the setup and configuration of the NIS+ naming service in the Solaris operating environment.

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 in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


About NIS+

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

The NIS+ name 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, The 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+

NIS 

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 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 Domains, 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.x Releases and NIS-Compatibility Mode

NIS+ can be used by machines running NIS with Solaris 1x or 2x Release 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 operating environment 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 Chapter 26, Transitioning from NIS to NIS+.

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 26, Transitioning from NIS to NIS+.

NIS+ Administration Commands

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

Table 2–2 NIS+ Namespace Administration Commands

Command 

Description 

nisaddcred

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

nisaddent

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

nisauthconf

Optionally configure Diffie-Hellman key length. 

nisbackup

Backs up NIS directories. 

nis_cachemgr

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

niscat

Displays the contents of NIS+ tables. 

nis_checkpoint

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

nischgrp

Changes the group owner of an NIS+ object. 

nischmod

Changes an object's access rights. 

nischown

Changes the owner of an NIS+ object. 

nischttl

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

nisclient

Initializes NIS+ principals. 

nisdefaults

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. 

nisgrep

Searches for entries in an NIS+ table. 

nisgrpadm

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. 

nisinit

Initializes an NIS+ client or server. 

nisln

Creates a symbolic link between two NIS+ tables. 

nislog

Displays the contents of NIS+ transaction log. 

nisls

Lists the contents of an NIS+ directory. 

nismatch

Searches for entries in an NIS+ table. 

nismkdir

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

nispasswd

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

nis_ping

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

nispopulate

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

nisprefadm

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

nisrestore

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

nisrm

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

nisrmdir

Removes NIS+ directories and replicas from the namespace. 

nisserver

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

nissetup

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

nisshowcache

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

nisstat

Reports statistics and other information about an NIS+ server. 

nistbladm

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

nistest

Reports the current state of the NIS+ namespace. 

nisupdkeys

Updates the public keys stored in an NIS+ object. 

passwd

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

NIS+ API

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:

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 Chapter 26, Transitioning from NIS to NIS+.

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

NIS+ Files and Directories

Table 2–3 lists the UNIXTM 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 – 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:

Diagram compares UNIX file system with NIS+ namespace

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

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 root

A namespace can have several levels of directories:

Diagram shows directory structure using FNS with 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:

Graphic shows NIS+ groups, tables and org_dir within NIS+ domain

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.

Diagram shows NIS+ directory structure with 3 major directory groups

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

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

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

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 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 doc.com 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.

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.)

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 doc.com domain Illustration shows clients accessing sales.doc.com 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.

The 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 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.

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 The nisshowcache Command.) Here is a simplified example:

Domain Name and Directory Name are the same 

Supporting Server 

IP Address 

doc.com.

rootmaster 

123.45.6.77 

sales.doc.com.

salesmaster 

123.45.6.66 

manf.doc.com.

manfmaster 

123.45.6.37 

int.sales.doc.com.

Intlsalesmaster 

111.22.3.7 

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 The 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, sales.doc.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.

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 domains

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

Server 

Supports 

Belongs to 

RootMaster 

doc.com. 

doc.com. 

SalesMaster 

sales.doc.com. 

doc.com. 

IntlSalesMaster 

intl.sales.doc.com. 

sales.doc.com. 

ManfMaster 

manf.doc.com. 

doc.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 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 docs.com 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 Namespace Components

Diagram shows FQDNs for the docs.com 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:

doc.com. (root domain)

sales.doc.com. (subdomain)

intl.sales.doc.com. (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

Domain 

Purpose 

com

Commercial organizations 

edu

Educational institutions 

gov

Government institutions 

mil

Military groups 

net

Major network support centers 

org

Nonprofit organizations and others 

int

International organizations 

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

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)

groups_dir.manf.doc.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.mydomain.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_PATH Environment Variable).

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:


admin.groups_dir.doc.com.	
admin.groups_dir.doc.com. 
admin.groups_dir.sales.doc.com. 
admin.groups_dir.sales.doc.com. 
hosts.org_dir.doc.com.	
hosts.org_dir.doc.com. 
hosts.org_dir.sales.doc.com.	
hosts.org_dir.sales.doc.com.

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=value,column=value,...],tablename

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:


[addr=129.44.2.1,name=pine],hosts.org_dir.sales.doc.com. 
[addr=129.44.2.2,name=elm],hosts.org_dir.sales.doc.com. 
[addr=129.44.2.3,name=oak],hosts.org_dir.sales.doc.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 Part 2.

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 myco.2 is not permitted. Dots are not allowed in host names even if they are enclosed in quotes. For example, `myco.2' is not permitted. Dots are only used as part of a fully qualified host name to identify the domain components. For example, myco-2.sales.doc.com. 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 applies to subdomains, for example if you have a machine named west you don't want to create a sales.west.myco.com 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:

Table 2–5 NIS+ Principal Names

olivia.sales.doc.com.

NIS+ principal name 

unix.olivia@sales.doc.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 Name 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 o'henry, type o”'”henry). To include white space (as in John Smith), use double quotes within single quotes, like this:

`”John Smith”`

See 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 software.big.sales.doc.com. domain).

Diagram shows examples of name extentions

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

or


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 doc.com directories

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

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 26, Transitioning from NIS to NIS+ before you starting 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 26, Transitioning from NIS to NIS+.

For your reference, key preparations are summarized below:


Caution – Caution –

In Solaris 2.4 and earlier, 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 Solaris 2.5, the two files are named trans.log and data.dict, and the subdirectory is named /var/nis/data. In Solaris 2.5, the content of the files has also been changed and they are not backward compatible with Solaris 2.4 or earlier. 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 rpc.nisd. Therefore, you should rename neither the directories nor the files.


Two Configuration Methods

The rest of this part of the manual 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 name service has the correct nsswitch.conf file in its /etc directory as described in Chapter 1, The 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.

Chapter 3 NIS+ Setup Scripts

This chapter describes the NIS+ scripts and their functionalities.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) ). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


About the NIS+ Scripts


Caution – Caution –

Before running the NIS+ setup scripts, make sure you have performed the steps described in NIS+ Configuration Overview.


The three NIS+ scripts—nisserver, nispopulate, and nisclient—enable you to set up an NIS+ namespace. The NIS+ scripts are Bourne shell scripts that execute groups of NIS+ commands so you do not have to type the NIS+ commands individually. The following table describes what each script does.

Table 3–1 NIS+ Scripts

NIS+ Script 

What It Does 

nisserver

Sets up the root master, non-root master and replica servers with level 2 security (DES) 

nispopulate

Populates NIS+ tables in a specified domain from their corresponding system files or NIS maps 

nisclient

Creates NIS+ credentials for hosts and users; initializes NIS+ hosts and users 

What the NIS+ Scripts Will Do

In combination with a few NIS+ commands, you can use the NIS+ scripts to perform all the tasks necessary for setting up an NIS+ namespace. See the nisserver, nispopulate, and nisclient man pages for complete descriptions of these commands and their options. Chapter 4, Configuring NIS+ With Scripts shows you how to use the NIS+ scripts to set up an NIS+ namespace.

You can run each of the scripts without having the commands execute by using the -x option. This option lets you see what commands the scripts call and their approximate output without the scripts actually changing anything on your systems. Running the scripts with -x can minimize unexpected surprises.

What the NIS+ Scripts Will Not Do

While the NIS+ scripts reduce the effort required to create an NIS+ namespace, the scripts do not completely replace the individual NIS+ commands. The scripts only implement a subset of NIS+ features. If you are unfamiliar with NIS+, you may want to refer back to this section after you have created the sample NIS+ namespace.

The nisserver script only sets up an NIS+ server with the standard default tables and permissions (authorizations). This script does not:

See Chapter 4, Configuring NIS+ With Scripts for how to use the rpc.nisd command instead of one of the NIS+ scripts to change NIS+ client machines into non-root servers.

The nisclient script does not set up an NIS+ client to resolve host names using DNS. You need to explicitly set DNS for clients that require this option.

Chapter 4 Configuring NIS+ With Scripts

This chapter describes how to configure a basic NIS+ namespace using the nisserver, nispopulate, and nisclient scripts in combination with a few NIS+ commands.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


NIS+ Configuration Overview

Using the configuration scripts is the recommended method of setting up and configuring an NIS+ namespace. Using these scripts is easier than to trying to set up an NIS+ namespace with the NIS+ command set, as described in Chapter 6, Configuring NIS+ Clients, Chapter 7, Configuring NIS+ Servers, and Chapter 8, Configuring a Non-Root Domain

(See the nisserver, nispopulate, and nisclient man pages for complete descriptions of the scripts. See the Glossaryfor definitions of terms and acronyms you do not recognize.)

You should not use the small sample NIS+ namespace referred to in this tutorial manual as a basis for your actual NIS+ namespace. You should destroy the sample namespace after you finish exploring it, instead of adding on to it. It is better to begin again and carefully plan your NIS+ hierarchy before you create your actual namespace.

Table 4–1 summarizes the recommended generic configuration procedure. The left column lists the major configuration activities, such as configuring the root domain or creating a client. The text in the middle describes the activities. The third column lists which script or NIS+ commands accomplish each step.

Table 4–1 Recommended NIS+ Configuration Procedure Overview

Activity 

Description 

Script/NIS+ Commands 

Plan your new NIS+ namespace 

Plan your new NIS+ namespace. See Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model for a full discussion of planning requirements and steps. (If you are just following the NIS+ tutorial in a test-bed network, this step has been done for you.)

 

Prepare your existing namespace 

In order for the scripts to work best, your current namespace (if any) must be properly prepared. See and the Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Modelfor a description of necessary preparations. (If you are just following the NIS+ tutorial in a test-bed network, this step has been done for you.)

 

Configure the Diffie-Hellman key length 

If you intend to use DES authentication, consider using Diffie-Hellman keys longer than the 192-bit default. The extended key length must be the same on all machines in the domain. Specify the desired key length before running the respective initialization scripts. 

nisauthconf

Configure root Domain 

Create the root domain. Configure and initialize the root master server. Create the root domain admin group. 

nisserver

Populate tables 

Populate the NIS+ tables of the root domain from text files or NIS maps. Create credentials for root domain clients. Create administrator credentials. 

nispopulate

nisgrpadm

nisping

Configure root domain clients 

Configure the client machines. (Some of them will subsequently be converted into servers.) Initialize users as NIS+ clients. 

nisclient

Enable servers 

Enable some clients of the root domain to become servers. Some servers will later become root replicas; others will support lower-level domains. 

rpc.nisd

Configure root replicas 

Designate one or more of the servers you just configured as replicas of the root domain. 

rpc.nisd

nisserver

Configure non-root domains 

Create a new domain. Designate a previously enabled server as its master. Create its admin group and admin credentials. 

rpc.nisd

nisserver

Populate tables 

Create credentials for clients of the new domain. Populate the NIS+ tables of the new domain from text files or NIS maps. 

nispopulate

Configure non-root domain clients 

Configure the clients of the new domain. (Some may subsequently be converted into servers for lower-level domains.) Initialize users as NIS+ clients. 

nisclient

The NIS+ scripts enable to you to skip most of the individual procedures included in the above activities.

Creating a Sample NIS+ Namespace

The procedures in this chapter show you how to create a sample NIS+ namespace. The sample NIS+ namespace will be created from /etc files and NIS maps. This sample shows you how to use the scripts both when your site is not running NIS and when NIS is running at your site. You can set your servers to NIS-compatibility mode if they will be serving NIS clients. See the Chapter 26, Transitioning from NIS to NIS+ for more information on NIS-compatibility mode.


Note –

Your site's actual NIS+ namespace and its domain hierarchy probably differs from the sample namespace's, and yours probably contains a different number of servers, clients, and domains. Do not expect any resemblance between your final domain configuration or hierarchy and the sample one. The sample namespace is only an illustration of how to use the NIS+ scripts. After you have created this sample namespace, you should have a clear idea about how to create domains, servers, and clients at your site.


The sample namespace contains the following components:

This scenario shows the scripts being used to configure NIS+ at a site that uses both system information files, such as /etc/hosts, and NIS maps to store network service information. The sample NIS+ namespace uses such a mixed site purely for example purposes.

Summary of NIS+ Scripts Command Lines

Table 4–2 contains the generic sequence of NIS+ scripts and commands you will use to create a ample NIS+ domain. Subsequent sections describe these command lines in detail. After you are familiar with the tasks required to create NIS+ domains, servers, and clients, use Table 4–2 as a quick-reference guide to the appropriate command lines. Table 4–2 is a summary of the actual commands with the appropriate variables that you type to create the sample NIS+ namespace.

Table 4–2 NIS+ Domains Configuration Command Lines Summary

Action 

Machine 

Command 

Include /usr/lib/nis in root's path; C shell or Bourne shell.

Root master server and client machines as superuser 

setenv PATH $PATH:/usr/lib/nis

or 

PATH=$PATH:/usr/lib/nis; export PATH

Optionally, if using DES authentication, select the Diffie-Hellman key length 

Server and client machines as superuser 

nisauthconf -dhkey-length-alg-type des

Create a root master server without or with NIS (YP) compatibility. 

Root master server as superuser 

nisserver -r-dnewdomain.

or 

nisserver -Y-r-d newdomain.

Populate the root master server tables from files or from NIS maps. 

Root master server as superuser 

nispopulate -F-p /files -d newdomain.

or 

nispopulate -Y-d newdomain. -h NISservername\ -a NIS_server_ipaddress -y NIS_domain

Add additional users to the NIS+ admin group. 

Root master server as superuser 

nisgrpadm-aadmin.domain.name.domain.

Make a checkpoint of the NIS+ database. 

Root master server as superuser 

nisping- C domain.

Initialize a new client machine. 

Client machine as superuser 

nisclient- i-d domain . -h master1

Initialize user as an NIS+ client. 

Client machine as user 

nisclient-u

Start the rpc.nisd daemon—required to convert a client to a server without or with NIS (and DNS) compatibility.

Client machine as superuser 

rpc.nisd

or 

rpc.nisd-Y

or 

rpc.nisd -Y -B

Convert a server to a root replica. 

Root master server as superuser 

nisserver-R-ddomain. -h clientname

Convert a server to a non-root master server. 

Root master server as superuser 

nisserver -M-dnewsubdomain.domain. -h\clientmachine

Populate the new master server tables from files or from NIS maps. 

New subdomain master server as superuser 

nispopulate -F-p/subdomaindirectory -d \ newsubdomain .domain .

or 

nispopulate -Y-dnewsubdomain .domain.-h NISservername -aNIS_server_ipaddress -y NIS_domain

Convert a client to a master server replica. 

Subdomain master server as superuser 

nisserver-R-dsubdomain .domain. - h clientname

Initialize a new client of the subdomain. Clients can be converted to subdomain replicas or to another server.  

New subdomain client machine as superuser  

nisclient -i -d newsubdomain.domain. - h \ subdomainmaster

Initialize user as an NIS+ client.  

Client machine as user 

nisclient -u


Note –

To see what commands an NIS+ script calls, without actually executing the commands, use the -x option. The -x option causes the command names and their approximate output to echo to the screen as if you were actually running the script. Running the scripts for the first time with -x can minimize unexpected results. For more information, see the man pages for the scripts.


Setting Up NIS+ Root Servers

Setting up the root master server is the first activity towards establishing NIS+ domain. This section shows you how to configure a root master server using the nisserver script with default settings. The root master server uses the following defaults:


Note –

The nisserver script modifies the name service switch file for NIS+ when it sets up a root master server. The /etc/nsswitch.conf file can be changed later. See Chapter 1, The Name Service Switch for information on the name service switch.


Prerequisites to Running nisserver

Check to see that the /etc/passwd file on the machine you want to be root master server contains an entry for root.

Information You Need

You need the following:

Table 4–3 Internet Organizational Domains

Domain 

Purpose 

com 

Commercial organizations 

edu 

Educational institutions 

gov 

Government institutions 

mil 

Military groups 

net 

Major network support centers 

org 

Nonprofit organizations and others 

int 

International organizations 

In the following example, the machine that is designated as the root master server is called master1, and doc.com. becomes the new root domain.


Note –

Domains and hosts should not have the same name. For example, if you have doc.com. as a root domain, you should not have a machine named doc in any of your domains. 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 do not want to create a sales.west.myco.com subdomain.


How to Create a Root Master Server

  1. Set the superuser's PATH variable to include /usr/lib/nis.

    Either add this path to root's .cshrc or .profile file or set the variable directly.

  2. Optionally, if using DES authentication, specify the Diffie-Hellman key length.

    To use 640–bit Diffie-Hellman keys as well as the default 192–bit keys, type:


    nisauthconf dh640-0 des

    To allow only 640–bit keys (rejects 192–bit keys), type:


    nisauthconf dh640-0
  3. Type the following command as superuser (root) to configure a root master server.

    The -r option indicates that a root master server should be configure. The -d option specifies the NIS+ domain name.


    master1# nisserver -r -d doc.com.
    This script sets up this machine “master1” as a NIS+ root master
    server for domain doc.com.
    Domain name : doc.com.
    NIS+ group : admin.doc.com.
    NIS (YP) compatibility : OFF
    Security level : 2=DES
    Is this information correct? (type 'y' to accept, 'n' to change)

    “NIS+ group” refers to the group of users who are authorized to modify the information in the doc.com. domain. (Domain names always end with a period.) Modification includes deletion. admin.domainname is the default name of the group. See How to Change Incorrect Information for instructions on how to change this name.

    “NIS compatibility” refers to whether an NIS+ server accepts information requests from NIS clients. When set to OFF, the default setting, the NIS+ server does not fulfill requests from NIS clients. When set to ON, an NIS+ server fulfills such requests. You can change the NIS-compatibility setting with this script. See How to Change Incorrect Information.


    Note –

    This script sets machines up only at security level 2, the highest level of NIS+ security. You cannot change the security level when using this script. After the script has completed, you can change the security level with the appropriate NIS+ command. See the rpc.nisd man page for more information on changing security levels.


  4. Type y (if the information shown on the screen is correct).

    Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information for what you need to do if you type n.)


    Is this information correct? (type 'y' to accept, 'n'' to change) 
    y
    This script will set up your machine as a root master server for 
    domain doc.com. without NIS compatibility at security level 2.
    Use "nisclient -r" to restore your current network service environment.
    Do you want to continue? (type `y' to continue, `n' to exit the script)
  5. Type y to continue NIS+ configuration.

    (Typing n safely stops the script.) If you interrupt the script after you have chosen y and while the script is running, the script stops running and leaves configured whatever it has created so far. The script does not do any automatic recovery or cleaning up. You can always rerun this script.


    Do you want to continue? (type 'y' to continue, 'n' to exit the script
    y
    setting up domain information “doc.com.” ...
    setting up switch information ...
    running nisinit ...
    This machine is in the doc.com. NIS+ domain.
    Setting up root server ...
    All done.
    starting root server at security level 0 to create credentials...
    running nissetup ...
    (creating standard directories & tables)
    org_dir.doc.com. created
    Enter login password:

    The nissetup command creates the directories for each NIS+ table.

  6. Type your machine's root password at the prompt and press Return.

    In this case, the user typed the master1 machine's root password.


    Wrote secret key into /etc/.rootkey
    setting NIS+ group to admin.doc.com. ...
    restarting root server at security level 2 ...
    This system is now configured as a root server for domain doc.com.
    You can now populate the standard NIS+ tables by using the
    nispopulate or /usr/lib/nis/nisaddent commands.

    Your root master server is now configured and ready for you to populate the NIS+ standard tables. To continue with populating tables, skip to Populating NIS+ Tables.

How to Change Incorrect Information

If you typed n because some or all of the information returned to you was wrong in Step 4 in the above procedure, you will see the following:


Is this information correct? (type 'y' to accept, 'n' to change)
 n
Domain name: [doc.com.]
  1. Press Return if the domain name is correct; otherwise, type the correct domain name and press Return.

    In this example, Return was pressed, confirming that the desired domain name is doc.com.. The script then prompts for the NIS+ group name.


    Is this information correct? (type 'y' to accept, 'n' to change)
     n
    Domain name: [doc.com.]
    NIS+ group: [admin.doc.com.]
  2. Press Return if NIS+ group is correct; otherwise, type the correct NIS+ group name and press Return.

    In this example, the name was changed. The script then prompts for NIS compatibility.


    NIS+ group: [admin.doc.com.] netadmin.doc.com.
    NIS (YP) compatibility (0=off, 1=on): [0]
  3. Press Return if you do not want NIS compatibility; otherwise, type 1 and press Return.

    In this example, Return was pressed, confirming that NIS compatibility status is correct. Once again, the script asks you if the information is correct.


    Note –

    If you choose to make this server NIS compatible, you also need to edit a file and restart the rpc.nisd daemon before it will work. See Configuring a Client as an NIS+ Server for more information.



    NIS (YP) compatibility (0=off, 1=on): [0]
    Domain name : doc.com.
    NIS+ group : netadmin.doc.com.
    NIS (YP) compatibility : OFF
    Security level : 2=DES
    Is this information correct? (type 'y' to accept, 'n' to change) 

    When the information is correct, continue with Step 3 in How to Create a Root Master Server. You can keep choosing -n until the information is correct.

How to Set Up a Multihomed NIS+ Root Master Server

The procedure for setting up a multihomed NIS+ server is the same as setting up a single interface server. The only difference is that there are more interfaces that need to be defined in the hosts database (/etc/hosts and /etc/inet/ipnodes files, and NIS+ hosts and ipnodes tables). Once the host information is defined, use the nisclient and nisserver scripts to set up the multihomed NIS+ server. For information about setting up a multihomed replica server, see How to Set Up Multihomed NIS+ Replica Servers.


Caution – Caution –

When setting up a multihomed NIS+ server, the server's primary name must be the same as the nodename for the system. This is a requirement of both Secured RPC and nisclient.

If these names are different, Secure RPC authentication will fail to work properly causing NIS+ problems.


The following procedure shows how to set up an NIS+ root master server:

  1. On the root master, add the server host information into the /etc/hosts or /etc/inet/ipnodes file.

    For example, the /etc/hosts file for the hostA system with three ethernet interfaces looks like:


    127.0.0.1 localhost loghost
    192.168.10.x hostA hostA-10 hostA-le0
    192.168.11.y hostA hostA-11 hostA-le1
    192.168.12.z hostA hostA-12
     
  2. Set up the server as a multihome NIS+ root server with nisserver.


    hostA# nisserver -r -d sun.com

    where our example shows sun.com as the root domain name. Issue the nisserver command using the name of your root domain name.

    After completing the steps for setting up a multihome NIS+ root server, the remainder of the setup is exactly the same as for a single interface server.

Populating NIS+ Tables

After the root master server has been configured, you can populate its standard NIS+ tables with name services information. This section shows you how to populate the root master server's tables with data from files or NIS maps using the nispopulate script with default settings. The script uses:


Note –

The shadow file's contents are merged with the passwd file's to create the passwd table when files are the tables' information source. No shadow table is created.


Prerequisites to Running nispopulate

Before you can run the nispopulate script:

Information You Need

If populating from files, you need:

If populating from NIS maps, you need:


Note –

The NIS domain name is case-sensitive, while the NIS+ domain name is not.


How to Populate the Root Master Server Tables

  1. Perform either substep a or b to populate the root master server tables, then continue with Step 2.

    Substep a shows you how to populate tables from files. Substep b shows you how to populate tables from NIS maps. Type these commands in a scrolling window; otherwise, the script's output might scroll off the screen.


    Note –

    The nispopulate script can fail if there is insufficient /tmp space on the system. To keep this from happening, you can set the environment variable TMPDIR to a different directory. If TMPDIR is not set to a valid directory, the script uses the /tmp directory.


    1. Type the following command to populate the tables from files.


      master1# nispopulate -F -p /nis+files -d doc.com.
      NIS+ domain name : doc.com.
      Directory Path : /nis+files
      Is this information correct? (type 'y' to accept, 'n' to change)

      The -F option indicates that the tables take their data from files. The -p option specifies the directory search path for the source files. (In this case, the path is /nis+files.) The -d option specifies the NIS+ domain name. (In this case, the domain name is doc.com.)

      The NIS+ principal user is root. You must perform this task as superuser in this instance because this is the first time that you are going to populate the root master server's tables. The nispopulate script adds credentials for all members of the NIS+ admin group.

    2. Type the following command to populate the tables from NIS maps.


      master1# nispopulate -Y -d doc.com. -h salesmaster -a 130.48.58.111 
      -y sales.doc.com.
      NIS+ domain name : doc.com.
      NIS (YP) domain : sales.doc.com.
      NIS (YP) server hostname : salesmaster
      Is this information correct? (type 'y' to accept, 'n' to change)

      The -Y option indicates that the tables take their data from NIS maps. The -d option specifies the NIS+ domain name. The -h option specifies the NIS server's machine name. (In this case, the NIS server's name is salesmaster. You have to insert the name of a real NIS server at your site to create the sample domain.) The -a option specifies the NIS server's IP address. (In this case, the address is 130.48.58.111. You have to insert the IP address of a real NIS server at your site to create the sample domain.) The -y option specifies the NIS domain name. (In this case, the domain's name is sales.doc.com.; you have to insert the NIS domain name of the real NIS domain at your site to create the sample domain.

      The NIS+ principal user is root. You must perform this task as superuser in this instance because this is the first time that you are going to populate the root master server's tables. The nispopulate script also adds credentials for all members of the NIS+ admin group.

  2. Type y (if the information returned on the screen is correct).

    Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information for what you need to do if the information is incorrect.)

    • If you performed substep a of Step a, you will see the following:


      Is this information correct?
      (type 'y' to accept, 'n' to change) 
      y
      
      This script will populate the following NIS+ tables for domain doc.com. from 
      the files in /nis+files: auto_master auto_home ethers group hosts networks 
      passwd protocols services rpc netmasks bootparams netgroup aliases shadow
      **WARNING: Interrupting this script after choosing to continue may leave 
      the tables only partially populated. This script does not do any automatic 
      recovery or cleanup.
      Do you want to continue? (type 'y' to continue, 'n' to exit this script)
    • If you performed substep b of Step b, you will see the following:


      Is this information correct? (type 'y' to accept, 'n' to change)
      y
      This script will populate the following NIS+ tables for domain doc.com. from the 
      NIS (YP) maps in domain sales: auto_master auto_home ethers group hosts networks 
      passwd protocols services rpc netmasks bootparams netgroup aliases
      **WARNING: Interrupting this script after choosing to continue may leave the
       tables only partially populated. This script does not do any automatic recovery 
      or cleanup.
      Do you want to continue? (type 'y' to continue, 'n' to exit this script)
  3. Type y to continue populating the tables.

    (Typing n safely stops the script.) If you interrupt the script after you have chosen y—while the script's running—the script stops running and can leave the tables only partially populated. The script does not do any automatic recovery or cleaning up. You can safely rerun the script, but the tables will be overwritten with the latest information.

    • If you are populating tables from files, you see messages like the following as the script uses hosts and passwd information to create the credentials for hosts and users:


      Do you want to continue? (type 'y' to continue, 'n' to exit this script) 
      y
      populating auto_master table from file /nis+files/auto_master
      ... auto_master table done. 
      populating auto_home table from file /nis+files/auto_home
      ... auto_home table done.
      Credentials have been added for the entries in the hosts and passwd table(s).
      Each entry was given a default network password (also known as a Secure-
      RPC password). This password is: nisplus
      Use this password when the nisclient script requests the network password.
      Done!

      Note and remember the Secure RPC password (nisplus, in the above example). Use this password when prompted for your network or Secure RPC password.

      The script continues until it has searched for all the files it expects and loads all the tables it can from the available files.

    • If you are populating tables from NIS maps, you will see messages like the following as the script uses hosts and passwd information to create the credentials for hosts and users:


      Do you want to continue? (type 'y' to continue, 'n' to exit this script)
      y
      populating auto_master table from sales.doc.com. NIS(YP) domain... 
      auto_master table done. 
      populating auto_home table from file sales.doc.com. NIS(YP) domain...
      auto_home table done.
      ....
      Credentials have been added for the entries in the hosts and passwd table(s).
      Each entry was given a default network password (also known as a Secure-RPC password). 
      This password is: nisplus
      Use this password when the nisclient script requests the network password.
      Done!

      Note and remember the Secure RPC password (nisplus, in the above example). Use this password when prompted for your network or Secure RPC password.

      All the tables are now populated. You can ignore any parse error warnings. Such errors indicate that NIS+ found empty or unexpected values in a field of a particular NIS map. You may want to verify the data later after the script completes.

  4. (Optional) Add yourself and others to the root domain's admin group.

    For example, if your login ID is topadm and your co-worker's ID is secondadmin, you enter:


    master1# nisgrpadm -a admin.doc.com. topadm.doc.com. secondadm.doc.com.
    Added “topadm.doc.com.” to group “admin.doc.com.”.
    Added “secondadm.doc.com.” to group “admin.doc.com.”.

    The admin.doc.com. argument in the nisgrpadm -a command above is the group name, which must come first. The remaining two arguments are the names of the administrators.


    Note –

    This step is necessary only if you want to add additional users to the admin group now, which is a good time to add administrators to the root server. You can also add users to the admin group after you have configured NIS+.


    You do not have to wait for the other administrators to change their default passwords to perform this step; however, they must already be listed in the passwd table before you can add them to the admin group. Members of the admin group will be unable to act as NIS+ principals until they add themselves to the domain. See How to Initialize an NIS+ User for more information on initializing users. The group cache also has to expire before the new members become active.

  5. Type the following command to checkpoint the domain.


    master1# nisping -C doc.com.
    Checkpointing replicas serving directory doc.com.
    Master server is master1.doc.com.
     Last update occurred at date
    Master server is master1.doc.com.
    checkpoint scheduled on master1.doc.com.

    This step ensures that all the servers supporting the domain transfer the new information from their initialization (.log) files to the disk-based copies of the tables. Since you have just configured the root domain, this step affects only the root master server, as the root domain does not yet have replicas.


Caution – Caution –

If you do not have enough swap or disk space, the server will be unable to checkpoint properly, but it will not notify you. One way to make sure everything is correct is to list the contents of a table with the niscat command. For example, to check the contents of the rpc table, type:


master1# niscat rpc.org_dir
rpcbind rpcbind 100000
rpcbind portmap 100000
rpcbind sunrpc 100000

If you do not have enough swap space, you will see the following error message instead of the sort of output you see above.


can't list table: Server busy, Try Again.

Even though it does not say so, in this context this message indicates that you do not have enough swap space. Increase the swap space and checkpoint the domain again.


Setting Up NIS+ Client Machines

After the root master server's tables have been populated from files or NIS maps, you can initialize NIS+ client machines. (Because the root master server is an NIS+ client of its own domain, no further steps are required to initialize it.) This section shows you how to initialize an NIS+ client by using the nisclient script with default settings. The script will use:


Note –

The -i option used in How to Initialize a New Client Machinedoes not configure an NIS+ client to resolve host names requiring DNS. You need to explicitly include DNS for clients in their name service switch files. See the “Domain Name System (Overview)” in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information on resolving host names through DNS.


Prerequisites to Running nisclient

Before you can use the nisclient script:

Information You Need

You need:

How to Initialize a New Client Machine

  1. Optionally, if using DES authentication, specify the Diffie-Hellman key length.

    On the master server, type


    nisauthconf

    Use the output as the arguments when running the nisauthconf command on the client. For example, if nisauthconf on the master server produces


    dh640dh-0 des

    type the following command on the client machine


    nisauthconf dh640dh-0 des
  2. Type the following command to initialize the new client on the new client machine.

    The -i option initializes a client. The -d option specifies the new NIS+ domain name. (If the domain name is not specified, the default is the current domain name.) The -h option specifies the NIS+ server's host name.


    client1# nisclient -i -d doc.com. -h master1
    Initializing client client1 for domain “doc.com.”.
    Once initialization is done, you will need to reboot your machine.
    Do you want to continue? (type 'y' to continue, 'n' to exit this script)
  3. Type y.

    Typing n exits the script. The script prompts you only for the root server's IP address if there is no entry for it in the client's /etc/hosts or /etc/inet/ipnodes file.


    Do you want to continue? (type 'y' to continue, 'n' to exit this script)
    y
    Type server master1's IP address:
  4. Type the correct IP address, and press Return.

    This example uses the hypothetical address 123.123.123.123.


    Type server master1's IP address: 123.123.123.123
    setting up the domain information...
    setting up the name service switch information...
    At the prompt below, type the network password (also known as the 
    Secure-RPC password) that you obtained either from your administrator or 
    from running the nispopulate script.
     Please enter the Secure-RPC password for root:
  5. Type the Secure RPC password (also known as the network password) only if the Secure RPC password differs from the root login password.

    In this case, use the default, nisplus.

    The password does not echo on the screen. If you mistype it, you are prompted for the correct one. If you mistype it twice, the script exits and restores your previous network service. If this happens, try running the script again.


    Please enter the login password for root:
  6. Type the root password for this client machine.

    The password does not echo on the screen. (If the Secure RPC password and the root login password happen to be the same, you will not be prompted for the root login password.)

    Typing the root password changes the credentials for this machine. The RPC password and the root password are now the same for this machine.


    Please enter the login password for root:
    Wrote secret key into /etc/.rootkey
    Your network password has been changed to your login one.
    Your network and login passwords are now the same.
    Client initialization completed!!
    Please reboot your machine for changes to take effect.
  7. Reboot your new client machine.

    Your changes do not take effect until you reboot the machine.

    You can now have the users of this NIS+ client machine add themselves to the NIS+ domain.

Creating Additional Client Machines

Repeat the preceding client-initiation procedure on as many machines as you like. To initiate clients for another domain, repeat the procedure but change the domain and master server names appropriately.

The sample NIS+ domain described in this chapter assumes that you will initialize four clients in the doc.com. domain. You are then going to configure two of the clients as non-root NIS+ servers and a third client as a root replica of the root master server of the doc.com. domain.


Note –

You always have to make a system into a client of the parent domain before you can make the same system a server of any type.


Initializing NIS+ Client Users

After a machine has become an NIS+ client, the users of that machine must add themselves to the NIS+ domain. Adding a user to the domain means changing the Secure RPC password to that user's login password. What actually happens is that the user's password and the Secure RPC password are bound together. This procedure uses the nisclient script.

Prerequisites to Running nisclient

Before you can use the nisclient script to initialize a user:

Information You Need

You need:

How to Initialize an NIS+ User

  1. To become an NIS+ client, enter the following nisclient command while logged in as the user.


    user1prompt% nisclient -u
    At the prompt below, type the network password (also known as the 
    Secure-RPC password) that you obtained either from your administrator 
    or from running the nispopulate script.
    Please enter the Secure-RPC password for user1:
  2. Enter the Secure RPC password, which is nisplus in this case.

    The password does not echo on the screen.


    Please enter the login password for user1:
  3. Type the user's login password and press Return.

    The password does not echo on the screen.


    Your network password has been changed to your login one.
    Your network and login passwords are now the same

    This user is now an NIS+ client. You need to have all users make themselves NIS+ clients.

Setting Up NIS+ Servers

Now that the client machines have been initialized, you can change any of them to NIS+ servers of the following types:


Note –

You can have only one NIS+ master root server. Root NIS+ servers are a special type of NIS+ server. This section does not describe how to configure a root master server; see Setting Up NIS+ Root Servers for more information.


You can configure servers any of these different ways:

Servers and their replicas should have the same NIS-compatibility settings. If they do not have the same settings, a client that needs NIS compatibility set to receive network information may not be able to receive it if either the server or replica it needs is unavailable.

This example shows the machine client1 being changed to a server. This procedure uses the NIS+ rpc.nisd command instead of an NIS+ script.

Prerequisites to Running rpc.nisd

Before you can run rpc.nisd:

Information You Need

You need the superuser password of the client that you will convert into a server.

Configuring a Client as an NIS+ Server

Perform any of the following to alternate procedures to configure a client as a server. These procedures create a directory with the same name as the server and create the server's initialization files which are placed in /var/nis.


Note –

All servers in the same domain must have the same NIS-compatibility setting. For example, if the master server is NIS compatible, then its replicas should also be NIS compatible.


How to Configure a Server Without NIS Compatibility

  1. To configure a server without NIS compatibility, enter the following command:


    client1# rpc.nisd

How to Configure a Server With NIS Compatibility

  1. Edit the /etc/init.d/rpc file on the server to uncomment the whole line containing the string -EMULYP=”-Y”.

    To do this, remove the # character from the beginning of the line.

  2. Type the following as superuser.


    client1# rpc.nisd -Y

How to Configure a Server With DNS and NIS Compatibility

This procedure configures an NIS+ server with both DNS forwarding and NIS+ compatibility. Both of these features are needed to support SunOS 4.x clients.

  1. Edit the /etc/init.d/rpc file on the server to uncomment the whole line containing the string EMULYP=”-Y”.

    To do this, remove the # character from the beginning of the line.

  2. Add -B to the above line inside the quotes.

    The line should read:

    -EMULYP=”-Y -B”

  3. Type the following command as superuser.


    client1# rpc.nisd -Y -B

    Now this server is ready to be designated a master or replica of a domain.

Creating Additional Servers

Repeat the preceding client-to-server conversion procedure on as many client machines as you like.

The sample NIS+ domain described in this chapter assumes that you will convert three clients to servers. You will then configure one of the servers as a root replica, another as a master of a new subdomain, and the third as a replica of the master of the new subdomain.

Creating a Root Replica Server

To have regularly available NIS+ service, you should always create one or more root replica servers. Having replicas can also speed network-request resolution because multiple servers are available to handle requests.

For performance reasons, you should have no more than a few replicas per domain. If your network includes multiple subnets or different sites connected by a Wide Area Network (WAN), you may need additional replicas:

See Creating a Root Replica Server for additional information on how to determine the optimum number of replicas.

How to Create a Root Replica shows the machine client1 being configured as a root replica for the doc.com. domain. This procedure uses the NIS+ nisserver script. (You can also use the NIS+ command set to configure a replica server as described in Using NIS+ Commands to Configure a Replica Server.)

Prerequisites to Running nisserver

Before you can run nisserver to create a replica:

Information You Need

You need:

How to Create a Root Replica

  1. To create a root replica, type the following command as superuser (root) on the NIS+ domain's root master server.


    master1# nisserver -R -d doc.com. -h client1
    This script sets up a NIS+ replica server for domain doc.com.
    Domain name: :doc.com.
    NIS+ server	: :client1
    Is this information correct? (type 'y' to accept, 'n' to change)

    The -R option indicates that a replica should be configured. The -d option specifies the NIS+ domain name (doc.com., in this example). The -h option specifies the client machine (client1, in this example) that will become the root replica.

  2. Type y to continue.

    Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information for what you need to do if you type n.)


    Is this information correct? (type 'y' to accept, 'n' to change) 
    y
    This script will set up machine “client1” as an NIS+ replica server for domain 
    doc.com. without NIS compatibility. The NIS+ server daemon, rpc.nisd, must 
    be running on client1 with the proper options to serve this domain. 
    Do you want to continue? (type 'y' to continue, 'n' to exit this script)
  3. Type y to continue.

    Typing n safely stops the script. The script will exit on its own if rpc.nisd is not running on the client machine.


    Is this information correct? (type 'y' to continue, 'n' to exit this script)
    y
    The system client1 is now configured as a replica server for domain doc.com..
    The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper 
    options to serve this domain. If you want to run this replica in NIS (YP) 
    compatibility mode, edit the /etc/init.d/rpc file on the replica server '
    to uncomment the line which sets EMULYP to "-Y". This will ensure that 
    rpc.nisd will boot in NIS-compatibility mode. Then, restart rpc.nisd with 
    the “-Y” option. These actions should be taken after this script completes.

    Note –

    The above notice refers to an optional step. You need to modify only the /etc/init.d/rpc file if you want the root replica to be NIS compatible and it is not now NIS compatible. That is, the file needs modification only if you want the root replica to fulfill NIS client requests and it was not already configured as an NIS-compatible server. See Configuring a Client as an NIS+ Server for more information on creating NIS-compatible servers.


  4. [Optional] Configure the replica to run in NIS (YP) compatibility mode.

    If you want this replica to run in NIS compatibility mode, follow these steps:

    1. Kill rpc.nisd

    2. Edit the server's /etc/init.d/rpc file to uncomment the line that sets EMULYP to -Y.

      In other words, delete the # character from the start of the EMULYP line.

    3. Restart rpc.nisd.

  5. Load your namespace data on to the new replica server.

    You can do this in two ways:

    • The preferred method of loading data on to a new replica server is to use the NIS+ backup and restore capabilities to back up the master server, then “restore” that data on to the new replica server. This step is described in detail in How to Load Namespace Data—nisrestore Method.

    • Run nisping. Running nisping initiates a full resynch of all NIS+ data from the master server to this new replica. If your namespace is large, this can take a long time, during which your master server is very busy and slow to respond and your new replica is unable to answer NIS+ requests. This step is described in detail in How to Load Namespace Data—nisping Method.

    When you have finished loading your namespace data, the machine client1 is now an NIS+ root replica. The new root replica can handle requests from the clients of the root domain. Because there are now two servers available to the domain, information requests can be fulfilled faster.

    Using these procedures, you can create as many root replicas as you need. You can also use these procedures to create replica servers for subdomains.

How to Set Up Multihomed NIS+ Replica Servers

The procedure for setting up a multihomed NIS+ server is the same as setting up a single interface server. The only difference is that there are more interfaces that need to be defined in the hosts database (/etc/hosts and /etc/inet/ipnodes files, and NIS+ hosts and ipnodes tables). Once the host information is defined, use the nisclient and nisserver scripts to set up the multihomed NIS+ server.


Caution – Caution –

When setting up a multihomed NIS+ server, the server's primary name must be the same as the nodename for the system. This is a requirement of both Secured RPC and nisclient.

If these names are different, Secure RPC authentication will fail to work properly causing NIS+ problems.


This procedure shows how to set up any NIS+ non-root master servers. The following example creates a replica for the root domain. For information about setting up a multihomed root server, see How to Set Up a Multihomed NIS+ Root Master Server.

  1. Add the server host information into the hosts or ipnodes file.

    For example, for the hostB system with three interfaces:


    192.168.11.y hostB hostB-11
    192.168.12.x hostB hostB-12
    192.168.14.z hostB hostB-14
     
  2. On the root master server, use either nispopulate or nisaddent to load the new host information into the hosts or ipnodes table.

    For example:


    hostA# nispopulate -F -d sun.com hosts

    where the example shows sun.com as the NIS+ root domain name. Issue the nispopulate command specifying the name of your NIS+ root domain name.

  3. On the root master server, use the nisclient script to create the credential for the new client.

    For example:


    hostA# nisclient -c -d sun.com hostB

    where the example shows sun.com as the root domain name. Issue the nisclient command specifying the name of your root domain name.

  4. On the non-root master server, use nisclient to start the new server if it is not already running and initialize the machine as an NIS+ client.

    For example:


    hostB# nisclient -i -d sun.com

    where the example shows sun.com as the root domain name. Issue the nisclient command specifying the name of your root domain name.

  5. On the root master server, use nisserver to create a non-root master.

    For example:


    hostA# nisserver -M -d eng.sun.com -h hostB.sun.com.

    where the example shows eng.sun.com as the NIS+ domain name and hostB.sun.com as the fully-qualified hostname for the NIS+ server. Issue the nisserver command specifying the name of your NIS+ domain and the fully-qualified hostname for the NIS+ server.

  6. On the root master server, use nisserver to set up a replica server.

    For example:


    hostA# nisserver -R -d sun.com -h hostB.sun.com.

    where the example shows sun.com as the replica server and hostB.sun.com as the fully-qualified hostname for the NIS+ server. Issue the nisserver command specifying the name of your replica server and NIS+ domain.

After completing the steps for setting up a multihome NIS+ replica server, the remainder of the setup is exactly the same as for a single interface server.

Creating a Subdomain

This section shows you how to create the master server of a new non-root domain. The new domain will be a subdomain of the doc.com. domain. The hierarchical structure of NIS+ allows you to create a domain structure that parallels your organizational structure.

This example shows the machine client2 being converted to the master server of a new domain called sub.doc.com.. This procedure uses the NIS+ script nisserver.

Prerequisites to Running nisserver

Before you can run nisserver to create a master server for a new non-root domain:

Information You Need

You need:

In How to Create a New Non-Root Domain, the new non-root domain is called sub.doc.com..


Note –

In Solaris release 2.6 and earlier, any NIS+ client can be converted to an NIS+ master server as long as it is itself in a domain above the domain it is serving. For example, an NIS+ client in domain sales.doc.com. can serve domains below it in the hierarchy, such as west.sales.doc.com. or even alameda.west.sales.doc.com.. This client cannot, however, serve the domain doc.com., because doc.com. is above the domain sales.doc.com. in the hierarchy. Root replicas are the only exception to this rule. They are clients of the domain that they serve.



Note –

In Solaris release 7, the domainname of any non-root NIS+ server can be set to the domain it serves. The non-root server behaves as if it lives in its own domain. This allows you to configure applications on the non-root server to use the information provided by the domain above it in the hierarchy.

The non-root server's credentials must still be in the domain above it in the hierarchy. Configure the non-root servers as described in How to Create a New Non-Root Domain. Only after the servers are properly configured, can you change the domainname to that of the domain it serves. See the -k option of nisinit and the -d option of nisserver.


How to Create a New Non-Root Domain

  1. Type the following command as superuser (root) on the NIS+ domain's root master server to create a new non-root domain master server.

    The -M option indicates that a master server for a new non-root domain should be created. The -d option specifies the new domain name, sales.doc.com. in this instance. The -h option specifies the client machine, (client2, in this example), that will become the master server of the new domain.


    master1# nisserver -M -d sales.doc.com. -h client2
    This script sets up a non-root NIS+ master server for domain sales.doc.com.
    Domain name : sales.doc.com.
    NIS+ server : client2
    NIS+ group : admin.sales.doc.com.
    NIS (YP) compatibility : OFF
    Security level : 2=DES
    Is this information correct? (type 'y' to accept, 'n' to change)

    Master servers of new non-root domains are created with the same set of default values as root servers. See How to Create a Root Master Server for more information on NIS+ group, NIS compatibility, and security level.

  2. Type y to continue.

    Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information for what you need to do if you type n.)


    Is this information correct? 
    (type 'y' to accept, 'n' to change) y
    This script sets up machine “client2” as an NIS+ non-root master 
    server for domain sales.doc.com.
    Do you want to continue? (type 'y' to continue, 'n' to exit this script)
  3. Type y to continue.

    Typing n safely exits the script. The script exits on its own if rpc.nisd is not running on the client machine.


    Do you want to continue? (type 'y' to continue, 'n' 
    to exit this script) 
    y
    running nissetup ...
    org_dir.sales.doc.com. created
    groups_dir.sales.doc.com. created
    ...
    ...
    setting NIS+ group admin.sales.doc.com. ...
    The system client2 is now configured as a non-root server for 
    domain sales.doc.com.
    You can now populate the standard NIS+ tables by using the 
    nispopulate or /usr/lib/nis/nisaddent commands. 

    The machine client2 is now the master server of the sales.doc.com. domain. The sales.doc.com. domain is a subdomain of the doc.com. domain. The machine client2 is simultaneously still a client of the root domain doc.com., and the master server of the sales.doc.com. domain.

    You can now populate the standard NIS+ tables on the new master server of the sales.doc.com. domain.

Creating Additional Domains

Repeat the preceding procedure for changing servers to master servers of new non-root domains on as many server machines as you like. Every new master server is a new domain. Plan your domain structure before you start creating an NIS+ namespace. See Structure of the NIS+ Namespace for more information on planning an NIS+ hierarchy.

Populating the New Subdomain's Tables

After you have created a new domain, you need to populate its master server's standard NIS+ tables. You use the same procedure to populate the new master server's tables as you used to populate the root master server's tables. The major difference is that the nispopulate script is run on the new master server instead of on the root master server. The domain names and file paths or NIS servers' names may change as well.

This example shows the tables of the new domain, sales.doc.com., being populated.

Prerequisites to Running nispopulate

Before you can run the nispopulate script to populate the new master server's tables:


root:x:0:1:0000-Admin(0000):/:/sbin/sh
daemon:x:1:3:0000-Admin(0000):/:
bin:x:3:5:0000-Admin(0000):/usr/bin:
sys:x:3:3:0000-Admin(0000):/:
adm:x:4:4:0000-Admin(0000):/var/adm:
lp:x:78:9:0000-lp(0000):/usr/spool/lp:
smtp:x:0:0:mail daemon user:/:
uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:
nuucp:x:7:8:0000-
uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:22:6:Network Admin:/usr/net/nls:
nobody:x:60000:60000:uid no body:/:
noaccess:x:60002:60002:uid no access:/:

Note –

The nispopulate script can fail if there is insufficient /tmp space on the system. To keep this from happening, you can set the environment variable TMPDIR to a different directory. If TMPDIR is not set to a valid directory, the script uses the /tmp directory instead.


Information You Need

If populating from files, you need:

If populating from NIS maps, you need:


Note –

The NIS domain name is case-sensitive, while the NIS+ domain name is not.


Populating the Master Server Tables

Since this procedure is essentially the same as the procedure shown in How to Populate the Root Master Server Tables, this example shows you only what you would type to populate the tables of the new domain, sales.doc.com.. For more information about this procedure, see How to Populate the Root Master Server Tables.


Note –

This script should be run on the new domain's master server, not the root master server.


The alternate methods of populating the master server tables on the new master server are:

Whichever method you choose should be executed in a scrolling window as the script's output might otherwise scroll off the screen.

How to Populate the Tables From Files

To populate master server tables from files, type the following commands.


client2# nispopulate -F -p /nis+files -d sales.doc.com.
NIS+ domain name : sales.doc.com.
Directory Path : /nis+files
Is this information correct? (type 'y' to accept, 'n' to change

How to Populate the Tables From NIS Maps

To populate master server tables from NIS maps, type the following commands.


client2# nispopulate -Y -d sales.doc.com. -h businessmachine -a 
 IP_addr_of_NIS_server -y business.doc.com.
NIS+ Domain name : sales.doc.com.
NIS (YP) domain : business.doc.com.
NIS (YP) server hostname : businessmachine
Is this information correct? (type 'y' to accept, 'n' to change)

See How to Populate the Root Master Server Tables for additional information.

Creating Subdomain Replicas

The same principles that apply to root domain replicas apply to subdomain replicas (see Creating a Root Replica Server).

You use the same procedure to create a subdomain replica as you do to create a root replica. The major difference between creating the root replica and a subdomain replica is that the machine you are going to convert to a subdomain replica remains a client of the domain above the one it serves as a replica. This example shows you only what you type to create a replica for the new domain. For the rest of the script's output, see How to Create a Root Replica.

Prerequisites to Running nisserver

Before you can run nisserver to create a replica:

Information You Need

How to Create a Replica

    Run the nisserver -R command as superuser (root) on the NIS+ domain's master server.


client2# nisserver -R -d sales.doc.com. -h client3
This script sets up a NIS+ replica server for domain sales.doc.com.
Domain name 	::sales.doc.com.
NIS+ server :client
Is this information correct? (type 'y' to accept, 'n' to change)

In this example, client2 is the master server. The -R option indicates that a replica should be configured. The -d option specifies the NIS+ domain name (sales.doc.com. in this example). The -h option specifies the client machine (client3, in this example) that will become the replica. Notice that this machine is still a client of the doc.com. domain and not a client of the sales.doc.com. domain.

See How to Create a Root Replica for the rest of this script's output.

Initializing Subdomain NIS+ Client Machines

After the master server's tables have been populated from files or NIS maps, you can initialize an NIS+ client machine. This section shows you how to initialize an NIS+ client in the new domain using the nisclient script with default settings. The NIS+ client machine is a different machine from the NIS+ master server.


Note –

The -i option used in How to Initialize a New Subdomain Client Machinedoes not configure an NIS+ client to resolve host names requiring DNS. You need to explicitly include DNS for clients in their name service switch files.


You use the same procedure to initialize a client in the new domain as you do to initialize a client in the root domain. This example shows you only what you would type to initialize a client for the new domain. For the rest of the script's output, see How to Initialize a New Client Machine.

Prerequisites to Running nisclient

Before you can use the nisclient script to initialize a user:

Information You Need

You need:

How to Initialize a New Subdomain Client Machine

    Type the following command as superuser to initialize the new client on the new client machine.


subclient1# nisclient -i -d sales.doc.com. -h client2
Initializing client subclient1 for domain “sales.doc.com.”.
Once initialization is done, you will need to reboot your machine.
Do you want to continue? (type 'Y' to continue, 'N' to exit this script)

The -i option initializes a client. The -d option specifies the new NIS+ domain name. (If the domain name is not specified, the default becomes the current domain name.) The -h option specifies the NIS+ server's host name.

See How to Initialize a New Client Machine for the rest of this script's output.

Initializing Subdomain NIS+ Client Users

You use the same procedure (nisclient) to initialize a user in the new domain as you do to initialize a user in the root domain. All users must make themselves NIS+ clients. This example shows you only what you would type to initialize a user for the new domain. For the rest of the script's output, see How to Initialize an NIS+ User.

Prerequisites to Running nisclient

Before you can use the nisclient script to initialize a user:

Information You Need

You need:

How to Initialize an NIS+ Subdomain User

    To become an NIS+ client, type the following command while logged in as the user.


user2prompt% nisclient -u
At the prompt below, type the network password (also known as the 
Secure-RPC password) that you obtained either from your administrator 
or from running the nispopulate script.
Please enter the Secure-RPC password for user2:

See How to Initialize an NIS+ User for the rest of this script's output.

Summary of Commands for the Sample NIS+ Namespace

Table 4–4 summarizes the actual commands that you typed to create the sample namespace. The prompt preceding each command indicates on which machine the command should be typed.

Table 4–4 Creating the Sample Namespace: Command Summary

Tasks 

Commands 

Set environment path to include /usr/lib/nis—C shell or Bourne shell.

# setenv PATH $PATH:/usr/lib/nis

or 

# PATH=$PATH:/usr/lib/nis; export PATH

Optionally configure Diffie-Hellman key length. 

master1# nisauthconf dh640-0 des

Create root master server for doc.com. domain.

master1# nisserver -r -d doc.com.

Populate the root master server's NIS+ tables—from files or from NIS maps. 

master1# nispopulate -F -p /nis+files -d doc.com.

or 

master1# nispopulate -Y -d doc.com. -h salesmaster -a \ 130.48.58.111 -y sales.doc.com.

Add additional members to the admin group (2). 

master1# nisgrpadm -a admin. doc.com. topadmin.doc.com. \ secondadmin.doc.com.

Make a checkpoint of the NIS+ database. 

master1# nisping -C org_dir. doc.com.

Optionally configure Diffie-Hellman key length. 

client1# nisauthconf dh640-0 des

Initialize an NIS+ client machine in the doc.com. domain. 

client1# nisclient -i -d doc.com. -h master1

Initialize user as an NIS+ client. 

client1user1prompt% nisclient -u

Convert NIS+ client to NIS+ server, without or with NIS compatibility or with NIS and DNS. 

client1#rpc.nisd

or 

client1# rpc.nisd -Y

or 

client1# rpc.nisd -Y -B

Create a root replica. 

master1# nisserver -R -d doc.com. -h client1

Convert a server to a non-root master server of the sales.doc.com. domain.

master1# nisserver -M -d sales.doc.com. -h client2

Populate the new master server's NIS+ tables—from files or from NIS maps. 

client2# nispopulate -F -p /nis+files -d sales.doc.com.

or 

client2# nispopulate -Y -d sales.doc.com. -h \ businessmachine -a 130.48.58.242 -y business.doc.com.

Create a master server replica. 

client2# nisserver -R -d sales.doc.com. -h client3

Initialize an NIS+ client in the sales.doc.com.. domain.

subclient1# nisclient -i -d sales.doc.com. -h client2

Initialize user as an NIS+ client. 

subclient1user2prompt% nisclient -u

Chapter 5 Setting Up the Root Domain

This chapter provides step-by-step instructions for setting up the root domain and DES authentication using the NIS+ command set.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the SolarisTM 9 operating environment. (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


Introduction to Setting Up the Root Domain

This task describes how to configure the root domain with the root master server running at security level 2 (the normal level).


Note –

It is much easier to perform this task with the NIS+ installation scripts than with the NIS+ command set as described here. The methods described in this chapter should be used only by those administrators who are very familiar with NIS+ and who require some nonstandard features or configurations not provided by the installation scripts.


Setting up the root domain involves three major tasks:

However, setting up the root domain is not as simple as performing these three tasks in order; they are intertwined with one another. For instance, you must specify some security parameters before you create the root directory, the rest, after. To make the root domain easier to configure, this chapter separates these tasks into individual steps and arranges them into their most efficient order.

Standard Versus NIS-Compatible Configuration Procedures

The steps in this chapter apply to both a standard NIS+ root domain and an NIS-compatible root domain. There are, however, some important differences. The NIS+ daemon for an NIS-compatible domain must be started with the -Y option, which allows the root master server to answer requests from NIS clients. This is described in Step 11. The equivalent step for standard NIS+ domains is Step 12.

An NIS-compatible domain also requires read rights to the passwd table for the nobody class, which allows NIS clients to access the information stored in the table's passwd column. This is accomplished with the -Y option to the nissetup command, in Step 14. The standard NIS+ domain version uses the same command but without the -Y option.

Establishing the Root Domain

The procedure describes each step in detail and provides related information. For those who do not need detailed instructions, a summary listing of the necessary commands is provided on Root Domain Configuration Summary.

Summary of Steps

Here is a summary of the entire configuration process:

  1. Log in as superuser to the root master server.

  2. Check the root master server's domain name.

  3. Check the root master server's switch-configuration file.

  4. Optionally, configure the Diffie-Hellman key length.

  5. Clean out leftover NIS+ material and processes.

  6. Name the root domain's admin group.

  7. Create the root directory and initialize the root master server.

  8. [NIS-compatibility Only] Start the NIS+ daemon with -Y. [Standard NIS+ Only] Start the NIS+ daemon.

  9. Verify that the daemon is running.

  10. Create the root domain's subdirectories and tables.

  11. Create DES credentials for the root master server.

  12. Create the root domain's admin group.

  13. Add the root master to the root domain's admin group.

  14. Update the root domain's public keys.

  15. Start the NIS+ cache manager.

  16. Restart the NIS+ daemon with security level 2.

  17. Add your LOCAL credentials to the root domain.

  18. Add your DES credentials to the root domain.

  19. Add credentials for other administrators.

  20. Add yourself and other administrators to the root domain's admin group.

Establishing the Root Domain—Task Map

Table 5–1 Establishing the Root Domain

Task 

Description 

For Instructions, Go To 

Establishing the Root Domain 

Use the domainname command to establish the root domain. Optionally extend the Diffie-Hellman key length. Stop and start the ncsd daemon. Kill and restart keyserv. Clean out leftover NIS+ information.

How to Configure a Root Domain

Security Considerations

NIS+ provides preset security defaults for the root domain. The default security level is level 2. Operational networks with actual users should always be run at security level 2. Security levels 0 and 1 are for configuring and testing purposes only. Do not run an operational network at level 0 or 1.


Note –

The NIS+ security system is complex. If you are not familiar with NIS+ security, you might want to review Chapter 11, NIS+ Security Overviewbefore starting to configure your NIS+ environment.


Prerequisites

Before proceeding, make sure that:

Information You Need

In order to complete this task you need to know:

How to Configure a Root Domain

  1. Log in as superuser on the machine designated to be the root master server.

    The examples in these steps use rootmaster as the root master server and doc.com. as the root domain.

  2. Check the root master server's domain name.

    Use the domainname command to make sure the root master server is using the correct domain name. The domainname command returns a machine's current domain name.


    Caution – Caution –

    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 applies to subdomains; for example, if you have a machine named west, you don't want to create a sales.west.myco.com subdirectory.


    If the name is not correct, change it.


    rootmaster# domainname 
    strange.domain
    rootmaster# domainname doc.com
    rootmaster# domainname
    rootmaster# doc.com
    rootmaster# rm -f /etc/defaultdomain
    rootmaster# domainname > /etc/defaultdomain
    

    (Do not include a trailing dot with the domainname command. The domainname command is not an NIS+ command, so it does not follow the NIS+ conventions of a trailing dot.)

    The above example changes the domain name of the root master server from strange.domain to doc.com. When changing or establishing a domain name, make sure that it has at least two elements; for example, doc.com instead of doc. The final element should end in either an Internet organizational name (such as .com) or a geographical identifier (such as .jp or .uk).

  3. Check the root master server's switch-configuration file.

    Make sure the root master server is using the NIS+ version of the nsswitch.conf file, even if it will run in NIS-compatibility mode. This step ensures that the primary source of information for the root master are NIS+ tables.


    rootmaster# more /etc/nsswitch.conf

    This command displays the current nsswitch.conf file. The primary name service referenced by this file should be nisplus. If the root master server's configuration file does not use nisplus as the primary name service, exchange it for one that does, as explained in Selecting a Different Configuration File.

  4. Optionally, configure the Diffie-Hellman key length.

    If you are using DES authentication, you can elect to increase the Diffie-Hellman key length from the default 192 bits. For example, to allow both 640 and 192–bit keys type the following:


    rootmaster# nisauthconf dh640-0 des
  5. If you made any changes at all to the nsswitch.conf file, stop and restart the nscd daemon.

    Because nscd caches the contents of the nsswitch.conf file, it is necessary to stop and restart nscd after any change to the switch file.

    Complete instructions are provided in Chapter 1, The Name Service Switch.

  6. Now kill and restart keyserv, as shown below.


    rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
    rootmaster# sh /etc/init.d/nscd stop
    rootmaster# sh /etc/init.d/nscd start
    rootmaster# ps -e | grep keyserv
     root 145 1 67 16:34:44 ? keyserv
     .
     .
    rootmaster# kill -9 145
    rootmaster# rm -f /etc/.rootkey
    rootmaster# keyserv
  7. Clean out leftover NIS+ material and processes.

    If the machine you are working on was previously used as an NIS+ server or client, remove any files that might exist in /var/nis and kill the cache manager, if it is still running. In this example, a cold-start file and a directory cache file still exist in /var/nis:


    rootmaster# ls /var/nis 
    NIS_COLD_START NIS_SHARED_CACHE
    rootmaster# rm -rf /var/nis/*
    rootmaster# ps -ef | grep nis_cachemgr
     root 295 260 10 15:26:58 pts/0 0:00 grep nis_cachemgr
     root 286 1 57 15:21:55 ? 0:01 /usr/sbin/nis_cachemgr
    rootmaster# kill -9 286

    This step makes sure files left in /var/nis or directory objects stored by the cache manager are completely erased so they do not conflict with the new information generated during this configuration process. If you have stored any admin scripts in /var/nis, you might want to consider temporarily storing them elsewhere, until you finish setting up the root domain.

  8. Kill server daemons

    If the machine you are working on was previously used as an NIS+ server, check to see if rpc.nisd or rpc.nispasswdd is running. If either of these daemons is running, kill them.

  9. Name the root domain's admin group.

    Although you won't actually create the admin group until Step 16, you must identify it now. Identifying it now ensures that the root domain's org_dir directory object, groups_dir directory object, and all its table objects are assigned the proper default group when they are created in Step 14.

    To name the admin group, set the value of the environment variable NIS_GROUP to the name of the root domain's admin group. Here are two examples, one for csh users, and one for sh/ksh users. They both set NIS_GROUP to admin.doc.com..

    For C Shell


    rootmaster# setenv NIS_GROUP admin.doc.com.

    For Bourne or Korn Shell


    rootmaster# NIS_GROUP=admin.doc.com.
    rootmaster# export NIS_GROUP
  10. Create the root directory and initialize the root master server.

    This step creates the first object in the namespace—the root directory—and converts the machine into the root master server. Use the nisinit -r command, as shown below. (This is the only instance in which you will create a domain's directory object and initialize its master server in one step. In fact, nisinit -r performs an automatic nismkdir for the root directory. In any case, except the root master, these two processes are performed as separate tasks.)


    rootmaster# nisinit -r 
    This machine is in the doc.com. NIS+ domain
    Setting up root server ...
    All done.

    A UNIX directory with the name /var/nis/data is created.

    Within the /var/nis directory is a file named root.object.


    rootmaster# ls -l /var/nis/data 
    -rw-rw-rw- 1 root other 384 date root.object

    This is not the root directory object; it is a file that NIS+ uses to describe the root of the namespace for internal purposes. The NIS+ root directory object is created in Step 11 or Step 12.

    In subsequent steps, other files are added beneath the directory created in this step. Although you can verify the existence of these files by looking directly into the UNIX directory, NIS+ provides more appropriate commands. They are called out where applicable in the following steps.


    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+ configuration procedures. In Solaris Release 2.4 and earlier, the /var/nis directory contained two files named hostname. It also contained a subdirectory named /var/nis/hostname. In Solaris Release 2.5, the two files are named trans.log and data.dict, and the subdirectory is named /var/nis/data. In Solaris Release 2.5, the content of the files has also been 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 Release 2.4 or the Solaris Release 2.5 version of rpc.nisd. Therefore, you should not rename either the directories or the files.


  11. [NIS-Compatibility only] Start the NIS+ daemon with -Y.

    Perform this step only if you are setting up the root domain in NIS-compatibility mode; if setting up a standard NIS+ domain, perform Step 12 instead. This step includes instructions for supporting the DNS forwarding capabilities of NIS clients.

    Substep a starts the NIS+ daemon in NIS-compatibility mode. Substep b makes sure that when the server is rebooted, the NIS+ daemon restarts in NIS-compatibility mode. After substep b of Step b, go to Step 14.

    1. Use rpc.nisd with the -Y, -B, and -S 0 options.


      rootmaster# rpc.nisd -Y -B -S 0 options
      

      The -Y option invokes an interface that answers NIS requests in addition to NIS+ requests. The -B option supports DNS forwarding. The -S 0 flag sets the server's security level to 0, which is required at this point for bootstrapping. Because no cred table exists yet, no NIS+ principals can have credentials; if you used a higher security level, you would be locked out of the server.

    2. Edit the /etc/init.d/rpc file.

      Search for the string EMULYP=”Y” in the /etc/init.d/rpc file. Uncomment the line and, to retain DNS forwarding capabilities, add the -B flag.

      An rpc file with DNS forwarding contains:


      EMULYP=”-Y -B”

      An rpc file without DNS forwarding contains:


      EMULYP=”-Y”

      If you do not need to retain DNS forwarding capabilities, uncomment the line but do not add the -B flag.

  12. [Standard NIS+ only] Start the NIS+ daemon.

    Use the rpc.nisd and be sure to add the -S 0 flag.


    rootmaster# rpc.nisd -S 0

    The -S 0 flag sets the server's security level to 0, which is required at this point for bootstrapping. Because no cred table exists yet, no NIS+ principals can have credentials, and if used with a higher security level, you would be locked out of the server.

  13. Verify that the root objects have been properly created.

    As a result of Step 11 or Step 12, your namespace should now have:

    • A root directory object (root.dir)

    • A root master server (rootmaster) running the NIS+ daemon (rpc.nisd)

    • A cold start file for the master server (NIS_COLD_START)

    • A transaction log file (trans.log)

    • A table dictionary file (data.dict).

    The root directory object is stored in the directory created in Step 10. Use the ls command to verify that it is there.


    rootmaster# ls -l /var/nis/data 
    -rw-rw-rw- 1 root other 384 date root.object
    -rw-rw-rw- 1 root other 124 date root.dir

    At this point, the root directory is empty; in other words, it has no subdirectories. You can verify this by using the nisls command.


    rootmaster# nisls -l doc.com.
    doc.com.:

    However, it has several object properties, which you can examine using niscat -o:


    rootmaster# niscat -o doc.com.
     Object Name : doc
    Owner : rootmaster.doc.com.
    Group : admin.doc.com.
    Domain : Com.
    Access Rights : r---rmcdrmcdr---

    Notice that the root directory object provides full (read, modify, create, and destroy) rights to both the owner and the group, while providing only read access to the world and nobody classes. (If your directory object does not provide these rights, you can change them using the nischmod command.)

    To verify that the NIS+ daemon is running, use the ps command.


    rootmaster# ps -ef | grep rpc.nisd
    root 1081 1 61 16:43:33 ? 0:01 rpc.nisd -S 0
    root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd

    The root domain's NIS_COLD_START file, which contains the Internet address (and, eventually, public keys) of the root master server, is placed in /var/nis. Although there is no NIS+ command that you can use to examine its contents, its contents are loaded into the server's directory cache (NIS_SHARED_DIRCACHE). You can examine those contents with the /usr/lib/nis/nisshowcache command.

    Also created are a transaction log file (trans.log) and a dictionary file (data.dict). The transaction log of a master server stores all the transactions performed by the master server and all its replicas since the last update. You can examine its contents by using the nislog command. The dictionary file is used by NIS+ for internal purposes; it is of no interest to an administrator.

  14. Create the root domain's subdirectories and tables.

    This step adds the org_dir and groups_dir directories, and the NIS+ tables, beneath the root directory object. Use the nissetup utility. For an NIS-compatible domain, be sure to include the -Y flag. Here are examples for both versions:

    For standard NIS+ only


    rootmaster# /usr/lib/nis/nissetup

    NIS-compatible only


    rootmaster# /usr/lib/nis/nissetup -Y

    Each object added by the utility is listed in the output:


    rootmaster# /usr/lib/nis/nissetup 
    org_dir.doc.com. created
    groups_dir.doc.com. created
    auto_master.org_dir.doc.com. created
    auto_home.org_dir.doc.com. created
    bootparams.org_dir.doc.com. created
    cred.org_dir.doc.com. created
    ethers.org_dir.doc.com. created
    group.org_dir.doc.com. created
    hosts.org_dir.doc.com. created
    mail_aliases.org_dir.doc.com. created
    sendmailvars.org_dir.doc.com. created
    netmasks.org_dir.doc.com. created
    netgroup.org_dir.doc.com. created
    networks.org_dir.doc.com. created
    passwd.org_dir.doc.com. created
    protocols.org_dir.doc.com. created
    rpc.org_dir.doc.com. created
    services.org_dir.doc.com. created
    timezone.org_dir.doc.com. created

    The -Y option creates the same tables and subdirectories as for a standard NIS+ domain, but assigns read rights to the passwd table to the nobody class so that requests from NIS clients, which are unauthenticated, can access the encrypted password in that column.

    Recall that when you examined the contents of the root directory with nisls (in Step 12), it was empty. Now, however, it has two subdirectories.


    rootmaster# nisls doc.com.
    doc.com.:
    org_dir
    groups_dir

    You can examine the object properties of the subdirectories and tables by using the niscat -o command. You can also use the niscat option without a flag to examine the information in the tables, although at this point they are empty.

  15. Create DES credentials for the root master server.

    The root master server requires DES credentials so that its own requests can be authenticated. To create those credentials, use the nisaddcred command, as shown below. When prompted, enter the server's root password.


    rootmaster# nisaddcred des 
    DES principal name: unix.rootmaster@doc.com
    Adding key pair for unix.rootmaster@doc.com
     (rootmaster.doc.com.).
    Enter login password:
    Wrote secret key into /etc/.rootkey

    If you enter a password that is different from the server's root password, you receive a warning message and a prompt to repeat the password:


    Enter login password:
    nisaddcred: WARNING: password differs from login password.
    Retype password:

    If you persist and retype the same password, NIS+ will still create the credential. The new password will be stored in /etc/.rootkey and be used by the keyserver when it starts up. To give the keyserver the new password right away, run keylogin -r, as described in Chapter 12, Administering NIS+ Credentials.

    If you decide to use your login password after all, press Control-c and start the sequence over. If you were to retype your login password as encouraged by the server, you would get an error message designed for another purpose, but which in this instance could be confusing.


    nisaddcred: WARNING: password differs from login password.
    Retype password:
    nisaddcred: password incorrect.
    nisaddcred: unable to create credential.

    As a result of this step, the root server's private and public keys are stored in the root domain's cred table (cred.org_dir.doc.com.) and its secret key is stored in /etc/.rootkey. You can verify the existence of its credentials in the cred table by using the niscat command. Since the default domain name is doc.com., you don't have to enter the cred table's fully qualified name; the org_dir suffix is enough. You can locate the root master's credential by looking for its secure RPC netname.

  16. Create the root domain's admin group.

    This step creates the admin group named in Step 9. Use the nisgrpadm command with the -c option. The example below creates the admin.doc.com. group.


    rootmaster# nisgrpadm -c admin.doc.com.
     Group admin.doc.com. created.

    This step only creates the group—it does not identify its members. That is done in Step 17. To observe the object properties of the group, use niscat -o, but be sure to append groups_dir in the group's name.


    doc.com. 
    Object Name : admin
    Directory : groups_dir.doc.com
    Owner : rootmaster.doc.com.
    Group : admin.doc.com.
    Domain : groups_dir.doc.com.
    Access Rights : ----rmcdr---r---
    Time to Live : 1:0:0
    Object Type : GROUP
    Group Flags :
    Group Members :
  17. Add the root master to the root domain's admin group.

    Since at this point the root master server is the only NIS+ principal that has DES credentials, it is the only member you should add to the admin group. Use the nisgrpadm command again, but with the -a option. The first argument is the group name, the second is the name of the root master server. This example adds rootmaster. doc.com. to the doc.com domain.


    rootmaster# nisgrpadm -a admin.doc.com.
     rootmaster.doc.com.
    Added rootmaster.doc.com. to group admin.doc.com.

    To verify that the root master is indeed a member of the group, use the nisgrpadm command with the -l option (see Chapter 17, Administering NIS+ Groups).


    Note –

    With group-related commands such as nisgrpadm, you don't have to include the groups_dir subdirectory in the name. You need to include that directory with commands like niscat because they are designed to work on NIS+ objects in general. The group-related commands are “targeted” at the groups_dir subdirectory.



    rootmaster# nisgrpadm -l admin.doc.com.
     Group entry for admin.doc.com. group:
     Explicit members:
     rootmaster.doc.com.
     No implicit members
     No recursive members
     No explicit nonmembers
     No implicit nonmembers
     No recursive nonmembers
  18. Update the root domain's public keys.

    Normally, directory objects are created by an NIS+ principal that already has DES credentials. In this case, however, the root master server could not acquire DES credentials until after it created the cred table (since there was no parent domain in which to store its credentials). As a result, three directory objects—root, org_dir, and groups_dir—do not have a copy of the root master server's public key. (You can verify this by using the niscat -o command with any of the directory objects. Look for the public key field. Instructions are provided inChapter 18, Administering NIS+ Directories.)

    To propagate the root master server's public key from the root domain's cred table to those three directory objects, use the /usr/lib/nis/nisupdkeys utility for each directory object.


    rootmaster# /usr/lib/nis/nisupdkeys doc.com.
    rootmaster# /usr/lib/nis/nisupdkeys org_dir.doc.com.
    rootmaster# /usr/lib/nis/nisupdkeys groups_dir.doc.com.

    After each instance, you will receive a confirmation message such as this one:


    Fetch Public key for server rootmaster.doc.com.
     netname = 'unix.rootmaster@doc.com.'
    Updating rootmaster.doc.com.'s public key.
     Public key:

    If you look in any of those directories (use niscat -o), you can find one or more entries like the following in the public key field:


    Public key: Diffie-Hellman (192 bits)
  19. Start the NIS+ cache manager.

    The cache manager maintains a local cache of location information for an NIS+ client (in this case, the root master server). It obtains its initial set of information from the client's cold-start file (created in Step 11 or Step 12), and downloads it into a file named NIS_SHARED_DIRCACHE in /var/nis.

    To start the cache manager, enter the nis_cachemgr command as shown below.


    rootmaster# nis_cachemgr

    After the cache manager has been started, you have to restart it only if you have explicitly killed it. You don't have to restart it if you reboot, since the NIS_COLD_START file in /var/nis starts it automatically when the client is rebooted.

  20. Restart the NIS+ daemon with security level 2.

    Now that the root master server has DES credentials and the root directory object has a copy of the root master's public key, you can restart the root master with security level 2. First kill the existing daemon, then restart with security level 2.

    For a standard NIS+ domain only:


    rootmaster# ps -e | grep rpc.nisd
    1081 ? 0:03 rpc.nisd -s 0
    rootmaster# kill 1081
    rootmaster# rpc.nisd

    For an NIS-compatible root domain, be sure to use the -Y (and -B) flags:

    For an NIS-compatible NIS+ domain:


    rootmaster# ps -e | grep rpc.nisd
    1081 ? 0:03 rpc.nisd -Y -B -s 0
    rootmaster# kill 1081
    rootmaster# rpc.nisd -Y -B

    Since security level 2 is the default, you don't need to use an -S 2 flag.


    Note –

    Operational networks with actual users should always be run at security level 2. Security levels 0 and 1 are for configuration and testing purposes only. Do not run an operational network at level 0 or 1.


  21. Add your LOCAL credentials to the root domain.

    Because you don't have access rights to the root domain's cred table, you must perform this operation as superuser. In addition, the root master's /etc/passwd file must contain an entry for you. Use the nisaddcred command with the -p and -P flags as shown below.


    nisaddcred -p uid -P principal-name local

    The principal-name consists of the administrator's login name and domain name. This example adds a LOCAL credential for an administrator with a UID of 11177 and an NIS+ principal name of topadmin.doc.com.


    rootmaster# nisaddcred -p 11177 -P topadmin.doc.com. local

    For more information about the nisaddcred command, see Chapter 12, Administering NIS+ Credentials.

  22. Add your DES credentials to the root domain.

    Use the nisaddcred command again, but with the following syntax:


    nisaddcred -p secure-RPC-netname- P principal-name des

    The secure-RPC-netname consists of the prefix unix followed by your UID, the symbol @, and your domain name, but without a trailing dot. The principal-name is the same as for LOCAL credentials: your login name followed by your domain name, with a trailing dot.


    rootmaster# nisaddcred -p unix.11177@doc.com -P topadmin.doc.com. des
    Adding key pair for unix.11177@doc.com (topadmin.doc.com.).
    Enter login password:

    If, after entering your login password, you get a password that differs from the login password warning, yet the password you entered is your correct login password, ignore the error message. The message appears because NIS+ cannot read the protected /etc/shadow file that stores the password, as expected. The message would not have appeared if you had no user password information stored in the /etc/passwd file.

  23. Add credentials for the other administrators.

    Add the credentials, both LOCAL and DES, of the other administrators who will work in the root domain. You can do this in the following ways.

    • An easy way to create temporary credentials for the other administrators is to use Solstice AdminSuite (if you have it available) running in NIS+ mode.

    • A second way is to ask them to add their own credentials. However, they will have to do this as superuser. Here is an example that adds credentials for an administrator with a UID of 33355 and a principal name of miyoko.doc.com.


      rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local 
      rootmaster# nisaddcred -p unix.33355@doc.com -P miyoko.doc.com. des 
      Adding key pair for unix.33355@doc.com (miyoko.doc.com.).
       Enter login password:
    • A third way is for you to create temporary credentials for the other administrators, using dummy passwords. (Note that the other administrator, in this example miyoko, must have an entry in the NIS+ passwd table. If no such entry exists, you must first create one with nistbladm. The example below includes that step.)


      rootmaster# nistbladm -D owner=miyoko.doc.com. name=miyoko uid=33355 gcos=miyoko 
      home=/home/miyoko shell=/bin/tcsh passwd.org_dir
      rootmaster# nisaddent -a -f /etc/passwd.xfr passwd 
      rootmaster# nisaddent -a -f /etc/shadow.xfr shadow
      rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local
      rootmaster# nisaddcred -p unix.33355@doc.com -P miyoko.doc.com. des
      Adding key pair for unix.33355@doc.com (miyoko.doc.com.).
      Enter miyoko's login password:
      nisaddcred: WARNING: password differs from login passwd.
      Retype password:
      rootmaster# nischown miyoko.doc.com. '[name=miyoko],passwd.org_dir'

      In this case, the first instance of nisaddent populates the passwd table—except for the password column. The second instance populates the shadow column. Each administrator can later change his or her network password using the chkey command. Chapter 12, Administering NIS+ Credentialsdescribes how to do this.

  24. Add yourself and other administrators to the root domain's admin group.

    You don't have to wait for the other administrators to change their dummy passwords to perform this step. Use the nisgrpadm command with the -a option. The first argument is the group name, the remaining arguments are the names of the administrators. This example adds two administrators, topadmin and miyoko, to the admin.doc.com. group:


    rootmaster# nisgrpadm -a admin.doc.com. topadmin.doc.com. miyoko.doc.com.
    Added topadmin.doc.com. to group admin.doc.com.
    Added miyoko.doc.com. to group admin.doc.com.
  25. Allocate sufficient swap space to accommodate NIS+ tables.

    Swap space should be double the size of the maximum size of rpc.nisd. To determine how much memory rpc.nisd is using, issue the following command:


    rootmaster# /usr/lib/nis/nisstat

    rpc.nisd will under certain circumstances fork a copy of itself. If there is not enough memory, rpc.nisd fails.

    You can also calculate the memory and swap space requirements for NIS+ tables. For example, if you have 180,000 users and 180,000 hosts in your NIS+ tables, those two tables occupy approximately 190 Mbytes of memory. When you add credentials for 180,000 users and 180,000 hosts, the cred table has 540,000 entries (one entry for each local user credential, one entry for each DES user credential, and one entry for each host). The cred table occupies approximately 285 Mbytes of memory. In this example, rpc.nisd occupies at least 190 Mbytes + 285 Mbytes = 475 Mbytes of memory. So, you will require at least 1 Gbyte swap space. You will also want at least 500 Mbytes of memory to hold rpc.nisd entirely in memory.

Root Domain Configuration Summary

Table 5–2 summarizes the steps required to configure a root domain. The summary assumes a simple case. Be sure you are familiar with the complete task descriptions before you use this summary as a reference. This summary does not show the server's responses to each command.

Table 5–2 Setting Up a Root Domain: Command Summary

Tasks 

Commands 

Log in as superuser to rootmaster.

rootmaster% su

Password:

Check domain name 

# domainname

Check Switch file. 

# more /etc/nsswitch.conf

Remove leftover NIS+ material. 

# rm -rf /var/nis*

Name the admin group. 

# NIS_GROUP=admin.doc.com.; export NIS_GROUP

Initialize the root master. 

# nisinit -r

[NIS-compat only] 

Start daemon with -Y -B, S 0.

Change to EMULYP=-Y -B.

# rpc.nisd -Y -B -S 0

# vi /etc/inet.d/rpc

[NIS+ Only] Start daemon with -S 0.

# rpc.nisd -S 0

Create org_dir and groups_dir tables.

# /usr/lib/nis/nissetup [-Y]

Create DES credentials for root master. 

#nisaddcred des

Enter login password:

Create admin group.

# nisgrpadm -c admin.doc.com.

Assign full group rights to root directory 

# nischmod g+rmcd doc.com.

Add rootmaster to admin group.

# nisgrpadm -a admin.doc.com. rootmaster.doc.com.

Update root directory's keys. Update org_dir's keys. Update groups_dir's keys.

# /usr/lib/nis/nisupdkeys doc.com.

# /usr/lib/nis/nisupdkeys org_dir.doc.com.

# /usr/lib/nis/nisupdkeys groups_dir.doc.com.

Start NIS+ cache manager 

# nis_cachemgr

Kill existing daemon. 

# ps -ef | grep rpc.nisd

# kill -9 process-id

Restart the NIS+ daemon. (Use -Y for NIS compat and -B for DNS.)

# rpc.nisd [-Y] [-B]

Add your LOCAL credentials. 

# nisaddcred -p 11177 -P topadmin.doc.com. local

Add your DES credentials. 

# nisaddcred -p unix.11177@doc.com -P topadmin.doc.com. des Enter login password:

Add credentials for other admins. 

Add other admins to admin group.

# nisaddcred ... nisgrpadm -a admin.doc.com members

Chapter 6 Configuring NIS+ Clients

This chapter gives step-by-step instructions for setting up NIS+ clients using the NIS+ command set and three different initialization methods. These instructions apply to clients in both the root domain and subdomains, whether all-NIS+ or NIS-compatible.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


Introduction to Setting Up NIS+ Clients

This chapter describes how to configure clients in both standard NIS+ domains and NIS-compatible domains. The procedure describes each step in detail and provides related information. For those who do not need detailed instructions, a summary listing of the necessary commands is provided in Table 6–6.


Note –

It is much easier to perform this task with the NIS+ installation scripts, as described in Part 1, than with the NIS+ command set as described here. The methods described in this chapter should only be used by those administrators who are very familiar with NIS+ and who require some non-standard features or configurations not provided by the installation scripts. If you have them available, the Solstice AdminSuiteTM tools also provide easier methods of adding and setting up NIS+ client machines.


At Step 10 in the client configuration instructions you must choose which of three methods to use: broadcast, host name, or cold-start file. Because each method is implemented differently, each has its own task description. After initializing a client by one of these methods, you can continue setting up the client by returning to Step 11.

The last task in the chapter describes how to change a machine's domain.

Configuring the Client

This section describes how to configure a typical NIS+ client in either the root domain or a non-root domain. This procedure applies to regular NIS+ clients and to those clients that will later become NIS+ servers. It applies, as well, to clients in a standard NIS+ domain and those in an NIS-compatible domain.


Caution – Caution –

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 applies to subdomains; for example, if you have a machine named west you do not want to create a sales.west.myco.com subdomain.


Setting up an NIS+ client involves the following tasks:

However, as with setting up the root domain, setting up a client is not as simple as carrying out these three tasks in order. To make the configuration process easier to execute, these tasks have been broken down into individual steps, and the steps have been arranged in the most efficient order:

  1. Logging in to the domain's master server

  2. Creating DES credentials for the new client machine

  3. Ascertaining the Diffie-Hellman key length used on the master server

  4. Logging in as superuser to the client

  5. Assigning the client its new domain name

  6. Stopping and restarting nscd

  7. Checking the client's nsswitch.conf file

  8. Setting the client's Diffie-Hellman key

  9. Cleaning out leftover NIS+ material and processes

  10. Initializing the client

  11. Killing and restarting the keyserv daemon

  12. Running keylogin

  13. Rebooting the client

Security Considerations

Setting up a client has two main security requirements: both the administrator and the client must have the proper credentials and access rights. Otherwise, the only way for a client to obtain credentials in a domain running at security level 2 is for the credentials to be created by an administrator with valid DES credentials and modify rights to the cred table in the client's home domain. The administrator can either have DES credentials in the client's home domain or in the administrator's home domain.

After an administrator creates the client's credentials, the client can complete the configuration process. However, the client still needs read access to the directory object of its home domain. If you configured the client's home domain according to the instructions in either Chapter 5, Setting Up the Root Domain or Chapter 8, Configuring a Non-Root Domain, read access was provided to the world class by the NIS+ commands used to create the directory objects (nisinit and nismkdir, respectively).

You can check the directory object's access rights by using the niscat-o command. This command displays the properties of the directory, including its access rights:


rootmaster# niscat -o doc.com.
ObjectName : Doc
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdr---r---

You can change the directory object's access rights, provided you have modify rights to it yourself, by using the nischmod command, described in Chapter 15, Administering NIS+ Access Rights.

Prerequisites

The administrator setting up the client's credentials must have:

The client must have:

Information You Need

Configuring the Client—Task Map

Table 6–1 Configuring the Client

Task 

Description 

For Instructions, Go To 

Configuring the Client” 

Create credentials fpr the client. Prepare the client machine and initialize it as an NIS+ client. 

How to Configure an NIS+ Client

How to Configure an NIS+ Client

  1. Log into the domain's master server.

    You can log in as superuser or as yourself, depending on which NIS+ principal has the proper access rights to add credentials to the domain's cred table.

  2. Create DES credentials for the new client machine.

    Use the nisaddcred command with the -p and -P arguments. Here is the syntax:


    nisaddcred -p secure-RPC-netname  principal-name des [domain]

    The secure-RPC-netname consists of the prefix unix followed by the client's host name, the symbol @ and the client's domain name, but without a trailing dot. The principal-name consists of the client's host name and domain name, with a trailing dot. If the client belongs to a different domain than the server from which you enter the command, append the client's domain name after the second argument.

    This example adds a DES credential for a client machine named client1 in the doc.com. domain:


    rootmaster% nisaddcred -p unix.client1@doc.com -P client1.doc.com. des 
    Adding key pair for unix.client1@doc.com (client1.doc.com.).
    Enter client1.doc.com.'s root login passwd:
    Retype password:

    For more information about the nisaddcred command, see Chapter 12, Administering NIS+ Credentials.

  3. Ascertain the Diffie-Hellman key length used on the master server.

    For example:


    rootmaster% nisauthconf dh640-0 des
  4. Log in as superuser to the client.

    Now that the client machine has credentials, you can log out of the master server and begin working from the client itself. You can do this locally or remotely.

  5. Assign the client its new domain name.

    See Changing a machine's Domain Name for information on how to assign (or change) a client's domain name, then return to Step 6.

  6. Check the client's nsswitch.conf file.

    Make sure the client is using an NIS+ version of the nsswitch.conf file. This ensures that the primary source of information for the client will be NIS+ tables. See Example 1–1 for a description of an NIS+ switch file.

  7. If you made any changes to the nsswitch.conf file (or copied over a new file), you must now stop and restart nscd, as shown below.


    client1# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
    client1# sh /etc/init.d/nscd stop
    client1# sh /etc/init.d/nscd start

    (You do not need to kill and restart the keyserver at this point, as you will do so in Step 11.)

  8. Set the Diffie-Hellman key length on the client, using the information from step 3.

    For example:


    client# nisauthconf dh640-0 des
  9. Clean out leftover NIS+ material and processes.

    If the machine you are working on was previously used as an NIS+ server or client, remove any files that might exist in /var/nis and kill the cache manager, if it is still running. In this example, a cold-start file and a directory cache file still exist in /var/nis.


    client1# ls /var/nis
    NIS_COLD_START NIS_SHARED_CACHE
    client1# rm -rf /var/nis/*
    client1# ps -ef | grep nis_cachemgr
     root 295 260 10 15:26:58 pts/0 0:00 grep nis_cachemgr
     root 286 1 57 15:21:55 ? 0:01 /usr/sbin/nis_cachemgr
    client1# kill -9 286

    This step makes sure that files left in /var/nis or directory objects stored by the cache manager are completely erased so that they do not conflict with the new information generated during this configuration process. If you have stored any admin scripts in /var/nis, you might want to consider temporarily storing them elsewhere, until you finish setting up the root domain.

  10. Initialize the client.

    You can initialize a client in three different ways: by host name, by cold-start file, or by broadcast. Choose and perform one of those methods. After initializing the client, proceed with Step 11.

  11. Kill and restart the keyserv daemon.

    This step stores the client's secret key on the keyserver.

    1. Kill the keyserv daemon.

      This also has the side effect of updating the key server's switch information about the client.

    2. Remove the /etc/.rootkey file.

    3. Restart the keyserver.

      This example shows the complete procedure in Step 11.


      client1# ps -e | grep keyserv
       root 145 1 67 16:34:44 ? keyserv
      client1# kill 145
      client1# rm -f /etc/.rootkey
      client1# keyserv
    4. Run keylogin-r.

      This step stores the client's secret key with the keyserver. It also saves a copy in /etc/.rootkey, so that the superuser on the client does not have to run keylogin to use NIS+. Use keylogin with the -r option. When prompted for a password, type the client's superuser password. It must be the same as the password supplied to create the client's DES credentials:


      client1# keylogin -r 
      Password:
      Wrote secret key into /etc/.rootkey
    5. Reboot the client.

Setting Up DNS Forwarding

To enable DNS forwarding capabilities on an NIS+ client:
  1. Login as superuser.

  2. Properly configure the hosts line in the /etc/resolve.conf file to read: hosts:nisplus dns files.

In this implementation of NIS, if a /etc/resolve.conf file exists on the server, ypstart automatically starts the ypserv daemon with the -d option to forward requests to DNS. (To stop forwarding to DNS, edit the /usr/lib/netsvc/yp/ypstart script to remove the -d option from the ypserv command. You must then reboot the machine.)

Changing a machine's Domain Name

This task changes a machine's domain name. Since a machine's domain name is usually set during installation, you should check it (type domainname without an argument) before you decide to perform this task.

Security Considerations

You must perform this task as superuser on the machine whose domain name you are changing.

Information You Need

Changing a machine's Domain—Task Map

Table 6–2 Configuring the Client

Task 

Description 

For Instructions, Go To 

Changing a machine's Domain 

Use the domainname command to change the client machine domain

How to Change a Client's Domain Name

How to Change a Client's Domain Name

  1. Log in to the machine and become superuser.

    The examples in this task use client1 as the machine and doc.com. as the new domain name.


    client1% su
    Password:
  2. Change the machine's domain name.

    Type the new name after the domainname command. Do not use a trailing dot. For example, to change a machine's domain to the doc.com domain, you enter:


    client1# domainname doc.com

    If the machine had been an NIS client, it may no longer be able to get NIS service.

  3. Verify the result.

    Run the domainname command again, this time without an argument, to display the server's current domain.


    client1# domainname
    doc.com
  4. Save the new domain name.

    Redirect the output of the domainname command into the /etc/defaultdomain file.


    client1# domainname > /etc/defaultdomain
  5. At a convenient time, reboot the machine.

    Even after entering the new domain name into the /etc/defaultdomain file, some processes may still operate with the old domain name. To ensure that all processes are using the new domain name, reboot the machine.

    Because you may be performing this task in a sequence of many other tasks, examine the work remaining to be done on the machine before rebooting. Otherwise, you might find yourself rebooting several times instead of just once.

    Although restarting individual daemons, such as mountd may solve an NFS problem, it is strongly recommended that you reboot to synchronize configuration changes across daemons. This minimizes application failures caused by unknown changes to the configuration.

Initializing an NIS+ Client

The three different ways to initialize an NIS+ client are:

Broadcast Initialization

This method initializes an NIS+ client by sending an IP broadcast on the client's subnet.

This is the simplest way to configure a client but is also the least secure. The NIS+ server that responds to the broadcast sends the client all the information that the client needs in its cold-start file, including the server's public key. Presumably, only an NIS+ server will respond to the broadcast. However, the client has no way of knowing whether the machine that responded to the broadcast is indeed a trusted server. As a result, this method is only recommended for sites with small, secure networks.

Security Considerations

You must perform this task as superuser on the client.

Prerequisites

At least one NIS+ server must exist on the same subnet as the client. The client must use the same Diffie-Hellman key lengths as those on the master server. See nisauthconf(1M).

Information You Need

You need the superuser password to the client.

Initializing an NIS+ Client—Task Map

Table 6–3 Initializing an NIS+ Client

Task 

Description 

For Instructions, Go To 

Initializing an NIS+ Client 

Use nisclient command to initialize an NIS+ client

How to Configure an NIS+ Client

How to Initialize a Client—Broadcast Method

    Initialize the client.

This step initializes the client and creates a NIS_COLD_START file in its /var/nis directory. Use the nisinit command with the -c and -B options.


client1# nisinit -c -B
This machine is in the doc.com. NIS+ domain.
Setting up NIS+ client ...
All done.

An NIS+ server on the same subnet will reply to the broadcast and add its location information into the client's cold-start file.

Initializing a Client by Host Name

Initializing a client by host name consists of explicitly identifying the IP address of its trusted server. This server's name, location information, and public keys are then placed in the client's cold-start file.

This method is more secure than the broadcast method because it actually specifies the IP address of the trusted server, rather than relying on a server to identify itself. However, if a router exists between the client and the trusted server, it could intercept messages to the trusted IP address and route them to an untrusted server.

Security Considerations

You must perform this operation as superuser on the client.

Prerequisites

Information You Need

You need the name and IP address of the trusted server.

Initializing an NIS+ Client—Task Map

Table 6–4 Initializing an NIS+ Client

Task 

Description 

For Instructions, Go To 

Initializing a Client by Host Name  

Use nisinit command to initialize an NIS+ client by host name.

How to Initialize a Client—Host-name Method

How to Initialize a Client—Host-name Method

  1. Check the client's /etc/hosts or /etc/inet/ipnodes file.

    Make sure the client has an entry for the trusted server.

  2. Initialize the client.

    This step initializes the client and creates a NIS_COLD_START file in its /var/nis directory. Use the nisinit command with the -c and -H options. This example uses rootmaster as the trusted server.


    Client1# nisinit -c -H rootmaster
    This machine is in the doc.com. NIS+ domain.
    Setting up NIS+ client ...
    All done.

    The nisinit utility looks for the server's address in the client's /etc/hosts or /etc/inet/ipnodes file, so do not append a domain name to the server. If you do, the utility will not be able to find its address.

Initializing Client Using a Cold-Start File

This task initializes an NIS+ client by using the cold-start file of another NIS+ client, preferably one from the same domain. This is the most secure method of setting up an NIS+ client. It ensures that the client obtains its NIS+ information from a trusted server, something that cannot be guaranteed by the host-name or broadcast method.

Security Considerations

You must perform this task as superuser on the client.

Prerequisites

The servers specified in the cold-start file must already be configured and running NIS+.

The client must use the same Diffie-Hellman key lengths as those on the master server. See nisauthconf(1M).

Information You Need

You need the name and location of the cold-start file you will copy.

Initializing an NIS+ Client—Task Map

Table 6–5 Initializing an NIS+ Client

Task 

Description 

For Instructions, Go To 

InitializingClient via Cold-Start File 

Use nisinit command to initialize an NIS+ client via a cold-start file

How to Initialize a Client—Cold-Start Method

How to Initialize a Client—Cold-Start Method

  1. Copy the other client's cold-start file.

    Copy the other client's cold-start file into a directory in the new client. This may be easier to do while logged on as yourself rather than as superuser on the client. Be sure to switch back to superuser before initializing the client.

    Don't copy the NIS_COLD_START file into /var/nis, because that file gets overwritten during initialization. This example copies the cold-start file of previously initialized client1 into the /tmp directory of uninitialized client2.


    client2# exit
    client2% rcp client1:/var/nis/NIS_COLD_START /tmp
    client2% su
  2. Initialize the client from the cold-start file.

    Use the nisinit command with the -c and -C options.


    client2# nisinit -c  -C /tmp/NIS_COLD_START 
    This machine is in the doc.com. NIS+ domain.
    Setting up NIS+ client ...
    All done.

NIS+ Client Configuration Summary

Table 6–6 shows a summary of the steps required to configure a client named client1 in the doc.com domain. It assumes the simplest case, so be sure you are familiar with the more thorough task descriptions before you use this summary as a reference. For the sake of brevity, this summary does not show the responses to each command.

Table 6–6 Setting Up a Client: Command Summary

Tasks 

Commands 

Log in to domain's master. 

rootmaster%

Create DES credentials for client. 

rootmaster% nisaddcred -p unix.client1.doc.com -P client1.doc.com. des

Ascertain the Diffie-Hellman .key length. 

rootmaster% nisauthconf

Log in, as superuser, to the client. 

client1% su

Password:

Assign the client a domain name. 

client1# domainname doc.com

client1# domainname > /etc/defaultdomain

Check that the client's switch configuration file has the correct settings. 

client1# more /etc/nsswitch.conf

Set the Diffie-Hellman key length. 

client1# nisauthconf dh640-0 des

Clean out /var/nis.

client1# rm -rf /var/nis/*

Initialize the client. 

client1# nisinit -c -H rootmaster

Kill and restart the keyserver. 

client1# ps -ef | grep keyserv

client1# kill -9 process-id

client1# keyserv

Run keylogin on the client.

client1# keylogin -r password:

Reboot the client. 

client1# init 6

Chapter 7 Configuring NIS+ Servers

This chapter provides step-by-step procedures for using the NIS+ commands to set up NIS+ servers (except the root master) and add replica servers to existing NIS+ domains.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


Setting Up an NIS+ Server

It is much easier to perform this task with the NIS+ installation scripts than with the NIS+ command set described here. The methods described in this chapter should be used only by those administrators who are very familiar with NIS+ and who require some nonstandard features or configurations not provided by the installation scripts.

Standard Versus NIS-Compatible Configuration Procedures

The differences between setting up an NIS-compatible and a standard NIS+ server are the same as the differences between setting up standard and NIS-compatible root master servers (see Standard Versus NIS-Compatible Configuration Procedures). The NIS+ daemon for an NIS-compatible server must be started with the -Y option (and the -B option for DNS forwarding), which allows the server to answer requests from NIS clients. This is described in Step 2 (the equivalent step for standard NIS+ servers is Step 3).


Note –

Whenever rpc.nisd is started with either the -Y or -B option, a secondary daemon named rpc.nisd_resolv is spawned to provide name resolution. This secondary daemon must be separately killed whenever you kill the primary rpc.nisd daemon.


Here is a summary of the entire configuration process:

  1. Log in as superuser to the new replica server.

  2. [NIS-Compatibility Only] Start the NIS+ daemon with -Y.

  3. [Standard NIS+ Only] Start the NIS+ daemon.

Security Considerations


Note –

The NIS+ security system is complex. If you are not familiar with NIS+ security, you might want to reviewChapter 11, NIS+ Security Overview before starting to configure your NIS+ environment.


The security level at which you start the server determines the credentials that its clients must have. For instance, if the server is configured with security level 2 (the default), the clients in the domain it supports must have DES credentials. If you have configured the client according to the instructions in this book, the client has DES credentials in the proper domain, and you can start the server with security level 2.


Note –

Security level 0 is for administrator configuration and testing purposes only. Security level 1 is not supported. Do not use level 0 or 1 in any environment where ordinary users are doing their normal work. Operating networks should always be run at security level 2.


Prerequisites

Information You Need

You need the superuser password of the client that you will convert into a server.

How to Configure an NIS+ Server

While it is possible to have a master or replica server serving more than one domain, doing so is not recommended.

  1. Log in as superuser to the new replica server.

    The following steps assume that you rebooted the machine after you set it up as an NIS+ client, as instructed in Configuring the Client. Rebooting starts the cache manager, which is a recommended prerequisite to the following step. If you did not reboot the machine, restart the cache manager now, using nis_cachemgr.

  2. [NIS-Compatibility Only] Start the NIS+ daemon with -Y.

    Perform this step only if you are setting up the server in NIS-compatibility mode; if setting up a standard NIS+ server, perform Step 3 instead. This step also includes instructions for supporting the DNS forwarding capabilities of NIS clients.

    This step has two parts. The first part starts the NIS+ daemon in NIS-compatibility mode. The second part makes sure that when the server is rebooted, the NIS+ daemon restarts in NIS-compatibility mode.

    1. Run rpc.nisd with the -Y and -B flags.


      compatserver# rpc.nisd -Y -B

      The -Y option invokes an interface that answers NIS requests in addition to NIS+ requests. The -B option supports DNS forwarding.

    2. Edit the /etc/init.d/rpc file.

      Search for the string EMULYP=-Y in the /etc/init.d/rpc file and uncomment that line.

      To retain DNS forwarding capabilities, add a -B flag to the EMULYP=-Y line. (If you don't need to retain DNS forwarding capabilities, uncomment the line, but don't add the -B flag.)

      This step creates a directory called /var/nis/data and a transaction log file called trans.log, which is placed in /var/nis.


      compatserver# ls -F /var/nis
      NIS_COLD_START data/ trans.log data.dict

      The trans.log file is a transaction log. You can examine the contents of the transaction log by using the nislog command, described in The nislog Command.


      Caution – Caution –

      Do not move or rename the /var/nis or /var/nis/data directories. Do not move or rename the /var/nis/trans.log or /var/nis/data.dict files. If you are upgrading from Solaris Release 2.4 or earlier, the older /hostname subdirectory is automatically converted to /var/nis/data and the relevant files are converted as necessary. Do not change these new names after the conversion has occurred.


      Now this server is ready to be designated a master or replica of a domain, as described in Chapter 8, Configuring a Non-Root Domain. This step completes this task. A task summary is provided on Server Configuration Summary.

  3. [Standard NIS+ Only] Start the NIS+ daemon.

    Run the rpc.nisd command.


    server# rpc.nisd

    To verify that the NIS+ daemon is indeed running, use the ps command.


    server# ps -ef | grep rpc.nisd
    root 1081 1 16:43:33 ? 0:01 rpc.nisd
    root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd

    This step creates a directory called /var/nis/data and a transaction log file called trans.log which is placed in /var/nis.


    compatserver# ls -F /var/nis
    NIS_COLD_START data/ trans.log data.dict

    The compatserver.log file is a transaction log. You can examine the contents of the transaction log by using the nislog command, described in Chapter 18, Administering NIS+ Directories.


    Caution – Caution –

    Do not move or rename the /var/nis or /var/nis/data directories. Do not move or rename the /var/nis/trans.log or /var/nis/data.dict files. If you are upgrading from Solaris Release 2.4 or earlier, the older /hostname subdirectory will be automatically converted to /var/nis/data and the relevant files will also be converted as necessary. Do not change these new names after the conversion has occurred.


    Now this server is ready to be designated a master or replica of a domain, as described in Chapter 8, Configuring a Non-Root Domain. This step completes this task. A task summary is provided on Server Configuration Summary.

Adding a Replica to an Existing Domain

To have regularly available NIS+ service, you should always create one or more replica servers for each domain. Having replicas can also speed network-request resolution because multiple servers are available to handle requests.

For performance reasons, you should have no more than a few replicas per domain. If your network includes multiple subnets or different sites connected by a Wide Area Network (WAN), you might need additional replicas:

See Determining Server Requirements for more information on replica distribution and on how to determine the optimum number of replicas. To add a replica to an existing domain you must first configure the new replica, then load the NIS+ data set for your namespace.

The two ways to configure and load a new replica server are:

Using NIS+ Commands to Configure a Replica Server

This section describes how to add a replica server to an existing domain using the NIS+ command.

Security Considerations

The NIS+ principal performing this operation must have modify rights to the domain's directory object.

Prerequisites

Information You Need

Using NIS+ Commands to Configure a Replica Server-Task Map

Table 7–1 Using NIS+ Commands to Configure a Replica Server

Task 

Description 

For Instructions, Go To 

Setting Up an NIS+ Server 

Use NIS+ commands to set up an NIS+ server 

How to Configure a Replica Server With NIS+ Commands

How to Configure a Replica Server With NIS+ Commands

In this example, the master server is named master1, and the new replica is named replica2.

  1. Log in to the domain's master server.

  2. Make sure that rpc.nisd is running.

  3. Add the replica to the domain.

    Run the nismkdir command with the -s option. The example below adds the replica machine named replica2 to the doc.com.domain.


    master1# nismkdir -s replica2 doc.com. 
    master1# nismkdir -s replica2 org_dir.doc.com. 
    master1# nismkdir -s replica2 groups_dir.doc.com.

    When you run the nismkdir command on a directory object that already exists, it does not recreate the directory but modifies it, according to the flags you provide. In this case, the -s flag assigns the domain an additional replica server. You can verify that the replica was added by examining the directory object's definition, using the niscat -o command.


    Caution – Caution –

    Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replicas.


    Your new replica is now configured. You can now load your NIS+ data set on to the replica. You can do this in two ways:

    • nisping. If you do nothing, your master server will use the nisping command to load your namespace data on to your newly configured replica server. If your namespace is large, this process can take hours. During this process, requests for naming information can be delayed. See Using nisping to Load Data on to a Replica Server for details.

    • Backup and restore. You can interrupt the transfer of data via nisping and use the NIS+ backup and restore capabilities to load your namespace data on to a newly configured replica server, as described in Using nisrestore to Load Data on to a Replica Server. Because it is so much faster and more efficient, this is the preferred method.

Using nisrestore to Load Data on to a Replica Server

This section describes how to use the NIS+ backup and restore utilities to load namespace data on to a newly configured replica. This is the preferred method of loading data on to a replica.

Security Considerations

The NIS+ principal performing this operation must have modify rights to the domain's directory object.

Prerequisites

Using nisrestore to Load Data on to a Replica Server — Task Map

Table 7–2 Using nisrestore to Load Data on to a Replica Server

Task 

Description 

For Instructions, Go To 

Using nisrestore to Load Data on to a Replica Server

Use the nisrestore command to load data on to a replica server

How to Load Namespace Data—nisrestore Method

How to Load Namespace Data—nisrestore Method

In this example, the master server is named master1, and the new replica is named replica2.

  1. Kill rpc.nisd on the new replica server.

    This interrupts the automatic transfer of namespace data from the master to the replica with the nisping command.

  2. Perform an NIS+ backup on the master server.

    This step is described in more detail in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). The example below shows how to use the nisbackup command to backup up the master1 server to the /var/master1_bakup directory.


    master1# nisbackup -a /var/master1_bakup

    The most convenient method of using nisrestore to configure a new replica is to back up the master's data to an NFS mounted directory that the new replica can access. This example assumes that both the master and the new replica server have access to the /var/master1_bakup directory.

    Another method is to use the tar command to copy the data from the /var/master1_bakup directory to some transferable storage media, such as a tape cartridge, then copy the data from storage media into a directory mounted on the new replica, then use that directory as the source for the nisrestore command, as described in Step 3.

  3. Download the NIS+ data set onto the new replica using the nisrestore command.

    This step is described in more detail in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). The example below shows how to use the nisrestore command to down load NIS+ data on to the client2 replica from the /var/master1_bakup directory.


    replica2# nisrestore -a /var/master1_bakup

    If the replica you are creating is for the root domain, or if you get an error message that nisrestore cannot verify or look up needed data, then use the nisrestore -f option. For example:


    replica2# nisrestore -f -a /var/master1_bakup
  4. Restart rpc.nisd on the new replica

    See How to Configure an NIS+ Server for details.

Using nisping to Load Data on to a Replica Server

This section describes how to use the nisping command to load namespace data onto a newly configured replica. In most cases, it is not necessary to actually run the nisping command because the process should begin automatically.

The problem with the nisping method is that it requires a full resync of data from the master to the replica over the network using NIS+ protocols. If your namespace is large, this process can take hours, during which requests for naming information can be delayed.

Security Considerations

The NIS+ principal performing this operation must have modify rights to the domain's directory object.

Prerequisites

Using nisping to Load Data on to a Replica Server — Task Map

Table 7–3 Using nisping to Load Data on to a Replica Server

Task 

Description 

For Instructions, Go To 

Using nisping to Load Data on to a Replica Server

Use nisping to load data on to a replica server

How to Load Namespace Data—nisping Method

How to Load Namespace Data—nisping Method

Normally, the loading for namespace data is automatically initiated by the master server. If that does not occur, run the nisping command as described below.

    Run nisping on the directories

This step sends a message (a “ping”) to the new replica, telling it to ask the master server for an update. If the replica does not belong to the root domain, be sure to specify its domain name. (The example below includes the domain name only for completeness. Since the example used throughout this task adds a replica to the root domain, the doc.com. domain name in the example below is not necessary.)


master1# nisping doc.com. 
master1# nisping org_dir.doc.com. 
master1# nisping groups_dir.doc.com.

You should see results similar to these:


master1# nisping doc.com. 
Pinging replicas serving directory doc.com. :
Master server is master1.doc.com.
 No last update time
Replica server is replica1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1992
 Pinging ... replica2.doc.com.

If your namespace is large, this process can take a significant amount of time. For more information about nisping, see Chapter 18, Administering NIS+ Directories.

Server Configuration Summary

Table 7–5 and Table 7–4 provide a summary of the tasks described in this chapter. They assume the simplest cases, so be sure you are familiar with the more thorough task descriptions before you use this summary as a reference. This summary does not show the server's responses to each command.

Table 7–4 Adding a Replica Named replica2 to doc.com.: Command Summary

Tasks 

Commands 

Log in as superuser to domain master. 

master1% su

Designate the new replica. 

# nismkdir -s replica2 doc.com.

# nismkdir -s replica2 org_dir.doc.com.

# nismkdir -s replica2 groups_dir.doc.com.

Ping the replica. 

# /usr/lib/nis/nisping doc.com.

# /usr/lib/nis/nisping org_dir.doc.com.

# /usr/lib/nis/nisping groups_dir.doc.com.


Note –

Rather than using nisping to transfer data to the new replica, as shown in the example above, an easier method is to use the NIS+ backup and restore capability, as described in Using nisrestore to Load Data on to a Replica Server.


Table 7–5 Starting Up a Non-root Master Server: Command Summary

Tasks 

Commands 

Log in to the server as root. 

server%su

NIS-compat only: Start daemon with -Y -B

server# rpc.nisd -Y - B

Change to EMULYP= -Y -B.

server# vi /etc/inet.d/rpc

NIS+-Only: Start daemon. 

server# rpc.nisd

Chapter 8 Configuring a Non-Root Domain

This chapter provides step-by-step instructions for using the NIS+ command set to configure a subdomain domain (also known as a non-root domain) including designating its master and replica servers.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


Setting Up a Non-Root Domain


Note –

It is much easier to perform this task with the NIS+ installation scripts, as described in Part 1, than with the NIS+ command set as described here. The methods described in this chapter should be used only by those administrators who are very familiar with NIS+ and who require some nonstandard features or configurations not provided by the installation scripts.


You should not configure a non-root domain until after you have configured its servers.

Setting up a non-root domain involves the following tasks:

As with setting up the root domain, these tasks cannot be performed sequentially. To make the configuration process easier to execute, they have been broken down into individual steps and the steps have been arranged into the most efficient order.

Standard Versus NIS-Compatible Configuration Procedures

The differences between NIS-compatible and standard NIS+ servers in subdomains are the same as they are for servers in the root domain (see Standard Versus NIS-Compatible Configuration Procedures).

The NIS+ daemon for each server in an NIS-compatible domain should have been started with the -Y option, as instructed in Chapter 7, Configuring NIS+ Servers. An NIS-compatible domain also requires its tables to provide read rights for the nobody class, which allows NIS clients to access the information stored in them. This is accomplished with the -Y option to the nissetup command, shown in Step 4. (The standard NIS+ domain version uses the same command but without the -Y option, so it is described in the same step.)

Here is a summary of the entire configuration process:

  1. Log in to the domain's master server.

  2. Name the domain's administrative group.

  3. Create the domain's directory and designate its servers.

  4. Create the domain's subdirectories and tables.

  5. Create the domain's admin group.

  6. Assign full group access rights to the directory object.

  7. Add the servers to the domain's admin group.

  8. Add credentials for other administrators.

  9. Add the administrators to the domain's admin group.

Security Considerations


Note –

The NIS+ security system is complex. If you are not familiar with NIS+ security, you might want to review Chapter 17, Administering NIS+ Groupsbefore starting to configure your NIS+ environment.


At most sites, to preserve the security of the parent domain, only the parent domain's master server or an administrator who belongs to the parent domain's admin group is allowed to create a domain beneath it. Although this is a policy decision and not a requirement of NIS+, the instructions in this chapter assume that you are following that policy. Of course, the parent domain's admin group must have create rights to the parent directory object. To verify this, use the niscat -o command.


rootmaster# niscat -o doc.com.
Object Name : Doc
Owner : rootmaster
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdrmcdr---
:

If you are more concerned about convenience than security, you can make the new domain's master server a member of its parent domain's admin group, then perform the entire procedure from the server. Use the nisgrpadm command, described in Chapter 17, Administering NIS+ Groups.

Prerequisites

Information You Need

Setting Up a Non-root Domain — Task Map

Table 8–1 Setting Up a Non-root Domain

Task 

Description 

For Instructions, Go To 

Setting Up a Non-root Domain 

Use NIS+ commands to set up a non-root domain 

How to Configure a Non-root Domain

How to Configure a Non-root Domain

  1. Log in to the domain's master server.

    Log in to the server that you will designate as the new domain's master. The steps in this task use the server named smaster, which belongs to the doc.com. domain, and will become the master server of the sales.doc.com. subdomain. The administrator performing this task is nisboss.doc.com., a member of the admin.doc.com. group. That group has full access rights to the doc.com. directory object.

  2. Name the domain's administrative group.

    Although you won't actually create the admin group until Step 5, you need to identify it now. This enables the nismkdir command used in the following step to create the directory object with the proper access rights for the group. It does the same for the nissetup utility used in Step 4.

    Set the value of the environment variable NIS_GROUP to the name of the domain's admin group. Here are two examples, one for C shell users and one for Bourne or Korn shell users. They both set NIS_GROUP to admin.sales.doc.com.

    For C Shell


    smaster# setenv NIS_GROUP admin.sales.doc.com.

    For Bourne or Korn Shell


    smaster# NIS_GROUP=admin.sales.doc.com.
    smaster# export NIS_GROUP
  3. Create the domain's directory and designate its servers.

    The nismkdir command, in one step, creates the new domain's directory and designates its supporting servers. It has the following syntax:


    nismkdir -m master -s replica domain
    

    The -m flag designates its master server, and the -s flag designates its replica.


    smaster# nismkdir -m smaster -s salesreplica sales.doc.com. 

    Caution – Caution –

    Always run nismkdir on the master server. Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replica.


    The directory is loaded into /var/nis. Use the niscat -o command to view it (do not use cat or more).


    smaster# niscat -o sales.doc.com.
    Object Name : Sales
    Owner : nisboss.doc.com.
    Group : admin.sales.doc.com.
    Domain : doc.com.
    Access Rights : ----rmcdr---r---
    .

    Unlike the root directory, this directory object does have the proper group assignment. As a result, you won't have to use nischgrp.

  4. Create the domain's subdirectories and tables.

    This step adds the org_dir and groups_dir directories and the NIS+ tables beneath the new directory object. Use the nissetup utility, but be sure to add the new domain name. And, for an NIS-compatible domain, include the -Y flag.

    NIS compatible


    smaster# /usr/lib/nis/nissetup -Y sales.doc.com.

    NIS+


    smaster# /usr/lib/nis/nissetup sales.doc.com.

    Each object added by the utility is listed in the output:


    smaster# /usr/lib/nis/nissetup
    org_dir.sales.doc.com. created
    groups_dir.sales.doc.com. created
    auto_master.org_dir.sales.doc.com. created
    auto_home.org.dir.sales.doc.com. created
    bootparams.org_dir.sales.doc.com. created
    cred.org_dir.sales.doc.com. created
    ethers.org_dir.sales.doc.com. created
    group.org_dir.sales.doc.com. created
    hosts.org_dir.sales.doc.com. created
    mail_aliases.org_dir.sales.doc.com. created
    sendmailvars.org_dir.sales.doc.com. created
    netmasks.org_dir.sales.doc.com. created
    netgroup.org_dir.sales.doc.com. created
    networks.org_dir.sales.doc.com. created
    passwd.org_dir.sales.doc.com. created
    protocols.org_dir.sales.doc.com. created
    rpc.org_dir.sales.doc.com. created
    services.org_dir.sales.doc.com. created
    timezone.org_dir.sales.doc.com. created

    The -Y option creates the same tables and subdirectories as for a standard NIS+ domain, but assigns read rights to the nobody class so that requests from NIS clients, which are unauthenticated, can access information in the NIS+ tables.

    You can verify the existence of the org_dir and groups_dir directories by looking in your master server's /var/nis/data directory. They are listed along with the root object and other NIS+ tables. The tables are listed under the org_dir directory. You can examine the contents of any table by using the niscat command, described in Chapter 9, Setting Up NIS+ Tables (although at this point the tables are empty).

  5. Create the domain's admin group.

    This step creates the admin group named in Step 2. Use the nisgrpadm command with the -c option. This example creates the admin.sales.doc.com. group


    smaster# nisgrpadm -c admin.sales.doc.com.
     Group admin.sales.doc.com. created.

    This step only creates the group—it does not identify its members. That is done in Step 9.

  6. Assign full group access rights to the directory object.

    By default, the directory object grants only its group read access, which makes the group no more useful than the world class. To make the configuration of clients and subdomains easier, change the access rights that the directory object grants its group from read to read, modify, create, and destroy. Use the nischmod command.


    smaster# nischmod g+rmcd sales.doc.com.

    Complete instructions for using the nischmod command are provided in Chapter 15, Administering NIS+ Access Rights.

  7. Add the servers to the domain's admin group.

    At this point, the domain's group has no members. Add the master and replica servers, using the nisgrpadm command with the -a option. The first argument is the group name; the others are the names of the new members. This example adds smaster.doc.com. and salesreplica.doc.com. to the admin.sales.doc.com. group:


    smaster# nisgrpadm -a admin.sales.doc.com. smaster.doc.com. 
    salesreplica.doc.com.
    Added smaster.doc.com. to group admin.sales.doc.com.
    Added salesreplica.doc.com. to group admin.sales.doc.com.

    To verify that the servers are indeed members of the group, use the nisgrpadm command with the -l option (see Chapter 17, Administering NIS+ Groups).


    smaster# nisgrpadm -l admin.sales.doc.com.
     Group entry for admin.sales.doc.com. group:
     Explicit members:
     smaster.doc.com.
     salesreplica.doc.com.
     No implicit members
     No recursive members
     No explicit nonmembers
     No implicit nonmembers
     No recursive nonmembers
  8. Add credentials for other administrators.

    Add the credentials of the other administrators who will work in the domain.

    For administrators who already have DES credentials in another domain, add LOCAL credentials. Use the nisaddcred command with both the -p and the -P flags.


    smaster# nisaddcred -p 33355 -P nisboss.doc.com. local

    For administrators who do not yet have credentials, you can proceed in two different ways.

    • One way is to ask them to add their own credentials. However, they will have to do this as superuser. Here is an example in which an administrator with a UID of 22244 and a principal name of juan.sales.doc.com. adds his own credentials to the sales.doc.com. domain.


    smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local
    smaster# nisaddcred -p unix.22244@sales.doc.com -P juan.sales.doc.com. des
    Adding key pair for unix.22244@sales.doc.com.
    Enter login password:
    • The other way is for you to create temporary credentials for the other administrators, using dummy passwords (each administrator must have an entry in the NIS+ passwd table).


    smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local
    smaster# nisaddcred -p unix.22244@sales.doc.com -P juan.sales.doc.com. des
    Adding key pair for unix.22244@sales.doc.com.
    Enter juan's login password:
    nisaddcred: WARNING: password differs from login passwd.
    Retype password:

    Each administrator can later change his or her network password by using the chkey command. Chapter 12, Administering NIS+ Credentials and Chapter 13, Administering NIS+ Keys describe how to do this.


    Note –

    In the two examples shown in Step 8, the domain name following the lower case -p flag must never end in a trailing dot, while the domain name following the upper case -P flag must always end in a trailing dot.


  9. Add the administrators to the domain's admin group.

    You don't have to wait for the other administrators to change their dummy passwords to perform this step. Use the nisgrpadm command with the -a option. The first argument is the group name, and the remaining arguments are the names of the administrators. This example adds the administrator juan to the admin.sales.doc.com. group:


    smaster# nisgrpadm -a admin.sales.doc.com. juan.sales.doc.com.
    Added juan.sales.doc.com. to group admin.sales.doc.com.
  10. Allocate sufficient swap space to accommodate NIS+ tables.

    Swap space should be double the size of the maximum size of rpc.nisd. To determine how much memory rpc.nisd is using, issue the following command:


    rootmaster# /usr/lib/nis/nisstat

    rpc.nisd will under certain circumstances fork a copy of itself. If there is not enough memory, rpc.nisd fails.

    You can also calculate the memory and swap space requirements for NIS+ tables. For example, if you have 180,000 users and 180,000 hosts in your NIS+ tables, those two tables occupy approximately 190 Mbytes of memory. When you add credentials for 180,000 users and 180,000 hosts, the cred table has 540,000 entries (one entry for each local user credential, one entry for each DES user credential, and one entry for each host). The cred table occupies approximately 285 Mbytes of memory. In this example, rpc.nisd occupies at least 190 Mbytes + 285 Mbytes = 475 Mbytes of memory. So, you will require at least 1 Gbyte swap space. You will also want at least 500 Mbytes of memory to hold rpc.nisd entirely in memory.

Subdomain Configuration Summary

Table 8–2 is a summary of the steps required to configure a non-root domain. It assumes the simplest case, so be sure you are familiar with the more thorough task descriptions before you use this summary as a reference. This summary does not show the server's responses to each command.

Table 8–2 Setting Up a Subdomain Command Summary

Tasks 

Commands 

Log in as superuser to domain master. 

smaster% su

Name the domain's admin group. 

# NIS_GROUP=admin.sales.doc.com.

# export NIS_GROUP

Create the domain's directory and designate its servers. 

# nismkdir -m smaster -s salesreplica sales.doc.com.

Create org_dir, groups_dir, and tables. (For NIS-compatibility, use -Y.)

# /usr/lib/nis/nissetup sales.doc.com.

Create the admin group. 

# nisgrpadm -c admin.sales.doc.com.

Assign full group rights to the domain's directory. 

# nischmod g+rmcd sales.doc.com.

Add servers to admin group. 

# nisgrpadm -a admin.sales.doc.com. smaster.doc.com. sreplica.doc.com.

Add credentials for other admins. 

# nisaddcred -p 22244 -P juan.sales.doc.com. local

# nisaddcred -p unix.22244@sales.doc.com. juan.sales.doc.com. DES

Add admins to domain's admin group. 

# nisgrpadm -a admin.sales.doc.com. juan.sales.doc.com.

Chapter 9 Setting Up NIS+ Tables

This chapter provides step-by-step instructions for using the NIS+ command set to populate NIS+ tables on a master server from /etc files or NIS maps, how to transfer information back from NIS+ tables to NIS maps, how to limit access to the passwd column of the passwd table.


Note –

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)). For more information, visit http://www.sun.com/directory/nisplus/transition.html.


Setting Up Tables


Note –

It is much easier to perform this task with the NIS+ installation scripts, as described in Part 1, than with the NIS+ command set, as described here. The methods described in this chapter should be used only by those administrators who are very familiar with NIS+ and who require some nonstandard features or configurations not provided by the installation scripts. Also, if you have them available, the Solstice AdminSuite tools provide easier methods of working with NIS+ tables.


You can populate NIS+ tables in four ways:

When populating tables from maps or files, the tables should have already been created in the process of setting up a root or subdomain, as explained in Chapter 5, Setting Up the Root Domain and Chapter 8, Configuring a Non-Root Domain. Although you can populate a domain's tables at any time after they are created, it is recommended that you do so immediately after setting up the domain. This enables you to add clients more easily, since the required information about the clients should already be available in the domain's tables.

Populating Tables—Options

When you populate a table—whether from a file or an NIS map—you can use any of these options:

Populating NIS+ Tables From Files

This task transfers the contents of an ASCII file, such as /etc/hosts, into an NIS+ table.

Here is an outline of the procedure:

  1. Check the content of each file that you will be transferring data from.

  2. Make a copy of each file. Use this copy for the actual transfer. In this guide, copies of files to be transferred are given names ending in xfr (for example, hosts.xfr).

  3. Log in to an NIS+ client. (You must have credentials and permissions allowing you to update the tables. See Files Security Considerations, below.)

  4. Add /usr/lib/nis to the search path for this shell (if not already done).

  5. Use nisaddent to transfer any of these files one at a time: aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services, shadow, and ipnodes.


    Note –

    The new /etc/inet/ipnodes file contains IPv4 and IPv6 addresses. Use nisaddent to transfer the /etc/inet/ipnodes file into the ipnodes.org_dir table.


  6. Transfer the publickey file.

  7. Transfer the automounter information.

  8. Ping any replicas.

  9. Checkpoint the tables.

Files Security Considerations

You can populate NIS+ tables from any NIS+ client or from the root master server. You do not have to be logged in as superuser (root) to populate NIS+ tables, but you do have to have the proper credentials and access rights. If you are going to replace or merge the entries in the table with the entries from the text file, you must have create and destroy rights to the table. If you are going to append the new entries, you only need create rights.


Note –

The NIS+ security system is complex. If you are not familiar with NIS+ security, you may want to review Chapter 11, NIS+ Security Overview before starting to set up your NIS+ environment.


After you complete this operation, the table entries will be owned by the NIS+ principal that performed the operation and the group specified by the NIS_GROUP environment variable.

Prerequisites

Information You Need

You need the name and location of the text files that will be transferred.

Populating NIS+ Tables From Files — Task Map

Table 9–1 Populating NIS+ Tables From Files

Task 

Description 

For Instructions, Go To 

Populating NIS+ Tables From Files 

Populate NIS+ tables from files 

How to Populate NIS+ Tables From Files

How to Populate NIS+ Tables From Files

  1. Check each file that you will be transferring data from.

    Make sure that there are no spurious or incorrect entries. Make sure that the right data is in the correct place and formatted properly. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. (It is easier to add incomplete entries after setup than to try transferring incomplete or damaged entries from the file.)

  2. Make a working copy of each file you will be transferring.

    Use this working copy for the actual file transfer steps described in this section. Give each working copy the same filename extension (for example, .xfr).


    rootmaster% cp /etc/hosts /etc/hosts.xfr

    For safety reasons, you might also copy all of the files you plan to use to some directory other than /etc. The nisaddent and nispopulate commands allow you to specify the file source directory.

  3. Log in to an NIS+ client.

    You can perform this task from any NIS+ client—just be sure that the client belongs to the same domain as the tables into which you want to transfer the information. The examples in this task use the root master server. Because the administrator in these examples is logged on as superuser, the NIS+ principal actually performing this operation (and therefore needing the proper credentials and access rights) is the root master server.

    However, it is not necessary to be a superuser (root) or to be logged in on the root master server to update NIS+ tables. Regular users or superusers on any machine can update NIS+ tables, so long as they have the proper credentials, authorization, file permissions.

  4. Add /usr/lib/nis to the search path for this shell.

    Since you will be using the /usr/lib/nis/nisaddent command once per table, adding its prefix to the search path will save you the trouble of typing it each time. Here are two examples, one for C shell users and one for Bourne or Korn shell users:

    For C Shell


    rootmaster# setenv PATH $PATH:/usr/lib/nis

    For Bourne or Korn Shell


    rootmaster# PATH=$PATH:/usr/lib/nis
    rootmaster# export PATH
  5. Use nisaddent to transfer any of these files, one at a time:


    aliases
    bootparams
    ethers
    group
    hosts
    ipnodes
    netgroup
    netmasks
    networks
    protocols
    rpc, services

    The publickey, automounter, passwd, and shadow files require slightly different procedures; for the publickey file, go to Step 6; for the automounter files, go to Step 7; for the passwd and shadow files, go to Step 8.

    By default, nisaddent appends the information. To replace or merge instead, use the -r or -m options.

    To replace:


    rootmaster# nisaddent -r -f filename table[domain]

    To append:


    rootmaster# nisaddent -a -f filename table [domain]

    To merge:


    rootmaster# nisaddent -m -f filename table [domain]

    The best option for populating the tables for the first time is the -a option, the default. The best option to synchronize the NIS+ tables with NIS maps or /etc files is the -m (merge) option.

    • filename is the name of the file. The common convention is to append .xfr to the end of these file names to identify them as transfer files created with nisaddent.

    • table is the name of the NIS+ table. The domain argument is optional; use it only to populate tables in a different domain. Here are some examples, entered from the root domain's master server. The source files are edited versions of the /etc files:


    rootmaster# nisaddent -m -f /etc/hosts.xfr hosts
    rootmaster# nisaddent -m -f /etc/groups.xfr groups

    If you perform this operation from a non-root server, keep in mind that a non-root server belongs to the domain above the one it supports; therefore, it is a client of another domain. For example, the sales.doc.com. master server belongs to the doc.com. domain. To populate tables in the sales.doc.com. domain from that master server, you must append the sales.doc.com. domain name to the nisaddent statement.


    salesmaster# nisaddent -f /etc/hosts.xfr hosts Sales.doc.com.

    If you perform this operation as a client of the sales.doc.com. domain, you do not need to append the domain name to the syntax.

    To verify that the entries were transferred into the NIS+ table, use the niscat command, as described more fully in .Chapter 19, Administering NIS+ Tables


    rootmaster# niscat groups.org_dir
    root::0:root
    other::1::
    bin::2:root,bin,daemon
    .

    Troubleshooting tip: If niscat does not now show the updates immediately, it could be because the changes have not been sent by the master server to one or more of the replica servers. In this case, you can either wait and try again in five or ten minutes or use niscat's -M option, which specifies that niscat obtain its data from the master server.

  6. Transfer the publickey file.

    Because the domain's cred table already stores some credentials, you need to make sure they are not overwritten by the contents of the publickey text file that you transfer into the cred table. You can avoid this by removing those credentials from the publickey text file. For rootmaster, there might be one or more lines like the following, all of which should be removed:


    unix.rootmaster@doc.com public-key:private-key [alg-type]

    Then you can transfer the contents of the publickey file to the cred table. Use nisaddent, with the -a (add) option.


    rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir publickey [domain]

    Note, however, that this operation transfers only DES credentials into the cred table. You still need to create their LOCAL credentials to the cred table.

  7. Transfer the automounter information.

    Although the nissetup utility creates auto_master and auto_home tables, they are not considered standard NIS+ tables. Therefore, transferring information into them requires a slightly different syntax; in particular, you must use the -t flag and specify that the table is of type key-value.


    rootmaster# nisaddent -f auto.master.xfr -t auto_master.org_dir key-value
    rootmaster# nisaddent -f auto.home.xfr -t auto_home.org_dir key-value 
  8. Build the NIS+ passwd table.

    The NIS+ passwd table is composed of data drawn from both the /etc/passwd and /etc/shadow files. Thus, you must run nisaddent twice to build the passwd table: once for the /etc/passwd file, using passwd as the target table, and once for the /etc/shadow file, using shadow as the target table. (Note that when running nisaddent on the shadow file, you specify shadow as the target table, even though there is no shadow table and the data is actually being placed in the shadow column of the passwd table.)


    rootmaster# nisaddent -m -f /etc/passwd.xfr passwd
    rootmaster# nisaddent -m -f /etc/shadow.xfr shadow
  9. Transfer your updates to your replica servers by running nisping.

    Running nisping updates any replica servers with your changes.


    master1# nisping domain 
    master1# nisping org_dir.domaincom. 
    master1# nisping groups_dir.domain
    
  10. Checkpoint the tables.

    Now that you have updated the in-memory copies of the NIS+ data set on your master and replica servers, you should write those changes into the table files on disk. This is called checkpointing. (Checkpoint is not mandatory at this time, so long as you have regularly scheduled checkpoints that will take care of it later. But if your changes have been significant, it is a good idea to get them written to disk as soon as convenient.)

    This step ensures that all the servers supporting the domain transfer the new information from their .log files to the disk-based copies of the tables. If you have just set up the root domain, this step affects only the root master server, since the root domain does not yet have replicas. To checkpoint, use the nisping command with the -C (uppercase) option.


    rootmaster# nisping -C org_dir 
    Checkpointing replicas serving directory org_dir.doc.com. :
    Master server is rootmaster.doc.com.
     Last update occurred at July 14, 1997
    Master server is rootmaster.doc.com.
    checkpoint succeeded.

    If you do not have enough swap space, the server is unable to checkpoint properly, but it will not notify you. One way to make sure that you have sufficient swap space is to list the contents of a table with the niscat command. If you do not have enough swap space, you will see this error message:


    can't list table: Server busy, Try Again.

    Even though it doesn't seem to, this message indicates that you don't have enough swap space. Increase the swap space and checkpoint the domain again.

Populating NIS+ Tables From NIS Maps

This task transfers the contents of an NIS map into an NIS+ table. Here is a list of the steps:

  1. Check the content of each NIS map that you will be transferring data from.

  2. Log in to an NIS+ client.

  3. Add /usr/lib/nis to the search path for this shell.

  4. Use nisaddent to transfer any of these maps, one at a time: aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services.

  5. Transfer the publickey map.

  6. Transfer the automounter information.

  7. Update your replicas with your changes by running nisping.

  8. Checkpoint the tables.

Maps Security Considerations

You can perform this task from any NIS+ client as long as you (or superuser on the client) have the proper credentials and access rights. If you are going to replace or merge the entries in the table with the entries from the NIS map, you must have create and destroy rights to the table. If you are going to append the new entries, you need only create rights.

After you complete this operation, the table entries are owned by the NIS+ principal that performed the operation (either you or, if logged on as superuser, the client) and the group specified by the NIS_GROUP environment variable.

Prerequisites

Information You Need

You need the name and location of the NIS maps.

Populating NIS+ Tables From NIS Maps — Task Map

Table 9–2 Populating NIS+ Tables From NIS Maps

Task 

Description 

For Instructions, Go To 

Populating NIS+ Tables From NIS Maps 

Populate NIS+ tables from NIS maps 

How to Populate Tables From Maps

How to Populate Tables From Maps

  1. Check each NIS map that you will be transferring data from.

    Make sure that there are no spurious or incorrect entries. Make sure that the right data is in the correct place and format properly. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. (It is easier to add incomplete entries after setup than to try transferring incomplete or damages entries from the map.)

  2. Log in to an NIS+ client.

    You can perform this task from any NIS+ client—so long as that client belongs to the same domain as the tables into which you want to transfer the information. The examples in this task use the root master server. Since the administrator in these examples is logged in as superuser, the NIS+ principal actually performing this operation (and therefore needing the proper credentials and access rights) is the root master server.

  3. Add /usr/lib/nis to the search path for this shell.

    Because you will be using the /usr/lib/nis/nisaddent command once for each table, adding its prefix to the search path will save you the trouble of typing it each time. Here are two examples, one for C shell users and one for Bourne or Korn shell users:

    For C Shell


    rootmaster# setenv PATH $PATH:/usr/lib/nis

    For Bourne or Korn Shell


    rootmaster# PATH=$PATH:/usr/lib/nis
    rootmaster# export PATH
  4. Use nisaddent to transfer any of these maps, one at a time:

    aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services.

    The -publickey and automounter maps require slightly different procedures; for the publickey file, go to Step 6, and for the automounter files, go to Step 7.

    By default, nisaddent appends the file information to the table information. To replace or merge instead, use the -r or -m options:

    To replace:


    rootmaster# nisaddent -r -y nisdomain table
    

    To append:


    rootmaster# nisaddent -a -y nisdomain table
    

    To merge:


    rootmaster# nisaddent -m -y nisdomain table
    

    The best option for populating the tables for the first time is the -a option, which is the default. The best option to synchronize the NIS+ tables with NIS maps or /etc files is the -m (merge) option.

    The -y (lowercase) option indicates an NIS domain instead of a text file. The nisdomain argument is the name of the NIS domain whose map you are going transfer into the NIS+ table. You don't have to name the actual map; the nisaddent utility automatically selects the NIS map that corresponds to the table argument. Here are some examples:


    rootmaster# nisaddent -m -y olddoc hosts
    rootmaster# nisaddent -m -y olddoc passwd
    rootmaster# nisaddent -m -y olddoc groups

    The first example transfers the contents of the hosts.byname and hosts.byaddr maps in the olddoc (NIS) domain to the NIS+ hosts table in the root domain (NIS+). The second transfers the NIS maps that store password-related information into the NIS+ passwd table. The third does the same with group-related information. For more information about the nisaddent command, see Chapter 19, Administering NIS+ Tables.

  5. Transfer the publickey map.

    Since the domain's cred table already stores some credentials, you need to make sure they are not overwritten by the contents of the publickey map that you transfer into the cred table.

    1. First, dump the publickey map to a file, then open that file with your text editor.


      rootmaster# makedbm -u /var/yp/olddoc/publickey.byname /etc/publickey.xfr 
      rootmaster# vi /tmp/publickey.tmp
    2. Now remove the credentials of the machine you are logged in to from the publickey map.

      For rootmaster, there might be one or lines like the following, all of which should be removed:


      unix.rootmaster@doc.com public-key:private-key [alg-type]
    3. Now you can transfer the contents of the file—not the map—into the cred table. Use nisaddent, with the -a (add) option.


      rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir Publickey

      Notice that this operation transfers only DES credentials into the cred table. You still need to create their LOCAL credentials to the cred table.

  6. Transfer the automounter information.

    Although the nissetup utility creates auto_master and auto_home tables, they are not considered standard NIS+ tables. Therefore, transferring information into them requires a slightly different syntax:


    rootmaster# nisaddent -y olddoc -Y auto.master -t auto_master.org_dir key-value
    rootmaster# nisaddent -y olddoc -Y auto.home -t auto_home.org_dir key-value

    The -m and -y options are still required, as is the NIS domain name (in this instance, olddoc). However, you must precede the name of the NIS map (for example, auto.master) with a -Y (uppercase). Then, as is required when transferring automounter text files, you must use the -t option, which indicates that this is a nonstandard NIS+ table. Its arguments are the name of the NIS+ directory object (auto_master.org_dir) and the type of table (key-value). Be sure to append the org_dir suffixes to the NIS+ table names.

  7. Transfer your updates to your replica servers by running nisping.

    Running nisping updates any replica servers with your changes.


    master1# nisping domain 
    master1# nisping org_dir.domaincom. 
    master1# nisping groups_dir.domain
    
  8. Checkpoint the tables.

    This step ensures that all the servers supporting the domain transfer the new information from their .log files to the disk-based copies of the tables. If you just finished setting up the root domain, this step affects only the root master server, since the root domain does not yet have replicas. Use the nisping command with the -C (uppercase) option.


    rootmaster# nisping -C org_dir
    Checkpointing replicas serving directory org_dir.doc.com. :
    Master server is rootmaster.doc.com.
     Last update occurred at July 14, 1994
    Master server is rootmaster.doc.com.
    checkpoint succeeded.

    If you do not have enough swap space, the server is unable to checkpoint properly, but it does not notify you. One way to make sure you have sufficient swap space is to use list the contents of a table with the niscat command. If you do not have enough swap space, you will see this error message:


    can't list table: Server busy, Try Again.

    Even though it does not seem to, this message indicates that you do not have enough swap space. Increase the swap space and checkpoint the domain again.

Transferring Information From NIS+ to NIS

This task transfers the contents of NIS+ tables into NIS maps on a Solaris 1.x NIS master server. Here is an outline of the procedure:

  1. Log in to the NIS+ server.

  2. Transfer the NIS+ tables in to output files.

  3. Transfer the contents of the output files to the NIS maps.

NIS to NIS+ Security Considerations

To perform this task, you must have read access to each table whose contents you transfer.

Prerequisites

The maps must already have been built on the NIS server.

Transferring Information From NIS+ to NIS — Task Map

Table 9–3 Transferring Information From NIS+ to NIS

Task 

Description 

For Instructions, Go To 

Transferring Information From NIS+ to NIS 

Transfer information from NIS+ tables to NIS maps on a Solaris 1.x NIS master server 

How to Transfer Information From NIS+ to NIS

How to Transfer Information From NIS+ to NIS

  1. Log in to the NIS+ server.

    This example uses the server named dualserver.

  2. Transfer the NIS+ tables to output files.

    Use the nisaddent command with the -d option, once for each table.


    dualserver% /usr/lib/nis/nisaddent -d -t table tabletype > filename
    

    The -d option transfers the contents of table to filename, converting the contents back to standard /etc file format.

  3. Transfer the contents of the output files in to the NIS maps.

    The NIS+ output files are ASCII files that you can use as input files for the NIS maps. Copy them into the NIS master's /etc directory, then use make as usual.


    dualserver# cd /var/yp
    dualserver# make

Limiting Access to the Passwd Column to Owners and Administrators

This task describes how to limit read access to the password-related columns of the passwd table to the entry owner and the table administrators, without affecting the read access of other authenticated principals (including applications) to the remaining columns of the passwd table.

This task establishes the following rights:


                         Nobody  Owner   Group  World
Table Level Rights:      ----    rmcd    rmcd   ----
Passwd Column Rights:    ----    rm--    rmcd   ----
Shadow Column Rights:    ----    rm--    rmcd   ----

Passwd Column Security Considerations

Prerequisites

Information You Need

All you need is the name of the passwd table.

Limiting Access to the Passwd Column to Owners and Administrators — Task Map

Table 9–4 Limiting Access to the Passwd Column to Owners and Administrators

Task 

Description 

For Instructions, Go To 

Limiting Access to the Passwd Column to Owners and Administrators 

Modify passwd.org_dir, via NIS+ commands, to restrict access to the passwd column for owners and administrators.

How to Limit Read Access to the Passwd Column

How to Limit Read Access to the Passwd Column

  1. Log in to the domain's master server.

    The examples in this task use the root master server, rootmaster.

  2. Check the current table and column permissions.

    Use the niscat -o command.


    rootmaster# niscat -o passwd.org_dir

    This task assumes the existing permissions are:


    Access Rights    : ----rmcdrmcdr---
    Columns          :       
                         [0]  Name              : name
                               Access Rights : r-----------r---
                         [1]  Name              : passwd
                               Access Rights : -----m----------
                         [2]  Name              : uid
                               Access Rights : r-----------r---
                         [3]  Name              : gid
                               Access Rights : r-----------r---
                         [4]  Name              : gcos
                               Access Rights : r----m------r---
                         [5]  Name              : home
                               Access Rights : r-----------r---
                         [6]  Name              : shell
                               Access Rights : r-----------r---
                         [7]  Name              : shadow
                               Access Rights : r-----------r---

    If your permissions are different, you may need to use a different syntax. For instructions, see Chapter 15, Administering NIS+ Access Rights.

  3. Change the table permissions.

    Use the nischmod command to change the table's object-level permissions to ---- rmcdrmcd ----


    rootmaster# nischmod og=rmcd,nw= passwd.org_dir
  4. Change the column permissions.

    Use the nistbladm command with the -u option to change the permissions of the passwd and shadow columns to:


    passwd ---- rm-- ---- ----
    shadow ---- r--- ---- ----
    rootmaster# nistbladm -u passwd=o+r, shadow=o+r passwd.org_dir
  5. Verify the new permissions.

    Use the niscat -o command, as you did in Step 2. The permissions should look the same as they do in that step's output.

Table Population Summaries

Following are summaries of the steps required to populate NIS+ tables. They assume the simplest case, so be sure you are familiar with the more thorough task descriptions before you use this summary as a reference. For brevity, these summaries do not show the server's responses to each command.

Table 9–5 Transferring Files Into NIS+ Tables: Command Summary

Tasks 

Commands 

Log in to an NIS+ client. 

rootmaster%

Create working copies of the files to be transferred. 

% cp /etc/hosts /etc/hosts.xfr

Add /usr/lib/nis to search path.

% PATH=$PATH:/usr/lib/nis; export PATH

Transfer each file, one at a time. 

% nisaddent -m -f /etc/hosts.xfr hosts

Remove old server credentials from publickey file.

% vi /etc/publickey.xfer

Transfer it to the cred table. 

% nisaddent -a -f /etc/publickey.xfr cred

Transfer the automounter files. 

% nisaddent -f auto.master.xfr -t auto_master.org_dir key-value

% nisaddent -f auto.home.xfr -t auto_home.org_dir key-value

Checkpoint the table directory. 

% nisping -C org_dir

Table 9–6 Transferring Maps Into NIS+ Tables: Command Summary

Tasks 

Commands 

Log in to an NIS+ client. 

rootmaster%

Add /usr/lib/nis to search path.

% PATH=$PATH:/usr/lib/nis; export PATH

Transfer each map, one at a time. 

% nisaddent -m -y olddoc hosts

Dump publickey map to a file.

% makedbm -u /var/yp/olddoc/publickey.byname > /etc/publickey.xfr

Remove new credentials. 

% vi /etc/publickey.xfr

Transfer the publickey file.

% nisaddent -a -f /etc/publickey.xfr -t cred.ortg_dir publickey

Transfer the automounter maps. 

% nisaddent -y olddoc -Y auto.master -t auto_master.org_dir key-value

% nisaddent -y olddoc -Y auto.home -t auto_home.org_dir key-value

Checkpoint the table directory. 

% nisping -C org_dir

Table 9–7 Transferring NIS+ Tables to NIS Maps: Command Summary

Tasks 

Commands 

Log in to NIS+ server. 

dualserver%

Transfer NIS+ tables to files. 

% /usr/lib/nis/nisaddent -d [-t table] tabletype > filename

Transfer files to NIS maps. 

% makedbm flags output-file NIS-dbm-file

Table 9–8 Limiting Access to Passwd Column: Command Summary

Tasks 

Commands 

Log into the domain's master server. 

rootmaster#

Check the table's existing rights. 

# niscat -o passwd.org_dir

Assign the table new rights. 

# nischmod og=rmcd,nw= passwd.org_dir

Assign the columns new rights 

# nistbladm -u passwd=o+r, shadow=n+r passwd.org_dir

Verify the new rights. 

# niscat -o passwd.org_dir