|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris Administration: Naming and Directory Services Oracle Solaris 11 Information Library|
This section covers two areas of troubleshooting:
Sometimes the N2L server logs errors that relate to internal LDAP problems, resulting in LDAP-related error messages. Although the errors are nonfatal, they indicate problems to investigate. For example, the N2L server might continue to operate, but provide out-of-date or incomplete results.
The following list includes some of the common LDAP error messages that you might encounter when implementing the N2L service. Error descriptions, and possible causes and solutions for the errors, are included.
Administrative limit exceeded
Error Number: 11
Cause: An LDAP search was made that was larger than allowed by the directory server's nsslapd-sizelimit attribute. Only partial information will be returned.
Solution: Increase the value of the nsslapd-sizelimit attribute, or implement a VLV index for the failing search.
Invalid DN Syntax
Error Number: 34
Cause: An attempt has been made to write an LDAP entry with a DN that contains illegal characters. The N2L server attempts to escape illegal characters, such as the + symbol, that are generated in DNs.
Solution: Check the LDAP server error log to find out which illegal DNs were written, then modify the NISLDAPmapping file that generated the illegal DNs.
Object class violation
Error Number: 65
Cause: An attempt has been made to write an LDAP entry that is invalid. Generally, this error is due to missing MUST attributes that can be caused by either of the following circumstances.
Bugs in the NISLDAPmapping file that create entries with missing attributes
Attempts to add an AUXILIARY attribute to an object that does not exist
For example, if a user name has not yet been created from the passwd.byxxx map, an attempt to add auxiliary information to that user will fail.
Solution: For bugs in the NISLDAPmapping file, check what was written in the server error log to determine the nature of the problem.
Can't contact LDAP server
Error Number: 81
Cause: The ypserv file might be incorrectly configured to point to the wrong LDAP directory server. Alternatively, the directory server might not be running.
Reconfigure the ypserv file to point to the correct LDAP directory server.
To confirm that the LDAP server is running, become superuser, or assume an equivalent role, on the directory server and type:
# pgrep -l slapd
Error Number: 85
Cause: An LDAP operation timed out, typically while updating a map from the DIT. The map might now contain out-of-date information.
Solution: Increase the nisLDAPxxxTimeout attributes in the ypserv configuration file.
The following problems could occur while running the N2L server. Possible causes and solutions are provided.
The mapping file, NISLDAPmapping, is complex. Many potential errors might cause the mapping to behave in unexpected ways. Use the following techniques to resolve such problems.
Console Message Displays When ypserv -ir(or -Ir) Runs
Problem: A simple message is displayed on the console and the server exits (a detailed description is written to syslog).
Cause: The syntax of the mapping file might be incorrect.
Solution: Check and correct the syntax in the NISLDAPmapping file.
NIS Daemon Exits at Startup
Problem: When ypserv or other NIS daemons run, an LDAP-related error message is logged and the daemon exits.
Cause: The cause might be one of the following:
The LDAP server cannot be contacted.
An entry found in an NIS map or in the DIT is incompatible with the mapping specified.
An attempt to read or write to the LDAP server returns an error.
Solution: Examine the error log on the LDAP server. See the LDAP errors that are listed in Common LDAP Error Messages.
Unexpected Results From NIS Operations
Problem: NIS operations do not return the expected results, but no errors are logged.
Cause: Incorrect entries might exist in the LDAP or NIS maps, which results in mappings not completing as intended.
Solution: Check and correct entries in the LDAP DIT and in the N2L versions of the NIS maps.
Check that the correct entries exist in the LDAP DIT, and correct the entries as needed.
If you are using Oracle Directory Server Enterprise Edition, start the management console by running the dsadm startconsole command.
Check that the N2L versions of the NIS maps in the /var/yp directory contain the expected entries by comparing the newly generated map to the original map. Correct entries as needed.
# cd /var/yp/domainname # makedbm -u test.byname # makedbm -u test.byname
Be aware of the following when checking the output for the maps:
The order of entries might not be the same in both files.
Use the sort command before comparing output.
The use of white space might not be the same in both files.
Use the diff -b command when comparing output.
Processing Order of NIS Maps
Problem: Object class violations occur.
Cause: When the ypserv -i command is run, each NIS map is read and its contents are written into the DIT. Several maps might contribute attributes to the same DIT object. Generally, one map creates most of the object, including all the object's MUST attributes. Other maps contribute additional MAY attributes.
Maps are processed in the same order that nisLDAPobjectDN attributes appear in the NISLDAPmapping file. If maps containing MAY attributes get processed before maps containing MUST attributes, then object class violations occur. See Error 65 in Common LDAP Error Messages for more information about this error.
Solution: Reorder the nisLDAPobjectDN attributes so that maps are processed in the correct order.
As a temporary fix, rerun the ypserv -i command several times. Each time the command is executed, more of the LDAP entry is built up.
Note - Mapping in such a way that all of an object's MUST attributes cannot be created from at least one map is not supported.
Problem: The server times out.
Cause: When the N2L server refreshes a map, the result might be a large LDAP directory access. If the Oracle Directory Server Enterprise Edition is not correctly configured, this operation might time out before completion.
Solution: To avoid directory server timeouts, modify the Oracle Directory Server Enterprise Edition attributes manually or by running the idsconfig command. See Common LDAP Error Messages and NIS-to-LDAP Best Practices With Oracle Directory Server Enterprise Edition for details.
Problem: The ypserv command starts but does not respond to NIS requests.
Cause: The N2L server lock files are not correctly synchronizing access to the NIS maps. This should never happen.
# svcadm disable network/nis/server:default # rm /var/run/yp_maplock /var/run/yp_mapupdate # svcadm enable network/nis/server:default
Problem: The N2L server deadlocks.
Cause: If the addresses of the N2L master server and the LDAP server are not listed properly in the hosts, ipnodes, or ypserv files, a deadlock might result. See Prerequisites for the NIS-to-LDAP Transition for details about proper address configuration for N2L.
For an example of a deadlock scenario, consider the following sequence of events:
An NIS client tries to look up an IP address.
The N2L server finds that the hosts entry is out-of-date.
The N2L server tries to update the hosts entry from LDAP.
The N2L server gets the name of its LDAP server from ypserv, then does a search by using libldap.
libldap tries to convert the LDAP server's name to an IP address by making a call to the name service switch.
The name service switch might make an NIS call to the N2L server, which deadlocks.
Solution: List the addresses of the N2L master server and the LDAP server in the hosts or ipnodes files on the N2L master server. Whether the server addresses must be listed in hosts, ipnodes, or both files depends on how these files are configured to resolve local host names. Also, check that the config/hosts property of the svc:/network/name-service/switch service lists files before nis in the lookup order.
An alternative solution to this deadlock problem is to list the LDAP server address, not its host name, in the ypserv file. This means that the LDAP server address would be listed in another place. Therefore, changing the address of either the LDAP server or the N2L server would require slightly more effort.