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.

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.

bye,
Sumit
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to