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, 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.
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.
Kurt D. Zeilenga wrote:
At 06:42 AM 1/20/2007, Pierangelo Masarati wrote:
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.
It sounds like it would only ever be useful for modrdn operations, and would only ever be used by a slurpd-style replicator.
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.
The perceived problem isn't a problem with syncrepl, and I don't see a compelling general use case for this.
Howard Chu wrote:
The perceived problem isn't a problem with syncrepl, and I don't see a compelling general use case for this.
Hm, I take this back. If we're pushing syncrepl through a proxy, the proxy could use this control. Though it may not matter much if no other servers implement the control...
Howard Chu wrote:
The perceived problem isn't a problem with syncrepl, and I don't see a compelling general use case for this.
Hm, I take this back. If we're pushing syncrepl through a proxy, the proxy could use this control. Though it may not matter much if no other servers implement the control...
Honestly, I also think this might be of very little use; from a theoretical point of view, any replication or otherwise push synchronization could just send the user's data as is, and wrap DSA specific data in that control, but it would sort of being a waste of resources, except for modrdn. Another approach, which came to mind right after posting my previous message, is that we could simply add a modify and wrap everything with a transaction... when available, of course!
p.
-
Howard Chu -
Kurt D. Zeilenga -
Pierangelo Masarati