[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Is existing documentation kind of vague?
I actually like 389 a lot and I have used Netscape DS extensively in
managing international telecom networks about 15 years ago. There are
quite many management features that are superior to OpenLDAP still to
this day, but I simply cannot use it anymore because of the lack of
scalability. I know the original Netscape DS devs quite extensively...
-mike
On Fri, Nov 17, 2017 at 8:34 AM, William Brown <wibrown@redhat.com> wrote:
> 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
>