Solaris Naming Setup and Configuration Guide

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.

This section applies to any NIS+ server except the root master; that is, it applies to root replicas, non-root masters, and non-root replicas, whether running in NIS-compatibility mode or not. A summary of each task is provided at the end of the chapter.

See Solaris Naming Administration Guide for information on how to take an existing server out of service and replace it with a new machine.

Setting Up an NIS+ Server

It is much easier to perform this task with the NIS+ installation scripts, as described in Part 1, 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 review the security-related chapters of Solaris Naming Administration Guide 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.

Setting Up an NIS+ Server -- Task Map

Table 7-1 Setting Up an NIS+ Server

Task 

Description 

For Instructions, Go To 

Setting Up an NIS+ Server 

Set up an NIS+ server for NIS compatibility or NIS+ only. 

"How to Configure an NIS+ 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 workstation after you set it up as a 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 workstation, 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 directories chapter of Solaris Naming Administration Guide.


      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 the directories chapter of Solaris Naming Administration Guide.


    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 Solaris Naming Administration Guide for additional information 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-2 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-3 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 Solaris Naming Administration Guide. 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 Solaris Naming Administration Guide. 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-4 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 the directories chapter of Solaris Naming Administration Guide.

Server Configuration Summary

Table 7-6 and Table 7-5 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-5 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" and Solaris Naming Administration Guide .


Table 7-6 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