linked attributes, DRS and abusing the ldb modules API

tridge at tridge at
Wed Aug 26 06:18:19 MDT 2009

Hi Andrew,

 > >  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
 > The problem with this is that it fails across module boundaries.  The
 > repl_meta_data module operates after the partitions module, so I'm
 > worried what happens to a link that crosses the partitions.

I don't think that is a problem. When the repl_meta_data module is
called, its module chain looks like this:


the ldb_load_modules_list() call I'm making changes it to this:


so the partition module is not being linked in. We're just adding the
linked_attributes module to the list of those modules that should
process the modify request we've constructed.

 > It's an interesting hack.  We also have to get in some of the other
 > modules, like the extended DN storage stuff.   

I'm not at all sure what modules we want to get in there. The whole
design of the DRS pull replication code seems to be based on bypassing
modules. It could just call a ldb_modify() at the top level, but
instead it constructs a complex extended operation specially designed
to bypass all the top level modules and jump down below the partition
module. I'm guessing that Metze did that for some reason (as Metze
understands this DRS stuff a lot better than I do!).

The problem is that it does need the linked_attributes module, and the
API usage I've proposed is the only sane way I can see to allow a
caller to call into a specific list of modules.

If it turns out we also need the extended DN module, then we can add
it to the list. That's why I made replmd_ctx_init() take a char **.

Cheers, Tridge

More information about the samba-technical mailing list