On Mon, 2009-11-30 at 11:47 +0100, Sumit Bose wrote:
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
>
> Simo.
>
0001 does not compile:
ldb_modules/memberof.c: In function 'memberof_del':
ldb_modules/memberof.c:1152: error: 'el' undeclared (first use in this
function)
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.)
I will check, builds and tests fine here.
Do I miss another patch which fixes this?
Why do you save 'only' the name attribute in memberuid and not the DN?
Because these are all users, the DN is reconstructed quite easily.
It's part of the optimization, having to dissect a DN at every query is
just a lot of work for nothing.
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
attribute.
This is only for NSS, if we need member/memberof, unless the tartget
entry is of type objectclass=user no memberuids are generated in the
groups.
Simo.
--
Simo Sorce * Red Hat, Inc * New York