Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Testing and Troubleshooting the NIS+ Gateway
Before uploading all your NIS+ data to the LDAP server, it is wise to test out the mapping you established. This should be done before you rename the configuration file to NIS+LDAPmapping and restart rpc.nisd, which activates the NIS+ Gateway.
The following assumes you have a group in your NIS+ database called gem. The nisldapmaptest command is run in the verbose mode to give you a clearer idea of what the command is doing.
# nisldapmaptest -v -r -m nls -t group.org_dir name=gem createQuery: NIS+ query: [name=gem]group.org_dir.example.com. mapToLDAP: group.org_dir.example.com.: 1 * 1 potential updates mapToLDAP: group.org_dir.example.com.: 1 update requested controlSupported: 127.0.0.1: 1.2.840.113556.1.4.319: disabled controlSupported: 127.0.0.1: 2.16.840.1.113730.3.4.9: enabled mapToLDAP: group.org_dir.example.com.: 1 update performed
As you can observe from the last line the update was performed. To verify this, you can run the ldapsearch command as shown in the following example.
# ldapsearch -b dc=example,dc=com cn=gem cn=gem,ou=Group,dc=example,dc=com cn=gem gidNumber=2292 objectClass=posixGroup objectClass=top
To remove test entries:
# ldapsearch -b dc=example,dc=com cn=gem dn cn=gem,ou=Group,dc=example,dc=com # ldapdelete -D "cn=directory manager"-w mypass cn=gem,ou=Group,dc=example,dc=com
Once the NIS+ Gateway is activated, you can test it by creating an entry in LDAP and see if it appears in NIS+.
# vi /tmp/hosts.ldif dn: cn=test1+ipHostNumber=10.10.9.12,ou=Hosts,dc=example,dc=com cn: test1 ipHostNumber: 10.10.9.12 objectClass: ipHost objectClass: device objectClass: top # ldapmodify -a -D "cn=directory manager" -f /tmp/hosts.ldif Bind Password: adding new entry cn=test1+ipHostNumber=10.10.9.12,
After a few seconds, you should be able to see the new entry from NIS+ as shown in this example.
# niscat hosts.org_dir | grep test1 test1 test1 10.10.9.12
Troubleshooting Tips
Most errors are the result of misconfigured rpc.nisd or NIS+LDAPmapping files. If you encounter problems, follow these steps:
Check for syslog messages in /var/adm/messages that are generated from rpc.nisd.
Restart rpc.nisd with the verbose (-v) option for more detailed error messages.
Run the nisldapmaptest(1M) utility for entries that fail, observing error messages.
Run snoop if the directory server is on a separate system. See Appendix C, "Using snoop with LDAP."
Common Problems
The directory server is missing necessary schema definitions. This will occur if you fail to comment out the directory, group, and table entries in NIS+LDAPmapping(4) file and do not add the nisObjectContainer object class and associated attributes.
The naming service containers, for example ou=hosts, have not been created. To avoid this, run the idsconfig command before uploading NIS+ data.
The proxy user account specified does not have sufficient write permissions. For test purposes you can choose cn=directory manager to avoid this issue.
The NIS+ tables being imported have duplicate entries. While this is allowed in NIS+, you will get an LDAP object class violation error when they are imported because it will be interpreted as a multi-value attribute.