Univention Bugzilla – Bug 33292
libnss-ldap connection problems
Last modified: 2014-05-09 06:56:19 CEST
Seen at ticket #2013011421000766:
Sometimes the customer sees error messages in the auth.log at memberservers:
nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server Nov
6 16:17:40 servername ls: nss_ldap: failed to bind to LDAP server ldap://servername:389:
Can't contact LDAP server
This is repeated for every ldap server registered in ldap-srv record.
The only case in which this record is used is located at "ldap-nss.c" if the ldap config could not be parsed - we've tested that and there is no obvious explanation for that. The config is readable and okay.
With strace and wireshark I saw that the connections are only hitting one server - the first in the ldap config. I also saw that this system uses an ip adress from an external range (duplicated) - perhaps thats the point if sometimes the name resolution is done externally?
In wireshark you can see a tcp rst when this phenomenon starts. Afterwards even if auth.log sais that connection against all other ldap servers fails I cannot see connection tries in wireshark...perhaps wrong debugging.
After all systems from the srv record are "tried" everything works again like expected.
strace, logs and tcpdump can be obtained from otrs - not attaching them here due to customer related information.
At least there are connection attempts without answer against the other ldap servers from srv record - I missed them.
Relevant additional information:
1. The system is hidden behind routers/firewalls. The ldap servers which are tried next are not reachable. The first ldap server configured is reachable - when the phenomenon starts, the connection to this server gets an tcp rst
2. An external IP is used by the first ldapserver - should not affect the situation as nothing externally is reachable (customer information)
ucr set nssldap/nss_srv=false should fix it.
*** This bug has been marked as a duplicate of bug 30779 ***