openldap-bugs April 2016

openldap-bugs@openldap.org

19 participants
66 discussions

Re: (ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠zimbra.com 04 Apr '16

04 Apr '16

--On Sunday, April 03, 2016 3:34 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) Closing this ITS, it was related to a bug in the code in our side that sets the DH Param bits for slapd, that has a race condition, where the file may be 0 sized initially. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 04 Apr '16

04 Apr '16

Full_Name: Francis Swasey Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.2 (Maipo) URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz Submission from: (NULL) (132.198.104.198) Once an hour, the primary server logs a syncprov_sendresp that does not include a csn. When that happens, the replica misses that there were changes and does not update and therefore falls behind. The URI provides files for the primary and replica. replica/slapd_db.ldif -- starting database replica/slapd.conf -- replica's slapd configuration file (you'll need to create your own ssl certs) replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the path to check_syncrepl replica/check_syncrepl -- Used by nagios to report csn being in sync or not primary/slapd_db.ldif -- starting database (almost exactly like the replica's version) primary/slapd.conf -- primary's slapd configuration file (you'll need to create your own ssl certs) primary/syncprov_audit.sh -- greps the system log (edit the path) looking for the syncprov error primary/makechanges.sh -- edit to change the name of the ldap server and run this to make constant changes The bad log entries that coincide with check_syncrepl finding the replica has fallen behind are like: Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 They appear once an hour.

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 04 Apr '16

04 Apr '16

My initial report was garbled. What I mean is that a protection violation occurs in mdb.c when I add a 13'th item to a multiset and I compile with one of the mentioned compilers and with -fPIC -O3. The code works fine when compiled with older GCC compilers or with -O0 or with -fno-strict-aliasing. Given what I read at https://gcc.gnu.org/bugs/ under section "Casting does not work as expected when optimization is turned on", I suspect the problem is simply that a pointer variable is not following the ISO C aliasing rules and breaks with the new, more aggressive compiler optimization. Here is the part that fails: for (i=0; i<NUMKEYS(fp); i++) mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; If this turns out to not be straightforward, I can try building a small test program to reproduce the problem. On 04/03/2016 09:44 AM, Howard Chu wrote: > bdallen(a)nps.edu wrote: >> Full_Name: Bruce Allen >> Version: 2.4.44 >> OS: Fedora 23 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (205.155.65.226) >> >> >> LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when >> compiled >> using these compilers: >> * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) >> * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW >> 5.2.0-1.fc23) >> >> The crash happens afterrititing the 12'th item (with the same key but >> different >> value using flags MDB_NODUPDATA and MDB_DUPSORT). > > Your message appears garbled here. Please send a test case with steps > to reproduce. >> >> The problem goes away when compiling mdb.c with the >> -fno-strict-aliasing flag. >> >> > >

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by hyc＠symas.com 03 Apr '16

03 Apr '16

bdallen(a)nps.edu wrote: > Full_Name: Bruce Allen > Version: 2.4.44 > OS: Fedora 23 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.155.65.226) > > > LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled > using these compilers: > * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) > * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) > > The crash happens afterrititing the 12'th item (with the same key but different > value using flags MDB_NODUPDATA and MDB_DUPSORT). Your message appears garbled here. Please send a test case with steps to reproduce. > > The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag. > > -- -- 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#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠openldap.org 02 Apr '16

02 Apr '16

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) While testing the new DH params code for slapd, we found that there is an interval in which slapd will break for startTLS connections while it loads in the DH key. Example: Slapd is up and running, accepts startTLS connections just fine: Apr 2 21:13:08 zre-ldap002 slapd[4844]: conn=1004 fd=13 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=AES256-SHA256 Then we update olcTLSDHParamFile to add a DH key: Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD dn="cn=config" Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD attr=olcTLSDHParamFile Immediately after this, all startTLS attempts fail for the next few minutes: Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 fd=14 ACCEPT from IP=10.137.242.52:48327 (IP=10.137.242.52:389) Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 STARTTLS Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 RESULT oid= err=52 etime=0.000078 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 fd=14 closed Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 ACCEPT from IP=10.137.242.52:48328 (IP=10.137.242.52:389) Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 STARTTLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 RESULT oid= err=52 etime=0.000054 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 closed Apr 2 21:13:17 zre-ldap002 slapd[4844]: connD1D1010 fd=14 ACCEPT from IP=10.137.242.52:48329 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 STARTTLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 RESULT oid= err=52 etime=0.000124 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 fd=14 closed Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 ACCEPT from IP=10.137.242.52:48330 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 STARTTLS Apr 2 21:13:18 zre-lda0202 slapd[4844]: conn=1011 op=0 RESULT oid= err=52 etime=0.000075 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 ACCEPT from IP=10.137.242.52:48331 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 RESULT oid= err=52 etime=0.000098 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 ACCEPT from IP=10.137.242.52:48332 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 RESULT oid= err=52 etime=0.000062 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 closed Apr 2 21:13"22 zre-ldap0 s slapd[4844]: conn=1014 fd=14 ACCEPT from IP=10.137.242.52:48333 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 RESULT oid= err=52 etime=0.000108 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=1 UNBIND Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 fd=14 closed Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 fd=14 ACCEPT from IP=10.137.242.52:48334 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 RESULT oid= err=52 etime=0.000066 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=1 UNBIND .... Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022d%d=14 ACCEPT from IP=10.137.242.52:48339 (IP=10.137.242.52:389) Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 STARTTLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 RESULT oid= err=52 etime=0.000143 text=Could not initialize TLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 fd=14 closed (connection lost) Eventually it recovers: Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 ACCEPT from IP=10.137.242.52:48340 (IP=10.137.242.52:389) Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 STARTTLS Apr 2 21:16:02 zre-ldap002 slapd[4844]: connD1D1027 op=0 RESULT oid= err=0 etime=0.000085 text= Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.2 tls_cipher=AES128-SHA256 My guess is that startTLS is essentially broken while slapd spends time loading in the DH key. I would think that during this time, slapd should be deferring connections rather than accepting them immediately.

1 0

(ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 01 Apr '16

01 Apr '16

Full_Name: Bruce Allen Version: 2.4.44 OS: Fedora 23 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.155.65.226) LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled using these compilers: * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) The crash happens afterrititing the 12'th item (with the same key but different value using flags MDB_NODUPDATA and MDB_DUPSORT). The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2016