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@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/