[PATCH] Samba KCC python topology generator

Dave Craft wimberosa at gmail.com
Wed Jan 11 07:25:38 MST 2012

Tridge, Samba Team,

The patchsets available at
are now available for review and integration if acceptable.

This version of the samba_kcc python code advances in two major

1) Support for exporting an LDIF file from any database and then importing
    the LDIF into an (abbreviated, schema-less, temporary) database such that
    the topology generator can run against it.  The point of this
function is to be
    able to extract a small aspect of any forest configuration that is
only relevent
    for KCC topology generation and then to be able to re-run the samba_kcc
    against it to test if the generated topology is equivalent.
Effectively this allows
    us to debug a customer situation without exposing any security
relevant information
    in the exported ldif as well as allowing test case generation
against varying

    The supported syntax of the samba_kcc includes normal options such as
    -H <databaseUrl> -U <admin%pw> as well as new options:
            --exportldif <db.ldif>
            --importldif <db.ldif>  --tmpdb <db.ldb>

    Operationally you point the samba_kcc at a DC's database URL with the
    --exportldif option included and you will receive a <db.ldif> file
(must not already
    exist) that includes crossRefs, siteLinks, etc. that are relevant
to topology generation.

    After receiving the <db.ldif> file, you may then import it to a
    database via  --importldif <db.ldif> --tmpdb <db.ldb>.    The
<db.ldb> file must not
    already exist.   This creates and runs the topology generator
against <db.ldb>.  The
    file is left in place after the run so that you can run against
<db.ldb> as many times
    as you like.

2) The second major advancement is the inclusion of a version of INTER-SITE
    topology generation.  This is not an exact replica of the MS tech
version of
    inter-site (as opposed to the samba_kcc exact replication of
intra-site).   This
    implementation however follows the flow closely while abbreviating
the minimum
    cost spanning tree computation.    The full bore implementation is
going to take
    more time, but this abbreviated implementation will still produce a set of
    NTDS Connections that are a super-set of what the minimum cost spanning
    tree algorithm would produce.    That means that this
implementation will cause
    the DRS to arrive at the correct replication state but additional
    connections and traffic) will be produced.

    Effectively instead of a minimum cost spanning tree this algorithm selects
    the ISTG (inter-site topology generator) and a set of bridgehead
servers in each
    site, and then produces NTDSConnections between bridgeheads at every site.
    That is not optimal since no link cost is being computed in this
algorithm and
    the site tree connections are n to n.

To Be Done:
     Lots...but this gets us much closer.   The two things that have
to be done before
     this really gets fully turned on though is the addition of lots
of LDIF test cases with
     different configurations.   There are more edges in these
algorithms than I've
     seen in a long time.  Hence the --exportldif/--importldif code
was important.   The
     second thing that has to be done is the proper management of kccFailedLinks
     and kccFailedConnections in the daemon and the retrieval of it in
the samba_kcc.
     This is absolutely needed because currently the bridgehead
computation doesn't
     consider whether the bridgehead is actually alive and being
responsive.   So we
     could be producing connections to bridgeheads that are never
useful because the
     connection is dead.   The current (old kcc) code doesn't do this
either but since
     it creates connections to every DC (even across sites) it is
still a larger superset
     of connections than even the samba_kcc produces.

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

More information about the samba-technical mailing list