openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

29 Aug '12

Howard Chu writes: > PTHREAD_PROCESS_SHARED is defined just about everywhere, that's not a useful > test. (You only discover at runtime that the mutex creation/init failed...) Argh. Oh well, we should only do the namespace cleanup, then. __BSD__ symbols etc. BTW, I think the lock file should contain a field indicating the sync primitive type, so different compilations of MDB won't use different sync primitives. Which maybe also means we might as well pick the primitive at runtime (try PTHREAD_PROCESS_SHARED first, then sem_open). -- Hallvard

1 0

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

29 Aug '12

h.b.furuseth(a)usit.uio.no wrote: > We can #ifndef PTHREAD_PROCESS_SHARED instead of BSD, unless someone > #define it without supporting it. Not for MDB_FDATASYNC though. > PTHREAD_PROCESS_SHARED is defined just about everywhere, that's not a useful test. (You only discover at runtime that the mutex creation/init failed...) -- -- 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#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by h.b.furuseth＠usit.uio.no 29 Aug '12

29 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs