OK, I've found the problem, and it seems to be a configuration problem. Please read below.

Here is the slapd.conf used in the test:

# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /home/build/rel-openldap/etc/openldap/schema/core.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org

pidfile /home/build/rel-openldap/var/run/slapd.pid argsfile /home/build/rel-openldap/var/run/slapd.args

# Load dynamic backend modules: # modulepath /home/build/rel-openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la

# Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING!

database perl suffix "ou=perl,dc=my-domain,dc=com"

^^ This is the suffix where the instance of back-perl is rooted at

subordinate perlModulePath /home/build/rel-openldap/etc/openldap perlModule SampleLDAP

####################################################################### # BDB database definitions #######################################################################

database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /home/build/rel-openldap/var/openldap-data # Indices to maintain index objectClass eq

And here is the slapcat output when the perl database is disabled in slapd.conf to prevent the crash:

dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z

dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z

dn: ou=perl,dc=my-domain,dc=com

^^^ An entry with the same DN exists in the superior database. As a consequence, this entry is returned by back-bdb's tool functions, but backglue tries to release it using back-perl. Since back-perl does not have any tool functions, what is considered a safe replacement is used. Unfortunately, the safe replacement doesn't know how to deal with read-only entries returned by back-bdb. The solution consists in:

- temporarily commenting the instance of back-perl

- removing this entry from your back-bdb

- re-enabling the instance of back-perl

A follow-on to this ITS could be to devise a means to detect whether a superior database contains entries that belong to a subordinate one, and warn the administrator of the inconsistency.

p.