This section covers the following areas of troubleshooting:
The N2L server might log errors that relate to internal LDAP problems, resulting in LDAP-related error messages. Although the errors are nonfatal, they indicate that you need to investigate the problems. The N2L server might continue to operate but provide out-of-date or incomplete results.
This section describes some of the common LDAP error messages that you might encounter when implementing the N2L service. It also includes error descriptions and possible causes and solutions for the errors.
Administrative limit exceeded
Error Number: 11
Cause: An LDAP search was larger than the limit allowed by the directory server's nsslapd-sizelimit attribute. The search returns partial information.
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 and 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 the information 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.
Solution: Perform the following actions to resolve the issue:.
Reconfigure the ypserv file to point to the correct LDAP directory server.
Type the following command to confirm that the LDAP server is running:
% ping hostname 5 | grep "no answer" || \ (ldapsearch -H ldapuri -s base -b "" \ "objectclass=*" >/dev/null && echo Directory accessible)
If the server is unavailable, the following message is displayed:
no answer from hostname
If there are problems with the LDAP server, the following message is displayed:
ldap_search: Can't connect to the LDAP server - Connection refused
If everything is working, the following message is displayed:
Error Number: 85
Cause: An LDAP operation timed out 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.
This section describes problems that could occur while running the N2L server and provides possible causes and solutions.
The mapping file, NISLDAPmapping, is complex. Different issues might cause the mapping to behave in unexpected ways. Use the described techniques to resolve such problems.
Console Message Displays When ypserv -ir (or –Ir) Runs
Description: 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
Description: 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. For the information about LDAP errors, see Common LDAP Error Messages.
Unexpected Results From NIS Operations
Description: 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 fix the entries as needed.
If you are using OUD, 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. Fix entries as needed.
# cd /var/yp/domain-name # 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
Description: Object class violations have occurred.
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 of 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. For more information about this error, see Common LDAP Error Messages.
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, the LDAP entry approaches a complete state.
The server times out.
Cause: When the N2L server refreshes a map, the result might require a single lengthy access of a large LDAP directory. If OUD is not correctly configured, this operation might time out before completion.
Solution: To avoid directory server timeouts, modify the OUD attributes manually or by running the ldapservercfg command. For more information, see Common LDAP Error Messages and NIS-to-LDAP Best Practices With Oracle Unified Directory.
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.
Solution: Type the following commands on the N2L server:
Stop the NIS server.
# svcadm disable network/nis/server:default
Remove the lock files.
# rm /var/run/yp_maplock /var/run/yp_mapupdate
Restart the NIS server.
# svcadm enable network/nis/server:default
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. For more information about address configuration for N2L, see Prerequisites for the NIS-to-LDAP Transition.
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 the LDAP client library.
The LDAP client library 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. Because the LDAP server address would be listed in another place, changing the address of either the LDAP server or the N2L server would require slightly more effort.