openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by quanah＠symas.com 22 Mar '17

22 Mar '17

--On Wednesday, March 22, 2017 8:11 PM +0000 hyc(a)symas.com wrote: > subbarao(a)computer.org wrote: >> Full_Name: Kartik Subbarao >> Version: 2.4.44 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (108.52.86.252) >> >> >> A recent 2.4.44 package build failed on a VM due to the following timing >> dependency between the lockout and expiration tests in test022-ppolicy. > > Clocks on VMs are notoriously unstable, which is why we have always used > such large margins in these tests. Shaving things down to "1 second more > than needed" will probably break in multiple build environments. Even better is to use the SLEEP variables instead of hard coded values. Then they can be overridden in the test environment if necessary for specific VMs. At the moment we have: quanah@ub16:~/git/openldap/openldap-head/tests/scripts$ grep SLEEP defines.sh SLEEP0=${SLEEP0-1} SLEEP1=${SLEEP1-7} SLEEP2=${SLEEP2-15} It may be useful to add things like SLEEP10, SLEEP20, etc, and rebase tests off of that. 1/7/15 seem rather odd increments (no pun intended!). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by hyc＠symas.com 22 Mar '17

22 Mar '17

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.52.86.252) > > > A recent 2.4.44 package build failed on a VM due to the following timing > dependency between the lockout and expiration tests in test022-ppolicy. Clocks on VMs are notoriously unstable, which is why we have always used such large margins in these tests. Shaving things down to "1 second more than needed" will probably break in multiple build environments. > > The problem is that the password expiration time is 30 seconds, and on slower > VMs, lines 67-91 take more than 30 seconds to execute. This causes the password > to expire by the time the ldapsearch command on line 93 is executed. That > ldapsearch command eats up one of the grace logins that's not supposed to be > consumed until line 106. This causes the grep count on line 124 to be off, > failing the entire script. > > A simple improvement would be to change line 91 to "sleep 10" instead of the > current "sleep 20". This would buy 10 more seconds of leeway on slower VMs, > while guaranteeing sufficient delay between lines 67-90 (e.g. 16 seconds, 1 > second more than the 15 second lockout time) on fast VMs. A more robust > improvement would be to check how much time has actually elapsed between lines > 67-90 and change line 91 to only sleep until 16 total seconds have elapsed since > line 67. > > Another suggestion would be to change the "sleep 20" on line 104 to "sleep 15". > That will shave 5 seconds off the build time for everyone, while still > guaranteeing that 31 seconds (e.g. 1 second more than the 30 second expiration > time) will have elapsed between lines 67-106). > > A further optimization could be implemented, if desired, by revisiting the test > and reducing all lockout times, expiration times, and other delays to the bare > minimum necessary, which would speed up package build times across the board. > > -- -- 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#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by h.b.furuseth＠usit.uio.no 22 Mar '17

22 Mar '17

I wrote: > URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html malloc (sizeof (KeyDataType) * recordCount); in the test program should be calloc (recordCount, sizeof (KeyDataType)); to avoid writing uninit'ed data. And the test can be a lot smaller and faster: static long size = 50000000; static int recordCount = 600000; static int majorIdCount = 2500; static int minorIdCount = 5000;

1 0

(ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 22 Mar '17

22 Mar '17

Full_Name: Kartik Subbarao Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.52.86.252) A recent 2.4.44 package build failed on a VM due to the following timing dependency between the lockout and expiration tests in test022-ppolicy. The problem is that the password expiration time is 30 seconds, and on slower VMs, lines 67-91 take more than 30 seconds to execute. This causes the password to expire by the time the ldapsearch command on line 93 is executed. That ldapsearch command eats up one of the grace logins that's not supposed to be consumed until line 106. This causes the grep count on line 124 to be off, failing the entire script. A simple improvement would be to change line 91 to "sleep 10" instead of the current "sleep 20". This would buy 10 more seconds of leeway on slower VMs, while guaranteeing sufficient delay between lines 67-90 (e.g. 16 seconds, 1 second more than the 15 second lockout time) on fast VMs. A more robust improvement would be to check how much time has actually elapsed between lines 67-90 and change line 91 to only sleep until 16 total seconds have elapsed since line 67. Another suggestion would be to change the "sleep 20" on line 104 to "sleep 15". That will shave 5 seconds off the build time for everyone, while still guaranteeing that 31 seconds (e.g. 1 second more than the 30 second expiration time) will have elapsed between lines 67-106). A further optimization could be implemented, if desired, by revisiting the test and reducing all lockout times, expiration times, and other delays to the bare minimum necessary, which would speed up package build times across the board.

1 0

RE: (ITS#8402) indexing issue
by quanah＠symas.com 22 Mar '17

22 Mar '17

--On Wednesday, April 13, 2016 5:00 PM +0000 escriba(a)cells.es wrote: > Mail system message that raised the alarm: > > Reporting-MTA: dns; mail01.xxxx.xx > X-Postfix-Queue-ID: 24C5526003F > X-Postfix-Sender: rfc822; xxxxx at xxx .xy > Arrival-Date: Wed, 13 Apr 2016 16:30:34 +0200 (CEST) > > Final-Recipient: rfc822; xxxxx @ xxx .xy > Original-Recipient: rfc822; xxxxxx at xxx .xy > Action: failed > Status: 5.1.1 > Remote-MTA: dns; mail02.xxxx.xx > Diagnostic-Code: smtp; 550 5.1.1 <xxxxxxx at xxx .xy >: Recipient address > rejected: User unknown in local recipient table > > >> From my point of view indexing, even if not needed, may never do the >> queries > fail, isn't it? > But seems something weird happened. Hello, I would note that you reported using a very ancient version of OpenLDAP (2.4.23, released June 2010). It's possible you encountered a bug that has long since been fixed. I would advise using a current release of OpenLDAP. If you still encounter the same issue with indices, then please follow up to this ITS. In the meantime, this ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8451) slapd[27939]: connection_input: conn=1295612 deferring operation: binding
by quanah＠symas.com 22 Mar '17

22 Mar '17

Hello, The ITS system is for reporting bugs with OpenLDAP, rather than help/configuration requests such as what was filed in your report. In the future, please use the OpenLDAP technical mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8546) "allow bind_anon_cred" in slapd.conf does not work as expected
by quanah＠symas.com 22 Mar '17

22 Mar '17

Hello Yelin, The ITS system is for filing bug reports, not for asking help with slapd configuration. The correct resource for configuration questions is the openldap-technical list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> Your understanding of how this feature works is incorrect. As noted in the slapd.conf(5) man page: bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). The option you are looking for in your case is: bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by h.b.furuseth＠usit.uio.no 22 Mar '17

22 Mar '17

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.19, mdb.master OS: Linux x86_64 URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html Submission from: (NULL) (193.157.240.142) Submitted by: hallvard This is Klaus Malorny's test case from openldap-technical (linked below). Compiled with gcc -std=gnu99. Breaks mdv.master and mdb.RE: .... 33000000 records written testing mdb_cursor_get: unexpected error -30796: MDB_CORRUPTED: Located page was wrong type In LMDB 0.9.18, the test case instead asserted: mdb.c:5647: Assertion 'mc->mc_flags & C_INITIALIZED' failed in mdb_cursor_next() That was fixed by commit b46fc3e438d8085d5e5fc7d558c0002ee1e2753c "ITS#8406 fix xcursors after cursor_del". Then it broke again at 6b1df0e4c7fadd21d1233d7157229b2d89ccaa04 "More for ITS#8406 (xcursor fixups)", giving the MDB_CORRUPTED.

1 0

Re: (ITS#8467) LMDB creation
by quanah＠symas.com 20 Mar '17

20 Mar '17

--On Tuesday, July 19, 2016 3:44 PM +0000 potte324(a)umn.edu wrote: > I've been trying to create LMDB files for a particle physics project in > classifying particle interactions. Anyways, I modified an old code used to > create levelDB files from a TTree in the Root software developed by CERN > using c++. Then, I tried to run the neural net on the lmdb files and it > gave me an error that std::string_length was too large. And I tried to > show the images I had saved in it and it didn't show me anything, whereas > on an LMDB file I had from one of the caffe tutorials it did show me the > image. > > Do you have any ideas of what could be wrong? It think it is likely that I > messed something up and can't find a lot of documentation for building > LMDB files. In addition, I'm fairly new to coding and I had a hard time > reading the API page due to this. If you have any ideas of how to help > that would be great. Hi Jordan, The ITS system is for reporting bugs, rather than asking for help with programming questions, etc. The correct place for such questions would be the openldap-technical mailing list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8621) Unique through multiple attribute
by quanah＠symas.com 20 Mar '17

20 Mar '17

--On Sunday, March 19, 2017 12:07 AM +0000 michael(a)stroeder.com wrote: > I'd say it works as designed and there is no bug. > > The work-around for your use-case is to use SUP to derive from a common > attribute type. But this should be discussed on openldap-technical > mailing list. Agreed. I've moved this to the enhancement queue in case anyone ever wants to work on enforcing uniqueness across > 1 attribute, but I would think that would require all of the attributes to have the same syntax, etc. Michael's suggestion for this specific use case seems to be the best solution for now. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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