1.7.6 redirect regression (commit 73d071ecc84e0f26ebe1b9576fffc1ed0357ef32)

2017-06-20 Thread Jarno Huuskonen 
Hi,

1.7.6 gives me errors (in log) with redirect rules. Example config that
produces 503 errors in logs and curl -v complains:
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://127.0.0.1:8080/
< 
* Excess found in a non pipelined read: excess = 212 url = /
* (zero-length body)
* Connection #0 to host 127.0.0.1 left intact

Example config:
frontend test
bind ipv4@127.0.0.1:8080

redirect scheme https code 301 if { dst_port 8080 }
# this also gives 503
#http-request redirect scheme https code 301 if { dst_port 8080 }
default_backend test_be2

backend test_be2
server wp1 ip.add.re.ss:80 id 1 

(I have quite a few redirect rules in prod. config and all seem to
produce 503 in logs).

git bisect gives this commit as "bad":

commit 73d071ecc84e0f26ebe1b9576fffc1ed0357ef32
BUG/MINOR: http: Fix conditions to clean up a txn and to handle the next req

If I revert this commit then the example config gives 301 in log and
curl doesn't complain about read.

-Jarno

-- 
Jarno Huuskonen

BUG: frontend IP/port logging broken since 9b061e332

2017-06-20 Thread Lukas Tribus 
Hello,


as per Mathias Weiersmueller's report on discourse [1], there is a bug
in TCP logging when using a custom log-format, accessing the frontend
IP or port (%fi/%fp or the deprecated form %Fi/%Fp) in conjunction with
other log variables like %Tw or %B.

Repro config:

global
 log  syslog debug
defaults
 log global
 log-format %Fi/%B
listen Test
 bind :80
 server test-src2 10.0.0.254:80


If the %B variable is removed from the above config, logging also works
fine.

This is broken since commit 9b061e332 ("MEDIUM: bstream_sock: add a
get_src and get_dst callback and remove SN_FRT_ADDR_SET"), which is in
1.5-dev9, so this is broken for some time now.


Gonna need someone smarter than me for this one.


cheers,
lukas


[1] 
http://discourse.haproxy.org/t/frontend-ip-and-ports-not-logged-in-tcp-mode-custom-log-format-fi-fp/1353/1

Re: [PR] Update transparent_proxy.cfg

2017-06-20 Thread Willy Tarreau 
On Tue, Jun 20, 2017 at 07:29:29PM +0200, PR Bot wrote:
> Dear list!
> 
> Author: hflamboauto1 
> Number of patches: 1
> 
> This is an automated relay of the Github pull request:
>Update transparent_proxy.cfg
> 
> Patch title(s): 
>Update transparent_proxy.cfg
> 
> Link:
>https://github.com/haproxy/haproxy/pull/79
> 
> Edit locally:
>wget https://github.com/haproxy/haproxy/pull/79.patch && vi 79.patch
> 
> Apply locally:
>curl https://github.com/haproxy/haproxy/pull/79.patch | git am -
> 
> Description:
>This is basically a question regarding this value.
>Everywhere on
>"internet resources" i see *clientip* ... which one is correct? This
>example ?

Both are valid, have a look at doc/configuration.txt. In short :

  - "client" asks to reuse both the client's address and port. This is
the most transparent mode, when you know what you're doing, and the
one with the least risk of running out of source ports. But it
requires that you properly configure your timeouts.

  - "clientip" only reuses the source address, and lets the system
allocate a spare port.

Willy

[PR] Update transparent_proxy.cfg

2017-06-20 Thread PR Bot 
Dear list!

Author: hflamboauto1 
Number of patches: 1

This is an automated relay of the Github pull request:
   Update transparent_proxy.cfg

Patch title(s): 
   Update transparent_proxy.cfg

Link:
   https://github.com/haproxy/haproxy/pull/79

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/79.patch && vi 79.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/79.patch | git am -

Description:
   This is basically a question regarding this value.
   Everywhere on
   "internet resources" i see *clientip* ... which one is correct? This
   example ?

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Re: HAProxy 1.5.18 - rare handshake failure - Bad Record MAC

2017-06-20 Thread Lukas Tribus 
Hello,


Am 20.06.2017 um 17:00 schrieb Teichmann, Janek:
>> I'm not sure if this was backported in RedHat/CentOS. Is the package 
>> uptodate (should be openssl-1.0.1e-60.el7.x86_64 afaik)?
> By now openssl is recent (your version is right), but there are for long no 
> openssl bugfixes. I couldn't find one in the Release Note of RHEL 7.0-3.
>

Actually the bug I mentioned was fixed in openssl-1.0.1e-34.el7_0.3 back in 
2014:
https://rhn.redhat.com/errata/RHSA-2014-0679.html

So that is actually not the root cause, but going to OpenSSL 1.0.2k is 
definitely the
way to go forward in this issue.


cheers,
lukas

AW: HAProxy 1.5.18 - rare handshake failure - Bad Record MAC

2017-06-20 Thread Teichmann, Janek 
Hello Lukas,

thank you very much.
Tomorrow I will migrate the configuration to a tcp load balancer until CentOS 
7.4 is coming. There will be OpenSSL 1.0.2k included. See:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/7.4_Release_Notes/new_features_security.html#BZ1276310



> I'm not sure if this was backported in RedHat/CentOS. Is the package uptodate 
> (should be openssl-1.0.1e-60.el7.x86_64 afaik)?
By now openssl is recent (your version is right), but there are for long no 
openssl bugfixes. I couldn't find one in the Release Note of RHEL 7.0-3.

Regards
Janek

Re: master-worker and seamless reload (bug)

2017-06-20 Thread Willy Tarreau 
On Tue, Jun 20, 2017 at 02:41:51PM +0200, William Lallemand wrote:
> Willy, could you merge them? thanks

done, thanks!
willy

Re: master-worker and seamless reload (bug)

2017-06-20 Thread William Lallemand 
On Mon, Jun 19, 2017 at 03:35:08PM +0200, Emmanuel Hocdet wrote:
> In case of upgrade from haproxy without -x option to -x, i suppose it will do 
> cleanly.
> I try to play with -x, multi-proc (add and remove), upgrade pre -x  without 
> master-worker and is painful.
> Perhaps i misunderstood (and i used multi -x). Now, i only test from legacy 
> to  -x with master-worker.
> 
> > I think that's just a matter of documentation, maybe I can write a longer
> > paragraph in the management.txt doc explaining how to upgrade for the legacy
> > mode, and what changed between this one and the master worker.
> 
> Yes, documentation must be sufficient to avoid bad usages. What about case of 
> multi -x?
> 

Well, the -x should be unique, you don't need several -x, one socket is enough
because you have access to every FD of every processes from it. I add a warning
about that.

I fixed the few issues you had in the attached patches.

Willy, could you merge them? thanks

-- 
William Lallemand
>From 9927f4a1e864638e16dcb3c61de23bcc8f256a91 Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Mon, 19 Jun 2017 15:57:55 +0200
Subject: [PATCH 1/4] BUG/MEDIUM: fix segfault when no argument to -x option

This patch fixes a segfault in the command line parser.

When haproxy is launched with -x with no argument and -x is the latest
option in argv it segfaults.

Use usage() insteads of exit() on error.
---
 src/haproxy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index d64058da..2fd387f3 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -1279,9 +1279,9 @@ static void init(int argc, char **argv)
 			else if (*flag == 'q')
 arg_mode |= MODE_QUIET;
 			else if (*flag == 'x') {
-if (argv[1][0] == '-') {
-	Alert("Unix socket path expected with the -x flag\n");
-	exit(1);
+if (argc <= 1 || argv[1][0] == '-') {
+	Alert("Unix socket path expected with the -x flag\n\n");
+	usage(progname);
 }
 old_unixsocket = argv[1];
 argv++;
-- 
2.13.0

>From 0dc2e1f497f475e541056e0769431528a6edb39c Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Mon, 19 Jun 2017 16:37:19 +0200
Subject: [PATCH 2/4] MINOR: warning on multiple -x

Multiple use of the -x option is useless, emit a warning.
---
 src/haproxy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/haproxy.c b/src/haproxy.c
index 2fd387f3..1eabb552 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -1283,7 +1283,10 @@ static void init(int argc, char **argv)
 	Alert("Unix socket path expected with the -x flag\n\n");
 	usage(progname);
 }
+if (old_unixsocket)
+	Warning("-x option already set, overwriting the value\n");
 old_unixsocket = argv[1];
+
 argv++;
 argc--;
 			}
-- 
2.13.0

>From 17f2decfe5d667d77415d390c61f839db8470065 Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Tue, 20 Jun 2017 11:20:23 +0200
Subject: [PATCH 3/4] MINOR: mworker: don't copy -x argument anymore in
 copy_argv()

Don't copy the -x argument anymore in copy_argv() since it's already
allocated in mworker_reload().

Make the copy_argv() more consistent when used with multiple arguments
to strip.

It prevents multiple -x on reload, which is not supported.
---
 src/haproxy.c | 36 +---
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 1eabb552..cdb6066b 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -596,23 +596,12 @@ static void mworker_reload()
 	}
 	next_argv[next_argc] = NULL;
 
-	/* if -x was used, try to update the stat socket if not available anymore */
+	/* add the -x option with the stat socket */
 	if (cur_unixsocket) {
 
-		if (old_unixsocket) {
-
-			/* look for -x  */
-			for (j = 0; next_argv[j]; j++) {
-if (!strcmp(next_argv[j], "-x"))
-	next_argv[j + 1] = (char *)cur_unixsocket;
-			}
-		} else {
-			/* if -x is not specified but we know the socket, add -x with it */
-			next_argv[next_argc++] = "-x";
-			next_argv[next_argc++] = (char *)cur_unixsocket;
-			next_argv[next_argc++] = NULL;
-
-		}
+		next_argv[next_argc++] = "-x";
+		next_argv[next_argc++] = (char *)cur_unixsocket;
+		next_argv[next_argc++] = NULL;
 	}
 
 	deinit(); /* we don't want to leak FD there */
@@ -1101,7 +1090,7 @@ out:
 static char **copy_argv(int argc, char **argv)
 {
 	char **newargv;
-	int i, j;
+	int i = 0, j = 0;
 
 	newargv = calloc(argc + 2, sizeof(char *));
 	if (newargv == NULL) {
@@ -1109,19 +1098,20 @@ static char **copy_argv(int argc, char **argv)
 		return NULL;
 	}
 
-	for (i = 0, j = 0; i < argc; i++, j++) {
-		char *flag = *(argv + i) + 1;
-
-		/* -sf or -st */
-		if (*flag == 's' && (flag[1] == 'f' || flag[1] == 't')) {
-			/* list of pids to finish ('f') or terminate ('t') */
+	while (i < argc) {
+		/* -sf or -st or -x */
+		if ((argv[i][1] == 's' && (argv[i][2] == 'f' || argv[i][2] == 't')) ||

Re: LoadBalance whole subnet

2017-06-20 Thread William Lallemand 
On Tue, Jun 20, 2017 at 12:49:32PM +0200, Aleksandar Lazic wrote:
> Hi Anamarija.
> 
> ?!
> 
> Do you plan to make the mailing list out of support?!
> 
> Best Regards
> aleks
> 

Hi Aleksandar,

Don't worry that's a mistake, Sarunas put cont...@haproxy.com in copy to his
mail which lead to this.

Please don't continue this thread on the mailing list, thanks.

-- 
William Lallemand

Re: LoadBalance whole subnet

2017-06-20 Thread Aleksandar Lazic 
Title: Re: LoadBalance whole subnet


Hi Anamarija.

?!

Do you plan to make the mailing list out of support?!

Best Regards
aleks


Anamarija Murgic wrote on 20.06.2017:





Hello Sarunas, 


Thank you very much for considering HAProxy products and solutions for your business.
 
If you are looking for help with HAProxy Community Edition then we recommend looking at our community support pages http://discourse.haproxy.org/. They are very active and many experts, including our own developers, get involved. Obviously, answers are given on a voluntary basis so there are no guaranteed responses times.
 
If however, you are interested in commercial solutions we do offer support, consulting and training on all our products. Notably, HAProxy Enterprise Edition (HAPEE), which is a commercially supported version of HAProxy.  It comes as an annual subscription per server and provides you with 3 primary features:
 
1) unlimited access to our support team (offered in Premium 24/7 or Business Hour levels);
2) the Enterprise version of our HAProxy Load Balancer (still GPL)
3) our Enterprise Suite of commercial modules offering additional functionality, availability and security. 

Would you be interested in talking more about our solution or seeing a 1 year quote? 

Looking forward to talking to you.
 
Kind Regards,
Anamarija


On 20/06/2017 8:49 AM, Sarunas Rakauskas wrote:




Hello,

Is it possible to configure HaProxy to automatically balance traffic to 
all subnet VM's(Virtual Machine)? The only answer I found is that you 
need to reconfigure haproxy.cfg file after VM creation and restart 
haproxy service.

Best regards from Lithuania,

Sarunas




-- 
Anamarija Murgic
Account Manager
Tel. +1 (844) 222-4340 / ext.no. 7506
Mobile: +385 99 44 11 521
Email: amur...@haproxy.com
Website: www.haproxy.com

HAProxy Technologies | Powering Your Uptime !



-- 
Best Regards
Aleks

Re: LoadBalance whole subnet

2017-06-20 Thread Anamarija Murgic 

Hello Sarunas,

Thank you very much for considering HAProxy products and solutions for 
your business.


If you are looking for help with HAProxy Community Edition then we 
recommend looking at our community support pages 
http://discourse.haproxy.org/. They are very active and many experts, 
including our own developers, get involved. Obviously, answers are given 
on a voluntary basis so there are no guaranteed responses times.


If however, you are interested in commercial solutions we do offer 
support, consulting and training on all our products. Notably, HAProxy 
Enterprise Edition (HAPEE), which is a commercially supported version of 
HAProxy.It comes as an annual subscription per server and provides you 
with 3 primary features:


1) unlimited access to our support team (offered in Premium 24/7 or 
Business Hour levels);

2) the Enterprise version of our HAProxy Load Balancer (still GPL)
3) our Enterprise Suite of commercial modules offering additional 
functionality, availability and security.



Would you be interested in talking more about our solution or seeing a 1 
year quote?



Looking forward to talking to you.

Kind Regards,

Anamarija



On 20/06/2017 8:49 AM, Sarunas Rakauskas wrote:

Hello,

Is it possible to configure HaProxy to automatically balance traffic to
all subnet VM's(Virtual Machine)? The only answer I found is that you
need to reconfigure haproxy.cfg file after VM creation and restart
haproxy service.

Best regards from Lithuania,

Sarunas



--
Anamarija Murgic
Account Manager
Tel. +1 (844) 222-4340 / ext.no. 7506
Mobile: +385 99 44 11 521
Email: amur...@haproxy.com
Website: www.haproxy.com

HAProxy Technologies | Powering Your Uptime !

LoadBalance whole subnet

2017-06-20 Thread Sarunas Rakauskas 
Hello,

Is it possible to configure HaProxy to automatically balance traffic to 
all subnet VM's(Virtual Machine)? The only answer I found is that you 
need to reconfigure haproxy.cfg file after VM creation and restart 
haproxy service.

Best regards from Lithuania,

Sarunas