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
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. See the LDAP error descriptions in 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 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. Fix 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
Description: 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, the LDAP entry approaches a complete state.
The server times out.
Cause: When the N2L server refreshes a map, the result might be a single access of a large LDAP directory. 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.
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.
Solution: Type the following commands on the N2L server to describe actions:
# svcadm disable network/nis/server:default # rm /var/run/yp_maplock /var/run/yp_mapupdate # 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. 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. 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.