On Wed, Jul 27, 2016 at 02:55:37PM +0200, thierry bordaz wrote:
On 07/27/2016 01:56 PM, Jakub Hrozek wrote:
> On Wed, Jul 27, 2016 at 01:03:59PM +0200, Jakub Hrozek wrote:
> > On Wed, Jul 27, 2016 at 12:22:46PM +0200, Lukas Slebodnik wrote:
> > > On (27/07/16 12:08), Jakub Hrozek wrote:
> > > > On Wed, Jul 27, 2016 at 12:02:24PM +0200, Jakub Hrozek wrote:
> > > > > On Wed, Jul 27, 2016 at 11:54:16AM +0200, Lukas Slebodnik
wrote:
> > > > > > ehlo,
> > > > > >
> > > > > > attached patch fixes acces denied after activating user in
389ds.
> > > > > > Jakub had some comments/ideas in ticket but I think
it's better to discuss
> > > > > > about virtual attributes and timestamp cache on mailing
list.
> > > > > Yes, so the comment I have is that while this works, it might
break some
> > > > > strange LDAP servers.
> > > > >
> > > > > We use modifyTimestamp as a 'positive' indicator that
the entry has not
> > > > > changed -- if the modifyTimestamp didn't change, we consider
the cached
> > > > > entry the same as what is on the server and only bump the
timestamp
> > > > > cache. If the timestamp is different, we do a deep-comparison of
cached
> > > > > attribute values with what is on the LDAP server and write the
sysdb
> > > > > cache entry only if the attributes differ.
> > > > >
> > > > > I was wondering if we can use the modifyTimestamp at all, then,
because
> > > > > even if it's the same, we might want to check the attributes
to see if
> > > > > some of the values are different because some of the attributes
might be
> > > > > this operational/virtual attribute..
> > > > Sorry, sent too soon.
> > > >
> > > > I think the questions are -- 1) can we enumerate the virtual
attributes?
> > > That might be a question for 389-ds developers.
> > > But it's very likely it will be different on other LDAP servers.
> > >
> > > > 2) Would different LDAP servers have different virtual attributes.
> > > >
> > > > For 2) maybe a possible solution might be to set a non-existing
> > > > modifyTimestamp attribute value, but I would consider that only a
> > > > kludge, we shouldn't break existing setups..
> > > I am not satisfied with this POC solution either.
> > >
> > > So should we remove usage of modifyTimestamp for detecting changes?
> > I would prefer to ask the DS developers before removing it completely.
> >
> > At least for large groups it might take a long time to compare all attribute
> > values and IIRC we don't depend on any virtual attributes for groups.
Maybe
> > we could parametrize that part of the code and enable the fast way with
> > modifyTimestamps for 'known' server types, that is for setups with AD
and
> > IPA providers.
> >
> > For users, there is typically not as many attributes so we should be
> > fine deep-comparing all attributes.
> I'm adding Thierry (so please reply-to-all to keep him in the thread).
>
> Thierry, in the latest sssd version we tried to add a performance
> improvement related to how we store SSSD entries in the cache. The short
> version is that we store the modifyTimestamp attribute in the cache and
> when we fetch an entry, we compare the entry modifyTimestamp with what
> is on the server. When the two are the same, we say that the entry did
> not change and don't update the cache.
>
> This works fine for most attributes, but not for attributes like
> nsAccountLock which do not change modifyTimestamp when they are
> modified. So when an entry was already cached but then nsAccountLock
> changed, we treated the entry as the same and never read the new
> nsAccountLock value.
>
> To fix this, I think we have several options:
> 1) special-case the nsAccountLock. This seems a bit dangerous,
> because I'm not sure we can say that some other attribute we are
> interested in behaves the same as nsAccountLock.
> 2) drop the modifyTimestamp optimization completely. Then we fall
> back to comparing the attribute values, which might work, but for
> huge objects like groups with thousands of members, this might be
> too expensive.
> 3) only use the modifyTimestamp optimization for cases where we know
> we don't read any virtual attributes.
>
> And my question is -- can we, in general, know if the modifyTimestamp
> way of detecting changes is realiable for all LDAP servers? Or do you
> think it should only be used for cases where we know we are not
> interested in any virtual attributes (that would mostly be storing
> groups from servers where we know exactly what is on the server side,
> like IPA or AD).
Hello,
Relying on modifytimestamp looks a good idea. Any MOD/MODRDN will update it,
except I think it is unchanged when updating some password policy
attributes.
Regarding virtual attribute, the only one I know in IPA is nsaccountlock.
nsaccountlock is an operational attribute (you need to request it to see it)
and is also a virtual attribute BUT only for 'staged' and 'deleted'
users.
It is a stored attribute for regular users and we should update
modifytimestamp when it is set.
thanks
thierry
OK, in that case it seems like we can special-case it. But do you know
about any other attributes in any other LDAP servers?