Re: ratio spam/useful message
On 08 Jul 05:40, Willy Tarreau wrote: > Hi Julien, > > On Tue, Jul 06, 2021 at 11:06:05AM +0200, Julien Pivotto wrote: > > Hello, > > > > Lately, the ratio spam/useful message on the ML has been quite high. > > Well, that's not what I'm seeing in the archives here: > >https://www.mail-archive.com/haproxy@formilux.org/ > > I had to manually delete 9 messages this month and 29 last month from > my mbox, or 1 per day, I don't find it high at all, quite the opposite! Hello Willy, Yes, that is what I have too. I guess we simply don't have the same standards - to me one spam a day is 'high'. > I've added the recurrent "NFP workshops" ones and the occasional > "sock-raw.org" to the block list, but I'm not seeing that much come in. > Are you getting more from the list ? Am I the only one getting so few ? > Even checking the local archives here didn't reveal anything exceptional. Nope, it is just that I am not used to receive a spam a day on the other mailing lists I follow. > > Willy > Regards, -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
ratio spam/useful message
Hello, Lately, the ratio spam/useful message on the ML has been quite high. Could we maybe force the registration on the mailing list or set moderation for new users? Regards, -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: SNI spoofing in HAproxy?
On 24 Jun 13:29, Froehlich, Dominik wrote:
> Hi,
>
> Not sure if you would call this a security issue, hence I am asking this on
> the mailing list prior to opening a github issue:
>
> I’ve noticed that it is really easy to bypass the check on client
> certificates of a domain when the client can present a valid certificate for
> another domain.
>
> Consider this HAproxy config:
>
> global
> log /dev/log len 4096 format rfc3164 syslog info
>
> defaults
> log global
> mode http
> timeout connect 5s
> timeout client 1h
> timeout server 5s
>
> frontend myfrontend
> bind :443 ssl crt /etc/cert/server.pem crt-list /crt-list
> log-format "%ci:%cp [%tr] (%ID) %ft %b/%s %TR/%Tw/%Tc/%Tr/%Tt %ST %B %CC
> %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %sslc %sslv"
>
> capture request header Host len 256
>
> http-request set-header X-SSL-Client %[ssl_c_used]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-Session-ID %[ssl_fc_session_id,hex]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-Verify %[ssl_c_verify]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-Subject-DN %{+Q}[ssl_c_s_dn]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-Subject-CN %{+Q}[ssl_c_s_dn(cn)]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-Issuer-DN%{+Q}[ssl_c_i_dn]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-NotBefore%{+Q}[ssl_c_notbefore]
> if { ssl_c_used }
> http-request set-header X-SSL-Client-NotAfter %{+Q}[ssl_c_notafter]
> if { ssl_c_used }
>
> use_backend bob if { hdr(host) -m dom bob.com }
> use_backend alice if { hdr(host) -m dom alice.com }
Thanks for taking the time to write this report.
SNI and host header are indeed different.
You should consider using req.ssl_sni instead of hdr(host).
Regards,
>
> default_backend alice
>
> backend alice
> server alice localhost:8080 check
>
> backend bob
> server bob localhost:8081 check
>
> ---
> So this HAproxy hosts two domains alice.com and bob.com. It uses the
> following crt-list to make TLS connections:
>
> /etc/cert/server.pem [ca-file /alice.ca.pem verify required] *.alice.com
> /etc/cert/server.pem [ca-file /bob.ca.pem verify required] *.bob.com
>
> ---
> So any client connecting to alice.com must present a certificate signed by
> the Alice CA and any client connecting to bob.com must present a certificate
> signed by the Bob CA.
>
>
> However, I noticed that HAproxy does allow me to “spoof” the host header to
> bob.com even though I did a TLS handshake with alice.com. The request will be
> forwarded to bob.com with the alice.com certificate:
>
> curl -v -k --cert alice.com.crt --key alice.com.key --resolve
> www.alice.com:9443:127.0.0.1<http://www.alice.com:9443:127.0.0.1>
> https://www.alice.com:9443/headers -H "host: www.bob.com<http://www.bob.com>"
>
> * Added www.alice.com:9443:127.0.0.1 to DNS cache
> * Hostname www.alice.com was found in DNS cache
> * Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to www.alice.com (127.0.0.1) port 9443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> * CAfile: /etc/ssl/cert.pem
> CApath: none
> (…)
> > GET /headers HTTP/1.1
> > Host: www.bob.com
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < date: Thu, 24 Jun 2021 13:07:17 GMT
> < content-length: 578
> < content-type: text/plain; charset=utf-8
> <
> Hello from Bob!
>
> - Headers Received -
> Accept : [*/*]
> User-Agent : [curl/7.64.1]
> X-Ssl-Client : [1]
> X-Ssl-Client-Issuer-Dn :
> [/C=US/ST=California/L=AliceLand/O=Alice.com/CN=Alice.com Root
> CA/emailAddress=ad...@alice.com]
> X-Ssl-Client-Notafter : [220624125634Z]
> X-Ssl-Client-Notbefore : [210624125634Z]
> X-Ssl-Client-Session-Id :
> [D941ECCAACAFEBC5CB3AE17794B54DC3DFC7549C401DB20D7EC5ADC48244D3D0]
> X-Ssl-Client-Subject-Cn : [Alice]
> X-Ssl-Client-Subject-Dn :
> [/C=US/ST=Michigan/L=Detroit/O=Alice.com/CN=Alice/emailAddress=al...@alice.com]
> X-Ssl-Client-Verify : [0]
>
> ---
> So basically anyone who can get a client certificate from Alice.com can use
> it to also connect to Bob.com without getting validated against Bob’s CA.
>
> I’ve tested this with HAproxy 2.2.14.
>
> My questions:
>
> * HAproxy does seem to treat SNI (L5) and HTTP Host Header (L7) as
> unrelated. Is this true?
> * Applications offloading TLS to HAproxy usually trust
Re: Brainstorming to add JWT verify to HAPoxy (was: Re: What's the "best" way to read a file in a sample converter)
On 01 May 18:40, Aleksandar Lazic wrote:
>
> On 01.05.21 14:38, Julien Pivotto wrote:
> > I do not know what you are trying to achieve.
>
> I try to add on the first line of defense => HAProxy, the possibility to
> protect
> the backend attack without to talk outside of HAProxy.
>
> > Did you see https://github.com/criteo/haproxy-spoe-auth ?
>
>
> Well yes, thanks for shareing.
>
> There are some envirnoments where you can't use SPOE and therfore it would be
> nice
> to have the option to verify the Token before any connections goes to any
> backend or
> SPOE agent.
Did you also see the other approach
https://github.com/haproxytech/haproxy-lua-jwt then?
>
>
>
> > On 01 May 13:42, Aleksandar Lazic wrote:
> > >
> > > On 30.04.21 02:01, Aleksandar Lazic wrote:
> > > > Hi.
> > > >
> > > > I think about to integrate the "l8w8jwt_decode(...)" into HAProxy.
> > > > https://github.com/GlitchedPolygons/l8w8jwt
> > > >
> > > > The RS* methods requires some "RSA_PRIVATE_KEY[] = ..." and I'm not sure
> > > > what's the best method for a sample to read such a key in HAProxy
> > > > converters.
> > > >
> > > > My suggestion for the converter name.
> > > >
> > > > jwt_verify(alg,key) : boolean
> > > >
> > > > Example call:
> > > > http-request set-var(txn.jwt_verified)
> > > > req.hdr(Authorization),ub64dec,jwt_verify(alg,HSKEY)
> > > > http-request set-var(txn.jwt_verified)
> > > > req.hdr(Authorization),ub64dec,jwt_verify(alg,"path_to_RS_PEM")
> > > >
> > > > Any opinions?
> > >
> > > Some more examples and questions.
> > >
> > > I have such a sequence in mind.
> > > ```
> > >
> > > # check if the request have a Bearer Token
> > > # https://tools.ietf.org/html/rfc6750
> > > acl bearer_header_exist if req.hdr(Authorization) -m beg Bearer
> > >
> > > # Get the right HMAC or PEM-File into the variable jwt_verify_value
> > > http-request set-var(txn.jwt_verify_value)
> > > req.hdr(host),map_str(jwt_pem.lst),read_file_to_string if
> > > bearer_header_exist
> > >
> > > # Extract the JSON Web Algorithms (JWA) from Bearer Token.
> > > http-request set-var(txn.jwt_algo)
> > > req.hdr(Authorization),word(1,.),ub64dec,json_query('$.alg') if
> > > bearer_header_exist
> > >
> > >
> > > # Verify the JWT Token with the right HMAC and PEM
> > > http-request set-var(txn.jwt_check)
> > > req.hdr(Authorization),ub64dec,jwt_verify(%[var(txn.jwt_algo)],%[var(txn.jwt_verify_value)])
> > > \
> > >
> > > if bearer_header_exist {
> > > jwt_valid_algo(%[var(txn.jwt_algo)]) }
> > >
> > > ```
> > >
> > > jwt_valid_algo will be similar like fix_is_valid.
> > > jwt_valid_algo will check if the '$.alg' is a supported JSON Web
> > > Algorithms
> > >
> > > Do I need to call some functions in the converters
> > > (jwt_verify,jwt_valid_algo) to lookup '%[var(...)]'?
> > > I haven't found a function which do the read_file_to_string, does such a
> > > function exist in HAProxy?
> > > Can I create a $MAP or $DATA_STRUCTURE to prevent to read the file on
> > > very request?
> > > Is there a max size of a variable in HAProxy?
> > >
> > > Any feedback is very welcome.
> > >
> > > Regards
> > > Alex
> > >
> >
>
>
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
signature.asc
Description: PGP signature
Re: Brainstorming to add JWT verify to HAPoxy (was: Re: What's the "best" way to read a file in a sample converter)
I do not know what you are trying to achieve.
Did you see https://github.com/criteo/haproxy-spoe-auth ?
On 01 May 13:42, Aleksandar Lazic wrote:
>
> On 30.04.21 02:01, Aleksandar Lazic wrote:
> > Hi.
> >
> > I think about to integrate the "l8w8jwt_decode(...)" into HAProxy.
> > https://github.com/GlitchedPolygons/l8w8jwt
> >
> > The RS* methods requires some "RSA_PRIVATE_KEY[] = ..." and I'm not sure
> > what's the best method for a sample to read such a key in HAProxy
> > converters.
> >
> > My suggestion for the converter name.
> >
> > jwt_verify(alg,key) : boolean
> >
> > Example call:
> > http-request set-var(txn.jwt_verified)
> > req.hdr(Authorization),ub64dec,jwt_verify(alg,HSKEY)
> > http-request set-var(txn.jwt_verified)
> > req.hdr(Authorization),ub64dec,jwt_verify(alg,"path_to_RS_PEM")
> >
> > Any opinions?
>
> Some more examples and questions.
>
> I have such a sequence in mind.
> ```
>
> # check if the request have a Bearer Token
> # https://tools.ietf.org/html/rfc6750
> acl bearer_header_exist if req.hdr(Authorization) -m beg Bearer
>
> # Get the right HMAC or PEM-File into the variable jwt_verify_value
> http-request set-var(txn.jwt_verify_value)
> req.hdr(host),map_str(jwt_pem.lst),read_file_to_string if bearer_header_exist
>
> # Extract the JSON Web Algorithms (JWA) from Bearer Token.
> http-request set-var(txn.jwt_algo)
> req.hdr(Authorization),word(1,.),ub64dec,json_query('$.alg') if
> bearer_header_exist
>
>
> # Verify the JWT Token with the right HMAC and PEM
> http-request set-var(txn.jwt_check)
> req.hdr(Authorization),ub64dec,jwt_verify(%[var(txn.jwt_algo)],%[var(txn.jwt_verify_value)])
> \
>
> if bearer_header_exist {
> jwt_valid_algo(%[var(txn.jwt_algo)]) }
>
> ```
>
> jwt_valid_algo will be similar like fix_is_valid.
> jwt_valid_algo will check if the '$.alg' is a supported JSON Web Algorithms
>
> Do I need to call some functions in the converters
> (jwt_verify,jwt_valid_algo) to lookup '%[var(...)]'?
> I haven't found a function which do the read_file_to_string, does such a
> function exist in HAProxy?
> Can I create a $MAP or $DATA_STRUCTURE to prevent to read the file on very
> request?
> Is there a max size of a variable in HAProxy?
>
> Any feedback is very welcome.
>
> Regards
> Alex
>
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
signature.asc
Description: PGP signature
Re: [ANNOUNCE] haproxy-2.3.9
Hello, Just giving my feedback on part of the story: On 31 Mar 12:46, Willy Tarreau wrote: > On the kernel Greg solved all this by issuing all versions very > frequently: as long as you produce updates faster than users are > willing to deploy them, they can choose what to do. It just requires > a bandwidth that we don't have :-/ Some weeks several of us work full > time on backports and tests! Right now we've reached a point where > backports can prevent us from working on mainline, and where this lack > of time increases the risk of regressions, and the regressions require > more backport time. I just want to say that I greatly appreciate the backport policy of HAProxy. I often see really small bugs or even small improvements being backported, where I personally would have been happy with them just fixed on devel. This is greatly appreciated! -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HTTP/2 and compression
I have tried it and it works with HTTP/2. I have sent a patch in another thread to clarify the documentation. On 29 Mar 10:45, Julien Pivotto wrote: > > Hello there, > > I read in the HAProxy configuration: > https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-compression%20algo > > ``` > Compression is disabled when: > > * the response message is not HTTP/1.1 > ``` > > Did we forget to add HTTP/2 in the docs, or we do not support it for HTTP/2? > > > Regards, > > -- > (o-Julien Pivotto > //\Open-Source Consultant > V_/_ Inuits - https://www.inuits.eu -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Patch: DOC: clarify that compression works for HTTP/2
Dear, Please find a patch attached with a small fix for the documentation. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu From 359e386c711276c554eb8b9f07476017b6128519 Mon Sep 17 00:00:00 2001 From: Julien Pivotto Date: Mon, 29 Mar 2021 12:41:40 +0200 Subject: [PATCH] DOC: clarify that compression works for HTTP/2 This patch clarifies that compression also works with HTTP/2. I have picked the wording "HTTP/1.1 or above" because it is already used elsewhere in the documentation. I have tested that compression indeed works in HTTP/2. Signed-off-by: Julien Pivotto --- doc/configuration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 7048fb63e..7862ce34e 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -4215,7 +4215,7 @@ compression offload Compression is disabled when: * the request does not advertise a supported compression algorithm in the "Accept-Encoding" header -* the response message is not HTTP/1.1 +* the response message is not HTTP/1.1 or above * HTTP status code is not one of 200, 201, 202, or 203 * response contain neither a "Content-Length" header nor a "Transfer-Encoding" whose last value is "chunked" -- 2.28.0 signature.asc Description: PGP signature
HTTP/2 and compression
Hello there, I read in the HAProxy configuration: https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-compression%20algo ``` Compression is disabled when: * the response message is not HTTP/1.1 ``` Did we forget to add HTTP/2 in the docs, or we do not support it for HTTP/2? Regards, -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] MINOR: contrib/prometheus-exporter: export build_info
On 04 Jan 09:25, Willy Tarreau wrote:
> On Mon, Jan 04, 2021 at 08:58:05AM +0100, William Dauchy wrote:
> > On Tue, Dec 22, 2020 at 3:10 PM William Dauchy wrote:
> > > > But in addition, it only uses the field for prometheus and not
> > > > for the rest of the stats, making a special case in the stats for
> > > > prometheus, which I don't like much.
> > > > So given that the version and release dates were already present there,
> > > > why not just add a new compiler_version field, fill it with the missing
> > > > info so that the consumer has all 3 info available ?
> > >
> > > I understand your comment; however from prometheus point of view, it
> > > is not so nice:
> > > My patch was producing something like:
> > >
> > > # HELP haproxy_process_build_info HAProxy build info.
> > > # TYPE haproxy_process_build_info gauge
> > > haproxy_process_build_info{version="2.4-dev4-7a58a2-1",releasedate="2020/12/22",gccversion="10.2.1
> > > 20201207"} 1
> > >
> > > And you propose to have:
> > > haproxy_process_version{version="2.4-dev4-7a58a2-1"} 1
> > > haproxy_process_relase_date{releasedate="2020/12/22"} 1
> > > haproxy_process_compiler_version{gccversion="10.2.1 20201207"} 1
> > >
> > > I understand it creates two different ways to handle that information
> > > but from a prometheus point of view, this is not the recommended way
> > > to do those things. With our current implementation there is no easy
> > > way to gather those 3 values within a single metric.
> >
> > What do we conclude here? Christopher, any thoughts about it?
>
> Just a suggestion, couldn't we have the prometheus exporter simply build
> these elements by assembling them together ? We could possibly special-case
> a few entries (especially for the info part) but we should definitely avoid
> doing this too often, otherwise it will make it impossible to make prometheus
> users benefit from regular additions to the stats and we'll be back to the
> situation we used to be in a long time ago with the HTML stats page. Note,
> if what is needed is just to add multiple fields (e.g. an extra aggregate
> version field in the same spirit as /proc/version), that's certainly fine.
> I doubt anyone cares about the compiler version alone anyway, so we could
> have a "build_version" or whatever with the full string in the format you
> suggest.
>
> Just my two cents,
> Willy
>
Good morning,
As said before, from a Prometheus perspective the _build_info approach
is indeed more common.
I am questioning if the release date is really a useful label however.
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
signature.asc
Description: PGP signature
Wording in home page
Dear list, on http://www.haproxy.org/ : > We always support at least two active versions in parallel and an extra > old one in critical fixes mode only. The currently supported versions > are : Then, all releases to 1.5 are listed. I think we don't support 1.5 anymore :) Could someone fix the wording? Thanks! -- (o- Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Add 401, 403 retries at l7
:facepalm:
Here is the good one
On 22 Nov 15:39, Tim Düsterhus wrote:
> Julien,
>
> Am 22.11.20 um 15:24 schrieb Julien Pivotto:
> > Here you go.
> >
>
> It looks like you sent the same patch again.
>
> Best regards
> Tim Düsterhus
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
From daec1090f96ddc7c8dafce839fa847b8faee3776 Mon Sep 17 00:00:00 2001
From: Julien Pivotto
Date: Thu, 12 Nov 2020 11:14:05 +0100
Subject: [PATCH] MINOR: Add level 7 retries on http error 401, 403
Level-7 retries are only possible with a restricted number of HTTP
return codes. While it is usually not safe to retry on 401 and 403, I
came up with an authentication backend which was not synchronizing
authentication of users. While not perfect, being allowed to also retry
on those return codes is really helpful and acts as a hotfix until we
can fix the backend.
Signed-off-by: Julien Pivotto
---
doc/configuration.txt | 9 +
include/haproxy/proxy-t.h | 25 ++---
include/haproxy/proxy.h | 4
src/proxy.c | 4
4 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 2a7a9a508..234002294 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -9307,10 +9307,11 @@ retry-on [list of keywords]
rejected by the server. These requests are generally
considered to be safe to retry.
-any HTTP status code among "404" (Not Found), "408"
-(Request Timeout), "425" (Too Early), "500" (Server
-Error), "501" (Not Implemented), "502" (Bad Gateway),
-"503" (Service Unavailable), "504" (Gateway Timeout).
+any HTTP status code among "401" (Unauthorized), "403"
+(Forbidden), "404" (Not Found), "408" (Request
Timeout),
+"425" (Too Early), "500" (Server Error), "501" (Not
+Implemented), "502" (Bad Gateway), "503" (Service
+Unavailable), "504" (Gateway Timeout).
all-retryable-errors
retry request for any error that are considered
diff --git a/include/haproxy/proxy-t.h b/include/haproxy/proxy-t.h
index 41aca9d39..998e210f6 100644
--- a/include/haproxy/proxy-t.h
+++ b/include/haproxy/proxy-t.h
@@ -175,17 +175,20 @@ enum PR_SRV_STATE_FILE {
#define PR_RE_CONN_FAILED 0x0001 /* Retry if we failed to connect
*/
#define PR_RE_DISCONNECTED0x0002 /* Retry if we got disconnected
with no answer */
#define PR_RE_TIMEOUT 0x0004 /* Retry if we got a server
timeout before we got any data */
-#define PR_RE_404 0x0008 /* Retry if we got a 404 */
-#define PR_RE_408 0x0010 /* Retry if we got a 408 */
-#define PR_RE_425 0x0020 /* Retry if we got a 425 */
-#define PR_RE_500 0x0040 /* Retry if we got a 500 */
-#define PR_RE_501 0x0080 /* Retry if we got a 501 */
-#define PR_RE_502 0x0100 /* Retry if we got a 502 */
-#define PR_RE_503 0x0200 /* Retry if we got a 503 */
-#define PR_RE_504 0x0400 /* Retry if we got a 504 */
-#define PR_RE_STATUS_MASK (PR_RE_404 | PR_RE_408 | PR_RE_425 | \
- PR_RE_425 | PR_RE_500 | PR_RE_501 | \
- PR_RE_502 | PR_RE_503 | PR_RE_504)
+#define PR_RE_401 0x0008 /* Retry if we got a 401 */
+#define PR_RE_403 0x0010 /* Retry if we got a 403 */
+#define PR_RE_404 0x0020 /* Retry if we got a 404 */
+#define PR_RE_408 0x0040 /* Retry if we got a 408 */
+#define PR_RE_425 0x0080 /* Retry if we got a 425 */
+#define PR_RE_500 0x0100 /* Retry if we got a 500 */
+#define PR_RE_501 0x0200 /* Retry if we got a 501 */
+#define PR_RE_502 0x0400 /* Retry if we got a 502 */
+#define PR_RE_503 0x0800 /* Retry if we got a 503 */
+#define PR_RE_504 0x1000 /* Retry if we got a 504 */
+#define PR_RE_STATUS_MASK (PR_RE_401 | PR_RE_403 | PR_RE_404 | \
+ PR_RE_408 | PR_RE_425 | PR_RE_500 | \
+ PR_RE_501 | PR_RE_502 | PR_RE_503 | \
+ PR_RE_504)
/* 0x0800, 0x1000, 0x2000, 0x4000 and 0x8000 unused,
* reserved for eventual future status codes
*/
diff --git a/include/haproxy/proxy.h b/include/hap
Re: Add 401, 403 retries at l7
Here you go.
On 20 Nov 12:51, Christopher Faulet wrote:
> Le 12/11/2020 à 11:18, Julien Pivotto a écrit :
> > Dear,
> >
> > Please find a patch to add 401 and 403 l7 retries, see
> > https://github.com/haproxy/haproxy/issues/948
> >
>
> Thanks Julien. Sorry for the delay.
>
> Sure we can add it. However could you adapt your commit message to follow
> CONTRIBUTING advises (section 11) ?
>
> --
> Christopher Faulet
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
From f71e0b2eb69303fa59645fefda3960fb2a9eb7fb Mon Sep 17 00:00:00 2001
From: Julien Pivotto
Date: Thu, 12 Nov 2020 11:14:05 +0100
Subject: [PATCH] Add level 7 retries on http error 401, 403
Signed-off-by: Julien Pivotto
---
doc/configuration.txt | 9 +
include/haproxy/proxy-t.h | 25 ++---
include/haproxy/proxy.h | 4
src/proxy.c | 4
4 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 2a7a9a508..234002294 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -9307,10 +9307,11 @@ retry-on [list of keywords]
rejected by the server. These requests are generally
considered to be safe to retry.
-any HTTP status code among "404" (Not Found), "408"
-(Request Timeout), "425" (Too Early), "500" (Server
-Error), "501" (Not Implemented), "502" (Bad Gateway),
-"503" (Service Unavailable), "504" (Gateway Timeout).
+any HTTP status code among "401" (Unauthorized), "403"
+(Forbidden), "404" (Not Found), "408" (Request
Timeout),
+"425" (Too Early), "500" (Server Error), "501" (Not
+Implemented), "502" (Bad Gateway), "503" (Service
+Unavailable), "504" (Gateway Timeout).
all-retryable-errors
retry request for any error that are considered
diff --git a/include/haproxy/proxy-t.h b/include/haproxy/proxy-t.h
index 41aca9d39..998e210f6 100644
--- a/include/haproxy/proxy-t.h
+++ b/include/haproxy/proxy-t.h
@@ -175,17 +175,20 @@ enum PR_SRV_STATE_FILE {
#define PR_RE_CONN_FAILED 0x0001 /* Retry if we failed to connect
*/
#define PR_RE_DISCONNECTED0x0002 /* Retry if we got disconnected
with no answer */
#define PR_RE_TIMEOUT 0x0004 /* Retry if we got a server
timeout before we got any data */
-#define PR_RE_404 0x0008 /* Retry if we got a 404 */
-#define PR_RE_408 0x0010 /* Retry if we got a 408 */
-#define PR_RE_425 0x0020 /* Retry if we got a 425 */
-#define PR_RE_500 0x0040 /* Retry if we got a 500 */
-#define PR_RE_501 0x0080 /* Retry if we got a 501 */
-#define PR_RE_502 0x0100 /* Retry if we got a 502 */
-#define PR_RE_503 0x0200 /* Retry if we got a 503 */
-#define PR_RE_504 0x0400 /* Retry if we got a 504 */
-#define PR_RE_STATUS_MASK (PR_RE_404 | PR_RE_408 | PR_RE_425 | \
- PR_RE_425 | PR_RE_500 | PR_RE_501 | \
- PR_RE_502 | PR_RE_503 | PR_RE_504)
+#define PR_RE_401 0x0008 /* Retry if we got a 401 */
+#define PR_RE_403 0x0010 /* Retry if we got a 403 */
+#define PR_RE_404 0x0020 /* Retry if we got a 404 */
+#define PR_RE_408 0x0040 /* Retry if we got a 408 */
+#define PR_RE_425 0x0080 /* Retry if we got a 425 */
+#define PR_RE_500 0x0100 /* Retry if we got a 500 */
+#define PR_RE_501 0x0200 /* Retry if we got a 501 */
+#define PR_RE_502 0x0400 /* Retry if we got a 502 */
+#define PR_RE_503 0x0800 /* Retry if we got a 503 */
+#define PR_RE_504 0x1000 /* Retry if we got a 504 */
+#define PR_RE_STATUS_MASK (PR_RE_401 | PR_RE_403 | PR_RE_404 | \
+ PR_RE_408 | PR_RE_425 | PR_RE_500 | \
+ PR_RE_501 | PR_RE_502 | PR_RE_503 | \
+ PR_RE_504)
/* 0x0800, 0x1000, 0x2000, 0x4000 and 0x8000 unused,
* reserved for eventual future status codes
*/
diff --git a/include/haproxy/proxy.h b/include/haproxy/proxy.h
index fe253bf7f..f63f4a2cd 100644
--- a/include/haproxy/proxy.h
+++ b/include/haproxy/proxy.h
@@ -154,6 +154,10 @@ static inline int l7_status_match(str
Re: [2.2.5] High cpu usage after switch to threads
; > > > server slot_0_checker 10.x.x.x:31180 check weight 54 > > server slot_1_checker 10.x.x.x:31146 check weight 33 > > server slot_2_checker 10.x.x.x:31313 check weight 55 > > server slot_3_checker 10.x.x.x:31281 check weight 33 disabled > > server slot_4_checker 10.x.x.x:31717 check weight 55 > > server slot_5_checker 10.x.x.x:31031 check weight 76 > > server slot_6_checker 10.x.x.x:31124 check weight 50 > > server slot_7_checker 10.x.x.x:31353 check weight 48 > > server slot_8_checker 10.x.x.x:31839 check weight 33 > > server slot_9_checker 10.x.x.x:31854 check weight 44 > > server slot_10_checker 10.x.x.x:31794 check weight 60 disabled > > server slot_11_checker 10.x.x.x:31561 check weight 56 > > server slot_12_checker 10.x.x.x:31814 check weight 57 > > server slot_13_checker 10.x.x.x:31535 check weight 44 disabled > > server slot_14_checker 10.x.x.x:31829 check weight 43 disabled > > server slot_15_checker 10.x.x.x:31655 check weight 40 disabled > > -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Add 401, 403 retries at l7
On 13 Nov 00:12, Jonathan Matthews wrote: > On Thu, 12 Nov 2020 at 12:21, Julien Pivotto wrote: > > > Dear, > > > > Please find a patch to add 401 and 403 l7 retries, see > > https://github.com/haproxy/haproxy/issues/948 > > > Hey Julien, > > This really feels like an anti-feature, to be frank! > > If a specific backend server can’t auth anyone, don’t have it in the pool > of servers which process auth requests. > > If it can’t auth anyone, only some of the time, take it out of the auth > pool based on health checks. > > If it can’t auth *some* people, *some* of the time, while other servers can: > > A) fix your broken server; don’t enlarge a nice piece of middleware like > haproxy! > B) you probably want a redispatch, not a retry; I *think* a retry can end > up on the same server, which isn’t want you want. I might be wrong there, > though. You can't redispatch without retry. > I think retry on 4XX, without modifying the request, is a terrible idea. > It’s pretty much the opposite of what the HTTP spec says, and isn’t > something haproxy should learn how to do :-) > > I know it already knows how to do it on 404 (& 408) which I can see a > /slight/ rationale for, in a bulk-file-hosting, > round-robin-until-a-server-has-a-file situation. That’s still, IMHO, the > wrong place for this to be implemented - it should be in-app, not in-proxy. > I genuinely don’t think we should expand the set of 4XX responses that can > be automatically retried! > > J It is not the first time I hit arbitrary code selection limitation by HAProxy. I think that it should be up to the user/admin to decide what they can do, and that HAProxy should empower them to do so. I am not willing to expose all the details why I exactly need this. I am not up for a long debate about the patch however. It is open source software, I will carry the patch in my setup as long as I need it. If the broader community does not want the patch, so be it. Thanks. > > > <https://github.com/haproxy/haproxy/issues/948> > > -- > Jonathan Matthews > https://jpluscplusm.com -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Add 401, 403 retries at l7
Dear,
Please find a patch to add 401 and 403 l7 retries, see
https://github.com/haproxy/haproxy/issues/948
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
From f71e0b2eb69303fa59645fefda3960fb2a9eb7fb Mon Sep 17 00:00:00 2001
From: Julien Pivotto
Date: Thu, 12 Nov 2020 11:14:05 +0100
Subject: [PATCH] Add level 7 retries on http error 401, 403
Signed-off-by: Julien Pivotto
---
doc/configuration.txt | 9 +
include/haproxy/proxy-t.h | 25 ++---
include/haproxy/proxy.h | 4
src/proxy.c | 4
4 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 2a7a9a508..234002294 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -9307,10 +9307,11 @@ retry-on [list of keywords]
rejected by the server. These requests are generally
considered to be safe to retry.
-any HTTP status code among "404" (Not Found), "408"
-(Request Timeout), "425" (Too Early), "500" (Server
-Error), "501" (Not Implemented), "502" (Bad Gateway),
-"503" (Service Unavailable), "504" (Gateway Timeout).
+any HTTP status code among "401" (Unauthorized), "403"
+(Forbidden), "404" (Not Found), "408" (Request
Timeout),
+"425" (Too Early), "500" (Server Error), "501" (Not
+Implemented), "502" (Bad Gateway), "503" (Service
+Unavailable), "504" (Gateway Timeout).
all-retryable-errors
retry request for any error that are considered
diff --git a/include/haproxy/proxy-t.h b/include/haproxy/proxy-t.h
index 41aca9d39..998e210f6 100644
--- a/include/haproxy/proxy-t.h
+++ b/include/haproxy/proxy-t.h
@@ -175,17 +175,20 @@ enum PR_SRV_STATE_FILE {
#define PR_RE_CONN_FAILED 0x0001 /* Retry if we failed to connect
*/
#define PR_RE_DISCONNECTED0x0002 /* Retry if we got disconnected
with no answer */
#define PR_RE_TIMEOUT 0x0004 /* Retry if we got a server
timeout before we got any data */
-#define PR_RE_404 0x0008 /* Retry if we got a 404 */
-#define PR_RE_408 0x0010 /* Retry if we got a 408 */
-#define PR_RE_425 0x0020 /* Retry if we got a 425 */
-#define PR_RE_500 0x0040 /* Retry if we got a 500 */
-#define PR_RE_501 0x0080 /* Retry if we got a 501 */
-#define PR_RE_502 0x0100 /* Retry if we got a 502 */
-#define PR_RE_503 0x0200 /* Retry if we got a 503 */
-#define PR_RE_504 0x0400 /* Retry if we got a 504 */
-#define PR_RE_STATUS_MASK (PR_RE_404 | PR_RE_408 | PR_RE_425 | \
- PR_RE_425 | PR_RE_500 | PR_RE_501 | \
- PR_RE_502 | PR_RE_503 | PR_RE_504)
+#define PR_RE_401 0x0008 /* Retry if we got a 401 */
+#define PR_RE_403 0x0010 /* Retry if we got a 403 */
+#define PR_RE_404 0x0020 /* Retry if we got a 404 */
+#define PR_RE_408 0x0040 /* Retry if we got a 408 */
+#define PR_RE_425 0x0080 /* Retry if we got a 425 */
+#define PR_RE_500 0x0100 /* Retry if we got a 500 */
+#define PR_RE_501 0x0200 /* Retry if we got a 501 */
+#define PR_RE_502 0x0400 /* Retry if we got a 502 */
+#define PR_RE_503 0x0800 /* Retry if we got a 503 */
+#define PR_RE_504 0x1000 /* Retry if we got a 504 */
+#define PR_RE_STATUS_MASK (PR_RE_401 | PR_RE_403 | PR_RE_404 | \
+ PR_RE_408 | PR_RE_425 | PR_RE_500 | \
+ PR_RE_501 | PR_RE_502 | PR_RE_503 | \
+ PR_RE_504)
/* 0x0800, 0x1000, 0x2000, 0x4000 and 0x8000 unused,
* reserved for eventual future status codes
*/
diff --git a/include/haproxy/proxy.h b/include/haproxy/proxy.h
index fe253bf7f..f63f4a2cd 100644
--- a/include/haproxy/proxy.h
+++ b/include/haproxy/proxy.h
@@ -154,6 +154,10 @@ static inline int l7_status_match(struct proxy *p, int
status)
return 0;
switch (status) {
+ case 401:
+ return (p->retry_type & PR_RE_401);
+ case 403:
+ return (p->retry_type & PR_RE_403);
case 404:
return (p->retry_type & PR_RE_404);
case 408:
diff --git a/src/proxy.c b/src/proxy.c
Re: Can I help with the 2.1 release?
On 30 Jul 21:29, Lukas Tribus wrote: > Hello, > > On Thu, 30 Jul 2020 at 20:49, Valter Jansons wrote: > > > > On Thu, Jul 30, 2020 at 6:44 PM Harris Kaufmann > > wrote: > > > my company really needs the next 2.1 release but we want to avoid > > > deploying a custom, self compiled version. > > > > > > Is there something I can do to help with the release? I guess there > > > are no blocking issues left? > > > > For mission-critical setups you should be running the LTS release > > lines. The 2.1 release line was more of a technical preview line for > > the following 2.2 LTS release, to keep changes flowing, and you should > > not expect regular new release tags on the 2.1 line considering the > > 2.2 line has shipped. I am not involved in the release process but I > > would assume the team will push a new 2.1 tag some day however I do > > not see that being a high priority for them in any way. > > > > As a result, I would instead rephrase the question in the other > > direction: Are there any blockers for you to upgrade to 2.2? > > I'm not sure I agree. > > I would be reluctant to suggest upgrading mission-critical setups to > 2.2, it's not even a month old at this point. Unless you expect to run > into bugs and have time and resources to troubleshoot it. > > 2.1 is not a technical preview, it's a proper release train with full > support. Support for it will cease in 2021-Q1, but I don't think you > can conclude that that means it's getting less love now. > > > Lukas > I'm with Lukas on this. 2.1 is a strong release, and we should be grateful for everyone which is using that release, as their feedback is valuable for the building the next releases of HAProxy. I am not yet confident to run 2.2 in prod yet, but I will roll out 2.2 in non-prod env soon. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PR] DOC: Update docs / comments to be inclusive of all gender identities
On 23 Jul 02:23, PR Bot wrote: > Dear list! > > Author: Jackie Tapia > Number of patches: 2 > > This is an automated relay of the Github pull request: >DOC: Update docs / comments to be inclusive of all gender identities > > Patch title(s): >Update docs / comments to be more inclusive of all gender identities >Update contributing doc > > Link: >https://github.com/haproxy/haproxy/pull/772 > > Edit locally: >wget https://github.com/haproxy/haproxy/pull/772.patch && vi 772.patch > > Apply locally: >curl https://github.com/haproxy/haproxy/pull/772.patch | git am - > > Description: >To promote an inclusive environment for all communities, this PR >converts all references of gender specific pronouns, e.g "he" or >"she", into the third-person pronoun "they" as it is inclusive of all >people. Furthermore, documentation / comments should use singular >"they" when referring to a generic person whose gender is unknown or >irrelevant to the context. > >Also, remove some trailing >whitespaces from the files modified. > > 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. > +1 -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HAproxy 2.X RPM
On 27 May 12:27, Loïc Chanel wrote: > Hello, > > Do any of you guys know where I could find RPM files for 2.0 or 2.1 version > ? > I am looking for a public repository offering an automated build of HAproxy > 2.X, but all I could find until now was this repo : > http://au1.mirror.crc.id.au/repo/el7-extra/x86_64/ and I don't know if the > owner plans on keeping it up-to-date with latest versions of HAproxy. I > thought that > > Thanks for your help, I maintain https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/ on a best effort basis. > > > Loïc CHANEL > System Big Data engineer > Vision 360 Degrés - SoftAtHome (Lyon, France) -- Julien Pivotto @roidelapluie
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
On 27 May 12:40, William Lallemand wrote: > Hello List, > > Since HAProxy 1.8, the minimum default TLS version for bind lines is > TLSv10. I was thinking to increase this minimum default to TLSv11 before > the 2.2 release. But when we discussed the other day about the DH > param set to 2048 by default, I read that RHEL 8 was also disabling > TLSv11 by default. TLSv12 now exists for 12 years, it is widely-spread > nowadays. > > So in my opinion we should do the same, and set the minimum version to > TLSv12 by default on bind lines. It's still configurable with > min-ssl-ver if you want the support for prior TLS versions. > > Does anybody have any objections? That would be really good. > > -- > William Lallemand > -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [ANNOUNCE] haproxy-2.1.4
On 02 Apr 15:27, Julien Pivotto wrote: > On 02 Apr 15:03, Willy Tarreau wrote: > > Hi, > > > > HAProxy 2.1.4 was released on 2020/04/02. It added 99 new commits > > after version 2.1.3. > > > > The main driver for this release is that it contains a fix for a serious > > vulnerability that was responsibly reported last week by Felix Wilhelm > > from Google Project Zero, affecting the HPACK decoder used for HTTP/2. > > CVE-2020-11100 was assigned to this issue. > > > > There is no configuration-based workaround for 2.1 and above. > > > Is disabling HTTP2 a workaround? > > Thanks. Sorry, I have only read the 2.1 mail. Thanks > > > > > This vulnerability makes it possible under certain circumstances to write > > to a wide range of memory locations within the process' heap, with the > > limitation that the attacker doesn't control the absolute address, so the > > most likely result and by a far margin will be a process crash, but it is > > not possible to completely rule out the faint possibility of a remote code > > execution, at least in a lab-controlled environment. Felix was kind enough > > to agree to delay the publication of his findings to the 20th of this month > > in order to leave enough time to haproxy users to apply updates. But please > > do not wait, as it is not very difficult to figure how to exploit the bug > > based on the fix. Distros were notified and will also have fixes available > > very shortly. > > > > Three other important fixes are present in this version: > > - a non-portable way of calculating a list pointer that breaks with > > gcc 10 unless using -fno-tree-pta. This bug results in infinite loops > > at random places in the code depending how the compiler decides to > > optimize the code. > > > > - a bug in the way TLV fields are extracted from the PROXY protocol, as > > they could be mistakenly looked up in the subsequent payload, even > > though these would have limited effects since these ones would generally > > be meaningless for the transported protocol, but could be used to hide a > > source address from logging for example. > > > > - the "tarpit" rules were partially broken in that since 1.9 they wouldn't > > prevent a connection from being sent to a server while the 500 response > > is delivered to the client. Given that they are often used to block > > suspicious activity it's problematic. > > > > The rest is less important, but still relevant to some users. Among those > > noticeable I can enumerate: > > - the O(N^2) ACL unique-id allocator that could take several minutes to > > boot on certain very large configs was reworked to follow O(NlogN) > > instead. > > > > - the default global maxconn setting when not set in the configuration was > > incorrectly set to the process' soft limit instead of the hard limit, > > resulting in much lower connection counts on some setups after upgrade > > from 1.x to 2.x. It now properly follows the hard limit. > > > > - a new thread-safe random number generator that will avoid the risk that > > the "uuid" sample fetch function returns the exact same UUID in several > > threads. > > > > - issues in HTX mode affecting filters, namely cache and compression, that > > could lead to data corruption. > > > > - alignment issues causing bus error on Sparc64 were addressed > > > > - fixed a rare case of possible segfault on soft-stop when a finishing > > thread > > flushes its pools while another one is freeing some elements. > > > > > > Please have a look at the changelog below for a more detailed list of fixes, > > and do not forget to update, either from the sources or from your regular > > distro channels. > > > > Please find the usual URLs below : > >Site index : http://www.haproxy.org/ > >Discourse: http://discourse.haproxy.org/ > >Slack channel: https://slack.haproxy.org/ > >Issue tracker: https://github.com/haproxy/haproxy/issues > >Sources : http://www.haproxy.org/download/2.1/src/ > >Git repository : http://git.haproxy.org/git/haproxy-2.1.git/ > >Git Web browsing : http://git.haproxy.org/?p=haproxy-2.1.git > >Changelog: http://www.haproxy.org/download/2.1/src/CHANGELOG > >Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ > > > > Willy > > --- > > Complete changelog : > > Balvinder Singh Rawat (
Re: [ANNOUNCE] haproxy-2.1.4
config.h and > complete them > BUG/MEDIUM: ebtree: don't set attribute packed without unaligned access > support > BUILD: fix recent build failure on unaligned archs > BUG/MINOR: sample: fix the json converter's endian-sensitivity > BUG/MEDIUM: ssl: fix several bad pointer aliases in a few sample fetch > functions > BUG/MINOR: connection: make sure to correctly tag local PROXY > connections > MINOR: compiler: add new alignment macros > BUILD: ebtree: improve architecture-specific alignment > BUG/MINOR: h2: reject again empty :path pseudo-headers > BUG/MEDIUM: random: initialize the random pool a bit better > MINOR: tools: add 64-bit rotate operators > BUG/MEDIUM: random: implement a thread-safe and process-safe PRNG > MINOR: backend: use a single call to ha_random32() for the random LB > algo > BUG/MINOR: checks/threads: use ha_random() and not rand() > BUG/MAJOR: list: fix invalid element address calculation > MINOR: debug: report the task handler's pointer relative to main > BUG/MEDIUM: debug: make the debug_handler check for the thread in > threads_to_dump > MINOR: haproxy: export main to ease access from debugger > BUILD: tools: remove obsolete and conflicting trace() from standard.c > BUG/MINOR: wdt: do not return an error when the watchdog couldn't be > enabled > DOC: fix incorrect indentation of http_auth_* > BUG/MINOR: init: make the automatic maxconn consider the max of > soft/hard limits > REGTEST: make the PROXY TLV validation depend on version 2.2 > BUILD: wdt: only test for SI_TKILL when compiled with thread support > BUG/MEDIUM: random: align the state on 2*64 bits for ARM64 > BUG/MINOR: haproxy: always initialize sleeping_thread_mask > BUG/MINOR: listener/mq: do not dispatch connections to remote threads > when stopping > BUG/MINOR: haproxy/threads: try to make all threads leave together > BUILD: makefile: fix regex syntax in ARM platform detection > BUILD: makefile: fix expression again to detect ARM platform > REGTESTS: use "command -v" instead of "which" > REGTEST: increase timeouts on the seamless-reload test > BUG/MINOR: haproxy/threads: close a possible race in soft-stop detection > BUILD: ssl: only pass unsigned chars to isspace() > BUG/CRITICAL: hpack: never index a header into the headroom after > wrapping > > --- > -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
On 31 Mar 17:14, Willy Tarreau wrote: > On Tue, Mar 24, 2020 at 04:46:43PM +0100, Tim Düsterhus wrote: > > > Could you please cut a release ? there are many fixes that just cherry > > > picking it in my fork would make sense. > > > > I second that. I was already thinking about asking after yesterday's > > 2.2-dev5. > > I'm aiming at Thursday. Still working on the backports. I know sometimes > we're lagging behind a lot, but when you consider that backports can take > up to 50% of the work time, and more importantly that many times it can > divert you by 3 hours for something that was expected to take 10 seconds, > it's easy to understand why they're often handled in batches :-/ > > Willy No worries. The goal is not to put pressure on the maintainers, also I did not insist after my first mail. Take your time, thanks! -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
Dear list, We are facing some of the bugs fixed in the 2.1 branch (in particular the replace-path bug). Could you please cut a release ? there are many fixes that just cherry picking it in my fork would make sense. Thanks :) Note: the bot says that the ideal date was 2020-03-06 :) On 18 Mar 00:00, stable-...@haproxy.com wrote: > Hi, > > This is a friendly bot that watches fixes pending for the next haproxy-stable > release! One such e-mail is sent periodically once patches are waiting in > the last maintenance branch, and an ideal release date is computed based on > the severity of these fixes and their merge date. Responses to this mail > must be sent to the mailing list. > > > Last release 2.1.3 was issued on 2020-02-12. There are currently 21 patches > in the queue cut down this way: > - 2 MAJOR, first one merged on 2020-02-21 > - 6 MEDIUM, first one merged on 2020-02-21 > - 13 MINOR, first one merged on 2020-02-21 > > Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which was > one week ago. > > Last release 2.0.13 was issued on 2020-02-13. There are currently 16 patches > in the queue cut down this way: > - 1 MAJOR, first one merged on 2020-02-21 > - 6 MEDIUM, first one merged on 2020-02-21 > - 9 MINOR, first one merged on 2020-02-21 > > Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which > was one week ago. > > The current list of patches in the queue is: > - 2.1 - MAJOR : list: fix invalid element address > calculation > - 2.0, 2.1 - MAJOR : http-ana: Always abort the request > when a tarpit is triggered > - 2.0, 2.1 - MEDIUM : shctx: make sure to keep all blocks > aligned > - 2.0, 2.1 - MEDIUM : muxes: Use the right argument when > calling the destroy method. > - 2.0, 2.1 - MEDIUM : ebtree: don't set attribute packed > without unaligned access support > - 2.0, 2.1 - MEDIUM : random: implement a thread-safe and > process-safe PRNG > - 2.0, 2.1 - MEDIUM : random: initialize the random pool a > bit better > - 2.0, 2.1 - MEDIUM : ssl: fix several bad pointer aliases > in a few sample fetch functions > - 2.0, 2.1 - MINOR : connection: make sure to correctly > tag local PROXY connections > - 2.1 - MINOR : http-htx: Don't return error if > authority is updated without changes > - 2.0, 2.1 - MINOR : checks/threads: use ha_random() and > not rand() > - 2.0, 2.1 - MINOR : sample: Make sure to return stable > IDs in the unique-id fetch > - 2.1 - MINOR : mux-fcgi: Forbid special characters > when matching PATH_INFO param > - 2.0, 2.1 - MINOR : dns: ignore trailing dot > - 2.0, 2.1 - MINOR : filters: Count HTTP headers as > filtered data but don't forward them > - 2.0, 2.1 - MINOR : http-ana: Matching on monitor-uri > should be case-sensitive > - 2.1 - MINOR : http-htx: Do case-insensive > comparisons on Host header name > - 2.0, 2.1 - MINOR : namespace: avoid closing fd when > socket failed in my_socketat > - 2.1 - MINOR : h2: reject again empty :path > pseudo-headers > - 2.0, 2.1 - MINOR : sample: fix the json converter's > endian-sensitivity > - 2.0, 2.1 - MINOR : http: http-request replace-path > duplicates the query string > > -- > The haproxy stable-bot is freely provided by HAProxy Technologies to help > improve the quality of each HAProxy release. If you have any issue with > these emails or if you want to suggest some improvements, please post them on > the list so that the solutions suiting the most users can be found. > -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
On 12 Feb 18:47, Daniel Corbett wrote: > Hello, > > > On 2/12/20 12:55 PM, Tim Düsterhus wrote: > > > > Threading would solve most of the pain points for me, because the emails > > will nicely be merged on both my computer and my phone. For the > > remaining points I don't really care that much. I'll leave this up to > > the people that actually read the emails. I'm currently just marking > > them as read without taking a single look :-) Most of by curiosity is > > satisfied using git and the bug list on haproxy.org. > > > I just wanted to acknowledge this thread and let you know that I appreciate > the suggestions. > > I'll do what I can to improve it starting with working on moving these items > to a thread and increasing the calculations for expected release dates for > older branches. > > I'll also take your other suggestions into account as well but I think these > might be a good starting point. > > I may be a little slow on this but I'll put something together that can > hopefully make the bot more useful. > > > Thanks again, > > -- Daniel Hi Daniel, I want to tell another story. I find the bot useful and appreciate it. We get more real spam on the mailing list than emails from the bot, and it gives a good reminder about what's coming next and what are the bugs. In the current status of HAProxy development, where lots of things only happen on the mailing list, and branches are not all mirrored on github, this is really welcome. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH v2] BUG/MINOR: connection: fix ip6 dst_port copy in make_proxy_line_v2
On 26 Jan 18:46, William Dauchy wrote: > On Sun, Jan 26, 2020 at 7:33 PM Tim Düsterhus wrote: > > Backport information are missing (without looking up that commit). 1.8+ > > it is. > > Thanks. Could be nice to change a bit these rules; indeed, when the > `Fixes` tag is present, it's very easy to ask git in which tag this > was introduced; so in my opinion this should be part of a > semi-automatic process proposing to backport a given fix when this tag > is present (`git tag --contains`). That will not work with cherry-picked commits. > However, I agree that's a bit wonky as a few commits are > cherry-picked, like this one which was cherry-picked in v1.8 indeed. > -- > William -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Found a security issue
On 15 Jan 21:07, Willy Tarreau wrote: > Hi Julien, > > even a security.txt file: https://securitytxt.org/ > > Thanks for this link. I never heard about this one. Did you hear about > anyone using it yet ? https://www.facebook.com/security.txt https://www.google.com/.well-known/security.txt > > Willy -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Found a security issue
On 15 Jan 20:51, Willy Tarreau wrote: > On Wed, Jan 15, 2020 at 10:06:12PM +0800, ZeddYu Lu wrote: > > Hi. I found a security issue about the latest haproxy. How can I > > report this? > > Just a quick update on this one, I got it and it was just a false alarm. > > Willy > we could improve http://www.haproxy.org/ and add such a contact, maybe even a security.txt file: https://securitytxt.org/ -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] MINOR: http: Add 410 to http-request deny
On 09 Jan 06:01, Willy Tarreau wrote: > On Wed, Jan 08, 2020 at 01:26:00PM +0100, Julien Pivotto wrote: > > While we are at it, could we add 404 as well? > > > > 404 is frequently used to deny to hide the fact that the access is > > denied, see > > https://developer.github.com/v3/troubleshooting/#why-am-i-getting-a-404-error-on-a-repository-that-exists > > > > I know there are workarounds for this like service an error file but > > getting it out of the box would be nice. > > Agreed, I remember someone proposing it a year or two ago already and it > does make sense. Feel free to propose a patch, Florian's can serve as an > example. > > Willy Florian was very kind and implemented it. Thank you Florian! -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] MINOR: http: Add 410 to http-request deny
[HTTP_ERR_429] = 429,[0m
> [37m@@ -273,6 +274,15 @@ const char *http_err_msgs[HTTP_ERR_SIZE] = {[0m
> [37m "\r\n"[0m
> [37m "408 Request Time-out\nYour browser didn't
> send a complete request in time.\n\n",[0m
> [37m [0m
> [32m+[HTTP_ERR_410] =[0m
> [32m+"HTTP/1.1 410 Gone\r\n"[0m
> [32m+"Content-length: 44\r\n"[0m
> [32m+"Cache-Control: no-cache\r\n"[0m
> [32m+"Connection: close\r\n"[0m
> [32m+"Content-Type: text/html\r\n"[0m
> [32m+"\r\n"[0m
> [32m+"410 Gone\n",[0m
> [32m+[0m
> [37m [HTTP_ERR_421] =[0m
> [37m "HTTP/1.1 421 Misdirected Request\r\n"[0m
> [37m "Content-length: 104\r\n"[0m
> [37m@@ -379,6 +389,7 @@ int http_get_status_idx(unsigned int status)[0m
> [37m case 403: return HTTP_ERR_403;[0m
> [37m case 405: return HTTP_ERR_405;[0m
> [37m case 408: return HTTP_ERR_408;[0m
> [32m+case 410: return HTTP_ERR_410;[0m
> [37m case 421: return HTTP_ERR_421;[0m
> [37m case 425: return HTTP_ERR_425;[0m
> [37m case 429: return HTTP_ERR_429;[0m
> [31m-- [0m
> 2.24.1
>
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
signature.asc
Description: PGP signature
Re: [ANNOUNCE] haproxy-2.1.2
Thank you to all the team for the work on the FD layer and my best wishes! However to avoid phone calls I have set nbthread to 1 before leaving ;) - Original Message - From: Willy Tarreau To: haproxy@formilux.org Sent: Sat, 21 Dec 2019 12:44:05 +0100 (CET) Subject: [ANNOUNCE] haproxy-2.1.2 Hi, HAProxy 2.1.2 was released on 2019/12/21. It added 18 new commits after version 2.1.1. It fixes a last bunch of stability bugs that are not new but are better fixed quickly. One of them may cause a crash when mixing HTTP and TCP on a TCP frontend if a second request of an upgraded connection is sent to a TCP backend. One is a tight corner case in the scheduler and can only impact slow HTTP checks running on servers configured with fastinter and observe-l7 in multi-thread configs. The effect is that it can corrupt the timer's queue resulting in the watchdog killing the process. One in the FD layer could impact the DNS and cas the cause for the remaining cases of 100% CPU reported. And a last one was causing similar symptoms but when using 0-RTT. At least, now nasty bugs start to require a lot of conditions to appear, that's good! In addition to this, this release fixes some build issues with OpenSSL libraries built with the "no-deprecated" option, fixes excessive memory usage on global state-file (16kB per server line), makes the "debug" converter available by default, and introduces a new "replace-path" HTTP action that is more convenient to use than "replace-uri" when HTTP/1 and HTTP/2 are used together. Quite frankly if you're not affected by the issues above, there's no need to rush an update, especially in this period. I'm mainly releasing this for those who need something easy to deploy in order to fix pending issues and avoid phone calls during Xmas ;-) I'll try to stay offline for a few days and am aware that some of the usual suspects here are also taking a bit of vacation, so please don't get upset if you face issues and there's a bit more lag than usual, and instead take the opportunity to first update, and second collect detailed traces to save time when people are back at the keyboard. Note: I'm also doing another 2.0 in parallel. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/2.1/src/ Git repository : http://git.haproxy.org/git/haproxy-2.1.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-2.1.git Changelog: http://www.haproxy.org/download/2.1/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Christopher Faulet (1): BUG/MEDIUM: stream: Be sure to never assign a TCP backend to an HTX stream Lukas Tribus (1): BUILD: ssl: improve SSL_CTX_set_ecdh_auto compatibility Olivier Houchard (3): BUG/MEDIUM: ssl: Don't set the max early data we can receive too early. BUG/MEDIUM: ssl: Revamp the way early data are handled. BUG/MEDIUM: fd/threads: fix a concurrency issue between add and rm on the same fd Rosen Penev (1): BUG/MINOR: ssl: openssl-compat: Fix getm_ defines Tim Duesterhus (1): MINOR: sample: Validate the number of bits for the sha2 converter Willy Tarreau (11): DOC: clarify the fact that replace-uri works on a full URI BUG/MINOR: sample: fix the closing bracket and LF in the debug converter BUG/MINOR: sample: always check converters' arguments MINOR: debug: support logging to various sinks MINOR: http: add a new "replace-path" action MINOR: task: only check TASK_WOKEN_ANY to decide to requeue a task BUG/MAJOR: task: add a new TASK_SHARED_WQ flag to fix foreing requeuing MINOR: fd/threads: make _GET_NEXT()/_GET_PREV() use the volatile attribute BUG/MEDIUM: state-file: do not allocate a full buffer for each server entry BUG/MINOR: state-file: do not store duplicates in the global tree BUG/MINOR: state-file: do not leak memory on parse errors ---
Re: [RFC PATCH] HTTPS connection reuse with SNI
On 18 Dec 16:46, Joshua Knox wrote: > A github issue was filed at https://github.com/haproxy/haproxy/issues/371 > > The CONTRIBUTING guidelines requested discussion on the list, I believe the > included diff would address that issue and arguably be less surprising > behavior. > > The comment from ehocdet on the issue indicated that connection reuse could > be reused if SNI was incorporated into connection selection criteria. I > think that that larger change would make sense for reuse in "http-reuse > safe" mode. > > There are currently a number of explicit checks for "http-reuse never" that > set the private connection flag (CO_FL_PRIVATE), I think that failing to > set it in this case is the logical counterpart. > > Thanks in advance, > Josh I would actually like the idea to remove the criteria to not reuse SNI connection, even in safe mode. After all there is not big difference once the connection is established and we can not change the value of sni() between requests anyway. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Outdated retries documentation
On 17 Dec 11:13, Willy Tarreau wrote: > Hi Julien, > > On Tue, Dec 17, 2019 at 09:16:37AM +0100, Julien Pivotto wrote: > > Dear list, > > > > https://github.com/haproxy/haproxy/blob/50603267981a002d2593bfe219e5071d66a8ea65/doc/configuration.txt#L7798-L7809 > > > > Is the retries documentation up to date, or should it be updated to > > specify that not only network errors are retried, but everything that > > falls into the "retry-on" directive? > > It would indeed make sense to update it to reflect the new possibilities. > > Thanks! > Willy Thanks for the confirmation. As the change is substantial I have created https://github.com/haproxy/haproxy/issues/412 so we don't forget. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Outdated retries documentation
Dear list, https://github.com/haproxy/haproxy/blob/50603267981a002d2593bfe219e5071d66a8ea65/doc/configuration.txt#L7798-L7809 Is the retries documentation up to date, or should it be updated to specify that not only network errors are retried, but everything that falls into the "retry-on" directive? Thanks -- (o- Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [2.1.1] http-request replace-uri does not work
On 17 Dec 06:58, Willy Tarreau wrote: > On Tue, Dec 17, 2019 at 06:08:56AM +0100, Willy Tarreau wrote: > > But now I'm starting to suspect that most of the problem comes from the > > fact that people who used to rely on regex in the past will not as easily > > perform their rewrites using set-path as they would using a replace rule > > which is very similar to the old set. So probably we'd need to introduce > > a "replace-path" action and suggest it in the warning emitted for reqrep. > > > > I think it is important that we properly address such needs and am > > willing to backport anything like this to 2.1 to ease the transition if > > that's the best solution. > > What about this ? It does exactly what's needed for me. It's self-contained > enough that we could get it backported to 2.1 and maybe even to 2.0 (though > it would require some adaptations to legacy mode there). > > Willy I am in favour of replace-path. Should we have a replace-domain or so for the first part of the abs url? -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HAProxy 2.0.10 and 2.1.0 RPM's
On 16 Dec 15:00, Ryan O'Hara wrote: > On Tue, Nov 26, 2019 at 2:40 PM Russell Eason wrote: > > > Hello, > > > > Fedora upstream added it > > https://src.fedoraproject.org/rpms/haproxy/c/45c57ba71174f308a5f59569bac0598bb31ef767 > > , and can be seen as far back as F24 here > > https://src.fedoraproject.org/rpms/haproxy/blob/f24/f/haproxy.spec . LUA > > support is in the RHEL 8 version of HAProxy, but not in 7 (yet?). > > > > Sorry for the late reply. I believe the reason that RHEL7 lacks LUA support > is because the required version of LUA is not available in RHEL7. Enabling > LUA support in haproxy at build time is easy, but if the underlying bits > aren't available, there is nothing I can do. Cheers. > > Ryan Alternatively I have updated https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/ to 2.1.1 In ELEL7 it uses https://copr.fedorainfracloud.org/coprs/roidelapluie/lua/ which is the LUA for RHEL8 compiled for RHEL7. We statically compile it within haproxy. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] DOC: proxies: HAProxy only supports 3 connection modes
On 11 Dec 10:51, Willy Tarreau wrote: > On Wed, Dec 11, 2019 at 10:49:00AM +0100, Julien Pivotto wrote: > > On 11 Dec 10:19, Willy Tarreau wrote: > > > On Tue, Dec 10, 2019 at 01:11:17PM +0100, Julien Pivotto wrote: > > > > The 4th one (forceclose) has been deprecated and deleted from the > > > > documentation in 10c6c16cde0b0b473a1ab16e958a7d6b61ed36fc > > > > > > > > Signed-off-by: Julien Pivotto > > > (...) > > > > > > Applied, thank you Julien. > > > Willy > > > > I am wondering wether there would be a value in adding a 4th one where > > we would keep alive the client connection but not the backend > > connection. > > That's exactly http-server-close. And yes it's very useful! I meant the opposite :) Client <- close -> HAProxy <- keepalive -> Backend > > Willy -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] DOC: proxies: HAProxy only supports 3 connection modes
On 11 Dec 10:19, Willy Tarreau wrote: > On Tue, Dec 10, 2019 at 01:11:17PM +0100, Julien Pivotto wrote: > > The 4th one (forceclose) has been deprecated and deleted from the > > documentation in 10c6c16cde0b0b473a1ab16e958a7d6b61ed36fc > > > > Signed-off-by: Julien Pivotto > (...) > > Applied, thank you Julien. > Willy I am wondering wether there would be a value in adding a 4th one where we would keep alive the client connection but not the backend connection. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
[PATCH] DOC: proxies: HAProxy only supports 3 connection modes
The 4th one (forceclose) has been deprecated and deleted from the
documentation in 10c6c16cde0b0b473a1ab16e958a7d6b61ed36fc
Signed-off-by: Julien Pivotto
---
doc/configuration.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 862fa72d4..cd6edc7d5 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2412,7 +2412,7 @@ arbitrary criteria.
In HTTP mode, the processing applied to requests and responses flowing over
a connection depends in the combination of the frontend's HTTP options and
-the backend's. HAProxy supports 4 connection modes :
+the backend's. HAProxy supports 3 connection modes :
- KAL : keep alive ("option http-keep-alive") which is the default mode : all
requests and responses are processed, and connections remain open but idle
--
2.22.0
signature.asc
Description: PGP signature
stable-bot for 2.1
Hi, I have the impression that stable-bot has not been configured for the 2.1 branch yet. Regards, -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
[PATCH] MINOR: acl: Add pre-defined HTTP_2.0 ACL
Signed-off-by: Julien Pivotto
---
doc/configuration.txt | 1 +
src/acl.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 862fa72d4..71fa1bdc8 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -16314,6 +16314,7 @@ FALSEalways_false never
match
HTTP req_proto_httpmatch if protocol is valid HTTP
HTTP_1.0 req_ver 1.0 match HTTP version 1.0
HTTP_1.1 req_ver 1.1 match HTTP version 1.1
+HTTP_2.0 req_ver 2.0 match HTTP version 2.0
HTTP_CONTENT hdr_val(content-length) gt 0 match an existing content-length
HTTP_URL_ABS url_reg ^[^/:]*://match absolute URL with scheme
HTTP_URL_SLASH url_beg / match URL beginning with "/"
diff --git a/src/acl.c b/src/acl.c
index 209580a11..e2d5f9ba7 100644
--- a/src/acl.c
+++ b/src/acl.c
@@ -797,6 +797,7 @@ const struct {
{ .name = "HTTP", .expr = {"req_proto_http",""}},
{ .name = "HTTP_1.0", .expr = {"req_ver","1.0",""}},
{ .name = "HTTP_1.1", .expr = {"req_ver","1.1",""}},
+ { .name = "HTTP_2.0", .expr = {"req_ver","2.0",""}},
{ .name = "METH_CONNECT", .expr = {"method","CONNECT",""}},
{ .name = "METH_DELETE",.expr = {"method","DELETE",""}},
{ .name = "METH_GET", .expr = {"method","GET","HEAD",""}},
--
2.22.0
signature.asc
Description: PGP signature
Re: Extra Prometheus metrics
On 05 Dec 14:45, Christopher Faulet wrote: > - haproxy_backend_response_time_average_seconds > - haproxy_server_response_time_average_seconds That is not helpful as 1024 last connection could have happened in the last 5 minutes or the last 1 second. I would like to be able to run: rate(haproxy_backend_http_responses_time_second_total[5m]) / rate(haproxy_backend_http_responses_total[5m]) -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Extra Prometheus metrics
Dear list, I am looking at the Prometheus metrics in HAProxy and I miss some of them: - Is it possible to get a more fine grained view of the return codes than 2xx,3xx,4xx. Indeed, an error 404 is different than 403 (404 might be the browser trying to get a favicon and 400 an actual error) and 503 is different than 500 (500 might be a business SOAP FAULT) - I see no metrics like: - haproxy_frontend_http_responses_seconds_total - haproxy_backend_http_responses_seconds_total Those metrics would allow me to calculate the response time of the http queries that go via HAProxy. Thank you. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: DNS resolution every second - v2.0.10
On 28 Nov 11:02, Baptiste wrote: > On Thu, Nov 28, 2019 at 10:56 AM Julien Pivotto > wrote: > > > On 28 Nov 10:38, Baptiste wrote: > > > 'hold valid' still prevents HAProxy from changing the status of the > > server > > > in current Valid status to an other status for that period of time. > > > Imagine your server is UP, DNS is valid, then your server returns NX for > > 2 > > > minutes, then the status of the server won't change. If NX is returned > > for > > > more than 5 minutes (as stated in your config), then it will change. > > > > > > Baptiste > > > > That is really great. Does it mean that with > > > > hold valid 1h > > timeout resolve 30s > > > > we can have: > > 1h of DNS downtime without impact on haproxy > > > > but if DNS is up, any change will be picked after 30 seconds? > > > > > yep exactly! > Previous behavior was wrong (using hold valid as timeout resolve). hold Defines during which the last name resolution should be kept based on last resolution So ... I guess the documentation is not clear here. Would you mind clarifying it? I read it as: host valid 300s define a period of 300s during which the last name resolution should be kept based on last valid resolution I understand: if we get a valid resolution, we keep the last name resolution for 300s. > > Baptiste -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HAProxy 2.0.10 and 2.1.0 RPM's
On 28 Nov 12:09, Julien Pivotto wrote: > On 27 Nov 01:15, Илья Шипицин wrote: > > ср, 27 нояб. 2019 г. в 01:10, Russell Eason : > > > > > Hello, > > > > > > Fedora upstream added it > > > https://src.fedoraproject.org/rpms/haproxy/c/45c57ba71174f308a5f59569bac0598bb31ef767 > > > , and can be seen as far back as F24 here > > > https://src.fedoraproject.org/rpms/haproxy/blob/f24/f/haproxy.spec . LUA > > > support is in the RHEL 8 version of HAProxy, but not in 7 (yet?). > > > > > > > I really stuck on that. > > haproxy needs Lua-5.3, there's no good for CentOS 7 > > I have published 2.1.0-7 rpm's which use LUA: > > - in EL7 it is statically linked (from > https://copr.fedorainfracloud.org/coprs/roidelapluie/lua/) so it does > not depend on any centos lua package. As trade off I needed to disable > PIE: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie. > Use with care. > - in EL8 is is dynamically linked 2.1.0-8 is out, where I successfully enabled PIE again, which is really a good thing (needed to enable PIE on lua too). Please test and send feedback: 2.1.0-8 EL7 : HAProxy with LUA statically linked https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/repo/epel-7/roidelapluie-haproxy-epel-7.repo 2.1.0-8 EL8 : HAProxy with LUA dynamically linked https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/repo/epel-8/roidelapluie-haproxy-epel-8.repo > > I also cherry-picked fa137e3b5c994508370e0cd2396ece081a1316c4 as it is a > bug that affects me (being totally selfish here ...) > > Regards, > > -- > (o-Julien Pivotto > //\Open-Source Consultant > V_/_ Inuits - https://www.inuits.eu -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HAProxy 2.0.10 and 2.1.0 RPM's
On 27 Nov 01:15, Илья Шипицин wrote: > ср, 27 нояб. 2019 г. в 01:10, Russell Eason : > > > Hello, > > > > Fedora upstream added it > > https://src.fedoraproject.org/rpms/haproxy/c/45c57ba71174f308a5f59569bac0598bb31ef767 > > , and can be seen as far back as F24 here > > https://src.fedoraproject.org/rpms/haproxy/blob/f24/f/haproxy.spec . LUA > > support is in the RHEL 8 version of HAProxy, but not in 7 (yet?). > > > > I really stuck on that. > haproxy needs Lua-5.3, there's no good for CentOS 7 I have published 2.1.0-7 rpm's which use LUA: - in EL7 it is statically linked (from https://copr.fedorainfracloud.org/coprs/roidelapluie/lua/) so it does not depend on any centos lua package. As trade off I needed to disable PIE: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie. Use with care. - in EL8 is is dynamically linked I also cherry-picked fa137e3b5c994508370e0cd2396ece081a1316c4 as it is a bug that affects me (being totally selfish here ...) Regards, -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: DNS resolution every second - v2.0.10
On 28 Nov 10:38, Baptiste wrote: > 'hold valid' still prevents HAProxy from changing the status of the server > in current Valid status to an other status for that period of time. > Imagine your server is UP, DNS is valid, then your server returns NX for 2 > minutes, then the status of the server won't change. If NX is returned for > more than 5 minutes (as stated in your config), then it will change. > > Baptiste That is really great. Does it mean that with hold valid 1h timeout resolve 30s we can have: 1h of DNS downtime without impact on haproxy but if DNS is up, any change will be picked after 30 seconds? -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
[PATCH] DOC: Fix ordered list in summary
Signed-off-by: Julien Pivotto --- doc/configuration.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 7e5ecd881..787f77988 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -64,6 +64,12 @@ Summary 5.3.1. Global overview 5.3.2. The resolvers section +6.Cache +6.1. Limitation +6.2. Setup +6.2.1.Cache section +6.2.2.Proxy section + 7.Using ACLs and fetching samples 7.1. ACL basics 7.1.1. Matching booleans @@ -82,12 +88,6 @@ Summary 7.3.6.Fetching HTTP samples (Layer 7) 7.4. Pre-defined ACLs -6.Cache -6.1. Limitation -6.2. Setup -6.2.1.Cache section -6.2.2.Proxy section - 8.Logging 8.1. Log levels 8.2. Log formats -- 2.22.0 -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HAProxy 2.0.10 and 2.1.0 RPM's
On 27 Nov 04:00, Willy Tarreau wrote: > Hi guys, > > Regarding Lua, it is among the packages which don't move fast and which > present very little long-term risk, so it can very well be included as > a static dependency if not supported in certain distros. I've already > been wondering whether or not we should include a local copy of it into > the haproxy source code, but I really hate doing this. I'd rather help > packagers build it locally in fact. > > Thanks, > Willy Willy, What is the flag to build lua statically? is there a flag yet? -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Regression in 2.1 with Host header sent by backends
On 27 Nov 00:39, Lukas Tribus wrote: > On Wed, Nov 27, 2019 at 12:36 AM Julien Pivotto > wrote: > > > > On 27 Nov 00:31, Lukas Tribus wrote: > > > Hello Julien, > > > > > > > > > > > > On Wed, Nov 27, 2019 at 12:21 AM Julien Pivotto > > > wrote: > > > > Haproxy 2.1 blocks a response with PH-- if the response has a Host > > > > header. > > > > > > A Host header belongs to the request, not the response. Haproxy 2.1 is > > > more strict in that regard. You can configure "option > > > accept-invalid-http-response" to ignore it. > > > > > > That said, I'm not sure this was really the intention of the change in > > > question (commit 531b83e03 "MINOR: h1: Reject requests if the > > > authority does not match the header host"). Christopher? > > > > > > > > > Lukas > > > > I tried this option after finding that commit, but it does not work. > > > > I know that that header belongs to requests normally but in this case we > > have a backend that sends it in the response. > > I just tried it, it does work, but it needs to be > option accept-invalid-http-response > > not > option accept-invalid-http-request > > as mentioned in the commit, because this is about the server response, > not the client request. Yes indeed. I tested too and it works. I indeed tried accept-invalid-http-request like in the commit message instead of accept-invalid-http-response. My concern with the workaround is that there might be huge side effects. Thank you :) > > > Lukas -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: Regression in 2.1 with Host header sent by backends
On 27 Nov 00:31, Lukas Tribus wrote: > Hello Julien, > > > > On Wed, Nov 27, 2019 at 12:21 AM Julien Pivotto > wrote: > > Haproxy 2.1 blocks a response with PH-- if the response has a Host header. > > A Host header belongs to the request, not the response. Haproxy 2.1 is > more strict in that regard. You can configure "option > accept-invalid-http-response" to ignore it. > > That said, I'm not sure this was really the intention of the change in > question (commit 531b83e03 "MINOR: h1: Reject requests if the > authority does not match the header host"). Christopher? > > > Lukas I tried this option after finding that commit, but it does not work. I know that that header belongs to requests normally but in this case we have a backend that sends it in the response. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Regression in 2.1 with Host header sent by backends
Hello Haproxy 2.1 blocks a response with PH-- if the response has a Host header. Haproxy config: frontend default bind 127.0.0.1:8443 use_backend default log stdout format raw local0 mode http option httplog backend default mode http http-request set-header Host mcntest.free.beeceptor.com server x mcntest.free.beeceptor.com:443 ssl sni str(mcntest.free.beeceptor.com) ssl verify none Request without haproxy: [root@1f8d018cdbee /]# curl https://mcntest.free.beeceptor.com:443 -v * About to connect() to mcntest.free.beeceptor.com port 443 (#0) * Trying 165.227.26.218... * Connected to mcntest.free.beeceptor.com (165.227.26.218) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=beeceptor.com * start date: Nov 02 19:01:58 2019 GMT * expire date: Jan 31 19:01:58 2020 GMT * common name: beeceptor.com * issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: mcntest.free.beeceptor.com > Accept: */* > < HTTP/1.1 200 OK < Date: Tue, 26 Nov 2019 22:50:21 GMT < Transfer-Encoding: chunked < Connection: keep-alive < Access-Control-Allow-Origin: * < Host: mcntest.free.beeceptor.com < * Connection #0 to host mcntest.free.beeceptor.com left intact Request with haproxy: [root@1f8d018cdbee /]# curl 127.0.0.1:8443 -v * About to connect() to 127.0.0.1 port 8443 (#0) * Trying 127.0.0.1... * Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 127.0.0.1:8443 > Accept: */* > < HTTP/1.1 502 Bad Gateway < content-length: 107 < cache-control: no-cache < content-type: text/html < connection: close < 502 Bad Gateway The server returned an invalid or incomplete response. * Closing connection 0 127.0.0.1:39820 [26/Nov/2019:22:53:09.560] default default/x 0/0/486/-1/681 502 229 - - PH-- 1/1/0/0/0 0/0 "GET / HTTP/1.1" Why is this request blocked? As soon as I remove the HOST header from the response (server side), it works fine. NOTE: this worked in haproxy 2.0, no longer in 2.1, so it looks like a regression. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: HAProxy 2.0.10 and 2.1.0 RPM's
On 27 Nov 00:51, Илья Шипицин wrote: > thank for the rpm > > it was faster than I did )) > > any plans to add Lua ? Hello, It is not in the upstream spec file that I use, and I personnaly do not use lua yet. If there is interest I can have a look at that. > > ср, 27 нояб. 2019 г. в 00:36, Julien Pivotto : > > > Dear HAProxy Community, > > > > I have started building HAProxy 2.x packages for CentOS. > > > > It includes HAProxy 2.0.10 and 2.1.0. > > > > You can find them here: > > https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/ > > > > https://github.com/roidelapluie/haproxy-rpm > > which is based on https://git.centos.org/rpms/rh-haproxy18-haproxy > > > > Repo config: > > > > https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/repo/epel-7/roidelapluie-haproxy-epel-7.repo > > > > Copr is the Fedora public tool to build packages. Build logs are public, > > as well as source RPM's etc. So you are free to review it. > > > > -- > > (o-Julien Pivotto > > //\Open-Source Consultant > > V_/_ Inuits - https://www.inuits.eu > > -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
HAProxy 2.0.10 and 2.1.0 RPM's
Dear HAProxy Community, I have started building HAProxy 2.x packages for CentOS. It includes HAProxy 2.0.10 and 2.1.0. You can find them here: https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/ https://github.com/roidelapluie/haproxy-rpm which is based on https://git.centos.org/rpms/rh-haproxy18-haproxy Repo config: https://copr.fedorainfracloud.org/coprs/roidelapluie/haproxy/repo/epel-7/roidelapluie-haproxy-epel-7.repo Copr is the Fedora public tool to build packages. Build logs are public, as well as source RPM's etc. So you are free to review it. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
