Grouper Users - Open Discussion List

[Michael R Gettes <>]

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.

/mrg

> On Feb 3, 2017, at 1:32 PM, Tom Poage 
> <>
>  wrote:
> 
> 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.
> 
> http://www.openldap.org/faq/data/cache/1209.html
> http://www.openldap.org/lists/openldap-technical/201207/msg00172.html
> 
> Just thinking out loud,
> Tom.
> 
>> On Feb 3, 2017, at 8:18 AM, Michael R Gettes 
>> <>
>>  wrote:
>> 
>> 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.
>> 
>> /mrg
>> 
>>> On Feb 3, 2017, at 11:12 AM, Tom Poage 
>>> <>
>>>  wrote:
>>> 
>>> 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.
>>> 
>>> Tom.
>>> 
>>>> On Jan 30, 2017, at 7:50 AM, Michael R Gettes 
>>>> <>
>>>>  wrote:
>>>> 
>>>> 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
>>> ...
>> 
>