Re: (ITS#6675) ConnectException UnknownHostException using subdomain URL when searching
by quanah＠zimbra.com
--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
12 years, 11 months
(ITS#6675) ConnectException UnknownHostException using subdomain URL when searching
by adolfo＠ingenia.es
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
12 years, 11 months
Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by hyc＠symas.com
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/
12 years, 11 months
Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com
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.
12 years, 11 months
Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com
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/
12 years, 11 months
Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org
--=-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--
12 years, 11 months
Re: (ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by quanah＠zimbra.com
--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
12 years, 11 months
(ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by donal.duane＠ericsson.com
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
12 years, 11 months
Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com
arthur(a)arthurdejong.org wrote:
> Full_Name: Arthur de Jong
> Version: 2.4.23
> OS: Debian/unstable
> URL:
> Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f)
>
>
> When a network connection to the LDAP server fails (is severed with iptables in
> my set-up) the error is detected properly with ldap_result()
> (LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are
> set), however closing the connection with ldap_unbind() hangs indefinitely on a
> read() operation (determined by strace) when using a ldaps:// connection.
>
> 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?
>
> This is a backtrace of the thread that was hanging:
>
> #0 0xb7fe2424 in __kernel_vsyscall ()
> #1 0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82
> #2 0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5)
> at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493
> #3 0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5)
> at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827
> #4 0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at
> tls_g.c:904
> #5 0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26
> #6 0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26
> #7 0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26
> #8 0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26
> #9 0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970
> #10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8)
> at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383
> #11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1,
> unbind=1) at request.c:768
> #12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0)
> at unbind.c:93
> #13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at
> unbind.c:52
> #14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69
> #15 0x0804cfc0 in ?? ()
> #16 0x0804e750 in ?? ()
> #17 0x08057a9f in ?? ()
> #18 0x0804bb8d in ?? ()
> #19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300
> #20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>
>
> More background information is available at [0].
>
> As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the
> connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it.
> This fixes the problem for me at least but I'm not 100% this has no unwanted
> side-effects.
>
> [0] http://bugs.debian.org/596983
> [1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 11 months
Local structure mech in servers/slapd/bind.c assigned to op->orb_mech.
by Grafton Kennedy
The local structure mech in servers/slapd/bind.c is declared in do_bind as
struct berval mech = BER_BVNULL;
at about line 44.
Further in do_bind, around line 201, mech is assigned to op->orb_mech.
As a newbie to slapd, I'm concerned about this assignment.
Later, slapd cores in an_find and I see that op->orb_mech.bv_len shares the same
address as op->o_request.oq_search.rs_attrs:
Program received signal SIGSEGV, Segmentation fault.
an_find (a=0x6, s=0x814322c) at ad.c:874
874 for ( ; a->an_name.bv_val; a++ ) {
(gdb) up
#1 0x0807f865 in slap_attr_flags (an=0x6) at result.c:1659
1659 flags |= an_find( an, slap_bv_all_operational_attrs )
(gdb) up
#2 0x08080a54 in slap_send_search_entry (op=0x81e74e0, rs=0xbfffa368) at
result.c:821
821 rs->sr_attr_flags = slap_attr_flags( rs->sr_attrs );
(gdb) print &op->o_request.oq_bind.rb_mech
$97 = (struct berval *) 0x81e751c
(gdb) print &op->o_request.oq_bind.rb_mech.bv_len
$98 = (ber_len_t *) 0x81e751c
(gdb) print &op->o_request.oq_search.rs_attrs
$99 = (AttributeName **) 0x81e751c
I am using back-shell and slapd cores when my bind shell script outputs blank
lines between data lines. If I remove the blank lines slapd doesn't core. But
then it dumps the whole input and complains "expected RESULT" which I know isn't
right.
Thanks,
Grafton
12 years, 11 months