Network Information Services (NIS and NIS+) Guide

Setting Up NIS+ Servers

This section provides instructions for using the NIS+ command set to perform the following server-related tasks:

• Setting Up an NIS+ Server
• Adding a Replica to an Existing Domain

Note: Perform this task with the NIS+ installation scripts as described in Using NIS+ Setup Scripts rather than with the NIS+ command set as described here. The methods described in this section 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.

See Configuration Worksheets, for worksheets that you can use to plan your NIS+ namespace.

A summary of each task is provided at the end of the section.

Setting Up an NIS+ Server

This section applies to any NIS+ server except the root master; that is, root replicas, nonroot masters, and nonroot replicas, whether running in NIS-compatibility mode or not.

Standard versus NIS-Compatible Setup 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 Setup 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.

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.

Prerequisites

Before you continue with the following procedure, you must:

• Set up the root domain (see Setting Up the Root Domain)
• Initialize the server as an NIS+ client (see Setting Up NIS+ Clients)
• Configure the /etc/resolv.conf file (if the server will run in NIS-compatibility mode and support DNS forwarding)
• Know the root user password of the client that you are converting into a server
• Be logged in as root user on the server
• Decide which security level the client must have. The security level at which you start the server determines the credentials of its clients. For instance, if the server is set up with security level 2 (the default), the clients in the domain it supports must have DES credentials. If you have set up 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 levels 0 or 1 are reserved for setup and testing purposes only. Do not use level 0 or 1 in a work environment. Operational networks should always be run at security level 2.

• Have rebooted the workstation after you set it up as an NIS+ client, as instructed in Setting Up Clients. Rebooting starts the cache manager, which is a recommended for the following procedure. If you have not rebooted the workstation, restart the cache manager using stopsrc -s nis_cachemgr then startsrc -s nis_cachemgr.

Procedure

To set up an NIS+ server:

1. Log in as root user to the new replica server.
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 the following step instead.

   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. This step also includes instructions for supporting the DNS forwarding capabilities of NIS clients.

   • Start the NIS+ daemon with the -Y and -B flags.

     compatserver# startsrc -s rpc.nisd -a "-Y -B" 
     

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

   • Run the nissetup command.

     This step creates a directory called /var/nis/data and a transaction log file called trans.log, which is placed in /var/nis. To verify that /var/nis/data exists, do the following:

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

     You can examine the contents of the transaction log by using the nislog command, described in Administering NIS+ Directories.

     Attention: Do not rename the /var/nis directory or the /var/nis/trans.log or /var/nis/data.dict files. If any required file or directory is renamed, NIS+ will not start or operate correctly.

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

   server# startsrc -s rpc.nisd
   

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

   server# ps -ef | grep rpc.nisd
   root 1081     1  0   16:43:33  -      0:01  rpc.nisd
   root 1087  1004  1   16:44:09  0      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 Administering NIS+ Directories.

   Attention: Do not rename the /var/nis directory or the /var/nis/trans.log or /var/nis/data.dict files. If any required file or directory is renamed, NIS+ will not start or operate correctly.

   Now this server is ready to be designated a master or replica of a domain, as described in Setting Up a Nonroot Domain. This step completes this task.

Adding a Replica to an Existing Domain

This section describes how to add a replica server to an existing domain using the raw NIS+ command, whether root or nonroot.

Notes:

• If the root master server is unavailable and the NIS+ domain is being served solely by a replica, you cannot change information in the NIS+ tables. You can obtain information from a replica, but changes to the master tables can be made only when the master server is available. Also, do not run a checkpoint (nisping -C) command when the root master server is unavailable. Checkpoint inaccurately updates entries in your local tables if the master server tables are unavailable.
• If you have a domain that spans multiple subnets, have at least one replica server within each subnet so if a connection between nets is temporarily out of service, each subnet can continue to function until the connection is restored.
• An easier way to add a replica server is to use the nisserver script, as described in Setting Up NIS+ Servers.

Prerequisites

Before continuing with the procedure, ensure the following:

• You have modify rights to the domain's directory object.
• The server that will be designated as a replica is already set up.
• The domain is already set up and assigned a master server.
• You know the name of the server.
• You know the name of the domain.

Procedure

The following procedure adds a replica server to an existing domain.

1. Log in to the domain's master server.
2. Add the replica to the domain using the nismkdir command with the -s option. The following example adds the replica machine named rootreplica to the Wiz.Com. domain.

   rootmaster# nismkdir -s rootreplica Wiz.Com. 
   rootmaster# nismkdir -s rootreplica org_dir.Wiz.Com. 
   rootmaster# nismkdir -s rootreplica group_dir.Wiz.Com. 
   

   When you run the nismkdir command on a directory object that already exists, it does not re-create the directory; it modifies the directory object 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.

   Attention: 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 replicas.

3. Run nisping on the directories.

   This step sends a message (a ping) to the new replica requesting the master server for an update. If the replica does not belong to the root domain, be sure to specify its domain name. (The following example includes the domain name only for completeness; since the example used throughout this task adds a replica to the root domain, the Wiz.Com. domain name in the example below is not necessary.)

   rootmaster# nisping Wiz.Com. 
   rootmaster# nisping org_dir.Wiz.Com. 
   rootmaster# nisping group_dir.Wiz.Com. 
   

   You should see results similar to the following:

   rootmaster# nisping Wiz.Com. 
   Pinging replicas serving directory wiz.com. :
   Master server is rootmaster.wiz.com.
           No last update time
    
   Replica server is rootreplica.wiz.com.
           Last update seen was Wed Nov 18 11:24:32 1992
    
           Pinging ... rootreplica.wiz.com.
   

   If you have set up the domain's tables immediately after completing the domain setup, this step propagates the tables down to the replica. For more information about nisping, see Administering NIS+ Directories.

Server Setup Summary

The following table shows a summary of the steps described in this section. Table entries are simplified. Refer to the more thorough task descriptions for options, exceptions, and messages.

server% su

server# startsrc -s rpc.nisd -a "-Y -B"
server# nissetup

server# startsrc -s rpc.nisd

rootmaster% su

nismkdir -s rootreplica Wiz.Com.
nismkdir -s rootreplica org_dir.Wiz.Com.
nismkdir -s rootreplica groups_dir.Wiz.Com.

/usr/lib/nis/nisping Wiz.Com.
/usr/lib/nis/nisping org_dir.Wiz.Com.
/usr/lib/nis/nisping groups_dir.Wiz.Com.