openldap-bugs July 2009

openldap-bugs@openldap.org

49 participants
166 discussions

(ITS#6222) Add "unlimited" option for cachesize settings
by quanah＠zimbra.com 22 Jul '09

22 Jul '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Now that we have multiple cache sizes, it would be extremely useful, particularly with dncachesize, to be able to specify an "unlimited" setting, so that the 2.3 behavior can be easily replicated. Also so that people who have systems with plenty of RAM can just set it once. In particular, I've noticed in 2.3->2.4 upgrades, if dncachesize is particularly small in relation to the size of the database, slapd is essentially unusable. I'd rather see dncachesize default to unlimited if it isn't set (2.3 behavior), and people can tune it down from there if they need to do so. This allows slapd to remain usable without severely impacting the ability of slapd to function. It is so bad, that it becomes impossible to modify cn=config via ldap commands, and you have to stop slapd and manually hack the cn=config text files to return slapd to a usable state.

1 0

Re: (ITS#6220) Problem with writetimeout
by moenoel＠informatik.uni-bremen.de 22 Jul '09

22 Jul '09

Howard Chu wrote: > moenoel(a)informatik.uni-bremen.de wrote: >> Full_Name: Christian Manal >> Version: 2.4.17 >> OS: SunOS 5.10 Generic_139556-08 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) >> >> >> Clients that take a long time to process search results are geting a >> writetimeout, even though the keyword is unset or 0 in slapd.conf. >> Setting the >> value to a big enough number solves the problem, but that behavior >> doesn't >> conform to the docs. >> >> Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of >> entries from the directory, but failed sporadically on slow systems since >> updating to OpenLDAP 2.4.17. >> >> Backend is hdb using BDB 4.4 from opencsw repository. Server setup is >> one master >> and four slaves on Solaris 10. > > Thanks for the report, this is now fixed in CVS HEAD. > I just tested it and can confirm that it works now. Thank you. Regards, Christian Manal

1 0

Re: (ITS#6145) Resource leaks shown when running cppcheck against openldap
by hyc＠symas.com 21 Jul '09

21 Jul '09

Paul Albert wrote: > Even if these are one shot commands, it could still mask a potential > problem that comes up in a later release that does have a real leak (think why any programmer doesn't want any warnings in his code when building). Would you consider making the changes if I were to get you a patch to fix all of these problems? If I were to do this, would you like one patch to cover the entire fix or a patch per file? Thanks for the offer. The use of scanf() in getpass.c was in code that was never actually compiled before. Due to ITS#4643 I've removed the obsolete scanf() calls. The assignment error detected in slapi_utils.c is wrong, there is no error in this code. Your tool needs to be fixed. dsaschema is a contrib module; you're welcome to submit a patch for that. The code in thr_debug.c is not compiled by default; any developer who uses it is expected to know what they're doing. Since the only way to free the table being allocated is by use of something like an atexit() handler, and those things tend to be non-portable, it's best left alone. The code in tests/progs is never installed, it's only for internal testing (and again, it's all one-shot commands) so none of that is of any concern. ldapdelete.c and ldapmodrdn.c are now fixed in HEAD. >> sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . >> [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp >> [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn >> [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn >> [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp >> [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: >> saveline >> [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t >> [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use >> 'fgets' instead >> [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use >> 'fgets' instead >> [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an >> auto-variable to an effective parameter of a function >> [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager >> [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename >> [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager >> [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry >> [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry >> [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase >> [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter -- -- 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#4643 getpass()
by hyc＠symas.com 21 Jul '09

21 Jul '09

Since getpass() has been dropped from POSIX and is now considered unsafe, I've decided to remove all detection of it. I've reworked the implementation of lutil_getpass() which is used instead, when getpassphrase() is not present. In addition to streamlining the code, I've removed the Merit-specific use of telnet control codes, since that was specifically for a long obsolete deployment at UMich (most likely the old ud client which was deleted from the OpenLDAP tree years ago). -- -- 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#6202) adding command line option to disable line breaking in ldif output
by hyc＠symas.com 21 Jul '09

21 Jul '09

dieter(a)bloms.de wrote: > Hi, > > On Thu, Jul 09, Michael Str=F6der wrote: > >>> I want to do an enhancement request for ldapsearch, because it insert a= > line >>> break after 78 characters. >>> Many people like me use the ldapsearch command in shell script and have= > to >>> workaround this issue. >>> Maybe it make sense to add a command line option to deactivate this lin= > e breaks. >> =20 >> I'd rather recommend to use a decent scripting language with LDAP and/or >> LDIF modules than using ldapsearch in shell scripts. This gives better >> control over data and error handling. > > there are several ldapsearch binaries from other distributor, which > includes an option -T for this concern. > > http://www.koders.com/c/fidD1B671B4DA7CB116CA077E4694EEBAE167D3F85E.aspx > http://docs.sun.com/source/816-6400-10/lsearch.html > =2E.. > > so why doesn't ldapsearch from openldap inlcude this option. > It doesn't break any rfc and historcal implementation and as far as I > can see (with google), there are many admins who have to workaround this > with a little perl script. > > I think it must be a little diff, with a few lines > > I can write it, but is someone willing to inlcude it in the upstream > versions ? It has already been written, see ITS#6149. Closing this ITS as a dup. Since the LDIF spec says that lines MAY be folded, any script that processes LDIF MUST be able to handle folded lines correctly. As such, there is nothing to gain from changing things at this late date, IMO. Other folks may have different opinions, but I don't think the ITS is the place to discuss this. -- -- 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#6214) slapacl causes bdb_db_close error
by hyc＠symas.com 21 Jul '09

21 Jul '09

dkastens(a)uni-osnabrueck.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.17 > OS: Red Hat Enterprise Linux Server release 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.173.16.92) > > > I'm using BerkeleyDB.4.6.21 > This issue existed in openldap 2.4.16, so I updated to 2.4.17, but the error > still exists. It seems no one else encountered the problem or reported it against 2.4.16 before... Anyway, thanks for the report, it's now fixed in CVS HEAD. > When I call "slapacl", for example > slapacl -b uid=xmuster,ou=people,dc=myorg -D uid=xmuster,ou=people,dc=myorg > the output ends with the lines: > > bdb(dc=myorg): Error: closing the transaction region with active transactions > bdb_db_close: database "dc=myorg": close failed: Invalid argument (22) > > and the database is corrupted. slapd wasn't running during execution. After > running slapacl slapd starts with the message: > > bdb_db_open: database "dc=myorg": unclean shutdown detected; attempting > recovery. > > This seems to be an old but re-occuring bug. > -- -- 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#6220) Problem with writetimeout
by hyc＠symas.com 21 Jul '09

21 Jul '09

moenoel(a)informatik.uni-bremen.de wrote: > Full_Name: Christian Manal > Version: 2.4.17 > OS: SunOS 5.10 Generic_139556-08 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) > > > Clients that take a long time to process search results are geting a > writetimeout, even though the keyword is unset or 0 in slapd.conf. Setting the > value to a big enough number solves the problem, but that behavior doesn't > conform to the docs. > > Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of > entries from the directory, but failed sporadically on slow systems since > updating to OpenLDAP 2.4.17. > > Backend is hdb using BDB 4.4 from opencsw repository. Server setup is one master > and four slaves on Solaris 10. Thanks for the report, this is now fixed in CVS HEAD. -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

On Tue, 2009-07-21 at 11:17 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: > >> steve(a)falchion.com wrote: > >>> 2.4.17 fails in an identical manner. > >>> > >>> For those interested, 2.4.17 failed to compile because the installed > >>> 2.4.16 libs were being picked up instead of the freshly compiled ones > >>> during the link phase. > >> > >> Looks like a problem in your OpenSSL build, not in OpenLDAP. > > > > Any ideas what that problem might be or what leads you to believe this? > > The backtrace shows that these SSL functions are contained inside your > libldap_r shared library object file. Usually they should be present in > OpenSSL's own shared libraries. If OpenSSL was only provided as a static > library, it's not clear that their code will behave correctly when used inside > a shared library (i.e., PIC vs non-PIC dependencies). Thanks for that info. I apologize for my ignorance but I got out of code development 15-20 years ago. Would it help if I compiled slapd statically? Is there an option for that in configure? > > > Unfortunately this OpenSSL is the one distributed by IBM as part of the > > AIX operating system, so it's not really my build... If I'm going to go > > to them with this, I could use a little more ammo :) > > It would also help if you compile without optimization, with debug symbols, > and run the non-stripped binaries. Your backtraces are lacking a lot of info > at the moment. I re-configured with --enable-debug and re-compiled, then ran slapd from the servers/slapd directory and got the following backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] 0xd2514a34 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) (gdb) bt #0 0xd2514a34 in SSL_CTX_set_info_callback () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #1 0xd2512118 in tlso_ctx_init () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #2 0xd250e70c in ldap_int_tls_init_ctx () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #3 0xd2510400 in ldap_pvt_tls_set_option () from /LDAP/build/openldap-2.4.17/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) #4 0x10001fb0 in main () To my relatively untrained eye this doesn't look much different from the original. Can you give me an example of how I could compile and run to produce a better stack trace? I couldn't find documentation of that sort on the OpenLDAP web page... Thanks again, Steve > > > > > Steve > > > >>> > >>> Steve > >>> > >>> On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > >>>> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > >>>> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > >>>> > >>>> Steve > >>>> > >>>> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > >>>>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > >>>>> <steve(a)falchion.com> wrote: > >>>>> > >>>>>> Haven't tried it. is it stable now (or soon to be?) > >>>>> > >>>>> I'd assume that depends on what bugs people report against it. Knowing > >>>>> whether or not this affects 2.4.17 would certainly be useful in that > >>>>> determination. ;) > >>>>> > >>>>> --Quanah > >> > > > > > >

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by hyc＠symas.com 21 Jul '09

21 Jul '09

Steve Paras-Charlton wrote: > On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: >> steve(a)falchion.com wrote: >>> 2.4.17 fails in an identical manner. >>> >>> For those interested, 2.4.17 failed to compile because the installed >>> 2.4.16 libs were being picked up instead of the freshly compiled ones >>> during the link phase. >> >> Looks like a problem in your OpenSSL build, not in OpenLDAP. > > Any ideas what that problem might be or what leads you to believe this? The backtrace shows that these SSL functions are contained inside your libldap_r shared library object file. Usually they should be present in OpenSSL's own shared libraries. If OpenSSL was only provided as a static library, it's not clear that their code will behave correctly when used inside a shared library (i.e., PIC vs non-PIC dependencies). > Unfortunately this OpenSSL is the one distributed by IBM as part of the > AIX operating system, so it's not really my build... If I'm going to go > to them with this, I could use a little more ammo :) It would also help if you compile without optimization, with debug symbols, and run the non-stripped binaries. Your backtraces are lacking a lot of info at the moment. > > Steve > >>> >>> Steve >>> >>> On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: >>>> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work >>>> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? >>>> >>>> Steve >>>> >>>> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: >>>>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton >>>>> <steve(a)falchion.com> wrote: >>>>> >>>>>> Haven't tried it. is it stable now (or soon to be?) >>>>> >>>>> I'd assume that depends on what bugs people report against it. Knowing >>>>> whether or not this affects 2.4.17 would certainly be useful in that >>>>> determination. ;) >>>>> >>>>> --Quanah >> > > -- -- 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#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 21 Jul '09

21 Jul '09

On Tue, 2009-07-21 at 10:32 -0700, Howard Chu wrote: > steve(a)falchion.com wrote: > > 2.4.17 fails in an identical manner. > > > > For those interested, 2.4.17 failed to compile because the installed > > 2.4.16 libs were being picked up instead of the freshly compiled ones > > during the link phase. > > Looks like a problem in your OpenSSL build, not in OpenLDAP. Any ideas what that problem might be or what leads you to believe this? Unfortunately this OpenSSL is the one distributed by IBM as part of the AIX operating system, so it's not really my build... If I'm going to go to them with this, I could use a little more ammo :) Steve > > > > Steve > > > > On Mon, 2009-07-20 at 20:04 -0700, Steve Paras-Charlton wrote: > >> Currently 2.4.17 fails to compile under AIX 5.3TL10, so I'll try to work > >> on it, but in the meantime, any ideas why 2.4.16 is crashing thus? > >> > >> Steve > >> > >> On Mon, 2009-07-20 at 15:58 -0700, Quanah Gibson-Mount wrote: > >>> --On Monday, July 20, 2009 3:52 PM -0700 Steve Paras-Charlton > >>> <steve(a)falchion.com> wrote: > >>> > >>>> Haven't tried it. is it stable now (or soon to be?) > >>> > >>> I'd assume that depends on what bugs people report against it. Knowing > >>> whether or not this affects 2.4.17 would certainly be useful in that > >>> determination. ;) > >>> > >>> --Quanah >

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2009