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@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/