On Fri, 2017-11-17 at 08:27 +0200, MJ J wrote:
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.
Whoa mate - I'm not here to claim that 389 is a better ldap server - we
just do some different things. We acknowledge our limitations and are
really working on them and paying down our tech debt. We want to remove
parts of nspr, replace bdb and more. :)
I'm here to follow the progress of the openldap project, who have a
team of people I respect greatly and want to learn from, and here to
help discussions and provide input from a different perspective.
There are things that today openldap does much better than us for
certain - and there are also some things that we do differently too
like DNA plugin uid allocation, replication etc,
There are also project focusses and decisions made to improve
supportability in systems like FreeIPA - we can discuss them forever,
but reality is today, FreeIPA is not targeting multi-tennant
environments because the majority of our consumers don't want that
functionality. We made a design decision and have to live with it. I'm
providing this information to help give the ability for people to
construct an informed opinion.
As mentioned, I'm not here to throw insults and criticisms, I'm here to
have positive, respectful discussions about technology, to provide
different ideas, and to learn from others :)
Thanks,
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@stroed
er.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
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane