[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Is existing documentation kind of vague?
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