<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 09/12/2011 10:39 AM, Stephen Gallagher wrote:
    <blockquote
      cite="mid:1315838356.2367.14.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">On Mon, 2011-09-12 at 10:07 -0400, Dmitri Pal wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 09/12/2011 08:41 AM, Stephen Gallagher wrote: 
</pre>
      </blockquote>
      <pre wrap="">...
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">=== 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.
</pre>
        </blockquote>
        <pre wrap="">
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. 

</pre>
      </blockquote>
      <pre wrap="">
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).

</pre>
    </blockquote>
    <br>
    Ok<br>
    <br>
    <blockquote
      cite="mid:1315838356.2367.14.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">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.
</pre>
    </blockquote>
    <br>
    Report yes, update no, i.e. first one wins.<br>
    <blockquote
      cite="mid:1315838356.2367.14.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">== 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.
</pre>
        </blockquote>
        <pre wrap="">
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

</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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...]

</pre>
        </blockquote>
        <pre wrap="">
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

</pre>
      </blockquote>
      <pre wrap="">
I assume you mean [domain/DOMAINNAME/ldap_search/sectionN]

</pre>
    </blockquote>
    <br>
    Yes, this is what I meant, just did not remember the exact syntax
    from top of my head.<br>
    <br>
    <blockquote
      cite="mid:1315838356.2367.14.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">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.

</pre>
      <blockquote type="cite">
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
This is probably a good plan. Thanks for the suggestion!

</pre>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/mailman/listinfo/sssd-devel">https://fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>