[Pkg-openldap-devel] Bug#595672: Upgrading slapd from 2.4.17-2.1 to 2.4.23-4 can fail due to database issues

[Jamie Thompson]

On 2010-09-05 10:11 PM, Steve Langasek wrote:
> It may be that we want the slapd.d migration to call slaptest with -u, to
> ignore any such problems that aren't related to the slapd.d migration per
> se.  But I don't understand the origin of this error either, so we should
> get to the bottom of this.  What was the location of this log.0000000026
> that you had to delete?  The log clearly shows a dump and restore of the
> databases, so there should not have been any remaining files from db4.7
> present there.

I only have the one directory in OpenLDAP, "dc=." (I run my DNS out of
this directory, and this serves as a root between
"dc=in-addr,dc=arpa,dc=." and my other roots, like "dc=co,dc=uk,dc=.").

Anyway, the log file was in "/var/lib/ldap/", where I had/have my index
bdb files, 26 of those log files, "alock", and "DB_CONFIG".

I seem to recall trying to fiddle with DB_CONFIG a long time ago, the
only uncommented settings in the file are:
> set_cachesize   0       2097152         0
> set_lg_bsize    524288
> set_lk_max_objects      5000
> set_lk_max_locks        5000
> set_lk_max_lockers      5000

> Can you attach a copy of /var/backups/slapd-2.4.17-2.1/slapd.conf (sanitized
> to remove any sensitive information, of course)?  Specifically, I would like
> to see the database/suffix/directory configs from this file, but the more
> context you can provide the more likely this will be reproducible.  The
> directory slaptest complains about, 'dc=.', doesn't appear to match the
> information in the debconf settings for the package.

See attached.

> Is there any chance that the old slapd process was still running and writing
> to this directory while the upgrade was under way?  That would explain files
> appearing in a location that was supposed to have been cleaned out shortly
> before.

I can confirm slapd was *not* running when I tried recovering the
databases, though it still complained about the environment being that
of 4.7. As for during the upgrade, I cannot say. I left it running in a
SSH session whilst attending to something else, and when I came back
everything had gone to pot and I'd lost network connectivity (DHCP lease
has expired and my DHCP config is pulled from the directory).

> Actually, looking more closely, there appear to be several lines missing
> from your upgrade log.  The expected output looks like:
> 
>   Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.11-1... done.
>   Moving old database directories to /var/backups:
>   - directory dc=dodds,dc=net... done.
>   Loading from /var/backups/slapd-2.4.11-1: 
>   - directory dc=dodds,dc=net... done.
>   - chowning database directory (openldap:openldap)... done
>   Migrating slapd.conf to slapd.d configuration style... done.
> 
> I.e., a line of output for each directory that's backed up and restored. 
> Have you edited the output from the upgrade log to conceal details, or has
> it really not done anything with your directories here?  The slapd.conf
> should help us answer this.

I copied the output from the SSH session verbatim and pasted it into the
bug report. I was upgrading other packages at the same time, but they
all succeeded. The closest thing to editing it was that I looked for the
start of slapd, and only copied from there to the start of the next package.

There is nothing in the backup directory other than "slapd.conf".

I suppose particular relevance for the other packages might be:
> 2010-09-05 16:49:41 upgrade libdb4.8 4.8.26-1 4.8.30-2
> 2010-09-05 16:51:46 upgrade db4.8-util 4.8.26-1 4.8.30-2
...but as you can see, I already had DB 4.8 installed, so I doubt this
was the problem. Unfortunately, I lost the rest of the log as my
workstation died after I filed the bug, so I have lost that terminal
log, annoyingly.

- Jamie
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sanitised-slapd.conf
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20100905/8d843da1/attachment.txt>