Grouper Users - Open Discussion List

[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.

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
>> ...
>