--On Friday, September 15, 2017 8:49 PM +0200 Michael Ströder michael@stroeder.com wrote:
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
Quanah Gibson-Mount wrote:
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.
Standard schema files are shipped with the source and installed with make install. slapd should simply work after make install when these schema files are used.
If they are using a build of OpenLDAP provided by their OS vendor, then the OS vendor is going to be responsible.
Nope. IMO the OS vendor should rather keep out of config things after "make install".
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.
Yes, and even the sysadmin easily runs into an operational dead-end where there's no fix except violating what's considered best practice here.
Please have a look at other LDAP server implementations with dynamic config: They get this particular aspect of shipping and using schema LDIF files right.
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.
This change led to a non-trivial breakage because the back-config concepts and best practices have serious deficiencies.
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.
Hmmpf. Why not provide something similar to Apache httpd's LogFormat directive with the old slapd log format being the default?
Ciao, Michael.
(For the record, I agree with most of your points; and I personally would be more satisfied with slapd.conf and reloading it on SIGHUP than I am with cn=config.)
On Fri, Sep 15, 2017 at 08:12:04PM +0200, Michael Ströder wrote:
Standard schema files are shipped with the source and installed with make install. slapd should simply work after make install when these schema files are used.
There was some talk, either in IRC or on -devel, of creating a way for cn=config to reference schema files (possibly LDIF) on disk rather than importing them into the config database. I think that would be an improvement. Importing schemas into cn=config is cool - especially if you want to replicate the config - but I'm not sure it's a good default.
The fact that we install schema files (LDIF and otherwise) and then never refer to them again after the initial configuration is definitely one of the ways we violate expectations of experienced sysadmins who are new to OpenLDAP.
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy