openldap-bugs July 2009

openldap-bugs@openldap.org

49 participants
166 discussions

Re: (ITS#6223) [patch] snprint() fix in guess_service_principal()
by hyc＠symas.com 24 Jul '09

24 Jul '09

jerry(a)plainjoe.org wrote: > Correction to the URL. Should be: > ftp://ftp.openldap.org/incoming/openldap-2.4.16-guess_service_principal.diff That file is zero bytes long. Did we run out of space on ftp.openldap.org again? -- -- 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 24 Jul '09

24 Jul '09

Thanks for the encouragement Michael :) For those who find this in searches to come, I compiled OpenSSL (0.9.8k) myself and the problem is resolved. Not sure if this is a bug fixed between 0.9.8h and 0.9.8k or something weird that IBM did when building the package, but all is well now. Steve=20 On Fri, 2009-07-24 at 13:24 +0200, Michael Str=C3=B6der wrote: > steve(a)falchion.com wrote: > > Now you might tell me (as you've already implied) to compile my own SSL > > libraries, >=20 > Being in your situation I'd try that. >=20 > > which I may try, but doing so opens me up to a world of > > interop issues as IBM tends to compile their tools with links to > > specific versions of shared libraries (I've been there and done that in > > AIX this year once already). >=20 > You could build all the necessary libs (Berkeley DB, OpenSSL, > cyrus-sasl, heimdal etc.) and install them in a separate prefix without > conflicting with any pre-installed libs. I'd go that route and did that > on e.g. old Solaris platforms. And I think it would be feasible for me > even though I'm not an C programmer. >=20 > > Do I sound frustrated yet? Cause I am... >=20 > Sometimes things are hard. But just don't give up! >=20 > Ciao, Michael.

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by hyc＠symas.com 24 Jul '09

24 Jul '09

Fixed now in CVS HEAD. mbuschman(a)cashnetusa.com wrote: > Full_Name: Marshall Buschman > Version: 2.4.17 > OS: Debian Etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.98.177.132) > > I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the > autogroup overlay, and I get the following error when I do an ldapsearch: > > $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com > # extended LDIF > ... > # search result > search: 2 > result: 53 Server is unwilling to perform > text: operation not supported within namingContext > > Relevant config: > ---------------------------------------------- > moduleload autogroup > > database bdb > suffix "dc=cashnetusa,dc=com" > > overlay autogroup > autogroup-attrset groupOfURLs memberURL member > ---------------------------------------------- > > OpenLDAP does start normally without the overlay. > -- -- 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#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 24 Jul '09

24 Jul '09

OS is Debian Lenny, not Debian Etch. Apologies. openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6227. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6227) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6227) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6227 > > Please remember to retain your issue tracking number (ITS#6227) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > >

1 0

(ITS#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 24 Jul '09

24 Jul '09

Full_Name: Marshall Buschman Version: 2.4.17 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.98.177.132) I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the autogroup overlay, and I get the following error when I do an ldapsearch: $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com # extended LDIF ... # search result search: 2 result: 53 Server is unwilling to perform text: operation not supported within namingContext Relevant config: ---------------------------------------------- moduleload autogroup database bdb suffix "dc=cashnetusa,dc=com" overlay autogroup autogroup-attrset groupOfURLs memberURL member ---------------------------------------------- OpenLDAP does start normally without the overlay.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by michael＠stroeder.com 24 Jul '09

24 Jul '09

steve(a)falchion.com wrote: > Now you might tell me (as you've already implied) to compile my own SSL > libraries, Being in your situation I'd try that. > which I may try, but doing so opens me up to a world of > interop issues as IBM tends to compile their tools with links to > specific versions of shared libraries (I've been there and done that in > AIX this year once already). You could build all the necessary libs (Berkeley DB, OpenSSL, cyrus-sasl, heimdal etc.) and install them in a separate prefix without conflicting with any pre-installed libs. I'd go that route and did that on e.g. old Solaris platforms. And I think it would be feasible for me even though I'm not an C programmer. > Do I sound frustrated yet? Cause I am... Sometimes things are hard. But just don't give up! Ciao, Michael.

1 0

Re: (ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 23 Jul '09

23 Jul '09

Thank-you, that is much more helpful. I apologize for my rant. I'll join that mailing list and post my issue there. Thanks, Steve On Thu, 2009-07-23 at 15:23 -0700, Howard Chu wrote: > Steve Paras-Charlton wrote: > > Thanks, that was sooo helpful. > > > > What I'm trying to do is port your software package to a platform where > > it obviously fails to work properly using the vendor's supplied SSL > > libraries, and you're giving me a PFO. > > The ITS is for tracking problems in the actual OpenLDAP code base. Since > you're not reporting an actual issue in OpenLDAP code, this is the wrong forum > for this discussion. > > You can get help on interoperability issues elsewhere, e.g. the > openldap-technical mailing list. > > > So now I get to go to IBM and say "your library is broken but I can't > > tell you how/why" (gee... I wonder how that call will go) or abandon > > open source and install their LDAP server package (which is what they'll > > tell me to do anyhow). > > > > Now you might tell me (as you've already implied) to compile my own SSL > > libraries, which I may try, but doing so opens me up to a world of > > interop issues as IBM tends to compile their tools with links to > > specific versions of shared libraries (I've been there and done that in > > AIX this year once already). > > > Do I sound frustrated yet? Cause I am... > > > > Sorry to anyone else who reads this rant. > > You obviously have to ask the right questions to the right people who can > actually help you. We can't fix your OpenSSL build for you. > > > > Steve > > > > On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: > >> Steve Paras-Charlton wrote: > >>> > >>> I tried re-compiling with CC="gcc -g" and got the following backtrace > >>> from gdb: > >>> > >>> Program received signal SIGSEGV, Segmentation fault. > >>> [Switching to Thread 1] > >>> 0xd26d07d0 in SSL_CTX_set_info_callback () > >>> > >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > >>> (gdb) bt > >>> #0 0xd26d07d0 in SSL_CTX_set_info_callback () > >>> > >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) > >>> #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, > >>> is_server=1) at tls_o.c:320 > >>> #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at > >>> tls2.c:245 > >>> #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, > >>> arg=0x2ff22ae8) at tls2.c:800 > >>> #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 > >>> > >>> This one seems much more useful from a debugging perspective. > >>> > >>> I noticed that the configure program has some options along the lines of > >>> "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this > >>> to help debug the issue perhaps? How would I use it (not sure what > >>> options it takes). > >> > >> This trace is the kind that we would normally look for, yes. But the crash is > >> in an OpenSSL function, and you haven't got debug symbols for that since you > >> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, > >> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS > >> will be closed. > >> > > > > > >

1 0

2.4.17 - autogroup overlay breaks searches
by Marshall Buschman 23 Jul '09

23 Jul '09

Hello All: I'm running OpenLDAP 2.4.17+bdb 4.7 on Debian Lenny. I've enabled the autogroup overlay, and I get the following when I do an ldapsearch. Disabling the overlay does fix the issue, but I do need the functionality the overlay provides. $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com # extended LDIF ... # search result search: 2 result: 53 Server is unwilling to perform text: operation not supported within namingContext Relevant config: ---------------------------------------------- moduleload autogroup database bdb suffix "dc=cashnetusa,dc=com" overlay autogroup autogroup-attrset posixGroup memberURL member ---------------------------------------------- Help? -Marshall Buschman

2 1

Re: (ITS#6200)
by hyc＠symas.com 23 Jul '09

23 Jul '09

imf(a)u.washington.edu wrote: > The changes made to 2.4.17 seem to have fixed the crashes in the caching > module. Thanks for that. > > We still are able to crash 2.4.17, however. It only happens after a heavy > load is placed on the producer for>24 hours continuous. Unfortunately, > we've not been able to get good tracebacks. They all look like this, > > (gdb) where > #0 0x00869410 in __kernel_vsyscall () > #1 0x00390d80 in raise () from /lib/libc.so.6 > #2 0x00392691 in abort () from /lib/libc.so.6 > #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 > #4 0x0808d532 in malloc () > #5 0x0822c93f in ?? () > #6 0x0822c933 in ?? () > #7 0x00000039 in ?? () > #8 0x0822c908 in ?? () > #9 0x00000000 in ?? () > > The producer slowly grows its memory footprint. I can't tell if it's from > just normal operations or memory leaks. I suspect it's a little of both. > The end result, as you can see from the core above, is that there's likely > some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down > further. There's not enough information here. An assert is always accompanied by an error message on stderr; we need to see the actual error message. There are no symbols in the stack trace pertaining to slapd itself. You seem to be running a stripped binary. Please provide a trace using a non-stripped binary that was compiled with -g (debug symbols enabled). > > The load profile that we placed on the server is documented in my prior > report. See above. -- -- 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 hyc＠symas.com 23 Jul '09

23 Jul '09

Steve Paras-Charlton wrote: > Thanks, that was sooo helpful. > > What I'm trying to do is port your software package to a platform where > it obviously fails to work properly using the vendor's supplied SSL > libraries, and you're giving me a PFO. The ITS is for tracking problems in the actual OpenLDAP code base. Since you're not reporting an actual issue in OpenLDAP code, this is the wrong forum for this discussion. You can get help on interoperability issues elsewhere, e.g. the openldap-technical mailing list. > So now I get to go to IBM and say "your library is broken but I can't > tell you how/why" (gee... I wonder how that call will go) or abandon > open source and install their LDAP server package (which is what they'll > tell me to do anyhow). > > Now you might tell me (as you've already implied) to compile my own SSL > libraries, which I may try, but doing so opens me up to a world of > interop issues as IBM tends to compile their tools with links to > specific versions of shared libraries (I've been there and done that in > AIX this year once already). > Do I sound frustrated yet? Cause I am... > > Sorry to anyone else who reads this rant. You obviously have to ask the right questions to the right people who can actually help you. We can't fix your OpenSSL build for you. > > Steve > > On Thu, 2009-07-23 at 14:15 -0700, Howard Chu wrote: >> Steve Paras-Charlton wrote: >>> >>> I tried re-compiling with CC="gcc -g" and got the following backtrace >>> from gdb: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 1] >>> 0xd26d07d0 in SSL_CTX_set_info_callback () >>> >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) >>> (gdb) bt >>> #0 0xd26d07d0 in SSL_CTX_set_info_callback () >>> >>> from /LDAP/build/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a(libldap_r-2.4.so.2) >>> #1 0xd26cdedc in tlso_ctx_init (lo=0x200c087c, lt=0x2ff22970, >>> is_server=1) at tls_o.c:320 >>> #2 0xd26ca50c in ldap_int_tls_init_ctx (lo=0x200c087c, is_server=1) at >>> tls2.c:245 >>> #3 0xd26cc1cc in ldap_pvt_tls_set_option (ld=0x200c0878, option=24591, >>> arg=0x2ff22ae8) at tls2.c:800 >>> #4 0x10001f90 in main (argc=9, argv=0x2ff22b94) at main.c:826 >>> >>> This one seems much more useful from a debugging perspective. >>> >>> I noticed that the configure program has some options along the lines of >>> "--with-PIC" which defaults to "both PIC and non-PIC". Could I use this >>> to help debug the issue perhaps? How would I use it (not sure what >>> options it takes). >> >> This trace is the kind that we would normally look for, yes. But the crash is >> in an OpenSSL function, and you haven't got debug symbols for that since you >> haven't recompiled that yet. Anyway, it still has nothing to do with OpenLDAP, >> your OpenSSL library is broken. Since this is not an OpenLDAP bug this ITS >> will be closed. >> > > -- -- 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

← Newer
1
2
3
4
5
6
7
...
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