On Thursday 09 September 2010 18:33:26 Simo Sorce wrote:
On Thu, 9 Sep 2010 08:57:37 -0700
Jeff Schroeder <jeffschroeder(a)computer.org> wrote:
[..]
> Having enumerate = False but still enumerate the members of
each
> group (when the group is looked up) would be nice. Some users got
> really confused with the output of getent group showed them in the
> right groups, but not all of the members.
>
> Remember that while optimizing for hte 50k member group is
> important, it is likely not the most common usage scenario.
Ok, I was also wondering we can use a slightly different set of
heuristics depending on what kind of schema is used.
So we have the following scenarios:
1) If we use rfc2307 classic with memberUid attributes, we can just
create the fake/expired users and be done with it.
Agreed.
2) If we use rfc2307bis w/o nested groups we can count the number of
members on the group entry and switch to a full user enumeration if
the number of members is greater than a defined (potentially user
defined) threshold. Assuming a threshold value of 100, if we have 10
members we just do 10 lookups, while, if we have > 100 member we do a
full enumeration (it's a single ldap search, and if modifyTimestamp
is used also highly optimized after the first search) so we are sure
all users are there with the right name.
I think that's an optimization that
could be worth exploring later. In a
first iteration I'd just go for implementing the complete group lookup by
looking up every single user regardless of how large the group is. (plus
the possiblity to completely disable member unrolling through the
configuration)
3) If we use rfc2307bis with nested groups we do the same as in 2,
but
we add an internal user lookup against the cache we just populated to
determine if some members are groups that need further lookups in
order to complete the group unrolling operation.
Why do an extra cache lookup? You
could issue the addtional LDAP lookups
right when you receive the entries of the group members. Provided the
correct LDAP attributes where requested (i.e. user attributes + groups
attributes).
4) If we use IPA (rfc2307bis + nested groups + unrolled members in
memberOf attribute), we can do a single search with memberOf=groupDN,
as IPa's memberOf fully resolves nested groups. This would return all
and only the users members of the group.
So if the group has 101 members in a directory of 50k users we do not
do a full 50k users enumeration just because we have a group that is 1
above the threshold.
Do I miss any scenario ?
Simo.
regards,
Ralf