Re: (ITS#4809) Replication of operational attributes when performing modrdn operation

[ando@sys-net.it]

Apparently, according to slurpd's replog, no operational attrs are
modified on modrdn.  In fact, modrdn is replicated as a plain modrdn,
which does not alter the write-related operational attrs (nor it is
allowed to, according to LDIF, as per RFC 2849).  Rep-logging an
additional modify that only changes the write-related operational attrs
could fix the problem, at the cost of not making it atomical.  A
"cleaner" solution would be to wrap a modify with a control that gets
added to the modrdn operation by slurpd, which modifies modifiersName,
modifyTimestamp and entryCSN using the "relax" control.  Or, the (yet
unpublished) "relax" control could be redefined to allow an optional
control value that contains a modification required to maintain
consistency of the final entry, or something like that.

This definitely needs investigation, but it could be considered yet
another reason for dropping slurpd.

p.