openldap-bugs May 2008

openldap-bugs@openldap.org

54 participants
208 discussions

Re: (ITS#5489) Assert failed in slapd_clr_write()
by rein＠OpenLDAP.org 02 May '08

02 May '08

On Wed, 30 Apr 2008, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in >> slapd_clr_write() failed, see the stack trace at the end. The >> last log message (at loglevel stat) related to the socket was >> "fd=657 closed (connection lost on write)". The comment where >> slapd_daemon_task() calls connection_write() makes me believe >> that slapd_clr_write() should not have use assert here. Remove >> it or include it as a condition in the following if statement? > > How frequently can you reproduce this? I'm tempted to say move the > assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still > triggers. This is the only occurrence I have found of this abort, so it is not very reproduce able :-( But the core shows that SLAP_SOCK_IS_WRITE would be false (as would SLAP_SOCK_IS_READ), so moving the assert into the if block should fix this case. And asserting a writeable socket is also active makes sence to me. Rein

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 02 May '08

02 May '08

luca(a)OpenLDAP.org wrote: > luca(a)OpenLDAP.org wrote: >> This is a multi-part message in MIME format. >> --------------080809000906010300090306 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> >> Howard Chu wrote: >> >>> Thanks. Please try HEAD again. >>> >> No way. >> new testrun directory in >> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >> >> backtrace attached >> > recent commits seem to have fixed it (at least, right now I'm not able > to reproduce it anymore...) Right. Confirmed here too; I (temporarily) added an assert(0) to the offending branch of code to make sure the patch was actually getting hit. It takes a very particular timing to trigger that code path. I'm not sure how we can reliably test for this down the road. Perhaps we should add a "disabled" config keyword for backends and syncrepl consumers, so that we can start up the individual servers, (which takes an unpredictable amount of time for each) and then enable various parts in a fixed sequence (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit or miss, because our test database is so small it's unlikely that we can hit the window of time on demand. -- -- 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#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 02 May '08

02 May '08

luca(a)OpenLDAP.org wrote: > This is a multi-part message in MIME format. > --------------080809000906010300090306 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Howard Chu wrote: > >> Thanks. Please try HEAD again. >> > No way. > new testrun directory in > ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz > > backtrace attached > recent commits seem to have fixed it (at least, right now I'm not able to reproduce it anymore...)

1 0

Potential deadlock in back-monitor cache
by Yin Wang 01 May '08

01 May '08

We are working on a project that could relieve from programmer the burden of reasoning about deadlocks, races etc. Our study of the latest OpenLDAP source code shows the following susceptible to deadlock. - monitor_cache_get at servers/slapd/back-monitor/cache.c:163 waiting for mp_mutex while holding mi_cache_mutex - monitor_cache_release at servers/slapd/back-monitor/cache.c:366 waiting for mi_cache_mutex while holding mp_mutex We have not verified this in production run, which could be difficult. Any comment would be greatly appreciated. Yin Wang

1 0

Re: (ITS#5491) slapd crashes with ldappasswd
by quanah＠zimbra.com 30 Apr '08

30 Apr '08

--On Wednesday, April 30, 2008 10:34 PM +0000 Deepak.Cheema(a)emerson.com wrote: > Full_Name: Deepak Cheema > Version: 2.4.8 > OS: Red Hat Linux 3.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.189.5.201) > > > Just built, installed openldap 2.4.8 and slapd starts up fine using the > following > > slapd -f slapd.conf -u root > > as root user on default port 389 > > [root@dl2k245 libexec]# ps -ef|grep slapd > root 15065 1 0 15:31 ? 00:00:00 ./slapd -f > /dbapps/informatica/l > dap/etc/openldap/slapd.conf -u root > > The process stays up as long as I don't type the ldappasswd command to > get the encrypted password a new user... > > once I type in ldappasswd... this is what happens.. > > [root@dl2k245 bin]# ldappasswd > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > additional info: SASL(0): successful result: security flags do not > match > required > [root@dl2k245 bin]# ps -ef|grep lapd > root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd > > and the slapd process is no longer there... > > Any ideas why it might be happening or how to debug this? > I tried dbg but it did not tell me much.. maybe I did not use it > correctly... > > Any help is appreciated ! gdb the slapd process, let it run, and then run your ldappasswd command and see where it is segfaulting. Provide a backtrace, etc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5492)
by hyc＠symas.com 30 Apr '08

30 Apr '08

huynh.tuan(a)comcast.net wrote: > --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 > Content-Type: text/plain > Content-Transfer-Encoding: 8bit > > I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. > > Used crypt to hash password. DES-based Unix crypt only checks the first 8 characters. As I said, if you want longer passwords, then your current choice of password hash is no good. Use some other hash instead. 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

(ITS#5492)
by huynh.tuan＠comcast.net 30 Apr '08

30 Apr '08

--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. Used crypt to hash password. --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/html Content-Transfer-Encoding: 8bit <html><body> <DIV> <DIV>I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same.  </DIV> <DIV> </DIV> <DIV>Used crypt to hash password.</DIV></DIV></body></html> --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0--

1 0

Re: (ITS#5492) Ignore password longer than pwdMinLength specified in PPOLICY
by hyc＠symas.com 30 Apr '08

30 Apr '08

huynh.tuan(a)comcast.net wrote: > Full_Name: Tuan Huynh > Version: 2.3.39 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.39.129.66) > > > My password is 10 characters long, however system allowed me to login as long as > I enter first 8 characters and it ignored the rest even if I enter garbage. For > example: > > my password is !thisIsATest! > when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdkdkdk > > I used ppolicy and pwdMinLength is set at 8 Sounds like a configuration error in your Solaris system, or possibly a poor choice of password hash mechanism. I don't see any evidence of an OpenLDAP bug here. -- -- 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:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2008