samldb and associated patches

Matthias Dieter Wallnöfer mdw at
Sat Sep 18 01:14:56 MDT 2010

Hi Andrew,

Andrew Bartlett wrote:
> On Fri, 2010-09-17 at 22:37 +0200, Matthias Dieter Wallnöfer wrote:
>> Hi Andrew,
>> please have a look at my patchset which passes "make test" on my
>> development box. Branch "stuff" in my private repo on and
>> Link:
>> I hope that the commit messages are clear enough.
> Do you have a test for the deleted objects behaviour?  This looks
> subtle, and I would like to have metze or tridge look over it first.
> s4:subtree_delete LDB module - adapt the module to support deleted
> objects not under "CN=Delete Objects"
> Also, where it is so trivial, it would be kinder to developers who later
> have to test this code if you could re-order these commits:
Is there a test suite which does perform such checks? Since I've really 
no idea how to write such one. If you could provide me with some code 
snippets or informations I would be very happy.
> s4:rootdse LDB module - make "dsServiceName" and "serverName" dynamic
> s4:provision - rootdse - remove the two static attributes
> "dsServiceName" and "server...
> s4:samdb_ntds_settings_dn - perform the NTDS settings container lookup
> without the...
> s4:samdb_ntds_settings_dn - ignore an error condition when a LDB
> connection setup...
> If you put these in the opposite order (easily done with a rebase as far
> as I can see), then a user who happens to bisect halfway though this
> code should always have this work.
Easy to do for me.
> Also on s4:samdb_ntds_settings_dn - perform the NTDS settings container
> lookup without the...
> This seems to do a unindexed search on dnsHostName.  We should avoid
> unindexed searches in routines such as this - and I fear that soon
> someone will request that likewise dnsHostName be made dynamic.  Perhaps
> instead search for our samAccountName based on the lp_netbios_name(),
> and follow the serverReference link?
Well, so I could make "dNSHostName" dynamic just now. And I will use 
> Finally, I think we really need to break up into more discrete
> tests.  We should not continue to extend the main test here, but instead
> write new tests in separate scripts, or at least separate tests in this
> script.
I agree, but this can also be done later. I would first really like to 
prepare this patchset before doing that.


More information about the samba-technical mailing list