On Mon, 2014-09-22 at 11:22 +0200, thierry bordaz wrote:
> On 09/20/2014 09:39 PM, Nathaniel McCallum wrote:
> > On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote:
> >> Hello Nathaniel,
> >> sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It
> >> looks good but difficult to think to all possible cases.
> >> I think to the following corner case:
> >> The initial entry has ipatokenHOTPcounter=5
> >> ldapmodify..
> >> changetype: modify
> >> add: ipatokenHOTPcounter
> >> ipatokenHOTPcounter: 6
> >> -
> >> replace: ipatokenHOTPcounter
> >> ipatokenHOTPcounter: 7
> >> It translates
> >> add: 6
> >> del: 5
> >> add: 7
> >> This operation will fail because ipatokenHOTPcounter is
> >> single-valued although IMHO it should succeed.
> > No. It should fail. There can only ever be one ipatokenHOTPcounter.
> >> This is a so special operation that is may not really be a
> >> concern.
> > +1
> >> It is important that attribute are single valued. The
> >> replication changelog will replicated MOD/DEL + MOD/ADD for a
> >> MOD/REPL.
> >> That means that if the attributes are updated on several
> >> masters, the number of values can likely increase. Where for
> >> single value it should only keep the most recent value.
> > That is a concern, at least for now. Eventually we won't use replication
> > for this at all. But for now, we will.
> > Here is the problem I foresee. You have two servers: A and B.
> > The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1).
> > Replication is sent to server B.
> > Before the replication is performed on server B, the user authenticates
> > with the next token. This triggers a MOD/DEL(0)+MOD/ADD(2). Replication
> > is sent to server A. This replication will fail because A has a value of
> > 1, not a value of 0.
> > The end result is that there will be different values for
> > ipatokenHOTPcounter on the two different servers. A will have 1 and B
> > will have 2. Once this happens, the replications can never reconcile
> > (this is a big problem). I see two options here, both theoretical.
> The final value (when all updates has been replicated/applied) will rely
> on the timestamp of the operation (CSN). When a CSN is generated on a
> master it is guaranteed that it is greater (more recent) than any known
> CSNs. In your scenario "nothing" can guaranty that the CSN of the
> second update (B) is larger than the CSN of the first update. If CSN(B)
> > CSN(A), the final value will be '2' else it will be '1'.
> When the server B will receive the first update ('1') its current value
> is '2'. So it will reject the update, that may break replication.
> If we decide to not control replicated update and if CSN(A) > CSN(B),
> then the final value will go backward.
The whole point of this plugin is, in a sense, to break replication. CSN
is *not* sufficient to determine valid updates for the
counter/watermark. We don't care what the CSN is, we only care whether
the counter/watermark has increased.
The counter/watermark MUST NEVER decrease.
Please see my new patch here:
> > Option #1 is to hook 389 in a different place: before the mods are
> > performed by after the replication changelog is generated.
> > Alternatively, we could insert a hook after the replication changelog is
> > generated, but before it is sent. We could consolidate the MOD/DEL
> > +MOD/ADD here into a single MOD/REPLACE operation.
> With current replication it would be major change. Update of the
> changelog is done in betxn_postop based on the operations mods.
> > Option #2 is to have some way to translate the MOD/REPLACE(X) into a
> > MOD/DEL(<=X)+MOD/ADD(X).
> I think it is already what the plugin is doing. It retrieves the current
> value from the entry and do a mod/del on this value then a mod/add of
> the new value. (at the condition new_value>current_value).
> My concern is that in your scenario, due to parallel update with several
> new_values we may select an incorrect new_value.
> The 'Dynamic Master proxy' (
> solution looks as a good one.
Synchronous synchronization is the better plan on that page. But this is
a *huge* task. Too big for 4.1.
Freeipa-devel mailing list