On Tue, Oct 19, 2021 at 6:04 AM THomas HUMMEL <thomas.hummel(a)pasteur.fr> wrote:
Hello,
any hints ?
Also, why is the default entry_cache_timeout so high (1.5 hour if I
understand correctly) ?
Many people use SSSD for its caching purpose, in environments with a
high volume of clients it can help a lot to avoid sending too many
LDAP searches and authentication attempts to backend servers. Feel
free to adjust this timeout as you prefer for your environment. Note
that with the default value (50), entries may be requested in the
background at half of the entry_cache_timeout due to
entry_cache_nowait_percentage.
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:
I also am unable to reproduce this issue, I tested by setting
entry_cache_timeout = 0 and prefixing commands with
SSS_NSS_USE_MEMCACHE=no
>
> 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
To rule out any caching logic, you may try
disabling the caching
entirely (on-disk and memcache) to help with troubleshooting this
issue.
>
> 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 ?
Make sure you are checking the timestamps in the
timestamps_ad.vm.ldb file
>
> 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 ?
I
don't believe so.
>
> 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...
>
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure