[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd

Full_Name: Christian Kratzer
Version: 2.4.35
OS: CentOS 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (


I have setup an acl to allow write access to cn=config for users in the main

This is mainly to have a clean audit trail of config changes using auditlog so
changes can be tracked back to who did them.

We also backup config with slapcat -n0 and data with slapcat.

When restoring configs and data I ran into two spefific problems when cn=config
entries have a modifiersdn outside of cn=config as in:

  dn: cn=config
  objectClass: olcGlobal
  modifiersName: cn=Alice,ou=People,dc=test
  modifyTimestamp: 20130524161850Z

This is on openldap-2.4.35 on centos-6.4.

I have built a simple test case to illustrate the problem. Should be easily
reproducible using after editing a few paths in below configs.

We setup a new openldap server by using slapadd -n0 of below config and slapadd
of below data in test.ldif.


After starting slapd I modify the configuration as cn=Alice,ou=People,dc=test
using below scripts


I then extract following two backups from cn=config using slapcat -n0 and
dc=test using slapcat


First problem: An attempt to to restore slapcat-dc=test.ldif after deleting data
using "rm -f /var/lib/ldap/*" fails as follows:

  [root@test-centos64 openldap]# slapadd -v -F slapd.d -l slapcat-dc\=test.ldif
  519f93a8 PROXIED attributeDescription "OU" inserted.
  519f93a8 PROXIED attributeDescription "DC" inserted.
  519f93a8 => mdb_tool_entry_put: id2entry_add failed: err=17
  519f93a8 => mdb_tool_entry_put: txn_aborted! File exists (17)
  slapadd: could not add entry dn="dc=test" (line=1): txn_aborted! File exists
  _####                  24.55% eta   none elapsed            none spd   2.0
  Closing DB...
  [root@test-centos64 openldap]#

I can successfully import the data if I edit cn=config.ldif and manuelly fix the
modifiersName to cn=config and reimport configuration using slapadd -n0.

This also kills our disaster recovery scenario of deleting data and letting
syncrepl handle the recovery.

Second problem: Recovery of the configuration fails as after "rm -fr slapd.d"

  [root@test-centos64 openldap]# slapadd -v -n0 -F slapd.d -l
  519f95c2 str2entry: invalid value for attributeType modifiersName #0 (syntax
  slapadd: could not parse entry (line=1)
  _#                      5.39% eta   none elapsed            none spd   3.2
  Closing DB...
  [root@test-centos64 openldap]#

Again I am able to work around the problem by fixing the modifiersdn of the
cn=config dump before slapadding with slapadd -n0.

Any chance of getting above use cases working ?  I would like to provide the
customer in question with a straight forward recovery process for both data and

They would like to avoid using the cn=config rootDN for regular administration
in order to have a clean audit trail of changes using auditlog on cn=config.