DRSUAPI interface - test case scenarious

[Stefan (metze) Metzmacher]

Hi Kamen,

> As you may know, we are currently on DRSUAPI implementation.
> In the existing code base there are bunch of torture tests for the interface - most of them are calling the corresponding interface method and print what the traffic is. No doubt this is quite useful for cracking data.
> 
> Nevertheless, we decided to implement some more tests.
> The idea is - we think it will be great for us to have few more complex tests to be discussed with MS guys during Microsoft interoperability event.
> 
> Here is a very short list of tests we are thinking of (just a draft):
> 
> TC1: Test case for DsGetNCChanges() (IDL_DRSGetNCChanges) method:
> 1. Call drsuapi_DsGetNCChanges() to get highest USN
> 2. Add attribute, object, whatever
> 3. Call drsuapi_DsGetNCChanges() - check replica contains added objects in step 2

We should be careful with other changes also being replicated, maybe
other local application on the dc have done some changes at the same
time. But we should also try to detect that an origin update triggers
changes on more than one object, e.g. the rid counter... we should also
verify this things.


> NOTE: I am quite qurious if we can use DRS interface without joining the domain.
> 	Reading the docs I am getting the impression we don't need to be joined in the domain (correct me if wrong here)

You can use it as domain administrator, you don't need a dc machine account.

> TC2: Test case for "urgent replication" - IDL_DRSReplicaSync() && IDL_DRSGetNCChanges().
> Precondition is for us to have 2 AD DCs (Win-Win, Win-S4, S4-S4). Lets name the machines M1 and M2. In case we have Win-Win configuration, torture test is to be performed on M3 machine. 
> 1. Verify M1 and M2 are part of replication graph, i.e. repsFrom/repsTo are set correctly
> 2. Tune AD on M1 and M2 to replicated with long delay (any ideas?)
> 3. Add attribute, object, whatever on M1.
> 4. Send IDL_DRSReplicaSync() to M2 setting it should replicate from M1.
> 5. Verify objects added on M1 are replicated on M2.
> 
> TC_all utils: It should be nice if we have "data validation" helpers. I.e. to be able to verify data returned from, say IDL_DRSGetNCChanges(), is valid and is what we have expected.
> 
> 
> Any notes, comments, ideas etc are very welcomed.
> We need to implement as much as we can before the mid of September so that any documentation misunderstandings to be clarified before progress of DRSUAPI development advance too much.

Sounds great!

You could also have a test that verifies the order the objects and
linked attributes are returned. E.g. verify all attributes with DN
syntax and all drsuapi_DsReplicaObjectIdentifier structues that the
guids are already known by when we receive them.
Then you can also check for differences depending on the
drsuapi_DsReplicaNeighbourFlags flags. I assume
DRSUAPI_DS_REPLICA_NEIGHBOUR_RETURN_OBJECT_PARENTS may cause
differences, but maybe others too.

We also need to tests for the DsAddEntry() call, which is used
by a dc promotion.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090825/df607593/attachment.pgp>