Hello,
any hints ?
Also, why is the default entry_cache_timeout so high (1.5 hour if I
understand correctly) ?
Thanks for your help
--
Thomas HUMMEL
On 10/13/21 16:00, Thomas HUMMEL wrote:
> Hello,
>
> sssd-2.3.0 on RHEL/CentOS 8.3, I'm trying to figure out how refreshing a
> user cache entry could impact (or not) a group entry this user is or has
> been a member of in the backend
>
> I'm using sssd-2.3.0 on RHEL/CentOS 8.3 with
>
> auth_provider = ldap
> ldap_schema = AD
> access_provider = ldap
> id_provider = ldap
>
> authselect provides the following setup of nsswitch:
>
> passwd: sss files systemd
> group: sss files systemd
>
> Initial experience on *some* hosts using the same sssd config:
>
> a user <user> which has been for some time (greater than any sssd
> timeout) removed from group <group> in the AD backend still appeared as
> a member when running getent group <group>
>
> "refreshing" this user with getent passwd <user> would fix the issue
>
> I don't quite get the reasoning behind this behavior.
> Does the link between the 2 actions lies in the ghost/unghost mechanism ?
>
> I did not manage to reproduce it. The tests I made on another similar
> host raised some more questions though:
>
> a) I was able to verify the expected behavior of
> entry_cache_group_timeout (or entry_cache_timeout for that matter):
> after 1h30m getent group <group> would get the group entry from the
> backend. Before that result were fed by the cache and could not be
> consistent with the backend
>
> b) I'm having trouble understanding how sss_cache -u or -g works as,
> using ldbsearch -H <cache_ldb_file> I can see the dataExpireTimestamp
> set to 1 but after what I thought would be a refresh (getent passwd or
> group), I still see this value : is this because sssd RAM cache is not
> sync'ed ?
>
> Finally, do you confirm that the setting of ldap_purge_cache_timeout
> should not change how the membership of a user in a group is return ?
>
> Thanks for you help
>
> --
> Thomas HUMMEL
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
>
https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/project/...
> List Guidelines:
>
https://urldefense.com/v3/__https://fedoraproject.org/wiki/Mailing_list_g...
> List Archives:
>
https://urldefense.com/v3/__https://lists.fedorahosted.org/archives/list/...
> Do not reply to spam on the list, report it:
>
https://urldefense.com/v3/__https://pagure.io/fedora-infrastructure__;!!J...
>