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(a)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(a)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(a)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(a)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(a)lists.fedorahosted.org
> > >> > To unsubscribe send an email to sssd-users-leave(a)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(a)lists.fedorahosted.org/message/M4
> > >> R23YDHWUMUZPE4QZW2CFCYVU3WTXUO/
> > >> _______________________________________________
> > >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > >> To unsubscribe send an email to sssd-users-leave(a)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(a)lists.fedorahosted.org/message/GY
> > >> L5YCE73YNOBPV6JNY2F5WVSBBRMCEC/
> > >>
> > >
> > >
>
> > _______________________________________________
> > 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://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(a)lists.fedorahosted.org/message/P3
> WAZ36XA2RL7MLNFMVKBAB2DDVK2SSE/
> _______________________________________________
> 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://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(a)lists.fedorahosted.org/message/RU
> JIULW2YG7NJZPU64NHTCR2GSAIQZE4/
>