Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by hyc＠symas.com
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.35
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.58.125)
>
>
> If the root of the primary database is "", and you try and export a base that
> doesn't exist via slapcat, the entire database is exported (i.e., it acts like
> you specified "" as the base):
Works as designed. -b selects the backend that matches the DN you provided. A
backend with suffix "" matches anything that nothing more specific matched. If
you wanted to filter down to a specific branch, you should have used -s.
Closing this ITS.
>
> [root@zcs724 ldap]# /opt/zimbra/openldap/sbin/slapcat -b cn=ThisDoesntExist -F
> /opt/zimbra/data/ldap/config -l /tmp/q.test
>
> dn: cn=zimbra
> objectClass: organizationalRole
> description: Zimbra Systems Application Data
> cn: zimbra
> structuralObjectClass: organizationalRole
> entryUUID: 1f75edee-6b87-1032-961f-b17f0b52f5bc
> creatorsName: cn=config
> createTimestamp: 20130617104800Z
> entryCSN: 20130617104800.311168Z#000000#000#000000
> modifiersName: cn=config
> modifyTimestamp: 20130617104800Z
>
> dn: cn=admins,cn=zimbra
> objectClass: organizationalRole
> description: admin accounts
> cn: admins
> structuralObjectClass: organizationalRole
> entryUUID: 1f7d451c-6b87-1032-9620-b17f0b52f5bc
> creatorsName: cn=config
> createTimestamp: 20130617104800Z
> entryCSN: 20130617104800.359221Z#000000#000#000000
> modifiersName: cn=config
> modifyTimestamp: 20130617104800Z
>
> dn: uid=zimbra,cn=admins,cn=zimbra
> uid: zimbra
> objectClass: zimbraAccount
> objectClass: organizationalPerson
> cn: zimbra
> sn: zimbra
> zimbraAccountStatus: active
> zimbraIsAdminAccount: TRUE
> zimbraIsSystemResource: TRUE
> zimbraId: e0fafd89-1360-11d9-8661-000a95d98ef2
> description: The master zimbra admin account
> userPassword:: text=
> structuralObjectClass: organizationalPerson
> entryUUID: 1f7e29e6-6b87-1032-9621-b17f0b52f5bc
> creatorsName: cn=config
> createTimestamp: 20130617104800Z
> zimbraLastLogonTimestamp: 20131202121011Z
> entryCSN: 20131202121011.054477Z#000000#000#000000
> modifiersName: uid=zimbra,cn=admins,cn=zimbra
> modifyTimestamp: 20131202121011Z
>
>
> (etc)
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
(ITS#7758) slapcat exports entire databases when given a non-existent base
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.35
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.58.125)
If the root of the primary database is "", and you try and export a base that
doesn't exist via slapcat, the entire database is exported (i.e., it acts like
you specified "" as the base):
[root@zcs724 ldap]# /opt/zimbra/openldap/sbin/slapcat -b cn=ThisDoesntExist -F
/opt/zimbra/data/ldap/config -l /tmp/q.test
dn: cn=zimbra
objectClass: organizationalRole
description: Zimbra Systems Application Data
cn: zimbra
structuralObjectClass: organizationalRole
entryUUID: 1f75edee-6b87-1032-961f-b17f0b52f5bc
creatorsName: cn=config
createTimestamp: 20130617104800Z
entryCSN: 20130617104800.311168Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130617104800Z
dn: cn=admins,cn=zimbra
objectClass: organizationalRole
description: admin accounts
cn: admins
structuralObjectClass: organizationalRole
entryUUID: 1f7d451c-6b87-1032-9620-b17f0b52f5bc
creatorsName: cn=config
createTimestamp: 20130617104800Z
entryCSN: 20130617104800.359221Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130617104800Z
dn: uid=zimbra,cn=admins,cn=zimbra
uid: zimbra
objectClass: zimbraAccount
objectClass: organizationalPerson
cn: zimbra
sn: zimbra
zimbraAccountStatus: active
zimbraIsAdminAccount: TRUE
zimbraIsSystemResource: TRUE
zimbraId: e0fafd89-1360-11d9-8661-000a95d98ef2
description: The master zimbra admin account
userPassword:: text=
structuralObjectClass: organizationalPerson
entryUUID: 1f7e29e6-6b87-1032-9621-b17f0b52f5bc
creatorsName: cn=config
createTimestamp: 20130617104800Z
zimbraLastLogonTimestamp: 20131202121011Z
entryCSN: 20131202121011.054477Z#000000#000#000000
modifiersName: uid=zimbra,cn=admins,cn=zimbra
modifyTimestamp: 20131202121011Z
(etc)
9 years, 5 months
Re: (ITS#7757) Memory leak
by huaraz＠moeller.plus.com
That was quick ! And my leak is gone.
Thank you
Markus
-----Original Message-----
From: Howard Chu
Sent: Tuesday, December 03, 2013 10:17 PM
To: huaraz(a)moeller.plus.com ; openldap-its(a)openldap.org
Subject: Re: (ITS#7757) Memory leak
huaraz(a)moeller.plus.com wrote:
> Full_Name:
> Version: 2.4.33
> OS: OpenSuSe 12.3
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2a01:348:1f9::11)
>
>
> I identified a memory leak when using sasl
>
> ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost
> in
> loss record 561 of 666
> ==14039== at 0x4C2C27B: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==14039== by 0x558E764: ber_memalloc_x (memory.c:228)
> ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582)
> ==14039== by 0x558AFF5: ber_scanf (decode.c:806)
> ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327)
> ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551)
> ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474)
> ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511)
> ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338)
A fix for this is now in git master (rev
f8efeb42783f958dd0dc997f8084e6b3b4502830 )
Please test and report your results, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
Re: (ITS#7757) Memory leak
by hyc＠symas.com
huaraz(a)moeller.plus.com wrote:
> Full_Name:
> Version: 2.4.33
> OS: OpenSuSe 12.3
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2a01:348:1f9::11)
>
>
> I identified a memory leak when using sasl
>
> ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in
> loss record 561 of 666
> ==14039== at 0x4C2C27B: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==14039== by 0x558E764: ber_memalloc_x (memory.c:228)
> ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582)
> ==14039== by 0x558AFF5: ber_scanf (decode.c:806)
> ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327)
> ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551)
> ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474)
> ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511)
> ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338)
A fix for this is now in git master (rev
f8efeb42783f958dd0dc997f8084e6b3b4502830 )
Please test and report your results, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 5 months
(ITS#7757) Memory leak
by huaraz＠moeller.plus.com
Full_Name:
Version: 2.4.33
OS: OpenSuSe 12.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2a01:348:1f9::11)
I identified a memory leak when using sasl
==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in
loss record 561 of 666
==14039== at 0x4C2C27B: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14039== by 0x558E764: ber_memalloc_x (memory.c:228)
==14039== by 0x558A8B7: ber_get_stringal (decode.c:582)
==14039== by 0x558AFF5: ber_scanf (decode.c:806)
==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327)
==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551)
==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474)
==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511)
==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338)
9 years, 5 months