[Pkg-openldap-devel] Bug#462667: Bug#462667: slapd: Upgrade fails as LDIF backup has incorrect names

[Steve Langasek]

Hi Jamie,

Thanks for reporting about your upgrade experience.

On Sat, Jan 26, 2008 at 05:42:39PM +0000, Jamie Thompson wrote:
> Setting up slapd (2.4.7-3) ...
>   Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.3.38-1+lenny1... done.
>   Upgrading BDB 'checkpoint' options... .
>   Moving old database directories to /var/backups:
>   - directory dc=.... done.
>   Loading from /var/backups/slapd-2.3.38-1+lenny1:
>   - directory dc=.... failed.

> Loading the database from the LDIF dump failed with the following
> error while running slapadd:
>     slapadd: line 1: database (dc=.) not configured to hold "dc=jamie-thompson,dc=co,dc=uk"
>     slapadd: line 1: database (dc=.) not configured to hold "dc=jamie-thompson,dc=co,dc=uk"
> dpkg: error processing slapd (--configure):
>  subprocess post-installation script returned error exit status 1
> Errors were encountered while processing:
>  slapd
> E: Sub-process /usr/bin/dpkg returned an error code (1)

> I looked at the backup LDIF, and as the error says, the backup contains two
> entries at the top of the file with the incorrect names
> "dn: dc=jamie-thompson,dc=co,dc=uk" and "dn: cn=admin,dc=jamie-thompson,dc=co,dc=uk"

> I used to use the above base without the "."  before I altered my configuration a
> year or two ago to support ldapdns usage. I have my old settings in my slapd.conf
> file for reference, abet commented out. Perhaps a rexgx of some sort pulled out the
> wrong settings, as these are above the current ones in my config file.

So this is the behavior we would expect for a directory containing DNs that
aren't below the indicated suffix.  I don't see that there's anything we
could do to automatically fix up such directories that I would consider
safe.

> I'm guessing the old entries still exist in my database which is why they were backed
> up successfully? I don't know, but I thought I shoudl make someone aware that the
> upgrade process is not as robust as it may seem.

Rather, in this case I think it's as robust as is possible given that your
directory contents are such that openldap 2.4 will refuse to work with them.
It's my opinion that the current behavior is not a bug, and that letting the
admin fix up the results manually is the right thing to do.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org