[Pkg-openldap-devel] Bug#742862: Bug#742862: upgrade to 2.4.39-1 breaks slapd

[Ryan Tandy]

I accidentally dropped the bug from Cc. Restoring it, and including
the lost messages.

On Mon, Mar 31, 2014 at 12:16 AM, Erwan David <erwan at rail.eu.org> wrote:
> On Sat, Mar 29, 2014 at 12:31:13AM CET, Ryan Tandy <ryan at nardis.ca> said:
>> On Fri, Mar 28, 2014 at 2:14 PM, Erwan David <erwan at rail.eu.org> wrote:
>> > Hi, find attached the configuration (with passwords removed).
>>
>> That looks fine to me, and just now I successfully upgraded a system
>> from wheezy to sid (2.4.31->2.4.39) with that configuration and some
>> random data.
>>
>> > The /var/lib/ldap which did not wok is indeed owned by root, not by
>> > openldap (I just did a mv ldap ldap-broken before restoring from backups).
>>
>> Unusual permissions on /var/lib/ldap/alock would explain your original
>> error message (reproducible just by "chown root /var/lib/ldap/alock"
>> on a working system), but the upgrade script is supposed to fix the
>> database permissions, using SLAPD_USER and SLAPD_GROUP from
>> /etc/default/slapd, after restoring the database from backup (look for
>> "chowning database directory" in apt's term.log to verify that). There
>> are other possibilities too, but again I'm surprised that this
>> appeared when a new database had just been created from the old data.
>>
>> You said you restored your backup and reverted to 2.4.31; if you
>> upgrade to 2.4.39 again does it break the same way? Any other clues?
>>
>> As far as your particular case, I think deleting /var/lib/ldap/alock
>> and trying again to start slapd should allow it to start, assuming
>> everything else is in order; but I'm curious how this happened.
>>
>
> Before I try again, here is what I found in /var/log/apt/term.log (I
> did not kow it existed before-hand). It seems there was an error
> before the alock problem (and maybe that's why the files where not changed to openldap:openldap).
>
>
> Setting up slapd (2.4.39-1) ...
> Installing new version of config file /etc/ldap/schema/inetorgperson.ldif ...
> Installing new version of config file /etc/ldap/schema/dyngroup.schema ...
> Installing new version of config file /etc/ldap/schema/README ...
> Installing new version of config file /etc/ldap/schema/misc.ldif ...
> Installing new version of config file /etc/ldap/schema/openldap.schema ...
> Installing new version of config file /etc/ldap/schema/pmi.schema ...
> Installing new version of config file /etc/ldap/schema/duaconf.schema ...
> Installing new version of config file /etc/ldap/schema/collective.ldif ...
> Installing new version of config file /etc/ldap/schema/nis.ldif ...
> Installing new version of config file /etc/ldap/schema/inetorgperson.schema ...
> Installing new version of config file /etc/ldap/schema/core.schema ...
> Installing new version of config file /etc/ldap/schema/corba.ldif ...
> Installing new version of config file /etc/ldap/schema/core.ldif ...
> Installing new version of config file /etc/ldap/schema/java.ldif ...
> Installing new version of config file /etc/ldap/schema/cosine.ldif ...
> Installing new version of config file /etc/ldap/schema/openldap.ldif ...
> Installing new version of config file /etc/ldap/schema/misc.schema ...
> Installing new version of config file /etc/ldap/schema/nis.schema ...
> Installing new version of config file /etc/ldap/schema/ppolicy.ldif ...
> Installing new version of config file /etc/ldap/schema/dyngroup.ldif ...
> Installing new version of config file /etc/ldap/schema/pmi.ldif ...
> Installing new version of config file /etc/ldap/schema/duaconf.ldif ...
>   Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.31-1+nmu2+b1... done.
>   Moving old database directories to /var/backups:
>   Loading from /var/backups/slapd-2.4.31-1+nmu2+b1:
>   - directory dc=rail,dc=eu,dc=org... failed.
>
> Loading the database from the LDIF dump failed with the following
> error while running slapadd:
>     BDB1538 Program version 5.3 doesn't match environment version 5.1
>     BDB1538 Program version 5.3 doesn't match environment version 5.1
>     53351d1f => hdb_tool_entry_put: id2entry_add failed: BDB0067 DB_KEYEXIST: Key/data pair already exists (-30994)
>     slapadd: could not add entry dn="dc=rail,dc=eu,dc=org" (line=1): id2entry_add failed: BDB0067 DB_KEYEXIST: Key/data pair already exists (-30994)
> dpkg: error processing package slapd (--configure):
>  subprocess installed post-installation script returned error exit status 1

That BDB error is the cause of your upgrade failing; after this it's
certainly in an inconsistent state. The old (BDB 5.1) databases were
supposed to be moved away in the previous step and the slapadd should
create a new (BDB 5.3) database in an empty /var/lib/ldap, but in your
log, no directories are listed in the "Moving old database
directories" step so the old database files are still there.

So I'd still like to know whether you can reproduce the upgrade
failure, and I'd also like to know the result of this command at the
time of the upgrade (maybe after restoring your backup, but before
upgrading): grep olcSuffix
/etc/ldap/slapd.d/cn\=config/olcDatabase*.ldif

Might also be relevant: did you ever edit the files under
/etc/ldap/slapd.d by hand, ie. with a text editor or script?