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
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/project/cod... List Guidelines: https://urldefense.com/v3/__https://fedoraproject.org/wiki/Mailing_list_guid... List Archives: https://urldefense.com/v3/__https://lists.fedorahosted.org/archives/list/sss... Do not reply to spam on the list, report it: https://urldefense.com/v3/__https://pagure.io/fedora-infrastructure__;!!JFdN...
On Tue, Oct 19, 2021 at 6:04 AM THomas HUMMEL thomas.hummel@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/project/cod... List Guidelines: https://urldefense.com/v3/__https://fedoraproject.org/wiki/Mailing_list_guid... List Archives: https://urldefense.com/v3/__https://lists.fedorahosted.org/archives/list/sss... Do not reply to spam on the list, report it: https://urldefense.com/v3/__https://pagure.io/fedora-infrastructure__;!!JFdN...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 19/10/2021 22:20, Justin Stephenson wrote:
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
Hello, thanks for your answer. I'll try again with the hints you gave me.
Thanks again
-- Thomas HUMMEL
sssd-users@lists.fedorahosted.org