Re: slow login with sssd and ldap config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/11/2010 12:41 PM, Gowrishankar Rajaiyan wrote:
> On 06/10/2010 05:09 PM, Eric Doutreleau wrote:
>> thanks for your answer
>> well i have the problem when i don't set up
>> ldap_user_search_base and
>> ldap_group_search_base
>> but i discovered that ou=Groups,dc=int-evry,dc=fr contains nothing
>> our posix group are elsewhere
>> and when i put ldap_group_search_base with the good value i have the
>> problem again
>> i guess i have to talk to the ldap guy to see if the data are correctly
>> indexed.
>> do u know what i should index on group?
>>
>> Le 10/06/2010 13:12, Stephen Gallagher a écrit :
>>> On 06/10/2010 05:50 AM, Eric Doutreleau wrote:
>>>> ahhh i took a day to write the mail and i found the solution 5 minutes
>>>> just after write the mail
>>>>
>>>> i add
>>>> ldap_group_search_base = ou=Groups,dc=int-evry,dc=fr
>>>> and it s far faster
>>>>
>>>> sorry to have disturbed
>>>>
>>>
>>> Hmm, this shouldn't have had a direct effect. If unspecified,
>>> ldap_group_search_base should default to being the same as
>>> ldap_search_base. Unless your LDAP server is incredibly large (and no
>>> indexing is being performed), setting this should not have a measurable
>>> effect. The primary purpose for this option is for LDAP deployments
>>> where users and groups are in vastly disparate sections of the tree.
>>>
>>> I'm more concerned that there's a bug in our processing when only one of
>>> the two options is specified. I'm CCing one of our upstream QE engineers
>>> to try and reproduce your original performance issue. I think you may
>>> have found a bug here.
>>>
>>> Eric, if you would also be willing to try it, I'm curious if you still
>>> see this problem with only ldap_search_base specified (without
>>> ldap_user_search_base and ldap_group_search_base)
>>>
>>>
>>>
>
>
> Hi Eric,
>
> I was unable to reproduce this issue on my test bed.


Sorry, I should have responded to this on-list (the discussion continued 
in private email for a bit).

The problem here is that there is a performance hit in our initgroups 
processing when dealing with groups that have a very large number of 
users in them.

However, I'm not opening a bug for two reasons:
1) For environments with this many users in the groups, it's more 
efficient in SSSD 1.2.0 to use enumerate=true (which will front-load the 
heavy processing and make all requests after the first few minutes go 
much faster)

2) It's already fixed coincidentally in the master branch upstream due 
to the complete rewrite of the cache.


-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux