linked attributes, DRS and abusing the ldb modules API

[Stefan (metze) Metzmacher]

Hi Tridge,

> I've been looking at supporting linked attributes in the
> repl_meta_data module. The test I've been using is to add/remove a
> couple of users from a global group on a W2K3 system, with DRS pull
> replication happening to a S4 DC.
> 
> As it stands in the tree now, the DRS pull does pull across the modify
> request for the 'member' attribute of the group, and this gets applies
> correctly, but the memberOf linked attributes don't get updated. The
> reason they don't get updated is that the linked_attributes module
> comes before the repl_meta_data module in the module list (as the
> repl_meta_data module gets pulled in as part of the partition module).

Your only talking about the linked attributes which come with the
object,right?

I mean

drsuapi_DsGetNCChangesCtr6->first_object->
...->object.attribute_ctr.attributes[i].value_ctr.values[j]


instead of

drsuapi_DsGetNCChangesCtr6->linked_attributes[i].value

correct?

> So to make this work, we have a few choices:
> 
>  1) we could reproduce the linked_attributes logic in the
>     repl_meta_data module. I'm guessing that is what your 'todo' in
>     dsdb_extended_replicated_objects_commit() impled?
> 
>  2) we could call into the linked_attributes module from the
>     repl_meta_data module, letting the linked_attributes module do its
>     work as usual when it gets a modify request on an attribute that
>     is linked
> 
>  3) we could change the module ordering
> 
> I've written a quick patch that implements (2). What do you think
> about this approach? The patch is below.
> 
> Note in particular the line:
> 
> 		if (ldb_load_modules_list(ldb, module_list, module->next, &ac->module->next) != LDB_SUCCESS) {
> 
> which is an approach I don't think we've used before, but does offer a
> way to re-use modules in a fairly clean fashion. For now it assumes
> the modules don't need initialisation, but that could be fixed.
> 
> The patch works in the sense that the member/memberOf attributes get
> correctly updated by a DRS pull, although we do generate a warning as
> we get some spurious updates to the memberOf linked attribute target,
> which are then discarded (which turns out to do the right thing).

I would create a new extended operation that will store the back link.

the repl_meta_data module can send this operation via the top of the
module stack, and the linked attribute module implements it.

Note this extended operation need to return the dn of the target
searched by the guid, so that the repl_meta_data module can store the
forward link with the fixed dn in case the link target was renamed on
the local server.

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/20090826/d3af465d/attachment.pgp>