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