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, 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
--
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, 7 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com
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/
7 years, 7 months
(ITS#7609) back-meta enhancement: filter patterns for target selection
by hyc＠OpenLDAP.org
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...)
7 years, 7 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de
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
7 years, 7 months
Re: (ITS#7607) Assertion triggers during many sequential transaction commits
by hyc＠symas.com
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/
7 years, 7 months
Re: (ITS#7606) reference through null pointer and memory leak
by quanah＠zimbra.com
--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><br=
>> CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/
>> --e=
> nable-overlays=3Dyes --enable-slapd --enable-debug<br><br>Start server:
> <br=
>> <br> valgrind --leak-check=3Dfull
>> openldap/servers/slapd/slapd<br><b=
> r>Perform search with sorted, paged results. Repeating the command will
> cau= se the leaked memory to grow. I'm using:<br><br> 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'<br><br>At the prompt, type
> ctrl-C.<br><br>Kill t= he slapd process. The output of valgrind shows the
> following:<br><br>=3D=3D= 486=3D=3D <br>=3D=3D486=3D=3D HEAP
> SUMMARY:<br>=3D=3D486=3D=3D &= nbsp; in use at exit:
> 95,262 bytes in 1,984 blocks<br>=3D=3D486=3D=3D= total heap
> usage: 34,975 allocs, 32,991 frees, 22,150,370 byte= s
> allocated<br>=3D=3D486=3D=3D <br>=3D=3D486=3D=3D 394 (16
> direct, 378 indirect) bytes in 1 blocks are definitely lost in loss
> record= 7 of 10<br>=3D=3D486=3D=3D at 0x4027282:
> malloc (vg_repl= ace_malloc.c:270)<br>=3D=3D486=3D=3D
> by 0x82228BF: ber_me= malloc_x
> (memory.c:228)<br>=3D=3D486=3D=3D by 0x822290C: =
> ber_memalloc (memory.c:244)<br>=3D=3D486=3D=3D by
> 0x81EAC= 29: tavl_insert (tavl.c:94)<br>=3D=3D486=3D=3D
> by 0x81C7F= E9: sssvlv_op_response
> (sssvlv.c:760)<br>=3D=3D486=3D=3D = by 0x8084184:
> slap_response_play (result.c:491)<br>=3D=3D486=3D=3D &nb= sp;
> by 0x80859AE: slap_send_search_entry (result.c:995)<br>=3D=3D486=
> =3D=3D by 0x810BDD6: bdb_search
> (search.c:1014)<br>=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)<br>=3D=3D486=3D=3D by 0x80F1443: over_op_search
> (ba= ckover.c:750)<br>=3D=3D486=3D=3D by 0x80748AE:
> fe_op_sear= ch
> (search.c:402)<br>=3D=3D486=3D=3D <br>=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<br>=3D=3D486=3D=3D at 0x4027282: malloc
> (vg_replace_ma= lloc.c:270)<br>=3D=3D486=3D=3D by
> 0x82228BF: ber_memalloc= _x
> (memory.c:228)<br>=3D=3D486=3D=3D by 0x822290C: ber_me=
> malloc (memory.c:244)<br>=3D=3D486=3D=3D by 0x81EAB3A:
> ta= vl_insert (tavl.c:69)<br>=3D=3D486=3D=3D by
> 0x81C7FE9: ss= svlv_op_response
> (sssvlv.c:760)<br>=3D=3D486=3D=3D by 0x8= 084184:
> slap_response_play (result.c:491)<br>=3D=3D486=3D=3D &nb= sp;
> by 0x80859AE: slap_send_search_entry (result.c:995)<br>=3D=3D486=3D=3D&=
> nbsp; by 0x810BDD6: bdb_search
> (search.c:1014)<br>=3D=3D486=3D= =3D by 0x80F11DB:
> overlay_op_walk (backover.c:671)<br>=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)<br>=3D=3D486=3D=3D by 0x80748AE:
> fe_op_= search (search.c:402)<br>=3D=3D486=3D=3D <br>=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<br>=3D=3D486=3D=3D possibly lost: 0
> b= ytes in 0 blocks<br>=3D=3D486=3D=3D still reachable:
> 115 = bytes in 6
> blocks<br>=3D=3D486=3D=3D &nb=
> sp; suppressed: 0 bytes in 0 blocks<br>=3D=3D486=3D=3D Reachable
> bloc= ks (those to which a pointer was found) are not
> shown.<br>=3D=3D486=3D=3D T= o see them, rerun with: --leak-check=3Dfull
> --show-reachable=3Dyes<br>=3D= =3D486=3D=3D <br>=3D=3D486=3D=3D For
> counts of detected and suppressed erro= rs, rerun with:
> -v<br>=3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex= ts
> (suppressed: 71 from 13)<br><br><br><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
7 years, 7 months
Re: (ITS#7606) reference through null pointer and memory leak
by jdhgit＠yahoo.com
--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><br=
> CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/ --e=
nable-overlays=3Dyes --enable-slapd --enable-debug<br><br>Start server: <br=
><br> valgrind --leak-check=3Dfull openldap/servers/slapd/slapd<br><b=
r>Perform search with sorted, paged results. Repeating the command will cau=
se the leaked memory to grow. I'm using:<br><br> 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'<br><br>At the prompt, type ctrl-C.<br><br>Kill t=
he slapd process. The output of valgrind shows the following:<br><br>=3D=3D=
486=3D=3D <br>=3D=3D486=3D=3D HEAP SUMMARY:<br>=3D=3D486=3D=3D &=
nbsp; in use at exit: 95,262 bytes in 1,984 blocks<br>=3D=3D486=3D=3D=
total heap usage: 34,975 allocs, 32,991 frees, 22,150,370 byte=
s allocated<br>=3D=3D486=3D=3D <br>=3D=3D486=3D=3D 394 (16
direct, 378 indirect) bytes in 1 blocks are definitely lost in loss record=
7 of 10<br>=3D=3D486=3D=3D at 0x4027282: malloc (vg_repl=
ace_malloc.c:270)<br>=3D=3D486=3D=3D by 0x82228BF: ber_me=
malloc_x (memory.c:228)<br>=3D=3D486=3D=3D by 0x822290C: =
ber_memalloc (memory.c:244)<br>=3D=3D486=3D=3D by 0x81EAC=
29: tavl_insert (tavl.c:94)<br>=3D=3D486=3D=3D by 0x81C7F=
E9: sssvlv_op_response (sssvlv.c:760)<br>=3D=3D486=3D=3D =
by 0x8084184: slap_response_play (result.c:491)<br>=3D=3D486=3D=3D &nb=
sp; by 0x80859AE: slap_send_search_entry (result.c:995)<br>=3D=3D486=
=3D=3D by 0x810BDD6: bdb_search (search.c:1014)<br>=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)<br>=3D=3D486=3D=3D by 0x80F1443: over_op_search (ba=
ckover.c:750)<br>=3D=3D486=3D=3D by 0x80748AE: fe_op_sear=
ch
(search.c:402)<br>=3D=3D486=3D=3D <br>=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<br>=3D=3D486=3D=3D at 0x4027282: malloc (vg_replace_ma=
lloc.c:270)<br>=3D=3D486=3D=3D by 0x82228BF: ber_memalloc=
_x (memory.c:228)<br>=3D=3D486=3D=3D by 0x822290C: ber_me=
malloc (memory.c:244)<br>=3D=3D486=3D=3D by 0x81EAB3A: ta=
vl_insert (tavl.c:69)<br>=3D=3D486=3D=3D by 0x81C7FE9: ss=
svlv_op_response (sssvlv.c:760)<br>=3D=3D486=3D=3D by 0x8=
084184: slap_response_play (result.c:491)<br>=3D=3D486=3D=3D &nb=
sp; by 0x80859AE: slap_send_search_entry (result.c:995)<br>=3D=3D486=3D=3D&=
nbsp; by 0x810BDD6: bdb_search (search.c:1014)<br>=3D=3D486=3D=
=3D by 0x80F11DB: overlay_op_walk (backover.c:671)<br>=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)<br>=3D=3D486=3D=3D by 0x80748AE: fe_op_=
search (search.c:402)<br>=3D=3D486=3D=3D <br>=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<br>=3D=3D486=3D=3D possibly lost: 0 b=
ytes in 0 blocks<br>=3D=3D486=3D=3D still reachable: 115 =
bytes in 6 blocks<br>=3D=3D486=3D=3D &nb=
sp; suppressed: 0 bytes in 0 blocks<br>=3D=3D486=3D=3D Reachable bloc=
ks (those to which a pointer was found) are not shown.<br>=3D=3D486=3D=3D T=
o see them, rerun with: --leak-check=3Dfull --show-reachable=3Dyes<br>=3D=
=3D486=3D=3D <br>=3D=3D486=3D=3D For counts of detected and suppressed erro=
rs, rerun with: -v<br>=3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex=
ts (suppressed: 71 from 13)<br><br><br><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--
7 years, 7 months
Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by pierangelo.masarati＠polimi.it
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=co...
> http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=te...
>
> 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
7 years, 7 months
(ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de
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=co...
http://www.cksoft.de/paste/374f18f905d53f8e6e158702e686b563/slapcat-dc=te...
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
7 years, 7 months
