[Pkg-openldap-devel] Bug#594821: slapd upgrade may fail on subordinate databases

[Peter Marschall]

Package: slapd
Version: 2.4.23-4
Severity: normal
Tags: patch sid

Hi,

another day, another system, another bug ;-(

Upgrading slapd to 2.4.23-4 fails on subordinate databases

Error message
-------------
(Reading database ... 246653 files and directories currently installed.)
Preparing to replace slapd 2.4.23-4 (using slapd_2.4.23-4_i386.deb) ...
Stopping OpenLDAP: slapd                                                                   [   OK   ]
Unpacking replacement slapd ...
Setting up slapd (2.4.23-4) ...
  Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.23-3... done.
  Moving old database directories to /var/backups:
  - directory o=EDV... done.
  - directory o=ADPM,c=DE... done.
  - directory c=DE... done.
  Loading from /var/backups/slapd-2.4.23-3: 
  - directory o=EDV... done.
  - chowning database directory (openldap:openldap)... done
  - directory o=ADPM,c=DE... done.
  - chowning database directory (openldap:openldap)... done
  - directory c=DE... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
    => hdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995)
    slapadd: could not add entry dn="o=adpm,c=de" (line=28006): id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995)
    Segmentation fault
dpkg: error processing slapd (--install):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db ...
Errors were encountered while processing:
 slapd


The important thing to know is that the databas o=ADPM,c=DE is a subordinate
of the database c=DE.

I.e. searches starting with a base c=DE also return results from o=ADPM,c=DE.
This is also true for slapcat, so that the backup of c=DE contains also the
entries from o=ADPM,c=DE.
When trying to restore the 2nd of these databases this is bound to fail
with the error message above.

Fortunately slapcat & slapadd offer the "-g" switch to disable subordinate
glueing. As this option does not have negative effects on non-glued databases,
it can IMHO be safely set as default.

The attached patch does exactly this.

Best regards
Peter


-- System Information:
[removed, because I write this on a different machine] ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openldap-2.4.23-deb_no_subordinate_glueing.patch
Type: text/x-shellscript
Size: 1350 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20100829/05f408d7/attachment.bin>