openldap-bugs May 2013

openldap-bugs@openldap.org

30 participants
83 discussions

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 28 May '13

28 May '13

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/

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 28 May '13

28 May '13

h.b.furuseth(a)usit.uio.no wrote: > 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. > Just doc this. No cursors should be open on a DB that is being dropped. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 28 May '13

28 May '13

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

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 28 May '13

28 May '13

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

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 27 May '13

27 May '13

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/

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 27 May '13

27 May '13

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

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 27 May '13

27 May '13

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/

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 27 May '13

27 May '13

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

1 0

Re: reference through null pointer and memory leak (related to ITS#7588)
by hyc＠symas.com 27 May '13

27 May '13

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/

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 27 May '13

27 May '13

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.l… > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-2-ok.ldif > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/config-3-fail.l… > > 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/

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2013