On 8/5/21 3:39 PM, Philipp Wagner wrote:
On 05.08.21 08:38, Andreas Vögele wrote:
This change in OpenLDAP 2.5 is scary as it affects most users who run slapd:
"Due to database format changes between OpenLDAP 2.4 and OpenLDAP 2.5 it is mandatory for existing slapd-mdb(5) databases to be exported via an OpenLDAP 2.4 slapcat prior to upgrade. They must then be reloaded via an OpenLDAP 2.5 slapadd after the binaries are updated."
I think that OpenLDAP 2.4 cannot be replaced by version 2.5. There have to be packages for both versions. At least a statically linked slapcat from version 2.4 has to be provided.
Good point, but I'm not sure what the solution is. To widen the question a bit: What do we do in Tumbleweed generally in a case where an update requires manual intervention from the user? (In this case *before* the update is actually performed.) 1. Somehow notify the user before doing the update, and giving them a choice to not do the upgrade and e.g. pin the old version.
And then what? If you want to satisfy users who run OpenLDAP's slapd but do not know how to administrate it you're stuck.
2. Buy us time by providing two versions of the same software.
Strictly speaking this would require multiple distinct config, run-time and database directories. Who is going to do the work?
3. Try to come up with a automatic migration solution downstream (in this case, dump the db and try to re-import it).
This can fail in the middle. And then what?
4. Simply do the upgrade and assume users will somehow deal with it (e.g. under the assumption that "this is Tumbleweed").
I think simply dumping databases during de-installation of 2.4 is the only viable solution. But it's tricky to find out how many relevant DBs are there. Anyone caring about availability has more than one replica in place and updates, fully resets and restarts one of the other. That's how I plan to do it. But I guess the average admin is not prepared for that. Ciao, Michael.