On Wed, May 11, 2016 at 11:42:40AM +0200, Jakub Hrozek wrote:
> On Wed, May 11, 2016 at 10:24:10AM +0200, Pavel Březina wrote:
> > On 05/10/2016 04:00 PM, Jakub Hrozek wrote:
> > > On Thu, Apr 21, 2016 at 02:54:21PM +0200, Pavel Březina wrote:
> > > > We can fail in sasl_bind_send() with ERR_AUTH_FAILED for basically
> > > > unspecified reason but we do not failover to next server. This patch
> > > > should
> > > > fix it.
> > > >
> > > > As said on the meeting, I didn't reproduce it and I'm not sure if it
> > > > will
> > > > fix the customer issue unless they confirm it, but it seems to be a
> > > > valid
> > > > patch anyway.
> > >
> > > > From c9e3bf2726d9edba3cddc91c4ae98a87a5c1652a Mon Sep 17 00:00:00 2001
> > > > From: =?UTF-8?q?Pavel=20B=C5=99ezina?= <pbrez...@redhat.com>
> > > > Date: Wed, 6 Apr 2016 13:20:59 +0200
> > > > Subject: [PATCH 1/2] Inform about (un)successful connection
> > > >
> > > > ---
> > > > src/providers/ldap/sdap_async_connection.c | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/src/providers/ldap/sdap_async_connection.c
> > > > b/src/providers/ldap/sdap_async_connection.c
> > > > index
> > > > f9074afb0c1340c7c2a50d4df0021eee4ae0d076..435cb1bb6864b516d386fafa360d062f780b5d04
> > > > 100644
> > > > --- a/src/providers/ldap/sdap_async_connection.c
> > > > +++ b/src/providers/ldap/sdap_async_connection.c
> > > > @@ -2035,6 +2035,9 @@ int sdap_cli_connect_recv(struct tevent_req *req,
> > > > if (tevent_req_is_error(req, &tstate, &err)) {
> > > > /* mark the server as bad if connection failed */
> > > > if (state->srv) {
> > > > + DEBUG(SSSDBG_OP_FAILURE, "Unable to establish connection "
> > > > + "[%d]: %s\n", err, sss_strerror(err));
> > > > +
> > >
> > > In file included from /sssd/src/util/util.h:54:0,
> > > from
> > > /sssd/src/providers/ldap/sdap_async_connection.c:26:
> > > /sssd/src/providers/ldap/sdap_async_connection.c: In function
> > > 'sdap_cli_connect_recv':
> > > /sssd/src/providers/ldap/sdap_async_connection.c:2038:38: warning: format
> > > '%d' expects argument of type 'int', but argument 6 has type 'uint64_t
> > > {aka long unsigned int}' [-Wformat=]
> > > DEBUG(SSSDBG_OP_FAILURE, "Unable to establish connection "
> > > ^
> > > /sssd/src/util/debug.h:108:22: note: in definition of macro 'DEBUG'
> > > format, ##__VA_ARGS__); \
> >
> > Fixed.
> >
> > > ^
> > >
> > > > be_fo_set_port_status(state->be, state->service->name,
> > > > state->srv, PORT_NOT_WORKING);
> > > > } else {
> > > > @@ -2048,6 +2051,8 @@ int sdap_cli_connect_recv(struct tevent_req *req,
> > > > }
> > > > return EIO;
> > > > } else if (state->srv) {
> > > > + DEBUG(SSSDBG_TRACE_FUNC, "Connection established.\n");
> > > > +
> > > > be_fo_set_port_status(state->be, state->service->name,
> > > > state->srv, PORT_WORKING);
> > > > }
> > > > --
> > > > 2.1.0
> > > >
> > >
> > > > From 8d6f024ac77ddb8dc87d7fd693cfe5846f3a88d6 Mon Sep 17 00:00:00 2001
> > > > From: =?UTF-8?q?Pavel=20B=C5=99ezina?= <pbrez...@redhat.com>
> > > > Date: Wed, 6 Apr 2016 13:21:21 +0200
> > > > Subject: [PATCH 2/2] Failover to next server if authentication fails
> > >
> > > I was only able to test this patch 'synthetically', by setting ret to the
> > > ERR_AUTH_FAILED value. But then it seemed to do the right thing, so ACK.
> >
> > Here as well.
> >
>
> ACK.
>
> CI is still running. I filed
> https://fedorahosted.org/sssd/ticket/3010 to track this issue..
CI: http://sssd-ci.duckdns.org/logs/job/43/18/summary.html
master:
8eb4a1f773b6c2246b0a6c6e3c3b8ef4d79c9ca6
73dd89c3fb361dab43b4802510f4c64d282dbde1
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
