On 03/14/2012 06:27 PM, Simo Sorce wrote:
On Wed, 2012-03-14 at 18:00 -0400, Stephen Gallagher wrote:
> On Wed, 2012-03-14 at 16:36 -0400, Simo Sorce wrote:
>> On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
>>> Ok, I see the logic now ( although I'm not completely
>>> convinced from a practical point of view to be honnest :
>>> a user name could be defined somewhere else, in a
>>> referal ldap for example. In that case, should it be an
>>> overall group consistency problem if a memberuid was
>>> uknown because a referal server is not accessible ? ).
>>>
>> memberuid cannot be resolved through a referral as it cannot contain a
>> DN :-)
>> however if you use the "member" attribute and rfc2307bis you could end
>> up chasing a referral that is temporarily broken. In that case you'd
>> have a resolution issue, not an "unknown" member.
>>
>> I am not sure how sssd would handle a referral problem in this case,
>> hopefully it would recognize the problem and just use a previously
>> cached value. If it is the first lookup it would have no choice but to
>> pretend the member did not exist until the next lookup.
> Right now we can't handle this safely. It's a limitation of using the
> internal openldap referral chasing. As far as we see as a consumer, the
> entry doesn't exist, and we have to treat it on the client as LDAP
> definitively asserting that the user does not exist, and therefore must
> delete it from the local cache.
>
> I'm trying to work out ways to resolve this when we rewrite the referral
> processing with our own implementation.
Thanks,
should we open a ticket specifically about this issue so we A) do not
forget and B) can add a test case ?
Simo.
https://fedorahosted.org/sssd/ticket/860#comment:8
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/