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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
