[SSSD] [PATCH] let ldap_chpass_uri failover work when using same hostname

Jakub Hrozek jhrozek at redhat.com
Sat Dec 15 10:26:20 UTC 2012


On Fri, Dec 14, 2012 at 07:02:00PM +0100, Pavel Březina wrote:
> On 12/11/2012 03:58 PM, Jakub Hrozek wrote:
> >On Tue, Dec 11, 2012 at 03:53:25PM +0100, Jakub Hrozek wrote:
> >>On Mon, Dec 10, 2012 at 12:35:29PM +0100, Pavel Březina wrote:
> >>>https://fedorahosted.org/sssd/ticket/1699
> >>
> >>> From 246cf7edc92ed2826cf8295787cfb4e78d28ffd4 Mon Sep 17 00:00:00 2001
> >>>From: =?UTF-8?q?Pavel=20B=C5=99ezina?= <pbrezina at redhat.com>
> >>>Date: Mon, 10 Dec 2012 12:23:25 +0100
> >>>Subject: [PATCH] let ldap_chpass_uri failover work when using same hostname
> >>>
> >>>https://fedorahosted.org/sssd/ticket/1699
> >>>
> >>>We want to continue with the next server on all errors, not only
> >>>on ETIMEDOUT.
> >>>
> >>
> >>I'm not quite sure, I think the intent was to only retry on
> >>network-related errors and fail right away with fatal errors like
> >>ENOMEM.
> >>
> >>>This particullar ticket was dealing with ECONNREFUSED.
> >>
> >>Can you check where the ECONNREFUSED error came from? Maybe we're just
> >>missing another special case for lret like the ones at the end of
> >>sdap_sys_connect_done().
> >>
> >>Also what about the same condition in auth_bind_user_done() ?
> >
> >One more question -- the QE have identified this problem as a regression
> >since 1.8.x The code you changed predates 1.8, I think...so while it
> >might be fixing the symptoms, it probably is not the place that
> >regressed.
> 
> I just tried it on 1.8 and the failover doesn't work there either.
> 
> As noticed by Jakub, the same issue was also in
> auth_bind_user_done(). I'm sending new patch that fixes both places.
> 

OK, the worst thing that can happen is longer timeouts if we actually
were relying on a different error code to set us offline. But I tested
the usual cases failover cases (hostname can't be resolved at all, no LDAP server
running on the hostname) and they worked fine.

Ack



More information about the sssd-devel mailing list