On Fri, Nov 27, 2009 at 07:13:55PM -0500, Simo Sorce wrote:
When I did the enumgrent optimization patch I totally forgot about
nested groups for some reason.
Of course I broke them. The gain in performance although was just way
too substantial to just revert to the previous way of resolving nested
groups again and again at every search.
These 2 patches instead store unrolled groups by adding a new
operational attribute: memberuid
This attribute contains just the user name of any user directly or
indirectly (through a nested group) members of a group.
This way computation is done once at modify time and never again.
Fixes bug #291
0001 does not compile:
ldb_modules/memberof.c: In function 'memberof_del':
ldb_modules/memberof.c:1152: error: 'el' undeclared (first use in this
ldb_modules/memberof.c:1152: error: (Each undeclared identifier is
reported only once
ldb_modules/memberof.c:1152: error: for each function it appears in.)
Do I miss another patch which fixes this?
Why do you save 'only' the name attribute in memberuid and not the DN?
It is ok for the nested groups use case, but I think from a general pov
it would make sense to store the DN, e.g. if we need to store generic,
i.e. non-posix, IPA groups where objects might not have a name