Re: Is existing documentation kind of vague?

[MJ J <mikedotjackson@gmail.com>]

Sure, it can be improved to become invulnerable to the academically
imaginative race conditions that are not going to happen in real life.
That will go to the very bottom of my list of things to do now,
thanks.

FreeIPA is a cool concept, too bad it's not scalable or multi-tenant capable.

On Wed, Nov 15, 2017 at 11:09 PM, Michael Ströder <michael@stroeder.com> wrote:
> MJ J wrote:
>> TLDR; in a split-brain situation, you could run into trouble. But this
>> isn't the only place. Efffective systems monitoring is the key here.
>>
>> Long answer;
>> [..]
>> The solution I posted has been in production in a large, dynamic
>> company for several years and never encountered a problem.
>
> Maybe it works for you. But I still don't understand why you post such a
> lengthy justification insisting on your MOD_INCREMENT / read-after-write
> approach with possible race condition even in a single master deployment
> while there are two proper solutions with just a few lines code more:
>
> 1. delete-by-value to provoke a conflict like the original poster
> mentioned by pointing to
> http://www.rexconsulting.net/ldap-protocol-uidNumber.html
>
> 2. MOD_INCREMENT with pre-read control
>
> Of course none of the solutions work when hitting multiple providers
> hard in a MMR setup or in a split-brain situation. One has to choose a
> "primary" provider then.
> BTW: AFAIK with FreeIPA each provider has its own ID range to prevent that.
>
> Ciao, Michael.