openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 14 Oct '10

14 Oct '10

Version 2... Part 3 of 3 of this patch with the request changes to options.c is now available for review. The full details are located here: http://cr.opensolaris.org/~djl/openldap-patch3/ The revised patch has been updated to include all changes as on 10-14-10AM including the commit of: Modified Files: cyrus.c 1.159 -> 1.160 The only file modified between the first and second version of this patch was options.c The web link above includes both the original patch (as version 1) and the revised patch (version 2) with full diff -Us, tarballs and such for both versions. Retesting has been completed on both Solaris x86 and Solaris SPARC. Both platforms have been re-tested under 32-bit and 64-bit compiles. All regression testing passed successfully. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. Thank you for your consideration, Doug.

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 14 Oct '10

14 Oct '10

--=-6hDPPEPvd2QOD+/Er+Q8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote: > It seems you can workaround this by changing tls_g.c's invocation of=20 > gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, = that=20 > strikes me as fundamentally wrong, since libldap is clearly closing both= =20 > directions when it gets here. I think the bug is in gnutls_bye(), it shou= ldn't=20 > be waiting indefinitely when it tries to read the peer's Close alert. I'm= not=20 > sure it should even be trying to read that at all; some peers may never s= end it. I can't comment on the GnuTLS API because I haven't used it before. Can you file a bugreport with GnuTLS? Do you need any more input from my end? > Note that because you're breaking the connection without warning, TCP doe= sn't=20 > know that the connection is gone, so there will be no error detected when= =20 > gnutls attempts to send its own Close alert. In this case, it will probab= ly=20 > block for 2*MSL before getting any further. In my tests I haven't waited that long (I think). Do you know if there are any problems with using setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on the socket? --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-6hDPPEPvd2QOD+/Er+Q8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJMt01mAAoJECqLdGgQ4K/B5ogP/ihMljH3hvC7aKd6W4Mt526F J/W6Gpx8w7UUI2uymq23epRa1s/2aLWnPDpdP9uGbswrdBrOsRrUARWHPRy/I61L 8JhCiFcEXqyMJxrm7sW4uaVTHBS1AZPklCdfQ0+s4JdVKccLjOkUGJFh4sQL5TtA 3syopgjuQ2inqc9+wA3ZuGL3HgiOuLjXQauHQ0YbWdr+QYZjDZcero5RU6HU+jIv uh+SyQaTiTkzDc8MqGc/ImPZ5R55YORiKUF90Wr+3lGPGCloj8snqfUbMpjNTBkG jUPKBrl+bKgmKPtnpJzLzeCAZsH/rMdyhL0Apr1AZb5Ay8uHqxE3bHE/bTL7/mxA J/RvZlIR/BGed1dWWlQ+j2YE8zsCfvUNxH1GbbmWqk6pO+4BbZP/7XHs6rMW7XkL bT+LwW6J70ZrUFR7XEjkn/a++S7dm9zRoIVDvVgw7HduQSVU+nVQRIwh/CxyGhoG J8OefK5OEYuAqZjFJk8U1OpslstpGDvMjr7nbnY2TRkAg1QshydvhFaq+cp56Uey RT97jWFYTYuIUTrWh8SOog/NxE0WaBJuUqx/Lz/mBX7BkJj+zSDT9SD6IntV73eJ GBBr5wgyEzYyu7pg9uo3Ux16XFp+wwtjMHd8H9/EEEsBjOkuPyGVCz/9CynUgegr A/rMhnTnXTAt7zM/ydh2 =uUuU -----END PGP SIGNATURE----- --=-6hDPPEPvd2QOD+/Er+Q8--

1 0

Re: (ITS#6675) ConnectException UnknownHostException using subdomain URL when searching
by quanah＠zimbra.com 14 Oct '10

14 Oct '10

--On Thursday, October 14, 2010 10:54 AM +0000 adolfo(a)ingenia.es wrote: > Full_Name: Adolfo Cort?s > Version: openldap-2.3.43-12.el5 > OS: CentOS release 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.15.226.90) I see nothing in this report that has to do with OpenLDAP. I.e., you do not show any problems with ldapsearch or any other utility provided by the OpenLDAP Foundation. All of your information is about Java/JNDI, none of which uses the OpenLDAP Code base. I advise you to contact Oracle if you have questions/issues with JNDI. I would note that there are far superior Java API's for connecting to LDAP than JNDI, and that Active Directory, while LDAP "like", is not truly LDAP, and has many unique quirks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6675) ConnectException UnknownHostException using subdomain URL when searching
by adolfo＠ingenia.es 14 Oct '10

14 Oct '10

Full_Name: Adolfo Cortés Version: openldap-2.3.43-12.el5 OS: CentOS release 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.15.226.90) I try to connect to an Active directory from a java application using JNDI /OpenLDAP openldap-2.3.43-12.el5 in CentOS release 5.2 When i did a search i get a CommunicationException Error : javax.naming.CommunicationException: xxxxxxxx.es:636 [Root exception is java.net.UnknownHostException: xxxxxxxx.es]] xxxxxxxx.es:636 is reachable and another operations over LDAP as create user goes fine. I see that the problem is related to the DNS configuration: the Active Directory server DNS is aaaaa.bbbbb.xxxxxxxx.es but the base search is only xxxxxxxx.es when I do the search i get the exception because it takes xxxxxxxx.es instead of ssss.xxxxxxxx.es to perform the operation. I tried to solve it adding xxxxxxxx.es to hosts and writing the same IP of aaaaa.bbbbb.xxxxxxxx.es , so the bypass works and the connection goes but now i have a new problem, when i execute the search it connects but retrieves a Referral Limit Exception, iŽm thinking because there are jumps or confussion between aaaaa.bbbbb.xxxxxxxx.es and xxxxxxxx.es because of the hosts bypass i did. So my workaround doesnŽt works and i need to know or solve the connection problem for use subdomain DNS and domain in search base. Connection Parameters: everytihg goes right, is interesting the url, using not secure ldap protocol I also get the same error. [url: ldaps://aaaaa.bbbbb.xxxxxxxx.es] java.naming.security.authentication:simple Usuario mypassword(a)bbbbb.xxxxxxxx.es] Password[getLDAPropertiesSSL]:mypassword] keystore[getLDAPropertiesSSL]:/opt/java/jre/lib/security/jssecacerts trustStore[getLDAPropertiesSSL]:/opt/java/jre/lib/security/jssecacerts Especificacion uso SSL[getLDAPPropertiesSSL]java.naming.security.protocol ssl Search details: see that base DC is xxxxxxxx.es [base: OU=YYY,DC=xxxxxxxx,DC=es] [searchFilter: (&(objectClass=group)(cn={0}))] [filterArgs: new String[] {Usuarios}] [searchControls: SUBTREE_SCOPE, Atributes null, returningobjflag true] This Hosts file doesnŽt produce the Communication ERROR aaaaa.bbbbb.xxxxxxxx.es ccc.ccc.ccc.ccc xxxxxxxx.es ccc.ccc.ccc.ccc With this hosts file i get the Communication ERROR aaaaa.bbbbb.xxxxxxxx.es ccc.ccc.ccc.ccc If i try this search directly in the AD server console, it works giving me the results. Thanks in advance, Adolfo

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by hyc＠symas.com 13 Oct '10

13 Oct '10

doug.leavitt(a)oracle.com wrote: > Part 3 of 3 of this patch > Part #1 delivered as: ITS#6669 remove obsolete SunOS4 LWP support > Part #2 delivered as: ITS#6672 mutex cleanup > > Is now available for review. The full details are located here: > > http://cr.opensolaris.org/~djl/openldap-patch3/ > > This patch is part 3 of 3 of the original ITS #6625 effort. > (aka openldap draft-zeilenga-ldap-c-api-concurrency) (aka CONCURRENCY) > This patch contains the library modifications to implement CONCURRENCY > as discussed previously in ITS #6625, on the openldap-devel mail list. > > This patch uses the new LDAP_MUTEX_[UN]LOCK macros, delivered by patch2. > Regression testing (post conversion) was performed using both 32-bit and > 64-bit x86 > compiles on an OpenSolaris system. In options.c, I'd rather just see "rc = foo; break;" instead of UNLOCK_RETURN() everywhere. (With the final unlock, return rc at the end of the function.) Aside from that things look ok to me. Anyone else have comments? > Additionally regular ongoing Solaris system testing is being performed > using the libraries built with this patch on both Solaris SPARC and > Solaris x86 systems. > > As previously shown in Round 3 codereview, there seems to be no performance > degradation with this patch, and a slight performance improvement with > the LDAP > server when using back-ldap and back-meta features of the server. > > IPR Notice > > This patch file is derived from OpenLDAP Software. All of the > modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Oracle Corporation. Oracle Corporation has not assigned rights and/or > interest > in this work to any party. I, Douglas Leavitt am authorized by Oracle > Corporation, > my employer, to release this work under the following terms. > > Thank you for your consideration, > Doug. > > > > -- -- 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#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 13 Oct '10

13 Oct '10

Part 3 of 3 of this patch Part #1 delivered as: ITS#6669 remove obsolete SunOS4 LWP support Part #2 delivered as: ITS#6672 mutex cleanup Is now available for review. The full details are located here: http://cr.opensolaris.org/~djl/openldap-patch3/ This patch is part 3 of 3 of the original ITS #6625 effort. (aka openldap draft-zeilenga-ldap-c-api-concurrency) (aka CONCURRENCY) This patch contains the library modifications to implement CONCURRENCY as discussed previously in ITS #6625, on the openldap-devel mail list. This patch uses the new LDAP_MUTEX_[UN]LOCK macros, delivered by patch2. Regression testing (post conversion) was performed using both 32-bit and 64-bit x86 compiles on an OpenSolaris system. Additionally regular ongoing Solaris system testing is being performed using the libraries built with this patch on both Solaris SPARC and Solaris x86 systems. As previously shown in Round 3 codereview, there seems to be no performance degradation with this patch, and a slight performance improvement with the LDAP server when using back-ldap and back-meta features of the server. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. Thank you for your consideration, Doug.

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 13 Oct '10

13 Oct '10

Arthur de Jong wrote: > On Wed, 2010-10-13 at 01:05 -0700, Howard Chu wrote: >> arthur(a)arthurdejong.org wrote: >>> If the connection is opened without TLS ldap_unbind() only writes some data on >>> the connection and then closes it but with TLS it expects some response back. >>> Since read() is used this blocks. >> >> Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL? > > I can confirm that this only happens if libldap is linked with GnuTLS > and not when it is linked against OpenSSL. It seems you can workaround this by changing tls_g.c's invocation of gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, that strikes me as fundamentally wrong, since libldap is clearly closing both directions when it gets here. I think the bug is in gnutls_bye(), it shouldn't be waiting indefinitely when it tries to read the peer's Close alert. I'm not sure it should even be trying to read that at all; some peers may never send it. Note that because you're breaking the connection without warning, TCP doesn't know that the connection is gone, so there will be no error detected when gnutls attempts to send its own Close alert. In this case, it will probably block for 2*MSL before getting any further. -- -- 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#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 13 Oct '10

13 Oct '10

--=-r1RmaIBBY6pCvl2u7gnR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-10-13 at 01:05 -0700, Howard Chu wrote: > arthur(a)arthurdejong.org wrote: > > If the connection is opened without TLS ldap_unbind() only writes some = data on > > the connection and then closes it but with TLS it expects some response= back. > > Since read() is used this blocks. >=20 > Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL? I can confirm that this only happens if libldap is linked with GnuTLS and not when it is linked against OpenSSL. --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-r1RmaIBBY6pCvl2u7gnR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJMthnmAAoJECqLdGgQ4K/BXucP/RnIZ5OWQtivRE94QBQyvb2C hSoQb0U+ToQZucUDxxsIoFO81eEKTfOk5M1RVawzVVDUviq7YVxiE28BEbZQMvix FPiyEYFsUhrsq+ieRMupYS1tsSXE+6fZUjRVJ7JXYMJyMy/sG17zzMJhD/GXfB3Z A2yewks+jl+1i88w55ufwvPAwDgo3TIS1VudvA1K9gJ1wOoDY3jUHCAuUGjDLQ6V kHZ8IYmyRgspD7/pjjCfIewGkoy+ARzguPl28bNcai9xlvnNCmDfg1ECeGoZ5hwD tGTRGTAChhsYX+Aflv0UHRgIk1mPThdFCLgwpda36faiYFsjjWdDKw8u0owqgeLX OUnjkZ+3Q7eetROaqi+VtAqKQ78pRmsMbydsF0O88fERxDOYTGFMqdPItzPtFay5 uFFWBt/SaJruxU/FDNM87lAoL6uOBuQSGJJLoTRa8Sh8cjwakrN/NbIYcEwYBaSJ mNCoeFudWTJLvEa/4Iflu3RXR74599J4/QVyHJUm5GScyLEtfqB+7Vs9FH5Fqni8 qr+OdVVxw1x93WEEFMRv6RRBcsTFhjDFiP3vZ47jez4QLY9lU7iIzAD86I1jT37e CV+oZa2o/vgZR5O8NLsK23c5JM8nGDMBmaNo4c+iTDCxcI+zAUulG2XLVh9u4u7w F/KVk/Tt1bHunrjDWHyF =pUs6 -----END PGP SIGNATURE----- --=-r1RmaIBBY6pCvl2u7gnR--

1 0

Re: (ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by quanah＠zimbra.com 13 Oct '10

13 Oct '10

--On Wednesday, October 13, 2010 10:11 AM +0000 donal.duane(a)ericsson.com wrote: > Full_Name: Donal Duane > Version: 2.4.16 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.45.199.134) The current stable release is 2.4.23. Please use the current release. You also should note the size of your database, BDB version (and whether or not it is up to date on patches), and the relevant configuration bits for the database configuration. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by donal.duane＠ericsson.com 13 Oct '10

13 Oct '10

Full_Name: Donal Duane Version: 2.4.16 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.45.199.134) Hi, I would like to know if this is a known issue, and if so, if a fix has been issued. We have only recently started using OpenLDAP 2.4.16 on Solaris 10, x86 HW. (Because of this, we have no previous benchmark for CPU usage for OpenDLAP for comparison - we also have sparc systems, but have not stress tested OpenLDAP on sparc yet). We have noticed that the slapd process is using a huge amount of CPU. There are massive CPU time spikes obvious over a period of time which we monitored, reaching 520 CPU seconds and even 700 CPU seconds at one stage. there are also some completely flat periods. The activities seem to be purely LDAP searches. Processor info: # psrinfo -pv The physical processor has 4 virtual processors (0 4 8 12) x86 (chipid 0x0 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (1 5 9 13) x86 (chipid 0x1 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (2 6 10 14) x86 (chipid 0x2 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (3 7 11 15) x86 (chipid 0x3 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz # isainfo -b 64 => (64 bit) # uname -a SunOS atrcxb1226 5.10 Generic_142901-13 i86pc i386 i86pc Any help appreciated. Regards, Dónal

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