patch set for kcc topology comparison

[Dave Craft]

This patch advances the kcc testing ability by introducing a new command
to samba-tool.   The invocation would normally be:
         samba-tool drs kcccmp <DC> -U Administrator%xxxxxx

The patch appears at:
        https://github.com/wimberosa/samba/tree/kcc-compare

Review is requested.

The patch does not include the newer intra-site topology (as that
still has pending work in my sandbox) but this is needed as a step
toward verifying ANY topology algorithm.

The code allows the samba KCC to run against a different LDAP database and
compute our algorithms topology for a different (potentially non samba) DC and
then perform a comparison looking for differences.   So when you invoke
the above (samba-tool drs kcccmp) command against a Samba DC
it finds no differences (the algorithms are the same) whereas when
you run against a windows server in a simple network topology you
find that there are differences in the repsFrom options.   Moreover
if you run this kcccmp against a more sophisticated network topology
you start seeing more and more differences with windows KCC.

These differences are expected given the current simplified nature
of our KCC versus the windows KCC.   However now we have a tool
to identify exactly what differences are showing up in the algorithms
and to allow us to modify our algorithm to converge with the windows
KCC algorithm.

Note that this patch took a good bit of restructuring of certain code
pieces in order to pull it out of a samba daemon task and build library
code for the representative pieces that both the KCC task and KCCCMP
utility would need.   I however wanted to make sure that I did not break
the baseline samba simple KCC so what you see here is some simple
changes in the shared code and a rebuilt simple KCC algorithm that is
part of the library.   I did both because I wanted to be able to run KCCCMP
against the traditional samba simple KCC to see if the new code is
algorithmically different in any manner (it appears to not be).   So effectively
I can compare against a windows KCC or the current (hopefully soon to be old)
KCC simple algorithm.

I am working on the intra-site topology for a future submission.

Regards
Dave Craft

On Wed, Jul 13, 2011 at 7:15 AM,  <tridge at samba.org> wrote:
> Hi Dave,
>
>  > Asking for a review / comments on:
>  >
>  > https://github.com/wimberosa/samba/tree/kcc-stable
>
> 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
>



-- 
Regards, Dave Craft
Cut the headlights and put it in neutral.