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

Lukas Slebodnik lslebodn at redhat.com
Fri Sep 4 14:12:44 UTC 2015


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.

sssd-1.13.0 works fine; there is just a problem with sssd master

LS


More information about the sssd-devel mailing list