- openldap-bugs - openldap.org

Re: (ITS#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by h.b.furuseth＠usit.uio.no 28 Aug '12

28 Aug '12

Please try this patch, I can't. It's split up for readability. Replace defined(BSD) in 1st patch with defined(__BSD__) or whatever, see below. http://folk.uio.no/hbf/its7363-cleanup.txt Also, maybe we can drop __APPLE__ - it may #define __BSD__ too. ANDROID should be something like __ANDROID__. I can't test either. Explanation: defined(BSD) breaks in strict ISO C mode. Is there a symbol like __BSD__ or __BSD to use instead? Namespace-wise, "MDB_USE_POSIX_SEM" would be better. MDB_FDATASYNC should not depend on USE_POSIX_SEM. We can #ifndef PTHREAD_PROCESS_SHARED instead of BSD, unless someone #define it without supporting it. Not for MDB_FDATASYNC though. -- Hallvard

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by h.b.furuseth＠usit.uio.no 28 Aug '12

28 Aug '12

Howard Chu writes: > h.b.furuseth(a)usit.uio.no wrote: >> That won't help if the mdb proccess crashes. > > If which process crashes? Sorry, I meant the process which would have removed the semaphore. -- Hallvard

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com 28 Aug '12

28 Aug '12

h.b.furuseth(a)usit.uio.no wrote: > cmikk(a)qwest.net writes: >> The patch at: >> >> http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… >> >> Attempts to upgrade the lockfile lock to exclusive when closing the environment. >> If that upgrade succeeds, it removes the semaphores. > > That won't help if the mdb proccess crashes. If which process crashes? If some other process crashes then this lock will succeed and remove the semaphores. > Sounds like mdb needs some > cleanup API calls. Maybe one which does the same as your patch after > opening the environment - except it does not create any files, and fails > if the exclusive lock fails. Sounds OK. Could add an invocation of it as an option for mdb_stat. mdb_stat needs to be extended anyway. -- -- 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#7364) mdb: clean up POSIX semaphores on environment close.
by h.b.furuseth＠usit.uio.no 28 Aug '12

28 Aug '12

cmikk(a)qwest.net writes: > The patch at: > > http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… > > Attempts to upgrade the lockfile lock to exclusive when closing the environment. > If that upgrade succeeds, it removes the semaphores. That won't help if the mdb proccess crashes. Sounds like mdb needs some cleanup API calls. Maybe one which does the same as your patch after opening the environment - except it does not create any files, and fails if the exclusive lock fails. -- Hallvard

1 0

Re: (ITS#7373) [PATCH] TLS: do not reuse tls_session if hostname check fails
by jvcelak＠redhat.com 28 Aug '12

28 Aug '12

> Original report: https://bugzilla.redhat.com/show_bug.cgi?id=843056 Sorry, correct one: https://bugzilla.redhat.com/show_bug.cgi?id=852476

1 0

(ITS#7373) [PATCH] TLS: do not reuse tls_session if hostname check fails
by jvcelak＠redhat.com 28 Aug '12

28 Aug '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120828-tls-do-not-reuse-tls_sessi… 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.

1 0

Re: (ITS#7371) slapd locks up at shutdown in SSL threads
by quanah＠zimbra.com 28 Aug '12

28 Aug '12

--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

1 0

(ITS#7372) slapd-meta stops at first unreachable target
by liam.gretton＠leicester.ac.uk 28 Aug '12

28 Aug '12

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.

1 0

Re: (ITS#7371) slapd locks up at shutdown in SSL threads
by hyc＠symas.com 27 Aug '12

27 Aug '12

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. -- -- 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#7371) slapd locks up at shutdown in SSL threads
by quanah＠zimbra.com 27 Aug '12

27 Aug '12

--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

1 0

(ITS#7371) slapd locks up at shutdown in SSL threads
by quanah＠OpenLDAP.org 27 Aug '12

27 Aug '12

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

1 0

Re: (ITS#7370) LDAP installation make file error
by quanah＠zimbra.com 27 Aug '12

27 Aug '12

--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

1 0

(ITS#7370) LDAP installation make file error
by abhishekkalwit＠gmail.com 27 Aug '12

27 Aug '12

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. Entering subdirectory liblber /bin/sh ../../libtool --mode=compile cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.8/include -DLBER_LIBRARY -c version.c cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.8/include -DLBER_LIBRARY -c version.c -DPIC -o .libs/version.o cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB.4.8/include -DLBER_LIBRARY -c version.c -o version.o >/dev/null 2>&1 /bin/sh ../../libtool --mode=link cc -g -L/usr/local/lib -L/usr/local/BerkeleyDB.4.8/lib -R/usr/local/BerkeleyDB.4.8/lib -release 2.4 -version-info 7:2:5 -rpath /usr/local/lib -o liblber.la assert.lo decode.lo encode.lo io.lo bprint.lo debug.lo memory.lo options.lo sockbuf.lo stdio.lo version.lo /usr/bin/ld -b +h liblber-2.4.so.7 -o .libs/liblber-2.4.so.7.2 .libs/assert.o .libs/decode.o .libs/encode.o .libs/io.o .libs/bprint.o .libs/debug.o .libs/memory.o .libs/options.o .libs/sockbuf.o .libs/stdio.o .libs/version.o -L/usr/local/BerkeleyDB.4.8/lib -L/usr/local/lib -L/usr/local/BerkeleyDB.4.8/lib -lc ld: Bad machine type: 62 in file .libs/assert.o Fatal error. *** Error exit code 1 Stop. *** Error exit code 1

1 0

Re: (ITS#7368) RE 24 build error: LDAP_BACK_AUTH_DN_AUTHZID’ undeclared etc.
by michael＠stroeder.com 24 Aug '12

24 Aug '12

seems to be fixed by commit a2d1b42e3921d5c874a8f35fcd42047af604ce96

1 0

Re: (ITS#7369) mdb_stat leaves an open transaction if a subdatabase does not exist
by ondrej.kuznik＠acision.com 24 Aug '12

24 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/24/2012 10:55 AM, ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik Version: mdb.master OS: Linux URL: > Submission from: (NULL) (62.168.56.1) > > > If mdb_stat fails (e.g. "mdb_stat db/ this_subdb_does_not_exist"), > it exits immediately rather than abort the txn and close the env. > > When another process has the mdb environment open while this > happens, as long as it does not close it, no new transaction can be > initiated. The whole env then effectively becomes read-only and > unopenable for new processes. A possible patch is at: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120824-ITS-7369.patch While I deem this modification too small to be copyrightable, the IPR notice follows just out of caution: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA3RH4ACgkQ9GWxeeH+cXuq0wCfZAR/XoC+5UZTpUvK2c1tK65P iXkAnR0Ad96dNEXL58BJs/ydLHvDmth4 =R+Jc -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7369) mdb_stat leaves an open transaction if a subdatabase does not exist
by ondrej.kuznik＠acision.com 24 Aug '12

24 Aug '12

Full_Name: Ondrej Kuznik Version: mdb.master OS: Linux URL: Submission from: (NULL) (62.168.56.1) If mdb_stat fails (e.g. "mdb_stat db/ this_subdb_does_not_exist"), it exits immediately rather than abort the txn and close the env. When another process has the mdb environment open while this happens, as long as it does not close it, no new transaction can be initiated. The whole env then effectively becomes read-only and unopenable for new processes.

1 0

(ITS#7368) RE 24 build error: LDAP_BACK_AUTH_DN_AUTHZID’ undeclared etc.
by michael＠stroeder.com 23 Aug '12

23 Aug '12

Full_Name: Version: RE24 9f9025a9765940cbdff4316852f1190946e2551d OS: URL: Submission from: (NULL) (79.219.97.190) Probably due to recent patches to back-meta RE24 does not build: make[3]: Entering directory `/usr/src/michael/openldap-git/re24/openldap/servers/slapd/back-meta' rm -f version.c ../../../build/mkversion -v "2.4.X" back_meta > version.c /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c init.c mkdir .libs cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c init.c -fPIC -DPIC -o .libs/init.o /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c config.c cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DSLAPD_IMPORT -c config.c -fPIC -DPIC -o .libs/config.o config.c: In function ‘meta_back_cf_gen’: config.c:1503:38: error: ‘LDAP_BACK_AUTH_DN_MASK’ undeclared (first use in this function) config.c:1503:38: note: each undeclared identifier is reported only once for each function it appears in config.c:1504:10: error: ‘LDAP_BACK_AUTH_DN_AUTHZID’ undeclared (first use in this function) config.c:1508:10: error: ‘LDAP_BACK_AUTH_DN_WHOAMI’ undeclared (first use in this function) make[3]: *** [config.lo] Error 1 make[3]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/servers/slapd/back-meta' make[2]: *** [back-meta] Error 2 make[2]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by cmikk＠qwest.net 23 Aug '12

23 Aug '12

On Wed, Aug 22, 2012 at 03:23:16PM -0700, Howard Chu wrote: > cmikk(a)qwest.net wrote: > > For example, if you run slapd as an unprivileged user, stop slapd, and do an > > offline slapcat as root, slapd will not start up again as that unprivileged > > user. [snip] > > This sounds like a bug in your platform's sem_open() syscall. If you first > started slapd as an unprivileged user, the semaphore should be owned by that > user. Running slapcat as root should not change the semaphore owner uid, and > the unprivileged owner should still be able to access the semaphore later. In the scenario described, slapd is not running when slapcat starts as root, so slapcat gets an exclusive lock on the lockfile, sem_unlink()s the semaphores created by the unprivileged slapd user, and recreates them, now owned by root. When slapcat finishes, it closes the database and does not remove the semaphores. When slapd starts up, it gets an exclusive lock, attempts to sem_unlink() the semaphores created as (and owned by) root, which fails. In timeline form: 1: slapcat gets exclusive lock on lock.mdb 2: slapcat (as root) unlinks /MDBrXXXX and /MDBwXXXX 3: slapcat (as root) creates /MDBrXXXX and /MDBwXXXX 4: slapcat exits, releasing lock on lock.mdb, leaving behind /MDBrXXXX and /MDBwXXXX (owned by root) 5: slapd gets exclusive lock on lock.mdb 6: slapd (as unpriv) unlinks /MDBrXXXX and /MDBwXXXX. This fails because of the semaphores are owned by root. 7: slapd fails startup. Thanks, -- Chris Mikkelson | "Unfortunately, simplicity is a complicated mess cmikk(a)qwest.net | of a concept." --Taner Edis

1 0

Re: (ITS#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com 23 Aug '12

23 Aug '12

--On Wednesday, August 22, 2012 6:49 PM +0000 quanah(a)zimbra.com wrote: > Something at the OS level is blocking the mdb memory allocation. This > same issue does not occur on other SLES11 installations we have, so I'm > somewhat at a loss to explain it. Just to follow up, this is specific to SLES11, and its ulimit -v setting. What is odd, is I only see it happen on some SLES11 machines. It happens at both SP1 and SP2 on the machines where it occurs. It doesn't happen on other machines that are SP1 or SP2. So why some SLES11 system honor ulimit -v and others don't is beyond me, but at least a root cause is known. --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

1 0

(ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 23 Aug '12

23 Aug '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120823-moznss-update-list-of-ciph… Submission from: (NULL) (209.132.186.34) I'm attaching patch which updates the list of supported cipher suites for Mozilla NSS backend. All ciphers currently implemented in NSS (3.13.5) are included. Default ciphers are selected on the same basis as in OpenSSL. NULL/EXPORT/LOW/MEDIUM/HIGH classification is taken from OpenSSL as well. 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.

1 0

(ITS#7366) [PATCH] Update slapo-constraint tests
by jsynacek＠redhat.com 23 Aug '12

23 Aug '12

Full_Name: Jan Synacek Version: master OS: linux-fedora17 URL: ftp://ftp.openldap.org/incoming/jsynacek-20120823-constraint-tests-update.p… Submission from: (NULL) (209.132.186.34) This patch updates the slapo-constraint testsuit. It adds additional tests for any constraint using 'set'. 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 Synacek 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.

1 0

Re: (ITS#7365) Server is unwilling to perform
by hyc＠symas.com 23 Aug '12

23 Aug '12

arunkumar_1123(a)yahoo.com wrote: > Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.83.248.38) > > > I discovered this while try to perform two paged search on a single connection . > ldap is not allowing me to perform two simultaneous paged request and getting > unwilling to perform (53) . i found this > http://www.openldap.org/lists/openldap-bugs/200406/msg00100.html thread while > searching for solution . Is this problem still exists ? . if so is there any > workaround ? This is no bug, this works as designed. Closing this ITS. -- -- 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#7365) Server is unwilling to perform
by masarati＠aero.polimi.it 23 Aug '12

23 Aug '12

On 08/23/2012 11:36 AM, arunkumar_1123(a)yahoo.com wrote: > Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.83.248.38) > > > I discovered this while try to perform two paged search on a single connection . > ldap is not allowing me to perform two simultaneous paged request and getting > unwilling to perform (53) . i found this > http://www.openldap.org/lists/openldap-bugs/200406/msg00100.html thread while > searching for solution . Is this problem still exists ? . if so is there any > workaround ? This is the intended behavior, based on the current implementation of RFC2696. The workaround consists in using separate connections. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7365) Server is unwilling to perform
by arunkumar_1123＠yahoo.com 23 Aug '12

23 Aug '12

Full_Name: Arunkumar shanmugam Version: 2.4.29 OS: rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.83.248.38) I discovered this while try to perform two paged search on a single connection . ldap is not allowing me to perform two simultaneous paged request and getting unwilling to perform (53) . i found this http://www.openldap.org/lists/openldap-bugs/200406/msg00100.html thread while searching for solution . Is this problem still exists ? . if so is there any workaround ?

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com 22 Aug '12

22 Aug '12

hyc(a)symas.com wrote: > cmikk(a)qwest.net wrote: >> Full_Name: Chris Mikkelson >> Version: 2.4.32 >> OS: FreeBSD >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (204.147.85.37) >> >> >> When a back-mdb database is closed, the POSIX semaphores created when the mdb >> database was opened are left behind. This prevents a different user from opening >> the database. >> >> For example, if you run slapd as an unprivileged user, stop slapd, and do an >> offline slapcat as root, slapd will not start up again as that unprivileged >> user. The only ways to recover I've found are: > > This sounds like a bug in your platform's sem_open() syscall. If you first > started slapd as an unprivileged user, the semaphore should be owned by that > user. Running slapcat as root should not change the semaphore owner uid, and > the unprivileged owner should still be able to access the semaphore later. My mistake. Your patch looks good, committed. Thanks. > > Either that, or your description of the bug scenario is incomplete. I won't > commit your patch without a more complete understanding of the bug. > >> a) reboot the machine >> b) restore the database from the slapcat, ensuring that slapadd runs as the >> correct user, or >> c) write a small program to re-generate the semaphore names an remove them. >> >> The patch at: >> >> http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… >> >> Attempts to upgrade the lockfile lock to exclusive when closing the environment. >> If that upgrade succeeds, it removes the semaphores. >> >> Patch has been tested on a BSD system. WIN32 has not been tested. > -- -- 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#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com 22 Aug '12

22 Aug '12

cmikk(a)qwest.net wrote: > Full_Name: Chris Mikkelson > Version: 2.4.32 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.147.85.37) > > > When a back-mdb database is closed, the POSIX semaphores created when the mdb > database was opened are left behind. This prevents a different user from opening > the database. > > For example, if you run slapd as an unprivileged user, stop slapd, and do an > offline slapcat as root, slapd will not start up again as that unprivileged > user. The only ways to recover I've found are: This sounds like a bug in your platform's sem_open() syscall. If you first started slapd as an unprivileged user, the semaphore should be owned by that user. Running slapcat as root should not change the semaphore owner uid, and the unprivileged owner should still be able to access the semaphore later. Either that, or your description of the bug scenario is incomplete. I won't commit your patch without a more complete understanding of the bug. > a) reboot the machine > b) restore the database from the slapcat, ensuring that slapadd runs as the > correct user, or > c) write a small program to re-generate the semaphore names an remove them. > > The patch at: > > http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… > > Attempts to upgrade the lockfile lock to exclusive when closing the environment. > If that upgrade succeeds, it removes the semaphores. > > Patch has been tested on a BSD system. WIN32 has not been tested. -- -- 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#7350) aclparse.c acl_unparse() attrval empty DN
by hyc＠symas.com 22 Aug '12

22 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff03:4dbf:1141:9dad:2f88) > > > It seems to me, that the following acl statement isn't correctly unparsed within > aclparse.c: > > to dn.base="ou=persons,o=test" attrs=seeAlso val/distinguishedNameMatch="" by > users read > > > Starting slapd using loglevel 128 reports: > > Backend ACL: access to dn.base="ou=persons,o=test" > attrs=seeAlso > by users read > > I would have expected: > > Backend ACL: access to dn.base="ou=persons,o=test" > attrs=seeAlso > val/distinguishedNameMatch="" > by users read > > > As the empty DN is empty, the problem seems to be located in aclparse.c's > acl_unparse()'s statement > > if ( !BER_BVISEMPTY( &a->acl_attrval ) ) > > or even in the parse_acl() flagless spliting into left and right. > > > Sounds right. Thanks for the report, fixed in master. -- -- 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

(ITS#7364) mdb: clean up POSIX semaphores on environment close.
by cmikk＠qwest.net 22 Aug '12

22 Aug '12

Full_Name: Chris Mikkelson Version: 2.4.32 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) When a back-mdb database is closed, the POSIX semaphores created when the mdb database was opened are left behind. This prevents a different user from opening the database. For example, if you run slapd as an unprivileged user, stop slapd, and do an offline slapcat as root, slapd will not start up again as that unprivileged user. The only ways to recover I've found are: a) reboot the machine b) restore the database from the slapcat, ensuring that slapadd runs as the correct user, or c) write a small program to re-generate the semaphore names an remove them. The patch at: http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… Attempts to upgrade the lockfile lock to exclusive when closing the environment. If that upgrade succeeds, it removes the semaphores. Patch has been tested on a BSD system. WIN32 has not been tested.

1 0

Re: (ITS#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by hyc＠symas.com 22 Aug '12

22 Aug '12

cmikk(a)qwest.net wrote: > Full_Name: Chris Miikkelson > Version: 2.4.32 > OS: FreeBSD > URL: > Submission from: (NULL) (204.147.85.37) > > > mdb on BSD-derived systems other than OS X also needs to use POSIX semaphores > for inter-process synchronization. I was working around this by adding > "-D__APPLE__" to CFLAGS, but that could have side-effects on some systems. The > following patch tells mdb to use posix semaphores if either BSD or __APPLE__ is > defined, which seems like a more targeted fix. > > http://mikk.net/~chris/patches/0001-Use-posix-semaphores-on-apple-and-bsd-s… > > Thanks for the patch, applied. -- -- 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

(ITS#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by cmikk＠qwest.net 22 Aug '12

22 Aug '12

Full_Name: Chris Miikkelson Version: 2.4.32 OS: FreeBSD URL: Submission from: (NULL) (204.147.85.37) mdb on BSD-derived systems other than OS X also needs to use POSIX semaphores for inter-process synchronization. I was working around this by adding "-D__APPLE__" to CFLAGS, but that could have side-effects on some systems. The following patch tells mdb to use posix semaphores if either BSD or __APPLE__ is defined, which seems like a more targeted fix. http://mikk.net/~chris/patches/0001-Use-posix-semaphores-on-apple-and-bsd-s…

1 0

Re: (ITS#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com 22 Aug '12

22 Aug '12

--On Wednesday, August 22, 2012 4:44 PM +0000 quanah(a)zimbra.com wrote: > --On Wednesday, August 22, 2012 4:40 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > >> > > data.mdb is zero sized: > > mail:/opt/zimbra/data/ldap/mdb/db # ls -l > total 4 > -rw------- 1 zimbra zimbra 0 2012-08-22 12:32 data.mdb > -rw------- 1 zimbra zimbra 8192 2012-08-22 12:32 lock.mdb > > mail:/opt/zimbra/data/ldap/mdb/db # df -h . > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/system-zimbra > 39G 33G 6.7G 83% /opt/zimbra > > > maxsize is 84GB, but the actual DB will be < 26MB when it is finished > being created. Is this because maxsize > total free disk space? This is definitely not an OpenLDAP bug. Apparently some OSes block max allocation, even if blocking it is disabled. This particular server is running SLES11 SP1: Linux mail 2.6.32.49-0.3-default #1 SMP 2011-12-02 11:28:04 +0100 x86_64 x86_64 x86_64 GNU/Linux Something at the OS level is blocking the mdb memory allocation. This same issue does not occur on other SLES11 installations we have, so I'm somewhat at a loss to explain it. --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

1 0

Re: (ITS#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com 22 Aug '12

22 Aug '12

--On Wednesday, August 22, 2012 4:40 PM +0000 openldap-its(a)OpenLDAP.org wrote: > data.mdb is zero sized: mail:/opt/zimbra/data/ldap/mdb/db # ls -l total 4 -rw------- 1 zimbra zimbra 0 2012-08-22 12:32 data.mdb -rw------- 1 zimbra zimbra 8192 2012-08-22 12:32 lock.mdb mail:/opt/zimbra/data/ldap/mdb/db # df -h . Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-zimbra 39G 33G 6.7G 83% /opt/zimbra maxsize is 84GB, but the actual DB will be < 26MB when it is finished being created. Is this because maxsize > total free disk space? --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

1 0

(ITS#7362) back-mdb: slapadd -q fails
by quanah＠OpenLDAP.org 22 Aug '12

22 Aug '12

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) slapadd fails with: 5035099b mdb_db_open: database "" cannot be opened, err 12. Restore from backup! 5035099b backend_startup_one (type=mdb, suffix=""): bi_db_open failed! (12) slap_startup failed

1 0

Re: (ITS#7359) [PATCH] MozNSS: prefer unlocked slot when getting private key
by jvcelak＠redhat.com 22 Aug '12

22 Aug '12

> >> 1) the recent patches do not adhere to the existing whitespace > >> conventions. > >> Please fix this. > > > > Sorry for that. Looks like you already committed the patch. I will send > > you > > a patch fixing just the whitespaces in my recent changes. > > Thanks. The patch is uploaded. I have touched only lines modified by me as a last one. ftp://ftp.openldap.org/incoming/jvcelak-20120822-moznss-fix-my-coding- standard.patch 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.

1 0

Re: (ITS#7358) Patch to fix Visual Studio build broken by 2.4.32
by mbooth＠apache.org 22 Aug '12

22 Aug '12

On 21 August 2012 23:17, Howard Chu <hyc(a)symas.com> wrote: > mbooth(a)apache.org wrote: >> Full_Name: Mat Booth >> Version: 2.4.32 >> OS: Windows XP >> URL: http://people.apache.org/~mbooth/0001-Fix-build-error-syntax-error-missing-… >> Submission from: (NULL) (77.86.30.139) >> >> >> The provided patch fixes a build problem for Visual Studio 2005 that was >> introduced with OpenLDAP 2.4.32. > > Thanks for the report. A different fix is now in git master. > >> * libraries/libldap/init.c >> Use C89-style variable declarations because Visual C does not support C99-style >> declarations. Avoids a "syntax error : missing ; before type" compile-time error >> with Microsoft compilers. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ Thanks for committing a better fix -- I wasn't sure if the LDAP_MUTEX_* macros needed to be in that scope for a reason I couldn't discern. :-) Mat

1 0

Re: (ITS#7359) [PATCH] MozNSS: prefer unlocked slot when getting private key
by hyc＠symas.com 22 Aug '12

22 Aug '12

Jan Včelák wrote: > On Tuesday 21 of August 2012 13:38:41, Howard Chu wrote: >> The quality of this code seems to be getting progressively worse. It seems >> I've been accepting the last several patches without giving feedback though. > > So thank you for feedback on this patch. > >> 1) the recent patches do not adhere to the existing whitespace conventions. >> Please fix this. > > Sorry for that. Looks like you already committed the patch. I will send you > a patch fixing just the whitespaces in my recent changes. Thanks. >> 2) the code in this patch is unnecessarily clumsy: > > It's a matter of opinion. In general, I rather see less levels of indentation. > That's why I used this construct. But right, you are the maintainer. This code > is too short to say that it is more readable and the code produced by the > compiler will be the same. Assuming how the compiler behaves is unsafe and nonportable. Even if you're only working on a single platform (which we are not) the compiler behavior can change drastically depending on optimization flags. During debugging you tend to need to compile without optimization, to be able to see clearly what's going on. It is best practice to write code that doesn't rely on the optimizer to kill redundancies, to minimize the difference between debug versions and deployed/optimized versions. These are facts, not opinions. -- -- 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#7359) [PATCH] MozNSS: prefer unlocked slot when getting private key
by jvcelak＠redhat.com 22 Aug '12

22 Aug '12

On Tuesday 21 of August 2012 13:38:41, Howard Chu wrote: > The quality of this code seems to be getting progressively worse. It seems > I've been accepting the last several patches without giving feedback though. So thank you for feedback on this patch. > 1) the recent patches do not adhere to the existing whitespace conventions. > Please fix this. Sorry for that. Looks like you already committed the patch. I will send you a patch fixing just the whitespaces in my recent changes. > 2) the code in this patch is unnecessarily clumsy: It's a matter of opinion. In general, I rather see less levels of indentation. That's why I used this construct. But right, you are the maintainer. This code is too short to say that it is more readable and the code produced by the compiler will be the same. Jan

1 0

RE: (ITS#7357) Pass-through radius auth. with RFC2865
by jet＠transniaga.co.th 21 Aug '12

21 Aug '12

Howard Chu wrote: > > jet(a)transniaga.co.th wrote: > > Full_Name: Jetasik Anantakunupakorn > > Version: 2.4.32 > > OS: FreeBSD 9.0-RELEASE amd64 > > URL: > > http://www.openldap.org/lists/openldap-technical/201208/msg00172.html > > Submission from: (NULL) (58.11.65.20) > > > > > > Pass-through radius authentication in contrib's passwd > > module(radius.c) does not include either a NAS-IP or a NAS-Identifier, > > according to radius RFC 2865 one of these attributes is mandatory in the > access request. > > > > The thing is that the previous version of Radius RFC standard(RFC > > 2138) specified that the access request "SHOULD" contain either a > > NAS-IP or a NAS-Identifier but the current version use "MUST" instead. > > > A patch for this is now in git master, please test. > Awesome!Thanks a lot. Properly tested with no error. -- JET JETASIK

1 0

Re: (ITS#7358) Patch to fix Visual Studio build broken by 2.4.32
by hyc＠symas.com 21 Aug '12

21 Aug '12

mbooth(a)apache.org wrote: > Full_Name: Mat Booth > Version: 2.4.32 > OS: Windows XP > URL: http://people.apache.org/~mbooth/0001-Fix-build-error-syntax-error-missing-… > Submission from: (NULL) (77.86.30.139) > > > The provided patch fixes a build problem for Visual Studio 2005 that was > introduced with OpenLDAP 2.4.32. Thanks for the report. A different fix is now in git master. > * libraries/libldap/init.c > Use C89-style variable declarations because Visual C does not support C99-style > declarations. Avoids a "syntax error : missing ; before type" compile-time error > with Microsoft compilers. -- -- 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#7359) [PATCH] MozNSS: prefer unlocked slot when getting private key
by hyc＠symas.com 21 Aug '12

21 Aug '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120820-nss-prefer-unlocked-slot-p… > Submission from: (NULL) (94.113.220.43) > > > With last MozNSS patches for OpenLDAP, the library explicitly opens the > certificate database when retrieving the certificates, even if the database is > already opened. (Requried for safe certificate lookup from a nickname.) This > might also require a re-authentication to a slot, which holds the private key. > > Some application might expect that the slot with private key is already unlocked > before passing the control to libldap. This got broken with the recent changes. The quality of this code seems to be getting progressively worse. It seems I've been accepting the last several patches without giving feedback though. 1) the recent patches do not adhere to the existing whitespace conventions. Please fix this. 2) the code in this patch is unnecessarily clumsy: +static SECKEYPrivateKey * +tlsm_find_unlocked_key(tlsm_ctx *ctx, void *pin_arg) +{ + SECKEYPrivateKey *result = NULL; + + PK11SlotList *slots = PK11_GetAllSlotsForCert(ctx->tc_certificate, NULL); + if (!slots) { + PRErrorCode errcode = PR_GetError(); + Debug(LDAP_DEBUG_ANY, + "TLS: cannot get all slots for certificate '%s' (error %d: %s)", + tlsm_ctx_subject_name(ctx), errcode, + PR_ErrorToString(errcode, PR_LANGUAGE_I_DEFAULT)); + return result; + } + + PK11SlotListElement *le; + for (le = slots->head; le && !result; le = le->next) { + PK11SlotInfo *slot = le->slot; + if (!PK11_IsLoggedIn(slot, NULL)) + continue; + + result = PK11_FindKeyByDERCert(slot, ctx->tc_certificate, pin_arg); + } + + PK11_FreeSlotList(slots); + return result; +} This should just be: + for (le = slots->head; le; le = le->next) { + PK11SlotInfo *slot = le->slot; + if (PK11_IsLoggedIn(slot, NULL)) { + result = PK11_FindKeyByDERCert(slot, ctx->tc_certificate, pin_arg); + break; + } + } > I'm attaching a patch which fixes it. If the certificate (and corresponding key) > is held in multiple slots, libldap will take the key from an already > authenticated slot. > > > 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. > > -- -- 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#7357) Pass-through radius auth. with RFC2865
by hyc＠symas.com 21 Aug '12

21 Aug '12

jet(a)transniaga.co.th wrote: > Full_Name: Jetasik Anantakunupakorn > Version: 2.4.32 > OS: FreeBSD 9.0-RELEASE amd64 > URL: http://www.openldap.org/lists/openldap-technical/201208/msg00172.html > Submission from: (NULL) (58.11.65.20) > > > Pass-through radius authentication in contrib's passwd module(radius.c) does not > include either a NAS-IP or a NAS-Identifier, according to radius RFC 2865 one of > these attributes is mandatory in the access request. > > The thing is that the previous version of Radius RFC standard(RFC 2138) > specified that the access request "SHOULD" contain either a NAS-IP or a > NAS-Identifier but the current version use "MUST" instead. > A patch for this is now in git master, please test. -- -- 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#7352) openldap not supporting CAMELLIA ciphers
by hyc＠symas.com 21 Aug '12

21 Aug '12

goodgoingswati(a)gmail.com wrote: > Full_Name: Swati > Version: 2.4.32 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.113.153.34) > > > openldap is not supporting CAMELLIA based ciphers(both RSA and DSA based) > I have configured SSL LDAP(LDAPS) and on checking SSL connection with LDAPS > server with CAMELLIA based cipher leads to failure in handshake: Sounds like something is wrong with your config. openssl s_client -connect localhost:9011 -showcerts -cipher CAMELLIA256-SHA -state -CAfile ~/cacert.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:unknown state SSL_connect:SSLv3 read server hello A depth=1 C = US, ST = California, L = Los Angeles, O = Symas Corp., CN = Symas Keymaster verify return:1 depth=0 C = US, ST = California, L = Los Angeles, O = Symas Corp., OU = R&D, CN = violino.symas.net verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read server session ticket A SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/C=US/ST=California/L=Los Angeles/O=Symas Corp./OU=R&D/CN=violino.symas.net i:/C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster -----BEGIN CERTIFICATE----- MIIDeDCCAuGgAwIBAgIBBDANBgkqhkiG9w0BAQQFADBoMQswCQYDVQQGEwJVUzET MBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxFDASBgNV BAoTC1N5bWFzIENvcnAuMRgwFgYDVQQDEw9TeW1hcyBLZXltYXN0ZXIwHhcNMTAw NTA4MTMxMTQwWhcNMTUwNTA3MTMxMTQwWjB4MQswCQYDVQQGEwJVUzETMBEGA1UE CBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxFDASBgNVBAoTC1N5 bWFzIENvcnAuMQwwCgYDVQQLFANSJkQxGjAYBgNVBAMTEXZpb2xpbm8uc3ltYXMu bmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+UzX69iQfiHqFsfmbft8r bbJ1B0khAMIyzbvAq+0TTXBl1z3vh/0zewfa2eXx75A+4j85VhJbmunKQtpGNZoU j78qmlZyyadr1JDV/IP1VdkvimAY/ms/AIN7VXKbo/dMvvE2/Wlz1k6uyARHKRO0 HuDSXR+/y8wxmbssonIaoQIDAQABo4IBIDCCARwwCQYDVR0TBAIwADARBglghkgB hvhCAQEEBAMCBkAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENl cnRpZmljYXRlMB0GA1UdDgQWBBRiK30dAs2UKMa0nqGuZ/ZOvHy/SzCBmgYDVR0j BIGSMIGPgBR8WtuSd1849yXVcEj7z1a5fdXhAKFspGowaDELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRQwEgYD VQQKEwtTeW1hcyBDb3JwLjEYMBYGA1UEAxMPU3ltYXMgS2V5bWFzdGVyggkAlRwa GgnLxpUwEgYDVR0RBAswCYIHdmlvbGlubzANBgkqhkiG9w0BAQQFAAOBgQBsQgtW fd3sjH3kou2QVI0YVh13mUdgLcFvyfI615cvhomttIfrHny2WYb9ktp7yBjsSni5 x6J0s0Xi0NnBgdfh0LNamQL06UXzEPhBwf90n+LyUq+F+9jbHSkQWlAfg+vaBWCs NpPOOvgFPpKkzMouLrc4hVDm9yvPnCh1jV5CKQ== -----END CERTIFICATE----- 1 s:/C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster i:/C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster -----BEGIN CERTIFICATE----- MIIDHDCCAoWgAwIBAgIJAJUcGhoJy8aVMA0GCSqGSIb3DQEBBQUAMGgxCzAJBgNV BAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3MgQW5nZWxl czEUMBIGA1UEChMLU3ltYXMgQ29ycC4xGDAWBgNVBAMTD1N5bWFzIEtleW1hc3Rl cjAeFw0xMDAyMjMwMTE0MTVaFw0yMDAyMjEwMTE0MTVaMGgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3MgQW5nZWxlczEUMBIG A1UEChMLU3ltYXMgQ29ycC4xGDAWBgNVBAMTD1N5bWFzIEtleW1hc3RlcjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtdAxWHaiQVRn4ulkvQ/kWdeQRTlmDp0I 6ROd8UTdZWgG8pdaaSjic3oRrzXGu3yci7oCTeJj//wL6QuAiP3RAd34nvAF3G+J 4fp4AUCYhT7kM1jdGe94omQZeEjVwgr33ugvUYEbVU/fPIn/T3bnmKLifrNcPF30 UimTPNCoTvMCAwEAAaOBzTCByjAdBgNVHQ4EFgQUfFrbkndfOPcl1XBI+89WuX3V 4QAwgZoGA1UdIwSBkjCBj4AUfFrbkndfOPcl1XBI+89WuX3V4QChbKRqMGgxCzAJ BgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3MgQW5n ZWxlczEUMBIGA1UEChMLU3ltYXMgQ29ycC4xGDAWBgNVBAMTD1N5bWFzIEtleW1h c3RlcoIJAJUcGhoJy8aVMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEA MtI45poCh3L8xk0g56WGxroIPMGPZvrHDo1XIj6ALxlhpSLIcTDPFbidJ0tD9aL3 7aNlCZQ7DeJx18BhIUUgSYZj/Sfb0oXZw9Vj59c1AA7UFGnvyjKuJx4G8sIYTFFx rYXCmXraOoB9x0+DcD/7I9ed5Ogid/tZklF9ORPjUgs= -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=California/L=Los Angeles/O=Symas Corp./OU=R&D/CN=violino.symas.net issuer=/C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster --- Acceptable client certificate CA names /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas Keymaster --- SSL handshake has read 2166 bytes and written 290 bytes --- New, TLSv1/SSLv3, Cipher is CAMELLIA256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1.1 Cipher : CAMELLIA256-SHA Session-ID: 430EAC39338B25DF6D1CC63928DB20830BA5A034F13EAF3BE3BED715015D33C1 Session-ID-ctx: Master-Key: F38B9781E21339675D80CDC3561B4ED906A15F5A6F5A9D1A9CCFFF9E16B912D270E2E1F44135FA6CA15D5A24DB720F67 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - f0 95 1a 3f 67 bf cd 43-d7 dc 70 ce a3 19 5a 4e ...?g..C..p...ZN 0010 - c7 2b 4e cc d5 48 df a9-7f d1 a7 b5 53 e0 35 28 .+N..H......S.5( 0020 - fa 7f 9c 70 37 b7 65 01-b6 27 bf 88 d6 dc 8a 36 ...p7.e..'.....6 0030 - 95 a8 2f fb 22 a6 26 3e-07 d3 9b 94 88 b7 99 de ../.".&>........ 0040 - 78 9b ee cb 52 51 5a 50-0a 53 a2 b8 05 f6 63 de x...RQZP.S....c. 0050 - c4 8e e1 2e 03 1c 5d a5-6a e2 6d 05 8e 62 aa 21 ......].j.m..b.! 0060 - f8 0e d0 5e 9f d4 89 3e-85 db b9 8f ed 04 9e 39 ...^...>.......9 0070 - a1 3e b1 44 a2 c3 48 5c-f8 d2 ff 5f 45 ad a0 d6 .>.D..H\..._E... 0080 - d7 c3 3b 4a bd 6e c6 09-9d 08 74 d9 1c c5 6b 1b ..;J.n....t...k. 0090 - b1 f3 eb dc 26 ac 10 31-66 d3 fb bb 6b 9e 4b 8d ....&..1f...k.K. 00a0 - df ef 17 69 97 7b 56 0d-a7 32 bf 6c c6 49 fa b5 ...i.{V..2.l.I.. Compression: 1 (zlib compression) Start Time: 1345578708 Timeout : 300 (sec) Verify return code: 0 (ok) --- > > openssl s_client -connect localhost:636 -showcerts -cipher > DHE-DSS-CAMELLIA256-SHA -state -CAfile /path_to_cert -cert /path_to_client_cert > -key /path_to_client_key > CONNECTED(00000003) > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL3 alert read:fatal:handshake failure > SSL_connect:error in SSLv2/v3 read server hello A > 47726707455072:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > handshake failure:s23_clnt.c:741: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 102 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > > Handshake is failing with all camellia ciphers. > > -- -- 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#7340) Regression in slapo-constraint
by michael＠stroeder.com 21 Aug '12

21 Aug '12

This is a cryptographically signed message in MIME format. --------------ms050203080706090204030402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Synacek wrote: > Ok, here is an attempt to fix this: >=20 > ftp://ftp.openldap.org/incoming/jsynacek-20120821-slapo-constraint-set-= fix.patch >=20 > Done on top of the latest OPENLDAP_REL_ENG_2_4 (7da024d80). Michael, ca= n you > please give it a quick try? Short test seems to be ok. Ciao, Michael. --------------ms050203080706090204030402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODIxMTcwNTUxWjAjBgkq hkiG9w0BCQQxFgQUHxRibOORi2JQfrRj8jVM8z2SgfgwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAbpYRbeLQ716KJyZwzpTpKDTHu28mIhhMMfGXNeHF7o0u5jsi5MrX1sp8MbaoA0r7pCQ5 k+G+irXT8fwCJ419Ydz2lxLJxgLaEmMsCMKElGfnk/gTwrKDq5FD+2rXJZ+Rw8fGyE6qxMnC a3exTDwIu6kWyP0sWrLkY0hnhC+ZoHz/H6WycJHh6DOdaBOJM2CJxlbMbsdV62t3l6aLaHcv k9Ij3Dg6/Eq7Vpzo+W27ByZx5yHGMnwZPA8ZiB+MDqziJAY4i6E7n3eoIQ8e5+gPP8LEvqYN MG4jJG3om4/rtmzaH0Qhn82D/YLTa1SWXQ15Jt/2yqw6WGHkvzEdjmV//AAAAAAAAA== --------------ms050203080706090204030402--

1 0

Re: (ITS#7340) Regression in slapo-constraint
by jsynacek＠redhat.com 21 Aug '12

21 Aug '12

On 08/21/2012 09:51 AM, michael(a)stroeder.com wrote: > It seems the following set-based constraints falsely fail even with valid > modifications: > > ---------------------------- snip ---------------------------- > # cn value has to be concatenated givenName SP sn > constraint_attribute cn,sn,givenName set > "(this/givenName + [ ] + this/sn) & this/cn" > > restrict="ldap:///ou=People,dc=infraldap,dc=onlinebrief,dc=de??sub?(objectClass=dpagE2Person)" > > # homeDirectory value has to be concatenated "/home/" uid > constraint_attribute uid,homeDirectory set > "([/home/] + this/uid) & this/homeDirectory" > > restrict="ldap:///ou=People,dc=infraldap,dc=onlinebrief,dc=de??sub?(objectClass=posixAccount)" > ---------------------------- snip ---------------------------- > > When I disable both valid modifications work. > > Ciao, Michael. > > Ok, here is an attempt to fix this: ftp://ftp.openldap.org/incoming/jsynacek-20120821-slapo-constraint-set-fix.… Done on top of the latest OPENLDAP_REL_ENG_2_4 (7da024d80). Michael, can you please give it a quick try? I will update the testsuit as well. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7361) alock is broken on Windows
by hyc＠OpenLDAP.org 21 Aug '12

21 Aug '12

Full_Name: Howard Chu Version: 2.4.32 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc alock assumes (wrongly) that it can always read from a locked region. That's true for POSIX advisory locks, but Windows locks are mandatory. I.e., attempting to read from a region with a write lock returns EACCES. Because alock doesn't detect this situation correctly, it will end up waiting forever to acquire a lock on a region that's already locked. (E.g., if slapd is already running and slapcat is started, slapcat will hang trying to get the region lock.) A fix is coming shortly.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 21 Aug '12

21 Aug '12

It seems the following set-based constraints falsely fail even with valid modifications: ---------------------------- snip ---------------------------- # cn value has to be concatenated givenName SP sn constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" restrict="ldap:///ou=People,dc=infraldap,dc=onlinebrief,dc=de??sub?(objectClass=dpagE2Person)" # homeDirectory value has to be concatenated "/home/" uid constraint_attribute uid,homeDirectory set "([/home/] + this/uid) & this/homeDirectory" restrict="ldap:///ou=People,dc=infraldap,dc=onlinebrief,dc=de??sub?(objectClass=posixAccount)" ---------------------------- snip ---------------------------- When I disable both valid modifications work. Ciao, Michael.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 21 Aug '12

21 Aug '12

This is a cryptographically signed message in MIME format. --------------ms080200020003000908060002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quanah Gibson-Mount wrote: > --On Monday, August 20, 2012 6:35 PM +0000 michael(a)stroeder.com wrote: >=20 >> michael(a)stroeder.com wrote: >> >> See also >> >> http://www.stroeder.com/temp/openldap-its7340-testrun.tar.gz >=20 > Fix for this is now in RE24, thanks! I get now (24885ef4baaad162bff19a244709770b19983c30) false constraint violation with my customer setup. Note that in opposite to the test suite I'm using static config method. test064 also does not utilize uri- and set-based constraints - both featu= res which I'm heavily using. I will try to come up with test cases failing th= is evening. Ciao, Michael. --------------ms080200020003000908060002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODIxMDcyNTMwWjAjBgkq hkiG9w0BCQQxFgQU98UIRB8yKJKISVTLDD4qDy3bId4wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAmSjae9cFiDXOuB8S3xVI09Q7Njw29o2kPx1Mr6L6yxAA7bW/PIwH6WNqISUw0jMZmYLQ JK5uoumTFRtGNdH44h7HjN6Mt9B+35kIw4X23/Xq/rX8rNx5gUQeiSCN/kHsWQzKLF9i+777 BE2u/DeC6Vc56nLTHCsxbAwzJsscfbPgwiembtBqXiySFg1j3FzlIetRNoCXxiRrLYvzykb5 4aOOmTb9+iY1t2a/5Gx4lLUQ9I2aV/j73F5Q48XAx1CZS+hmucjx7ESaTXa7Nyi20M3nL91s +m3LoaYTJe3xAgLmU3reO+1rRToIxLSs0LMxP19rkFQNUTxNo6Ko95tzpgAAAAAAAA== --------------ms080200020003000908060002--

1 0

Re: (ITS#7340) Regression in slapo-constraint
by quanah＠zimbra.com 20 Aug '12

20 Aug '12

--On Monday, August 20, 2012 6:35 PM +0000 michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: > > See also > > http://www.stroeder.com/temp/openldap-its7340-testrun.tar.gz Fix for this is now in RE24, thanks! --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

1 0

Re: (ITS#7340) Regression in slapo-constraint
by hyc＠symas.com 20 Aug '12

20 Aug '12

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> quanah(a)zimbra.com wrote: >>> --On Saturday, August 18, 2012 2:06 PM +0200 Michael Ströder >>> <michael(a)stroeder.com> wrote: >>>> I experienced the regression with RE24 but did not test with master yet. >>>> But if it works with master the porting to RE24 might have been >>>> incomplete back then. >>> >>> Ok. I'll backport it again, with the large test suite it now has as well, >>> and see what happens. ;) > > Retested with RE24 5e7b8160621ba7ed369ecebc0d03bed745914447 > >>>>>> Starting test064-constraint for bdb... > running defines.sh > slapadd: could not parse entry (line=883) > Starting slapd on TCP/IP port 9011... > Inserting constraint overlay... > ldapadd failed (32)! >>>>>> test064-constraint failed for bdb > (exit 32) > make[2]: *** [bdb-mod] Error 32 > make[2]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' > make: *** [test] Error 2 I see this as well. The test script is not taking into account a backend that is built as a loadable module. Will fix this shortly. -- -- 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#7340) Regression in slapo-constraint
by michael＠stroeder.com 20 Aug '12

20 Aug '12

michael(a)stroeder.com wrote: > quanah(a)zimbra.com wrote: >> --On Saturday, August 18, 2012 2:06 PM +0200 Michael Ströder >> <michael(a)stroeder.com> wrote: >>> I experienced the regression with RE24 but did not test with master yet. >>> But if it works with master the porting to RE24 might have been >>> incomplete back then. >> >> Ok. I'll backport it again, with the large test suite it now has as well, >> and see what happens. ;) Retested with RE24 5e7b8160621ba7ed369ecebc0d03bed745914447 >>>>> Starting test064-constraint for bdb... running defines.sh slapadd: could not parse entry (line=883) Starting slapd on TCP/IP port 9011... Inserting constraint overlay... ldapadd failed (32)! >>>>> test064-constraint failed for bdb (exit 32) make[2]: *** [bdb-mod] Error 32 make[2]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' make: *** [test] Error 2 See also http://www.stroeder.com/temp/openldap-its7340-testrun.tar.gz Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs