One feature that's still needed in some cases (e.g., using syncrepl to push updates to another slave thru back-ldap) is an updatedn identity with the privilege to write to unmodifiable operational attributes.
I guess this isn't something the Relax control is intended to allow. We can keep using the updatedn but it feels like this is something that should be generalized. E.g. one might want to have a cluster of servers sending updates to each other, with a unique identity for each server, and all of them with privilege to write to operational attributes. I think the updatedn feature captures the idea ("this identity is a DSA") but it just needs to be more flexibly configured.
Howard Chu wrote:
One feature that's still needed in some cases (e.g., using syncrepl to push updates to another slave thru back-ldap) is an updatedn identity with the privilege to write to unmodifiable operational attributes.
I guess this isn't something the Relax control is intended to allow. We can keep using the updatedn but it feels like this is something that should be generalized. E.g. one might want to have a cluster of servers sending updates to each other, with a unique identity for each server, and all of them with privilege to write to operational attributes. I think the updatedn feature captures the idea ("this identity is a DSA") but it just needs to be more flexibly configured.
Makes sense. In principle, slapd should allow any "push" replication mechanism that complies with its requirements in terms of operational attributes to work. Another mechanism, which would require more "pusher"'s modification, would be to use a control that behaves like "rekax", which explicitly indicates a DSA is replicating data.
p.
At 03:42 AM 12/14/2006, Pierangelo Masarati wrote:
Howard Chu wrote:
One feature that's still needed in some cases (e.g., using syncrepl to push updates to another slave thru back-ldap) is an updatedn identity with the privilege to write to unmodifiable operational attributes. I guess this isn't something the Relax control is intended to allow. We can keep using the updatedn but it feels like this is something that should be generalized. E.g. one might want to have a cluster of servers sending updates to each other, with a unique identity for each server, and all of them with privilege to write to operational attributes. I think the updatedn feature captures the idea ("this identity is a DSA") but it just needs to be more flexibly configured.
Makes sense. In principle, slapd should allow any "push" replication mechanism that complies with its requirements in terms of operational attributes to work. Another mechanism, which would require more "pusher"'s modification, would be to use a control that behaves like "rekax", which explicitly indicates a DSA is replicating data.
p.
I had long intended to replace the updatedn mechanism with a control mechanism... but with the deprecation of slurpd didn't see any good reason to take the pain that would be caused by such a change. But with other good reason for such a control, I would be happy to say "good riddance" to the updatedn mechanism.
Kurt
Kurt D. Zeilenga wrote:
At 03:42 AM 12/14/2006, Pierangelo Masarati wrote:
Howard Chu wrote:
One feature that's still needed in some cases (e.g., using syncrepl to push updates to another slave thru back-ldap) is an updatedn identity with the privilege to write to unmodifiable operational attributes. I guess this isn't something the Relax control is intended to allow. We can keep using the updatedn but it feels like this is something that should be generalized. E.g. one might want to have a cluster of servers sending updates to each other, with a unique identity for each server, and all of them with privilege to write to operational attributes. I think the updatedn feature captures the idea ("this identity is a DSA") but it just needs to be more flexibly configured.
Makes sense. In principle, slapd should allow any "push" replication mechanism that complies with its requirements in terms of operational attributes to work. Another mechanism, which would require more "pusher"'s modification, would be to use a control that behaves like "rekax", which explicitly indicates a DSA is replicating data.
I had long intended to replace the updatedn mechanism with a control mechanism... but with the deprecation of slurpd didn't see any good reason to take the pain that would be caused by such a change. But with other good reason for such a control, I would be happy to say "good riddance" to the updatedn mechanism.
The new mechanism wouldn't behave a whole lot differently... If we were to make this a control I would only define it for Bind operations, thus identifying an entire session to be a server-to-server interaction. It doesn't make sense to me to attach such a control on a per-operation basis. But once we've established that the peer is a server, we can simplify a lot of other checks. (E.g., set a boolean in the Connection structure, instead of having to compare DNs all the time.) This would give us the freedom to do a bit more along the lines of X.500 DSP without the ambiguity that the current chaining/proxyauth/etc. approaches suffer from.
At 08:36 AM 12/14/2006, Howard Chu wrote:
The new mechanism wouldn't behave a whole lot differently... If we were to make this a control I would only define it for Bind operations, thus identifying an entire session to be a server-to-server interaction.
I would hesitate a bit on making this a bind control. First, bind controls are not protected by the Bind's authentication mechanism. Second, there are likely cases where a client was to act as a DSA and act as a client. Adding a simple control (no control data) doesn't add much overhead...
It doesn't make sense to me to attach such a control on a per-operation basis. But once we've established that the peer is a server, we can simplify a lot of other checks. (E.g., set a boolean in the Connection structure, instead of having to compare DNs all the time.)
We, of course, could do this with updatedn. That is, check the authzDN after the bind completes and set a flag (and clear it in connection2anonymous()).
This would give us the freedom to do a bit more along the lines of X.500 DSP without the ambiguity that the current chaining/proxyauth/etc. approaches suffer from.
-
Howard Chu -
Kurt D. Zeilenga -
Pierangelo Masarati