While dealing with other related issue, today I was thinking about our caching strategy on the clients.
We have 2 options in sssd today: - we can fully enumerate regularly using an enumeration task - we update the information at log-in time. the first option may be very expensive in big domains, but in the second case we have some problems in deciding how to deal with refreshing and more importantly deleting stale data. One option we put on the table is to always delete data when it "expires" (and we are still online) and let the client application trigger a refresh only if they need data. This seems a good solution under most points of view as it will guarantee we keep around data that is used and introduces only a small latency and only when necessary if we need to refresh data that is explicitly requested. It leaves out 2 cases though: - application performs a generic enumeration and does not request explicitly for a user or a group. - data expires and is removed while online, then clients goes offline and needs the data. The second scenario is what convinced me we cannot just delete expired data. So how do we know what data to delete and what to keep ? Well we have one more piece of data that we can use to decide when to throw away data and when not. Each user have 2 important bits of information we can use: Last login date and the memberof attribute The Last login date can be used to decide when to delete a user account from the cache. This is not the same as the expiration date, the expiration date is used to decide when it is time to refresh the data even if we have it. So if the user data is expired, and the last login date is X days in the past, we can decide to remove the user from the cache without having to check the central authority (the LDAP server). The memberof attribute instead is fundamental to do the same operation for groups. Any group that is referenced by a user entry cannot be deleted or it would be missing is a cached login is performed while offline. But if a group is expired and it is not referenced by any user then it can be deleted. The memberof attribute for users is recalculated at each online login so that will assure that the groups that falls off of it are really not intersting anymore the client system. Please think about this and let me know if you see any problem with this proposal. Also please let me know if someone feels like volunteering for implementing it. It should be fairly simple to implement this logic and should completely replace the current cleanup task logic. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
