patch set for kcc topology comparison

[Dave Craft]

As per background discussions with Tridge, I am in agreement with his
direction that
dumping ldif records from the customer database for subsequent input/debug
by the developer would be a good thing.   This would of course allow several
things...

1) End user can analyse the ldif records to ensure it doesn't contain anything
    deemed secret or confidential to the user.   Given the records we
are looking
    for that probably isn't a concern but since the records are
readable by the user
    that gives the end-user extra confidence.
2) Developer can utilize records to rerun algorithms to debug and furthermore
    include records that produced algorithm anomalies into a testcase
that we can
    have for future reference.

However...here's a suggestion...

We may want to consider a slightly more expansive view of this problem/solution
as we probably have similar issues with algorithms beyond the KCC.   In
general I think it might be good to have one (or multiple distinct)
scripts that extract
a simplified set of ldif records from the customer database.   In the
KCC algorithm those records
are noted below.

Furthermore instead of going directly from ldif to ldb_result (and
having to modify the
KCC to take ldb_result messages in its core algorithm) we could just reproduce
a simplified sam ldb database from the end-users ldif files.   In that
manner the KCC
code would not really have to change that much and could continue to
perform ldb_search()
and the like within it.   We'd provably need a simple rootDSE record
as well since the ldb_context
wants to save the schema/config/default dn in its opaque attributes
when this simplified samdb
would be opened.

I ran a quick test on tridge's records to see if I could produce a
samdb that was significantly
abbreviated but would work.   I attached the example python hack to
this note (this was just
a test for my education and is in no way interesting or useful ;-).

The rest of this note is some background discussion we had about the
KCC records we need.
Tridge has clarified a great deal of this for me since we will have to
get the NCs from the
configuration schema (instead of the rootDSE) and we will have to
query on a different
port for certain info.

-------------------------

So here's what I think are inputs to the KCC algorithm:

Each naming context is taken in turn and connections / reps are
calculated individually.
The algorithms may prune connections if there are too many but the at
least one run
per algorithm (intra / inter) is devoted to each individual NC.   Thus.

1) need all the naming contexts (including application NCs)

So to determine if you have NCs for other domains or application NCs
need to understand
if the NC has an objectSid (application NCs don't have one).   Note
that application NCs have
 to be identfied in the  algorithms because they have modified
topology calculation rules.

2) Then for each NC we need to do something like

ldbsearch -H ldap://n1lin1 -U Administrator%p at ssw0rd -b
"DC=ad1,DC=wimberosa,DC=net" -s base

for each NC

In addition to that ojbectSid we'll also need that "repsFrom" and
"repsTo" attribute and blob so may
as well get the whole object under the dn if easy.

3) Next we will need all the nTDSDSA objects as we will need
"objectGUID", "options", "invocationID",
    "msDS-hasMasterNCs", "hasMasterNCs", "msDS-isRODC",
"msDS-hasFullReplicaNCs",
    "hasPartialReplicaNCs', "msDS-HasInstantiatedNCs".   So getting
the whole object for each
     nTDSDSA is important.

4) Under each NC dn we will also need the crossRef object under it.
We have to compare the "nCName"
    attributes of the crossRef object to see if it is a cross
reference for each NC we are examining.
    If it is then we consult the "msDS-NC-Replica-Locations" and
"msDS-NC-RO-Replica-Locations"
    attributes for the crossRef to see if it enumerates the nTDSDSA we
are currently computing a topology
    for.  If it matches then we should have a replica for the NC on
the DC we are computing topology for.

    Bottom line we need the crossRef objects under each partition dn

5) Then under our nTDSDSA object (identified by dsSeriviceName from
(1)) we need the nTDSConnection
     objects.   We'll need the objectGUID, fromServer and options
minimally but should get the whole set
     of connection objects if easy.

6) inter-site has the bridgehead and sites attribute inputs which can
be added  later.


-- 
Regards, Dave Craft
Cut the headlights and put it in neutral.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samdb_import
Type: application/octet-stream
Size: 1775 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20111010/0337b455/attachment.obj>