s4:samldb LDB module - "member" trigger
abartlet at samba.org
Wed Nov 3 01:34:32 MDT 2010
On Sat, 2010-10-30 at 20:16 +0200, Matthias Dieter Wallnöfer wrote:
> The branch, master has been updated
> via c0ebf5d s4:sam.py - add a short double swap "primaryGroupID" test
> via 98fefa8 s4:samldb LDB module - adapt the "samldb_prim_group_change" trigger to support multiple "primaryGroupID" modification entries
> via 02355fc s4:samr RPC server - the LDB error codes for adding or deleting a group member have changed
> via c664f01 s4:sam.py - enhance "member" tests
> via 4987467 s4:samldb LDB module - "member" trigger
> via 5a2c3ad s4:rpc_server/common.h - quiet compilation warnings
> from b548674 provision: fix wrong tests
> commit 4987467b785a5870cb338881c8916b4268006cd6
> Author: Matthias Dieter Wallnöfer <mdw at samba.org>
> Date: Sat Oct 30 17:12:48 2010 +0200
> s4:samldb LDB module - "member" trigger
> - adapt the "samldb_member_check" trigger to support multiple "member"
> modification entries. There can exist special modification messages which
> delete and add members in one operation
> - support the right error codes when modifications do fail
> (ERR_ENTRY_ALREADY_EXISTS, ERR_UNWILLING_TO_PERFORM)
Metze mentioned this patch to me on IRC as he chases down some
performance issues, and I wanted to comment on it. He may make further
comments once he finishes pinning down his issue.
The problem I have with the patch is that it seems very inefficient, and
I wondered if you had considered the O() notation complexity of this
For every member being added, you now do a search on the entry for that
member, rather than just let ldb_tdb complain about the duplicate
attribute when we eventually store it. Why is this? If an member
attribute gains 100 members, you now do 100 searches of the DB just to
check that they are not already there. The cost of that search is
rougly proportional to the number of members already being added -
particularly if done one at at a time, so this seems to be O(n^2).
And similarly, whey trying to determine if the member attribute would
conflict with a primaryGroupID, why not first (and only once) read the
sid of the entry, and then compare with the primaryGroupID of the
Surely this would be faster than dereferencing the member attribute,
only to form up a SID and compare it with our own DN?
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part
More information about the samba-technical