Bugzilla Bug 155492

In situations with very large groups (thousands to tens of thousands of users),
there is an unacceptable delay when looking up the group which makes nss_ldap
essentially unusable.

Paul Henson has written a patch to allow for a nss_getgrent_skipmembers
parameter in ldap.conf which, if enabled, will cause nss_ldap to not request
member attributes for group lookups.

Luke Howard (the maintainer of nss_ldap) has agreed to look into including the
patch into the official source, but we would like to see the patch go into
portage in the interim.

Created an attachment (id=102208) [edit]
Patch to add option to skip requesting member attributes for group lookups.

coming soon after 253 is in stable.

It looks like 253 has been stable for a while.  Any word on when we can look
forward to seeing this feature incorporated?

in cvs now on top of 254 which has some other group optimizations. 253 is still
pending on mips for stable.

Ok, great.  On the topic of other group optimizations, here is another patch
that adds the ability to configure the maximum number of nested groups queried
for.  It can reduce some unnecessary traffic.  Can you add it as well?

Created an attachment (id=109329) [edit]
Patch to add nss_max_group_depth config option.

in 257 in CVS now.

The re-diff of the nss_max_group_depth patch that is in portage is missing the
hunk that sets _nss_ldap_max_group_depth to what was read from the config.  A
fixed patch to follow.

Created an attachment (id=138522) [edit]
Fixed nss_ldap-257-nss_max_group_depth.patch

hncaldwell: please respin against 262, and state if it's to supplement or
replace the existing space.

I looked into rewriting the patch to not use a global variable (upstream
wouldn't accept it that way), but it would be such a mess to do it without one
that I don't think that it is worth the trouble.  I am curious why a global
variable isn't ok since it is currently a #define constant, but I never heard
back.

The reason that I wrote the patch in the first place was so that I could
disable querying for nested groups, which gained a slight amount of efficiency,
and I figured that others would like the ability to configure the max depth. 
Since the gained efficiency is pretty insignificant, the only reason I see to
go through the mess of passing another value down through all of the functions
necessary would be if someone needed it to be deeper than the hardcoded 16 (and
even then, it would be easier to just up that).

Since the skip members patch that this bug was initially made for is now
included upstream, I think it is just easiest to close this bug (unless there
is someone out there who really, really wants the max group depth to be
configurable).