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?
LS