--On Friday, September 15, 2017 8:49 PM +0200 Michael Ströder
<[email protected]> wrote:
Quanah Gibson-Mount wrote:
--On Friday, September 15, 2017 7:57 PM +0200 Michael Ströder
<[email protected]> 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>
