Bug 692817 - nslcd does not fallback to additional LDAP servers
Summary: nslcd does not fallback to additional LDAP servers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss-pam-ldapd
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 627601
TreeView+ depends on / blocked
 
Reported: 2011-04-01 09:55 UTC by J.H.M. Dassen (Ray)
Modified: 2019-04-16 13:59 UTC (History)
7 users (show)

Fixed In Version: nss-pam-ldapd-0.7.5-6.el6
Doc Type: Bug Fix
Doc Text:
When nslcd was configured to use multiple LDAP servers, it failed to fall back to a different server in case the primary server could not be reached. This was due to nslcd trying to keep the first connection alive even when the connection was dropped. With this update, nslcd correctly falls back to a different server after loosing connection with the current one.
Clone Of:
Environment:
Last Closed: 2011-05-19 14:30:05 UTC
Target Upstream Version:


Attachments (Terms of Use)
Proposed patch (3.32 KB, patch)
2011-04-01 10:00 UTC, J.H.M. Dassen (Ray)
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Debian BTS 596983 0 None None None Never
Red Hat Knowledge Base (Legacy) 54027 0 None None None Never
Red Hat Product Errata RHBA-2011:0796 0 normal SHIPPED_LIVE nss-pam-ldapd bug fix update 2011-05-18 18:08:08 UTC

Description J.H.M. Dassen (Ray) 2011-04-01 09:55:02 UTC
Description of problem:
Customer is being hit by this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596983

(author of nss-pam-ldapd fixed in in 0.7.10, RHEL6 uses 0.7.5)

As they are using LDAP to distribute user information to their computing
nodes, this bug is quite critical for them: if the first LDAP server becomes
unreachable they loose all LDAP access from client. (The only workaround
being to restart nslcd on the system - it will fallback at the bind time).

Version-Release number of selected component (if applicable):
nss-pam-ldapd-0.7.5-3.el6

How reproducible:
100%

Steps to Reproduce:
1. Configure nslcd to use more than one LDAP server
2. Use iptables to drop connections to the first configured LDAP server
  
Actual results:
nslcd continues to attempt to connect to the first configured LDAP server.

Expected results:
nslcd falls over to using a different LDAP server than the first configured
one.

Comment 1 J.H.M. Dassen (Ray) 2011-04-01 10:00:28 UTC
Created attachment 489343 [details]
Proposed patch

Relevant bit from diff between the upstream changelogs for 0.7.9 and 0.7.10:
+       * [r1211] ., nslcd/myldap.c: handle errors from ldap_result()
+         better and disconnect (and reconnect) in more cases (r1207 and
+         r1208 from trunk)

As such, the proposed patch is the combination of
<http://arthurdejong.org/viewvc/nss-pam-ldapd?view=revision&revision=1207> and
<http://arthurdejong.org/viewvc/nss-pam-ldapd?view=revision&revision=1208>.

Comment 2 Dmitri Pal 2011-04-01 14:12:34 UTC
Have they looked at SSSD?

Comment 9 Greg Cockburn 2011-04-12 22:59:03 UTC
We are in the same boat.

What is the timeline to have this fix available?

Comment 17 Martin Prpič 2011-04-28 08:25:50 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When nslcd was configured to use multiple LDAP servers, it failed to fall back to a different server in case the primary server could not be reached. This was due to nslcd trying to keep the first connection alive even when the connection was dropped. With this update, nslcd correctly falls back to a different server after loosing connection with the current one.

Comment 18 errata-xmlrpc 2011-05-19 14:30:05 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0796.html


Note You need to log in before you can comment on or make changes to this bug.