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