linked attributes, DRS and abusing the ldb modules API

[Stefan (metze) Metzmacher]

Andrew Bartlett schrieb:
> On Wed, 2009-09-02 at 11:14 +0200, Stefan (metze) Metzmacher wrote:
>> tridge at samba.org 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, bu=
t
>>> it looks easy to extend to the higher functional levels (we plan to d=
o
>>> 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.=20
>>>
>>>  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 d=
o
>>> 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 i=
s
>>> 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=3DComputers to
>>> OU=3DDomain Controlers. The forward linked attributes pointing at thi=
s
>>> 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, righ=
t?
>> Then we also catch the case where we have replicated
>> CN=3Dconfiguration,DC=3DDOMAIN as part of the replication cycle of DC=3D=
DOMAIN.
>=20
> Well, we came across that (and added special code to ensure it is still=

> replicated...).  Should we store it or not?

I don't understand that question...
where is that special code?

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/20090902/9038ce74/attachment.pgp>