Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
There were bug reports if centos 6 is broken. Which means people actively use it On Thu, May 28, 2020, 3:21 AM Tim Düsterhus wrote: > Ilya, > > Am 27.05.20 um 22:53 schrieb Илья Шипицин: > > Hello, > > > > let us skip new test on CentOS6 > > > > There definitely should be a smarter solution than "delete test" to skip > tests that depend on OpenSSL's features. > > Or maybe we should just get rid of CentOS 6 tests, it will be end of > life on November, 30th anyway. > > Best regards > Tim Düsterhus >
Re: stable-bot: Bugfixes waiting for a release 2.1 (52), 2.0 (45)
Hi Tim, On Wed, May 27, 2020 at 04:33:47PM +0200, Tim Düsterhus wrote: > I already asked 2 weeks ago [1], but I'll ask again: > > > Is there any date planned for 2.1.5? I'm still running 2.1.3 on one > > machine, because I use Dovecot. > > And I only just realize that 2.1.3 is affected by CVE-2020-11100 which > makes the current situation especially ugly. Either I run a version with > a critical bug without workaround, I break Dovecot or I compile my own > HAProxy. Thanks for the ping. I'm trying :-/ I've been stuck doing only janitor work for the last 3 months with zero development at all and am still having a number of things to do before the release. I'll try to emit a new one today or tomorrow. Willy
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
Ilya, Am 27.05.20 um 22:53 schrieb Илья Шипицин: > Hello, > > let us skip new test on CentOS6 > There definitely should be a smarter solution than "delete test" to skip tests that depend on OpenSSL's features. Or maybe we should just get rid of CentOS 6 tests, it will be end of life on November, 30th anyway. Best regards Tim Düsterhus
[PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
Hello,
let us skip new test on CentOS6
Cheers,
Ilya Shipitcin
From 4585b4f3b3f6dcbef071b36e7a589cd89757818e Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Thu, 28 May 2020 01:50:57 +0500
Subject: [PATCH] CI: cirrus-ci: skip
reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
as reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc requires ALPN, which is not
supported on CentOS 6, let us skip that test
---
.cirrus.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.cirrus.yml b/.cirrus.yml
index 07e1bb285..4e2a3330f 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -27,5 +27,5 @@ centos_6_task:
- ./haproxy -vv
- ldd haproxy
# remove some reg-tests (CentOS 6 does not support alpn)
-- rm reg-tests/connection/proxy_protocol_random_fail.vtc reg-tests/checks/tcp-check-ssl.vtc
+- rm reg-tests/{connection/proxy_protocol_random_fail,checks/tcp-check-ssl,connection/proxy_protocol_send_unique_id_alpn}.vtc
- env VTEST_PROGRAM=../vtest/vtest make reg-tests || (for folder in /tmp/*regtest*/vtc.*; do cat $folder/INFO $folder/LOG; done && exit 1)
--
2.26.2
Re: [PATCH] cleanup coverity findging (make it silent)
well, I do not have an idea why extchk_setenv(check, EXTCHK_HAPROXY_SERVER_ADDR, check->argv[3]); is used instead of EXTCHK_SETENV(check, EXTCHK_HAPROXY_SERVER_ADDR, check->argv[3], err); it means, some environment variables are set in "best effort" mode, i.e. error is ignored. is it bad ? I'm not sure. code comes from https://github.com/haproxy/haproxy/commit/61cc85223098a962616ececa2d6bdd7809c37fe3 Christopher, do you know why we ignore exit status here ? вт, 26 мая 2020 г. в 19:59, Илья Шипицин : > > > вт, 26 мая 2020 г. в 12:02, Willy Tarreau : > >> Hi Ilya, >> >> On Sat, May 23, 2020 at 03:47:58PM +0500, ??? wrote: >> > From: Ilya Shipitsin >> > Date: Sat, 23 May 2020 15:35:36 +0500 >> > Subject: [PATCH] CLEANUP: src/checks.c: ignore return value using >> DISGUISE(..) >> > >> > we do not want to check status of extchk_setenv, but static analyzsers >> > like Coverity are not happy about it. Let calm coverity down. >> >> Are you really sure we don't want to check them ? I'm seeing that >> prepare_external_check() uses EXTCHK_SETENV() to purposely add checks >> there, so it's unclear to me why we want to silently fail here. Maybe >> the calls should instead be changed to have a check and a jump to an >> error label doing the exit(). >> >> I don't know if anyone has an opinion on this, I'm not using external >> checks :-/ >> > > well, I meant to keep current behaviour, but also silence coverity warning. > > ok, we can investigate and discuss would it be better to change current > behaviour or to keep it. > > >> >> Willy >> >
Re: Redefine 401 error page
Hi Christopher, On Wed, May 27, 2020 at 07:03:58PM +0200, Christopher Faulet wrote: > Here are patches to handle customizable 401/407 messages. In fact, only the > second patch is really meaningful. There is no change for the http-request > auth rule from the configuration point of view. Internally, we rely on the > proxy's error messages. It means 401 and 407 status codes are allowed on > "errorfile" and "http-error" lines. I love patches like this which remove more code than they add :-) I'd have a minor request, which is to remove the empty www-authenticate and proxy-authenticate headers from the default response templates. Since the header is not edited in place but removed, it will make no difference, and at least if someone sends them as-is with http-request deny, we won't be sending an empty realm nor enforcing basic auth, but the browser will be free to do whatever it wants. In addition it would allow the user to manually append the header in a deny or return rule. Looks pretty good otherwise. Thanks! Willy
range queries (my favourite)
hello, how does haproxy serves queries like that: Range: bytes=0-,0-,0-,0-, more info: https://www.zdnet.com/article/rangeamp-attacks-can-take-down-websites-and-cdn-servers/ Cheers, Ilya Shipitcin
Re: Redefine 401 error page
Le 26/05/2020 à 10:22, Christopher Faulet a écrit :
In HAProxy 2.2, I guess 401/407 responses may be generated using an http-request
return rule, making http-request auth rule more or less deprecated. The only
mess is to handle 2 different responses depending on the request path when the
http-use-proxy-header option is used. In addition, http_reply_40x_unauthorized()
is also called for the stats page authentication. This part cannot be replaced
by an http-request return rule. So maybe a good solution is to use error files
(customizable since 2.2). And just add the realm at the right place, as Willy
said. I will investigate.
For HTTP_30X templates, you're right, they should be removed. And HTTP_10X too.
Here are patches to handle customizable 401/407 messages. In fact, only the
second patch is really meaningful. There is no change for the http-request auth
rule from the configuration point of view. Internally, we rely on the proxy's
error messages. It means 401 and 407 status codes are allowed on "errorfile" and
"http-error" lines.
The other patches are just cosmetic changes. The last one removes unused
HTTP_XXX templates.
Any comments ?
--
Christopher Faulet
>From 5eb45f6a374c920cff241e38e4e1010c593af403 Mon Sep 17 00:00:00 2001
From: Christopher Faulet
Date: Wed, 27 May 2020 15:24:22 +0200
Subject: [PATCH 1/4] MINOR: http-ana: Make the function http_reply_to_htx()
public
This function may be used from anywhere to convert an HTTP reply to an HTX
message.
---
include/proto/http_ana.h | 1 +
src/http_ana.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/proto/http_ana.h b/include/proto/http_ana.h
index c226b1254..894357688 100644
--- a/include/proto/http_ana.h
+++ b/include/proto/http_ana.h
@@ -52,6 +52,7 @@ void http_server_error(struct stream *s, struct stream_interface *si, int err, i
void http_reply_and_close(struct stream *s, short status, struct http_reply *msg);
void http_return_srv_error(struct stream *s, struct stream_interface *si);
struct http_reply *http_error_message(struct stream *s);
+int http_reply_to_htx(struct stream *s, struct htx *htx, struct http_reply *reply);
int http_reply_message(struct stream *s, struct http_reply *reply);
int http_forward_proxy_resp(struct stream *s, int final);
diff --git a/src/http_ana.c b/src/http_ana.c
index f5add7d98..f7da26821 100644
--- a/src/http_ana.c
+++ b/src/http_ana.c
@@ -4658,7 +4658,7 @@ struct http_reply *http_error_message(struct stream *s)
* errorfile, an raw file or a log-format string is used. On success, it returns
* 0. If an error occurs -1 is returned.
*/
-static int http_reply_to_htx(struct stream *s, struct htx *htx, struct http_reply *reply)
+int http_reply_to_htx(struct stream *s, struct htx *htx, struct http_reply *reply)
{
struct buffer *errmsg;
struct htx_sl *sl;
--
2.26.2
>From 686f4e1d19ba569890f6c91a6c2b189aeeb03c34 Mon Sep 17 00:00:00 2001
From: Christopher Faulet
Date: Wed, 27 May 2020 09:57:28 +0200
Subject: [PATCH 2/4] MINOR: http-ana: Use proxy's error replies to emit
401/407 responses
There is no reason to not use proxy's error replies to emit 401/407
responses. The function http_reply_40x_unauthorized(), responsible to emit those
responses, is not really complex. It only adds a
WWW-Authenticate/Proxy-Authenticate header to a generic message.
So now, error replies can be defined for 401 and 407 status codes, using
errorfile or http-error directives. When an http-request auth rule is evaluated,
the corresponding error reply is used. For 401 responses, all occurrences of the
WWW-Authenticate header are removed and replaced by a new one with a basic
authentication challenge for the configured realm. For 407 responses, the same
is done on the Proxy-Authenticate header. If the error reply must not be
altered, "http-request return" rule must be used instead.
---
doc/configuration.txt | 32 +++
include/common/http.h | 2 ++
src/http.c| 24 +++
src/http_ana.c| 71 +++
4 files changed, 78 insertions(+), 51 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 674acd2fd..8a67f4d12 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2522,8 +2522,8 @@ errorfile
Arguments :
is the HTTP status code. Currently, HAProxy is capable of
- generating codes 200, 400, 403, 404, 405, 408, 410, 425, 429,
- 500, 502, 503, and 504.
+ generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
+ 425, 429, 500, 502, 503, and 504.
designates a file containing the full HTTP response. It is
recommended to follow the common practice of appending ".http" to
@@ -3859,8 +3859,8 @@ errorfile
yes |yes | yes | yes
Arguments :
is the HTTP status code. Currently, HAProxy is capable of
-
Re: stable-bot: Bugfixes waiting for a release 2.1 (52), 2.0 (45)
Hi List, Willy, Am 27.05.20 um 02:00 schrieb stable-...@haproxy.com: > Last release 2.1.4 was issued on 2020-04-02. There are currently 52 patches > in the queue cut down this way: > - 1 MAJOR, first one merged on 2020-05-20 > - 20 MEDIUM, first one merged on 2020-05-01 > - 31 MINOR, first one merged on 2020-04-02 > > Thus the computed ideal release date for 2.1.5 would be 2020-04-30, which was > four weeks ago. > > Last release 2.0.14 was issued on 2020-04-02. There are currently 45 patches > in the queue cut down this way: > - 1 MAJOR, first one merged on 2020-05-22 > - 18 MEDIUM, first one merged on 2020-05-07 > - 26 MINOR, first one merged on 2020-04-02 > > Thus the computed ideal release date for 2.0.15 would be 2020-04-30, which > was four weeks ago. I already asked 2 weeks ago [1], but I'll ask again: > Is there any date planned for 2.1.5? I'm still running 2.1.3 on one > machine, because I use Dovecot. And I only just realize that 2.1.3 is affected by CVE-2020-11100 which makes the current situation especially ugly. Either I run a version with a critical bug without workaround, I break Dovecot or I compile my own HAProxy. Best regards Tim Düsterhus [1] https://www.mail-archive.com/haproxy@formilux.org/msg37344.html
Re: [PATCH] REGTEST: Add connection/proxy_protocol_send_unique_id_alpn
Christopher, Am 27.05.20 um 13:38 schrieb Christopher Faulet: > Thanks Tim. Now applied. > Ugh. I realize that I messed up all the commit hashes within the commit message, because I've taken the hashes from my testing branch where I cherry-picked them onto an old commit to verify the test fails without them and passes with them :-/ For posteriority the correct commits are: 68ad53cb3781010ccde7c781b6a3a1e926b5ed23 3ab504f5ff53968ae70d592cba4c1c7da6a0e7ff d82056c319814f9328db07dd50ab90785ec6c95c Best regards Tim Düsterhus
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
Hello, On Wed, 27 May 2020 at 13:33, Илья Шипицин wrote: > ср, 27 мая 2020 г. в 16:09, Tim Düsterhus : >> >> William, >> >> Am 27.05.20 um 12:40 schrieb William Lallemand: >> > 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? >> > >> >> As a data point: >> >> The OpenSSL shipped with Debian Buster does not support anything below >> TLS 1.2 by default [1]. The same is true starting with Ubuntu 20.04 LTS. > > > > I know several real-world cases when people had to build their own openssl on > Debian Buster in order get TLS1.0 back I'm certain that there is a ton of sites that still need TLSv1.0 going forward, however that doesn't mean we cannot change our *DEFAULTS* in a new *MAJOR* release, a default that is easily overwritten by a single configuration statement (and which is present in most configurations anyway). We are not talking about build options here. So in my opinion bumping the default minimum TLS version to 1.2 is a good thing and brings us inline with industry standard practices at this point. Therefor I don't have any objections. Lukas
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
Ilya, Am 27.05.20 um 13:33 schrieb Илья Шипицин: >> As a data point: >> >> The OpenSSL shipped with Debian Buster does not support anything below >> TLS 1.2 by default [1]. The same is true starting with Ubuntu 20.04 LTS. >> > > > I know several real-world cases when people had to build their own openssl > on Debian Buster in order get TLS1.0 back > Sure. But admins that are capable enough to compile their own OpenSSL will be capable enough to add the following to their HAProxy configuration: ssl-default-bind-options ssl-min-ver TLSv1.0 However in the general case you won't get far as a client in today's Internet without supporting TLS 1.2. For my machines I dropped support for anything < 1.2 on port 443 more than 2 years ago. Best regards Tim Düsterhus
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: [PATCH] REGTEST: Add connection/proxy_protocol_send_unique_id_alpn
Le 27/05/2020 à 12:58, Tim Duesterhus a écrit : Christopher, as mentioned in my comment in #640 I wrote a test that verifies that unique IDs via PPv2 continue to work or ALPN servers in the future: https://github.com/haproxy/haproxy/issues/640#issuecomment-634117124 The test does the bare minimum, receiving a single unique ID. The remaining behavior is tested in proxy_protocol_send_unique_id.vtc which does not depend on SSL. Thanks Tim. Now applied. -- Christopher Faulet
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
ср, 27 мая 2020 г. в 16:09, Tim Düsterhus : > William, > > Am 27.05.20 um 12:40 schrieb William Lallemand: > > 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? > > > > As a data point: > > The OpenSSL shipped with Debian Buster does not support anything below > TLS 1.2 by default [1]. The same is true starting with Ubuntu 20.04 LTS. > I know several real-world cases when people had to build their own openssl on Debian Buster in order get TLS1.0 back > > Best regards > Tim Düsterhus > > [1] > > https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#openssl-defaults > >
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
William, Am 27.05.20 um 12:40 schrieb William Lallemand: > 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? > As a data point: The OpenSSL shipped with Debian Buster does not support anything below TLS 1.2 by default [1]. The same is true starting with Ubuntu 20.04 LTS. Best regards Tim Düsterhus [1] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#openssl-defaults
[PATCH] REGTEST: Add connection/proxy_protocol_send_unique_id_alpn
Christopher,
as mentioned in my comment in #640 I wrote a test that verifies that unique IDs
via PPv2 continue to work or ALPN servers in the future:
https://github.com/haproxy/haproxy/issues/640#issuecomment-634117124
The test does the bare minimum, receiving a single unique ID. The remaining
behavior is tested in proxy_protocol_send_unique_id.vtc which does not depend
on SSL.
Best regards
Tim Düsterhus
Apply with `git am --scissors` to automatically cut the commit message.
-- >8 --
This reg-test checks that sending unique IDs via PPv2 works for servers
with the `alpn` option specified (issue #640). As a side effect it also
checks that PPv2 works with ALPN (issue #651).
It has been verified that the test fails without the following commits
applied and succeeds with them applied.
1f9a4ecea BUG/MEDIUM: backend: set the connection owner to the session when
using alpn.
083fd42d5 BUG/MEDIUM: connection: Ignore PP2 unique ID for stream-less
connections
eb9ba3cb2 BUG/MINOR: connection: Always get the stream when available to
send PP2 line
Without the first two commits HAProxy crashes during execution of the
test. Without the last commit the test will fail, because no unique ID
is received.
---
.../proxy_protocol_send_unique_id_alpn.vtc| 33 +++
1 file changed, 33 insertions(+)
create mode 100644 reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc
diff --git a/reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc
b/reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc
new file mode 100644
index 0..87e590a9b
--- /dev/null
+++ b/reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc
@@ -0,0 +1,33 @@
+varnishtest "Check that the unique ID TLV is properly sent for servers with
ALPN option"
+
+#REQUIRE_VERSION=2.2
+#REQUIRE_OPTIONS=OPENSSL
+
+feature ignore_unknown_macro
+
+haproxy h1 -conf {
+defaults
+mode http
+log global
+unique-id-format %{+X}o\ TEST-%[req.hdr(in)]
+
+listen sender
+bind "fd@${feS}"
+
+server example ${h1_feR_addr}:${h1_feR_port} send-proxy-v2
proxy-v2-options unique-id ssl alpn XXX verify none
+
+listen receiver
+bind "fd@${feR}" ssl crt ${testdir}/common.pem accept-proxy
+
+http-request set-var(txn.proxy_unique_id) fc_pp_unique_id
+http-after-response set-header proxy_unique_id
%[var(txn.proxy_unique_id)]
+http-request return status 200
+} -start
+
+# Validate that a correct header passes
+client c1 -connect ${h1_feS_sock} {
+txreq -url "/" \
+-hdr "in: foo"
+rxresp
+expect resp.http.proxy_unique_id == "TEST-foo"
+} -run
--
2.26.2
Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
as a person running pretty large load balancer installation, I confirm there are a lot of usages of TLS10. for example, depending on .net version, default setting might be TLS1.0 if you run .net 4.5 the ability to turn TLS1.0 without recompile is the must thing to have. I'm even not sure about benefits of disabling TLS1.0, yes it lack PFS support, but it is still not vulnerable to any attack and widely used (beleive me). I agree there are special cases like PCI DSS 3.2, but it is not the default :) ср, 27 мая 2020 г. в 15:43, William Lallemand : > 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? > > -- > William Lallemand > >
RFC: set minimum default TLS version to 1.2 for HAProxy 2.2
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? -- William Lallemand
HAproxy 2.X RPM
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, Loïc CHANEL System Big Data engineer Vision 360 Degrés - SoftAtHome (Lyon, France)
