Re: [ANNOUNCE] haproxy-1.8-rc2

On Fri, Nov 03, 2017 at 11:54:09PM +, Aleksandar Lazic wrote: > The new version is on docker hub Thanks Aleks! By the way, I've added this line to report whether threads are enabled or not, it will help during bug reports : > haproxy -vv > (...) > Built with PCRE version : 8.32 2012-11-30 >

Re: [ANNOUNCE] haproxy-1.8-rc2

The new version is on docker hub https://hub.docker.com/r/me2digital/haproxy18/ ### HA-Proxy version 1.8-rc2-a8d8d6e 2017/11/03 Copyright 2000-2017 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement

[ANNOUNCE] haproxy-1.8-rc2

Hi, 1.8-rc1 had quite a few painful issues that we managed to sort out, so in order to facilitate testing by most users, here comes 1.8-rc2. Here's an overview of the main changes : - fixed the deadlock that prevented us from using checks and threads at the same time - fixed the bug with t

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

Hi Robert, On Thu, Nov 02, 2017 at 03:58:47PM +, Robert Samuel Newson wrote: > Hi, > > I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact > config works with 1.7 but says this for 1.8-rc1; > > unable to stat SSL certificate from file '/path/to/foo.pem': No such file o

Re: [PATCH] send-proxy-v2-ssl-crypto parameter

Hi Manu, On Thu, Nov 02, 2017 at 02:57:10PM +0100, Emmanuel Hocdet wrote: > > Hi Willy, > > This patches implement send-proxy-v2-ssl-crypto to add CIPHER > SIG_ALG and KEY_ALG to send-proxy-v2-ssl as describe in proxy-protocol.txt I'm delaying this a bit, we first need to stabilize rc1. New stu

Re: Error 'NAME_MAX' undeclared in HAProxy 1.8 on Solaris 11.3 (64-bit)

On Fri, Nov 03, 2017 at 11:17:25PM +0100, Daniel Heitepriem wrote: > Hi Willy, > > when including "DEFINE="-DNAME_MAX=MAXPATHLEN"" in the build statement, > HAProxy compiles fine (leaving the warning aside). Cool, thank you for the report. willy

Re: Throughput issue after moving between kernels.

Hi Aaron, On Fri, Nov 03, 2017 at 07:23:20PM +, Aaron West wrote: > I think I understand that with faster networks giving shorter RTT you > need less buffer space and then as either RTT or throughput > increases(Maybe 40G+) then you will need more, am I right? no :-) It's the opposite, the BD

Re: Error 'NAME_MAX' undeclared in HAProxy 1.8 on Solaris 11.3 (64-bit)

Hi Willy, when including "DEFINE="-DNAME_MAX=MAXPATHLEN"" in the build statement, HAProxy compiles fine (leaving the warning aside). ./haproxy -vv HA-Proxy version 1.8-rc1 2017/10/31 Copyright 2000-2017 Willy Tarreau Build options :   TARGET  = solaris   CPU = generic

Re: Error 'NAME_MAX' undeclared in HAProxy 1.8 on Solaris 11.3 (64-bit)

Hi Daniel, On Fri, Nov 03, 2017 at 04:00:08PM +0100, Daniel Heitepriem wrote: > Hi everyone, > > I tried to compile the recent HAProxy 1.8 (pulled from the git > repository) on Solaris 11.3 (x86) with these settings: > gmake TARGET=solaris CPU=generic USE_TPROXY=1 USE_ZLIB=1 USE_OPENSSL=1 > USE_P

Re: Throughput issue after moving between kernels.

I think I understand that with faster networks giving shorter RTT you need less buffer space and then as either RTT or throughput increases(Maybe 40G+) then you will need more, am I right? So maybe it was changed to take into account modern internet links, however, that doesn't explain the observe

RE: HTTP DELETE command failing

This particular DELETE was designed to return a 204 – no payload expected. So the test which insisted on payload was incorrect. Problem solved. Thanks. From: Igor Cicimov [mailto:ig...@encompasscorporation.com] Sent: November-02-17 8:56 PM To: Norman Branitsky Cc: Moemen MHEDHBI ; haproxy@formilu

Re: log-format in defaults section in 1.7

Thank you! That's good to know. On Thu, Nov 2, 2017 at 5:36 PM Cyril Bonté wrote: > Hi Thayne, > > Le 02/11/2017 à 23:08, Thayne McCombs a écrit : > > So, I looked into using `no log` in non http frontends. But that isn't > > sufficient. > > > > For example, if I have: > > > > global > >log-

Re: [PATCH] : BUG/MINOR

On Fri, Nov 03, 2017 at 02:59:52PM +, David CARLIER wrote: > Sure makes sense in this case. Cheers. nice, thanks! Willy

[PATCHES] TLS 1.3 session resumption and early data to servers

Hi, The attached patches makes TLS 1.3 session resumption work (it is a bit different than the previous version, as the session is created after the handshake), and enable sending early data to the server, as long as the client used early data (we can't afford to send early data without knowing if

Re: Throughput issue after moving between kernels.

Though it would not cause your problem, the reason for this is: In 3.10.18: https://elixir.free-electrons.com/linux/v3.10.18/source/net/ipv4/tcp.c void tcp_init_mem (struct net *net){ unsigned long limit

Re: [PATCH] : BUG/MINOR

Sure makes sense in this case. Cheers. On 3 November 2017 at 14:50, Willy Tarreau wrote: > On Fri, Nov 03, 2017 at 02:45:43PM +, David CARLIER wrote: > > Hi again, > > > > while testing a build, clang spotted the health desc field improper check > > so here a little patch proposal. That shou

Error ‘NAME_MAX’ undeclared in HAProxy 1.8 on Solaris 11.3 (64-bit)

Hi everyone, I tried to compile the recent HAProxy 1.8 (pulled from the git repository) on Solaris 11.3 (x86) with these settings: gmake TARGET=solaris CPU=generic USE_TPROXY=1 USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 USE_GETADDRINFO=1 USE_REGPARM=1 DEFINE="-D_XOPEN_SOURCE=600" "-D_XOPEN_SOURCE=600" i

Re: Quick question re errorloc urls

Hello Andy, 2017-11-03 13:44 GMT+01:00 Franks Andy (IT Technical Architecture Manager) : > First of all, the errorloc “redirection” from a 503 works fine but since > this intranet page is configured using an internal CA certificate and for > some reason the client doesn’t see the letscrypt certif

Re: [PATCH] : BUG/MINOR

On Fri, Nov 03, 2017 at 02:45:43PM +, David CARLIER wrote: > Hi again, > > while testing a build, clang spotted the health desc field improper check > so here a little patch proposal. That should be all after it :-). I *think* that in fact we just have to remove the test. We need to look thro

[PATCH] : BUG/MINOR

Hi again, while testing a build, clang spotted the health desc field improper check so here a little patch proposal. That should be all after it :-). Kind regards. From e96a3190ada573dc39eb16e721dd1b9c297f9c45 Mon Sep 17 00:00:00 2001 From: David Carlier Date: Fri, 3 Nov 2017 14:41:46 + Subj

Re: [PATCH]: BUG/MINOR

On Fri, Nov 03, 2017 at 02:37:24PM +, David CARLIER wrote: > Sure thing. and it does :-) thank you! Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

Hi Dmitry, On Fri, Nov 03, 2017 at 03:11:21PM +0300, Dmitry Sivachenko wrote: > Hello, > > several new warnings from clang, some look meaningful: Thanks, Olivier also reported some of them. Some are valid or easy to address, others might need some -Wno-something I guess. > src/server.c:875:14:

Re: [PATCH]: BUG/MINOR

Sure thing. and it does :-) On 3 November 2017 at 14:05, Willy TARREAU wrote: > Hi David, > > On Fri, Nov 03, 2017 at 12:03:53PM +, David CARLIER wrote: > > Hi > > > > Here is a tiny diff while I was trying to build under OpenBSD (not sure > if > > few other oses are affected like Solaris bu

Re: Logging errors during reload of haproxy

Hello, > This is a test system with not much load other than my little 'ab -c 10 ...' > is creating. We have unix logging everywhere locally, works even under heavy > load. Be that as it may, this is a syscall returning an error: http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/log.c;h=88e0d

Re: [PATCH]: BUG/MINOR

Hi David, On Fri, Nov 03, 2017 at 12:03:53PM +, David CARLIER wrote: > Hi > > Here is a tiny diff while I was trying to build under OpenBSD (not sure if > few other oses are affected like Solaris but this change is not overkill I > think). Cool, thanks, now applied. By the way since you're t

Re: Logging errors during reload of haproxy

Hi Lukas, On 11/03/2017 02:53 PM, Lukas Tribus wrote: # service haproxy reload [ALERT] 306/110738 (29225) : sendmsg logger #1 failed: Resource temporarily unavailable (errno=11) Well the destination logging socket is unavailable. I don't think there is a lot to do here on the haproxy side, thi

Re: Logging errors during reload of haproxy

Hello Veiko, 2017-11-03 12:21 GMT+01:00 Veiko Kukk : > Hi, > > I noticed, while trying to reproduce conditions for another bug about > processes never closing after restart, that sometimes reload causes logging > errors displayed. > > Following config section might be relevant: > > global > log

Throughput issue after moving between kernels.

Hi All, We have been investigating an issue with reduced throughput. (its quite possible that its nothing to do with HAProxy.) I thought I would just check here to see if this rings a bell with anyone. We are currently looking to update our kernel from 3.10.18 to 4.4.49. It appears that in the mo

Quick question re errorloc urls

Hi all, We have a test haproxy instance that is using a letscrypt certificate, and is in a DMZ zone. We have internal network servers delivering an application via https using an internal CA certificate, and all works fine - the client connects, sees the letscrypt cert and since the load balan

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

> On 01 Nov 2017, at 02:20, Willy Tarreau wrote: > > Hi all! > Hello, several new warnings from clang, some look meaningful: cc -Iinclude -Iebtree -Wall -O2 -pipe -fstack-protector -fno-strict-aliasing -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-address-of-packed-m

[PATCH]: BUG/MINOR

Hi Here is a tiny diff while I was trying to build under OpenBSD (not sure if few other oses are affected like Solaris but this change is not overkill I think). Kind regards. From deb8a3aca9aec73d2edd3461e5bf2d0f7c9153f5 Mon Sep 17 00:00:00 2001 From: David Carlier Date: Fri, 3 Nov 2017 12:00:26

Re: Logging errors during reload of haproxy

On 11/03/2017 01:21 PM, Veiko Kukk wrote: Hi, I noticed, while trying to reproduce conditions for another bug about processes never closing after restart, that sometimes reload causes logging errors displayed. Should read here "never closing after *reload*". Veiko

Logging errors during reload of haproxy

Hi, I noticed, while trying to reproduce conditions for another bug about processes never closing after restart, that sometimes reload causes logging errors displayed. Following config section might be relevant: global log /dev/log local0 nbproc 3 defaults log /dev/log local0 fronten