Automatic openldap db migration fails on release upgrade when using nested database directories

[Dave Jones]

While attempting to perform an upgrade of my home server from Ubuntu 12.04 to Ubuntu 14.04, I received the following error:

===================================================================================
Error in function:

A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade has aborted.
Your original sources.list was saved in
/etc/apt/sources.list.distUpgrade.

SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)

Could not install the upgrades

The upgrade has aborted. Your system could be in an unusable state. A
recovery will run now (dpkg --configure -a).

Setting up slapd (2.4.31-1+nmu2ubuntu8.2) ...
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.28-1.1ubuntu4.6... done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.4.28-1.1ubuntu4.6:
  - directory dc=waveform,dc=org,dc=uk... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
    572f946e olcDbDirectory: value #0: invalid path: No such file or directory
    572f946e config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: value #0: invalid path: No such file or directory
    slapadd: bad configuration directory!
dpkg: error processing package slapd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 slapd

Upgrade complete

The upgrade has completed but there were errors during the upgrade
process.
===================================================================================

Admittedly, it's rather strange for a home server to use LDAP for authentication but I don't have a terribly complex setup: openldap with a fairly normal LDAP layout and SSSD for handling the PAM interface (no kerberos - I did try it in the past but quickly gave it up as too complex to maintain). Hence, I was rather expecting the upgrade to be relatively smooth (as much as server upgrades ever are :).

As requested in the message I'm attaching /var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log

[Dave Jones (waveform)]

After a bit of playing around, it appears the root cause was that I'm using the accesslog overlay which necessitates having another database under /var/lib/ldap/accesslog. The migration process backed up everything under /var/lib/ldap to /var/backups then re-created /var/lib/ldap - but didn't created the "accesslog" directory under it. As a result the attempt to restore the database (presumably with slapadd) failed. After I recreated the /var/lib/ldap/accesslog directory (with appropriate ownership of openldap:openldap), the database restored successfully.

[Dave Jones (waveform)]

I should add: I think the accesslog overlay is implicit in replicated setups (yes, I know, weird enough that a home server's using LDAP, but replication too?! I originally set it up to learn about LDAP replication in order to use it at work :). It seems to be used to ease the burden of change queries from downstream servers - hence I'm guessing this bug will apply particularly to openldap installations using syncrepl.

[Ryan Tandy (rtandy)]

Thanks for the report. This is most likely bug 1003854, triggered in this case by having /var/lib/ldap/accesslog nested inside /var/lib/ldap.

[Dave Jones (waveform)]

Ah, you're absolutely right - that looks like it. Sorry for the duplicate (don't know why I didn't find that report first)!