On Mon, 2012-02-20 at 16:37 +0000, Pascal.Schneider(a)swisslife.ch wrote:
Hi Stephen
...
So, the bad news:
No we just updated to sssd-1.5.1-44 on RHEL 5 and 1.5.1-66 on RHEL 6.
When we now update 1 of the AD Servers and ask immediately for the
change, we get for a long time the wrong answer (not updated yet). I
think the default behaviour is 5400 min.
How can I force sssd to catch the info faster!
We tried to manage it over:
[nss]
entry_cache_timeout = 30
But I had no success!
Extra infos: we use 4 AD Server 2008R2 with direct connection over
sssd (no samba, no winbind)
When we cache the data, we set the expiration time as a literal value,
not an offset from the lastUpdate time. (We're considering changing this
in an upcoming release, possibly 1.9 upstream). There were good reasons
for this originally, but I think they've slowly become irrelevant.
So once an entry is cached, its expiration is already set. Changing the
value in sssd.conf only affects new entries being saved. So you'll still
need to wait for the original entry to expire before it gets updated
with a newer timeout value.
In upstream SSSD 1.6.0 we added a new command-line utility to be able to
forcibly expire specific (or all) entries. But that's coming in RHEL
6.3.
One trick you could do would be to set
entry_cache_nowait_percentage = 1
This option is designed to avoid cache-miss waiting by telling the SSSD
to update the user entry in the background when a request comes in that
is past a percentage of the expiration time. In SSSD 1.8.0 we enabled
this by default at 50%. If you set the option above, what will happen is
that once the entry is past 1% (aka 54 seconds), we will look it up in
the background. So this will get your entries up-to-date quickly, then
you can turn this back off (or set it to something more reasonable, like
50%).
Also, in the future, please direct queries like this at
sssd-devel(a)lists.fedorahosted.org so that other people can gain the
benefits of the answers.