[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
- From: ck@cksoft.de
- Date: Mon, 27 May 2013 10:10:45 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Hi Howard,
On Mon, 27 May 2013, hyc@symas.com wrote:
> ck@cksoft.de wrote:
>> Hi,
>>
>> Summary: it seems having a modifiersdn outside of cn=config in cn=config breaks replication once slapd is restarted.
>
> Yeah, using DNs other than the cn=config rootDN is frequently a problem. This
> is why when cn=config was introduced in 2.3 only the cn=config rootDN was
> allowed access to the tree.
>
> In this particular case, there's a simpler solution - add schema definitions
> for the missing RDN attributes directly to the cn=config entry. In your case,
> move the "ou" definition from the cn=core schema entry.
>
> There's nothing dirty about this solution - it has always been valid to define
> schema elements in the top-level slapd.conf file as well as in the top
> cn=config global config entry. The feature doesn't get used much because most
> 3rd party schemas are distributed as their own files, so it's simpler to just
> use the include directive to reference them. But for your current situation,
> you need to define these schema elements as early as possible, so that they
> can be processed as valid later on.
Thanks for the feedback.
As my sample had modifiersName: cn=Alice,ou=People,dc=test I added definitions for 'ou' and 'dc' to cn=config.
It seems this helps for modifiersNames of entries below cn=config but not for cn=config itself.
I have uploaded following three configs that illustrate the remaining problem:
http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-1-fail.ldif
http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-2-ok.ldif
http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-3-fail.ldif
The original failure with config-1 because of a modifiersName on cn=module{0},cn=config:
[root@test-centos64 test]# slapadd -v -n0 -F config-1 -l config-1-fail.ldif
added: "cn=config" (00000001)
51a32d4b 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=42)
_# 7.41% eta none elapsed none spd 1.5 M/s
Closing DB...
[root@test-centos64 test]#
Workaround applied in config-2 with attribute definitions in cn=config
[root@test-centos64 test]# diff -u config-1-fail.ldif config-2-ok.ldif
--- config-1-fail.ldif 2013-05-27 11:50:35.368253951 +0200
+++ config-2-ok.ldif 2013-05-27 11:49:17.691253291 +0200
@@ -28,6 +28,12 @@
olcTLSVerifyClient: never
olcToolThreads: 1
olcWriteTimeout: 0
+olcAttributeTypes: ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC '
+ RFC2256: organizational unit this object belongs to' SUP name )
+olcAttributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone
+ nt' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBST
+ R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VA
+ LUE )
structuralObjectClass: olcGlobal
entryUUID: 3b1e9034-58d9-1032-8161-d3a3b8e342e7
creatorsName: cn=config
@@ -86,8 +92,6 @@
ubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {7}( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256
: organization this object belongs to' SUP name )
-olcAttributeTypes: {8}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC '
- RFC2256: organizational unit this object belongs to' SUP name )
olcAttributeTypes: {9}( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated
with the entity' SUP name )
olcAttributeTypes: {10}( 2.5.4.14 NAME 'searchGuide' DESC 'RFC2256: search gui
@@ -193,10 +197,6 @@
olcAttributeTypes: {48}( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbo
x' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR ca
seIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
-olcAttributeTypes: {49}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone
- nt' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBST
- R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VA
- LUE )
olcAttributeTypes: {50}( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' DE
SC 'RFC1274: domain associated with object' EQUALITY caseIgnoreIA5Match SUBST
R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
[root@test-centos64 test]#
[root@test-centos64 test]# slapadd -v -n0 -F config-2 -l config-2-ok.ldif
added: "cn=config" (00000001)
added: "cn=module{0},cn=config" (00000001)
added: "cn=schema,cn=config" (00000001)
added: "cn={0}core,cn=schema,cn=config" (00000001)
added: "olcDatabase={-1}frontend,cn=config" (00000001)
added: "olcDatabase={0}config,cn=config" (00000001)
added: "olcDatabase={1}mdb,cn=config" (00000001)
_#################### 100.00% eta none elapsed none fast!
Closing DB...
[root@test-centos64 test]#
Breaks again after a modifiersname is added to cn=config
[root@test-centos64 test]# diff -u config-2-ok.ldif config-3-fail.ldif
--- config-2-ok.ldif 2013-05-27 11:49:17.691253291 +0200
+++ config-3-fail.ldif 2013-05-27 11:52:57.346255334 +0200
@@ -42,7 +42,7 @@
olcLogLevel: Stats
olcLogLevel: Stats2
entryCSN: 20130524161850.764209Z#000000#000#000000
-modifiersName: cn=config
+modifiersName: cn=Alice,ou=People,dc=test
modifyTimestamp: 20130524161850Z
dn: cn=module{0},cn=config
[root@test-centos64 test]#
[root@test-centos64 test]# slapadd -v -n0 -F config-3 -l config-3-fail.ldif
51a32daf 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)
_# 7.35% eta none elapsed none spd 3.0 M/s
Closing DB...
[root@test-centos64 test]#
Sorry if I do not see the obvious. Is there any possibility to get this to work for cn=config as well as entries below cn=config.
How much freedom would we have to rearrange the entries und cn=config so we could have the schema defintions read before olcGlobal ?
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer