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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature