> > 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
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
> > down. I understand this is to prevent replaying the same OTP on
> > 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.