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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
