Adding a Replica to an Existing Directory

This section describes how to add a replica server to an existing system using the nismkdir command. An easier way to do this is with the nisserver script.

Keep in mind the following principles:

• Root domain servers reside in (are part of) the root domain.

• Subdomain servers reside in (are part of) the parent domain immediately above the subdomain in the hierarchy. For example, if a namespace has one root domain named prime and a subdomain named sub1:

  • The master and replica servers that serve the prime domain are themselves part of the prime domain because prime is the root domain.

  • The master and replica servers that serve the sub1 subdomain are also part of the prime domain because prime is the parent of sub1.

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

To assign a new replica server to an existing directory, use nismkdir on the master server with the -s option and the name of the existing directory, org_dir, and groups_dir:

nismkdir -s replica-server existing-directory-name
nismkdir -s replica-server org_dir. existing-directory-name
nismkdir -s replica-server groups_dir. existing-directory-name

The nismkdir command realizes that the directory already exists, so it does not recreate it. It only assigns it the additional replica. Here is an example with rep1 being the name of the new replica machine:

rootmaster% nismkdir -s rep1.doc.com. doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.doc.com.

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.

After running the three iterations of nismkdir as shown above, you need to run nisping from the master server on the three directories:

rootmaster# nisping doc.com.
rootmaster# nisping org_dir.doc.com.
rootmaster# nisping group_dir.doc.com.

You should see results similar to these:

rootmaster# nisping doc.com.
Pinging replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 18 19:54:38 1995
Replica server is rep1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1995
 Pinging ... rep1.doc.com

It is good practice to include nisping commands for each of these three directories in the master server's cron file so that each directory is "pinged" at least once every 24 hours after being updated.

The nisrmdir Command

The nisrmdir command can remove a directory or simply dissociate a replica server from a directory. (When a directory is removed or disassociated from a replica server, that machine no longer functions as an NIS+ replica server for that NIS+ domain.)

When it removes a directory, NIS+ first disassociates the master and replica servers from the directory, and then removes the directory.

• To remove the directory, you must have destroy rights to its parent directory.

• To dissociate a replica server from a directory, you must have modify rights to the directory.

If problems occur, see "Removal or Disassociation of NIS+ Directory from Replica Fails".

Removing a Directory

To remove an entire directory and dissociate its master and replica servers, use the nisrmdir command without any options:

nisrmdir directory-name
nisping domain

This example removes the manf.doc.com. directory from beneath the doc.com. directory:

rootmaster% nisrmdir manf.doc.com.
rootmaster% nisping doc.com.

Disassociating a Replica From a Directory

To disassociate a replica server from a directory, you must first remove the directory's org_dir and groups_dir subdirectories. To do this, use the nisrmdir command with the -s option. After each of the subdirectories are removed, you must run nisping on parent domain.

nisrmdir -s replicanameorg_dir.domain
nisrmdir -s replicanamegroups_dir.domain
nisrmdir -s replicaname domain
nisping domain

This example disassociates the manfreplica1 server from the manf.doc.com. directory:

rootmaster% nisrmdir -s manfreplica1 org_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 groups_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 manf.doc.com.
rootmaster% nisping manf.doc.com.

If the replica server you are trying to dissociate is down or out of communication, the nisrmdir -s command returns a Cannot remove replicaname: attempt to remove a non-empty table error message. In such cases, you can run nisrmdir -f -s replicaname on the master to force the dissociation. Note, however, that if you use nisrmdir -f -s to dissociate an out-of-communication replica, you must run nisrmdir -f -s again as soon as the replica is back on line in order to clean up the replica's /var/nis file system. If you fail to rerun nisrmdir -f -s replicaname when the replica is back in service, the old out-of-date information left on the replica could cause problems.

The nisrm Command

The nisrm command is similar to the standard rm system command. It removes any NIS+ object from the namespace, except directories and nonempty tables. To use the nisrm command, you must have destroy rights to the object. However, if you don't, you can use the -f option, which tries to force the operation in spite of permissions.

You can remove group objects with the nisgrpadm -d command (see "Deleting an NIS+ Group"), and you can empty tables with nistbladm -r or nistbladm -R (see "Deleting a Table").

To remove a nondirectory object, use:

nisrm [-if] object-name

Table 18-2 nisrm Syntax Options

Removing Nondirectory Objects

To remove nondirectory objects, use the nisrm command and provide the object names:

nisrm object-name...

This example removes a group and a table from the namespace:

rootmaster% nisrm -i admins.doc.com. groups.org_dir.doc.com.
Remove admins.doc.com.? y
Remove groups.org_dir.doc.com.? y

The rpc.nisd Command

The rpc.nisd command starts the NIS+ daemon. The daemon can run in NIS-compatibility mode, which enables it to answer requests from NIS clients as well. You don't need any access rights to start the NIS+ daemon, but you should be aware of all its prerequisites and related tasks. They are described in "Prerequisites to Running rpc.nisd".

By default, the NIS+ daemon starts with security level 2.

To start the daemon, use:

rpc.nisd

To start the daemon in NIS-compatibility mode, use:

rpc.nisd -Y [-B]

To start an NIS-compatible daemon with DNS forwarding capabilities, use:

rpc.nisd -Y -B

Table 18-3 Other rpc.nisd Syntax Options

To start the NIS+ daemon on any server, use the command without options:

rpc.nisd

The daemon starts with security level 2, which is the default.

To start the daemon with security level 0, use the -S flag:

rpc.nisd -S 0