On Wed, 2016-11-09 at 13:08 +0100, Sumit Bose wrote: > On Tue, Nov 08, 2016 at 10:28:20AM +0100, Jakub Hrozek wrote: > > Hi, > > > > I would like to ask for opinions about: > > https://fedorahosted.org/sssd/ticket/3126 > > > > The basic idea is that the responder would choose what kind of optimization > > would the back end perform when saving the sysdb entries. Requests that > > just return information might choose to optimize very aggressively (using > > modifyTimestamp) and requests that actually authenticate or authorize the > > user might choose to not optimize at all to avoid issues like the ones we > > saw > > with virtual attributes that don't bump the modifyTimestamp attribute at > > all. > > > > On the responder side, this is quite easy, just send an additional flag > > during the responder request. It's the provider part I'm not so sure > > about, because there the optimizations are performed at the sysdb level. > > > > So far I can only think about extending sysdb_transaction_start() (or > > providing sysdb_opt_transaction_start and letting the old > > sysdb_transaction_start default to no optimization) which would > > internally keep track of the active transaction and the optimization we > > want to perform. Since only sssd_be is the cache writer and there is > > only one cache per domain. > > > > Additionally, we would have to keep the transaction optimization level > > around > > in some context until the request bubbles from the data provider handler to > > actually saving the transaction. I don't I hope this won't be too messy, but > > since the requests are asynchronous, so far I don't see any way around > > it. The only thing that might be less messy in the long term is to provide > > a bit more generic structure ("request status") that would so far only > > include the optimization level and later might be extended to include > > e.g. intermediate data. But on the other hand, I'm not sure I have > > thought about passing the data between requests hard enough to design > > this properly. Should I? > > > > Any other opinions? Thoughts? > > I'm not sure if this wouldn't confuse users. If I understood the > proposal correctly the typical nss calls like getpwnam(), getgrnam() etc > will use the optimized requests with modifyTimestamp checks. If there is > a server which does not change modifyTimestamp on updates changes in > e.g. the user's shell or in the list of group-members will not be > visible even after calling 'sss_cache -E' because modifyTimestamp didn't > change on the server. But typically a user does not log in again to > check for such changes but just calls e.g. 'getent group changed_group' > again and again waiting for changes. > > I think if there are really such servers out there which do not update > modifyTimestamp it should be just possible to switch of the time-stamp > cache generally in this case (I wonder if this is already possible by > setting ldap_{user|group|netgroup}_modify_timestamp to a non-existing > attribute?). In this case the number of cache updates can be reduced by > increasing the cache timeout because during authenticating and > authorization fresh data is requested from the backend anyways.
There are cases where things like CoS are used that can change an attribute value (even dynamically) but do not alter the modifyTimestamp. In general operational attributes can behave that way. > I think the time would be better spend e.g. on > https://fedorahosted.org/sssd/ticket/3211 "Refactor the > sdap_async_groups.c module" and make sure all needed data is read from > LDAP (multiple LDAP connections might be involved here) first and > written to the cache in a single transaction. The problem is deciding when to forcibly reload data we already have in the cache, regardless of cache status. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
