patch set for kcc intra-site topology

tridge at tridge at
Wed Jul 13 06:15:04 MDT 2011

Hi Dave,

 > Asking for a review / comments on:

thanks for your great work on this!

I've signed off on the first 7 patches. They are in autobuild now.

In the 8th one, it would be a bit neater to use some of the
ldb_msg_*() helper functions to make the code more compact. For
example, the use of ldb_msg_find_element() followed by ldb_dn_new()
can be replaced with ldb_msg_find_attr_as_dn(). 

Even better would be to use ldb_get_config_basedn(), as it uses a
cached value. The same goes for ldb_get_schema_basedn() and
ldb_get_default_basedn().  When you find you need one of these common
elements, try a "git grep" to see if someone else has already created
a utility function for it. If it is commonly accessed then there is
probably a library function for it (or there should be!).

I should also explain a bit about WERR_FOOBAR. We originally added the
FOOBAR error codes as markers in the code for "I don't know what error
code to use here, so I'll put in FOOBAR and we'll work them out
later". That approach didn't really work too well, as we never came
back to them and lots of them are still in the tree.

So we now prefer to put in the right error code from the start, or a
best guess. For example, if you don't have a
configurationNamingContext then your database is pretty badly hosed,
and returning WERR_DATABASE_FAILURE is reasonable. 

 > This also does not properly introduce kCCFailedLinks or
 > kCCFailedConnections as those seem to be runtime attributes
 > that are going to have to be tracked during replication communication
 > (as opposed to database attributes)

it would be nice to get these right, but I doubt it is critical for a
first pass at this code.

 > Lastly I have to figure out how to introduce good tests and there
 > are still some multi-site and application naming contexts that I need
 > to compare against a windows server implementation.

I think we'll need to use unit tests for this, where we create fake
topology structures and pass them to the kcc code then check against a
known answer.

Probably the best way is to expose these functions in python, then
create a python test that has a set of known complex network setups,
and asks the kcc C code to create the links for it. If the python test
could also generate its own test case by looking at a real network
that would be great. 

A samba-tool command that checks all topology links for all DCs (by
just looking in the SAM) would also be very useful. It would run our
topology code while pretending to be each DC in the domain in
turn. Then it would report any discrepencies. Running that against a
few complex networks should pretty quickly find any bugs!

Cheers, Tridge

More information about the samba-technical mailing list