I have an AD setup where users can be a member of perhaps 130 groups. When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less that one second. However, after a length of time the cache seems to be invalidated and the information is fetched again from the server, taking 20 seconds again. The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group information is refreshed in the background. So a user running the groups command would always see freshly cached values?
Clearly I am not understanding something here.
On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
I have an AD setup where users can be a member of perhaps 130 groups. When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less that one second. However, after a length of time the cache seems to be invalidated and the information is fetched again from the server, taking 20 seconds again. The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group information is refreshed in the background. So a user running the groups command would always see freshly cached values?
With 'debug_level=6' or higher in the [domain/...] section of sssd.conf you should be able to see messages like 'Refreshing <username> in domain <domainname>' in domain log file when is refresh task is running.
bye, Sumit
Clearly I am not understanding something here.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted....
Thankyou Sumit. I think you might be trying to tel lme something with the debug_level=6 :-)
On 4 July 2018 at 09:04, Sumit Bose sbose@redhat.com wrote:
On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
I have an AD setup where users can be a member of perhaps 130 groups. When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less that
one
second. However, after a length of time the cache seems to be invalidated and the information is fetched again from the server, taking 20 seconds again. The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group information
is
refreshed in the background. So a user running the groups command would always see freshly cached
values?
With 'debug_level=6' or higher in the [domain/...] section of sssd.conf you should be able to see messages like 'Refreshing <username> in domain <domainname>' in domain log file when is refresh task is running.
bye, Sumit
Clearly I am not understanding something here.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@
lists.fedorahosted.org/message/M4R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/ _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@ lists.fedorahosted.org/message/GYL5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
One thing I do note. I have reduced refresh_expired_interval to 40 seconds, which is clearly a ridiculously low time. However when I look at the cached information I always see Initgroups expiration time:Expired
I am not sure what this means.
root@ibis:~# sssctl user-show abc Name: abc Cache entry creation date: 06/27/18 17:09:58 Cache entry last update time: 07/04/18 11:28:16 Cache entry expiration time: 07/04/18 11:29:16 Initgroups expiration time: Expired Cached in InfoPipe: No
On 4 July 2018 at 11:01, John Hearns hearnsj@googlemail.com wrote:
Thankyou Sumit. I think you might be trying to tel lme something with the debug_level=6 :-)
On 4 July 2018 at 09:04, Sumit Bose sbose@redhat.com wrote:
On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
I have an AD setup where users can be a member of perhaps 130 groups. When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less that
one
second. However, after a length of time the cache seems to be invalidated and
the
information is fetched again from the server, taking 20 seconds again. The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group
information is
refreshed in the background. So a user running the groups command would always see freshly cached
values?
With 'debug_level=6' or higher in the [domain/...] section of sssd.conf you should be able to see messages like 'Refreshing <username> in domain <domainname>' in domain log file when is refresh task is running.
bye, Sumit
Clearly I am not understanding something here.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.or
g/archives/list/sssd-users@lists.fedorahosted.org/message/M4 R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/ _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.or g/archives/list/sssd-users@lists.fedorahosted.org/message/GY L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
On Wed, Jul 04, 2018 at 11:30:21AM +0200, John Hearns wrote:
One thing I do note. I have reduced refresh_expired_interval to 40 seconds, which is clearly a ridiculously low time. However when I look at the cached information I always see Initgroups expiration time:Expired
I am not sure what this means.
root@ibis:~# sssctl user-show abc Name: abc Cache entry creation date: 06/27/18 17:09:58 Cache entry last update time: 07/04/18 11:28:16 Cache entry expiration time: 07/04/18 11:29:16 Initgroups expiration time: Expired Cached in InfoPipe: No
Yes, this is expected because the groupmemberships are not updated here because it would be too expensive. But if you use the AD provider with tokenGroups enabled (the default) it should help nonetheless because all groups in the cache should be valid and after the single tokenGroups LDAP request the user "just" has to be added to all the group it is a member of.
Please let me know if it still needs 20s or more to update the group memberships with tokenGroups enabled if all groups are still valid.
bye, Sumit
On 4 July 2018 at 11:01, John Hearns hearnsj@googlemail.com wrote:
Thankyou Sumit. I think you might be trying to tel lme something with the debug_level=6 :-)
On 4 July 2018 at 09:04, Sumit Bose sbose@redhat.com wrote:
On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
I have an AD setup where users can be a member of perhaps 130 groups. When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less that
one
second. However, after a length of time the cache seems to be invalidated and
the
information is fetched again from the server, taking 20 seconds again. The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group
information is
refreshed in the background. So a user running the groups command would always see freshly cached
values?
With 'debug_level=6' or higher in the [domain/...] section of sssd.conf you should be able to see messages like 'Refreshing <username> in domain <domainname>' in domain log file when is refresh task is running.
bye, Sumit
Clearly I am not understanding something here.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.or
g/archives/list/sssd-users@lists.fedorahosted.org/message/M4 R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/ _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.or g/archives/list/sssd-users@lists.fedorahosted.org/message/GY L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted....
Thankyou Sumit. I will test with and without tokengroups.
However, please bear with me. Could you make it more clear what is happening here
a) an initial run of 'groups abc' takes some time to complete. OK, that is fine - we know information must be fetched from Active Directory
b) the next time 'groups abc' is run it returns in less thna 1 second. OK - I think this mus tbe using cached information
c) after a certain amount of time 'groups abc' again takes a long time to return
The documentation says that after refresh_expired_interval a BACKGROUND refresh is run. Surely then you always have an up to date set of cached information?
I think what you are saying is that the groupmemberships are NOT refreshed in the background.
If so, would it be the useful to set entry_cache_timeout to a very high level?
To explain, we work in a windowing environment (LightDM). When a window is opened this can take a long time, as 'groups abc' is run as part of the login. We dont want a user to have random times when opening a window will seem to freeze or take a long time.
On 4 July 2018 at 16:00, Sumit Bose sbose@redhat.com wrote:
On Wed, Jul 04, 2018 at 11:30:21AM +0200, John Hearns wrote:
One thing I do note. I have reduced refresh_expired_interval to 40
seconds,
which is clearly a ridiculously low time. However when I look at the cached information I always see Initgroups expiration time:Expired
I am not sure what this means.
root@ibis:~# sssctl user-show abc Name: abc Cache entry creation date: 06/27/18 17:09:58 Cache entry last update time: 07/04/18 11:28:16 Cache entry expiration time: 07/04/18 11:29:16 Initgroups expiration time: Expired Cached in InfoPipe: No
Yes, this is expected because the groupmemberships are not updated here because it would be too expensive. But if you use the AD provider with tokenGroups enabled (the default) it should help nonetheless because all groups in the cache should be valid and after the single tokenGroups LDAP request the user "just" has to be added to all the group it is a member of.
Please let me know if it still needs 20s or more to update the group memberships with tokenGroups enabled if all groups are still valid.
bye, Sumit
On 4 July 2018 at 11:01, John Hearns hearnsj@googlemail.com wrote:
Thankyou Sumit. I think you might be trying to tel lme something with
the
debug_level=6 :-)
On 4 July 2018 at 09:04, Sumit Bose sbose@redhat.com wrote:
On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
I have an AD setup where users can be a member of perhaps 130
groups.
When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less
that
one
second. However, after a length of time the cache seems to be invalidated
and
the
information is fetched again from the server, taking 20 seconds
again.
The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group
information is
refreshed in the background. So a user running the groups command would always see freshly cached
values?
With 'debug_level=6' or higher in the [domain/...] section of
sssd.conf
you should be able to see messages like 'Refreshing <username> in domain <domainname>' in domain log file when is refresh task is running.
bye, Sumit
Clearly I am not understanding something here.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/
wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.or
g/archives/list/sssd-users@lists.fedorahosted.org/message/M4 R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/ _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/
wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.or g/archives/list/sssd-users@lists.fedorahosted.org/message/GY L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@
lists.fedorahosted.org/message/P3WAZ36XA2RL7MLNFMVKBAB2DDVK2SSE/ _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@ lists.fedorahosted.org/message/RUJIULW2YG7NJZPU64NHTCR2GSAIQZE4/
Testing with tokengroups enabled and disabled a 'groups userabc' For reference in my sssd.conf ignore_group_members = TRUE
Using ldap_group_nesting_level = 0 ldap_use_tokengroups = TRUE Time taken is 56.5 seconds The user abc is member of 227 groups
ldap_group_nesting_level = 0 ldap_use_tokengroups = FALSE Time taken is 20.4 seconds The user abc is a member of 104 groups
Setting the nesting_level
ldap_group_nesting_level = 5 ldap_use_tokengroups = TRUE Time taken is 330 seconds !!!!!!!!!!!!!!!!!!!!!!! The user abc is member of 227 groups
dap_group_nesting_level = 5 ldap_use_tokengroups = FALSE Time taken is 314 seconds The user abc is member of groups
My reading of the documentation says ldap_use_tokengroups must be false if the ldap_group_nesting_level is set
Clearly when I get the groups returned in 20 seconds I am not getting a complete list. As Penelope Pitstop says: Hayyullpp!
On 5 July 2018 at 10:37, John Hearns hearnsj@googlemail.com wrote:
Thankyou Sumit. I will test with and without tokengroups.
However, please bear with me. Could you make it more clear what is happening here
a) an initial run of 'groups abc' takes some time to complete. OK, that is fine - we know information must be fetched from Active Directory
b) the next time 'groups abc' is run it returns in less thna 1 second. OK - I think this mus tbe using cached information
c) after a certain amount of time 'groups abc' again takes a long time to return
The documentation says that after refresh_expired_interval a BACKGROUND refresh is run. Surely then you always have an up to date set of cached information?
I think what you are saying is that the groupmemberships are NOT refreshed in the background.
If so, would it be the useful to set entry_cache_timeout to a very high level?
To explain, we work in a windowing environment (LightDM). When a window is opened this can take a long time, as 'groups abc' is run as part of the login. We dont want a user to have random times when opening a window will seem to freeze or take a long time.
On 4 July 2018 at 16:00, Sumit Bose sbose@redhat.com wrote:
On Wed, Jul 04, 2018 at 11:30:21AM +0200, John Hearns wrote:
One thing I do note. I have reduced refresh_expired_interval to 40
seconds,
which is clearly a ridiculously low time. However when I look at the cached information I always see Initgroups expiration time:Expired
I am not sure what this means.
root@ibis:~# sssctl user-show abc Name: abc Cache entry creation date: 06/27/18 17:09:58 Cache entry last update time: 07/04/18 11:28:16 Cache entry expiration time: 07/04/18 11:29:16 Initgroups expiration time: Expired Cached in InfoPipe: No
Yes, this is expected because the groupmemberships are not updated here because it would be too expensive. But if you use the AD provider with tokenGroups enabled (the default) it should help nonetheless because all groups in the cache should be valid and after the single tokenGroups LDAP request the user "just" has to be added to all the group it is a member of.
Please let me know if it still needs 20s or more to update the group memberships with tokenGroups enabled if all groups are still valid.
bye, Sumit
On 4 July 2018 at 11:01, John Hearns hearnsj@googlemail.com wrote:
Thankyou Sumit. I think you might be trying to tel lme something with
the
debug_level=6 :-)
On 4 July 2018 at 09:04, Sumit Bose sbose@redhat.com wrote:
On Tue, Jul 03, 2018 at 02:12:22PM +0200, John Hearns wrote:
I have an AD setup where users can be a member of perhaps 130
groups.
When I run 'groups jbloggs' this can take 90 seconds or even
longer.
I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE
Once the information is cached the groups command returns in less
that
one
second. However, after a length of time the cache seems to be invalidated
and
the
information is fetched again from the server, taking 20 seconds
again.
The cacheing parameters are set to:
entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000
Surely this means that after 4000 seconds the user and group
information is
refreshed in the background. So a user running the groups command would always see freshly
cached
values?
With 'debug_level=6' or higher in the [domain/...] section of
sssd.conf
you should be able to see messages like 'Refreshing <username> in domain <domainname>' in domain log file when is refresh task is running.
bye, Sumit
Clearly I am not understanding something here.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki
/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.or
g/archives/list/sssd-users@lists.fedorahosted.org/message/M4 R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/ _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki
/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.or g/archives/list/sssd-users@lists.fedorahosted.org/message/GY L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.or
g/archives/list/sssd-users@lists.fedorahosted.org/message/P3 WAZ36XA2RL7MLNFMVKBAB2DDVK2SSE/ _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.or g/archives/list/sssd-users@lists.fedorahosted.org/message/RU JIULW2YG7NJZPU64NHTCR2GSAIQZE4/
sssd-users@lists.fedorahosted.org