[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Is existing documentation kind of vague?

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 ;-)

On Sun, Nov 19, 2017 at 8:28 PM, Howard Chu <hyc@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@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
>>>
>>
>>
>
>
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/