test

Solaris Naming Administration Guide

Part VII Appendices

This part of the manual provides reference material.

Appendix A Problems and Solutions

This appendix describes some of the problems you may encounter while administering Solaris operating environment namespaces and how to correct them.

Troubleshooting NIS+

In this appendix, problems are grouped according to type. For each problem there is a list of common symptoms, a description of the problem, and one or more suggested solutions.

In addition to this appendix, there is an appendix containing an alphabetic listing of the more common NIS+ error messages. If you are responding to a specific error message, check Appendix B, Error Messages, first. If the problem is simple, or specific to a single error message, its solution is usually described in Appendix B, Error Messages.

NIS+ Debugging Options

The NIS_OPTIONS environment variable can be set to control various NIS+ debugging options.

Options are specified after the NIS_OPTIONS command separated by spaces with the option set enclosed in double quotes. Each option has the format name=value. Values can be integers, character strings, or filenames depending on the particular option. If a value is not specified for an integer value option, the value defaults to 1.

NIS_OPTIONS recognizes the following options:

Table A-1 NIS_OPTIONS Options and Values

Option 

Values 

Actions 

debug_file

filename

Directs debug output to specified file. If this option is not specified, debug output goes to stdout.

debug_bind

Number

Displays information about the server selection process. 

debug_rpc

1 or 2

If the value is 1, displays RPC calls made to the NIS+ server and the RPC result code. If the value is 2, displays both the RPC calls and the contents of the RPC and arguments and results. 

debug_calls

Number

Displays calls to the NIS+ API and the results that are returned to the application. 

pref_srvr

String

Specifies preferred servers in the same format as that generated by the nisprefadm command (see Table 15-1). This will over-ride the preferred server list specified in nis_cachemgr.

server

String

Bind to a particular server. 

pref_type

String

Not currently implemented. 

For example, (assuming that you are using a C-Shell):


setenv NIS_OPTIONS "debug_calls=2 debug_bind debug_rpc"
 

setenv NIS_OPTIONS "debug_calls debug_file=/tmp/CALLS"
 

setenv NIS_OPTIONS "debug_calls server=sirius"

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 Problems

Symptoms

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

nisinit Fails

Make sure that:

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.

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.

NIS+ Database Problems

This section covers problems related to the namespace database and tables. Common symptoms include error messages with operative clauses such as:

as well as when rpc.nisd fails.

See also "NIS+ Ownership and Permission Problems".

Multiple rpc.nisd Parent Processes

Symptoms:

Various Database and transaction log corruption error messages containing the terms:

Possible Causes:

You have multiple independent rpc.nisd daemons running. In normal operation, rpc.nisd can spawn other child rpc.nisd daemons. This causes no problem. However, if two parent rpc.nisd daemons are running at the same time on the same machine, they will overwrite each other's data and corrupt logs and databases. (Normally, this could only occur if someone started running rpc.nisd by hand.)

Diagnosis:

Run ps -ef | grep rpc.nisd. Make sure that you have no more than one parent rpc.nisd process.

Solution:

If you have more than one "parent" rpc.nisd entries, you must kill all but one of them. Use kill -9 process-id, then run the ps command again to make sure it has died.

Note -

If you started rpc.nisd with the -B option, you must also kill the rpc.nisd_resolv daemon.

If an NIS+ database is corrupt, you will also have to restore it from your most recent backup that contains an uncorrupted version of the database. You can then use the logs to update changes made to your namespace since the backup was recorded. However, if your logs are also corrupted, you will have to recreate by hand any namespace modifications made since the backup was taken.

rpc.nisd Fails

If an NIS+ table is too large, rpc.nisd may fail.

Diagnosis:

Use nisls to check your NIS+ table sizes. Tables larger than 7k may cause rpc.nisd to fail.

Solution:

Reduce the size of large NIS+ tables. Keep in mind that as a naming service NIS+ is designed to store references to objects, not the objects themselves.

NIS+ and NIS Compatibility Problems

This section describes problems having to do with NIS compatibility with NIS+ and earlier systems and the switch configuration file. Common symptoms include:

Error messages with operative clauses include:

User Cannot Log In After Password Change

Symptoms:

New users, or users who recently changed their password are unable to log in at all, or able to log in on one or more machines but not on others. The user may see error messages with operative clauses such as:

First Possible Cause:

Password was changed on NIS machine.

If a user or system administrator uses the passwd command to change a password on a Solaris operating environment machine running NIS in a domain served by NIS+ namespace servers, the user's password is changed only in that machine's /etc/passwd file. If the user then goes to some other machine on the network, the user's new password will not be recognized by that machine. The user will have to use the old password stored in the NIS+ passwd table.

Diagnosis:

Check to see if the user's old password is still valid on another NIS+ machine.

Solution:

Use passwd on a machine running NIS+ to change the user's password.

Second Possible Cause:

Password changes take time to propagate through the domain.

Diagnosis:

Namespace changes take a measurable amount of time to propagate through a domain and an entire system. This time might be as short as a few seconds or as long as many minutes, depending on the size of your domain and the number of replica servers.

Solution:

You can simply wait the normal amount of time for a change to propagate through your domain(s). Or you can use the nisping org_dir command to resynchronize your system.

nsswitch.conf File Fails to Perform Correctly

A modified (or newly installed) nsswitch.conf file fails to work properly.

Symptoms:

You install a new nsswitch.conf file or make changes to the existing file, but your system does not implement the changes.

Possible Cause:

Each time an nsswitch.conf file is installed or changed, you must reboot the machine for your changes to take effect. This is because nscd caches the nsswitch.conf file.

Solution:

Check your nsswitch.conf file against the information contained in the nsswitch.conf man page. Correct the file if necessary, and then reboot the machine.

NIS+ Object Not Found Problems

This section describes problem in which NIS+ was unable to find some object or principal. Common symptoms include:

Error messages with operative clauses such as:

Syntax or Spelling Error

The most likely cause of some NIS+ object not being found is that you mistyped or misspelled its name. Check the syntax and make sure that you are using the correct name.

Incorrect Path

A likely cause of an "object not found" problem is specifying an incorrect path. Make sure that the path you specified is correct. Also make sure that the NIS_PATH environment variable is set correctly.

Domain Levels Not Correctly Specified

Remember that all servers are clients of the domain above them, not the domain they serve. There are two exceptions to this rule:

Object Does Not Exist

The NIS+ object may not have been found because it does not exist, either because it has been erased or not yet created. Use nisls -lin the appropriate domain to check that the object exists.

Lagging or Out-of-Sync Replica

When you create or modify an NIS+ object, there is a time lag between the completion of your action and the arrival of the new updated information at a given replica. In ordinary operation, namespace information may be queried from a master or any of its replicas. A client automatically distributes queries among the various servers (master and replicas) to balance system load. This means that at any given moment you do not know which machine is supplying you with namespace information. If a command relating to a newly created or modified object is sent to a replica that has not yet received the updated information from the master, you will get an "object not found" type of error or the old out-of-date information. Similarly, a general command such as nisls may not list a newly created object if the system sends the nisls query to a replica that has not yet been updated.

You can use nisping to resync a lagging or out of sync replica server.

Alternatively, you can use the -M option with most NIS+ commands to specify that the command must obtain namespace information from the domain's master server. In this way you can be sure that you are obtaining and using the most up-to-date information. (However, you should use the -M option only when necessary because a main point of having and using replicas to serve the namespace is to distribute the load and thus increase network efficiency.)

Files Missing or Corrupt

One or more of the files in /var/nis/data directory has become corrupted or erased. Restore these files from your most recent backup.

Old /var/nis Filenames

In Solaris Release 2.4 and earlier, the /var/nis directory contained two files named hostname.dict and hostname.log. It also contained a subdirectory named /var/nis/hostname. Starting with Solaris Release 2.5, the two files were renamed trans.log and data.dict, and the subdirectory is named /var/nis/data.

Do not rename the /var/nis or /var/nis/data directories or any of the files in these directories that were created by nisinit or any of the other NIS+ setup procedures.

In Solaris Release 2.5, the content of the files were also changed and they are not backward compatible with Solaris Release 2.4 or earlier. Thus, if you rename either the directories or the files to match the Solaris Release 2.4 patterns, the files will not work with either the Solaris Release 2.4 or the Solaris Release 2.5 or later versions of rpc.nisd. Therefore, you should not rename either the directories or the files.

Blanks in Name

Symptoms:

Sometimes an object is there, sometimes it is not. Some NIS+ or UNIX commands report that an NIS+ object does not exist or cannot be found, while other NIS+ or UNIX commands do find that same object.

Diagnoses:

Use nisls to display the object's name. Look carefully at the object's name to see if the name actually begins with a blank space. (If you accidentally enter two spaces after the flag when creating NIS+ objects from the command line with NIS+ commands, some NIS+ commands will interpret the second space as the beginning of the object's name.)

Solution:

If an NIS+ object name begins with a blank space, you must either rename it without the space or remove it and then recreate it from scratch.

Cannot Use Automounter

Symptoms:

You cannot change to a directory on another host.

Possible Cause:

Under NIS+, automounter names must be renamed to meet NIS+ requirements. NIS+ cannot access /etc/auto* tables that contain a period in the name. For example, NIS+ cannot access a file named auto.direct.

Diagnosis:

Use nisls and niscat to determine if the automounter tables are properly constructed.

Solution:

Change the periods to underscores. For example, change auto.direct to auto_direct. (Be sure to change other maps that might reference these.)

Links To or From Table Entries Do Not Work

You cannot use the nisln command (or any other command) to create links between entries in tables. NIS+ commands do not follow links at the entry level.

NIS+ Ownership and Permission Problems

This section describes problems related to user ownership and permissions. Common symptoms include:

Error messages with operative clauses such as:

Another Symptom:

No Permission

The most common permission problem is the simplest: you have not been granted permission to perform some task that you try to do. Use niscat -o on the object in question to determine what permissions you have. If you need additional permission, you, the owner of the object, or the system administrator can either change the permission requirements of the object (as described in Chapter 10, Administering NIS+ Access Rights,) or add you to a group that does have the required permissions (as described in Chapter 12, Administering NIS+ Groups).

No Credentials

Without proper credentials for you and your machine, many operations will fail. Use nismatch on your home domain's cred table to make sure you have the right credentials. See "Corrupted Credentials" for more on credentials-related problems.

Server Running at Security Level 0

A server running at security level 0 does not create or maintain credentials for NIS+ principals.

If you try to use passwd on a server that is running at security level 0, you will get the error message: You name do not have secure RPC credentials in NIS+ domain domainname.

Security level 0 is only to be used by administrators for initial namespace setup and testing purposes. Level 0 should not be used in any environment where ordinary users are active.

User Login Same as Machine Name

A user cannot have the same login ID as a machine name. When a machine is given the same name as a user (or vice versa), the first principal can no longer perform operations requiring secure permissions because the second principal's key has overwritten the first principal's key in the cred table. In addition, the second principal now has whatever permissions were granted to the first principal.

For example, suppose a user with the login name of saladin is granted namespace read-only permissions. Then a machine named saladin is added to the domain. The user saladin will no longer be able to perform any namespace operations requiring any sort of permission, and the root user of the machine saladin will only have read-only permission in the namespace.

Symptoms:

Note -

When running nisclient or nisaddcred, if the message Changing Key is displayed rather than Adding Key, there is a duplicate user or host name already in existence in that domain.

Diagnosis:

Run nismatch to find the host and user in the hosts and passwd tables to see if there are identical host names and user names in the respective tables: 


nismatch username passwd.org_dir

Then run nismatch on the domain's cred table to see what type of credentials are provided for the duplicate host or user name. If there are both LOCAL and DES credentials, the cred table entry is for the user; if there is only a DES credential, the entry is for the machine.

Solution:

Change the machine name. (It is better to change the machine name than to change the user name.) Then delete the machine's entry from the cred table and use nisclient to reinitialize the machine as an NIS+ client. (If you wish, you can use nistbladm to create an alias for the machine's old name in the hosts tables.) If necessary, replace the user's credentials in the cred table.

Bad Credentials

See "Corrupted Credentials".

NIS+ Security Problems

This section describes common password, credential, encryption, and other security-related problems.

Security Problem Symptoms

Error messages with operative clauses such as:

User or root unable to perform any namespace operations or tasks. (See also "NIS+ Ownership and Permission Problems".)

Login Incorrect Message

The most common cause of a "login incorrect" message is the user mistyping the password. Have the user try it again. Make sure the user knows the correct password and understands that passwords are case-sensitive and also that the letter "o" is not interchangeable with the numeral "0," nor is the letter "l" the same as the numeral "1."

Other possible causes of the "login incorrect" message are:

See Chapter 11, Administering Passwords for general information on passwords.

Password Locked, Expired, or Terminated

A common cause of a Permission denied, password expired, type message is that the user's password has passed its age limit or the user's password privileges have expired. See Chapter 11, Administering Passwords for general information on passwords.

Stale and Outdated Credential Information

Occasionally, you may find that even though you have created the proper credentials and assigned the proper access rights, some client requests still get denied. This may be due to out-of-date information residing somewhere in the namespace.

Storing and Updating Credential Information

Credential-related information, such as public keys, is stored in many locations throughout the namespace. NIS+ updates this information periodically, depending on the time-to-live values of the objects that store it, but sometimes, between updates, it gets out of sync. As a result, you may find that operations that should work, don't work. Table A-2 lists all the objects, tables, and files that store credential-related information and how to reset it.

Table A-2 Where Credential-Related Information is Stored

Item 

Stores 

To Reset or Change 

cred table 

NIS+ principal's secret key and public key. These are the master copies of these keys. 

Use nisaddcred to create new credentials; it updates existing credentials. An alternative is chkey.

Directory object 

A copy of the public key of each server that supports it. 

Run the /usr/lib/nis/

nisupdkeys command on the directory object.

Keyserver 

The secret key of the NIS+ principal that is currently logged in. 

Run keylogin for a principal user or keylogin -r for a principal workstation.

NIS+ daemon 

Copies of directory objects, which in turn contain copies of their servers' public keys. 

Kill the daemon and the cache manager. Then restart both. 

Directory cache 

A copy of directory objects, which in turn contain copies of their servers' public keys. 

Kill the NIS+ cache manager and restart it with the nis_cachemgr -i command. The -i option resets the directory cache from the cold-start file and restarts the cache manager.

Cold-start file 

A copy of a directory object, which in turn contains copies of its servers' public keys. 

On the root master, kill the NIS+ daemon and restart it. The daemon reloads new information into the existing NIS_COLD_START file.

For a client, first remove the cold-start and shared directory files from /var/nis, and kill the cache manager. Then re-initialize the principal with nisinit -c. The principal's trusted server reloads new information into the principal's existing cold-start file.

passwd table 

A user's password or a workstation's superuser password. 

Use the passwd -r nisplus command. It changes the password in the NIS+ passwd table and updates it in the cred table.

passwd file

A user's password or a workstation's superuser password. 

Use the passwd -r nisplus command, whether logged in as superuser or as yourself, whichever is appropriate.

passwd map

(NIS) 

A user's password or a workstation's superuser password. 

Use passwd -r nisplus.

Updating Stale Cached Keys

The most commonly encountered out-of-date information is the existence of stale objects with old versions of a server's public key. You can usually correct this problem by running nisupdkeys on the domain you are trying to access. (See Chapter 7, Administering NIS+ Credentials for information on using the nisupdkeys command.)

Because some keys are stored in files or caches, nisupdkeys cannot always correct the problem. At times you might need to update the keys manually. To do that, you must understand how a server's public key, once created, is propagated through namespace objects. The process usually has five stages of propagation. Each stage is described below.

Stage 1: Server's Public Key Is Generated

An NIS+ server is first an NIS+ client. So, its public key is generated in the same way as any other NIS+ client's public key: with the nisaddcred command. The public key is then stored in the cred table of the server's home domain, not of the domain the server will eventually support.

Stage 2: Public Key Is Propagated to Directory Objects

Once you have set up an NIS+ domain and an NIS+ server, you can associate the server with a domain. This association is performed by the nismkdir command. When the nismkdir command associates the server with the directory, it also copies the server's public key from the cred table to the domain's directory object. For example, assume the server is a client of the doc.com. root domain, and is made the master server of the sales.doc.com. domain.

Figure A-1 Public Key is Propagated to Directory Objects

Graphic

Its public key is copied from the cred.org_dir.doc.com. domain and placed in the sales.doc.com. directory object. This can be verified with the niscat -o sales.doc.com. command.

Stage 3: Directory Objects Are Propagated Into Client Files

All NIS+ clients are initialized with the nisinit utility or with the nisclient script.

Among other things, nisinit (or nisclient) creates a cold-start file /var/nis/NIS_COLDSTART. The cold-start file is used to initialize the client's directory cache /var/nis/NIS_SHARED_DIRCACHE. The cold-start file contains a copy of the directory object of the client's domain. Since the directory object already contains a copy of the server's public key, the key is now propagated into the cold-start file of the client.

In addition when a client makes a request to a server outside its home domain, a copy of the remote domains directory object is stored in the client's NIS_SHARED_DIRCACHE file. You can examine the contents of the client's cache by using the nisshowcache command, described on page 184.

This is the extent of the propagation until a replica is added to the domain or the server's key changes.

Stage 4: When a Replica is Added to the Domain

When a replica server is added to a domain, the nisping command (described in "The nisping Command") is used to download the NIS+ tables, including the cred table, to the new replica. Therefore, the original server's public key is now also stored in the replica server's cred table.

Stage 5: When the Server's Public Key Is Changed

If you decide to change DES credentials for the server (that is, for the root identity on the server), its public key will change. As a result, the public key stored for that server in the cred table will be different from those stored in:

Most of these locations will be updated automatically within a time ranging from a few minutes to 12 hours. To update the server's keys in these locations immediately, use the commands:

Table A-3 Updating a Server's Keys

Location 

Command 

See 

Cred table of replica servers (instead of using nisping, you can wait a few minutes until the table is updated automatically)

nisping

"The nisping Command"

Directory object of domain supported by server 

nisupdkeys

"The nisupdkeys Command"

NIS_COLDSTART file of clients

nisinit -c

"The nisinit Command"

NIS_SHARED_DIRCACHE file of clients

nis_cachemgr

"The nis_cachemgr Command"

Note -

You must first kill the existing nis_cachemgr before restarting nis_cachemgr.

Corrupted Credentials

When a principal (user or machine) has a corrupt credential, that principal is unable to perform any namespace operations or tasks, not even nisls. This is because a corrupt credential provides no permissions at all, not even the permissions granted to the nobody class.

Symptoms:

User or root cannot perform any namespace tasks or operations. All namespace operations fail with a "permission denied" type of error message. The user or root cannot even perform a nisls operation.

Possible Cause:

Corrupted keys or a corrupt, out-of-date, or otherwise incorrect /etc/.rootkey file.

Diagnosis:

Use snoop to identify the bad credential.

Or, if the principal is listed, log in as the principal and try to run an NIS+ command on an object for which you are sure that the principal has proper authorization. For example, in most cases an object grants read authorization to the nobody class. Thus, the nisls object command should work for any principal listed in the cred table. If the command fails with a "permission denied" error, then the principal's credential is likely corrupted.

Solution

Keyserv Failure

The keyserv is unable to encrypt a session. There are several possible causes for this type of problem:

Possible Causes and Solutions:

Machine Previously Was an NIS+ Client

If this machine has been initialized before as an NIS+ client of the same domain, try keylogin -r and enter the root login password at the Secure RPC password prompt.

No Entry in the cred Table

To make sure that an NIS+ password for the principal (user or host) exists in the cred table, run the following command in the principal's home domain


nisgrep -A cname=principal cred.org_dir.domainname

If you are running nisgrep from another domain, the domainname must be fully qualified.

Changed Domain Name

Do not change a domain name.

If you change the name of an existing domain you will create authentication problems because the fully qualified original domain name is embedded in objects throughout your network.

If you have already changed a domain name and are experiencing authentication problems, or error messages containing terms like "malformed" or "illegal" in relation to a domain name, change the domain name back to its original name. The recommended procedure for renaming your domains is to create a new domain with the new name, set up your machines as servers and clients of the new domain, make sure they are performing correctly, and then remove the old domain.

When Changing a Machine to a Different Domain

If this machine is an NIS+ client and you are trying to change it to a client of a different domain, remove the /etc/.rootkey file, and then rerun the nisclient script using the network password supplied by your network administrator or taken from the nispopulate script.

NIS+ and Login Passwords in /etc/passwd File

Your NIS+ password is stored in the NIS+ passwd table. Your user login password may be stored in NIS+ passwd table or in your /etc/passwd file. (Your user password and NIS+ password can be the same or different.) To change a password in an /etc/passwd file, you must run the passwd command with the nsswitch.conf file set to files or with the -r files flag.

The nsswitch.conf file specifies which password is used for which purpose. If the nsswitch.conf file is directing system queries to the wrong location, you will get password and permission errors.

Secure RPC Password and Login Passwords Are Different

When a principal's login password is different from his or her Secure RPC password, keylogin cannot decrypt it at login time because keylogin defaults to using the principal's login password, and the private key was encrypted using the principal's Secure RPC password.

When this occurs the principal can log in to the system, but for NIS+ purposes is placed in the authorization class of nobody because the keyserver does not have a decrypted private key for that user. Since most NIS+ environments are set up to deny the nobody class create, destroy, and modify rights to most NIS+ objects this results in "permission denied" types errors when the user tries to access NIS+ objects.

Note -

In this context network password is sometimes used as a synonym for Secure RPC password. When prompted for your "network password," enter your Secure RPC password.

To be placed in one of the other authorization classes, a user in this situation must explicitly run the keylogin program and give the principal's Secure RPC password when keylogin prompts for password. (See "Keylogin".)

But an explicit keylogin provides only a temporary solution that is good only for the current login session. The keyserver now has a decrypted private key for the user, but the private key in the user's cred table is still encrypted using the user's Secure RPC password, which is different than the user's login password. The next time the user logs in, the same problem reoccurs. To permanently solve the problem the user needs to change the private key in the cred table to one based on the user's login ID rather than the user's Secure RPC password. To do this, the user need to run the chkey program as described in "Changing Keys for an NIS+ Principal".

Thus, to permanently solve a Secure RPC password different than login password problems, the user (or an administrator acting for the user) must perform the following steps:

  1. Log in using the login password.

  2. Run the keylogin program to temporarily get a decrypted private key stored in the keyserver and thus gain temporary NIS+ access privileges.

  3. Run chkey -pto permanently change the encrypted private key in the cred table to one based on the user's login password.

Preexisting /etc/.rootkey File

Symptoms:

Various insufficient permission to and permission denied error messages.

Possible Cause:

An /etc/.rootkey file already existed when you set up or initialized a server or client. This could occur if NIS+ had been previously installed on the machine and the .rootkey file was not erased when NIS+ was removed or the machine returned to using NIS or /etc files.

Diagnosis:

Run ls -l on the /etc directory and nisls -l org_dir and compare the date of the /etc/.rootkey to the date of the cred table. If the /etc/.rootkey date is clearly earlier than that of the cred table, it may be a preexisting file.

Solution:

Run keylogin -r as root on the problem machine and then set up the machine as a client again.

Root Password Change Causes Problem

Symptoms:

You change the root password on a machine, and the change either fails to take effect or you are unable to log in as superuser.

Possible Cause:

Note -

For security reasons, you should not have User ID 0 listed in the passwd table.

You changed the root password, but root's key was not properly updated. Either because you forgot to run chkey -p for root or some problem came up.

Solution

Log in as a user with administration privileges (that is, a user who is a member of a group with administration privileges) and use passwd to restore the old password. Make sure that old password works. Now use passwd to change root's password to the new one, and then run chkey -p.

Caution - Caution -

Once your NIS+ namespace is set up and running, you can change the root password on the root master machine. But do not change the root master keys, as these are embedded in all directory objects on all clients, replicas, and servers of subdomains. To avoid changing the root master keys, always use the -p option when running chkey as root.

NIS+ Performance and System Hang Problems

This section describes common slow performance and system hang problems.

Performance Problem Symptoms

Error messages with operative clauses such as:

Other common symptoms:

Checkpointing

Someone has issued an nisping or nisping -C command. Or the rpc.nisd daemon is performing a checkpoint operation.

Caution - Caution -

Do not reboot! Do not issue any more nisping commands.

When performing a nisping or checkpoint, the server will be sluggish or may not immediately respond to other commands. Depending on the size of your namespace, these commands may take a noticeable amount of time to complete. Delays caused by checkpoint or ping commands are multiplied if you, or someone else, enter several such commands at one time. Do not reboot. This kind of problem will solve itself. Just wait until the server finishes performing the nisping or checkpoint command.

During a full master-replica resync, the involved replica server will be taken out of service until the resync is complete. Do not reboot--just wait.

Variable NIS_PATH

Make sure that your NIS_PATH variable is set to something clean and simple. For example, the default: org_dir.$:$. A complex NIS_PATH, particularly one that itself contains a variable, will slow your system and may cause some operations to fail. (See "NIS_PATH Environment Variable" for more information.)

Do not use nistbladm to set nondefault table paths. Nondefault table paths will slow performance.

Table Paths

Do not use table paths because they will slow performance.

Too Many Replicas

Too many replicas for a domain degrade system performance during replication. There should be no more than 10 replicas in a given domain or subdomain. If you have more than five replicas in a domain, try removing some of them to see if that improves performance.

Recursive Groups

A recursive group is a group that contains the name of some other group. While including other groups in a group reduces your work as system administrator, doing so slows down the system. You should not use recursive groups.

Large NIS+ Database Logs at Start-up

When rpc.nisd starts up it goes through each log. If the logs are long, this process could take a long time. If your logs are long, you may want to checkpoint them using nisping -C before starting rpc.nisd.

The Master rpc.nisd Daemon Died

Symptoms:

If you used the -M option to specify that your request be sent to the master server, and the rpc.nisd daemon has died on that machine, you will get a "server not responding" type error message and no updates will be permitted. (If you did not use the -M option, your request will be automatically routed to a functioning replica server.)

Possible Cause:

Using uppercase letters in the name of a home directory or host can sometimes cause rpc.nisd to die.

Diagnosis:

First make sure that the server itself is up and running. If it is, run ps -ef | grep rpc.nisd to see if the daemon is still running.

Solution:

If the daemon has died, restart it. If rpc.nisd frequently dies, contact your service provider.

No nis_cachemgr

Symptoms:

It takes too long for a machine to locate namespace objects in other domains.

Possible Cause:

You do not have nis_cachemgr running.

Diagnosis:

Run ps -ef | grep nis_cachemgr to see if it is still running.

Solution

Start nis_cachemgr on that machine.

Server Very Slow at Start-up After NIS+ Installation

Symptoms:

A server performs slowly and sluggishly after using the NIS+ scripts to install NIS+ on it.

Possible Cause:

You forgot to run nisping -C -a after running the nispopulate script.

Solution:

Run nisping -C -a to checkpoint the system as soon as you are able to do so.

niscat Returns: Server busy. Try Again

Symptoms:

You run niscat and get an error message indicating that the server is busy.

Possible Cause:

Diagnosis:

Run swap -s to check your server's swap space.

Solution:

You must have adequate swap and disk space to run NIS+. If necessary, increase your space.

NIS+ Queries Hang After Changing Host Name

Symptoms:

Setting the host name for an NIS+ server to be fully qualified is not recommended. If you do so, and NIS+ queries then just hang with no error messages, check the following possibilities:

Possible Cause:

Fully qualified host names must meet the following criteria:

Solution:

Kill the NIS+ processes that are hanging and then kill rpc.nisd on that host or server. Rename the host to match the two requirements listed above. Then reinitialize the server with nisinit. (If queries still hang after you are sure that the host is correctly named, check other problem possibilities in this section.)

NIS+ System Resource Problems

This section describes problems having to do with lack of system resources such as memory, disk space, and so forth.

Resource Problem Symptoms

Error messages with operative clauses such as:

Insufficient Memory

Lack of sufficient memory or swap space on the system you are working with will cause a wide variety of NIS+ problems and error messages. As a short-term, temporary solution, try to free additional memory by killing unneeded windows and processes. If necessary, exit your windowing system and work from the terminal command line. If you still get messages indicating inadequate memory, you will have to install additional swap space or memory, or switch to a different system that has enough swap space or memory.

Under some circumstances, applications and processes may develop memory leaks and grow too large. you can check the current size of an application or process by running:


ps -el

The sz (size) column shows the current memory size of each process. If necessary, compare the sizes with comparable processes and applications on a machine that is not having memory problems to see if any have grown too large.

Insufficient Disk Space

Lack of disk space will cause a variety of error messages. A common cause of insufficient disk space is failure to regularly remove tmp files and truncate log files. log and tmp files grow steadily larger unless truncated. The speed at which these files grow varies from system to system and with the system state. log files on a system that is working inefficiently or having namespace problems will grow very fast.

Note -

If you are doing a lot of troubleshooting, check your log and tmp files frequently. Truncate log files and remove tmp files before lack of disk space creates additional problems. Also check the root directory and home directories for core files and delete them.

The way to truncate log files is to regularly checkpoint your system (Keep in mind that a checkpoint process may take some time and will slow down your system while it is being performed, checkpointing also requires enough disk space to create a complete copy of the files before they are truncated.)

To checkpoint a system, run nisping -C.

Insufficient Processes

On a heavily loaded machine it is possible that you could reach the maximum number of simultaneous processes that the machine is configured to handle. This causes messages with clauses like "unable to fork". The recommended method of handling this problem is to kill any unnecessary processes. If the problem persists, you can reconfigure the machine to handle more processes as described in your system administration documentation.

NIS+ User Problems

This section describes NIS+ problems that a typical user might encounter.

User Problem Symptoms

User Cannot Log In

There are many possible reasons for a user being unable to log in:

(See "nsswitch.conf File Requirements" for further details.)

User Cannot Log In Using New Password

Symptoms:

Users who recently changed their password are unable to log in at all, or are able to log in on some machines but not on others.

Possible Causes:

User Cannot Remote Log In to Remote Domain

Symptoms:

User tries to rlogin to a machine in some other domain and is refused with a "Permission denied" type error message.

Possible Cause:

To rlogin to a machine in another domain, a user must have LOCAL credentials in that domain.

Diagnosis:

Run nismatch username.domainname. cred.org_dir in the other domain to see if the user has a LOCAL credential in that domain.

Solution:

Go to the remote domain and use nisaddcred to create a LOCAL credential for the user in the that domain.

User Cannot Change Password

The most common cause of a user being unable to change passwords is that the user is mistyping (or has forgotten) the old password.

Other possible causes:

Other NIS+ Problems

This section describes problems that do not fit any of the previous categories.

How to Tell if NIS+ Is Running

You may need to know whether a given host is running NIS+. A script may also need to determine whether NIS+ is running.

You can assume that NIS+ is running if:

Replica Update Failure

Symptoms:

Error messages indicating that the update was not successfully complete. (Note that the message: replica_update: number updates number errors indicates a successful update.)

Possible Causes:

Any of the following error messages indicate that the server was busy and that the update should be rescheduled:

(These messages are generated by, or in conjunction with, the NIS+ error code constant: NIS_DUMPLATER one replica is already resyncing.)

These messages indicate that there was some other problem:

(If rpc.nisd is being run with the -C (open diagnostic channel) option, additional information may be entered in either the master server or replica server's system log.

These messages indicate possible problems such as:

Diagnosis:

Check both the replica and server's system log for additional information. How much, if any, additional information is recorded in the system logs depends on your system's error reporting level, and whether or not you are running rpc.nisd with the -C option (diagnostics).

Solution:

In most cases, these messages indicate minor software problems which the system is capable of correcting. If the message was the result of a command, simply wait for a while and then try the command again. If these messages appear often, you can change the threshold level in your /etc/syslog.conf file. See the syslog.conf man page for details.

NIS Problems and Solutions

This section explains how to resolve problems encountered on networks running NIS. It covers problems seen on an NIS client and those seen on an NIS server.

Before trying to debug an NIS server or client, review Chapter 18, Network Information Service (NIS), which explains the NIS environment. Then look for the subheading in this section that best describes your problem.

Symptoms:

Common symptoms of NIS binding problems include:

NIS Problems Affecting One Client

If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers (see "NIS Problems Affecting Many Clients").

ypbind Not Running on Client

One client has problems, but other clients on the same subnet are operating normally. On the problem client, run ls -l on a directory, such as /usr, that contains files owned by many users, including some not in the client /etc/passwd file. If the resulting display lists file owners who are not in the local /etc/passwd as numbers, rather than names, this indicates that NIS service is not working on the client.

These symptoms usually mean that the client ypbind process is not running. Run ps -e and check for ypbind. If you do not find it, log in as superuser and start ypbind by typing:


client# /usr/lib/netsvc/yp/ypstart

Missing or Incorrect Domain Name

One client has problems, the other clients are operating normally, but ypbind is running on the problem client. The client may have an incorrectly set domain.

On the client, run the domainname command to see which domain name is set.


Client#7 domainname neverland.com

Compare the output with the actual domain name in /var/yp on the NIS master server. The actual NIS domain is shown as a subdirectory in the /var/yp directory. 


Client#7 ls /var/yp...
-rwxr-xr-x 1 root Makefile
drwxr-xr-x 2 root binding
drwx------ 2 root doc.com
...

If the domain name returned by running domainname on a machine is not the same as the server domain name listed as a directory in /var/yp, the domain name specified in the machine's /etc/defaultdomain file is incorrect. Log in as superuser and correct the client's domain name in the machine's /etc/defaultdomain file. This assures that the domain name is correct every time the machine boots. Now reboot the machine.

Note -

The domain name is case-sensitive.

Client Not Bound to Server

If your domain name is set correctly, ypbind is running, and commands still hang, then make sure that the client is bound to a server by running the ypwhich command. If you have just started ypbind, then run ypwhich several times (typically, the first one reports that the domain is not bound and the second succeeds normally).

No Server Available

If your domain name is set correctly, ypbind is running, and you get messages indicating that the client cannot communicate with a server, this may indicate a number of different problems:

Note -

For reasons of security and administrative control it is preferable to specify the servers a client is to bind to in the client's ypservers file rather than have the client search for servers through broadcasting. Broadcasting ties up the network, slows the client, and prevents you from balancing server load by listing different servers for different clients.

ypwhich Displays Are Inconsistent

When you use ypwhich several times on the same client, the resulting display varies because the NIS server changes. This is normal. The binding of the NIS client to the NIS server changes over time when the network or the NIS servers are busy. Whenever possible, the network stabilizes at a point where all clients get acceptable response time from the NIS servers. As long as your client machine gets NIS service, it does not matter where the service comes from. For example, an NIS server machine may get its own NIS services from another NIS server on the network.

When Server Binding is Not Possible

In extreme cases where local server binding is not possible, use of the ypset command may temporarily allow binding to another server, if available, on another network or subnet. However, in order to use the -ypset option, ypbind must be started with either the -ypset or -ypsetme options.

Note -

For security reasons, the use of the -ypset and -ypsetme options should be limited to debugging purposes under controlled circumstances. Use of the -ypset and -ypsetme options can result in serious security breaches because while they are operative anyone can then alter server bindings causing trouble for others and permitting unauthorized access to sensitive data. If you must start ypbind with these options, once you have fixed the problem you should kill ypbind and restart it again without those options.

ypbind Crashes

If ypbind crashes almost immediately each time it is started, look for a problem in some other part of the system. Check for the presence of the rpcbind daemon by typing:


% ps -ef | grep rpcbind

If rpcbind is not present or does not stay up or behaves strangely, consult your RPC documentation.

You may be able to communicate with rpcbind on the problematic client from a machine operating normally. From the functioning machine, type:


% rpcinfo client

If rpcbind on the problematic machine is fine, rpcinfo produces the following output:


program	version	netid	address	service	owner
...
100007	2	udp	0.0.0.0.2.219	ypbind	superuser
100007	1	udp	0.0.0.0.2.219	ypbind	superuser
100007	1	tcp	0.0.0.0.2.220	ypbind	superuser
100007	2	tcp	0.0.0.0.128.4	ypbind	superuser
100007	2	ticotsord	\000\000\020H	ypbind	superuser
100007	2	ticots	\000\000\020K	ypbind	superuser
...

Your machine will have different addresses. If they are not displayed, ypbind has been unable to register its services. Reboot the machine and run rpcinfo again. If the ypbind processes are there and they change each time you try to restart /usr/lib/netsvc/yp/ypbind, reboot the system, even if the rpcbind daemon is running.

NIS Problems Affecting Many Clients

If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients (see "NIS Problems Affecting One Client"). If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers.

Network or Servers are Overloaded

NIS can hang if the network or NIS servers are so overloaded that ypserv cannot get a response back to the client ypbind process within the time-out period.

Under these circumstances, every client on the network experiences the same or similar problems. In most cases, the condition is temporary. The messages usually go away when the NIS server reboots and restarts ypserv, or when the load on the NIS servers or network itself decreases.

Server Malfunction

Make sure the servers are up and running. If you are not physically near the servers, use the ping command.

NIS Daemons Not Running

If the servers are up and running, try to find a client machine behaving normally, and run the ypwhich command. If ypwhich does not respond, kill it. Then log in as root on the NIS server and check if the NIS ypbind process is running by entering:


# ps -e | grep yp
Note -

Do not use the -f option with ps because this option attempts to translate user IDs to names which causes more name service lookups that may not succeed.

If either the ypbind or ypserv daemons are not running, kill them and then restart them by entering:


# /usr/lib/netsvc/yp/ypstop
# /usr/lib/netsvc/yp/ypstart

If both the ypserv and ypbind processes are running on the NIS server, type:


# ypwhich

If ypwhich does not respond, ypserv has probably hung and should be restarted. While logged in as root on the server, kill ypserv and restart it by typing:


# /usr/lib/netsvc/yp/ypstop
# /usr/lib/netsvc/yp/ypstart

Servers Have Different Versions of an NIS Map

Because NIS propagates maps among servers, occasionally you may find different versions of the same map on various NIS servers on the network. This version discrepancy is normal add acceptable if the differences do not last for more than a short time.

The most common cause of map discrepancy is that something is preventing normal map propagation. For example, an NIS server or router between NIS servers is down. When all NIS servers and the routers between them are running, ypxfr should succeed.

If the servers and routers are functioning properly, check the following:

Logging ypxfr Output

If a particular slave server has problems updating maps, log in to that server and run ypxfr interactively. If ypxfr fails, it tells you why it failed, and you can fix the problem. If ypxfr succeeds, but you suspect it has occasionally failed, create a log file to enable logging of messages. To create a log file, enter: 


ypslave# cd /var/yp
ypslave# touch ypxfr.log

This creates a ypxfr.log file that saves all output from ypxfr.

The output resembles the output ypxfr displays when run interactively, but each line in the log file is time stamped. (You may see unusual ordering in the time-stamps. That is okay--the time-stamp tells you when ypxfr started to run. If copies of ypxfr ran simultaneously but their work took differing amounts of time, they may actually write their summary status line to the log files in an order different from that which they were invoked.) Any pattern of intermittent failure shows up in the log.

Note -

When you have fixed the problem, turn off logging by removing the log file. If you forget to remove it, it continues to grow without limit.

Check the crontab File and ypxfr Shell Script

Inspect the root crontab file, and check the ypxfr shell script it invokes. Typographical errors in these files can cause propagation problems. Failures to refer to a shell script within the /var/spool/cron/crontabs/root file, or failures to refer to a map within any shell script can also cause errors.

Check the ypservers Map

Also, make sure that the NIS slave server is listed in the ypservers map on the master server for the domain. If it is not, the slave server still operates perfectly as a server, but yppush does not propagate map changes to the slave server.

Work Around

If the NIS slave server problem is not obvious, you can work around it while you debug using rcp or ftp to copy a recent version of the inconsistent map from any healthy NIS server. For instance, here is how you might transfer the problem map: 


 ypslave# rcp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain

Here the * character has been escaped in the command line, so that it will be expanded on ypmaster, instead of locally on ypslave.

ypserv Crashes

When the ypserv process crashes almost immediately, and does not stay up even with repeated activations, the debug process is virtually identical to that described in "ypbind Crashes". Check for the existence of the rpcbind daemon as follows:


ypserver% ps -e | grep rpcbind

Reboot the server if you do not find the daemon. Otherwise, if the daemon is running, type the following and look for similar output:


% rpcinfo -p ypserver
program 	vers 	proto 	port 	service
100000	4	tcp	111	portmapper
100000	3	tcp	111	portmapper
100068	2	udp	32813	cmsd
...
100007	1	tcp	34900	ypbind
100004	2	udp	731	ypserv
100004	1	udp	731	ypserv
100004	1	tcp	732	ypserv
100004	2	tcp	32772	ypserv

Your machine may have different port numbers. The four entries representing the ypserv process are:


100004 	2 	udp 	731 	ypserv
100004 	1 	udp 	731 	ypserv
100004 	1 	tcp 	732 	ypserv
100004 	2 	tcp 	32772 	ypserv

If they are not present, and ypserv is unable to register its services with rpcbind, reboot the machine. If they are present, deregister the service from rpcbind before restarting ypserv. To deregister the service from rpcbind, on the server type:


# rpcinfo -d number 1
# rpcinfo -d number 2

Where number is the ID number reported by rpcinfo (100004, in the example above).

DNS Problems and Solutions

This section describes some common DNS problems and how to solve them.

Clients Can Find Machine by Name but Server Cannot

Symptoms:

DNS clients can find machines by either IP address or by host name, but the server can only find machines by their IP addresses.

Probable cause and solution:

This is most likely caused by omitting DNS from the hosts line of the server's nsswitch.conf file. For example, a bad hosts line might look like this: hosts: files

When using DNS you must include dns in the hosts record of every machine's nsswitch.conf file. For example:


hosts: dns nisplus [NOTFOUND=return] files

or


hosts: nisplus dns [NOTFOUND=return] files

Changes Do Not Take Effect or Are Erratic

Symptom:

You add or delete machines or servers but your changes are not recognized or do not take effect. Or in some instances the changes are recognized and at other times they are not in effect.

Probable cause:

The most likely cause is that you forgot to increment the SOA serial number on the primary master server after you made your change. Since there is no new SOA number, your secondary servers do not update their data to match that of the primary so they are working with the old, unchanged data files.

Another possible cause is that the SOA serial number in one or more of the primary data files was set to a value lower than the corresponding serial number on your secondary servers. This could happen, for example, if you deleted a file on the primary and then recreated it from scratch using an input file of some sort.

A third possible cause is that you forgot to send a HUP signal to the primary server after making changes to the primary's data files.

Diagnosis and solution:

First, check the SOA serial numbers in the data file that you changed and the corresponding file on the secondary server.

DNS Client Cannot Lookup "Short" Names

Symptoms:

Client can lookup fully qualified names but not short names.

Possible cause and solution:

Check the client's /etc/resolv.conf file for spaces at the end of the domain name. No spaces or tabs are allowed at the end of the domain name.

Reverse Domain Data Not Correctly Transferred to Secondary

While zone domain-named data is properly transferred from the zone primary master server to a zone secondary server, the reverse domain data is not being transferred. In other words, the host.rev file on the secondary is not being properly updated from the primary.

Possible causes:

Syntax error in the secondary server's boot file.

Diagnosis and Solution:

Check the secondary server's boot file. Make sure that the primary server's IP address is listed for the reverse zone entries just as it is for the hosts data.

For example, the following boot file is incorrect because the primary server's IP address (129.146.168.119) is missing from the secondary in-addr.arpa record:


;
; /etc/named.boot file for dnssecondary
directory /var/named
secondary   doc.com   129.146.168.119        dnshosts.bakup
secondary   168.146.129.in-addr.arpa  doc.rev.bakup

This is what the correct file should look like:


;
; /etc/named.boot file for dnssecondary
directory /var/named
secondary   doc.com   129.146.168.119        dnshosts.bakup
secondary   168.146.129.in-addr.arpa   129.146.168.119  doc.rev.bakup

Server Failed and Zone Expired Problems

When a secondary server cannot obtain updates from its master, it logs a master unreachable message. If the problem is not corrected, the secondary expires the zone and stops answering requests from clients. When that happens, users start seeing server failed messages.

Symptoms:

Note that if the problem lies with a secondary server, some users could still be successfully obtaining DNS information from the master and thus operating without experiencing any difficulty.

Possible causes:

The two most likely causes for these problems are network failure and a wrong IP address for the master in the secondary's boot file.

Diagnosis and solution:

Make sure that the IP address of the master matches the master's actual IP address and the address for the master specified in the hosts file. If the IP address is wrong, correct it, and then reboot the secondary.


% ping 129.146.168.119 -n 10

rlogin, rsh, and ftp Problems

Symptoms:

Possible causes:

Diagnosis and solution:

Check the appropriate hosts.rev file and make sure there is a PTR record for the user's machine. For example, if the user is working at the machine altair.doc.com with an IP address of 129.146.168.46, the doc.com primary master server's doc.rev file should have an entry like:


46 	IN	 PTR 	altair.doc.com.

If the record is missing, add it to the hosts.rev file and then reboot the server or reload its data as explained in "Forcing in.named to Reload DNS Data".

Check and correct the NS entries in the hosts.rev files and then reboot the server or reload its data as explained in "Forcing in.named to Reload DNS Data".

Other DNS Syntax Errors

Symptoms:

Error messages in console or syslog with operative phrases like the following are most often caused by syntax errors in DNS data and boot files:

Check the relevant files for spelling and syntax errors.

A common syntax error is misuse of the trailing dot in domain names (either using the dot when you should not, or not using it when you should). See "Trailing Dots in Domain Names".

FNS Problems and Solutions

This section presents problem scenarios with a description of probable causes, diagnoses, and solutions.

See "FNS Error Messages" for general information about FNS error messages, and Appendix B, Error Messages.

Cannot Obtain Initial Context

Symptom:

You get the message Cannot obtain initial context.

Possible Cause:

This is caused by an installation problem.

Diagnosis:

Check that FNS has been installed properly by looking for the file, /usr/lib/fn/fn_ctx_initial.so.

Solution:

Install the fn_ctx_initial.so library.

Nothing in Initial Context

Symptom:

When you run fnlist to see what is in the initial context, you see nothing.

Possible Cause:

This is caused by an NIS+ configuration problem. The organization associated with the user and machine running the fn* commands do not have an associated ctx_dir directory.

Diagnosis:

Use the nisls command to see whether there is a ctx_dir directory.

Solution:

If there is no ctx_dir directory, run fncreate -t org/nis+_domain_name/ to create the ctx_dir directory.

"No Permission" Messages (FNS)

Symptom:

You get no permission messages.

Possible Cause:

"No permission" messages mean that you do not have access to perform the command.

Diagnosis:

Check permission using the appropriate NIS+ commands, described in "Advanced FNS and NIS+ Issues". Use the nisdefaults command to determine your NIS+ principal name.

Another area to check is whether you are using the right name. For example, org// names the context of the root organization. Make sure you have permission to manipulate the root organization. Or maybe you meant to specify myorgunit/, instead.

Solution:

If you do have permission, then the appropriate credentials probably have not been acquired.

This could be caused by the following:

Check that the /etc/nsswitch.conf file has a publickey: nisplus entry. This might manifest itself as an authentication error.

fnlist Does not List Suborganizations

Symptom:

You run fnlist with an organization name, expecting to see suborganizations, but instead see nothing.

Possible Cause:

This is caused by an NIS+ configuration problem. Suborganizations must be NIS+ domains. By definition, an NIS+ domain must have a subdirectory named org_dir.

Diagnosis:

Use the nisls command to see what subdirectories exist. Run nisls on each subdirectory to verify which subdirectories have an org_dir. The subdirectories with an org_dir are suborganizations.

Solution:

Not applicable.

Cannot Create Host- or User-related Contexts

Symptom:

When you run fncreate -t for the user, username, host, or hostname contexts, nothing happens.

Possible Cause:

You have not set the NIS_GROUP environment variable. When you create a user or host context it is owned by the host or user, and not by the administrator who set up the namespace. Therefore, fncreate requires that the NIS_GROUP variable be set to enable the administrators who are part of that group to subsequently manipulate the contexts.

Diagnosis:

Check the NIS_GROUP environment variable.

Solution:

The NIS_GROUP environment variable should be set to the group name of the administrators who will administer the contexts.

Cannot Remove a Context You Created

Symptom:

When you run fndestroy on the host or user context the context is not removed.

Possible Cause:

You do not own the host or user context. When you create a user or host context it is owned by the host or user, and not by the administrator who set up the namespace.

Diagnosis:

Check the NIS_GROUP environment variable.

Solution:

The NIS_GROUP environment variable needs to be set to the group name of the administrator who will administer the contexts.

Name in Use with fnunbind

Symptom:

You get "name in use" when trying to remove bindings. It works for certain names but not for others.

Possible Cause:

You cannot unbind the name of a context. This restriction is in place to avoid leaving behind contexts that have no name ("orphaned contexts").

Diagnosis:

Run the fnlist command on the name to verify that it is a context.

Solution:

If the name is a context, use the fndestroy command to destroy the context.

Name in Use with fnbind/fncreate -s

Symptom:

You use the -s option with fnbind and fncreate, but for certain names you get "name in use."

Possible Cause:

fnbind -s and fncreate -soverwrite the existing binding if it already exists; but if the old binding is one that must be kept to avoid orphaned contexts, the operation fails with a "name in use" error because the binding could not be removed. This is done to avoid orphaned contexts.

Diagnosis:

Run the fnlist command on the name to verify that it is a context.

Solution:

Run the fndestroy command to remove the context before running fnbind or fncreate on the same name.

fndestroy/fnunbind Does Not Return Operation Failed

Symptom:

When you do an fndestroy or fnunbind on certain names that you know do not exist, you receive no indication that the operation failed.

Possible Cause:

The operation did not fail. The semantics of fndestroy and fnunbind are that if the terminal name is not bound, the operation returns success.

Diagnosis:

Run the fnlookup command on the name. You should receive the message, "name not found."

Solution:

Not applicable.

Appendix B Error Messages

This section alphabetically lists some common error messages. For each message there is an explanation and, where appropriate, a solution or a cross-reference to some other portion of this manual.

Appendix A, Problems and Solutions, describes various type of problems and their solutions. Where appropriate, error messages in this appendix are cross-referenced to the corresponding section in Appendix A, Problems and Solutions.

About Error Messages

Some of the error messages documented in this chapter are documented more fully in the appropriate man pages.

Some of the error messages documented in this chapter are documented more fully in the appropriate man pages.

Error Message Context

Error messages can appear in pop-up windows, shell tool command lines, user console window, or various log files. You can raise or lower the severity threshold level for reporting error conditions in your /etc/syslog.conf file.

In the most cases, the error messages that you see are generated by the commands you issued or the container object (file, map, table or directory) your command is addressing. However, in some cases an error message might be generated by a server invoked in response to your command (these messages usually show in syslog). For example, a "permission denied" message most likely refers to you, or the machine you are using, but it could also be caused by software on a server not having the correct permissions to carry out some function passed on to it by your command or your machine.

Similarly, some commands cause a number of different objects to be searched or queried. Some of these objects might not be obvious. Any one of these objects could return an error message regarding permissions, read-only state, unavailability, and so forth. In such cases the message may or may not be able to inform you of which object the problem occurred in.

In normal operation, the naming software and servers make routine function calls. Sometimes those calls fail and in doing so generate an error message. It occasionally happens that before a client or server processes your most recent command, then some other call fails and you see the resulting error message. Such a message might appear as if it were in response to your command, when in fact it is in response to some other operation.

Note -

When working with a namespace you might encounter error messages generated by remote procedure calls. These RPC error messages are not documented here. Check your system documentation.

Context-Sensitive Meanings

A single error message might have slightly different meanings depending on which part of various naming software applications generated the message. For example, when a "Not Found" type message is generated by the nisls command, it means that there are no NIS+ objects that have the specified name, but when it is generated by the nismatch command it means that no table entries were found that meet the search criteria.

How Error Messages Are Alphabetized

The error messages in this appendix are sorted alphabetically according to the following rules:

Numbers in Error Messages

FNS Error Messages

FNS messages are encapsulated in the FN_status_t object as status codes. See the FN_status_t man page for the corresponding status codes

When an error occurs, FNS commands print out the remaining part of the name on which the operation failed. The part of the name that has not been printed has been processed successfully.

For example, a user attempted to create a context for org//service/trading/bb. The name org//service/ was resolved successfully, but trading was not found in the context named by org//service/. Thus, trading/bb is displayed as the part of the name that remains when the operation failed:


Error in creating 'org//service/trading/bb': Name Not Found: 'trading/bb'

In another example, a user attempted to destroy the context org//service/dictionary/english, but could not carry out the operation because the context named was not empty. The pair of single quotes ('') indicates that FNS was able to resolve the complete name given, but could not complete the operation as requested:


Error in destroying 'org//service/dictionary/english': Context Not Empty: ''

Common Namespace Error Messages


abort_transaction: Failed to action NIS+ objectname

The abort_transaction routine failed to back out of an incomplete transaction due to a server crash or some other unrecoverable error. See "NIS+ Database Problems" for further information.


abort_transaction: Internal database error abort_transaction: Internal error, log entry corrupt NIS+ objectname

These two messages indicate some form of corruption in a namespace database or log. See "NIS+ Database Problems" for additional information.


add_cleanup: Cant allocate more rags.

This message indicates that your system is running low on available memory. See "Insufficient Memory" for information on insufficient memory problems.


add_pingitem: Couldn't add directoryname to pinglist (no memory)

See "Insufficient Memory" for information on low memory problems.


add_update: Attempt add transaction from read only child. add_update Warning: attempt add transaction from read only child

An attempt by a read-only child rpc.nisd process to add an entry to a log. An occasional appearance of this message in a log is not serious. If this message appears frequently, contact the Sun Solutions Center.


Attempting to free a free rag!

This message indicates a software problem with rpc.nisd. The rpc.nisd should have aborted. Run ps -ef | grep rpc.nisd to see if rpc.nisd is still running. If it is, kill it and restart it with the same options as previously used. If it is not running, restart it with the same options as previously used. Check /var/nis to see if a core file has been dumped. If there is a core file, delete it.

Note -

If you started rpc.nisd with the -YB option, you must also kill the rpc.nisd_reply daemon.


Attempt to remove a non-empty table

An attempt has been made by nistbladm to remove an NIS+ table that still contains entries. Or by nisrmdir to remove a directory that contains files or subdirectories.

  • If you are trying to delete a table, use niscat to check the contents of the table and nistbladm to delete any existing contents.

  • If you are trying to delete a directory, use nisls -l -R to check for existing files or subdirectories and delete them first.

  • If you are trying to dissociate a replica from a domain with nisrmdir -s, and the replica is down or otherwise out of communication with the master, you will get this 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 -sto 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.

This message is generated by the NIS+ error code constant: NIS_NOTEMPTY. See the nis_tables man page for additional information.


attribute no permission

FNS error message. The caller did not have permission to perform the attempted attribute operation.


attribute value required

FNS error message. The operation attempted to create an attribute without a value, and the specific naming system does not allow this.


authdes_marshal: DES encryption failure

DES encryption for some authentication data failed. Possible causes:

  • Corruption of a library function or argument.

  • A problem with a DES encryption chip, if you are using one.

Call the Sun Solutions Center for assistance.


authdes_refresh: keyserv is unable to encrypt session key

The keyserv process was unable to encrypt the session key with the public key that it was given. See "Keyserv Failure" for additional information.


authdes_refresh: unable to encrypt conversation key

The keyserv process could not encrypt the session key with the public key that was given. This usually requires some action on your part. Possible causes are:

  • The keyserv process is dead or not responding. Use ps -ef to check whether the keyserv process is running on the keyserv host. If it is not, then start it, and then run keylogin.

  • The client has not performed a keylogin. Do a keylogin for the client and see if that corrects the problem.

  • The client host does not have credentials. Run nismatch on the client's home domain cred table to see if the client host has the proper credentials. If it does not, create them.

  • A DES encryption failure. See the authdes_marshal: DES encryption failure error message).

See "NIS+ Security Problems" for additional information regarding security key problems.


authdes_refresh: unable to synchronize clock

This indicates a synchronization failure between client and server clocks. This will usually correct itself. However, if this message is followed by any time stamp related error, you should manually resynchronize the clocks. If the problem reoccurs, check that remote rpcbind is functioning correctly.


authdes_refresh: unable to synch up w/server

The client-server clock synchronization has failed. This could be caused by the rpcbind process on the server not responding. Use ps -ef on the server to see if rpcbind is running. If it is not, restart it. If this error message is followed by any time stamp-related message, then you need to use rdate servername to manually resync the client clock to the server clock.


authdes_seccreate: keyserv is unable to generate session key

This indicates that keyserv was unable to generate a random DES key for this session. This requires some action on your part:

  • Check to make sure that keyserv is running properly. If it is not, restart it along with all other long-running processes that use Secure RPC or make NIS+ calls such as automountd, rpc.nisd and sendmail. Then do a keylogin.

  • If keyserv is up and running properly, restart the process that logged this error.


authdes_seccreate: no public key found for servername

The client side cannot get a DES credential for the server named servername. This requires some action on your part:

  • Check to make sure that servername has DES credentials. If it does not, create them.

  • Check the switch configuration file to see which name service is specified and then make sure that service is responding. If it is not responding, restart it.


authdes_seccreate: out of memory

See "NIS+ System Resource Problems" for information on insufficient memory problems.


authdes_seccreate: unable to gen conversation key

The keyserv process was unable to generate a random DES key. The most likely cause is that the keyserv process is down or otherwise not responding. Use ps -ef to check whether the keyserv process is running on the keyserv host. If it is not, then start it and run keylogin.

If restarting keyserv fails to correct the problem, it might be that other processes that use Secure RPC or make NIS+ calls are not running (for example, automountd, rpc.nisd, or sendmail). Check to see whether these processes are running; if they are not, restart them.

See "NIS+ Security Problems" for additional information regarding security key problems.


authdes_validate: DES decryption failure

See authdes_marshal: DES decryption failure for authentication data failure.


authdes_validate: verifier mismatch

The time stamp that the client sent to the server does not match the one received from the server. (This is not recoverable within a Secure RPC session.) Possible causes:

  • Corruption of the session key or time stamp data in the client or server cache

  • Server deleted from this cache a session key for a still active session.

  • Network data corruption.

Try re-executing the command.


authentication failure

FNS error message. The operation could not be completed because the principal making the request cannot be authenticated with the name service involved. If the service is NIS+, check that you are identified as the correct principal (run the command nisdefaults) and that your machine has specified the correct source for publickeys. Check that the /etc/nsswitch.conf file has the entry, publickey: nisplus.


bad reference

FNS error message. FNS could not interpret the contents of the reference. This can result if the contents of the reference have been corrupted or when the reference identifies itself as an FNS reference, but FNS doesn't know how to decode it.


CacheBind: xdr_directory_obj failed.

The most likely causes for this message are:

  • Bad or incorrect parameters being passed to the xdr_directory_obj routine. Check the syntax and accuracy of whatever command you most recently entered.

  • An attempt to allocate system memory failed. See "Insufficient Memory" for a discussion of memory problems.

  • If your command syntax is correct, and your system does not seem to be short of memory, contact the Sun Solutions Center.


Cache expired

The entry returned came from an object cache that has expired. This means that the time-to-live value has gone to zero and the entry might have changed. If the flag -NO_CACHE was passed to the lookup function, then the lookup function will retry the operation to get an unexpired copy of the object.

This message is generated by the NIS+ error code constant: NIS_CACHEEXPIRED. See the nis_tables and nis_names man pages for additional information.


Callback: - select failed message nnnn

An internal system call failed. In most cases this problem will correct itself. If it does not correct itself, make sure that rpc.nisd has not been aborted. If it has, restart it. If the problem reoccurs frequently, contact the Sun Solutions Center.


CALLBACK_SVC: bad argument

An internal system call failed. In most cases this problem will correct itself. If it does not correct itself, make sure that rpc.nisd has not been aborted. If it has, restart it. If the problem reoccurs frequently, contact the Sun Solutions Center.


Cannot grow transaction log error string

The system cannot add to the log file. The reason is indicated by the string. The most common cause of this message is lack of disk space. See "Insufficient Disk Space".


Cannot obtain Initial Context

FNS error message. Indicates an installation problem. See "Cannot Obtain Initial Context".


Cannot truncate transaction log file

An attempt has been made to checkpoint the log, and the rpc.nisd daemon is trying to shrink the log file after deleting the checkpointed entries from the log. See the ftruncate man pages for a description of various factors that might cause this routine to fail. See also "NIS+ Database Problems".


Cannot write one character to transaction log, errormessage

An attempt has been made by the rpc.nisd daemon to add an update from the current transaction into the transaction log, and the attempt has failed for the reason given in the message that has been returned by the function. Additional information can be obtained from the write routine's man page.


Can't compile regular expression variable

Returned by the nisgrep command when the expression in keypat was malformed.


Can't get any map parameter information.

See "NIS Problems and Solutions"


Can't find name service for passwd

Either there is no nsswitch.conf file or there is no passwd entry in the file, or the passwd entry does not make sense or is not one of the allowed formats.


Can't find name 's secret key

Possible causes:

  • You might have incorrectly typed the password.

  • There might not be an entry for name in the cred table.

  • NIS+ could not decrypt the key (possibly because the entry might be corrupt).

  • The nsswitch.conf file might be directing the query to a local password in an /etc/passwd file that is different than the NIS+ password recorded in the cred table.

See "NIS+ Security Problems" for information on diagnosing and solving these type of problem.


*** servername.domainname can't find machinename; Server failed.

DNS error message. See "Server Failed and Zone Expired Problems" and "Other DNS Syntax Errors".


Can't find server name for address 127.0.0.1; server failed.

DNS error message. This message usually indicates that your primary master server is using an outdated named.ca file with invalid information. If your network is connected to the Internet, you need to get a current named.ca file from the authority that administers your top level domain (.com, for instance). For .com, .edu, .gov, .mil, .org, and others, that authority is InterNIC. If your network is not connected to the Internet, you need to check your named.ca file for errors.


checkpoint_log: Called from read only child ignored.

This is a status message indicating that a read-only process attempted to perform an operation restricted to the parent process, and the attempt was aborted. No action need be taken.


checkpoint_log: Unable to checkpoint, log unstable.

An attempt was made to checkpoint a log that was not in a stable state. (That is, the log was in a resync, update, or checkpoint state.) Wait until the log is stable, and then rerun the nisping command.


check_updaters: Starting resync.

This is a system status message. No action need be taken.


Child process requested to checkpoint!

This message indicates a minor software problem that the system is capable of correcting. If these messages appear often, you can change the threshold level in your /etc/syslog.conf file. See the syslog.conf man page for details.


Column not found: columnname

The specified column does not exist in the specified table.


communication failure

FNS error message. FNS could not communicate with the name service to complete the operation.


configuration error

An error resulted because of configuration problems. Examples:

(1) The bindings table is removed out-of-band (outside of FNS).

(2) A host is in the NIS+ hosts directory object but does not have a corresponding FNS host context.


context not empty

FNS error message. An attempt has been made to remove a context that still contains bindings.


continue operation using status values

FNS error message. The operation should be continued using the remaining name and the resolved reference returned in the status.


Could not find string 's secret key

Possible causes:

  • You might have incorrectly typed the password.

  • There might not be an entry for name in the cred table.

  • NIS+ could not decrypt the key (possibly because the entry might be corrupt)

  • The nsswitch.conf file might have the wrong publickey policy. It might be directing the query to a local public key in an /etc/publickey file that is different from the NIS+ password recorded in the cred table.

See "NIS+ Security Problems" for information on diagnosing and solving these types of problem.


Could not generate netname

The Secure RPC software could not generate the Secure RPC netname for your UID when performing a keylogin. This could be due to the following causes:

  • You do not have LOCAL credentials in the NIS+ cred table of the machine's home domain.

  • You have a local entry in /etc/passwd with a UID that is different from the UID you have in the NIS+ passwd table.


string: could not get secret key for 'string

Possible causes:

  • You might have incorrectly typed the password.

  • There might not be an entry for name in the cred table.

  • NIS+ could not decrypt the key (possibly because the entry might be corrupt)

  • The nsswitch.conf file might have the wrong publickey policy. It might be directing the query to a local publickey in an /etc/publickey file that is different from the NIS+ password recorded in the cred table.

See "NIS+ Security Problems" for information on diagnosing and solving these type of problem.


Couldn't fork a process!

The server could not fork a child process to satisfy a callback request. This is probably caused by your system reaching its maximum number of processes. You can kill some unneeded processes, or increase the number of processes your system can handle. See "Insufficient Processes" for additional information.


Couldn't parse access rights for column string

This message is usually returned by the nistbladm -u command when something other than a + (plus sign), a - (minus sign), or an = (equal sign) is entered as the operator. Other possible causes are failure to separate different column rights with a comma, or the entry of something other than r,d,c, or m for the type of permission. Check the syntax for this type of entry error. If everything is entered correctly and you still get this error, the table might have been corrupted.


Database for table does not exist

At attempt to look up a table has failed. See "NIS+ Object Not Found Problems" for possible causes.

This message is generated by the NIS+ error code constant: NIS_NOSUCHTABLE. See the nis_tables and nis_names man pages for additional information.


_db_add: child process attempting to add/modify _db_addib: non-parent process attempting an add

These messages indicate that a read-only or nonparent process attempted to add or modify an object in the database. In most cases, these messages do not require any action on your part. If these messages are repeated frequently, call the Sun Solutions Center.


db_checkpoint: Unable to checkpoint string

This message indicates that for some reason NIS+ was unable to complete checkpointing of a directory. The most likely cause is that the disk is full See "Insufficient Disk Space" for additional information).


_db_remib: non-parent process attempting an remove _db_remove: non-parent process attempting a remove

These messages indicate that a read-only or non-parent process attempted to remove a table entry. In most cases, these messages do not require any action on your part. If these messages are repeated frequently, call the Sun Solutions Center.


Do you want to see more information on this command?

This indicates that there is a syntax or spelling error on your script command line.


Entry/Table type mismatch

This occurs when an attempt is made to add or modify an entry in a table, and the entry passed is of a different type from the table. For example, if the number of columns is not the same. Check that your update correctly matches the table type.

This message is generated by the NIS+ error code constant: NIS_TYPEMISMATCH. See the nis_tables man page for additional information.


error

FNS error message. An error that cannot be classified as one of the other errors listed above occurred while processing the request. Check the status of the naming services involved in the operation and see whether any of them are experiencing extraordinary problems.


**ERROR: chkey failed again. Please contact your network administrator to verify your network password.

This message indicates that you typed the wrong network password.

  • If this is the first time you are initializing this machine, contact your network administrator to verify the network password.

  • If this machine has been initialized before as an NIS+ client of the same domain, try typing the root login password at the Secure RPC password prompt.

  • If this machine is currently an NIS+ client and you are trying to change it to a client of a different domain, remove the /etc/.rootkey file, and rerun the nisclient script, using the network password given to you by your network administrator (or the network password generated by the nispopulate script).


Error: Could not create a valid NIS+ coldstart file

This message is from nisinit, the NIS+ initialization routine. It is followed by another message preceded by a string that begins: "lookup:..". This second message will explain why a valid NIS+ cold-start file could not be created.


**ERROR: could not restore file filename

This message indicates that NIS+ was unable to rename filename.no_nisplus to filename.

Check your system console for system error messages.

  • If there is a system error message, fix the problem described in the error message and rerun nisclient -i.

  • If there aren't any system error messages, try renaming this file manually, and then rerun nisclient -i.


**ERROR: Couldn't get the server NIS+_server's address.

The script was unable to retrieve the server's IP address for the specified domain. Manually add the IP address for NIS+_server into the /etc/hosts or /etc/inet/ipnodes file, then rerun nisclient -i.


**ERROR: directory directory-path does not exist.

This message indicates that you typed an incorrect directory path. Type the correct directory path.


**ERROR: domainname does not exist.

This message indicates that you are trying to replicate a domain that does not exist.

  • If domainname is spelled incorrectly, rerun the script with the correct domain name.

  • If the domainname domain does not exist, create it. Then you can replicate it.


**ERROR: parent-domain does not exist.

This message indicates that the parent domain of the domain you typed on the command line does not exist. This message should only appear when you are setting up a nonroot master server.

  • If the domain name is spelled incorrectly, rerun the script with the correct domain name.

  • If the domain's parent domain does not exist, you have to create the parent domain first, and then you can create this domain.


**ERROR: Don't know about the domain "domainname". Please check your domainname.

This message indicates that you typed an unrecognized domain name. Rerun the script with the correct domain name.


**ERROR: failed dumping tablename table.

The script was unable to populate the cred table because the script did not succeed in dumping the named table.

  • If niscat tablename .org_dir fails, make sure that all the servers are operating, then rerun the script to populate the tablename table.

  • If niscat tablename.org_dir is working, the error might have been caused by the NIS+ server being temporarily busy. Rerun the script to populate the tablename table.


**ERROR: host hostname is not a valid NIS+ principal in domain domainname. This host name must be defined in the credential table in domain domainname. Use nisclient -c to create the host credential

A machine has to be a valid NIS+ client with proper credentials before it can become an NIS+ server. To convert a machine to an NIS+ root replica server, the machine first must be an NIS+ client in the root domain. Follow the instructions on how to add a new client to a domain, then rerun nisserver -R.

Before you can convert a machine to an NIS+ nonroot master or a replica server, the machine must be an NIS+ client in the parent domain of the domain that it plans to serve. Follow the instructions on how to add a new client to a domain, then rerun nisserver -M or nisserver -R.

This problem should not occur when you are setting up a root master server.


Error in accessing NIS+ cold start file is NIS+ installed?

This message is returned if NIS+ is not installed on a machine or if for some reason the file /var/nis/NIS_COLD_START could not be found or accessed. Check to see if there is a /var/nis/NIS_COLD_START file. If the file exists, make sure your path is set correctly and that NIS_COLD_START has the proper permissions. Then rename or remove the old cold-start file and rerun the nisclient script to install NIS+ on the machine.

This message is generated by the cache manager that sends the NIS+ error code constant: NIS_COLDSTART_ERR. See the write and open man pages for additional information on why a file might not be accessible.


Error in RPC subsystem

This fatal error indicates the RPC subsystem failed in some way. Generally, there will be a syslog message on either the client or server side indicating why the RPC request failed.

This message is generated by the NIS+ error code constant: NIS_RPCERROR. See the nis_tables and nis_names man pages for additional information.


**ERROR: it failed to add the credential for root.

The NIS+ command nisaddcred failed to create the root credential when trying to set up a root master server. Check your system console for system error messages:

  • If there is a system error message, fix the problem described in the error message and then rerun nisserver.

  • If there aren't any system error messages, check to see whether the rpc.nisd process is running. If it is not running, restart it and then rerun nisserver.


**ERROR: it failed to create the tables.

The NIS+ command nissetup failed to create the directories and tables. Check your system console for system error messages:

  • If there is a system error message, fix the problem described in the error message and rerun nisserver.

  • If there aren't any system error messages, check to see whether the rpc.nisd process is running. If it is not running, restart it and rerun nisserver.


**ERROR: it failed to initialize the root server.

The NIS+ command nisinit -r failed to initialize the root master server. Check your system console for system error messages. If there is a system error message, fix the problem described in the error message and rerun nisserver.


**ERROR: it failed to make the domainname directory

The NIS+ command nismkdir failed to make the new directory domainname when running nisserver to create a nonroot master. The parent domain does not have create permission to create this new domain.

  • If you are not the owner of the domain or a group member of the parent domain, rerun the script as the owner or as a group member of the parent domain.

  • If rpc.nisd is not running on the new master server of the domain that you are trying to create, restart rpc.nisd.


**ERROR: it failed to promote new master for the domainname directory

The NIS+ command nismkdir failed to promote the new master for the directory domainname when creating a nonroot master with the nisserver script.

  • If you do not have modify permission in the parent domain of this domain, rerun the script as the owner or as a group member of the parent domain.

  • If rpc.nisd is not running on the servers of the domain that you are trying to promote, restart rpc.nisd on these servers and rerun nisserver.


**ERROR: it failed to replicate the directory-name directory

The NIS+ command nismkdir failed to create the new replica for the directory directory-name.

  • If rpc.nisd is not running on the master server of the domain that you are trying to replicate, restart rpc.nisd on the master server, rerun nisserver.

  • If rpc.nisd is not running on the new replica server, restart it on the new replica and rerun nisserver.


**ERROR: invalid group name. It must be a group in the root-domain domain.

This message indicates that you used an invalid group name while trying to configure a root master server. Rerun nisserver -r with a valid group name for root-domain.


**ERROR: invalid name "client-name" It is neither an host nor an user name.

This message indicates that you typed an invalid client-name.

  • If client-name was spelled incorrectly, rerun nisclient -c with the correct client-name.

  • If client-name was spelled correctly, but it does not exist in the proper table, put client-name into the proper table and rerun nisclient -c. For example, a user client belongs in the passwd table, and a host client belongs in the hosts table.


**ERROR: hostname is a master server for this domain. You cannot demote a master server to replica. If you really want to demote this master, you should promote a replica server to master using nisserver with the M option.

You cannot directly convert a master server to a replica server of the same domain. You can, however, change a replica to be the new master server of a domain by running nisserver -M with the replica host name as the new master. This automatically makes the old master a replica.


**ERROR: missing hostnames or usernames.

This message indicates that you did not type the client names on the command line. Rerun nisclient -c with the client names.


**ERROR: NIS+ group name must end with a "."

This message indicates that you did not specify a fully qualified group name ending with a period. Rerun the script with a fully qualified group name.


**ERROR: NIS+ server is not running on remote-host. You must do the following before becoming a NIS+ server: 1. become a NIS+ client of the parent domain or any domain above the domain which you plan to serve. (nisclient) 2. start the NIS+ server. (rpc.nisd)

This message indicates that rpc.nisd is not running on the remote machine that you are trying to convert to an NIS+ server. Use the nisclient script to become an NIS+ client of the parent domain or any domain above the domain you plan to serve; start rpc.nisd on remote-host.


**ERROR: nisinit failed.

nisinit was unable to create the NIS_COLD_START file.

Check the following:

  • That the NIS+ server you specified with the -H option is running--use ping

  • That you typed the correct domain name

  • That rpc.nisd is running on the server

  • That the nobody class has read permission for this domain


**ERROR: NIS map transfer failed. tablename table will not be loaded.

NIS+ was unable to transfer the NIS map for this table to the NIS+ database.

  • If the NIS server host is running, try running the script again. The error might have been due to a temporary failure.

  • If all tables have this problem, try running the script again using a different NIS server.


**ERROR: no permission to create directory domainname

The parent domain does not have create permission to create this new domain. If you are not the owner of the domain or as a group member of the parent domain, rerun the script as the owner, or as a group member of the parent domain.


**ERROR: no permission to replicate directory domainname.

This message indicates that you do not have permission to replicate the domain. Rerun the script as the owner or as a group member of the domain.


error receiving zone transfer

DNS error message. This usually indicates a syntax error in one of the primary server's DNS files. See "Other DNS Syntax Errors".


**ERROR: table tablename .org_dir.domainname does not exist." tablename table will not be loaded."

The script did not find the NIS+ table tablename.

  • If tablename is spelled incorrectly, rerun the script with the correct table name.

  • If the tablename table does not exist, use nissetup to create the table if tablename is one of the standard NIS+ tables. Or use nistbladm to create the private table tablename. Then rerun the script to populate this table.

  • If the tablename table exists, the error might have been caused by the NIS+ server being temporarily busy. Rerun the script to populate this tablename table.


**ERROR: this name "clientname" is in both the passwd and hosts tables. You cannot have an username same as the host name.

client-name appears in both the passwd and hosts tables. One name is not allowed to be in both of these tables. Manually remove the entry from either the passwd or hosts table. Then, rerun nisclient -c.


**ERROR: You cannot use the -u option as a root user.

This message indicates that the superuser tried to run nisclient -u. The -u option is for initializing ordinary users only. Superusers do not need be initialized as NIS+ clients.


**ERROR: You have specified the Z option after having selected the X option. Please select only one of these options [list]. Do you want to see more information on this command?

The script you are running allows you to choose only one of the listed options.

  • Type y to view additional information.

  • Type n to stop the script and exit.

After exiting the script, rerun it with just one of the options.


**ERROR: you must specify a fully qualified groupname.

This message indicates that you did not specify a fully qualified group name ending with a period. Rerun the script with a fully qualified group name.


**ERROR: you must specify both the NIS domainname (-y) and the NIS server host name (-h).

This message indicates that you did not type either the NIS domain name and/or the NIS server host name. Type the NIS domain name and the NIS server host name at the prompt or on the command line.


**ERROR: you must specify one of these options: -c, -i, -u, -r.

This message indicates that one of these options, -c, -i, -u, -r was missing from the command line. Rerun the script with the correct option.


**ERROR: you must specify one of these options: -r, -M or -R"

This message indicates that you did not type any of the -r or the -M or the -R options. Rerun the script with the correct option.


**ERROR: you must specify one of these options: -C, -F, or -Y

This message indicates that you did not type either the -Y or the -F option. Rerun the script with the correct option.


**ERROR: You must be root to use -i option.

This message indicates that an ordinary user tried to run nisclient -i. Only the superuser has permission to run nisclient -i.


Error while talking to callback proc

An RPC error occurred on the server while it was calling back to the client. The transaction was aborted at that time and any unsent data was discarded. Check the syslog on the server for more information.

This message is generated by the NIS+ error code constant: NIS_CBERROR. See the nis_tables man page for additional information.


First/Next chain broken

This message indicates that the connection between the client and server broke while a callback routine was posting results. This could happen if the server died in the middle of the process.

This message is generated by the NIS+ error code constant: NIS_CHAINBROKEN.


getzone: print_update failed

DNS error message. This usually indicates a syntax error in one of the primary server's DNS files. See "Other DNS Syntax Errors".


Generic system error

Some form of generic system error occurred while attempting the request. Check the syslog record on your system for error messages from the server.

This message usually indicates that the server has crashed or the database has become corrupted. This message might also be generated if you incorrectly specify the name of a server or replica as if it belonged to the domain it was servicing rather than the domain above. See "Domain Name Confusion" for additional information.

This message is generated by the NIS+ error code constant: NIS_SYSTEMERROR. See the nis_tables and nis_names man pages for additional information.


illegal name

FNS error message. The name supplied is not a legal name.


Illegal object type for operation

See "Illegal Object Problems" for a description of these type of problems.

This message is generated by the NIS+ error code constant: DB_BADOBJECT.


incompatible code sets

FNS error message. The operation involved character strings from incompatible code sets, or the supplied code set is not supported by the implementation.


in.named [nnnn]: lame server on hostname

DNS error message. Lame delegation is when an NS record in the hosts file of a parent domain server identifies another server as authoritative for a subdomain zone, but that server is not authoritative for that zone. The NS records in the parent's hosts file must be a superset that includes all the authoritative servers in all delegated sub zones.


insufficient permission to update credentials.

This message is generated by the nisaddcred command when you have insufficient permission to execute an operation. This could be insufficient permission at the table, column, or entry level. Use niscat -o cred.org_dir to determine what permissions you have for that cred table. If you need additional permission, you or the system administrator can change the permission requirements of the object as described in Chapter 10, Administering NIS+ Access Rights, or add you to a group that does have the required permissions as described in Chapter 12, Administering NIS+ Groups.

See "NIS+ Ownership and Permission Problems" for additional information about permission problems.


insufficient resources

FNS error message. The name service used by FNS does not have sufficient resources to complete the request. Check memory and disk availability on the name servers involved.


invalid attribute identifier

FNS error message. The attribute identifier is in a format not acceptable to the naming system, or its contents are not valid for the format specified for the identifier.


invalid attribute value

FNS error message. The value supplied is not in the correct form for the given attribute.


invalid enumeration handle

FNS error message. The enumeration handle supplied is invalid. The handle could have been from another enumeration, an update operation might have occurred during the enumeration, or there might have been some other reason.


Invalid Object for operation

  • Name context. The name passed to the function is not a legal NIS+ name.

  • Table context. The object pointed to is not a valid NIS+ entry object for the given table. This could occur if it had a mismatched number of columns, or a different data type (for example, binary or text) than the associated column in the table.

This message is generated by the NIS+ error code constant: NIS_INVALIDOBJ. See the nis_tables and nis_names man pages for additional information.


invalid syntax attributes

FNS error message. The syntax attributes supplied are invalid or insufficient to fully specify the syntax.


invalid usecs Routine_name: invalid usecs

This message is generated when the value in the tv_usecs field of a variable of type struct time stamp is larger than the number of microseconds in a second. This is usually due to some type of software error.


tablename is not a table

The object with the name tablename is not a table object. For example, the nisgrep and nismatch commands will return this error if the object you specify on the command line is not a table.


link error

FNS error message. An error occurred while resolving an XFN link with the supplied name.


link loop limit reached

FNS error message. A nonterminating loop was detected due to XFN links encountered during composite name resolution, or the implementation-defined limit was exceeded on the number of XFN links allowed for a single operation.


Link Points to illegal name

The passed name resolved to a LINK type object and the contents of the object pointed to an invalid name.

You cannot link table entries. A link at the entry level can produce this error message.

This message is generated by the NIS+ error code constant: NIS_LINKNAMEERROR. See the nis_tables and nis_names man pages for additional information.


Load limit of number reached!

An attempt has been made to create a child process when the maximum number of child processes have already been created on this server. This message is seen on the server's system log, but only if the threshold for logging messages has been set to include LOG_WARNING level messages.


login and keylogin passwords differ.

This message is displayed when you are changing your password with nispasswd and the system has changed your password, but has been unable to update your credential entry in the cred table with the new password and also unable to restore your original password in the passwd table. This message is followed by the instructions:


Use NEW password for login and OLD password for 
keylogin. Use "chkey -p" to reencrypt the credentials with 
the new login password. You must keylogin explicitly after 
your next login.

These instructions are then followed by a status message explaining why it was not possible to revert back to the old password. If you see these messages, be sure to follow the instructions as given.


Login incorrect

The most common cause of a "login incorrect" message is mistyping the password. Try it again. Make sure you know the correct password. Remember that passwords are case-sensitive (uppercase letters are considered different than lowercase letters) and that the letter "o" is not interchangeable with the numeral "0," nor is the letter "l" the same as the numeral "1".

For other possible causes of this message, see "Login Incorrect Message".


log_resync: Cannot truncate transaction log file

An attempt has been made to checkpoint the log, and the rpc.nisd daemon is trying to shrink the log file after deleting the checkpointed entries from the log. See the ftruncate man pages for a description of various factors that might cause this routine to fail. See also "NIS+ Database Problems".


malformed link

FNS error message. A malformed link reference was found during a fn_ctx_lookup_link() operation. The name supplied resolved to a reference that was not a link.


Malformed Name or illegal name

The name passed to the function is not a legal or valid NIS+ name.

One possible cause for this message is that someone changed an existing domain name. Existing domain names should not be changed. See "Changed Domain Name".

This message is generated by the NIS+ error code constant: NIS_BADNAME. See the nis_tables man page for additional information.


_map_addr: RPC timed out.

A process or application could not contact NIS+ within its default time limit to get necessary data or resolve host names from NIS+. In most cases, this problem will solve itself after a short wait. See "NIS+ Performance and System Hang Problems" for additional information about slow performance problems.


Master server busy full dump rescheduled

This message indicates that a replica server has been unable to update itself with a full dump from the master server because the master is busy. See "Replica Update Failure" for additional information.


String Missing or malformed attribute

The name of an attribute did not match with a named column in the table, or the attribute did not have an associated value.

This could indicate an error in the syntax of a command. The string should give an indication of what is wrong. Common causes are spelling errors, failure to correctly place the equals sign (=), an incorrect column or table name, and so forth.

This message is generated by the NIS+ error code constant: NIS_BADATTRIBUTE. See the nis_tables man page for additional information.


Modification failed

Returned by the nisgrpadm command when someone else modified the group during the execution of your command. Check to see who else is working with this group. Reissue the command.

This message is generated by the NIS+ error code constant: NIS_IBMODERROR.


Modify operation failed

The attempted modification failed for some reason.

This message is generated by the NIS+ error code constant: NIS_MODFAIL. See the nis_tables and nis_names man pages for additional information.


servername named [nnnn]: directory directoryname: No such file or directory.

DNS error message. This usually indicates a syntax or spelling error in a DNS boot or data file.


servername named [nnnn]: /etc/named.boot: line n unknown field `name'

DNS error message. This often indicates a spelling error in the DNS named.boot file. For example, "primary" or "secondary" might be misspelled.


servername named [nnnn]: servername has CNAME and other data (illegal)

DNS error message. This often indicates a syntax error in, or misuse of, a CNAME record for machine servername.


servername named [nnnn]: domainname Line n: Database format error (n.n.n.n.n)

DNS error message. The resource record for the machine in domain name1, whose IP address is n.n.n.n might be missing the type (usually IN) or have some other syntax error.


servername named [nnnn]: Line n Unknown type: n.n.n.n.

DNS error message. The DNS hosts file resource record for the machine whose IP address is n.n.n.n does not include the type (usually IN).


servername named [nnnn]: secondary zone zonename expired.

DNS error message. See "Server Failed and Zone Expired Problems".


servername named [nnnn]: zoneref: Masters for secondary zone zonename unreachable

DNS error message. See "Server Failed and Zone Expired Problems".


name in use

FNS error message. The name supplied is already bound in the context.


name not found

FNS error message. The name supplied was not found.


Name not served by this server

A request was made to a server that does not serve the specified name. Normally this will not occur; however, if you are not using the built-in location mechanism for servers, you might see this if your mechanism is broken.

Other possible causes are:

  • Cold-start file corruption. Delete the /var/nis/NIS_COLD_START file and then reboot.

  • Cache problem such as the local cache being out of date. Kill the nis_cachemgr and /var/nis/NIS_SHARED_DIRCACHE, and then reboot. (If the problem is not in the root directory, you might be able to kill the domain cache manager and try the command again.)

  • Someone removed the directory from a replica.

This message is generated by the NIS+ error code constant: NIS_NOT_ME. See the nis_tables and nis_names man pages for additional information.


Named object is not searchable

The table name resolved to an NIS+ object that was not searchable.

This message is generated by the NIS+ error code constant: NIS_NOTSEARCHABLE. See the nis_tables man page for additional information.


Name/entry isn't unique

An operation has been requested based on a specific search criteria that returns more than one entry. For example, you use nistbladm -rto delete a user from the passwd table, and there are two entries in that table for that user name as shown as follows:


mymachine# nistbladm -r [name=arnold],passwd.org_dir 
Can't remove entry: Name/entry isn't unique

You can apply your command to multiple entries by using the -R option rather than -r. For example, to remove all entries for arnold:


mymachine# nistbladm -R name=arnold],passwd.org_dir

NIS make terminated

A problem caused your NIS make operation to terminate before successful conclusion. Check your NIS make file for problems and syntax errors.


NIS: server not responding for domain domainname. Still trying

See "NIS Problems and Solutions".


NIS+ error

The NIS+ server has returned an error, but the passwd command determines exactly what the error is.


NisDirCacheEntry:write: xdr_directory_obj failed

The most likely causes for this message is that an attempt to allocate system memory failed. See "Insufficient Memory" for a discussion of memory problems. If your system does not seem to be short of memory, contact the Sun Solutions Center.


NIS+ operation failed

This generic error message should be rarely seen. Usually it indicates a minor software problem that the system can correct on it own. If it appears frequently, or appears to be indicating a problem that the system is not successfully dealing with, contact the Sun Solutions Center.

This message is generated by the NIS+ error code constant: NIS_FAIL.


string: NIS+ server busy try again later.

See "NIS+ Performance and System Hang Problems" for possible causes.


NIS+ server busy try again later.

Self explanatory. Try the command later.

See also "NIS+ Performance and System Hang Problems" for possible causes.


NIS+ server for string not responding still trying

See "NIS+ Performance and System Hang Problems" for possible causes.


NIS+ server not responding

See "NIS+ Performance and System Hang Problems" for possible causes.


NIS+ server needs to be checkpointed. Use nisping -Cdomainname

Caution - Caution -

Checkpoint immediately! Do not wait!

This message is generated at the LOG_CRIT level on the server's system log. It indicates that the log is becoming too large. Use nisping -C domainname to truncate the log by checkpointing.

See also " Logs Grow too Large" for additional information on log size.


NIS+ servers unreachable

This soft error indicates that a server for the desired directory of the named table object could not be reached. This can occur when there is a network failure or the server has crashed. A new attempt might succeed. See the description of the -HARD_LOOKUP flag in the nis_tables and nis_names man pages.

This message is generated by the NIS+ error code constant: NIS_NaMEUNREACHABLE.


NIS+ service is unavailable or not installed

Self-explanatory. This message is generated by the NIS+ error code constant: NIS_UNAVAIL.


NIS+: write ColdStart File: xdr_directory_obj failed

The most likely causes for this message are:

  • Bad or incorrect parameters. Check the syntax and accuracy of whatever command you most recently entered.

  • An attempt to allocate system memory failed. See "Insufficient Memory" for a discussion of memory problems.

  • If your command syntax is correct, and your system does not seem to be short of memory, contact the Sun Solutions Center.


nis_checkpoint_svc: readonly child instructed to checkpoint ignored.

This is simply a status message indicating that a read-only process attempted to perform an operation restricted to the parent process, and the attempt was aborted. No action need be taken.


nis_dumplog_svc: readonly child called to dump log, ignore

This is simply a status message indicating that a read-only process attempted to perform an operation restricted to the parent process, and the attempt was aborted. No action need be taken.


nis_dump_svc: load limit reached.

The maximum number of child processes permitted on your system has been reached.


nis_dump_svc: one replica is already resyncing.

Only one replica can resync from a master at a time. Try the command later.

See "Replica Update Failure" for information on these three error messages.


nis_dump_svc: Unable to fork a process.

The fork system call has failed. See the fork man page for possible causes.


nis_mkdir_svc: readonly child called to mkdir, ignored

This is simply a status message indicating that a read-only process attempted to perform an operation restricted to the parent process, and the attempt was aborted. No action need be taken.


nis_ping_svc: readonly child was pung ignored.

This is simply a status message indicating that a read-only process attempted to perform an operation restricted to the parent process, and the attempt was aborted. No action need be taken.


nis_rmdir_svc: readonly child called to rmdir, ignored

This is simply a status message indicating that a read-only process attempted to perform an operation restricted to the parent process, and the attempt was aborted. No action need be taken.


nisaddcred: no password entry for uid userid nisaddcred: unable to create credential.

These two messages are generated during execution of the nispopulate script. The NIS+ command nisaddcred failed to add a LOCAL credential for the user ID userid on a remote domain. (This only happens when you are trying to populate the passwd table in a remote domain.)

To correct the problem, add a table path in the local passwd table:


# nistbladm -u -p passwd.org_dir.remote-domain passwd.org_dir

The remote-domain must be the same domain that you specified with the -d option when you ran nispopulate. Rerun the script to populate the passwd table.


No file space on server

Self-explanatory.

This message is generated by the NIS+ error code constant: NIS_NOFILESPACE.


No match

This is most likely an error message from the shell, caused by failure to escape the brackets when specifying an indexed name. For example, failing to set off a bracketed indexed name with quote marks would generate this message because the shell would fail to interpret the brackets as shown as follows:


# nistbladm -m shell=/bin/csh [name=miyoko],passwd.org_dir No match

The correct syntax is:


# nistbladm -m shell=/bin/csh `[name=miyoko],passwd.org_dir`

No memory

Your system does not have enough memory to perform the specified operation. See "NIS+ System Resource Problems" for additional information on memory problems.


Non NIS+ namespace encountered

The name could not be completely resolved. This usually indicates that the name passed to the function resolves to a namespace that is outside the NIS+ name tree. In other words, the name is contained in an unknown directory. When this occurs, this error is returned with an NIS+ object of type DIRECTORY.

This message is generated by the NIS+ error code constant: NIS_FOREIGNNS. See the nis_tables or nis_names man pages for additional information.


No password entry for uid userid No password entry found for uid userid

Both of these two messages indicate that no entry for this user was found in the passwd table when trying to create or add a credential for that user. (Before you can create or add a credential, the user must be listed in the passwd table.)

  • The most likely cause is misspelling the user's userid on the command line. Check your command line for correct syntax and spelling.

  • Check that you are either in the correct domain, or specifying the correct domain on the command line.

  • If the command line is correct, check the passwd table to make sure the user is listed under the userid you are entering. This can be done with nismatch:


mymachine# nismatch uid=userid passwd.org_dir.

If the user is not listed in the passwd table, use nistbladm or nisaddent to add the user to the passwd table before creating the credential.


no permission

FNS error message. The operation failed because of access control problems. See ""No Permission" Messages (FNS)". See also "No Permission".


No shadow password information

This means that password aging cannot be enforced because the information used to control aging is missing.


no such attribute

FNS error message. The object did not have an attribute with the given identifier.


no supported address

FNS error message. No shared library could be found under the /usr/lib/fn directory for any of the address types found in the reference bound to the FNS name. Shared libraries for an address type are named according to this convention: fn_ctx_address_type.so. Typically there is a link from fn_ctx_address_type.so to fn_ctx_address_type.so.1.

For example, a reference with address type onc_fn_nisplus would have a shared library in the path name: /usr/lib/fn/fn_ctx_onc_fn_nisplus.so.


not a context

FNS error message. The reference does not correspond to a valid context.


Not found String Not found

Names context. The named object does not exist in the namespace.

Table context. No entries in the table matched the search criteria. If the search criteria was null (return all entries), then this result means that the table is empty and can safely be removed.

If the -FOLLOW_PATH flag was set, this error indicates that none of the tables in the path contain entries that match the search criteria.

This message is generated by the NIS+ error code constant: NIS_NOTFOUND. See the nis_tables and nis_names man pages for additional information.

See also "NIS+ Object Not Found Problems" for general information on this type of problem.


Not Found no such name

This hard error indicates that the named directory of the table object does not exist. This could occur when the server that should be the parent of the server that serves the table, does not know about the directory in which the table resides.

This message is generated by the NIS+ error code constant: NIS_NOSUCHNAME. See the nis_names and nis_names man pages for additional information.

See also "NIS+ Object Not Found Problems" for general information on this type of problem.


Not master server for this domain

This message might mean that an attempt was made to directly update the database on a replica server.

This message might also mean that a change request was made to a server that serves the name, but it is not the master server. This can occur when a directory object changes and it specifies a new master server. Clients that have cached copies of that directory object in their /var/nis/NIS_SHARED_DIRCACHE file should run ps to obtain the process ID of the nis_cachemgr, kill the nis_cachemgr process, remove the /var/nis/NIS_SHARED_DICACHE file, and then restart nis_cachemgr.

This message is generated by the NIS+ error code constant: NIS_NOTMASTER. See the nis_tables and nis_names man pages for additional information.


Not owner

The operation you attempted can only be performed by the object's owner, and you are not the owner.

This message is generated by the NIS+ error code constant: NIS_NOTOWNER.


operation not supported

FNS error message. The operation is not supported by the context. For example, trying to destroy an organization is not supported.


Object with same name exists

An attempt was made to add a name that already exists. To add the name, first remove the existing name and then add the new name or modify the existing named object.

This message is generated by the NIS+ error code constant: NIS_NAMEEXISTS. See the nis_tables and nis_names man pages for additional information.


parse error: string (key variable)

This message is displayed by the nisaddent command when it attempts to use database files from a /etc directory and there is an error in one of the file's entries. The first variable should describe the problem, and the variable after key should identify the particular entry at fault. If the problem is with the /etc/passwd file, you can use /usr/sbin/pwck to check it.


partial result returned

FNS error message. The operation returned a partial result.


Partial Success

This result is similar to NIS_NOTFOUND, except that it means the request succeeded but resolved to zero entries.

When this occurs, the server returns a copy of the table object instead of an entry so that the client can then process the path or implement some other local policy.

This message is generated by the NIS+ error code constant: NIS_PARTIAL. See the nis_tables man page for additional information.


Passed object is not the same object on server

An attempt to remove an object from the namespace was aborted because the object that would have been removed was not the same object that was passed in the request.

This message is generated by the NIS+ error code constant: NIS_NOTSAMEOBJ. See the nis_tables and nis_names man pages for additional information.


Password does not decrypt secret key for name

Possible causes:

  • You might have incorrectly typed the password.

  • There might not be an entry for name in the cred table.

  • NIS+ could not decrypt the key (possibly because the entry might be corrupt).

  • The Secure RPC password does not match the login password.

  • The nsswitch.conf file might be directing the query to a local password in an /etc/passwd file that is different from the NIS+ password recorded in the cred table. (Note that the actual encrypted passwords are stored locally in the /etc/shadow file.)

See "NIS+ Security Problems" for information on diagnosing and solving these types of problems.


Password has not aged enough

This message indicates that your password has not been in use long enough and that you cannot change it until it has been in use for N (a number of) days. See "Changing Your Password" for further information.


Permission denied

Returned when you do not have the permissions required to perform the operation you attempted. See "NIS+ Ownership and Permission Problems" for additional information.

This message might be related to a login or password matter, or an NIS+ security problem. The most common cause of a Permission denied message is that the password of the user receiving it has been locked by an administrator or the user's account has been terminated. See Chapter 11, Administering Passwords, and the "NIS+ Security Problems" section of Appendix A, Problems and Solutions.


Permissions on the password database may be too restrictive

You do not have authorization to read (or otherwise use) the contents of the passwd field in an NIS+ table. See Chapter 10, Administering NIS+ Access Rights, for information on NIS+ access rights.


Please notify your System Administrator

When displayed as a result of an attempt to update password information with the passwd command, this message indicates that the attempt failed for one of many reasons. For example, the service might not be available, a necessary server is down, there is a "permission denied" type problem, and so forth. See "NIS+ Security Problems" for a discussion of various types of security problems.


Please check your /etc/nsswitch.conf file

The nsswitch.conf file specifies a configuration that is not supported for passwd update. See "nsswitch.conf File Requirements" for supported configurations.


Probable success

Name context. The request was successful; however, the object returned came from an object cache and not directly from the server. (If you do not want to see objects from object caches, you must specify the flag -NO_CACHE when you call the lookup function.)

Table context. Even though the request was successful, a table in the search path was not able to be searched, so the result might not be the same as the one you would have received if that table had been accessible.

This message is generated by the NIS+ error code constant: NIS_S_SUCCESS. See the nis_tables and nis_names man pages for additional information.


Probably not found

The named entry does not exist in the table; however, not all tables in the path could be searched, so the entry might exist in one of those tables.

This message is generated by the NIS+ error code constant: NIS_S_NOTFOUND. See the nis_tables man page for additional information.


Query illegal for named table

A problem was detected in the request structure passed to the client library.

This message is generated by the NIS+ error code constant: NIS_BADREQUEST. See the nis_tables man page for additional information.


Reason: can't communicate with ypbind.

See "NIS Problems and Solutions"


replica_update: Child process attempting update, aborted

This is simply a status message indicating that a read-only process attempted an update and the attempt was aborted.


replica_update: error result was string

This message indicates a problem (identified by string) in carrying out a dump to a replica. See "Replica Update Failure" for further information.


replica_update: error result was Master server busy, full dump rescheduled replica_update: master server busy rescheduling the resync. replica_update: master server is busy will try later. replica_update: nis dump result Master server busy, full dump rescheduled

These messages all indicate that the server is busy and the dump will be done later.


replica_update: nis dump result nis_perror errorstring

This message indicates a problem (identified by the error string) in carrying out a dump to a replica. See "Replica Update Failure" for further information.


replica_update: nnnn updates nnnn errors

A status message indicating a successful update.


replica_update: WARNING: last_update (directoryname) returned 0!

A NIS+ process could not find the last update time stamp in the transaction log for that directory. This will cause the system to perform a full resync of the problem directory.


Results Sent to callback proc

This is simply a status message. No action need be taken.

This message is generated by the NIS+ error code constant: NIS_CBRESULTS. See the nis_tables man page for additional information.


root_replica_update: update failed string: could not fetch object from master.

This message indicates a problem in carrying out a dump to a replica. See "Replica Update Failure" for further information.


RPC failure: "RPC failure on yp operation.

This message is returned by ypcat when a NIS client's nsswitch.conf file is set to files rather than nis, and the server is not included in the /etc/hosts or /etc/inet/ipnodes file


Security exception on local system. UNABLE TO MAKE REQUEST.

This message might be displayed if a user has the same login ID as a machine name. See "User Login Same as Machine Name" for additional information.


date: hostname: sendmail (nnnn) : gethostbyaddr failed

One common cause of this problem is entering IP addresses in NIS+, NIS, files, or DNS data sets with leading zeros. For example, you should never enter an IP address as 151.029.066.001. The correct way to enter that address is: 151.29.66.1.


Server busy, try again

The server was too busy to handle your request.

  • For the add, remove, and modify operations, this message is returned when either the master server for a directory is unavailable or it is in the process of checkpointing its database.

  • This message can also be returned when the server is updating its internal state.

  • In the case of nis_list, if the client specifies a callback and the server does not have enough resources to handle the callback.

Retry the command at a later time when the server is available.

This message is generated by the NIS+ error code constant: NIS_TRYAGAIN. See the nis_tables and nis_names man pages for additional information.


Server out of memory

In most cases this message indicates a fatal result. It means that the server ran out of heap space.

This message is generated by the NIS+ error code constant: NIS_NOMEMORY. See the nis_tables and nis_names man pages for additional information.


Sorry

This message is displayed when a user is denied permission to login or change a password, and for security reasons the system does not display the reason for that denial because such information could be used by an unauthorized person to gain illegitimate access to the system.


Sorry: less than nn days since the last change

This message indicates that your password has not been in use long enough and that you cannot change it until it has been in use for N days. See "Changing Your Password" for further information.


Success

(1) The request was successful. This message is generated by the NIS+ error code constant: NIS_SUCCESS. See the nis_tables man page for additional information.

(2) FNS error message. Operation succeeded.


_svcauth_des: bad nickname

The nickname received from the client is invalid or corrupted, possibly due to network congestion. The severity of this message depends on what level of security you are running. At a low security level, this message is informational only; at a higher level, you might have to try the command again later.


_svcauth_des: corrupted window from principalname

The window that was sent does not match the one sent in the verifier.

The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information; at a higher level you might have to try the command again at some later time or take corrective action as described below.

Possible causes:

  • The server's key pair has been changed. The client used the server's old public key while the server has a new secret key cached with keyserv. Run keylogin on both client and server.

  • The client's key pair has been changed and the client has not run keylogin on the client system, so system is still sending the client's old secret key to the server, which is now using the client's new public key. Naturally, the two do not match. Run keylogin again on both client and server.

  • Network corruption of data. Try the command again. If that does not work, use the snoop command to investigate and correct any network problems. Then run keylogin again on both server and client.


_svcauth_des: decryption failure

DES decryption for some authentication data failed. Possible causes:

  • Corruption to a library function or argument.

  • A problem with a DES encryption chip, if you are using one.

The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information; at a higher level, you might have to call the Sun Solutions Center for assistance. If the problem appears to be related to a DES encryption chip, call the Sun Solutions Center.


_svcauth_des: corrupted window from principalname

The window that was sent does not match the one sent in the verifier.

The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information; at a higher level you might have to try the command again at some later time or take corrective action as described below.

Possible causes:

  • The server's key pair has been changed. The client used the server's old public key while the server has a new secret key cached with keyserv. Run keylogin on both client and server.

  • The client's key pair has been changed and the client has not run keylogin on the client system, so system is still sending the client's old secret key to the server, which is now using the client's new public key. Naturally, the two do not match. Run keylogin again on both client and server.

  • Network corruption of data. Try the command again. If that does not work, use the snoop command to investigate and correct any network problems. Then run keylogin again on both server and client.


_svcauth_des: decryption failure for principalname

DES decryption for some authentication data failed. Possible causes:

  • Corruption to a library function or argument.

  • A problem with a DES encryption chip, if you are using one.

The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information; at a higher level, you might have to call the Sun Solutions Center for assistance. If the problem appears to be related to a DES encryption chip, call the Sun Solutions Center.


_svcauth_des: invalid timestamp received from principalname

The time stamp received from the client is corrupted, or the server is trying to decrypt it using the wrong key. Possible causes:

  • Congested network. Retry the command.

  • Server cached out the entry for this client. Check the network load.


_svcauth_des: key_decryptsessionkey failed for principalname

The keyserv process failed to decrypt the session key with the given public key. Possible causes are:

  • The keyserv process is dead or not responding. Use ps -ef to check if the keyserv process is running on the keyserv host. If it is not, then restart it and run keylogin.

  • The server principal has not keylogged in. Run keylogin for the server principal.

  • The server principal (host) does not have credentials. Run nismatch hostname.domainname. cred.org_dir on the client's home domain cred table. Create new credentials if necessary.

  • keyserv might have been restarted, in which case certain long-running applications, such as rpc.nisd, sendmail, and automountd, also need to be restarted.

  • DES encryption failure. Call the Sun Solutions Center.


_svcauth_des: no public key for principalname

The server cannot get the client's public key. Possible causes are:

  • The principal has no public key. Run nismatch on the cred table of the principal's home domain. If there is no DES credential in that table for the principal, use nisaddcred to create one, and then run keylogin for that principal.

  • The name service specified by a nsswitch.conf file is not responding.


_svcauth_des: replayed credential from principalname

The server has received a request and finds an entry in its cache for the same client name and conversation key with the time stamp of the incoming request before that of the one currently stored in the cache.

The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information. At a higher level, you might have to take corrective action as described below.

Possible causes are:

  • The client and server clocks are out of sync. Use rdate to resync the client clock to the server clock.

  • The server is receiving requests in random order. This could occur if you are using multithreading applications. If your applications support TCP, then set /etc/netconfig (or your NETPATH environment variable) to tcp.


_svcauth_des: timestamp is earlier than the one previously seen from principalname

The time stamp received from the client on a subsequent call is earlier than one seen previously from that client. The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information; at a higher level, you might have some corrective action as described below.

Possible causes are:

  • The client and server clocks are out of sync. Use rdate to resynch the client clock to the server clock.

  • The server cached out the entry for this client. The server maintains a cache of information regarding the current clients. This cache size equals 64 client handles.


_svcauth_des: timestamp expired for principalname

The time stamp received from the client is not within the default 35-second window in which it must be received. The severity of this message depends on what level of security you are running. At a low security level, this message is primarily for your information; at a higher level, you might have to take corrective action as described below.

Possible causes are:

  • The 35-second window is too small to account for slow servers or a slow network.

  • The client and server clocks are so far out of sync that the window cannot allow for the difference. Use rdate to resynchronize the client clock to the server clock.

  • The server has cached out the client entry. Retry the operation.


syntax not supported

FNS error message. The syntax type is not supported.


Too Many Attributes

The search criteria passed to the server had more attributes than the table had searchable columns.

This message is generated by the NIS+ error code constant: NIS_TOOMANYATTRS. See the nis_tables man page for additional information.


too many attribute values

FNS error message. The operation attempted to associate more values with an attribute than the naming system supports.


Too many failures - try later


Too many tries; try again later

These messages refer to logging in or changing your password. They indicate that you have had too many failed attempts (or taken too long) to either log in or change your password. See "The Login incorrect Message" or "Password Change Failures" for further information.


Unable to authenticate NIS+ client

This message is generated when a server attempts to execute the callback procedure of a client and gets a status of RPC_AUTHERR from the RPC clnt_call(). This is usually caused by out-of-date authentication information. Out-of-date authentication information can occur when the system is using data from a cache that has not been updated, or when there has been a recent change in the authentication information that has not yet been propagated to this server. In most cases, this problem should correct itself in a short period of time.

If this problem does not self-correct, it might indicate one of the following problems:

  • Corrupted /var/nis/NIS_SHARED_DIRCACHE file. Kill the cache manager, remove this file, and restart the cache manager.

  • Corrupted /var/nis/NIS_COLD_START file. Remove the file and then run nisinit to recreate it.

  • Corrupted /etc/.rootkey file. Run keylogin -r.

This message is generated by the NIS+ error code constant: NIS_CLNTAUTH.


Unable to authenticate NIS+ server

In most cases, this is a minor software error from which your system should quickly recover without difficulty. It is generated when the server gets a status of RPC_AUTHERR from the RPC clnt_call.

If this problem does not quickly clear itself, it might indicate a corrupted /var/nis/NIS_COLD_START, /var/nis/NIS_SHARED_DIRCACHE, or /etc/.rootkey file.

This message is generated by the NIS+ error code constant: NIS_SRVAUTH.


Unable to bind to master server for name 'string'

See "NIS+ Object Not Found Problems" for information on this type of problem. This particular message might be caused by adding a trailing dot to the server's domain name in the /etc/defaultdomain file.


Unable to create callback.

The server was unable to contact the callback service on your machine. This results in no data being returned.

See the nis_tables man page for additional information.


Unable to create process on server

This error is generated if the NIS+ service routine receives a request for a procedure number which it does not support.

This message is generated by the NIS+ error code constant: NIS_NOPROC.


string: Unable to decrypt secret key for string.

Possible causes:

  • You might have incorrectly typed the password.

  • There might not be an entry for name in the cred table.

  • NIS+ could not decrypt the key because the entry might be corrupt.

  • The nsswitch.conf file might be directing the query to a local password in an /etc/passwd file that is different than the NIS+ password recorded in the cred table.

See "NIS+ Security Problems" for information on diagnosing and solving these type of problem.


unavailable

FNS error message. The name service on which the operation depends is unavailable.


Unknown error

This is displayed when the NIS+ error handling routine receives an error of an unknown type.


Unknown object

The object returned is of an unknown type.

This message is generated by the NIS+ error code constant: NIS_UNKNOWNOBJ. See the nis_names man page for additional information.


update_directory: nnnn objects still running.

This is a status message displayed on the server during the update of a directory during a replica update. You do not need to take any action.


User principalname needs Secure RPC credentials to login but has none.

The user has failed to perform a keylogin. This problem usually arises when the user has different passwords in /etc/shadow and a remote NIS+ passwd table.


Warning: couldn't reencrypt secret key for principalname

The most likely cause of this problem is that your Secure RPC password is different from your login password (or you have one password on file in a local /etc/shadow file and a different one in a remote NIS+ table) and you have not yet done an explicit keylogin. See "NIS+ and Login Passwords in /etc/passwd File" and " Secure RPC Password and Login Passwords Are Different" for more information on these types of problems.


WARNING: db::checkpoint: could not dump database: No such file or directory

This message indicates that the system was unable to open a database file during a checkpoint. Possible causes:

  • The database file was deleted.

  • The server is out of file descriptors.

  • There is a disk problem

  • You or the host do not have correct permissions.


WARNING: db_dictionary::add_table: could not initialize database from scheme

The database table could not be initialized. Possible causes:

  • There was a system resource problem See "NIS+ System Resource Problems").

  • You incorrectly specified the new table in the command syntax.

  • The database is corrupted.


WARNING: db_query::db_query:bad index

In most cases this message indicates incorrect specification of an indexed name. Make sure that the indexed name is found in the specified table. Check the command for spelling and syntax errors.


**WARNING: domain domainname already exists.

This message indicates that the domain you tried to create already exists.

  • If you are trying to promote a new nonroot master server or are recovering from a previous nisserver problem, continue running the script.

  • If domainname was spelled incorrectly, rerun the script with the correct domain name.


**WARNING: failed to add new member NIS+_principle into the groupname group. You will need to add this member manually: 1. /usr/sbin/nisgrpadm -a groupname NIS+_principal

The NIS+ command nisgrpadm failed to add a new member into the NIS+ group groupname. Manually add this NIS+ principal by typing:


# /usr/sbin/nisgrpadm -a groupname NIS+_principal

**WARNING: failed to populate tablename table.

The nisaddent command was unable to load the NIS+ tablename table. A more detailed error message usually appears before this warning message.


**WARNING: hostname specified will not be used. It will use the local hostname instead.

This message indicates that you typed a remote host name with the -H option. The nisserver -rscript does not configure remote machines as root master servers.

  • If the local machine is the one that you want to convert to an NIS+ root master server, no other action is needed. The nisserver -rscript will ignore the host name you typed.

  • If you actually want to convert the remote host (instead of the local machine) to an NIS+ root master server, exit the script. Rerun the nisserver -rscript on the remote host.


**WARNING: hostname is already a server for this domain. If you choose to continue with the script, it will try to replicate the groups_dir and org_dir directories for this domain.

This is a message warning you that hostname is already a replica server for the domain that you are trying to replicate.

  • If you are running the script to fix an earlier nisserver problem, continue running the script.

  • If hostname was mistakenly entered, rerun the script with the correct host name.


**WARNING: alias-hostname is an alias name for host canonical_hostname. You cannot create credential for host alias.

This message indicates that you have typed a host alias in the name list for nisclient -c. The script asks you if you want to create the credential for the canonical host name, since you should not create credentials for host alias names.


**WARNING: file directory-path/tablename does not exist! tablename table will not be loaded.

The script was unable to find the input file for tablename.

  • If directory-path/tablename is spelled incorrectly, rerun the script with the correct table name.

  • If the directory-path/tablename file does not exist, create and update this file with the proper data. Then rerun the script to populate this table.


**WARNING: NIS auto.master map conversion failed. auto.master table will not be loaded.

The auto.master map conversion failed while trying to convert all the dots to underscores in the auto_master table. Rerun the script with a different NIS server.


**WARNING: NIS netgroup map conversion failed. netgroup table will not be loaded.

The netgroup map conversion failed while trying to convert the NIS domain name to the NIS+ domain name in the netgroup map. Rerun the script with a different NIS server.


**WARNING: nisupdkeys failed on directory domainname. This script will not be able to continue. Please remove the domainname directory using `nisrmdir'.

The NIS+ command nisupdkeys failed to update the keys in the listed directory object. If rpc.nisd is not running on the new master server that is supposed to serve this new domain, restart rpc.nisd. Then use nisrmdir to remove the domainname directory. Finally, rerun nisserver.


WARNING: nisupdkeys failed on directory directory-name You will need to run nisupdkeys manually: 1. /usr/lib/nis/nisupdkeys directory-name

The NIS+ command nisupdkeys failed to update the keys in the listed directory object. Manually update the keys in the directory object by typing:


# /usr/lib/nis/nisupdkeys directory-name

**WARNING: once this script is executed, you will not be able to restore the existing NIS+ server environment. However, you can restore your NIS+ client environment using "nisclient -r" with the proper domainname and server information. Use "nisclient -r" to restore your NIS+ client environment.

These messages appear if you have already run the script at least once before to set up an NIS+ server. They indicate that NIS+-related files will be removed and recreated as needed if you decide to continue running this script.

  • If it is all right for these NIS+ files to be removed, continue running the script.

  • If you want to save these NIS+ files, exit the script by typing "n" at the Do you want to continue? prompt. Then save the NIS+ files in a different directory and rerun the script.


**WARNING: this script removes directories and files related to NIS+ under /var/nis directory with the exception of the NIS_COLD_START and NIS_SHARED_DIRCACHE files which will be renamed to <file>.no_nisplus. If you want to save these files, you should abort from this script now to save these files first.

See "WARNING: once this script is executed,..." above.


**WARNING: you must specify the NIS domainname.

This message indicates that you did not type the NIS domain name at the prompt. Type the NIS server domain name at the prompt.


**WARNING: you must specify the NIS server hostname. Please try again.

This message indicates that you did not type the NIS server host name at the prompt. Type the NIS server host name at the prompt.


Window verifier mismatch

This is a debugging message generated by the _svcauth_des code. A verifier could be invalid because a key was flushed out of the cache. When this occurs, _svcauth_des returns the AUTH_BADCRED status.


You (string) do not have Secure RPC credentials in NIS+ domain 'string'

This message could be caused by trying to run nispasswd on a server that does not have the credentials required by the command. (Keep in mind that servers running at security level 0 do not create or maintain credentials.)

See "NIS+ Ownership and Permission Problems" for additional information on credential, ownership, and permission problems.


You may not change this password

This message indicates that your administrator has forbidden you to change your password.


You may not use nisplus repository

You used -r nisplus in the command line of your command, but the appropriate entry in the NIS+ passwd table was not found. Check the passwd table in question to make sure it has the entry you want. Try adding nisplus to the nsswitch.conf file.


Your password has been expired for too long


Your password is expired

These messages refer to password aging. They indicate that your password has been in use too long and needs to be changed now. See "The password expired Message" for further information.


Your password will expire in nn days


Your password will expire within 24 hours

These messages refer to password aging. They indicate that your password is about to become invalid and should be changed now. See "The will expire Message" for further information.


Your specified repository is not defined in the nsswitch file!

This warning indicates that you have specified a password information repository with the -r option, but that password repository is not included in the passwd entry of the nsswitch.conf file. The command you have just used will perform its job and make whatever change you intend to the password information repository you specified with the -r flag. However, the change will be made to information that the nsswitch.conf file does not point to, so no one will ever gain the benefit of it until the switch file is altered to point to that repository.

For example, suppose the passwd entry of the switch file reads: files nis, and you used


passwd -r nisplus

to establish a password age limit. That limit would not affect anyone because they are still using a switch file set to files nis.


verify_table_exists: cannot create table for string nis_perror message.

To perform an operation on a table, NIS+ first verifies that the table exists. If the table does not exist, NIS+ attempts to create it. If it cannot create the table, it returns this error message. The string portion of the message identifies the table that could not be located or created; the nis_perror message portion provides information as to the cause of the problem (you can look up that portion of the message as if it were an independent message in this appendix). Possible causes for this type of problem:

  • The server was just added as a replica of the directory and it might not have the directory object. Run nisping -C to checkpoint.

  • You are out of disk space. See "Insufficient Disk Space".

  • Database corruption.

  • Some other type of software error. Contact the Sun Solutions Center.


ypcat: can't bind to NIS server for domain domainname. Reason: can't communicate with ypbind.

See "NIS Problems and Solutions"


yppoll: can't get any map parameter.

See "NIS Problems and Solutions"

Appendix C Information in NIS+ Tables

This appendix summarizes the information stored in the default NIS+ tables supplied in the Solaris operating environment. (See Chapter 14, Administering NIS+ Tables, for general information regarding NIS+ tables and the commands used to administer them.)

NIS+ Tables

In an NIS+ environment, most namespace information is stored in NIS+ tables.

Without a name service, most network information would be stored in /etc files and almost all NIS+ tables have corresponding /etc files. With the NIS service, you stored network information in NIS maps that also mostly corresponded with /etc files.

Note -

This appendix describes only those that are distributed as part of NIS+. Users and application developers frequently create NIS+ compatible tables for their own purposes. For information about tables created by users and developers, you must consult the documentation that they provide.

All NIS+ tables are stored in the domain's org_dir NIS+ directory object except the admin and groups tables that are stored in the groups_dir directory object.

Note -

Do not link table entries. Tables can be linked to other tables, but do not link an entry in one table to an entry in another table.

NIS+ Tables and Other Name Services

In the Solaris environment the name service switch file (nsswitch.conf) allows you to specify one or more sources for different types of namespace information. In addition to NIS+ tables, sources can be NIS maps, DNS zone files, or /etc tables. The order in which you specify them in the switch file determines how the information from different sources is combined. (See Chapter 2, The Name Service Switch for more information on the switch file.)

NIS+ Table Input File Format

If you are creating input files for any of these tables, most tables share two formatting requirements:

If a particular table has different or additional format requirements, they are described under the heading, "Input File Format."

auto_home Table

The auto_home table is an indirect automounter map that enables an NIS+ client to mount the home directory of any user in the domain. It does this by specifying a mount point for each user's home directory, the location of each home directory, and mount options, if any. Because it is an indirect map, the first part of the mount point is specified in the auto_master table, which is, by default, /home. The second part of the mount point (that is, the subdirectory under /home) is specified by the entries in the auto_home map, and is different for each user.

The auto_home table has two columns:

Table C-1 auto_home Table

Column 

Content 

Description 

Key 

Mount point 

The login name of every user in the domain 

Value 

 

Options & location 

The mount options for every user, if any, and the location of the user's home directory 

For example:


costas barcelona:/export/partition2/costas

The home directory of the user costas, which is located on the server barcelona, in the directory /export/partition2/costas, would be mounted under a client's /home/costas directory. No mount options were provided in the entry.

auto_master Table

The auto_master table lists all the automounter maps in a domain. For direct maps, the auto_master table provides a map name. For indirect maps, it provides both a map name and the top directory of its mount point. The auto_master table has two columns:

Table C-2 auto_master Table

Column 

Content 

Description 

Key 

Mount point 

The top directory into which the map will be mounted. If the map is a direct map, this is a dummy directory, represented with /--.

Value 

Map name 

The name of the automounter map 

For example, assume these entries in the auto_master table:


/home auto_home
 /-auto_man
 /programs auto_programs

The first entry names the auto_home map. It specifies the top directory of the mount point for all entries in the auto_home map: /home. (The auto_home map is an indirect map.) The second entry names the auto_man map. Because that map is a direct map, the entry provides only the map name. The auto_man map will itself provide the topmost directory, as well as the full path name, of the mount points for each of its entries. The third entry names the auto_programs map and, since it provides the top directory of the mount point, the auto_programs map is an indirect map.

All automounter maps are stored as NIS+ tables. By default, the Solaris environment provides the auto_master map, which is mandatory, and the auto_home map, which is a great convenience.

You can create more automounter maps for a domain, but be sure to store them as NIS+ tables and list them in the auto_master table. When creating additional automount maps to supplement auto_master (which is created for you), the column names must be key and value. For more information about the automounter consult your automounter or NFS file system documentation.

bootparams Table

The bootparams table stores configuration information about every diskless workstation in a domain. A diskless workstation is a workstation that is connected to a network, but has no hard disk. Since it has no internal storage capacity, a diskless workstation stores its files and programs in the file system of a server on the network. It also stores its configuration information--or boot parameters--on a server.

Because of this arrangement, every diskless workstation has an initialization program that knows where this information is stored. If the network has no name service, the program looks for this information in the server's /etc/bootparams file. If the network uses the NIS+ name service, the program looks for it in the bootparams table, instead.

The bootparams table can store any configuration information about diskless workstations. It has two columns: one for the configuration key, another for its value. By default, it is set up to store the location of each workstation's root, swap, and dump partitions.

The default bootparams table has only two columns that provide the following items of information:

Table C-3 bootparams Table

Column 

Content 

Description 

Key 

Hostname 

The diskless workstation's official host name, as specified in the hosts table 

Value 

Configuration 

Root partition: the location (server name and path) of the workstation's root partition 

 

 

Swap partition: the location (server name and path) of the workstation's swap partition 

 

 

Dump partition: the location (server name and path) of the workstation's dump partition 

 

 

Install partition. 

 

 

Domain. 

Input File Format

The columns are separated with a TAB character. Backslashes (\) are used to break a line within an entry. The entries for root, swap, and dump partitions have the following format:


client-name root=server:path \
swap=server:path \ 
dump=server:path \
install=server:path \
domain=domainname

Here is an example:


buckarooroot=bigriver:/export/root1/buckaroo \
 swap=bigriver:/export/swap1/buckaroo \
 dump=bigriver:/export/dump/buckaroo \
 install=bigriver:/export/install/buckaroo \
 domain=sales.doc.com

Additional parameters are available for x86-based workstations. See the bootparams man page for additional information.

client_info Table

The client_info table is an optional internal NIS+ table used to store server preferences for the domain in which it resides. This table is created and maintained with the nisprefadm command.

Caution - Caution -

Only use nisprefadm to work with this table. Do not use any other NIS+ commands on this table.

cred Table

The cred table stores credential information about NIS+ principals. Each domain has one cred table, which stores the credential information of client workstations that belong to that domain and client users who are allowed to log into them. (In other words, the principals of that domain.) The cred tables are located in their domains' org_dir subdirectory.

Note -

Do not link a cred table. Each org_dir directory should have its own cred table. Do not use a link to some other org_dir cred table.

The cred table has five columns:

Table C-4 cred Table

NIS+ Principal Name 

Authentication Type 

Authentication Name 

Public Data 

 

Private Data 

 

Principal name of a principal user 

LOCAL 

UID 

GID list 

 

Principal name of a principal user or workstation 

DES 

Secure RPC netname 

Public key 

Encrypted private key 

The second column, authentication type, determines the types of values found in the other four columns.

See Chapter 7, Administering NIS+ Credentials, for additional information on credentials and the cred table.

ethers Table

The ethers table stores information about the 48-bit Ethernet addresses of workstations on the Internet. It has three columns:

Table C-5 ethers Table

Column 

Content 

Description 

Addr 

Ethernet-address 

The 48-bit Ethernet address of the workstation 

Name 

Official-host-name 

The name of the workstation, as specified in the hosts table 

Comment 

Comment 

An optional comment about the entry 

An Ethernet address has the form:

n:n:n:n:n:n hostname

where n is a hexadecimal number between 0 and FF, representing one byte. The address bytes are always in network order (most significant byte first).

group Table

The group table stores information about UNIX user groups. The group table has four columns:

Table C-6 group Table

Column 

Description 

Name 

The group's name 

Passwd 

The group's password 

GID 

The group's numerical ID 

Members 

The names of the group members, separated by commas 

Earlier Solaris releases used a +/- syntax in local /etc/group files to incorporate or overwrite entries in the NIS group maps. Since the Solaris environment uses the name service switch file to specify a workstation's sources of information, this is no longer necessary. All you have to do in Solaris Release 2x systems is edit a client's /etc/nsswitch.conf file to specify files, followed by nisplus as the sources for the group information. This effectively adds the contents of the group table to the contents of the client's /etc/group file.

hosts Table

The hosts table associates the names of all the workstations in a domain with their IP addresses. The workstations are usually also NIS+ clients, but they don't have to be. Other tables, such as bootparams, group, and netgroup, rely on the network names stored in this table. They use them to assign other attributes, such as home directories and group memberships, to individual workstations. The hosts table has four columns:

Table C-7 hosts Table

Column 

Description 

Addr 

The workstation's IP address (network number plus workstation ID number) 

Cname 

The workstation's official name 

Name 

A name used in place of the host name to identify the workstation 

Comment 

An optional comment about the entry 

mail_aliases Table

The mail_aliases table lists the domain's mail aliases recognized by sendmail. It has four columns:

Table C-8 mail_aliases Table

Column 

Description 

Alias 

The name of the alias 

Expansion 

A list containing the members that receive mail sent to this alias; members can be users, workstations, or other aliases 

Comment 

An optional comment about the entry 

Options 

(See man page for options) 

Input File Format

Each entry has the following format:


alias-name:member[,member]...

To extend an entry over several lines, use a backslash.

netgroup Table

The netgroup table defines network wide groups used to check permissions for remote mounts, logins, and shells. The members of net groups used for remote mounts are workstations; for remote logins and shells, they are users.

Note -

Users working on a client machine being served by a NIS+ server running in compatibility mode cannot run ypcat on the netgroup table. Doing so will give you results as if the table were empty even if it has entries.

The netgroup table has six columns:

Table C-9 netgroup Table

Column 

Content 

Description 

Name 

groupname 

The name of the network group 

Group 

groupname 

Another group that is part of this group 

Host 

hostname 

The name of a host 

User 

username 

A user's login name 

Domain 

domainname 

A domain name 

Comment 

Comment 

An optional comment about the entry 

Input File Format

The input file consists of a group name and any number of members:


groupname member-list...

The member list can contain the names of other net groups or an ordered member list with three fields or both:


member-list::=groupname | (hostname, username, domainname)

The first field of the member list specifies the name of a workstation that belongs to the group. The second field specifies the name of a user that belongs to the group. The third field specifies the domain in which the member specification is valid.

A missing field indicates a wildcard. For example, the netgroup specification shown below includes all workstations and users in all domains: 


everybody ( , , )

A dash in a field is the opposite of a wildcard; it indicates that no workstations or users belong to the group. Here are two examples:


(host1, -,doc.com.) (-,joe,doc.com.)

The first specification includes one workstation, host1, in the doc.com. domain, but excludes all users. The second specification includes one user in the doc.com. domain, but excludes all workstations.

netmasks Table

The netmasks table contains the network masks used to implement standard Internet subnetting. The table has three columns:

Table C-10 netmasks Table

Column 

Description 

Addr 

The IP number of the network 

Mask 

The network mask to use on the network 

Comment 

An optional comment about the entry 

For network numbers, you can use the conventional IP dot notation used by workstation addresses, but leave zeros in place of the workstation addresses. For example, this entry


128.32.0.0 255.255.255.0

means that class B network 128.32.0.0 should have 24 bits in its subnet field, and 8 bits in its host field.

networks Table

The networks table lists the networks of the Internet. This table is normally created from the official network table maintained at the Network Information Control Center (NIC), though you might need to add your local networks to it. It has four columns:

Table C-11 networks Table

Column 

Description 

Cname 

The official name of the network, supplied by the Internet 

Addr 

The official IP number of the network 

Name 

An unofficial name for the network 

Comment 

An optional comment about the entry 

passwd Table

The passwd table contains information about the accounts of users in a domain. These users generally are, but do not have to be, NIS+ principals. Remember though, that if they are NIS+ principals, their credentials are not stored here, but in the domain's cred table. The passwd table usually grants read permission to the world (or to nobody).

Note -

The passwd table should not have an entry for the user root (user ID 0). Root's password information should be stored and maintained in the machine's /etc files.

The information in the passwd table is added when users' accounts are created.

The passwd table contains the following columns:

Table C-12 passwd Table

Column 

Description 

Name 

The user's login name, which is assigned when the user's account is created; the name can contain no uppercase characters and can have a maximum of eight characters 

Passwd 

The user's encrypted password 

UID 

The user's numerical ID, assigned when the user's account is created 

GID 

The numerical ID of the user's default group 

GCOS 

The user's real name plus information that the user wishes to include in the From: field of a mail-message heading; an "&" in this column simply uses the user's login name 

Home 

The path name of the user's home directory. 

Shell 

The user's initial shell program; the default is the Bourne shell: /usr/bin/sh.

Shadow 

(See Table C-13.)

The passwd table shadow column stores restricted information about user accounts. It includes the following information:

Table C-13 passwd Table Shadow Column

Item 

Description 

Lastchg 

The number of days between January 1, 1970, and the date the password was last modified 

Min 

The minimum number of days recommended between password changes 

Max 

The maximum number of days that the password is valid 

Warn 

The number of days' warning a user receives before being notified that his or her password has expired 

Inactive 

The number of days of inactivity allowed for the user 

Expire 

An absolute date past which the user's account is no longer valid 

Flag 

Reserved for future use: currently set to 0. 

Earlier Solaris releases used a +/- syntax in local /etc/passwd files to incorporate or overwrite entries in the NIS password maps. Since the Solaris Release 2x environment uses the name service switch file to specify a workstation's sources of information, this is no longer necessary. All you have to do in Solaris Release 2x systems is edit a client's /etc/nsswitch.conf file to specify files, followed by nisplus as the sources for the passwd information. This effectively adds the contents of the passwd table to the contents of the /etc/passwd file.

However, if you still want to use the +/- method, edit the client's nsswitch.conf file to add compat as the passwd source if you are using NIS. If you are using NIS+, add passwd_compat: nisplus.

protocols Table

The protocols table lists the protocols used by the Internet. It has four columns:

Table C-14 protocols Table

Column 

Description 

Cname 

The protocol name 

Name 

An unofficial alias used to identify the protocol 

Number 

The number of the protocol 

Comments 

Comments about the protocol 

rpc Table

The rpc table lists the names of RPC programs. It has four columns:

Table C-15 rpc Table

Column 

Description 

Cname 

The name of the program 

Name 

Other names that can be used to invoke the program 

Number 

The program number 

Comments 

Comments about the RPC program 

Here is an example of an input file for the rpc table: 


#
# rpc file
#
rpcbind	00000	portmap	sunrpc	portmapper
rusersd	100002	rusers
nfs	100003	nfsprog
mountd	100005	mount	showmount
walld	100008	rwall	shutdown
sprayd	100012	spray
llockmgr	100020
nlockmgr	100021
status	100024
bootparam	100026
keyserv	100029	keyserver
nisd	100300	rpc.nisd
#

services Table

The services table stores information about the Internet services available on the Internet. It has five columns:

Table C-16 services Table

Column 

Description 

Cname 

The official Internet name of the service 

Name 

The list of alternate names by which the service can be requested 

Proto 

The protocol through which the service is provided (for instance, 512/tcp) 

Port 

The port number 

Comment 

Comments about the service 

timezone Table

The timezone table lists the default timezone of every workstation in the domain. The default time zone is used during installation but can be overridden by the installer. The table has three columns:

Table C-17 timezone Table

Field 

Description 

Name 

The name of the domain 

Tzone 

The name of the time zone (for example, US/Pacific) 

Comment 

Comments about the time zone 

Appendix D FNS Reference Formats and Syntax

This appendix contains supplemental information about the use of DNS text (TXT) records and the use of X.500 attributes in XFN references.

DNS Text Record Format for XFN References

The Solaris environment conforms to the XFN specification for federating global naming systems within DNS. In order to federate a naming system under DNS, you need to enter information into DNS TXT resource records. This information is then used to construct an XFN reference for that subordinate naming system. This appendix describes the format of these DNS TXT records.

The reference type of an XFN reference is constructed from a TXT record that begins with the XFNREF tag. It has the following format: 


TXT "XFNREF rformat reftype"

If spaces occur within the string appearing after TXT, such spaces must be escaped, or the entire string must be enclosed within double quotation marks. The three fields, XFNREF, rformat and reftype, are separated using space (spaces and tabs). rformat specifies format of the reference type identifier. It can be one of the following:

reftype specifies the contents of the reference type identifier.

If no XFNREF TXT record exists, the reference type defaults to an identifier XFN_SERVICE, with an FN_ID_STRING format. If more than one XFNREF TXT record exists, the handling of the record is undefined. The following TXT record is equivalent to the default XFNREF: 


TXT "XFNREF STRING XFN_SERVICE"

The address information for an XFN reference is constructed using TXT records with tags prefixed with the XFN string. Multiple addresses may be specified for a single reference. Records with the same tag are grouped and passed to the handler for each group. Each handler generates zero or more addresses from its group of TXT records and appends the addresses to the reference. The XFNREF tag is special in that it is used only to construct the reference type and thus, it is excluded from the address-construction process.

The syntax of address TXT records is as follows:


XFNaddress_type_tag   address_specific_data

The two fields, XFN_address_type_tag and address_specific_data, are separated using space (spaces and tabs). The address_type_tag specifies the handler to be used for address_specific_data.

TXT records have a limitation of 2K bytes of characters per record. If the address-specific data is too long to be stored in a single TXT record, multiple TXT records may be used, as shown:


TXT "XFNaddress_type_tag address_specific_data1"
TXT "XFNaddress_type_tag address_specific_data2"

When the tag-specific handler is called, both records are passed to it. The handler is responsible for determining the order in which these two lines need to be interpreted.

The order in which TXT records appear is not significant. If lines with different tags are present, lines with the same tag are grouped together before the tag-specific handler is called. In the following example, the handler for tag1 will be called with two text lines, and the handler for tag2 will be called with three text lines.


TXT "XFNtag1 address_specific_data1"
TXT "XFNtag2 address_specific_data2"
TXT "XFNtag1 address_specific_data3"
TXT "XFNtag2 address_specific_data4"
TXT "XFNtag2 address_specific_data5"

Here are some examples of TXT records that can be used for XFN references.

Example 1 


TXT		"XFNREF STRING XFN_SERVICE"
TXT		"XFNNISPLUS doc.com. nismaster 129.144.40.23"

Example 2 


TXT		"XFNREF OID 1.3.22.1.6.1.3"
TXT		"XFNDCE (1 fd33328c4-2a4b-11ca-af85-09002b1c89bb...)"

The following is an example of a DNS table with a subordinate naming system bound in it. 


$ORIGIN test.doc.com
@      IN SOA foo root.eng.doc.com          (
             100    ;; Serial
             3600   ;; Refresh
             3600   ;; Retry
             3600   ;; Expire
             3600   ;; Minimum
          )
       NS    nshost
       TXT   "XFNREF STRING XFN_SERVICE"
       TXT   "XFNNISPLUS doc.com. nismaster 129.144.40.23"
nshost IN  A 129.144.40.21

X.500 Attribute Syntax for XFN References

This section contains supplemental information about the use of X.500 attributes for XFN references. In order to permit an XFN reference to be stored as an attribute in X.500, the directory schema must be modified to support the object classes and attributes defined in this appendix.

Object Classes

Two new object classes, XFN and XFN-supplement, are introduced to support XFN references. The XFN object class is not relevant in FNS since the Sun Microsystems X.500 directory product cannot support the introduction of new compound ASN.1 syntaxes. Instead, FNS uses the XFN-supplement object class.

The two new object classes are defined in ASN.1 as follows:


   xFN OBJECT-CLASS ::= {
            SUBCLASS OF         { top }
            KIND                auxiliary
            MAY CONTAIN         { objectReferenceId |
                                  objectReference |
                                  nNSReferenceId |
                                  nNSReference }
            ID                  id-oc-xFN
        }
        id-oc-xFN OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-oc-xFN(24)
        }
   xFNSupplement OBJECT-CLASS ::= {
            SUBCLASS OF         { top }
            KIND                auxiliary
            MAY CONTAIN         { objectReferenceString |
                                  nNSReferenceString }
            ID                  id-oc-xFNSupplement
        }   
        id-oc-xFNSupplement OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-oc-xFNSupplement(25)
        }

The XFN-supplement object class is defined as an auxiliary object class so that it may be inherited by all X.500 object classes. It is defined with two optional attributes:

Both attributes are defined in ASN.1 as follows: 


        objectReferenceString ATTRIBUTE ::= {
            WITH SYNTAX             OCTET STRING
            EQUALITY MATCHING RULE  octetStringMatch
            SINGLE VALUE            TRUE
            ID                      { id-at-objectReferenceString }
        }
        id-at-objectReferenceString OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-at-objectReferenceString(30)
        }
        nNSReferenceString ATTRIBUTE ::= {
            WITH SYNTAX             OCTET STRING
            EQUALITY MATCHING RULE  octetStringMatch
            SINGLE VALUE            TRUE
            ID                      { id-at-nNSReferenceString }
        }
        id-at-nNSReferenceString OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-at-nNSReferenceString(31)
        }

Both objectReferenceString and nNSReferenceString store XFN references in a string form. Their octet string syntax is further constrained to conform to the following BNF definition:


     <ref>          ::= <id> '$' <ref-addr-set>
     <ref-addr-set> ::= <ref-addr> | <ref-addr> '$' <ref-addr-set>
     <ref-addr>     ::= <id> '$' <addr-set>
     <addr>         ::= <hex-string>
     <id>           ::= 'id'   '$' <string> |
                        'uuid' '$' <uuid-string> |
                        'oid'  '$' <oid-string>
     <string>       ::= <char> | <char> <string>
     <char>         ::= <PCS> | '\' <PCS>
     <PCS>          ::= // Portable Character Set:
                        // !"#$%&'()*+,-./0123456789:;<=>?
                        // @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
                        // `abcdefghijklmnopqrstuvwxyz{|}~
     <uuid-string>  ::= <uuid-char>  | <uuid-char> <uuid-string>
     <uuid-char>    ::= <hex-digit> | '-'
     <oid-string>   ::= <oid-char>  | <oid-char> <oid-string>
     <oid-char>     ::= <digit> | '.'
     <hex-string>   ::= <hex-octet> | <hex-octet> <hex-string>
     <hex-octet>    ::= <hex-digit> <hex-digit>
     <hex-digit>    ::= <digit> |
                        'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
                        'A' | 'B' | 'C' | 'D' | 'E' | 'F'
     <digit>        ::= '0' | '1' | '2' | '3' | '4' | '5' |
                        '6' | '7' | '8' | '9'

The following example is a string form XFN reference:


id$onc_fn_enterprise$id$onc_fn_nisplus_root$0000000f77697a2e636fd2e2062696762696700

The example uses an XFN reference of type onc_fn_enterprise. It contains the address type onc_fn_nisplus_root and a single address value. The address value is an XDR-encoded string, comprising the domain name, doc.com, followed by the host name, cygnus.

An XFN reference may be added to an X.500 entry by using the FNS command fnattr, as in this example: 


# fnattr -a .../c=us/o=doc object-class top organization xfn-supplement

creates a new entry called c=us/o=doc and adds an object class attribute with the values top, organization , and XFN-supplement.

The FNS command fnbind binds the NIS+ reference to the named entry and links X.500 to the root of the NIS+ namespace. (Note the use of a trailing slash in the name argument to fnbind.) 


# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root
 "doc.com. cygnus"