Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com
Christian Kratzer wrote:
> Hi Howard,
>
> On Mon, 27 May 2013, Howard Chu wrote:
> <snipp/>
>> This is now fixed in git master. Nothing fishy about the entry besides the
>> modifiersName. I've now tweaked slapadd to allow it.
>
> I can confirm my test cases all work now on openlap master on CentOS 6.4:
>
> I also applied following two patches to openldap-2.4.35 and tested with the customers full configuration:
>
> From 6dab36e97afb680452a13efd41e8653a8949e2aa Mon Sep 17 00:00:00 2001
> From: Howard Chu <hyc(a)openldap.org>
> Date: Mon, 27 May 2013 08:57:15 -0700
> Subject: [PATCH] ITS#7608 promoted attrs must have valid ad_index
>
> From b7df586674c65f1637ab5a59bd0a386f2031e95f Mon Sep 17 00:00:00 2001
> From: Howard Chu <hyc(a)openldap.org>
> Date: Mon, 27 May 2013 18:51:34 -0700
> Subject: [PATCH] ITS#7608 allow slapadd w/unknown RDNs for config DB
>
> Thanks a lot for the prompt fix.
You're welcome. Thanks for confirming.
>
> Greetings
> Christian
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de
Hi Howard,
On Mon, 27 May 2013, Howard Chu wrote:
<snipp/>
> This is now fixed in git master. Nothing fishy about the entry besides the
> modifiersName. I've now tweaked slapadd to allow it.
I can confirm my test cases all work now on openlap master on CentOS 6.4:
I also applied following two patches to openldap-2.4.35 and tested with the customers full configuration:
From 6dab36e97afb680452a13efd41e8653a8949e2aa Mon Sep 17 00:00:00 2001
From: Howard Chu <hyc(a)openldap.org>
Date: Mon, 27 May 2013 08:57:15 -0700
Subject: [PATCH] ITS#7608 promoted attrs must have valid ad_index
From b7df586674c65f1637ab5a59bd0a386f2031e95f Mon Sep 17 00:00:00 2001
From: Howard Chu <hyc(a)openldap.org>
Date: Mon, 27 May 2013 18:51:34 -0700
Subject: [PATCH] ITS#7608 allow slapadd w/unknown RDNs for config DB
Thanks a lot for the prompt fix.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)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
7 years, 10 months
Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no
Stealing this ITS for delete-related cursor problems,
since the ITSed problem is more general anyway:
It looks like mdb_drop0() should also reset/uninitialize
other cursors in the same (sub)database. Currently such
cursors keep any references to the deleted pages.
--
Hallvard
7 years, 10 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com
Christian Kratzer wrote:
> Hi,
>
> On Mon, 27 May 2013, Howard Chu wrote:
>>> great. Will the changes be automatically included in 2.4.36 when its
>>> released ?
>>
>> Assuming you test and send positive feedback, yes.
>
> I checked out master using git://git.openldap.org/openldap.git and built my rpm from it.
>
> My config-3-fail.ldif sample still fails to import into cn=config on centos-64
>
> [root@test-centos64 test]# slapadd -v -n0 -F config-3 -l config-3-fail.ldif
> 51a3b6c1 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 8.1 M/s
> Closing DB...
> [root@test-centos64 test]#
>
> It fails on the first entry. Do you see anything obviously fishy in it ?
This is now fixed in git master. Nothing fishy about the entry besides the
modifiersName. I've now tweaked slapadd to allow it.
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcConfigFile: slapd.conf.test
> olcConfigDir: slapd.d/
> olcArgsFile: /var/run/openldap/slapd.args
> olcAttributeOptions: lang-
> olcAuthzPolicy: none
> olcConcurrency: 0
> olcConnMaxPending: 100
> olcConnMaxPendingAuth: 1000
> olcGentleHUP: FALSE
> olcIdleTimeout: 0
> olcIndexSubstrIfMaxLen: 4
> olcIndexSubstrIfMinLen: 2
> olcIndexSubstrAnyLen: 4
> olcIndexSubstrAnyStep: 2
> olcIndexIntLen: 4
> olcLocalSSF: 71
> olcPidFile: /var/run/openldap/slapd.pid
> olcReadOnly: FALSE
> olcReverseLookup: FALSE
> olcSaslSecProps: noplain,noanonymous
> olcSockbufMaxIncoming: 262143
> olcSockbufMaxIncomingAuth: 16777215
> olcThreads: 16
> olcTLSCRLCheck: none
> 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
> createTimestamp: 20130524161753Z
> olcLogLevel: Conns
> olcLogLevel: Stats
> olcLogLevel: Stats2
> entryCSN: 20130524161850.764209Z#000000#000#000000
> modifiersName: cn=Alice,ou=People,dc=test
> modifyTimestamp: 20130524161850Z
>
> Can you verify above error on your setup.
>
> In the meantime I will build manually with default options without any rpm magic just to be sure.
>
> Greetings
> Christian
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de
Hi,
On Mon, 27 May 2013, Howard Chu wrote:
>> great. Will the changes be automatically included in 2.4.36 when its
>> released ?
>
> Assuming you test and send positive feedback, yes.
I checked out master using git://git.openldap.org/openldap.git and built my rpm from it.
My config-3-fail.ldif sample still fails to import into cn=config on centos-64
[root@test-centos64 test]# slapadd -v -n0 -F config-3 -l config-3-fail.ldif
51a3b6c1 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 8.1 M/s
Closing DB...
[root@test-centos64 test]#
It fails on the first entry. Do you see anything obviously fishy in it ?
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: slapd.conf.test
olcConfigDir: slapd.d/
olcArgsFile: /var/run/openldap/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcLocalSSF: 71
olcPidFile: /var/run/openldap/slapd.pid
olcReadOnly: FALSE
olcReverseLookup: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
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
createTimestamp: 20130524161753Z
olcLogLevel: Conns
olcLogLevel: Stats
olcLogLevel: Stats2
entryCSN: 20130524161850.764209Z#000000#000#000000
modifiersName: cn=Alice,ou=People,dc=test
modifyTimestamp: 20130524161850Z
Can you verify above error on your setup.
In the meantime I will build manually with default options without any rpm magic just to be sure.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)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
7 years, 10 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com
Christian Kratzer wrote:
> Hi Howard,
>
> On Mon, 27 May 2013, Howard Chu wrote:
>
>> Christian Kratzer wrote:
>>> Hi Howard,
>>
>> Never mind, this was actually a bug in the handling of proxied attributes.
>> Fixed now in master, your test case should work fine there.
>
> great. Will the changes be automatically included in 2.4.36 when its released ?
Assuming you test and send positive feedback, yes.
>
> I'll test against master and deploy a workaround with an acl to the customer site in the meantime.
>
> Greetings
> Christian
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de
Hi Howard,
On Mon, 27 May 2013, Howard Chu wrote:
> Christian Kratzer wrote:
>> Hi Howard,
>
> Never mind, this was actually a bug in the handling of proxied attributes.
> Fixed now in master, your test case should work fine there.
great. Will the changes be automatically included in 2.4.36 when its released ?
I'll test against master and deploy a workaround with an acl to the customer site in the meantime.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)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
7 years, 10 months
Re: reference through null pointer and memory leak (related to ITS#7588)
by hyc＠symas.com
John Hardin wrote:
> My previous email to ITS is unreadable. Here is a repeat of what I posted.
Thanks, fixed now in master.
>
> -John
>
>
> Configuration:
>
> CFLAGS="-g -O0" ./configure --exec-prefix=/usr --prefix=/ --enable-overlays=yes --enable-slapd --enable-debug
>
> Start server:
>
> valgrind --leak-check=full openldap/servers/slapd/slapd
>
> Perform search with sorted, paged results. Repeating the command will cause the leaked memory to grow. I'm using:
>
> ldapsearch -H ldap://10.10.9.85 -x -b ou=people,dc=example,dc=com -s one -E'!sss=sn:2.5.13.3' -E'!pr=10/prompt'
>
> At the prompt, type ctrl-C.
>
> Kill the slapd process. The output of valgrind shows the following:
>
> ==486==
> ==486== HEAP SUMMARY:
> ==486== in use at exit: 95,262 bytes in 1,984 blocks
> ==486== total heap usage: 34,975 allocs, 32,991 frees, 22,150,370 bytes allocated
> ==486==
> ==486== 394 (16 direct, 378 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 10
> ==486== at 0x4027282: malloc (vg_replace_malloc.c:270)
> ==486== by 0x82228BF: ber_memalloc_x (memory.c:228)
> ==486== by 0x822290C: ber_memalloc (memory.c:244)
> ==486== by 0x81EAC29: tavl_insert (tavl.c:94)
> ==486== by 0x81C7FE9: sssvlv_op_response (sssvlv.c:760)
> ==486== by 0x8084184: slap_response_play (result.c:491)
> ==486== by 0x80859AE: slap_send_search_entry (result.c:995)
> ==486== by 0x810BDD6: bdb_search (search.c:1014)
> ==486== by 0x80F11DB: overlay_op_walk (backover.c:671)
> ==486== by 0x80F138B: over_op_func (backover.c:723)
> ==486== by 0x80F1443: over_op_search (backover.c:750)
> ==486== by 0x80748AE: fe_op_search (search.c:402)
> ==486==
> ==486== 94,753 (16 direct, 94,737 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 10
> ==486== at 0x4027282: malloc (vg_replace_malloc.c:270)
> ==486== by 0x82228BF: ber_memalloc_x (memory.c:228)
> ==486== by 0x822290C: ber_memalloc (memory.c:244)
> ==486== by 0x81EAB3A: tavl_insert (tavl.c:69)
> ==486== by 0x81C7FE9: sssvlv_op_response (sssvlv.c:760)
> ==486== by 0x8084184: slap_response_play (result.c:491)
> ==486== by 0x80859AE: slap_send_search_entry (result.c:995)
> ==486== by 0x810BDD6: bdb_search (search.c:1014)
> ==486== by 0x80F11DB: overlay_op_walk (backover.c:671)
> ==486== by 0x80F138B: over_op_func (backover.c:723)
> ==486== by 0x80F1443: over_op_search (backover.c:750)
> ==486== by 0x80748AE: fe_op_search (search.c:402)
> ==486==
> ==486== LEAK SUMMARY:
> ==486== definitely lost: 32 bytes in 2 blocks
> ==486== indirectly lost: 95,115 bytes in 1,976 blocks
> ==486== possibly lost: 0 bytes in 0 blocks
> ==486== still reachable: 115 bytes in 6 blocks
> ==486== suppressed: 0 bytes in 0 blocks
> ==486== Reachable blocks (those to which a pointer was found) are not shown.
> ==486== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==486==
> ==486== For counts of detected and suppressed errors, rerun with: -v
> ==486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 71 from 13)
>
>
>
>
>
> ----- Original Message -----
> From: Howard Chu <hyc(a)symas.com>
> To: jdhgit(a)yahoo.com; openldap-its(a)openldap.org
> Cc:
> Sent: Friday, May 24, 2013 8:10 AM
> Subject: Re: reference through null pointer and memory leak (related to ITS#7588)
>
> jdhgit(a)yahoo.com wrote:
>> Full_Name: John Hardin
>> Version: master
>> OS: Centos 6.4
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (50.23.115.111)
>>
>>
>> The commit for ITS#7588 causes a crash if next_node is NULL:
>>
>> /* Set the first entry to send for the next page */
>> so->so_tree = next_node;
>> + next_node->avl_left = NULL;
>>
>> next_node will be NULL if all entries have been sent, or if slapd_shutdown is
>> true.
>
> Thanks for pointing this out, will fix it shortly.
>
>> Another issue related to ITS#7588 is a memory leak when a sorted search with
>> paged results is aborted. This may be because so->so_tree is not the root of the
>> tree when free_sort_op() calls tavl_free().
>
> Not being root of the tree is irrelevant. The tree is threaded, and every remaining node is connected by its preceding node's right child pointer. The tavl_free() function recurses over all of the right and left children, so this should not be a problem.
>
> Can you post a test case that demonstrates the leak?
>
> -- -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com
Christian Kratzer wrote:
> Hi Howard,
Never mind, this was actually a bug in the handling of proxied attributes.
Fixed now in master, your test case should work fine there.
>
> On Mon, 27 May 2013, hyc(a)symas.com wrote:
>> ck(a)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...
> http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-2-ok.ldif
> http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-3-fail...
>
> 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
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
