openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by quanah＠zimbra.com 15 Jun '07

15 Jun '07

--On Thursday, June 14, 2007 8:59 PM +0000 asedlack(a)mailfoundry.com wrote: > Full_Name: Aron Sedlack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.18.18.14) > LDBM is deprecated, and has been removed from the source tree. Bugs against LDBM will not be fixed, because of its inherent flaws. Upgrade your configuration to use one of the supported database mechanisms, back-bdb or back-hdb. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by hyc＠symas.com 15 Jun '07

15 Jun '07

asedlack(a)mailfoundry.com wrote: > Full_Name: Aron Sedlack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.18.18.14) > > > Platform: Linux, OpenLDAP-2.3.35 > Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no > --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls > --with-threads=no > gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e > > slapd core dumps with a corrupted stack, SIGABRT. > slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void > *)0)' failed.. > > Happens every time ldif is loaded... > $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret > adding new entry "dc=mf" > > adding new entry "dc=iana,dc=mf" > ldap_result: Can't contact LDAP server (-1) 1) ldbm is deprecated, don't use it. 2) if you insist on using it, get a debug stack trace for the abort 3) note that ldbm is still tested regularly in the 2.3 builds, and no one else has reported this occurrence, so there's probably something odd in your configuration. Providing your slapd.conf might help. But the ldbm code has been removed for 2.4; support for it is disappearing fast. -- -- Howard Chu Chief Architect, 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#4837) SunLDAP to OpenLDAP migration problem
by quanah＠zimbra.com 15 Jun '07

15 Jun '07

--On Thursday, June 14, 2007 10:02 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Quanah Gibson-Mount writes: >> It should be as simple as changing: >> passwd.c:#define SALT_SIZE 4 >> to >> passwd.c:#define SALT_SIZE 8 > > I don't get this. I don't know ssha1, but... Right, see my follow-up. I had the wrong string in my data when I did a cut and paste. ;) It actually works as it should. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Quanah Gibson-Mount writes: > It should be as simple as changing: > passwd.c:#define SALT_SIZE 4 > to > passwd.c:#define SALT_SIZE 8 I don't get this. I don't know ssha1, but... That's for generating ssha1 hashes in hash_ssha1(), it is not used for decoding them in chk_ssha1() - which I assume is what he needs when moving _to_ OpenLDAP. chk_ssha1() looks independent of salt size - it base64-decodes the provided salt+hash and finds expects the salt to start at position LUTIL_SHA1_BYTES (from include/lutil_sha1.h) in that string. -- Regards, Hallvard

1 0

Re: (ITS#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 9:23 PM +0000 quanah(a)zimbra.com wrote: > Kurt, > > Zimbra has run into this issue in helping a customer who was running > SunDS migrate to OpenLDAP. It does not work at all, unfortunately. > Changing code to use an 8-bit salt does work. Never mind, the 8-bit salt works just fine. I had bad data in my cut & paste buffer last night when I tried this. Trying with the correct data works just fine. yeah! I'll mark this ITS as invalid, and note in the comments that 8-bit salted SSHA passwords work just fine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ando(a)sys-net.it wrote: > Yes, I figured that out. I'll fix this later. Fixed; please test. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

Kurt, Zimbra has run into this issue in helping a customer who was running SunDS migrate to OpenLDAP. It does not work at all, unfortunately. Changing code to use an 8-bit salt does work. So, I'd be happy to fix this, but a general design question -- (a) Should this be implemented as a "ssha-salt" option in slapd.conf or (b) Should OpenLDAP try decrypting the password first as a 4-bit salt, and then try an 8-bit salt, then fail? (a) would be fairly portable across many salt settings, but AFAIK we've only hit 4 & 8 (b) would allow mixed salt values to be in userPassword, and I'd think that over time as people changed their passwords, it would allow the 8-bit salts to go away. Thoughts welcome. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5014) syncrepl failure syslog
by ando＠sys-net.it 14 Jun '07

14 Jun '07

donn(a)u.washington.edu wrote: > Hard to tell why syncrepl isn't working, if it discards error messages. This patch was not submitted according to the guidelines of usual contributions, which makes it hard to apply. In any case, it appears to be incorrect, since the response code should not be extracted that early, namely before getting the message type. AFAIK, only an LDAP_RES_SEARCH_RESULT could contain an error, and that value is already parsed out and stored in "err". What's missing is a log in case "err" indicates an error. So what's really relevant in your patch, and missing from the code, is a test for "err" after the "done" label. I have applied something along those lines to the code. Please test. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by asedlack＠mailfoundry.com 14 Jun '07

14 Jun '07

Full_Name: Aron Sedlack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.18.18.14) Platform: Linux, OpenLDAP-2.3.35 Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls --with-threads=no gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e slapd core dumps with a corrupted stack, SIGABRT. slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void *)0)' failed.. Happens every time ldif is loaded... $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret adding new entry "dc=mf" adding new entry "dc=iana,dc=mf" ldap_result: Can't contact LDAP server (-1)

1 0

Re: (ITS#5018) memory leak
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

niloulili(a)hotmail.com writes: > if ( (ld = ldap_init("192.xxx.xxx.xxx",389 ))== NULL ) > return 1; > if ( ldap_simple_bind_s( ld,"CN=nina > wang,CN=Users,DC=ldap,DC=qtier,DC=com","0000" ) != LDAP_SUCCESS ) > { > ldap_perror( ld, "ldap_simple_bind_s" ); insert "ldap_unbind( ld );" here. Does that fix the problem? That's how to free the LDAP* structure. In LDAP, "unbind" is the "disconnect" command, it's not the opposite of "bind". The misleading name came about because originally one had to bind after connect. > return 1; > } > ldap_msgfree( res ); res == NULL here in this particular code, so you can drop this and the declaration of 'res'. > /* close and free connection resources */ > ldap_unbind( ld ); > return 0; > } -- Regards, Hallvard

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