Comment 21 for bug 14929

This appears to be an LDIF parsing problem (which is why I have
submitted it to this bug number). In fact it is more subtle than that.
Feel free to move this to a different bug number if necessary.

The error during a dist-upgrade was:

Installing new version of config file /etc/init.d/slapd ...
  Updating config access directives... done.
  Moving old database directories to /var/backups:
  - directory dc=lea,dc=my,dc=base... done.
  Loading from /var/backups/slapd-2.1.30-3:
  - directory dc=lea,dc=my,dc=base... slapadd: could not add entry
dn="dc=my,dc=base" (line=14): txn_aborted! DB_KEYEXIST: Key/data pair
already exists (-30996)
failed.
dpkg: error processing slapd (--configure):
 subprocess post-installation script returned error exit status 1

attempting to manually slapadd the LDIF file produced:
/usr/sbin/slapadd -f /etc/ldap/slapd.conf -l /var/backups/slapd-2.1.30-3/foo.ldif
slapadd: could not parse entry (line=14)

turning on debug info produced:
/usr/sbin/slapadd -d1 -f /etc/ldap/slapd.conf -l /var/backups/slapd-2.1.30-3/foo.ldif
<snip>
backend_startup: starting "dc=lea,dc=my,dc=base"
bdb_db_open: dbenv_open(/var/lib/ldap)
=> str2entry: "dn: dc=my,dc=base
dc: my
objectClass: top
objectClass: domain
objectClass: nisDomainObject
structuralObjectClass: domain
entryUUID: 142d2f8e-52f5-1027-8b41-c022ab19fc70
creatorsName: cn=manager,dc=my,dc=base
createTimestamp: 20030725140732Z
nisDomain: foobar
entryCSN: 2003092908:57:14Z#0x0001#0#0000
modifiersName: cn=manager,dc=my,dc=base
modifyTimestamp: 20030929085714Z
"
>>> dnPrettyNormal: <dc=my,dc=base>
<<< dnPrettyNormal: <dc=my,dc=base>, <dc=my,dc=base>
str2entry: invalid value for attributeType objectClass #2 (syntax
1.3.6.1.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=14)
slapadd shutdown: initiated
====> bdb_cache_release_all
slapadd shutdown: freeing system resources.

openldap is known for obscure error messages but I believe this is
caused by trying to add data that is not within the DIT defined by the
suffix. The reasons for this are outlined below.

path names are not absolute for the binaries slapadd/slapcat nor for the
configuration file /etc/ldap/slapd.conf. ***This has led to complete
loss of data in my directory***

I have another openldap installed in /usr/local and binaries for this
installation appear first in PATH. this meant that slapcat and slapadd
were working on the wrong directory and so the backup kept
in /var/backups/slapd-2.1.30-3 is a backup of the wrong data and my
directory data is LOST!

I suggest that binaries are defined explicitly as well as paths to
config files eg:

/usr/bin/slapcat -f /etc/ldap/slapd.conf -l /var/backups/slapd...
/usr/bin/slapadd -f /etc/ldap/slapd.conf -l /var/backups/sla....

to prevent this happening in future.

GREG

hardware: Dell optiplex desktop
distro: sarge
kernel: 2.6.8-2-686
slapd: upgrade from 2.1.30-3 to 2.2.23 (dist-upgrade)
--
Greg Matthews
iTSS Wallingford 01491 692445