Bug 33292 - libnss-ldap connection problems
libnss-ldap connection problems
Status: CLOSED DUPLICATE of bug 30779
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 3.1
Other Linux
: P5 normal (vote)
: UCS 3.2-0-errata
Assigned To: Stefan Gohmann
Felix Botner
:
Depends on:
Blocks: 34787
  Show dependency treegraph
 
Reported: 2013-11-12 12:05 CET by Tim Petersen
Modified: 2014-05-09 06:56 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Petersen univentionstaff 2013-11-12 12:05:55 CET
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.
Comment 1 Tim Petersen univentionstaff 2013-11-13 14:56:00 CET
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)
Comment 2 Stefan Gohmann univentionstaff 2013-12-19 06:37:58 CET
ucr set nssldap/nss_srv=false should fix it.

*** This bug has been marked as a duplicate of bug 30779 ***
Comment 3 Felix Botner univentionstaff 2014-01-08 14:16:56 CET
OK
Comment 4 Moritz Muehlenhoff univentionstaff 2014-02-05 10:00:45 CET
Duplicate, closing