[SSSD] I think #2637 is out of scope of 1.13

Jakub Hrozek jhrozek at redhat.com
Fri Sep 4 14:17:54 UTC 2015


On Fri, Sep 04, 2015 at 04:12:44PM +0200, Lukas Slebodnik wrote:
> On (04/09/15 14:38), Jakub Hrozek wrote:
> >On Wed, Sep 02, 2015 at 12:42:17PM +0200, Jakub Hrozek wrote:
> >> On Wed, Sep 02, 2015 at 10:11:46AM +0200, Sumit Bose wrote:
> >> > On Tue, Sep 01, 2015 at 08:19:06PM +0200, Jakub Hrozek wrote:
> >> > > Hi,
> >> > > 
> >> > > ssia...
> >> > > 
> >> > > I was working on implementing https://fedorahosted.org/sssd/ticket/2637
> >> > > and while for most occurences it was quite easy to set domain status
> >> > > instead of back end status, I hit the sdap_id_op module..
> >> > > 
> >> > > The sdap_id_op operation sets the offline status directly, in a bit of
> >> > > a hackish way by accessing the be_ctx through sdap_id_ctx. It's not
> >> > > trivial to change the request to operate on domains, except changing
> >> > > sdap_id_op_create() to also accept domain as a parameter..but we already
> >> > > have 37 calls to sdap_id_op_create().
> >> > > 
> >> > > A better way would be to change the whole sdap_id_op request to return an
> >> > > error code and don't touch the backend status, but that's even more work
> >> > > -- we need to do that and it's something we need to do in the next weeks
> >> > > anyway, I just think it's not something that should land in 1.13..
> >> > > 
> >> > > Thoughts? Should I go ahead and change sdap_id_op_create() to accept
> >> > > domain in 1.13 or do refactor the sdap_id_op for 1.14? I would
> >> > > personally prefer the latter..
> >> > 
> >> > I agree that sdap_id_op should not change the status on its own and that
> >> > it should be fixed with the refactoring planned for 1.14.
> >> > 
> >> > Nevertheless I wonder if you already have a patch which covers all the
> >> > other cases if it wouldn't be an improvement to the current state to add
> >> > it?
> >> > 
> >> > I would assume that most issue are caused by error during the DNS
> >> > lookup, initial connect or authentication which iirc are not handled by
> >> > sdap_id_op.
> >> 
> >> The LDAP connection and the failover during the connection is handled by
> >> sdap_id_op. That's the crux of the problem I didn't realize when doing
> >> the initial design (frankly I didn't think the sdap operation was in the
> >> business of changing failover status and offline status for the backend..)
> >> 
> >> > I would assume that error during sdap_id_op, e.g. a server
> >> > shutdown, are more rare and it would be acceptable to let those errors
> >> > switch the whole backend to offline until the refactoring is done.
> >> 
> >> Hmm perhaps you're right that we can try solve at least the use-cases
> >> while we have the code in mind. I think we mostly care about:
> >>     - don't bring the whole AD backend offline if there are connection
> >>       problems with discovering subdomains when AD client is connected
> >>       to a subdomain
> >>     - don't bring the whole IPA backend offline if there are connection
> >>       problems with AD server in server mode
> >>     - don't bring the while IPA backend offline if there are connection
> >>       problems with AD server with IPA client
> >> 
> >> I think these are solvable without major hacks. I'll see about fixing
> >> these use-cases.
> >> 
> >> The rest needs to be fixed when I work on the LDAP code and Pavel
> >> Brezina works on the failover changes.
> >
> >The patches are on list now. Given the changes, I no longer think the
> >patches are out of scope for 1.13.x -- downstreams would really benefit
> >from them -- but I don't think we should block 1.13.1 over the patches
> >either, we should rather test them out well.
> >
> >FreeIPA would like us to release 1.13.1 on Monday, so I'll concentrate
> >on reviewing your patch for #2692 and respinning the patch for #2723 so
> >that we can do the release on Mon.
> I would say more realistic is in the middle of next week.
> 
> tbabej found some issues with authenticating a newly created user
> to FreeIPA 4.2.

Do we have a ticket already?

> 
> sssd-1.13.0 works fine; there is just a problem with sssd master
> 
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


More information about the sssd-devel mailing list