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.) 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 attribute. bye, Sumit _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
