Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] grouper and openldap

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] grouper and openldap

Chronological Thread 
  • From: Michael R Gettes <>
  • To: Tom Poage <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] grouper and openldap
  • Date: Fri, 3 Feb 2017 13:41:34 -0500
  • Ironport-phdr: 9a23:SppaRhVldbmpoJNFgOGU10VLuQvV8LGtZVwlr6E/grcLSJyIuqrYbBeOt8tkgFKBZ4jH8fUM07OQ6PG8HzNZqs/Y6jgrS99lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal8IRiyogjdrMsbjZZtJqos1xfFvGZDdvhLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PWwt68LlqRfMTQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WSin4qx2RhLklDsLOjgk+2zMlMd+kLxUrw6gpxxnwo7bfoeVNOZlfqjAed8WXHdNUtpNWyBEBI63cokBAPcbPetAs4byqEYAoxu8CgeiC+3hyTFIiGHx06Ahz+QhCATG0BAgH94SsnnZqsj+OqcIUeCyyanF1TLNb/JK1jf98ofHbBQhquyQU7ltcMTe11UvFx/bgVWLtIfoODaV1v4Cs2WV8+ZtTvqvi3U6qw1rvDeg29osh5DPi4kIxF7E8iB5z5w0Jd2+UEN7ZsakH4VWtyGeKoR5WNsiT3tvuCYgxb0Lv4OwcisSyJk/2hLTdf+Kf5KV7h7+V+udOyp0iX1kdb6lmhq//0mtxvXhWsWq01tGtDdJnsTPu3wXyhDf99SLRuFy80qv3zuEyhrd5fteIU8ukKrWM54hzaA0lpoUqUnDAjX2lFvogK+Qa0ko5/Kn5/79bbX9uJCcK5V4ihnlMqQzgMCwH/k3MhUWU2ia/+SzyqHj8FXkTLlUjfA6iLTVvI3ZKMgBu6K0DA5Y3pw+5xuxDjqqyNEYkmMGLFJBdhKHlY/pO1TWLfD9F/e/jFqhnCtwyvDeJb3hH4/BIWben7f8Zbp98VJTyBIvzdBD4JJZEr4BIOj0Wk/srNzXEAU5PxWpw+b8Ftp9zJgeVHmLAq+YK6PSrUSI6vw1L+mNYo8VpCjyK+Ij5/HwkX81h0URcre00psKOziEGaFaJEDRWX3ljdpJRXsEpg03Q+HClVaOWCBSfDC/U79qtR8hD4fzKIbIRomghPS7lAi2AoFbfSgSD0qDSi/Ab56ZHfoAdXTBcYdajjUYWO35GMca3ha0uVq/kuI/Iw==

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

Archive powered by MHonArc 2.6.19.

Top of Page