Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node

[hyc@symas.com]

masarati@aero.polimi.it wrote:
>
>> It's not clear to me where the issue is.  What is the "right" sequence the
>> add of the new superior and the mordrdn should be transmitted?  Should the
>> provider operate differently, or should the consumer check all syncrepl
>> messages and try to rebuild the final state, instead of giving up when the
>> internal lookup for the newsuperior fails?  Probably, a workaround could
>> be to perform the modrdn by crating the new superior as a glue object,
>> which eventually will be replaced by the actual add.
>
> I've quickly hacked things this way, and it seems to work fine.
>
> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.1.patch>
>
> Please let me know if this approach is sound enough, I might have
> overlooked some implications.

Patch looks good, solution makes sense. This is one of the reasons we would 
expect glue entries to be used.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/