linked attributes, DRS and abusing the ldb modules API

Andrew Bartlett abartlet at
Wed Sep 2 03:29:36 MDT 2009

On Wed, 2009-09-02 at 11:14 +0200, Stefan (metze) Metzmacher wrote:
> tridge at schrieb:
> > Hi Metze,
> > 
> > Andrew and I worked on this today, and I have just committed the
> > solution we came up with. The solution currently only copes with the
> > case where the linked attributes are sent as part of the messages, but
> > it looks easy to extend to the higher functional levels (we plan to do
> > that tomorrow).
> > 
> > The solution we used is this:
> > 
> >  1) we moved the repl_meta_data further up the module stack
> > 
> >  2) we modified the linked_attributes module to gather all the linked
> >  attributes changes that need to be made into a linked list, then
> >  commit them all at once when the transaction commit comes in. 
> > 
> >  3) we changed the vampire and repl code to wrap everything in a
> >  single transaction
> > 
> > The reason for the change is that we discovered cases where we got
> > forward links that pointed at records that don't yet exist. Thus we
> > needed to delay creating the backlinks until after all the DRS
> > operations in a replication cycle have finished. The easiest way to do
> > this was to do it in the transaction commit hook of the
> > linked_attributes module (that was Andrew's idea, and while I was
> > skeptical at first, I've warmed to the idea now!)
> > 
> > We also needed to cope with the situation where a forward attribute is
> > created for a record that is renamed during the replication
> > cycle. That happens during the initial vampire run for the machine
> > account of the samba server, as it moves from OU=Computers to
> > OU=Domain Controlers. The forward linked attributes pointing at this
> > record come across with a DN pointing at the old location. We cope
> > with that by updating the DN using the GUID during the commit phase.
> I like that approach! Thanks!
> The repl_meta_data modules comes before the partition module now, right?
> Then we also catch the case where we have replicated
> CN=configuration,DC=DOMAIN as part of the replication cycle of DC=DOMAIN.

Well, we came across that (and added special code to ensure it is still
replicated...).  Should we store it or not?

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the samba-technical mailing list