masarati@aero.polimi.it wrote:

...

...

access to * attrs=cmusaslsecretOTP by dn.regex="cn=replica,o=test" write stop by * break

This is orthogonal to the sasl auxprops discussion. It's a matter of well-configuring the authorizing identity in slapo-chain(5).

I pointed it here for future reference because this is an unusual case. I suspect everyone configure replicas with universal read-only access. For this to work, replica must also have write access to cmusaslsecretOTP.

Well, if a shadow uses slapo-chain(5), the producer must be configured in order to allow writes coming from the shadow.

...

...

Another point: bind on the replica is impossible when the master is down. I understand this is to prevent replaying the same OTP on

multiple

...

replicas, but that defeats the purpose of setting up replicas for fail over.

This was clearly pointed out at the beginning of the discussion. You can't have both, it should be clear.

Yes, I understand that.

...

Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is used, OTP breaks. If it is acceptable to have it broken, we can remove the hardcoding, and let admins decide whether they prefer fail-over over consistency. I'd have no doubt, and favor consistency.

When you tell about using the shadow copy, the modification will still be sent to the master, right?

Not in the original code. In that case, the modification was bypassing replication, thus it was being applied to the shadow without generating a referral. The alternative, inconsistent solution you seem to indicate would require to replay the modification as internal in case the modification to the producer failed because the service was not available.

Such a behavior allows replays attacks within the modification propagation time frame, but it ensures that bind are still possible when then master is down. I think it could be interesting to have a configuration setting for that.

We should bring this to -devel, to see whether it makes sense and whether it would be acceptable.

p.