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
