On Wed, Dec 01, 2010 at 10:54:05AM -0500, Simo Sorce wrote:
On Wed, 1 Dec 2010 12:38:52 +0100
Sumit Bose <sbose(a)redhat.com> wrote:
> On Fri, Nov 26, 2010 at 06:49:33PM -0500, Simo Sorce wrote:
> >
> > This set of patches allows SSSD to use the more reliable entryUSN
> > against FreeIPA (and USNchanged against AD) when performing
> > enumerations.
> >
> > If entryUSN(USNchanged) is not detected as available by checking
> > rootdse for lastUSN(highestCommittedUSN) then we fall back to use
> > modifyTimestamp which is fine in non-multimaster setups.
> >
> > This set comprises 4 patches.
> >
> > 1. pass sdap_id_ctx to sdap_id_op functions (needed later).
> >
> > 2. cleanup unused vars and functions about rootdse to avoid
> > confusion
> >
> > 3. add connection checks to test if USNs are available.
> >
> > 4. Change the code around to use the best USN method available and
> > fallback to the previous modifyTimestamp if not.
> >
> > These pacthes have been briefly tested against a FreeIPA server with
> > the entryUSN configuration patch (still unpushed upstream) and all
> > seem to working fine.
>
> I agree with the patches, but I would like to ask to rename
> max_user_value and max_group_value to something like max_user_usn and
> max_group_usn, because I find the original names very missleading.
I use value because when USNs are not available that thing contains the
max modifyTimestamp, so I wanted to make sure people think about it
when they see it.
ok, what about max_(user|group)_ref_value ? Maybe someone else has a
good idea, too? It is just that my first, second and third toughts when
reading max_user_value were not related to the USN or modifyTimestamps,
but to UIDs or usernames. But I agree, that max_group_usn, might be to
restricted here.
> Maybe it is easier for the LDAP server to optimize a search filter
> with (!(%s<=%s)) instead of (%s>=%s)(!(%s=%s)) ?
I haven't changed the original filters, I can create an additional
patch for this if you like.
I leave this up to you. This was more a question than a suggestion to
change it. I'm not sure how LDAP servers try to optimize this kind of
queries and just thought that a shorter condition might be easier to
optimize. On the other hand '(%s>=%s)(!(%s=%s))' might be easier to
understand for the human eye.
> OpenLDAP users might be happy if sssd would be able to autodetect
> OpenLDAP and use entryCSN. Do you think check for the OpenLDAProotDSE
> objectclass would be sufficient here?
Yes, give me the details and I can add that easily.
I think the only detail is the OpenLDAProotDSE objectclass. I haven't
found anything else in the OpenLDAP rootDSE which can help here.
bye,
Sumit
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel