Fw:

[Bobby]

Hello,

Our travel agency is offering 50% Off on all Airlines & Hotel Bookings.

This offer is valid only for today.

Call Toll Free (855) 976-2535

Bobby

Travel Deals America

Re[2]: [PATCH] Minor : Add a sampler to extract the microsecond information of the hit date

[Aleksandar Lazic]

Thanks for your answer.

Interesting use case.

Regards
aleks
-- Originalnachricht --
Von: "Etienne Carrière" 
An: "Aleksandar Lazic" 
Cc: haproxy@formilux.org
Gesendet: 17.01.2018 23:28:40
Betreff: Re: [PATCH] Minor : Add a sampler to extract the microsecond 
information of the hit date



Hi,

2018-01-17 20:47 GMT+01:00 Aleksandar Lazic :
(...)

Sounds interesting.
What use case have you in mind for this fetcher?


The use case is the following : we are using SPOE
(http://www.haproxy.org/download/1.8/doc/SPOE.txt) + SPO protocol in a
SaaS logic : Haproxy is in the customer office and our API Server (in
SPOP protocol) is in our datacenter. As the latency is critical, we
wanto to have an heuristic to measure the network latency so we want a
precise timestamp in SPOP message.


I vote for the attached patch, because it's small and looks not to
complicated.


(...)




Regards,

Etienne Carrière

Re: [PATCH] Minor : Add a sampler to extract the microsecond information of the hit date

[Etienne Carrière]

Hi,

2018-01-17 20:47 GMT+01:00 Aleksandar Lazic :
(...)
> Sounds interesting.
> What use case have you in mind for this fetcher?
>
The use case is the following : we are using SPOE
(http://www.haproxy.org/download/1.8/doc/SPOE.txt) + SPO protocol in a
SaaS logic : Haproxy is in the customer office and our API Server (in
SPOP protocol) is in our datacenter. As the latency is critical, we
wanto to have an heuristic to measure the network latency so we want a
precise timestamp in SPOP message.

> I vote for the attached patch, because it's small and looks not to
> complicated.
>
(...)
>

Regards,

Etienne Carrière

Re[3]: How to parse custom PROXY protocol v2 header for custom routing in HAProxy configuration?

[Aleksandar Lazic]

Hi.

Any one any hints?

Regards
aleks

-- Originalnachricht --
Von: "Aleksandar Lazic" 
An: "Adam Sherwood" ; haproxy@formilux.org
Gesendet: 15.01.2018 16:52:15
Betreff: Re[2]: How to parse custom PROXY protocol v2 header for custom 
routing in HAProxy configuration?



Hi.

Follow up question to proxy protocol

Is it possible to handle the Type-Length-Value (TLV)  fields in from 
pp2 in haproxy config or in lua?


I refer to
2.2.7. Reserved type ranges
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

from the question on so 
https://stackoverflow.com/questions/48195311/how-to-parse-custom-proxy-protocol-v2-header-for-custom-routing-in-haproxy-confi


Regards
aleks

-- Originalnachricht --
Von: "Aleksandar Lazic" 
An: "Adam Sherwood" ; haproxy@formilux.org
Gesendet: 11.01.2018 12:24:46
Betreff: Re: How to parse custom PROXY protocol v2 header for custom 
routing in HAProxy configuration?



Hi.

-- Originalnachricht --
Von: "Adam Sherwood" 
An: haproxy@formilux.org
Gesendet: 10.01.2018 23:40:25
Betreff: How to parse custom PROXY protocol v2 header for custom 
routing in HAProxy configuration?


I have written this up as a StackOverflow question here: 
https://stackoverflow.com/q/48195311/2081835.


When adding PROXY v2 with AWS VPC PrivateLink connected to a Network 
Load Balancer, the endpoint ID of the connecting account is added as 
a TLV. I need to use this for routing frontend to backend, but I 
cannot sort out how.


Is there a way to call a custom matcher that could do the parsing 
logic, or is this already built-in and I'm just not finding the 
documentation?


Any ideas on the topic would be super helpful. Thank you.
Looks like AWS use the "2.2.7. Reserved type ranges" as described in 
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt therefore 
you will need to parse this part by your own.


This could be possible in lua, maybe I'm not an expert in lua, yet ;-)

There are javexamples in the doc link ( 
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#proxy-protocol 
) which you have added int the stackoverflow request.


Regards
Aleks

Re: [PATCH] Minor : Add a sampler to extract the microsecond information of the hit date

[Aleksandar Lazic]

Hi.

-- Originalnachricht --
Von: "Etienne Carrière" 
An: haproxy@formilux.org
Gesendet: 17.01.2018 14:02:40
Betreff: [PATCH] Minor : Add a sampler to extract the microsecond 
information of the hit date



Hi,

I propose a patch to add a sampler that extract the microsecond part of 
a hit.

I had 2 ideas for implementation :
* The one in the attached patch which is a new sampler that return an
integer that is only the microsecond part of the timeval structure
* A new sampler that would return a string that would append the
second and the micro-second part (with a dot for separation)

Interested by your opinion,

Sounds interesting.
What use case have you in mind for this fetcher?

I vote for the attached patch, because it's small and looks not to 
complicated.



Regards,

Etienne Carrière

Regards
Aleks

Re: problem in 1.8 with hosts going out of service

[Paul Lockaby]

Ok I've tracked this problem down specifically to the usage of check tracking.

That is to say, the backend "example-api" is set to track the backend 
"example-http". When that tracking is enabled and one of the servers in the 
backend goes down then all of haproxy goes down and never recovers.

So this works:

server myhost myhost.example.com:8445 ssl ca-file 
/usr/local/ssl/certs/cacerts.cert


But this does not:

server myhost myhost.example.com:8445 track example-http/myhost ssl ca-file 
/usr/local/ssl/certs/cacerts.cert


This is definitely a regression from 1.7 because I used this feature in 1.7 
without issue.


> On Jan 16, 2018, at 10:36 PM, Paul Lockaby  wrote:
> 
> I'm experiencing a problem that I can't diagnose but I can recreate pretty 
> consistently. I have a single server that responds for example.com and 
> api.example.com and it runs haproxy. All the names run through an SSL front 
> door but an ACL makes it such that requests for example.com get sent to 8443 
> where Apache runs and requests for api.example.com get sent to 8445 where the 
> same instance of haproxy runs and does further examination of the request and 
> sends it to an application server running on localhost.
> 
> This configuration works great except when I take a server out of the 
> rotation by disabling it with disable-on-404. As soon as I take any server 
> out of the rotation, haproxy completely stops responding to ANY requests for 
> ANY backend even things that aren't part of the group such as the stats 
> backend and frontend. If I put the server back in to service haproxy does not 
> recover. I must restart haproxy on all hosts to recover. Nothing shows up in 
> the logs and I can't figure out how to debug it such that I can provide more 
> information but it's very consistently reproducible using the configuration 
> below. I am running 1.8.3 and I have not tried this on 1.7 or earlier 
> versions of 1.8.
> 
> Thanks for your help.
> -Paul
> 
> 
> 
> global
>log /dev/log local0
>user nobody
>group nobody
>tune.ssl.default-dh-param 2048
>stats socket /var/run/haproxy.sock user nobody group nobody
>daemon
> 
> defaults
>timeout connect 5000ms
>timeout client 60ms
>timeout server 60ms
> 
>option httplog
>option forwardfor
>option http-server-close
>option contstats
> 
> frontend stats-frontend
>bind *:2999
>mode http
>log global
>stats enable
>stats uri /haproxy
> 
> backend stats-backend
>mode http
>log global
>server stats /var/run/haproxy.sock check
> 
> frontend secured
># get the list of certificate options from a list in a file
>bind *:443 ssl crt-list /srv/haproxy/certificates.lst
>mode http
>log global
> 
># tell backend connections what our ssl client cn is
>http-request set-header X-SSL-Client-Verify %[ssl_c_verify]
>http-request set-header X-SSL-Client-DN %{+Q}[ssl_c_s_dn]
>http-request set-header X-SSL-Client-CN %{+Q}[ssl_c_s_dn(cn)]
>http-request set-header X-SSL-Issuer-DN %{+Q}[ssl_c_i_dn]
>http-request set-header X-SSL-Issuer-CN %{+Q}[ssl_c_i_dn(cn)]
> 
>acl server-status path_beg /server-
>use_backend bogus-http if server-status
> 
># connection requests for apis go to the api backends
>acl request_api hdr_beg(Host) -i api.
>use_backend example-api if request_api
> 
>default_backend example-http
> 
> backend example-http
>mode http
>log global
>balance source
>hash-type consistent
>option httpchk GET /haproxy/alive.txt
>http-check disable-on-404
>server myhost myhost.example.com:8443 check ssl ca-file 
> /usr/local/ssl/certs/cacerts.cert
> 
> backend bogus-http
>mode http
>errorfile 503 /netops/www/haproxy/403.http
> 
> backend example-api
>mode http
>log global
>balance roundrobin
>option httpchk GET /haproxy/alive.txt
>http-check disable-on-404
>server myhost myhost.example.com:8445 track example-http/myhost ssl 
> ca-file /usr/local/ssl/certs/cacerts.cert
> 
> frontend localhost-api-frontend
>bind *:8445 ssl crt /usr/local/ssl/certs/example.com.pem
>mode http
>log global
>option forwardfor if-none
>option dontlog-normal
> 
># the alerts api backend
>acl alerts-api_host hdr_beg(Host) -i api.alerts
>use_backend localhost-api-backend-alerts if alerts-api_host
> 
>default_backend bogus-http
> 
> backend localhost-api-backend-alerts
>mode http
>log global
>option forwardfor if-none
>option dontlog-normal
>server localhost localhost:4002
> 
> 
> 
> 
> 
> 
> 
> And the certificates.lst file referenced above looks like this:
> 
> 
> # this order is because we need to work with older clients that don't
> # speak sni and this works for them in our setup.
> /usr/local/ssl/certs/example.com.pem *
> /usr/local/ssl/certs/example.com.pem [ca-file 
> /usr/local/ssl/certs/example-ca.cert verify optional] 

Re: Warnings when using dynamic cookies and server-template

[William Dauchy]

On Wed, Jan 17, 2018 at 05:43:02PM +0100, Olivier Houchard wrote:
> Ok you got me convinced, the attached patch don't check for duplicate
> cookies for disabled server, until we enable them.

I also prefer this approach.

> From cfc333d2b04686a3c488fdcb495cba64dbfec14b Mon Sep 17 00:00:00 2001
> From: Olivier Houchard 
> Date: Wed, 17 Jan 2018 17:39:34 +0100
> Subject: [PATCH] MINOR: servers: Don't report duplicate dyncookies for
>  disabled servers.
> 
> Especially with server-templates, it can happen servers starts with a
> placeholder IP, in the disabled state. In this case, we don't want to report
> that the same cookie was generated for multiple servers. So defer the test
> until the server is enabled.
> 
> This should be backported to 1.8.
> ---
>  src/server.c | 50 +++---
>  1 file changed, 35 insertions(+), 15 deletions(-)
> 
> diff --git a/src/server.c b/src/server.c
> index a37e91968..3901e7d8b 100644
> --- a/src/server.c
> +++ b/src/server.c
> @@ -86,10 +86,34 @@ int srv_getinter(const struct check *check)
>   return (check->fastinter)?(check->fastinter):(check->inter);
>  }
>  
> -void srv_set_dyncookie(struct server *s)
> +/*
> + * Check that we did not get a hash collision.
> + * Unlikely, but it can happen.
> + */
> +static inline void srv_check_for_dup_dyncookie(struct server *s)
>  {
>   struct proxy *p = s->proxy;
>   struct server *tmpserv;
> +
> + for (tmpserv = p->srv; tmpserv != NULL;
> + tmpserv = tmpserv->next) {
> + if (tmpserv == s)
> + continue;
> + if (tmpserv->next_admin & SRV_ADMF_FMAINT)
> + continue;
> + if (tmpserv->cookie &&
> + strcmp(tmpserv->cookie, s->cookie) == 0) {
> + ha_warning("We generated two equal cookies for two 
> different servers.\n"
> +"Please change the secret key for '%s'.\n",
> +s->proxy->id);
> + }
> + }
> +
> +}
> +
> +void srv_set_dyncookie(struct server *s)
> +{
> + struct proxy *p = s->proxy;
>   char *tmpbuf;
>   unsigned long long hash_value;
>   size_t key_len;
> @@ -136,21 +160,13 @@ void srv_set_dyncookie(struct server *s)
>   if (!s->cookie)
>   return;
>   s->cklen = 16;
> - /*
> -  * Check that we did not get a hash collision.
> -  * Unlikely, but it can happen.
> +
> + /* Don't bother checking if the dyncookie is duplicated if
> +  * the server is marked as "disabled", maybe it doesn't have
> +  * its real IP yet, but just a place holder.
>*/
> - for (tmpserv = p->srv; tmpserv != NULL;
> - tmpserv = tmpserv->next) {
> - if (tmpserv == s)
> - continue;
> - if (tmpserv->cookie &&
> - strcmp(tmpserv->cookie, s->cookie) == 0) {
> - ha_warning("We generated two equal cookies for two 
> different servers.\n"
> -"Please change the secret key for '%s'.\n",
> -s->proxy->id);
> - }
> - }
> + if (!(s->next_admin & SRV_ADMF_FMAINT))
> + srv_check_for_dup_dyncookie(s);
>  }
>  
>  /*
> @@ -4398,6 +4414,10 @@ static int cli_parse_enable_server(char **args, struct 
> appctx *appctx, void *pri
>   return 1;
>  
>   srv_adm_set_ready(sv);
> + if (!(sv->flags & SRV_F_COOKIESET)
> + && (sv->proxy->ck_opts & PR_CK_DYNAMIC) &&
> + sv->cookie)
> + srv_check_for_dup_dyncookie(sv);
>   return 1;
>  }
>  
> -- 
> 2.14.3
> 

Re: Warnings when using dynamic cookies and server-template

[Olivier Houchard]

On Wed, Jan 17, 2018 at 04:42:01PM +0100, Pierre Cheynier wrote:
> On 17/01/2018 15:56, Olivier Houchard wrote:
> >
> >> So, as a conclusion, I'm just not sure that producing this warning is
> >> relevant in case the IP is duplicated for several servers *if they are
> >> disabled*...
> > Or maybe we should just advocate using 0.0.0.0 when we mean "no IP" :)
> Not sure about that, 0.0.0.0 is not valid in the config in this case but
> it is in some others (thinking about "bind" for ex.)
> 
> Advertising it can be a bit confusing.
> 
> > It would be a bit painful, though doable, to don't check if the server is
> > disabled, but to add the check when server is enabled. I don't know if
> > it's worth it.
> >
> 
> To me this would be the best (functionally speaking, don't know about
> the performances aspects :) ), since in the context of cookies, you
> probably doing it wrong if you enable 2 servers with the same IP.
> 
> But server-templates are a good use-case in which you want to be able to
> do what you want with disabled servers.
> 
> To be discussed with people on your side ? we can clearly live with both
> options.
> 

Ok you got me convinced, the attached patch don't check for duplicate
cookies for disabled server, until we enable them.

Regards,

Olivier
>From cfc333d2b04686a3c488fdcb495cba64dbfec14b Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Wed, 17 Jan 2018 17:39:34 +0100
Subject: [PATCH] MINOR: servers: Don't report duplicate dyncookies for
 disabled servers.

Especially with server-templates, it can happen servers starts with a
placeholder IP, in the disabled state. In this case, we don't want to report
that the same cookie was generated for multiple servers. So defer the test
until the server is enabled.

This should be backported to 1.8.
---
 src/server.c | 50 +++---
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/src/server.c b/src/server.c
index a37e91968..3901e7d8b 100644
--- a/src/server.c
+++ b/src/server.c
@@ -86,10 +86,34 @@ int srv_getinter(const struct check *check)
return (check->fastinter)?(check->fastinter):(check->inter);
 }
 
-void srv_set_dyncookie(struct server *s)
+/*
+ * Check that we did not get a hash collision.
+ * Unlikely, but it can happen.
+ */
+static inline void srv_check_for_dup_dyncookie(struct server *s)
 {
struct proxy *p = s->proxy;
struct server *tmpserv;
+
+   for (tmpserv = p->srv; tmpserv != NULL;
+   tmpserv = tmpserv->next) {
+   if (tmpserv == s)
+   continue;
+   if (tmpserv->next_admin & SRV_ADMF_FMAINT)
+   continue;
+   if (tmpserv->cookie &&
+   strcmp(tmpserv->cookie, s->cookie) == 0) {
+   ha_warning("We generated two equal cookies for two 
different servers.\n"
+  "Please change the secret key for '%s'.\n",
+  s->proxy->id);
+   }
+   }
+
+}
+
+void srv_set_dyncookie(struct server *s)
+{
+   struct proxy *p = s->proxy;
char *tmpbuf;
unsigned long long hash_value;
size_t key_len;
@@ -136,21 +160,13 @@ void srv_set_dyncookie(struct server *s)
if (!s->cookie)
return;
s->cklen = 16;
-   /*
-* Check that we did not get a hash collision.
-* Unlikely, but it can happen.
+
+   /* Don't bother checking if the dyncookie is duplicated if
+* the server is marked as "disabled", maybe it doesn't have
+* its real IP yet, but just a place holder.
 */
-   for (tmpserv = p->srv; tmpserv != NULL;
-   tmpserv = tmpserv->next) {
-   if (tmpserv == s)
-   continue;
-   if (tmpserv->cookie &&
-   strcmp(tmpserv->cookie, s->cookie) == 0) {
-   ha_warning("We generated two equal cookies for two 
different servers.\n"
-  "Please change the secret key for '%s'.\n",
-  s->proxy->id);
-   }
-   }
+   if (!(s->next_admin & SRV_ADMF_FMAINT))
+   srv_check_for_dup_dyncookie(s);
 }
 
 /*
@@ -4398,6 +4414,10 @@ static int cli_parse_enable_server(char **args, struct 
appctx *appctx, void *pri
return 1;
 
srv_adm_set_ready(sv);
+   if (!(sv->flags & SRV_F_COOKIESET)
+   && (sv->proxy->ck_opts & PR_CK_DYNAMIC) &&
+   sv->cookie)
+   srv_check_for_dup_dyncookie(sv);
return 1;
 }
 
-- 
2.14.3

Re: mworker: seamless reloads broken since 1.8.1

[Pierre Cheynier]

Hi,

On 08/01/2018 14:32, Pierre Cheynier wrote:
> I retried this morning, I confirm that on 1.8.3, using
(...)
> I get RSTs (not seamless reloads) when I introduce the global/nbthread
> X, after a systemctl haproxy restart.

Any news on that ?

I saw one mworker commit ("execvp failure depending on argv[0]") but I
guess it's completely independent.

Thanks,

Pierre

Re: Warnings when using dynamic cookies and server-template

[Pierre Cheynier]

On 17/01/2018 15:56, Olivier Houchard wrote:
>
>> So, as a conclusion, I'm just not sure that producing this warning is
>> relevant in case the IP is duplicated for several servers *if they are
>> disabled*...
> Or maybe we should just advocate using 0.0.0.0 when we mean "no IP" :)
Not sure about that, 0.0.0.0 is not valid in the config in this case but
it is in some others (thinking about "bind" for ex.)

Advertising it can be a bit confusing.

> It would be a bit painful, though doable, to don't check if the server is
> disabled, but to add the check when server is enabled. I don't know if
> it's worth it.
>

To me this would be the best (functionally speaking, don't know about
the performances aspects :) ), since in the context of cookies, you
probably doing it wrong if you enable 2 servers with the same IP.

But server-templates are a good use-case in which you want to be able to
do what you want with disabled servers.

To be discussed with people on your side ? we can clearly live with both
options.

Pierre

Re: Warnings when using dynamic cookies and server-template

[Olivier Houchard]

On Wed, Jan 17, 2018 at 02:25:59PM +0100, Pierre Cheynier wrote:
> Hi,
> 
> On 16/01/2018 18:48, Olivier Houchard wrote:
> >
> > Not really :) That's not a case I thought of.
> > The attached patch disables the generation of the dynamic cookie if the IP
> > is 0.0.0.0 or ::, so that it only gets generated when the server gets a real
> > IP. Is it OK with you ?
> I'm not sure this will fix the issue.
> In this blogpost
> https://www.haproxy.com/fr/blog/dynamic-scaling-for-microservices-with-runtime-api/,
> the example given is
> 
> server-template websrv 1-100192.168.122.1:8080check disabled
> 
> Which in fact will do exactly the same as 1 hundred times
> 
> server websrvN 192.168.122.1:8080 check disabled
> 
> right ?
> (I just confirmed that BTW, by switching my 'high-level' templating to
> HAProxy's one, and I reproduce the issue).
> 
> So, as a conclusion, I'm just not sure that producing this warning is
> relevant in case the IP is duplicated for several servers *if they are
> disabled*...
> 

Or maybe we should just advocate using 0.0.0.0 when we mean "no IP" :)
It would be a bit painful, though doable, to don't check if the server is
disabled, but to add the check when server is enabled. I don't know if
it's worth it.

Regards,

Olivier

Re: Warnings when using dynamic cookies and server-template

[Pierre Cheynier]

Hi,

On 16/01/2018 18:48, Olivier Houchard wrote:
>
> Not really :) That's not a case I thought of.
> The attached patch disables the generation of the dynamic cookie if the IP
> is 0.0.0.0 or ::, so that it only gets generated when the server gets a real
> IP. Is it OK with you ?
I'm not sure this will fix the issue.
In this blogpost
https://www.haproxy.com/fr/blog/dynamic-scaling-for-microservices-with-runtime-api/,
the example given is

server-template websrv 1-100192.168.122.1:8080check disabled

Which in fact will do exactly the same as 1 hundred times

server websrvN 192.168.122.1:8080 check disabled

right ?
(I just confirmed that BTW, by switching my 'high-level' templating to
HAProxy's one, and I reproduce the issue).

So, as a conclusion, I'm just not sure that producing this warning is
relevant in case the IP is duplicated for several servers *if they are
disabled*...

Pierre

[PATCH] Minor : Add a sampler to extract the microsecond information of the hit date

[Etienne Carrière]

Hi,

I propose a patch to add a sampler that extract the microsecond part of a hit.
I had 2 ideas for implementation :
* The one in the attached patch which is a new sampler that return an
integer that is only the microsecond part of the timeval structure
* A new sampler that would return a string that would append the
second and the micro-second part (with a dot for separation)

Interested by your opinion,

Regards,

Etienne Carrière


0001-MINOR-sample-add-date_us-sample.patch
Description: Binary data

Re: segfault error 6 in haproxy=1.8-3 (pendconn_grab_from_px)

[Максим Куприянов]

Hello again!

Today I have also found another segfaults which occurred under heavy load
with nbthreads>1 on two haproxy-instances:
segfault at 0040 ip 5566f9ceb3af sp 7f98d0d569f8 error
7 in haproxy[5566f9be+169000]
and
segfault at fffe0040 ip 55bbf359d3af sp 7ffe59ed65b8 error
7 in haproxy[55bbf3492000+169000]
Both lead us to init_task:
$ /usr/bin/addr2line -e /usr/sbin/haproxy -fCi 0x10b3af
init_task
??:?

2018-01-17 13:12 GMT+03:00 Максим Куприянов :

> Hi!
>
> I have multiple instances of haproxy=1.8-3 running with nbthreads=2 and
> more. Those instances sometimes fail with an error like that in dmesg:
> haproxy[22287]: segfault at 5574915aab8a ip 55828ce3adea sp
> 7ffc105c8fb0 error 6 in haproxy[55828cd2f000+169000]
> Instances with no nbthreads-parameter set are not affected.
>
> addr2line gave a tip to the falling function:
> /usr/bin/addr2line -e /usr/sbin/haproxy -fCi 0x10bdea
> pendconn_grab_from_px
> ??:?
>
> Version of haproxy:
> haproxy -vv
> HA-Proxy version 1.8.3-1 2018/01/09
> Copyright 2000-2017 Willy Tarreau 
>
> Build options :
>   TARGET  = linux2628
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
> -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
>   OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_THREAD=1
> USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1 USE_NS=1
>
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
> Built with Lua version : Lua 5.3.1
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Encrypted password support via crypt(3): yes
> Built with multi-threading support.
> Built with PCRE version : 8.31 2012-07-06
> Running on PCRE version : 8.31 2012-07-06
> PCRE library supports JIT : no (libpcre build without JIT?)
> Built with zlib version : 1.2.8
> Running on zlib version : 1.2.8
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with network namespace support.
>
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [TRACE] trace
>
>
> --
> Best regards,
> Maksim Kupriianov
>

Re: haproxy 1.8 ssl backend server leads to server session aborts

[Bart Geesink]

Hi,

On 01/17/2018 10:16 AM, Christopher Faulet wrote:
> Le 16/01/2018 à 16:18, Lukas Tribus a écrit :
>> Hello Christopher,
>>
>>
>> On 16 January 2018 at 15:01, Bart Geesink 
>> wrote:
>>> Hi,
>>>
>>> We have an issue in haproxy > 1.8 on CentOS when using SSL in the server
>>> configuration. Haproxy sometimes logs a http status code "-1" followed
>>> by the termination_state SDxx. This happens every few requests. When
>>> using one backend, the clients don't notice it. When using multiple
>>> backends, this can result in redirecting traffic to the wrong backend
>>> (the proxy inserts a cookie to track which backend is used).
>>>
>>> Removing the SSL configuration and using plain http solves the issue, as
>>> does downgrading to version 1.7.
>>
>> Also see:
>> https://discourse.haproxy.org/t/session-state-sdnn-http-status-code-200-when-upgrading-to-1-7/1409/10
>>
>>
> 
> Hi Lukas,
> 
> Thanks, I will check these 2 issues. First of all, I need to reproduce
> them to be sure. This one seems to be a bit different because the status
> code is "-1".
> 
It also different since it occurs in both 1.8.1 and 1.8.3

> Bart, when you said your backend does not log any problems, it means
> that for a request logged with SD termination state on haproxy, you have
> a 200 on Apache side ? And what does the response look like from the
> client side ? (truncated / good / error ...)
> 
Apache logs a 200. The reponse looks fine from the client side. The only
thing that seems to be missing is the cookie inserted by the proxy for
some requests. Other requests seem not to experience this behaviour.
There is no real pattern: I can happen when a valid proxy cookie is
present, but also when a new browser session is started and a proxy
cookie is not yet present. Downgrading to 1.7 helps, as does using a
http backend without ssl.

Regards,

Bart



signature.asc
Description: OpenPGP digital signature

segfault error 6 in haproxy=1.8-3 (pendconn_grab_from_px)

[Максим Куприянов]

Hi!

I have multiple instances of haproxy=1.8-3 running with nbthreads=2 and
more. Those instances sometimes fail with an error like that in dmesg:
haproxy[22287]: segfault at 5574915aab8a ip 55828ce3adea sp
7ffc105c8fb0 error 6 in haproxy[55828cd2f000+169000]
Instances with no nbthreads-parameter set are not affected.

addr2line gave a tip to the falling function:
/usr/bin/addr2line -e /usr/sbin/haproxy -fCi 0x10bdea
pendconn_grab_from_px
??:?

Version of haproxy:
haproxy -vv
HA-Proxy version 1.8.3-1 2018/01/09
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_THREAD=1
USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1 USE_NS=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.31 2012-07-06
Running on PCRE version : 8.31 2012-07-06
PCRE library supports JIT : no (libpcre build without JIT?)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace


--
Best regards,
Maksim Kupriianov

Re: haproxy 1.8 ssl backend server leads to server session aborts

[Christopher Faulet]

Le 16/01/2018 à 16:18, Lukas Tribus a écrit :

Hello Christopher,


On 16 January 2018 at 15:01, Bart Geesink  wrote:

Hi,

We have an issue in haproxy > 1.8 on CentOS when using SSL in the server
configuration. Haproxy sometimes logs a http status code "-1" followed
by the termination_state SDxx. This happens every few requests. When
using one backend, the clients don't notice it. When using multiple
backends, this can result in redirecting traffic to the wrong backend
(the proxy inserts a cookie to track which backend is used).

Removing the SSL configuration and using plain http solves the issue, as
does downgrading to version 1.7.


Also see:
https://discourse.haproxy.org/t/session-state-sdnn-http-status-code-200-when-upgrading-to-1-7/1409/10



Hi Lukas,

Thanks, I will check these 2 issues. First of all, I need to reproduce 
them to be sure. This one seems to be a bit different because the status 
code is "-1".


Bart, when you said your backend does not log any problems, it means 
that for a request logged with SD termination state on haproxy, you have 
a 200 on Apache side ? And what does the response look like from the 
client side ? (truncated / good / error ...)


--
Christopher Faulet