NIS+ Administration Problems

This section describes problems that may be encountered in the course of routine NIS+ namespace administration work. Common symptoms include:

• “Illegal object type” for operation message.

• Other “object problem” error messages

• Initialization failure

• Checkpoint failures

• Difficulty adding a user to a group

• Logs too large/lack of disk space/difficulty truncating logs

• Cannot delete groups_dir or org_dir

Illegal Object Problems

Symptoms

• "Illegal object type" for operation message

• Other “object problem” error messages

There are a number of possible causes for this error message:

• You have attempted to create a table without any searchable columns.

• A database operation has returned the status of DB_BADOBJECT (see the nis_db man page for information on the db error codes).

• You are trying to add or modify a database object with a length of zero.

• You attempted to add an object without an owner.

• The operation expected a directory object, and the object you named was not a directory object.

• You attempted to link a directory to a LINK object.

• You attempted to link a table entry.

• An object that was not a group object was passed to the nisgrpadm command.

• An operation on a group object was expected, but the type of object specified was not a group object.

• An operation on a table object was expected, but the object specified was not a table object.

nisinit Fails

Make sure that:

• You can ping the NIS+ server to check that it is up and running as a machine.

• The NIS+ server that you specified with the -H option is a valid server and that it is running the NIS+ software.

• rpc.nisd is running on the server.

• The nobody class has read permission for this domain.

• The netmask is properly set up on this machine.

Checkpoint Keeps Failing

If checkpoint operations with a nisping -C command consistently fail, make sure you have sufficient swap and disk space. Check for error messages in syslog. Check for core files filling up space.

Cannot Add User to a Group

A user must first be an NIS+ principal client with a LOCAL credential in the domain's cred table before the user can be added as a member of a group in that domain. A DES credential alone is not sufficient.

Logs Grow too Large

Failure to regularly checkpoint your system with nisping -C causes your log files to grow too large. Logs are not cleared on a master until all replicas for that master are updated. If a replica is down or otherwise out of service or unreachable, the master's logs for that replica cannot be cleared. Thus, if a replica is going to be down or out of service for a period of time, you should remove it as a replica from the master as described in Removing a Directory. Keep in mind that you must first remove the directory's org_dir and groups_dir subdirectories before you remove the directory itself.

Lack of Disk Space

Lack of sufficient disk space will cause a variety of different error messages. (See Insufficient Disk Space for additional information.)

Cannot Truncate Transaction Log File

First, check to make sure that the file in question exists and is readable and that you have permission to write to it.

• You can use ls /var/nis/trans.log to display the transaction log.

• You can use nisls -l and niscat to check for existence, permissions, and readability.

• You can use syslog to check for relevant messages.

The most likely cause of inability to truncate an existing log file for which you have the proper permissions is lack of disk space. (The checkpoint process first creates a duplicate temporary file of the log before truncating the log and then removing the temporary file. If there is not enough disk space for the temporary file, the checkpoint process cannot proceed.) Check your available disk space and free up additional space if necessary.

Domain Name Confusion

Domain names play a key role in many NIS+ commands and operations. To avoid confusion, you must remember that, except for root servers, all NIS+ masters and replicas are clients of the domain above the domain that they serve. If you make the mistake of treating a server or replica as if it were a client of the domain that it serves, you may get Generic system error or Possible loop detected in namespace directoryname:domainname error messages.

For example, the machine altair might be a client of the subdoc.doc.com. domain. If the master server of the subdoc.doc.com. subdomain is the machine sirius, then sirius is a client of the doc.com. domain. When using, specifying, or changing domains, remember these rules to avoid confusion:

1. Client machines belong to a given domain or subdomain.

2. Servers and replicas that serve a given subdomain are clients of the domain above the domain they are serving.

3. The only exception to Rule 2 is that the root master server and root replica servers are clients of the same domain that they serve. In other words, the root master and root replicas are all clients of the root domain.

Thus, in the example above, the fully qualified name of the altair machine is alladin.subdoc.doc.com. The fully qualified name of the sirius machine is sirius.doc.com. The name sirius.subdoc.doc.com. is wrong and will cause an error because sirius is a client of doc.com., not subdoc.doc.com.

Cannot Delete org_dir or groups_dir

Always delete org_dir and groups_dir before deleting their parent directory. If you use nisrmdir to delete the domain before deleting the domain's groups_dir and org_dir, you will not be able to delete either of those two subdirectories.

Removal or Disassociation of NIS+ Directory from Replica Fails

When removing or disassociating a directory from a replica server you must first remove the directory's org_dir and groups_dir subdirectories before removing the directory itself. After each subdirectory is removed, you must run nisping on the parent directory of the directory you intend to remove. (See Removing a Directory.)

If you fail to perform the nisping operation, the directory will not be completely removed or disassociated.

If this occurs, you need to perform the following steps to correct the problem:

1. Remove /var/nis/rep/org_dir on the replica.

2. Make sure that org_dir.domain does not appear in /var/nis/rep/serving_list on the replica.

3. Perform a nisping on domain.

4. From the master server, run nisrmdir -f replica_directory.

If the replica server you are trying to dissociate is down or out of communication, the nisrmdir -s command will return a Cannot remove replica name: 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.