openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by Frank.Swasey＠uvm.edu 05 Dec '13

05 Dec '13

--Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 4, 2013, at 9:58 PM, quanah(a)zimbra.com wrote: > --On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu = <hyc(a)symas.com>=20 > wrote: >=20 >> 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) >>>=20 >>>=20 >>> 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): >>=20 >> 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. >=20 > There is no backend matching cn=3Daccesslog. There is only "" and=20 > "cn=3Dmonitor" on this particular server. The goal here was not to = export a=20 > subtree, it was something trying to export the delta-syncrepl = accesslog on=20 > a server that didn't have one. That should result in an error, not = match=20 > the primary db rooted at "". I certainly wouldn't expect -n 3 to = default=20 > to -n 1 if -n 3 doesn't exist. Neither should -b "cn=3Daccesslog" = default to=20 > -b "". Those clearly do not match. Well, but -b is working as documented. Sadly, the -s parameter is = deprecated - so, that really shouldn't be used either. Therefore, since = -b simply grabs the -n that would contain the suffix specified (doesn't = do an exact suffix match and fail if not found as you wanted, Quanah) = and -s is deprecated - how is one to accomplish this in the future? Frank --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSoH4GAAoJEMOj4l6rFnCNMy0QAIpAf0e2XJ5T6/sX2lnaP+ms DCXvsxIRjy5F/vBKT1VLt0Z9pj6N1fSpnwYg66rViyaN2A3I/2BJfhz2u3V6ita7 /NeGgt2wEuS1OoVtULlapz1OAf91KuEASw7QLff2QmB3yS2Y3YGVom4Yu/h4EC0h aEBVKL088gbytJ19mPbRYN+7HYdcbO+QWiMvZER53wSvTV96vkOHFcUcXQf5fj6z 7QSMLzA9JUFFjYbYpvdjqtE9UqpPgLRLwIihbzN0DTX6HNavYGWPEzQGrMvvoUoN EP4uWNEGzfeV++yE0PiChGHtyqS/Q94nIQ6P815jBxN583oAtxTfIz6nFOyk4hV4 RhkdpH36z77S1k/KgWbATt5bUvF/wRzIb3pXY0968gC2XHVfh/KzQtLYcOUNCSBG yFGbUz9MyBNlicfjlKaDtetHkXUTvS5u8hlx9jO/Ik9L0ZBSzUuWSTQpwt8FXY6T WTFjeugu/vqxOrRS2/0yrrrT65Z9MbGt32aKk4QwaZOXDJVAoE5o1WScfQsCeX1G 6DBEC/Y1LXgMcOMCs8aKnzQolnMXAiNz1wuMAMDC8ffSYgA34VR4keCKXcmzonKT kkiuLCJG2s28vQQrtpwlbnd+OYtAmtBBHcafHZvvYUreap3DlOhbuhbC19QvqCSh 9WzShIf7BJeIQW/5xeGk =2cju -----END PGP SIGNATURE----- --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062--

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by quanah＠zimbra.com 04 Dec '13

04 Dec '13

--On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu <hyc(a)symas.com> wrote: > 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. There is no backend matching cn=accesslog. There is only "" and "cn=monitor" on this particular server. The goal here was not to export a subtree, it was something trying to export the delta-syncrepl accesslog on a server that didn't have one. That should result in an error, not match the primary db rooted at "". I certainly wouldn't expect -n 3 to default to -n 1 if -n 3 doesn't exist. Neither should -b "cn=accesslog" default to -b "". Those clearly do not match. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by hyc＠symas.com 04 Dec '13

04 Dec '13

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/

1 0

(ITS#7758) slapcat exports entire databases when given a non-existent base
by quanah＠OpenLDAP.org 04 Dec '13

04 Dec '13

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)

1 0

Re: (ITS#7757) Memory leak
by huaraz＠moeller.plus.com 03 Dec '13

03 Dec '13

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/

1 0

Re: (ITS#7757) Memory leak
by hyc＠symas.com 03 Dec '13

03 Dec '13

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/

1 0

(ITS#7757) Memory leak
by huaraz＠moeller.plus.com 03 Dec '13

03 Dec '13

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)

1 0

Re: (ITS#7756) LMDB assertion failed in mdb_page_search_root
by hyc＠symas.com 29 Nov '13

29 Nov '13

xramtsov(a)gmail.com wrote: > Full_Name: Evgeny Khramtsov > Version: LMDB 0.9.10 > OS: Debian Linux 3.10-3-amd64 SMP > URL: http://kuku.jabber.ru/~xram/lmdb_bug.tar.gz > Submission from: (NULL) (198.211.126.52) > > > The way to reproduce the crash: > 1) Write lots of key/vals such as "0", "1", "2", ..., "5000000" (all are "", but > this is irrelevant). > 2) Delete them in the same order. > 3) Get: mdb.c:4682: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - > ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed. > > On the url there is an example program reproducing the bug. > Unpack the tarball: > $ tar -xzf lmdb_bug.tar.gz > $ cd lmdb_bug > $ make > $ ./bug /path/to/some/non_existent/dir Thanks for the report. This is now fixed in git mdb.master. -- -- 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#7756) LMDB assertion failed in mdb_page_search_root
by xramtsov＠gmail.com 28 Nov '13

28 Nov '13

Full_Name: Evgeny Khramtsov Version: LMDB 0.9.10 OS: Debian Linux 3.10-3-amd64 SMP URL: http://kuku.jabber.ru/~xram/lmdb_bug.tar.gz Submission from: (NULL) (198.211.126.52) The way to reproduce the crash: 1) Write lots of key/vals such as "0", "1", "2", ..., "5000000" (all are "", but this is irrelevant). 2) Delete them in the same order. 3) Get: mdb.c:4682: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed. On the url there is an example program reproducing the bug. Unpack the tarball: $ tar -xzf lmdb_bug.tar.gz $ cd lmdb_bug $ make $ ./bug /path/to/some/non_existent/dir

1 0

(ITS#7755) not replicated nodes after recovery
by dmitrii.fonariuk＠gmail.com 26 Nov '13

26 Nov '13

Full_Name: Dmitrii Fonariuk Version: 2.4.38 OS: RHEL6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1) hi. I have two servers in Multi-Master mode (type=refreshAndPersist) 1. I add's one DN (DN=1) on first node, after replication i see DN=1 on both nodes. 2. I've done backup via mdb_copy on 1st node. 3. After that i add's one DN on 2nd node (DN=2) and one DN on 1st node (DN=3). 4. I see DN=1, DN=2, DN=3 on both nodes and the same contextCSN. 5. I stop the slapd on 1st node and do recovery from last backup. 6. Start slapd. 7. Now I see DN=1, DN=2, DN=3 on 2nd node and DN=1, DN=2 on 1nd node and the same contextCSN. Why DN=3, added after backup on 1st node doesn't replicated from 2nd node? if i on 6 step start slapd with -c rid=001 - all OK. (performed long time if a lot of data) if i on 6 step before start slapd change his serverID on different value - all OK. (not suitable) I can conclude that the back is not replicated that DN, entryCSN value that matches the value serverID. This is a bug or a feature?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs