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