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

[pierangelo.masarati@polimi.it]

On 05/24/2013 09:41 PM, ck@cksoft.de wrote:
> Full_Name: Christian Kratzer
> Version: 2.4.35
> OS: CentOS 6.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (37.80.52.67)
>
>
> Hi,
>
> I have setup an acl to allow write access to cn=config for users in the main
> directory.
>
> 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.
>
>    http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config.ldif
>    http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/test.ldif
>
> After starting slapd I modify the configuration as cn=Alice,ou=People,dc=test
> using below scripts
>
>    http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/olcLoglevel.sh
>    http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/olcLoglevel.ldif
>
> I then extract following two backups from cn=config using slapcat -n0 and
> dc=test using slapcat
>
>    http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-cn=config.ldif
>    http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=test.ldif
>
> 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

This is a chicken and egg problem.  OU is not built-in, so it cannot be 
used until it is configured.  Configuration data must only use schema 
items whose definition is already loaded.

I don't see a clear way out of this issue, so I'd pass the ball to 
Howard.  My (humble) suggestion is: delegate modifications to identities 
whose DN is made of hardcoded attribute types: CN, UID (you can find 
what attribute types are hardcoded in schema_prep.c).

p.

> (17)
>    _####                  24.55% eta   none elapsed            none spd   2.0
> M/s
>    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
> slapcat-cn\=config.ldif
>    519f95c2 str2entry: invalid value for attributeType modifiersName #0 (syntax
> 1.3.6.1.4.1.1466.115.121.1.12)
>    slapadd: could not parse entry (line=1)
>    _#                      5.39% eta   none elapsed            none spd   3.2
> M/s
>    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
> cn=config.
>
> 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.
>
> Greetings
> Christian
>
>
>
>
>


-- 
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano