openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

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 22 Apr '09

22 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 22 Apr '09

22 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

(ITS#6071) LDAP server becomes unresponsive
by rs1542＠gmx.com 22 Apr '09

22 Apr '09

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. We encounter the problem that occasionally the LDAP server becomes unresponsive. Investigating the network in such a situation shows a large number of connections in the state CLOSE-WAIT. These connections remain persistent until the LDAP server is restarted. I am able to reproduce the issue in our test environment using a client which accesses the LDAP using libldap. In an infinite loop, the client binds to the LDAP and performs a search, but it does do a proper unbinding. After about thirty loops (depending on the number of threads configured), the LDAP server becomes unresponsive. With netstat, I see the connection still as ESTABLISHED. After killing the client, the connection is marked as CLOSE-WAIT and remains in that state until the server is restarted. Any additional attempts to bind to the server leads to a connections in state CLOSE-WAIT. I do not have a Firewall in my test environment. When the server becomes unresponsive, the log displays the message "Resource temporarily unavailable" as in the following extract: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: => acl_mask: access to entry "cn=ACME Class 2 CA,o=ACME AG,ou=rootcerts,dc=acme,dc=de", attr "certificateRevocationList;binary" requested Apr 21 18:31:43 test2 slapd[644]: => acl_mask: to value by "", (=0) Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-admin,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-audit,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: anonymous Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] applying =rscx (stop) Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] mask: =rscx Apr 21 18:31:43 test2 slapd[644]: => slap_access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: => access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: activity on 2 descriptors Apr 21 18:31:43 test2 slapd[644]: daemon: activity on: Apr 21 18:31:43 test2 slapd[644]: 12w Apr 21 18:31:43 test2 slapd[644]: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero In the openLDAP mailing lists I have seen other users having similar although not identical problems. The common advice of reducing the parameter idletimout did not change the behavior. I am most pleased to provide any further information. I appreciate your help. Best regards, Carsten slpad.conf ##================================= ## include /usr/machine/local/admin/openldap/config/ldapdsa/schema/core.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/cosine.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/inetorgperson.schema password-hash {SSHA} ###################### # generic parameters # ###################### idletimeout 2 sizelimit 1000 timelimit 2 sockbuf_max_incoming 300000 sockbuf_max_incoming_auth 5000000 threads 4 gentlehup on #################### # pid & args files # #################### pidfile /usr/machine/local/work/openldap/slapd.pid argsfile /usr/machine/local/work/openldap/slapd.args ############################################################################### ################## # ssl parameters # ################## ###################### # used cipher suites # ###################### TLSCipherSuite HIGH:MEDIUM:+SSLv3 ################### # key, certs etc. # ################### TLSVerifyClient never ############################################################################### ################################## # macro bdb database definitions # ################################## ########################################## # suffix dc=acme,dc=de # ########################################## database bdb suffix "dc=acme,dc=de" cachesize 8000 checkpoint 5 30 mode 0600 directory /usr/machine/local/persistent/openldap/acme lastmod on rootdn "cn=admin,dc=acme,dc=de" rootpw <Passphrase removed> limits anonymous size.soft=10 ########################################## # ACLs # ########################################## include /usr/machine/local/admin/openldap/config/ldapdsa/acl.conf ############# # set index # ############# index default pres,eq index objectclass index cn,sn pres,eq,sub index mail #eof ##=================================

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 21 Apr '09

21 Apr '09

bryan.mesich(a)ndsu.edu wrote: > I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 > and recompiled. Slapd answers one request and then dies with > a segmentation fault: > > connection_get(14): got connid=3D1 > connection_read(14): checking for input on id=3D1 > ber_get_next > Segmentation fault > > I can send you the full debug output if it would be helpful. I'll ask you to send it unless I can easily reproduce the issue myself. Thanks for your time. 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#5941) Problem when stacking rwm and translucent overlays together
by bryan.mesich＠ndsu.edu 20 Apr '09

20 Apr '09

--17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2009 at 12:12:48PM +0200, Pierangelo Masarati wrote: >> Full_Name: Bryan Mesich >> Version: 2.4.13 >> OS: RHEL 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) >> >> >> When a rwm overlay is used in conjunction with the translucent overlay, = slapd >> dies with the following error and backtrace: > > I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could = =20 > also address yours. Can you check? You need to either build HEAD code, = =20 > or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> =20 > 1.119 to 2.4.16. I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 and recompiled. Slapd answers one request and then dies with a segmentation fault: connection_get(14): got connid=3D1 connection_read(14): checking for input on id=3D1 ber_get_next Segmentation fault I can send you the full debug output if it would be helpful. Thanks, Bryan --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJ7N6JlSl3SAlkhEcRAuOwAJ42EyL1dRJAFlZVz7zo5LMTCbgEeACePomd GlMyb+gwM6ZgvTkYl60S7h4= =t8Kh -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--

1 0

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2009