openldap-bugs September 2010

openldap-bugs@openldap.org

26 participants
109 discussions

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 09 Sep '10

09 Sep '10

I've just tested this scenario using the back-meta sources (and slap.h,sl_malloc.c) from HEAD. I also tried to add "tls start" to the back-meta configuration. Unfortunately, the problem still persists. (But the workaround, setting LDAPTLS_..., still works) When I look at the debug outputs (at debug level 1), the first difference is in the SSL_connect messages. Only my workaround method is sending the "write certificate verify" to authenticate with the certificate, whereas it doesn't send this message without the workaround. The Output from the "good" request (with workaround) is ----------------------------------------------------------------------------------------- TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server key exchange A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write certificate verify A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_int_sasl_open: host=localhost ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ----------------------------------------------------------------------------------------- The output from the request without the workaround: ----------------------------------------------------------------------------------------- TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server key exchange A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_int_sasl_open: host=localhost ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 15 TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed ----------------------------------------------------------------------------------------- Regards, Manuel

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

The issue should be fixed in HEAD both for back-meta and back-ldap; now if TLS is required by idassert it will be started. Moreover, back-meta now allows to specify tls options per-target. The man page has not been updated yet. Please test and report through the ITS. Thanks, p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 08 Sep '10

08 Sep '10

--On Monday, September 06, 2010 3:11 AM +0200 masarati(a)aero.polimi.it wrote: > Should now be fixed in HEAD; platform independent, on Linux was not > failing but memory was being used incorrectly. ldapsearch-specific, no > issue in client library. Please test. Thanks, p. > I can confirm the issue no longer occurs with this patch in place. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6642
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

The problem is slightly different: the tls_* parameters of idassert are ignored unless TLS is started for other reasons. I believe back-meta needs to automatically start TLS for those connections created by idassert when idassert requires TLS for authentication. You can work this around by setting tls start this forces TLS to be started on all connections (tls try-start will fall back to non-TLS if it cannot be started). I note that there is an asymmetry between back-ldap and back-meta: the former allows to configure specific tls_* parameters for the "tls" statement. However, also back-ldap seems to require the "tls" statement to honor EXTERNAL TLS-based idassert. p.

1 0

(ITS#6643) back-meta silently retries anonymously in case of idassert with auth method not supported
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.240) Submitted by: ando A fix is coming. p.

1 0

(ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 08 Sep '10

08 Sep '10

Full_Name: Manuel Gaupp Version: 2.4.23 OS: Linux 2.6/x86 URL: Submission from: (NULL) (93.222.169.203) Hi, as described in http://www.openldap.org/lists/openldap-technical/201009/msg00073.html using SASL EXTERNAL authentication within back-meta is not possible without the workaround to set some LDAPTLS_... environment variables. In http://www.openldap.org/lists/openldap-technical/201009/msg00085.html it is mentioned, that back-meta ignores the tls_... parameters for SASL EXTERNAL auth. I used the following configuration ------------------------------------------------- database meta suffix "dc=example" uri "ldaps://server2:636/cn=server2,dc=example" idassert-authzFrom "dn:*" idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=mycert.crt tls_key=mycert.key tls_cacert=trusted-ca.pem mode=none ------------------------------------------------- At least, the options tls_cert,tls_key and tls_cacert should work properly to authenticate with TLS certificates. Thanks in advance Manuel Gaupp

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by gturner＠unzane.com 07 Sep '10

07 Sep '10

Hello folks, I've never used a jitterbug, so I hope this email goes to the right place and doesn't spam up the system. I've been experiencing the same problem as Mark. I use OpenLDAP 2.4.23 packaged in Debian. I have a few processes that connect to ldapi:/// socket and do anonymous binds, there are one or two "no connection!" log messages each time these processes run. None of my remote connections produce these messages. This happens at very low volume, when slapd is idle. When slapd gets more utilization, maybe one or two requests per second, the noise stops. I've spent a few hours looking at the source of OpenLDAP slapd and libldap, also Perl Net::LDAP (the client most often generating these log entries on my system). The source code for OpenLDAP looks very clean, but I'm no C expert, and I'm lost in the asynchronous nature of the connection.c. FYI, Net::LDAP doesn't use libldap - it's all Perl, no native libraries. After hundreds of tests and various olcLogLevel settings I've finally stumbled upon something that solves the problem... usleep(1); I know this has to be the lamest bug report ever, but it works, please bear with me. The first thing that tipped me to try 'usleep' was that with olcLogLevel set to "trace packets args conns stats", I get the following output: connection_get(14) connection_get(14): got connid=1007 connection_read(14): checking for input on id=1007 * op tag 0x42, time 1283917507 * ber_get_next on fd 14 failed errno=0 (Success) connection_read(14): input error=-2 id=1007, closing. connection_closing: readying conn=1007 sd=14 for close connection_close: deferring conn=1007 sd=14 conn=1007 op=2 do_unbind conn=1007 op=2 UNBIND connection_resched: attempting closing conn=1007 sd=14 connection_close: conn=1007 sd=14 daemon: removing 14 conn=1007 fd=14 closed daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero connection_get(14) connection_get(14): connection not used connection_get(14) connection_get(14): connection not used connection_read(14): no connection! connection_read(14) error connection_read(14): no connection! The two lines I marked with asterisks are the output from the connection_input function, "op tag 0x42..." should be printed after "ber_get_next on fd 14 failed...", but it's not - so evidently this function is reentrant, the input loop is processing both the UNBIND request and the client closing the socket at the same time, and unfortunately the socket close processing came first so that connection_input thread tears down the connection. Now with the perl scripts I tried adding a microsecond sleep just after they unbind and before they exit, it worked - haven't seen any "no connection!" logs from them for hours. As for the libldap-client and ldapsearch commands, everytime I executed a simple 'ldapsearch -x -H ldapi:///' I'd get two "no connection!" log messages. I tried the same braindead usleep(1) solution and it worked. The following is the diff of what I changed to libldap, ldap_free_connection function in request.c: if ( unbind ) { ldap_send_unbind( ld, lc->lconn_sb, NULL, NULL ); + Debug( LDAP_DEBUG_TRACE, + "ldap_free_connection: sleeping after unbind\n", + 0, 0, 0 ); + usleep(1); } Here's the last bits of output from ldapsearch with -d3 after applying this brutal "fix" to libldap: ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: sleeping after unbind ldap_free_connection: actually freed Notice the bytes getting flushed between unbind, my dumb sleep, and "actually freed". Without the sleep it seems slapd may process the close before the unbind. -- Gerald Turner Email: gturner(a)unzane.com JID: gturner(a)jabber.unzane.com GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5

1 0

Re: (ITS#5796) back-sql intermittently failing
by frederik.bosch＠gmail.com 07 Sep '10

07 Sep '10

http://www.openldap.org/lists/openldap-technical/201009/msg00070.html While googling for reconnect in the ODBC API I found this: http://dev.mysql.com/doc/refman/5.0/en/connector-odbc-configuration-connect… option 4194304: Enables auto-reconnection functionality. It seems like it fixes my problem.

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by andrew.findlay＠skills-1st.co.uk 07 Sep '10

07 Sep '10

On Tue, Sep 07, 2010 at 05:09:07AM -0700, Howard Chu wrote: >> We've talked about doing this isolation in the first refresh upon slapd >> startup. That might still be a good idea. It would certainly help to keep the apparent promises made by things like the uniqueness overlay. Alternatively you could take the view that the data will converge eventually and that is all that the LDAP standards promise. > But that reminds me of the joys of being a Sun sysadmin back in the 1980s, > when Sun's boot scripts always started their NFS client before starting > their NFS server. If two machines cross-mounted each other's filesystems > and both were booting at the same time they would hang, each waiting for > the other's NFS server to respond to their mount request. I remember that - one of the many reasons for switching to automounters (along with their own set of problems)... The alternative was 'soft' mounts, which may be a better model for solving the mirrormode problem. > Mirrormode and multimaster bootstrapping becomes a lot harder if you > implement this type of isolation during startup refresh. I was originally going to suggest that servers should not listen for connections until the first refresh completes, but that would indeed cause the deadlock you describe. How about having master servers listen on an extra port which is used purely for replication and *is* available immediately? The main LDAP port would thus remain closed until the server is synced-up, making it much easier for load-balancers to do the right thing. [This should really be a separate discussion as it is not directly related to the bug.] >> Doing it on every refresh seems far more problematic, because without some >> type of multi-version concurrency control, that means making the server >> non-responsive until the refresh completes. That may not be a problem with refresh-and-persist, as in normal circumstances I would expect updates to arrive at the consumer in the same order they hit the supplier (so this bug could not trigger). More difficult for scheduled refresh mode though. Could the consumer server simply write-lock every entry involved in the refresh while it processes the list, and then commit the whole lot in one DB transaction? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by hyc＠symas.com 07 Sep '10

07 Sep '10

Howard Chu wrote: > andrew.findlay(a)skills-1st.co.uk wrote: >> Full_Name: Andrew Findlay >> Version: 2.4.23 >> OS: SLES 10.3 x86_64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.97.25.132) >> >> >> The attribute uniqueness overlay can cause syncrepl to jam up. >> Consider this case: > >> The obvious answer is for syncrepl to bypass all data checks, as the supplier >> server should have already enforced them. The problem with that is that clients >> could see data that breaks the rules if they query while syncrepl is running >> (unless the refresh phase is handled as a single transaction and thus isolated >> from clients until it is complete). > > We've talked about doing this isolation in the first refresh upon slapd > startup. That might still be a good idea. But that reminds me of the joys of being a Sun sysadmin back in the 1980s, when Sun's boot scripts always started their NFS client before starting their NFS server. If two machines cross-mounted each other's filesystems and both were booting at the same time they would hang, each waiting for the other's NFS server to respond to their mount request. Mirrormode and multimaster bootstrapping becomes a lot harder if you implement this type of isolation during startup refresh. > Doing it on every refresh seems far more problematic, because without some > type of multi-version concurrency control, that means making the server > non-responsive until the refresh completes. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2010