(ITS#7373) [PATCH] TLS: do not reuse tls_session if hostname check fails
by jvcelak＠redhat.com
Full_Name: Jan Vcelak
Version: git master
OS: Linux
URL: ftp://ftp.openldap.org/incoming/jvcelak-20120828-tls-do-not-reuse-tls_ses...
Submission from: (NULL) (209.132.186.34)
If multiple URIs are specified when creating LDAP connection, the connection to
the first one succeeds but the hostname verification fails, *tls_session is not
dropped, but reused when connecting to the second server.
This is a problem with Mozilla NSS backend because another handshake cannot be
performed on the same file descriptor and SSL_ForceHandshake() will hang. From
this reason, hostname checking was moved into ldap_int_tls_connect() before
connection error handling.
I have verified for all backends (OpenSSL, GnuTLS, MoznSSS) that this fix does
not break hostname verification and that this bug does not present.
Original report: https://bugzilla.redhat.com/show_bug.cgi?id=843056
The attached file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by Red
Hat. Red Hat has not assigned rights and/or interest in this work to any party.
I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under
the following terms.
Red Hat hereby place the following modifications to OpenLDAP Software (and only
these modifications) into the public domain. Hence, these modifications may be
freely used and/or redistributed for any purpose with or without attribution
and/or other notice.
10 years, 6 months
Re: (ITS#7371) slapd locks up at shutdown in SSL threads
by quanah＠zimbra.com
--On Monday, August 27, 2012 6:33 PM +0000 hyc(a)symas.com wrote:
> quanah(a)zimbra.com wrote:
>> --On Monday, August 27, 2012 6:14 PM +0000 quanah(a)OpenLDAP.org wrote:
>>
>>> Full_Name: Quanah Gibson-Mount
>>> Version: 2.4.32 + ITS7356
>>> OS: Linux 2.6
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (74.196.25.250)
>>
>> In reviewing the logs, slapd actually locked up on startup, not shutdown.
>
> Clearly an OpenSSL issue, not an OpenLDAP bug. This ITS should be closed
> and the issue reported to the OpenSSL project.
OpenSSL bug# 2866
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 6 months
(ITS#7372) slapd-meta stops at first unreachable target
by liam.gretton＠leicester.ac.uk
Full_Name: Liam Gretton
Version: 2.4.32
OS: SLES 11 SP 2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (143.210.13.77)
Although multiple targets can be specified in slapd-meta's uri directive to
provide failover should any become unreachable, in practice it seems that
secondary targets are almost never contacted and the failover mechanism doesn't
work as documented.
There was a discussion about this here:
http://www.openldap.org/lists/openldap-technical/201208/msg00103.html
What I've been trying to simulate are the various modes by which a uri target
will become unavailable.
Having gone through this and let the system time out each time, I've found it
does fail over under one of the conditions listed below, but it takes about 15
minutes to do so.
Scenarios:
1. slapd starts, first target is unreachable;
2. slapd starts, first target is reachable but has no service running;
3. slapd already running, first target up and connected then later
becomes unreachable.
Simulations:
a. 'Unreachable' simulated by blocking outbound access with the
following iptables rule:
iptables -A OUTPUT -d host1 -j DROP
b. 'Unreachable' simulated making the first target a host that is up but
with no service running.
Results:
Case 1a: slapd retries host1 continuously and times out after about
180s. No attempt is made to contact additional targets.
Case 2b: slapd retries host1 continuously and times out after about
180s. No attempt is made to contact additional targets.
Case 3a: slapd retries host1 continuously, doubling an internal timeout
value each time, eventually timing out after 19 retries and about 15m.
It does then fall through to host2 and subsequent connections don't
attempt to contact host1.
I also simulated failure with the iptables rule 'iptables -A OUTPUT -d host1 -j
REJECT'. The only difference was that with scenario 1, slapd timed out after
about 3s but still didn't attempt to contact subsequent targets.
Here's my config. I've also tried setting nretries explicitly to 3, but
it makes no difference.
database meta
suffix dc=local
rootdn cn=administrator,dc=local
rootpw secret
network-timeout 1
uri ldap://host1:3268/ou=dc1,dc=local
ldap://host2:3268/
ldap://host3:3268/
suffixmassage "ou=dc1,dc=local" "dc=example,dc=com"
idassert-bind bindmethod=simple
binddn="cn=proxyuser,dc=example,dc=com"
credentials="password"
idassert-authzfrom "dn.exact:cn=administrator,dc=local"
These results suggest to me that network-timeout and nretries (which
should default to 3) don't work as documented.
10 years, 6 months
Re: (ITS#7371) slapd locks up at shutdown in SSL threads
by quanah＠zimbra.com
--On Monday, August 27, 2012 6:14 PM +0000 quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.32 + ITS7356
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.196.25.250)
In reviewing the logs, slapd actually locked up on startup, not shutdown.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 6 months
(ITS#7371) slapd locks up at shutdown in SSL threads
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.32 + ITS7356
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.196.25.250)
With OpenSSL 1.0.1c (latest). We have twice encountered slapd locking up when
being shutdown. Both times, it is locked up in the crypto libraries:
#0 0x00007f838666eb53 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00000000004373db in slapd_daemon_task (ptr=0x16cfe48) at daemon.c:2540
#2 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x0000000000000000 in ?? ()
Thread 9 (Thread 0x7f6f80b46700 (LWP 23349)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385683d3b
"pmeth_lib.c", line=185) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x3564048, amount=1, type=10,
file=0x7f8385683d3b "pmeth_lib.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838560aaed in int_ctx_new (pkey=0x3564040, e=<optimized out>,
id=<optimized out>) at pmeth_lib.c:185
#7 0x00007f838560c094 in do_sigver_init (ctx=0x7f6f80b455c0, pctx=0x0,
type=0x7f83858d1860, e=0x0, pkey=<optimized out>, ver=<optimized out>) at
m_sigver.c:71
#8 0x00007f8385612c90 in ASN1_item_verify (it=0x7f83858cbe40, a=<optimized
out>, signature=0x3534e00, asn=0x1f1efc0, pkey=0x3564040) at a_verify.c:185
#9 0x00007f8385632327 in internal_verify (ctx=0x7f6f80b45720) at
x509_vfy.c:1627
#10 0x00007f8385632e13 in X509_verify_cert (ctx=0x7f6f80b45720) at
x509_vfy.c:367
#11 0x00007f838591474b in ssl3_output_cert_chain (s=0x1dc9180, x=<optimized
out>) at s3_both.c:377
#12 0x00007f8385907965 in ssl3_send_server_certificate (s=0x1dc9180) at
s3_srvr.c:3336
#13 0x00007f83859090c4 in ssl3_accept (s=0x1dc9180) at s3_srvr.c:415
#14 0x00007f8385915a63 in ssl23_accept (s=0x1dc9180) at s23_srvr.c:210
#15 0x00007f838740e328 in tlso_session_accept (sess=0x1dc9180) at tls_o.c:372
#16 0x00007f838740bb3a in ldap_pvt_tls_accept (sb=0x3530d20, ctx_arg=0x16fa600)
at tls2.c:421
#17 0x000000000043bfb5 in connection_read (s=10, cri=0x7f6f80b45b10) at
connection.c:1367
#18 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f80b45b60, argv=0xa)
at connection.c:1279
#19 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#20 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#21 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#22 0x0000000000000000 in ?? ()
Thread 8 (Thread 0x7f6f80345700 (LWP 23352)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f838568a7ef
"p_lib.c", line=393) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x17bbec8, amount=-1,
type=10, file=0x7f838568a7ef "p_lib.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f8385605459 in EVP_PKEY_free (x=0x17bbec0) at p_lib.c:393
#7 0x00007f8385614bfa in X509_PUBKEY_get (key=0x3535b00) at x_pubkey.c:178
#8 0x00007f8385632310 in internal_verify (ctx=0x7f6f80344720) at
x509_vfy.c:1620
#9 0x00007f8385632e13 in X509_verify_cert (ctx=0x7f6f80344720) at
x509_vfy.c:367
#10 0x00007f838591474b in ssl3_output_cert_chain (s=0x1dc8700, x=<optimized
out>) at s3_both.c:377
#11 0x00007f8385907965 in ssl3_send_server_certificate (s=0x1dc8700) at
s3_srvr.c:3336
#12 0x00007f83859090c4 in ssl3_accept (s=0x1dc8700) at s3_srvr.c:415
#13 0x00007f8385915a63 in ssl23_accept (s=0x1dc8700) at s23_srvr.c:210
#14 0x00007f838740e328 in tlso_session_accept (sess=0x1dc8700) at tls_o.c:372
#15 0x00007f838740bb3a in ldap_pvt_tls_accept (sb=0x3530c00, ctx_arg=0x16fa600)
at tls2.c:421
#16 0x000000000043bfb5 in connection_read (s=12, cri=0x7f6f80344b10) at
connection.c:1367
#17 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f80344b60, argv=0xc)
at connection.c:1279
#18 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#19 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x0000000000000000 in ?? ()
Thread 7 (Thread 0x7f6f7fb44700 (LWP 23455)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0
"ssl_cert.c", line=288) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10,
file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287
#7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314
#8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at
tls_o.c:354
#9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at
tls2.c:288
#10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3531fb0, ctx_arg=0x16fa600)
at tls2.c:410
#11 0x000000000043bfb5 in connection_read (s=13, cri=0x7f6f7fb43b10) at
connection.c:1367
#12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7fb43b60, argv=0xd)
at connection.c:1279
#13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#14 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()
Thread 6 (Thread 0x7f6f7f343700 (LWP 23458)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0
"ssl_cert.c", line=288) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10,
file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287
#7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314
#8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at
tls_o.c:354
#9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at
tls2.c:288
#10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568210, ctx_arg=0x16fa600)
at tls2.c:410
#11 0x000000000043bfb5 in connection_read (s=15, cri=0x7f6f7f342b10) at
connection.c:1367
#12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7f342b60, argv=0xf)
at connection.c:1279
#13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#14 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()
Thread 5 (Thread 0x7f6f7eb42700 (LWP 23459)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0
"ssl_cert.c", line=288) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10,
file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287
#7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314
#8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at
tls_o.c:354
#9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at
tls2.c:288
#10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x35680f0, ctx_arg=0x16fa600)
at tls2.c:410
#11 0x000000000043bfb5 in connection_read (s=14, cri=0x7f6f7eb41b10) at
connection.c:1367
#12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7eb41b60, argv=0xe)
at connection.c:1279
#13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#14 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()
Thread 4 (Thread 0x7f6f7e341700 (LWP 23558)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0
"ssl_cert.c", line=288) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10,
file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287
#7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314
#8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at
tls_o.c:354
#9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at
tls2.c:288
#10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568330, ctx_arg=0x16fa600)
at tls2.c:410
#11 0x000000000043bfb5 in connection_read (s=16, cri=0x7f6f7e340b10) at
connection.c:1367
#12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7e340b60, argv=0x10)
at connection.c:1279
#13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#14 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7f6f7db40700 (LWP 23885)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0
"ssl_cert.c", line=288) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10,
file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287
#7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314
#8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at
tls_o.c:354
#9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at
tls2.c:288
#10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568450, ctx_arg=0x16fa600)
at tls2.c:410
#11 0x000000000043bfb5 in connection_read (s=17, cri=0x7f6f7db3fb10) at
connection.c:1367
#12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7db3fb60, argv=0x11)
at connection.c:1279
#13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#14 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7f6f7d33f700 (LWP 24326)):
#0 0x00007f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) at
thr_posix.c:296
#4 0x00007f838740da54 in tlso_locking_cb (mode=9, type=10, file=0x7f8385939da0
"ssl_cert.c", line=288) at tls_o.c:84
#5 0x00007f83855748a7 in CRYPTO_add_lock (pointer=0x1d41888, amount=1, type=10,
file=0x7f8385939da0 "ssl_cert.c", line=<optimized out>) at cryptlib.c:632
#6 0x00007f838592b68b in ssl_cert_dup (cert=0x1730dc0) at ssl_cert.c:287
#7 0x00007f838592ab64 in SSL_new (ctx=0x16fa600) at ssl_lib.c:314
#8 0x00007f838740e2dd in tlso_session_new (ctx=0x16fa600, is_server=1) at
tls_o.c:354
#9 0x00007f838740b5a8 in alloc_handle (ctx_arg=0x16fa600, is_server=1) at
tls2.c:288
#10 0x00007f838740bab8 in ldap_pvt_tls_accept (sb=0x3568570, ctx_arg=0x16fa600)
at tls2.c:410
#11 0x000000000043bfb5 in connection_read (s=18, cri=0x7f6f7d33eb10) at
connection.c:1367
#12 0x000000000043bb56 in connection_read_thread (ctx=0x7f6f7d33eb60, argv=0x12)
at connection.c:1279
#13 0x00007f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#14 0x00007f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f8387afe740 (LWP 23346)):
#0 0x00007f8386942148 in pthread_join () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f83873d9c7e in ldap_pvt_thread_join (thread=140116885796608,
thread_return=0x0) at thr_posix.c:197
#2 0x0000000000438600 in slapd_daemon () at daemon.c:2930
#3 0x0000000000414968 in main (argc=9, argv=0x7fff01f36168) at main.c:1012
10 years, 6 months
Re: (ITS#7370) LDAP installation make file error
by quanah＠zimbra.com
--On Monday, August 27, 2012 2:58 PM +0000 abhishekkalwit(a)gmail.com wrote:
> Full_Name: Abhishek Kalwit
> Version: openldap-2.4.19
> OS: HP UX
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (37.131.68.47)
>
>
> I am trying to install LDAP on HP UX environment 64 bit.
> i have successfully installed BerkeleyDB.4.8.
> also installed openldap-2.4.19, and ran ./configure successfully.
> make depend was also success.
> however i am stuck after running make with below error..please help me
> resolve.
Why are you using OpenLDAP 2.4.19? The current release is OpenLDAP 2.4.32.
Also, questions about how to compile the software should be directed to
openldap-technical(a)openldap.org. This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 6 months
