openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by aej＠WPI.EDU 25 Feb '09

25 Feb '09

>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: hyc> aej(a)wpi.edu wrote: >> Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: >> Submission from: (NULL) (130.215.36.68) >> >> >> I somehow missed installing 2.1.14, and was still running 2.1.13. I found >> that 2.1.15 did not run on one of my servers (but worked on the other 2). >> Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked >> again on that same client still worked ok, so it doesn't appear that >> libraries went sour. The failure is on a gssapi syncrepl client on an >> opteron. The gssapi syncrepl client on Intel works ok. The master appears >> to work ok, too. The ldap server was running on appliance4 and was >> accessing the master on appliance1. >> >> When starting it under debugging -d-1, I got to this: hyc> I presume you meant 2.4.15, not 2.1.15. Thanks for the report, fixed now hyc> in HEAD. Yes, 2.4, once I typed one wrong, I copied my mistake again and again.

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by aej＠WPI.EDU 25 Feb '09

25 Feb '09

>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes: quanah> --On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: >> Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: >> Submission from: (NULL) (130.215.36.68) >> >> >> I somehow missed installing 2.1.14, and was still running 2.1.13. I found >> that 2.1.15 did not run on one of my servers (but worked on the other 2). >> Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked >> again on that same client still worked ok, so it doesn't appear that >> libraries went sour. The failure is on a gssapi syncrepl client on an >> opteron. The gssapi syncrepl client on Intel works ok. The master appears >> to work ok, too. The ldap server was running on appliance4 and was >> accessing the master on appliance1. quanah> OpenLDAP 2.1? That's years ancient, and no longer supported. Use a quanah> modern supported release. Well, there are a bunch of typos. It's 2.4 in all cases. I meant the 2.4.15 that was announced recently. I'd not installed 2.4.14, but that exhibits the same problem.

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by hyc＠symas.com 25 Feb '09

25 Feb '09

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I found that > 2.1.15 did not run on one of my servers (but worked on the other 2). Looking > back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that > same client still worked ok, so it doesn't appear that libraries went sour. The > failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl > client on Intel works ok. The master appears to work ok, too. The ldap server > was running on appliance4 and was accessing the master on appliance1. > > When starting it under debugging -d-1, I got to this: I presume you meant 2.4.15, not 2.1.15. Thanks for the report, fixed now in 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#5976) seg fault problem starting with version 2.1.14
by quanah＠zimbra.com 25 Feb '09

25 Feb '09

--On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I > found that 2.1.15 did not run on one of my servers (but worked on the > other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled > and linked again on that same client still worked ok, so it doesn't > appear that libraries went sour. The failure is on a gssapi syncrepl > client on an opteron. The gssapi syncrepl client on Intel works ok. The > master appears to work ok, too. The ldap server was running on > appliance4 and was accessing the master on appliance1. OpenLDAP 2.1? That's years ancient, and no longer supported. Use a modern supported release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5976) seg fault problem starting with version 2.1.14
by aej＠wpi.edu 25 Feb '09

25 Feb '09

Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: Submission from: (NULL) (130.215.36.68) I somehow missed installing 2.1.14, and was still running 2.1.13. I found that 2.1.15 did not run on one of my servers (but worked on the other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that same client still worked ok, so it doesn't appear that libraries went sour. The failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl client on Intel works ok. The master appears to work ok, too. The ldap server was running on appliance4 and was accessing the master on appliance1. When starting it under debugging -d-1, I got to this: ldap_sasl_interactive_bind_s: user selected: gssapi ldap_int_sasl_bind: gssapi ldap_int_sasl_open: host=appliance1.wpi.edu Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x43377940 (LWP 21161)] ber_get_tag (ber=0x433762c0) at decode.c:110 110 tag = *(unsigned char *)ber->ber_ptr; (gdb) where #0 ber_get_tag (ber=0x433762c0) at decode.c:110 #1 0x0000000000506bdb in ber_skip_tag (ber=0x433762c0, len=0x433763f8) at decode.c:169 #2 0x0000000000507653 in ber_peek_tag (ber=0x433762c0, len=0x433763f8) at decode.c:228 #3 0x0000000000502794 in ldap_X509dn2bv (x509_name=<value optimized out>, bv=0x43376520, func=0, flags=0) at tls2.c:1016 #4 0x0000000000502e6b in ldap_pvt_tls_get_my_dn (s=<value optimized out>, dn=0x43376520, func=0, flags=0) at tls2.c:876 #5 0x00000000004ebd8f in ldap_int_sasl_bind (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", sctrls=0x0, cctrls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at cyrus.c:479 #6 0x00000000004ed41c in ldap_sasl_interactive_bind_s (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", serverControls=0x0, clientControls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at sasl.c:464 #7 0x000000000041584b in slap_client_connect (ldp=0x1699d120, sb=0x1699cf20) at config.c:1764 #8 0x0000000000479dfa in do_syncrepl (ctx=0x43376d70, arg=<value optimized out>) at syncrepl.c:560 #9 0x00000000004e588a in ldap_int_thread_pool_wrapper (xpool=0x1693a410) at tpool.c:663 #10 0x0000003dedc06367 in start_thread () from /lib64/libpthread.so.0 #11 0x0000003ded0d30ad in clone () from /lib64/libc.so.6

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by ando＠sys-net.it 25 Feb '09

25 Feb '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to make > any difference whether or not you use the -d option with slapd. > > This phrasing could be replaced with something that indicates if it is not > specified, the file will not be created. Correct. However I'm not sure whether the man page or the code needs to be fixed. I'm open to suggestions. I'm inclined towards following the man page, as the use of -d implies one may not need the pid, and knows the args. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 25 Feb '09

25 Feb '09

On Feb 25, 2009, at 1:42 AM, hyc(a)symas.com wrote: > The -compat code is LGPL. I'm considering copying the ciphersuite > handling and > a few other pieces out of there, directly into our tree. There's a > lot of > other baggage in the compat library we don't need, and there's some > OpenSSL > emulation that would interfere with the NSS code we already have. > Any problem > with excerpting the bits we need? I would need to take a very careful look at this. In general, the answer is "NO", don't bring in LGPL code into our primary code base (standalone LGPL in contrib is another matter). -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 25 Feb '09

25 Feb '09

hyc(a)symas.com wrote: > Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code > in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency > as well. That's a key requirement to me personally, because otherwise it will > not interoperate with Mozilla/Seamonkey, and right now that's my primary goal > for this work. The -compat code is LGPL. I'm considering copying the ciphersuite handling and a few other pieces out of there, directly into our tree. There's a lot of other baggage in the compat library we don't need, and there's some OpenSSL emulation that would interfere with the NSS code we already have. Any problem with excerpting the bits we need? > It's been a few months since I last looked at this and it took me a while to > remember all the issues surrounding it... > > There are two major problems with the current MozNSS support in HEAD: > 1) It does no initialization of its own. This works with Seamonkey/Thunderbird > because the main app has already initialized the NSS library; libldap just > uses the state that's already there. Code to initialize properly when NSS > hasn't already been initialized still needs to be written. > 2) It cannot shutdown safely. This is a weakness in the NSS API that was > discussed at length in the Mozilla newsgroups. Unfortunately that discussion > went nowhere. (The NSS_Shutdown() function tears down the library > unconditionally; if there were multiple callers of the library and one of them > shuts down because it's going away, all of the other callers lose the library > too.) It appears that not much progress has been made on the latter problem. Here's a relevant wiki http://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Unfortunately this aspect of NSS is still too broken for it to be used safely in libldap, when other apps also use NSS directly. There's still no technical advantage to using this over OpenSSL, and there's still a significant usability/app-safety disadvantage to adopting it. (GnuTLS at least offers TLS1.2 support, which neither OpenSSL or MozNSS do yet. Both OpenSSL and MozNSS have FIPS-140 validations, but FIPS mode is incompatible with the way most existing software uses these libraries, so it's kind of a moot point.) -- -- 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#5975) minor issue with slapd.conf manpage
by eric＠huss.org 25 Feb '09

25 Feb '09

Full_Name: Eric Huss Version: 2.4.15 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.81.244.185) There appears to be a couple slightly incorrect statements in the slapd.conf manpage. It says that the argsfile and pidfile values are used "if started without the debugging command line option". However, it doesn't appear to make any difference whether or not you use the -d option with slapd. This phrasing could be replaced with something that indicates if it is not specified, the file will not be created.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: >> Perhaps a better question is - how would you like it to work? > I prefer that we leave the builder with as freedom as possible. Right, that makes the most sense. >> I'm assuming there must be some way specify which crypto you want to >> build >> openldap with - is that a configure option? > > Presently there is: > --with-tls=[auto,openssl,gnutls] > > I assume we'd just add an 'nss' option to the above. However, Howard > might have other things in mind. Yes (but the option will be "moznss"). >>>> Note >>>> that both NSPR and NSS support pkg-config >>> Here would be to ensure that the proper pkg-config is in the PATH. >>> >>> Of course, pkg-config stuff gets stuff into the environment in some >>> fixed order, which does take away some freedom from the builder. I >>> guess the builder can always manually adjust the order (by providing >>> CPPFLAGS, etc., directly) and then provide a pkg_config which does >>> little. So the freedom is there, just harder to take advantage of. >> The original patch - >> ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - >> assumes the use of pkg-config - I suppose that is not sufficient. > > My only concern would be whether or not pkg-config use here is > specific to a particular 3rd party packaging of NSS versus something > available with all installs of NSS. I currently build against a copy of NSS in my Mozilla build tree. There's nothing installed with pkg-config. I would like to avoid a dependency on pkg-config. Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency as well. That's a key requirement to me personally, because otherwise it will not interoperate with Mozilla/Seamonkey, and right now that's my primary goal for this work. It's been a few months since I last looked at this and it took me a while to remember all the issues surrounding it... There are two major problems with the current MozNSS support in HEAD: 1) It does no initialization of its own. This works with Seamonkey/Thunderbird because the main app has already initialized the NSS library; libldap just uses the state that's already there. Code to initialize properly when NSS hasn't already been initialized still needs to be written. 2) It cannot shutdown safely. This is a weakness in the NSS API that was discussed at length in the Mozilla newsgroups. Unfortunately that discussion went nowhere. (The NSS_Shutdown() function tears down the library unconditionally; if there were multiple callers of the library and one of them shuts down because it's going away, all of the other callers lose the library too.) Another problem I've had in integrating is that the documentation is out of date with the code - the docs recommend certain APIs and practices that are actually deprecated in the actual code. This has led down a lot of blind alleys/dead ends that could otherwise have been avoided... > I'll be leaving the actual technical review of your patch to Howard or > other active committers. -- -- 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

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