Starting an NIS-Compatible Daemon

You can start the NIS+ daemon in NIS-compatibility mode in any server, including the root master. Use the -Y (uppercase) option:

rpc.nisd -Y

If the server is rebooted, the daemon will not restart in NIS-compatibility mode unless you also uncomment the line that contains EMULYP=Y in the server's /etc/init.d/rpc file.

Starting a DNS-Forwarding NIS-Compatible Daemon

You can add DNS forwarding capabilities to an NIS+ daemon running in NIS-compatibility mode by adding the -B option to rpc.nisd:

rpc.nisd -Y -B

If the server is rebooted, the daemon will not restart in DNS-forwarding NIS-compatibility mode unless you also uncomment the line that contains EMULYP=-Y in the server's /etc/init.d/rpc file and change it to:

EMULYP -Y -B

Stopping the NIS+ Daemon

To stop the NIS+ daemon, whether it is running in normal or NIS-compatibility mode, kill it as you would any other daemon: first find its process ID, then kill it:

rootmaster# ps -e | 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
rootmaster# kill 1081

The nisinit Command

This section describes how to initialize a machine client using the nisinit command. An easier way to do this is with the nisclient script as described in "Setting Up NIS+ Client Machines".

The nisinit command initializes a machine to be an NIS+ client or server. As with the rpc.nisd command, you don't need any access rights to use the nisinit command, but you should be aware of its prerequisites and related tasks. These are described in "Initializing an NIS+ Client".

Initializing a Client

You can initialize a client in three different ways:

• By host name

• By broadcast

• By cold-start file

Each way has different prerequisites and associated tasks. For instance, before you can initialize a client by host name, the client's /etc/hosts or /etc/inet/ipnodes file must list the host name you will use and nsswitch.conf file must have files as the first choice on the hosts line. For IPv6 addresses, specify ipnodes as the first choice on the hosts line. Following is a summary of the steps that use the nisinit command.

To initialize a client by host name, use the -c and -H options, and include the name of the server from which the client will obtain its cold-start file:

nisinit -c -H hostname

To initialize a client by cold-start file, use the -c and -C options, and provide the name of the cold-start file:

nisinit -c -C filename

To initialize a client by broadcast, use the -c and -B options:

nisinit -c -B

Initializing the Root Master Server

To initialize the root master server, use the nisinit -rcommand:

nisinit -r

You will need the following information

• The superuser password of the machine that will become the root master server.

• The name of the new root domain. The root domain name must have at least two elements (labels) and end in a dot (for example, something.com.). The last element must be either an Internet organizational name (as shown in Table 18-4), or a two or three character geographic identifier such as .jp. for Japan.

Table 18-4 Internet Organizational Domains

The nis_cachemgr Command

The nis_cachemgr command starts the NIS+ cache manager program, which should run on all NIS+ clients. The cache manager maintains a cache of location information about the NIS+ servers that support the most frequently used directories in the namespace, including transport addresses, authentication information, and a time-to-live value.

At start-up the cache manager obtains its initial information from the client's cold-start file, and downloads it into the /var/nis/NIS_SHARED_DIRCACHE file.

The cache manager makes requests as a client machine. Make sure the client machine has the proper credentials, or instead of improving performance, the cache manager will degrade it.

Starting and Stopping the Cache Manager

To start the cache manager, enter the nis_cachemgr command (with or without the -i option):

client% nis_cachemgr
client% nis_cachemgr -i

Without the -i option, the cache manager is restarted but it retains the information in the /var/nis/NIS_SHARED_DIRCACHE file. The information in the cold-start file is simply appended to the existing information in the file. The -i option clears the cache file and re-initializes it from the contents of the client's cold-start file.

To stop the cache manager, kill it as you would any other process.

The nisshowcache Command

The nisshowcache command displays the contents of a client's directory cache.

Displaying the Contents of the NIS+ Cache

The nisshowcache command is located in /usr/lib/nis. It displays only the cache header and the directory names. Here is an example entered from the root master server:

rootmaster# /usr/lib/nis/nisshowcache -v
Cold Start directory:
Name : doc.com.
Type : NIS
Master Server :
 Name : rootmaster.doc.com.
 Public Key : Diffie-Hellman (192 bits)
 Universal addresses (3)
 . .
Replicate:
 Name : rootreplica1.doc.com.
 Public Key : Diffie-Hellman (192 bits)
 Universal addresses (3)
 .
 .
 .
Time to live : 12:0:0
Default Access Rights :

Pinging and Checkpointing

When a change is made to the NIS+ data set, that change is made in the memory of the master server for the NIS+ domain (or subdomain). A record of the change is also logged in the master server's transaction log (/var/nis/data/trans.log).

Normally, the master server transfers a change in the NIS+ data set to the domain's replica servers 120 seconds (2 minutes) after the change was made. This transfer process is called pinging. When the master server pings a replica, it updates the replica's data set with the change. The changed NIS+ data now resides in memory of the master and replica servers.

If the automatic ping process fails to update one or more replica servers, you need to manually force a ping as described in "Forcing a Ping". If you suspect that a replica has not been correctly updated with the most current NIS+ data, you can check when the replica was last updated as described in "Displaying When Replicas Were Last Updated".

Changes to the NIS+ data set stored in server memory and recorded in the transaction log need to be written into the NIS+ tables stored on disk. The process of updating the NIS+ tables is called checkpointing.

Checkpointing is not an automatic process. You must issue the checkpoint command as described in "Checkpointing a Directory".