[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Modrdn replication
At 06:42 AM 1/20/2007, Pierangelo Masarati wrote:
>ITS#4809 reports that when replicating modrdn via slurpd, operational
>attributes don't get replicated. This appears to be intrinsically
>caused by the definition of the modrdn operation, which, unlike the
>modify and add operations, doesn't contemplate the possibility to
>add/modify attributes other than the naming ones. So add/modify can be
>easily exploited for replication by adding/modifying the write-related
>operational attributes during replication, while modrdn can't.
>
>Assuming there's any intention to fix slurpd replication until slurpd is
>dismissed, we need to find a means to attach modification of
>write-related operational attributes to a modrdn operation, to
>complement the modrdn operation itself.
>
>The proposed solution consists in explicitly modifying the necessary
>(operational) attributes by means of an additional modify operation that
>is attached to modrdn. This may be occasionally useful regardless of
>slurpd replication, which makes it more appealing for OpenLDAP
>developers, so that the required effort wouldn't be just wasted by
>slurpd dismissal.
>
>The additional modify could be wrapped into a control's value, and that
>control might be the "relax" control itself,
I suggest a new control for this new function.
>so that the original
>operation, augmented by the optional modify, would need to succeed as a
>whole or abort, extending the capabilities of the "relax" control by
>allowing extra modifications to be added, in order to preserve the
>integrity of the object after the operation.
>
>Comments? p.