[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#6475

> <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.