Quanah Gibson-Mount wrote:--On Friday, September 15, 2017 7:57 PM +0200 Michael Ströder <michael@stroeder.com> wrote:I strongly disagree. It's a schema shipped by OpenLDAP installation. So this update should have simply worked.Since the schema is stored in the cn=config DB, there's not an option to replace the ppolicy LDIF in cn=config on upgrade. It has to be scripted.I fully understand the technical reason for what went wrong. But the sysadmin should not be required to script anything in case a schema file always shipped by OpenLDAP was updated by a regular OpenLDAP update. It should simply work like it does with other LDAP server implementations and cn=config.
The OpenLDAP project only provides one thing -- Source code. So no, the sysadmin is actually responsible for ensuring upgrade procedures between versions work for their deployment. If they are using a build of OpenLDAP provided by their OS vendor, then the OS vendor is going to be responsible. However, it is non-trivial for the OS vendor to be aware of what configuration(s) a given end-user is using, and whether or not they are affected by any specific change.
Again why I think this particular change should not have gone into RE24. It was a significant breaking change that is non-trivial for end users to deal with. We generally keep such things out of RE24. There are many great logging updates in RE25 for example that can be incredibly helpful for people on RE24 (operation duration, TLS cipher suite logging, etc), but we don't pull them in as it could break tools that depend on the existing 2.4 format.
--Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>