[prev in list] [next in list] [prev in thread] [next in thread]
List: openldap-technical
Subject: Re: Is existing documentation kind of vague?
From: Howard Chu <hyc () symas ! com>
Date: 2017-11-19 18:53:16
Message-ID: 06c09639-3092-1e2e-4e91-24310da2a73c () symas ! com
[Download RAW message or body]
MJ J wrote:
> Certainly, I will make a better list tomorrow or so and send them to
> you. Generally, it relates to the areas of cn=config which are not
> runtime configurable and the lack of inline ACLs being first-class
> citizens.
>
> Basically, I feel that anything which is exposed via cn=config should
> not require an offline slapadd in order to take effect. These are not
> really huge problems for LDAP experts, but quite challenging when
> trying to train a bit less skilled people to handle operations. A
> detailed list of cn=config params which can and cannot be modified
> during runtime would help matters greatly, instead of the current
> situation of knowledge via trial and error ;-)
The intention has always been 100% runtime modifiable. Any that aren't should
be considered as bugs in 2.5.
> On Sun, Nov 19, 2017 at 8:28 PM, Howard Chu <hyc(a)symas.com> wrote:
>> MJ J wrote:
>>>
>>> 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...
>>
>>
>> There are certainly some obvious deficiences remaining in cn=config, and
>> we're working on addressing as many as possible for 2.5. But I'd be curious
>> to see your list of issues.
>>
>>
>>>
>>> -mike
>>>
>>> On Fri, Nov 17, 2017 at 8:34 AM, William Brown <wibrown(a)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(a)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(a)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
>>>>
>>>
>>>
>>
>>
>> --
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic