[SSSD] DESIGN: Multiple LDAP search bases

Dmitri Pal dpal at redhat.com
Mon Sep 12 14:51:45 UTC 2011


On 09/12/2011 10:39 AM, Stephen Gallagher wrote:
> On Mon, 2011-09-12 at 10:07 -0400, Dmitri Pal wrote:
>> On 09/12/2011 08:41 AM, Stephen Gallagher wrote: 
> ...
>>> === Enumeration ===
>>> For enumeration, we will need to iterate through ALL search bases to
>>> retrieve users, groups, etc. For each search base, we need to examine
>>> each entry retrieved and compare it against the entries received from
>>> earlier search bases. If there are conflicts, we will discard the
>>> conflicting value from the later search base. (Therefore the entry in
>>> the earlier search bases will always win.
>> I am not sure we should pre-match anything and sort duplicates.
>> We should put fetched data into the cache right away as a result of
>> one search and then do the second search following the same logic and
>> so on.
>> If we encounter a duplicate i.e. a full duplicate of a user we just
>> updated (same user) we should just skip it. If we find a collision
>> meaning we found a user with same id but different name or vice verse
>> (same with group) we should report and skip. This is a
>> misconfiguration and admin should sort his domain out. 
>>
> Unless I'm missing something, that's the same behavior I'm describing,
> except less efficient. We always hold off on saving data to the cache
> until the very end (to avoid both inconsistent cache state and excess
> writes to the disk).
>

Ok

> The only difference between your approach and mine is that you would do
> an extra check to make sure they were the same and would just not report
> it if so. In my version, I'd always report duplicate names, even if they
> ultimately turn out to have the same data.

Report yes, update no, i.e. first one wins.
> You do make a good point that I forgot to put in my initial analysis
> that we probably need to ensure that there are no GID conflicts either.
> That means a second lookup table.
>
>>> == Implementation ==
>>> We will extend the ldap_*_search_base options to support behavior
>>> similar to that of nss_base_passwd and nss_base_group from nss-ldapd.
>> Is it a literal * or it is a placeholder?
>> In either case I do not like an approach. IMO the key names should be
>> predefined.
>>
>> May be use:
>>
>> ldap_search_base_multi = triplet, triplet, triplet
>>
> We cannot do this, because search bases have commas in them. It wouldn't
> be possible to parse them safely. However, your idea below might work.
>
>>> The standard search base (ldap_search_base will be left alone as a
>>> single value with scope "subtree".
>>>
>>> The new ldap_*_search_base options will include a new delimiter, '?'. If
>>> this is present, we will divide the string up into triples as follows:
>>>
>>> search_base?scope?filter[?search_base?scope?filter...]
>>>
>> Alternatively you can add sub sections to the ldap provider (we alread
>> yuse this approach with domains and providers, I do not see why we
>> should deviate in this case too)
>>
>> ldap_search_base_multi = section1, section2, section3
>>
>> [.../default/ldap_search/section1]
>> ldap_search_base = x
>> ldap_search_filter = y
>> ldap_search_scope = z
>>
>> [.../default/ldap_search/section2]
>> ldap_search_base = x
>> ldap_search_filter = y
>> ldap_search_scope = z
>>
> I assume you mean [domain/DOMAINNAME/ldap_search/sectionN]
>

Yes, this is what I meant, just did not remember the exact syntax from
top of my head.

> If so, this might be a decent approach. It might be a little tricky to
> add this to the SSSDConfig API, but the resulting interface will
> probably be cleaner, so I'll think about this carefully.
>
>> It will be easier to parse, more structured and readable and with such
>> organization you can extend the current search filter leaving it (if
>> specified) to be the first search filter to use.
>> In addition if the grammar validation is ever implemented we would be
>> able to apply the rules to such config. If we go with the original
>> proposal the ini validation would not be usable.
> This is probably a good plan. Thanks for the suggestion!
>
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110912/8238557d/attachment.html>


More information about the sssd-devel mailing list