openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Still going through the logs to see what slapd was doing at the time, but my expectation is "Nothing Particularly Exciting" -- this was under production load, I wasn't poking it with a stick or anything. URI with backtrace to follow...

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder wrote: >> I could not find a suitable api-call to determine a DN's depth. >> > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: >> > I guess reg ex splitting won't work for arbitrary DN strings. > Hi Michael, after I've had a quick look into "ldap_bv2dn()" you might be right... ;-) Before I'll try to upload the patch again (see ITS#6073) I'll update my code to include your suggestion. Many thanks for your advice! Cheers Daniel

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Hallvard B Furuseth wrote: >> DNs should be ordered accoring their in-DIT depth and not accoring their >> bv_len: >> > Does that matter, as long as (child, parent) are ordered correctly? > What is the bug you are fixing? > it's regarding the mentioned "*limited* overlapping feature" within the insert_ordered()-function's comment: cite: "... this means longer dn's (i.e. more specific dn's) will be found first when searching..." But, longer DNs do not neccessarily are more specific: ou=openldap,o=rockz,c=it dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) BTW: the use of insert_ordered() possibly cause some kind of strange (randomized) deletion of a collect_info config attribute's value in this overlay just in the case: c->type == LDAP_MOD_DELETE combined with c->valx > 1 I've noticed this behaviour during testing of my own (chaotic-)test-overlay but had no time to investigate in deep. In my opinion the effect depends on the order of ldapadds of additional DNs and the effective resulting order produced by insert_ordered in combination with "c->valx"... I would file another ITS in case I'm sure that this impressive effect is not cause by my "chaotic" component. ;-)

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 23 Apr '09

23 Apr '09

Daniel Pluta writes: > DNs should be ordered accoring their in-DIT depth and not accoring their > bv_len: Does that matter, as long as (child, parent) are ordered correctly? What is the bug you are fixing? -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by michael＠stroeder.com 23 Apr '09

23 Apr '09

daniel(a)pluta.biz wrote: > I could not find a suitable api-call to determine a DN's depth. How about using ldap_bv2dn() and count the DN components? > So I've used > posix regexp and uploaded that quick&dirty hacked patch right here: I guess reg ex splitting won't work for arbitrary DN strings. Ciao, Michael.

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by quanah＠zimbra.com 23 Apr '09

23 Apr '09

--On Wednesday, April 22, 2009 7:20 AM +0000 rs1542(a)gmx.com wrote: > Full_Name: Carsten T. Rieck > Version: 2.4.11 > OS: RedHat 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.194.157.126) > > > Hello, > > my company runs an anonymously accessible LDAP server on openLDAP 2.4.11 > with Berkeley database 4.6.21 (all recent patches applied) and RedHat 5.1 > as operating system. Please update to OpenLDAP 2.4.16, as the connection code has been significantly reworked, and some issues with using EPOLL have been addressed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by Kurt＠OpenLDAP.org 23 Apr '09

23 Apr '09

This problem as been addressed. -- Kurt On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) > > > ~/build/pkg$ ftp -p 204.152.186.57 > Connected to 204.152.186.57. > 220- OpenLDAP FTP Service > 220 boole.openldap.org FTP server (Version 6.00LS) ready. > Name (204.152.186.57:d): anonymous > 331 Guest login ok, send your email address as password. > Password: > 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights > Reserved. > 230- COPYING RESTRICTIONS APPLY, see: > 230- ftp://ftp.openldap.org/COPYRIGHT > 230- ftp://ftp.openldap.org/LICENSE > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd incoming > 250 CWD command successful. > ftp> put collect.c.patch > local: collect.c.patch remote: collect.c.patch > 227 Entering Passive Mode (204,152,186,57,240,13) > 150 Opening BINARY mode data connection for 'collect.c.patch.3'. > 452 Error writing to file: No space left on device. > 1833 bytes sent in 0.00 secs (1361.2 kB/s) > ftp>

1 0

(ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 22 Apr '09

22 Apr '09

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) ~/build/pkg$ ftp -p 204.152.186.57 Connected to 204.152.186.57. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (204.152.186.57:d): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> put collect.c.patch local: collect.c.patch remote: collect.c.patch 227 Entering Passive Mode (204,152,186,57,240,13) 150 Opening BINARY mode data connection for 'collect.c.patch.3'. 452 Error writing to file: No space left on device. 1833 bytes sent in 0.00 secs (1361.2 kB/s) ftp>

1 0

(ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 22 Apr '09

22 Apr '09

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/collect.c.patch Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) DNs should be ordered accoring their in-DIT depth and not accoring their bv_len: 1) "ou=test_ou_long,ou=test,dc=foo,dc=bar" 2) "ou=test,ou=de,ou=test,dc=foo,dc=bar" DN1' bv_len is higher than that of DN2 but DN2 is deeper located within the DIT. I could not find a suitable api-call to determine a DN's depth. So I've used posix regexp and uploaded that quick&dirty hacked patch right here: ftp://ftp.openldap.org/incoming/collect.c.patch Sorry, next time I'll respect the upload naming conventions that I've noticed a bit to late...

1 0

Re: (ITS#6051) JLDAP SASL issue
by rarpit＠novell.com 22 Apr '09

22 Apr '09

--=__Part654DCF55.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Hendrik, From Novell I am the one responsible for Jldap . Our product eDirectory = does not support CRAM authentication. So this functionality is missing . I do not know how to test it ? Can we test it against openldap server ? = =20 You were talking about some test suite in the bug . What is that test = suite ? Please if I can get that test suite I can test it . =20 regards and thanks=20 Arpit=20 >>> <hendrik.saly(a)gmx.de> 4/10/2009 2:19 PM >>> Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/n= ovell/ldap/SaslLDAPConnection.java Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09= 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore = properly under some circumstances. I tried to use more than the wit JLDAP provided = SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with = a Java 1.5 sasl client. All works very well but CRAM login for example fails. I = have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/ja= va/com/novell/ldap/SaslLDAPConnection.java but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t= ransport/ldap/sasl/ClientFactory.java If neccessary i can provide a test suite for this. Thanks Hendrik --=__Part654DCF55.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Hendrik,</DIV> <DIV>   From Novell I am the one responsible for Jldap . Our = product eDirectory does not support CRAM authentication. So this functional= ity is missing .</DIV> <DIV>   I do not know how to test it ? Can we test it = against openldap server ?  </DIV> <DIV>  You were talking about some test suite in the bug . What is = that test suite ? Please if I can get that test suite I can test it = .</DIV> <DIV> </DIV> <DIV>regards and thanks </DIV> <DIV>Arpit <BR><BR>>>> <hendrik.saly(a)gmx.de> 4/10/2009 2:19 = PM >>><BR>Full_Name: Hendrik Saly<BR>Version: JLDAP 4.3<BR>OS: = Linux 2.6, Sun JDK 1.5<BR>URL: <A href=3D"http://svn.muleforge.org/mule-tra= nsport-ldap/trunk/src/main/java/com/novell/ldap/SaslLDAPConnection.java">ht= tp://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell/l= dap/SaslLDAPConnection.java</A><BR>Submission from: (NULL) (78.43.136.21)<B= R><BR><BR>While trying to use SASL with JLDAP i encounter a potential = minor bug in<BR>$OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v = 1.154 2006/02/09<BR>08:43:45 sunilk Exp $<BR><BR>Seems the bind method on = line 1730 fails to release the bind semaphore properly<BR>under some = circumstances. I tried to use more than the wit JLDAP provided SASL<BR>mech= anisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a = Java<BR>1.5 sasl client. All works very well but CRAM login for example = fails. I have a<BR>workaround   <A href=3D"http://svn.muleforge.o= rg/mule-transport-ldap/trunk/src/main/java/com/novell/ldap/SaslLDAPConnecti= on.java">http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/c= om/novell/ldap/SaslLDAPConnection.java</A><BR>but i thinks there are some = problems with the bind semaphore.<BR><BR>The wrapping code is here<BR><A = href=3D"http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/or= g/mule/transport/ldap/sasl/ClientFactory.java">http://svn.muleforge.org/mul= e-transport-ldap/trunk/src/main/java/org/mule/transport/ldap/sasl/ClientFac= tory.java</A><BR><BR>If neccessary i can provide a test suite for = this.<BR><BR>Thanks<BR>Hendrik<BR></DIV></BODY></HTML> --=__Part654DCF55.1__=--

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