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 _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
