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 <h...@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 <wibr...@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 <wibr...@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/