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 ck＠cksoft.de 27 May '13

27 May '13

Hi Howard, 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 -- 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#7582) Access to uninitialized memory when sending cldap packet
by stefw＠redhat.com 27 May '13

27 May '13

On 23.05.2013 21:34, Howard Chu wrote: > Your patch doesn't fix the issue. The behavior under valgrind is > unchanged either way. Seems you're missing a '!' in your test. Indeed, thank you for fixing this and applying the patch. Cheers, Stef

1 0

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

26 May '13

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. -- -- 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

(ITS#7609) back-meta enhancement: filter patterns for target selection
by hyc＠OpenLDAP.org 26 May '13

26 May '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Since a lot of applications perform DN lookups using a search filter, it would be useful to allow specifying a regex pattern match on filters to select a target. This would avoid broadcasting a suffix-level search to all targets unnecessarily. The intended use case is for a system where the DIT is sharded across multiple servers, and entries are distributed across each target using some regular pattern. (e.g., uid=a.* on target1, uid=b.* on target2, etc...)

1 0

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

26 May '13

Hi, Summary: it seems having a modifiersdn outside of cn=config in cn=config breaks replication once slapd is restarted. I have a more elaborate test setup with four servers. Two masters ldaptest1, ldaptest2 using syncrepl in mirrormode . Two slaves ldaptest3, ldaptest4 that use syncrepl to slave from the masters. The masters and the slaves also replicate cn=config between themselves. Replication config is as follows: on ldaptest1 and ldaptest2: dn: cn=config ... olcServerID: 1 ldap://ldaptest1.cksoft.de olcServerID: 2 ldap://ldaptest2.cksoft.de olcServerID: 3 ldap://ldaptest3.cksoft.de olcServerID: 4 ldap://ldaptest4.cksoft.de dn: olcDatabase={1}mdb,cn=config ... olcSyncrepl: rid=001 provider=ldap://ldaptest1.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcSyncrepl: rid=002 provider=ldap://ldaptest2.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcMirrorMode: TRUE on ldaptest3 and ldaptest4: dn: cn=config ... olcServerID: 1 ldap://ldaptest1.cksoft.de olcServerID: 2 ldap://ldaptest2.cksoft.de olcServerID: 3 ldap://ldaptest3.cksoft.de olcServerID: 4 ldap://ldaptest4.cksoft.de dn: olcDatabase={1}mdb,cn=config ... olcSyncrepl: rid=001 provider=ldap://ldaptest1.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcSyncrepl: rid=002 provider=ldap://ldaptest2.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcMirrorMode: FALSE Once I modify something trivial like olcLogLevel on the slaves using my personal dn, cn=config will have following operational attributes: # config dn: cn=config structuralObjectClass: olcGlobal entryUUID: dc78e00a-461a-1032-9454-cd151c72b364 creatorsName: cn=config createTimestamp: 20130430194949Z entryCSN: 20130526075059.867187Z#000000#004#000000 modifiersName: uid=ckratzer,ou=people,dc=test modifyTimestamp: 20130526075059Z contextCSN: 20130526074631.636527Z#000000#003#000000 contextCSN: 20130526075059.867187Z#000000#004#000000 entryDN: cn=config subschemaSubentry: cn=Subschema I then restart slapd on the first slave ldaptest3 and leave it running on ldaptest4. A change replicated from the masters will appear on ldaptest4 just fine. The restarted master on ldaptest3 fails to apply the change May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_message_to_entry: rid=001 DN: cn=test,dc=test, UUID: 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 inserted UUID 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 be_search (0) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 cn=test,dc=test May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=test,dc=test,) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_updateCookie: rid=001 be_modify failed (17) May 26 10:06:13 ldaptest3 slapd[2410]: do_syncrepl: rid=001 rc 17 retrying May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_message_to_entry: rid=002 DN: cn=test,dc=test, UUID: 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 inserted UUID 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 be_search (0) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 cn=test,dc=test, May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 entry unchanged, ignored (cn=test,dc=test,) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_updateCookie: rid=002 be_modify failed (17) May 26 10:06:13 ldaptest3 slapd[2410]: do_syncrepl: rid=002 rc 17 retrying I currently have customer data in above test setup so I had to do some obfuscation in above samples and logs. If required I can setup maximally stripped down case that illustrates the problem. Would it be possible to mask modifiersName inside cn=config to either a fixed value just append something like cn=proxied,cn=config to dns outside of cn=config. 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#7607) Assertion triggers during many sequential transaction commits
by hyc＠symas.com 24 May '13

24 May '13

Howard Chu wrote: > éÌØÑ ìÕËØÑÎÏ× wrote: >> What can i do to help investigating this issue? >> I'm not very familliar with lmdb sources so any suggestions on where to look >> would be appreciated! > > I've installed a Win7 x64 VM here and compiled with gcc 4.8.0 and it works fine. > I've also installed Visual Studio 2012 Express and compiled with that, it's also working fine. Doesn't seem like there's an OpenLDAP bug here, must be a problem with your machine. >> ó Õ×ÁÖÅÎÉÅÍ, éÌØÑ >> >> >> 2013/5/24 Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> >> >> ilya.lukyanov(a)gmail.com <mailto:ilya.lukyanov@gmail.com> wrote: >> >> Full_Name: Ilya Lukyanov >> Version: 2.4.35 >> OS: Windows 7 x64 >> URL: ftp://ftp.openldap.org/__incoming/ <ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (95.25.254.250) >> >> >> I've built lmdb from source distribution of OpenLDAP 2.4.35 under >> Windows 7 x64 >> under Visual Studio 2012. All tests included into source distribution pass >> successfully. >> >> Then i'm executing my own test with code as follows: >> https://gist.github.com/__ilyalukyanov/5644971 >> <https://gist.github.com/ilyalukyanov/5644971> >> And i'm allways get an asserion when executing near 32500-th >> mdb_txn_commit >> (line 2231 - assert(oldpg_txnid <= env->me_pglast);) >> I think this is a bug because if consider the scenario with separate >> usage of >> LightningDB under high write-load scenario, 32k commits is not enough. >> >> >> Your test runs fine on my Linux box. I don't currently have a Windows 7 >> x64 test machine, won't be able to investigate this any time soon. -- -- 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#7606) reference through null pointer and memory leak
by quanah＠zimbra.com 24 May '13

24 May '13

--On Friday, May 24, 2013 9:06 PM +0000 jdhgit(a)yahoo.com wrote: Please don't send garbage to the ITS. I advise finding an email client that can actually generate proper email. --Quanah > --1665047788-1800616979-1369429529=:40525 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > Configuration:=0A=0A=A0 CFLAGS=3D"-g -O0" ./configure > --exec-prefix=3D/usr = --prefix=3D/ --enable-overlays=3Dyes > --enable-slapd --enable-debug=0A=0ASta= rt server: =0A=0A=A0 valgrind > --leak-check=3Dfull openldap/servers/slapd/sl= apd=0A=0APerform search > with sorted, paged results. Repeating the command w= ill cause the leaked > memory to grow. I'm using:=0A=0A=A0 ldapsearch -H ldap= ://10.10.9.85 -x > -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2= .5.13.3' > -E'!pr=3D10/prompt'=0A=0AAt the prompt, type ctrl-C.=0A=0AKill the= > slapd process. The output of valgrind shows the > following:=0A=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D HEAP > SUMMARY:=0A=3D=3D486=3D=3D=A0=A0=A0=A0 in us= e at exit: 95,262 bytes in > 1,984 blocks=0A=3D=3D486=3D=3D=A0=A0 total heap = usage: 34,975 allocs, > 32,991 frees, 22,150,370 bytes allocated=0A=3D=3D486= =3D=3D > =0A=3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks a= re > definitely lost in loss record 7 of 10=0A=3D=3D486=3D=3D=A0=A0=A0 at 0x4= > 027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x82= 228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x822290= C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x81EAC29: tav= l_insert (tavl.c:94)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x81C7FE9: sssvlv_op_res= ponse (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x8084184: slap_response= _play > (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80859AE: slap_send_sea= > rch_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x810BDD6: > bdb_searc= h (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F11DB: > overlay_op_walk = (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F138B: over_op_func (bac= kover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F1443: over_op_search (backo= ver.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x80748AE: fe_op_search (search.c:= 402)=0A=3D=3D486=3D=3D > =0A=3D=3D486=3D=3D 94,753 (16 direct, 94,737 indirec= t) bytes in 1 > blocks are definitely lost in loss record 10 of 10=0A=3D=3D48= > 6=3D=3D=A0=A0=A0 at 0x4027282: malloc > (vg_replace_malloc.c:270)=0A=3D=3D486= =3D=3D=A0=A0=A0 by 0x82228BF: > ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D= =3D=A0=A0=A0 by 0x822290C: > ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0= =A0=A0 by 0x81EAB3A: > tavl_insert (tavl.c:69)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x81C7FE9: > sssvlv_op_response (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by = > 0x8084184: slap_response_play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 > by = 0x80859AE: slap_send_search_entry > (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0= by 0x810BDD6: bdb_search > (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8= 0F11DB: > overlay_op_walk (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80= > F138B: over_op_func (backover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F144= 3: over_op_search (backover.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x80748AE:= fe_op_search (search.c:402)=0A=3D=3D486=3D=3D > =0A=3D=3D486=3D=3D LEAK SUMM= ARY:=0A=3D=3D486=3D=3D=A0=A0=A0 definitely > lost: 32 bytes in 2 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0 indirectly lost: > 95,115 bytes in 1,976 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0=A0=A0 possibly > lost: 0 bytes in 0 blocks=0A=3D=3D486= =3D=3D=A0=A0=A0 still reachable: > 115 bytes in 6 blocks=0A=3D=3D486=3D=3D=A0= =A0=A0=A0=A0=A0=A0=A0 > suppressed: 0 bytes in 0 blocks=0A=3D=3D486=3D=3D Rea= chable blocks > (those to which a pointer was found) are not shown.=0A=3D=3D4= 86=3D=3D > To see them, rerun with: --leak-check=3Dfull --show-reachable=3Dye= > s=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D For counts of detected and > suppresse= d errors, rerun with: -v=0A=3D=3D486=3D=3D ERROR SUMMARY: 2 > errors from 2 c= ontexts (suppressed: 71 from 13) > --1665047788-1800616979-1369429529=:40525 > Content-Type: text/html; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > <html><body><div style=3D"color:#000; background-color:#fff; > font-family:ti= mes new roman, new york, times, > serif;font-size:12pt">Configuration: <br= >>   CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/ >> --e= > nable-overlays=3Dyes --enable-slapd --enable-debug Start server: > <br= >>   valgrind --leak-check=3Dfull >> openldap/servers/slapd/slapd <b= > r>Perform search with sorted, paged results. Repeating the command will > cau= se the leaked memory to grow. I'm using:   ldapsearch -H > ldap:/= /10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one > -E'!sss=3Dsn:2.5= .13.3' -E'!pr=3D10/prompt' At the prompt, type > ctrl-C. Kill t= he slapd process. The output of valgrind shows the > following: =3D=3D= 486=3D=3D =3D=3D486=3D=3D HEAP > SUMMARY: =3D=3D486=3D=3D  &= nbsp;  in use at exit: > 95,262 bytes in 1,984 blocks =3D=3D486=3D=3D=    total heap > usage: 34,975 allocs, 32,991 frees, 22,150,370 byte= s > allocated =3D=3D486=3D=3D =3D=3D486=3D=3D 394 (16 > direct, 378 indirect) bytes in 1 blocks are definitely lost in loss > record= 7 of 10 =3D=3D486=3D=3D    at 0x4027282: > malloc (vg_repl= ace_malloc.c:270) =3D=3D486=3D=3D    > by 0x82228BF: ber_me= malloc_x > (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: = > ber_memalloc (memory.c:244) =3D=3D486=3D=3D    by > 0x81EAC= 29: tavl_insert (tavl.c:94) =3D=3D486=3D=3D    > by 0x81C7F= E9: sssvlv_op_response > (sssvlv.c:760) =3D=3D486=3D=3D    = by 0x8084184: > slap_response_play (result.c:491) =3D=3D486=3D=3D &nb= sp;  > by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486= > =3D=3D    by 0x810BDD6: bdb_search > (search.c:1014) =3D=3D= 486=3D=3D    by 0x80F11DB: > overlay_op_walk (backover.c:671)<= br>=3D=3D486=3D=3D    > by 0x80F138B: over_op_func (backover.c= > :723) =3D=3D486=3D=3D    by 0x80F1443: over_op_search > (ba= ckover.c:750) =3D=3D486=3D=3D    by 0x80748AE: > fe_op_sear= ch > (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D 94,753 (16 direct, > 9= 4,737 indirect) bytes in 1 blocks are definitely lost in loss record > 10 of = 10 =3D=3D486=3D=3D    at 0x4027282: malloc > (vg_replace_ma= lloc.c:270) =3D=3D486=3D=3D    by > 0x82228BF: ber_memalloc= _x > (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: ber_me= > malloc (memory.c:244) =3D=3D486=3D=3D    by 0x81EAB3A: > ta= vl_insert (tavl.c:69) =3D=3D486=3D=3D    by > 0x81C7FE9: ss= svlv_op_response > (sssvlv.c:760) =3D=3D486=3D=3D    by 0x8= 084184: > slap_response_play (result.c:491) =3D=3D486=3D=3D  &nb= sp; > by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486=3D=3D&= > nbsp;   by 0x810BDD6: bdb_search > (search.c:1014) =3D=3D486=3D= =3D    by 0x80F11DB: > overlay_op_walk (backover.c:671) =3D= =3D486=3D=3D    > by 0x80F138B: over_op_func (backover.c:723)<= > br>=3D=3D486=3D=3D    by 0x80F1443: over_op_search > (backover.c:750) =3D=3D486=3D=3D    by 0x80748AE: > fe_op_= search (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D LEAK > SUMMARY:<= br>=3D=3D486=3D=3D    definitely lost: 32 bytes > in 2 blocks<= br>=3D=3D486=3D=3D    indirectly lost: > 95,115 bytes in 1,976= > blocks =3D=3D486=3D=3D      possibly lost: 0 > b= ytes in 0 blocks =3D=3D486=3D=3D    still reachable: > 115 = bytes in 6 > blocks =3D=3D486=3D=3D      &nb= > sp;  suppressed: 0 bytes in 0 blocks =3D=3D486=3D=3D Reachable > bloc= ks (those to which a pointer was found) are not > shown. =3D=3D486=3D=3D T= o see them, rerun with: --leak-check=3Dfull > --show-reachable=3Dyes =3D= =3D486=3D=3D =3D=3D486=3D=3D For > counts of detected and suppressed erro= rs, rerun with: > -v =3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex= ts > (suppressed: 71 from 13) <div style=3D"font-family: times new= > roman, new york, times, serif; font-size: 12pt;"><div > style=3D"font-family= : times new roman, new york, > times, serif; font-size: 12pt;"> </div> </div> </div></body></html> > --1665047788-1800616979-1369429529=:40525-- > > -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7606) reference through null pointer and memory leak
by jdhgit＠yahoo.com 24 May '13

24 May '13

--1665047788-1800616979-1369429529=:40525 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Configuration:=0A=0A=A0 CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr = --prefix=3D/ --enable-overlays=3Dyes --enable-slapd --enable-debug=0A=0ASta= rt server: =0A=0A=A0 valgrind --leak-check=3Dfull openldap/servers/slapd/sl= apd=0A=0APerform search with sorted, paged results. Repeating the command w= ill cause the leaked memory to grow. I'm using:=0A=0A=A0 ldapsearch -H ldap= ://10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2= .5.13.3' -E'!pr=3D10/prompt'=0A=0AAt the prompt, type ctrl-C.=0A=0AKill the= slapd process. The output of valgrind shows the following:=0A=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D HEAP SUMMARY:=0A=3D=3D486=3D=3D=A0=A0=A0=A0 in us= e at exit: 95,262 bytes in 1,984 blocks=0A=3D=3D486=3D=3D=A0=A0 total heap = usage: 34,975 allocs, 32,991 frees, 22,150,370 bytes allocated=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks a= re definitely lost in loss record 7 of 10=0A=3D=3D486=3D=3D=A0=A0=A0 at 0x4= 027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x82= 228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x822290= C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x81EAC29: tav= l_insert (tavl.c:94)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x81C7FE9: sssvlv_op_res= ponse (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8084184: slap_response= _play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80859AE: slap_send_sea= rch_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x810BDD6: bdb_searc= h (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F11DB: overlay_op_walk = (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F138B: over_op_func (bac= kover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F1443: over_op_search (backo= ver.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80748AE: fe_op_search (search.c:= 402)=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D 94,753 (16 direct, 94,737 indirec= t) bytes in 1 blocks are definitely lost in loss record 10 of 10=0A=3D=3D48= 6=3D=3D=A0=A0=A0 at 0x4027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486= =3D=3D=A0=A0=A0 by 0x82228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D= =3D=A0=A0=A0 by 0x822290C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0= =A0=A0 by 0x81EAB3A: tavl_insert (tavl.c:69)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x81C7FE9: sssvlv_op_response (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x8084184: slap_response_play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x80859AE: slap_send_search_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0= by 0x810BDD6: bdb_search (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8= 0F11DB: overlay_op_walk (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80= F138B: over_op_func (backover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F144= 3: over_op_search (backover.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80748AE:= fe_op_search (search.c:402)=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D LEAK SUMM= ARY:=0A=3D=3D486=3D=3D=A0=A0=A0 definitely lost: 32 bytes in 2 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0 indirectly lost: 95,115 bytes in 1,976 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0=A0=A0 possibly lost: 0 bytes in 0 blocks=0A=3D=3D486= =3D=3D=A0=A0=A0 still reachable: 115 bytes in 6 blocks=0A=3D=3D486=3D=3D=A0= =A0=A0=A0=A0=A0=A0=A0 suppressed: 0 bytes in 0 blocks=0A=3D=3D486=3D=3D Rea= chable blocks (those to which a pointer was found) are not shown.=0A=3D=3D4= 86=3D=3D To see them, rerun with: --leak-check=3Dfull --show-reachable=3Dye= s=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D For counts of detected and suppresse= d errors, rerun with: -v=0A=3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 c= ontexts (suppressed: 71 from 13) --1665047788-1800616979-1369429529=:40525 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt">Configuration: <br= >  CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/ --e= nable-overlays=3Dyes --enable-slapd --enable-debug Start server: <br= >   valgrind --leak-check=3Dfull openldap/servers/slapd/slapd <b= r>Perform search with sorted, paged results. Repeating the command will cau= se the leaked memory to grow. I'm using:   ldapsearch -H ldap:/= /10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2.5= .13.3' -E'!pr=3D10/prompt' At the prompt, type ctrl-C. Kill t= he slapd process. The output of valgrind shows the following: =3D=3D= 486=3D=3D =3D=3D486=3D=3D HEAP SUMMARY: =3D=3D486=3D=3D  &= nbsp;  in use at exit: 95,262 bytes in 1,984 blocks =3D=3D486=3D=3D=    total heap usage: 34,975 allocs, 32,991 frees, 22,150,370 byte= s allocated =3D=3D486=3D=3D =3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks are definitely lost in loss record= 7 of 10 =3D=3D486=3D=3D    at 0x4027282: malloc (vg_repl= ace_malloc.c:270) =3D=3D486=3D=3D    by 0x82228BF: ber_me= malloc_x (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: = ber_memalloc (memory.c:244) =3D=3D486=3D=3D    by 0x81EAC= 29: tavl_insert (tavl.c:94) =3D=3D486=3D=3D    by 0x81C7F= E9: sssvlv_op_response (sssvlv.c:760) =3D=3D486=3D=3D    = by 0x8084184: slap_response_play (result.c:491) =3D=3D486=3D=3D &nb= sp;  by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486= =3D=3D    by 0x810BDD6: bdb_search (search.c:1014) =3D=3D= 486=3D=3D    by 0x80F11DB: overlay_op_walk (backover.c:671)<= br>=3D=3D486=3D=3D    by 0x80F138B: over_op_func (backover.c= :723) =3D=3D486=3D=3D    by 0x80F1443: over_op_search (ba= ckover.c:750) =3D=3D486=3D=3D    by 0x80748AE: fe_op_sear= ch (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D 94,753 (16 direct, 9= 4,737 indirect) bytes in 1 blocks are definitely lost in loss record 10 of = 10 =3D=3D486=3D=3D    at 0x4027282: malloc (vg_replace_ma= lloc.c:270) =3D=3D486=3D=3D    by 0x82228BF: ber_memalloc= _x (memory.c:228) =3D=3D486=3D=3D    by 0x822290C: ber_me= malloc (memory.c:244) =3D=3D486=3D=3D    by 0x81EAB3A: ta= vl_insert (tavl.c:69) =3D=3D486=3D=3D    by 0x81C7FE9: ss= svlv_op_response (sssvlv.c:760) =3D=3D486=3D=3D    by 0x8= 084184: slap_response_play (result.c:491) =3D=3D486=3D=3D  &nb= sp; by 0x80859AE: slap_send_search_entry (result.c:995) =3D=3D486=3D=3D&= nbsp;   by 0x810BDD6: bdb_search (search.c:1014) =3D=3D486=3D= =3D    by 0x80F11DB: overlay_op_walk (backover.c:671) =3D= =3D486=3D=3D    by 0x80F138B: over_op_func (backover.c:723)<= br>=3D=3D486=3D=3D    by 0x80F1443: over_op_search (backover.c:750) =3D=3D486=3D=3D    by 0x80748AE: fe_op_= search (search.c:402) =3D=3D486=3D=3D =3D=3D486=3D=3D LEAK SUMMARY:<= br>=3D=3D486=3D=3D    definitely lost: 32 bytes in 2 blocks<= br>=3D=3D486=3D=3D    indirectly lost: 95,115 bytes in 1,976= blocks =3D=3D486=3D=3D      possibly lost: 0 b= ytes in 0 blocks =3D=3D486=3D=3D    still reachable: 115 = bytes in 6 blocks =3D=3D486=3D=3D      &nb= sp;  suppressed: 0 bytes in 0 blocks =3D=3D486=3D=3D Reachable bloc= ks (those to which a pointer was found) are not shown. =3D=3D486=3D=3D T= o see them, rerun with: --leak-check=3Dfull --show-reachable=3Dyes =3D= =3D486=3D=3D =3D=3D486=3D=3D For counts of detected and suppressed erro= rs, rerun with: -v =3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex= ts (suppressed: 71 from 13) <div style=3D"font-family: times new= roman, new york, times, serif; font-size: 12pt;"><div style=3D"font-family= : times new roman, new york, times, serif; font-size: 12pt;"> </div> </div> </div></body></html> --1665047788-1800616979-1369429529=:40525--

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by pierangelo.masarati＠polimi.it 24 May '13

24 May '13

On 05/24/2013 09:41 PM, ck(a)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=conf… > http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=test… > > 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

1 0

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

24 May '13

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=conf… http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=test… 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 (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

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