openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 26 Feb '09

26 Feb '09

ando(a)sys-net.it writes: > 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. It _may_ mean that. But the existence of the pidfile also means one need not save the pid after running slapd &. So I think it's best to keep the existing behavior, in case someone depends on the pidfile. -- Hallvard

1 0

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

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