Re: Is existing documentation kind of vague?

[MJ J <mikedotjackson@gmail.com>]

No matter how you wrap poll() and select(), they will always be poll()
and select() - you will always run loops around an ever increasing
stack of file descriptors while doing I/O. BDB is always going to have
the same old problems... That's what I'm talking about - sacrificing
performance for platform portability (NSPR).

FreeIPA could be multi-tenant i.e.support top-level and subordinate
kerberos realms if it supported a more sensible DIT layout. I know
because I have built such a system (based on OpenLDAP) and deployed it
internationally. Probably the best piece of code to come out of the
project is bind-dyndb-ldap.

On Fri, Nov 17, 2017 at 4:49 AM, William Brown <wibrown@redhat.com> wrote:
> On Thu, 2017-11-16 at 05:54 +0200, MJ J wrote:
>> 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.
>
> It's a lot more scalable depending on which features you
> enable/disable. It won't even be multi-tenant due to the design with
> gssapi/krb.
>
> At the end of the day, the atomic UID/GID alloc in FreeIPA is from the
> DNA plugin from 389-ds-base (which you can multi-instance on a server
> or multi-tentant with many backends). We use a similar method to AD in
> that each master has a pool of ids to alloc from, and they can
> atomically request pools. This prevents the race issues you are
> describing here with openldap.
>
> So that's an option for you, because those race conditions *do* and
> *will* happen, and it will be a bad day for you when they do.
>
>
> Another option is an external IDM system that allocs the uid's and
> feeds them to your LDAP environment instead,
>
> Full disclosure: I'm a core dev of 389 directory server, so that's why
> I'm speaking in this context. Not here to say bad about openldap or try
> to poach you, they are a great project, just want to offer objective
> insight from "the other (dark?) side". :)
>
>>
>> On Wed, Nov 15, 2017 at 11:09 PM, Michael Ströder <michael@stroeder.c
>> om> 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.
>>
>>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
>