Re: (ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠zimbra.com
--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
7 years, 2 months
(ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu
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.
7 years, 2 months
Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu
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.
>>
>>
>
>
7 years, 2 months
Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by hyc＠symas.com
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/
7 years, 2 months
(ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠openldap.org
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.
7 years, 2 months
(ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu
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.
7 years, 2 months
