Subject: Grouper Users - Open Discussion List
- From: Michael R Gettes <>
- To: Tom Poage <>
- Cc: "" <>
- Subject: Re: [grouper-users] grouper and openldap
- Date: Fri, 3 Feb 2017 13:41:34 -0500
if one has to go the ‘unix-ish’ route of breaking down by alpha because of
filesystem limitations - that line of thought - i’m sorry but it’s time to
get another LDAP server - one that really scales. Now, the comments about
sorting and mdb backend may make this work for openldap - if so, that’s
great. if not, get a server that works. oh, and from my own experience, the
dynlist stuff doesn’t perform well in high-usage scenarios, just like use SQL
backends (no, they are not related).
just thinking out loud :-)
and thanks for the nod to the Recipe.
> On Feb 3, 2017, at 1:32 PM, Tom Poage
> Right. Your being author of the LDAP Recipe, I suspected something like
> this could be the case. :-)
> I haven't used OpenLDAP in several years but, thinking along the lines of
> the aphorism "all problems in computer science can be solved by another
> level of indirection," a form of 'hashed' storage for large aggregate
> groups, with a mechanism to dynamically resolve membership at query time
> could be fruitful.
> Found mention of an OpenLDAP 'dynlist'. If otherwise large static groups
> are hashed/broken up (member=a*, member=b*, ...), I wonder if that wouldn't
> remedy the issue of managing them with hopefully minimal impact on client
> query performance. It appears as if the client may need to be none the
> wiser wrt queries.
> Just thinking out loud,
>> On Feb 3, 2017, at 8:18 AM, Michael R Gettes
>> we have both static group objects and isMemberOf on the user object - so
>> we do as you suggest if I am understanding you correctly. The real issue
>> is application behavior. There are still many apps operating against
>> static group objects. So the need for large groups remains.
>> I hope this helps.
>>> On Feb 3, 2017, at 11:12 AM, Tom Poage
>>> Is it possible in Grouper to 'invert' the solution, making membership a
>>> user attribute? Then each user entry might be a member of, say, on the
>>> order of 100 groups vs. managing a single 40k entry object.
>>>> On Jan 30, 2017, at 7:50 AM, Michael R Gettes
>>>> I received only a few replies. Others have run into this limitation of
>>>> openldap not being able to support large static group objects. The
>>>> problem is really large numbers of multi-valued attributes (not just
>>>> group objects). My observation is 5 seconds to update when the group
>>>> object becomes greater than 35K-40K members. Apparently, openldap has
>>>> to regenerate the member/uniquemember attributes for the entire object
>>>> each time. This appears to be a known issue with
- Re: [grouper-users] grouper and openldap, Tom Poage, 02/03/2017
Archive powered by MHonArc 2.6.19.