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.
