Package: slapd Version: 2.4.40-2 Severity: normal Hi, I wanted to manually set dumping to "never" before upgrading, because restoring the dump breaks on partial replicas (#614569). However, dpkg-reconfigure slapd only asks if I want to "omit OpenLDAP server configuration", which I want, because the replication config is hand made. Thus I don't get to reconfigure dumping, even though it has nothing to do with the server configuration itself. 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. On the other hand, I could be saved by a little additional logic. #759597 may be hard in general, but I use MDB, which does not need a dump/restore below 2.5, which translates to never in Debian. :)
Control: tags -1 confirmed If I'm reading correctly, the value of that choice isn't actually important here: the problem is that the question about configuring dumping is only presented on upgrade, not when (re)configuring a new or existing installation. http://anonscm.debian.org/cgit/pkg-openldap/openldap.git/tree/debian/slapd.config#n174 IMO, the dumping questions could be asked outside of that guard, even on initial installation (and certainly on reconfiguration), with a low priority. 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. :)
Ryan Tandy <ryan@nardis.ca> writes: Agreed. Also agreed. Now, do you plan to do anything about these for jessie? As I understand it, anybody running a partial replica will necessarily hit this during the wheezy -> jessie upgrade. But we've still got a couple of days to get an unblock for these fixes...
Control: clone 770827 -2 Control: retitle -2 slapd: tries to reload on upgrade even with dumping disabled Control: severity 614569 important Just to be clear, we're talking about (at least) three separate bugs: #614569 - fails to reload a partial replica #770827 - dpkg-reconfigure doesn't ask the dumping question #??? - attempts database reload even with dumping set to 'never' #770827 I think is clearly not RC. #614569 would have been good to fix for jessie, but I personally have basically no time available at the moment. I can't provide a well-tested fix before the 5th, sorry. Other facts about #614569 are that it has been around for two upgrade cycles already, and that it can be worked around by editing the postinst to add -s to the slapadd invocation and running 'dpkg --configure -a' to retry the upgrade. Unless someone else wants to prepare and upload a fix in the next couple of days, I'll fix it in unstable later and then propose it for a point release of jessie. I'm also monitoring some lmdb issues being worked on upstream, in case some of the patches turn out to be suitable for a point release. I doubt this was the answer you hoped for; sorry for that. thanks, Ryan
Ryan Tandy <ryan@nardis.ca> writes: Precisely. Thanks for setting this up! Well, you can work around it by debconf-set-selections I guess... If #771823 didn't spoil it, this could be the recommended workaround for upgrades of partial MDB replicas. I'm inclined to simply add that -s option. If the database was schema- correct, it will stay so, and it it wasn't, then upgrade isn't the best time to point that out. There isn't much to test on such a change. To do any better, you'd need separate dumping decisions on each configured database, which would be nice (ATM only BDB and HDB need this, after all) but that may be too much for a last-minute change. I'm willing to work on this if we can agree on the direction. I'll have to upgrade my servers somehow, doing it offically can't hurt... That's what I did. Not exactly the expected Debian upgrade experience. :( That's good to hear. Sure it was, really! Unfortunately, I can't upload, so a sponsor would be needed to conclude this. Also, do you think some pre-agreement from the release team would be needed before the upload?
Ryan Tandy <ryan@nardis.ca> writes: 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.
Yikes! I didn't know about that. I was under the impression (e.g. [1]) that mdb databases could be upgraded from/to any 2.4.x version without issues. Thanks for bringing it up! Ironically, since #759597 isn't fixed yet this should not be an issue for the jessie upgrade; but if we try again at backporting to wheezy we should make sure it's accounted for (maybe just reverting my change to avoid the dump/reload). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750022#10 thanks, Ryan
...and come to think of it, how did I manage to hit that when I was testing that backport? Will have to check that again.
Reproduced when upgrading an mdb database from 2.4.31 to 2.4.40 without reloading. I guess I forgot to test mdb before and only covered bdb/hdb. I don't want to try introducing separate logic for reindexing vs reloading, just for a backport. I'll revert the change that allowed skipping the dump/reload.