[Pkg-openldap-devel] Bug#770827: slapd: can't reconfigure dumping

[Ferenc Wagner]

Ryan Tandy <ryan at nardis.ca> writes:

>> Trying to upgrade with DEBIAN_PRIORITY=medium does not work either
>> due to another problem: I can switch off dumping then, and dumping is
>> skipped all right, but the reload is attempted regardless and fails
>> not finding the dump.
>
> That's a bug, for sure. dump_databases() exits early if dumping is
> disabled, but the symmetric check in load_databases() is missing. That
> doesn't make a lot of sense. :)

I built a package with this change:

* Do not try to restore the databases if we did not dump them.
  Do not even move the old ones away: our current format change
  logic works with BDB and HDB only, slapd will continue to work
  with the other formats across upgrades.  (Closes: #771823)

--- a/debian/slapd.postinst
+++ b/debian/slapd.postinst
@@ -30,11 +30,11 @@ postinst_upgrade_configuration() {                                  # {{{
        echo -n "  Backing up $SLAPD_CONF in `database_dumping_destdir`... " >&2
        backup_config_once
        echo done. >&2
 
        # Check if the database format has changed.
-       if database_format_changed; then
+       if database_format_changed && database_dumping_enabled; then
 
                # During upgrading we have to load the old data
                move_incompatible_databases_away
                load_databases
        fi

During a wheezy -> jessie upgrade test with slapd/dump_database: never,
it correctly skipped loading of my (MDB) database.  But slapd did not
start:

mdb_db_open: database "...": DN index needs upgrade, run "slapindex entryDN"

http://brylov.info/2013/03/zimbra-8-0-2-8-0-3-update-failure led me to
http://www.openldap.org/lists/openldap-announce/201303/msg00000.html,
which explains the issue (DN index format change) and the solution.

So MDB also needs some care during dist-upgrade.  The above simple fix
seems to achieve its aim, but is no substitute for fixing #614569.
However, running slapindex may be much more feasible than a full
dump/restore on a big database, so it still has some value.
-- 
Regards,
Feri.