[PATCH] CI: switch to stable LibreSSL release
I attached a patch that switches to LibreSSL-3.2.X (in the future, I'll have a look whether it is good idea to try libressl master branch or not) Ilya From c5dc6ff148214b314673c6ee1f83cb973ee4b1db Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Fri, 19 Feb 2021 12:09:31 +0500 Subject: [PATCH] CI: github actions: switch to stable LibreSSL release LibreSSL-3.3.0 appeared to have its own bugs, it is development release, let us switch to stable LibreSSL-3.2.4 instead --- .github/matrix.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/matrix.py b/.github/matrix.py index a5ce1919a..3489833d0 100644 --- a/.github/matrix.py +++ b/.github/matrix.py @@ -105,7 +105,7 @@ for CC in ["gcc", "clang"]: "stock", "OPENSSL_VERSION=1.0.2u", "LIBRESSL_VERSION=2.9.2", -"LIBRESSL_VERSION=3.3.0", +"LIBRESSL_VERSION=3.2.4", "BORINGSSL=yes", ]: flags = ["USE_OPENSSL=1"] -- 2.29.2
[PATCH 2/3] REGTESTS: contrib/prometheus-exporter: test NaN values
In order to make sure we detect when we change default behaviour for
some metrics, test the NaN value when it is expected.
Those metrics were listed since our last rework as their default value
changed, unless the appropriate config is set.
Signed-off-by: William Dauchy
---
reg-tests/contrib/prometheus.vtc | 30 ++
1 file changed, 30 insertions(+)
diff --git a/reg-tests/contrib/prometheus.vtc b/reg-tests/contrib/prometheus.vtc
index cdd0f0f55..1ebeb29cb 100644
--- a/reg-tests/contrib/prometheus.vtc
+++ b/reg-tests/contrib/prometheus.vtc
@@ -10,6 +10,11 @@ server s1 {
txresp
} -repeat 2 -start
+server s2 {
+ rxreq
+ txresp
+} -repeat 2 -start
+
haproxy h1 -conf {
defaults
mode http
@@ -29,11 +34,13 @@ haproxy h1 -conf {
backend be
stick-table type ip size 1m expire 10s store http_req_rate(10s)
server s1 ${s1_addr}:${s1_port}
+ server s2 ${s2_addr}:${s2_port} check maxqueue 10 maxconn 12
pool-max-conn 42
} -start
client c1 -connect ${h1_stats_sock} {
txreq -url "/metrics"
rxresp
+ # test general metrics
expect resp.status == 200
expect resp.body ~ ".*haproxy_process.*"
expect resp.body ~ ".*haproxy_frontend.*"
@@ -42,6 +49,29 @@ client c1 -connect ${h1_stats_sock} {
expect resp.body ~ ".*haproxy_server.*"
expect resp.body ~ ".*haproxy_sticktable.*"
+ # test expected NaN values
+ expect resp.body ~
".*haproxy_server_check_failures_total{proxy=\"be\",server=\"s1\"} NaN.*"
+ expect resp.body ~
".*haproxy_server_check_up_down_total{proxy=\"be\",server=\"s1\"} NaN.*"
+ expect resp.body ~
".*haproxy_server_check_failures_total{proxy=\"be\",server=\"s2\"} 0.*"
+ expect resp.body ~
".*haproxy_server_check_up_down_total{proxy=\"be\",server=\"s2\"} 0.*"
+
+ expect resp.body ~
".*haproxy_server_queue_limit{proxy=\"be\",server=\"s1\"} NaN.*"
+ expect resp.body ~
".*haproxy_server_queue_limit{proxy=\"be\",server=\"s2\"} 10.*"
+
+ expect resp.body ~
".*haproxy_server_limit_sessions{proxy=\"be\",server=\"s1\"} NaN.*"
+ expect resp.body ~
".*haproxy_server_limit_sessions{proxy=\"be\",server=\"s2\"} 12.*"
+
+ expect resp.body ~
".*haproxy_backend_downtime_seconds_total{proxy=\"stats\"} NaN.*"
+ expect resp.body ~
".*haproxy_backend_downtime_seconds_total{proxy=\"be\"} 0.*"
+ expect resp.body ~
".*haproxy_server_downtime_seconds_total{proxy=\"be\",server=\"s1\"} NaN.*"
+ expect resp.body ~
".*haproxy_server_downtime_seconds_total{proxy=\"be\",server=\"s2\"} 0.*"
+
+ expect resp.body ~
".*haproxy_server_current_throttle{proxy=\"be\",server=\"s1\"} NaN.*"
+
+ expect resp.body ~
".*haproxy_server_idle_connections_limit{proxy=\"be\",server=\"s1\"} NaN.*"
+ expect resp.body ~
".*haproxy_server_idle_connections_limit{proxy=\"be\",server=\"s2\"} 42.*"
+
+ # test scope
txreq -url "/metrics?scope="
rxresp
expect resp.status == 200
--
2.30.0
[PATCH 1/3] DOC: contrib/prometheus-exporter: remove htx reference
now that htx is the default everywhere, we can remove the need to put
htx as a mandatory option to setup prometheus.
Signed-off-by: William Dauchy
---
contrib/prometheus-exporter/README | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/prometheus-exporter/README
b/contrib/prometheus-exporter/README
index 30154de95..fdbc50203 100644
--- a/contrib/prometheus-exporter/README
+++ b/contrib/prometheus-exporter/README
@@ -27,7 +27,6 @@ and the corresponding HTTP proxy must enable the HTX support.
For instance:
frontend test
mode http
...
-option http-use-htx
http-request use-service prometheus-exporter if { path /metrics }
...
--
2.30.0
[PATCH 3/3] REGTESTS: contrib/prometheus-exporter: test well known labels
as we previously briefly broke labels handling, test them to make sure
we don't introduce regressions in the future.
see also commit 040b1195f70d6a24204ede081451fd1dd71e6a34 ("BUG/MINOR:
contrib/prometheus-exporter: Restart labels dump at the right pos") for
reference
Signed-off-by: William Dauchy
---
reg-tests/contrib/prometheus.vtc | 9 +
1 file changed, 9 insertions(+)
diff --git a/reg-tests/contrib/prometheus.vtc b/reg-tests/contrib/prometheus.vtc
index 1ebeb29cb..ebe0b8753 100644
--- a/reg-tests/contrib/prometheus.vtc
+++ b/reg-tests/contrib/prometheus.vtc
@@ -71,6 +71,15 @@ client c1 -connect ${h1_stats_sock} {
expect resp.body ~
".*haproxy_server_idle_connections_limit{proxy=\"be\",server=\"s1\"} NaN.*"
expect resp.body ~
".*haproxy_server_idle_connections_limit{proxy=\"be\",server=\"s2\"} 42.*"
+ # test well known labels presence
+ expect resp.body ~ ".*haproxy_process_build_info{version=\".*\"} 1.*"
+ expect resp.body ~
".*haproxy_frontend_http_responses_total{proxy=\"stats\",code=\"4xx\"} 0.*"
+ expect resp.body ~
".*haproxy_frontend_status{proxy=\"fe\",state=\"UP\"} 1.*"
+ expect resp.body ~
".*haproxy_listener_status{proxy=\"stats\",listener=\"sock-1\",state=\"WAITING\"}
0.*"
+ expect resp.body ~ ".*haproxy_backend_status{proxy=\"be\",state=\"UP\"}
1.*"
+ expect resp.body ~
".*haproxy_server_status{proxy=\"be\",server=\"s1\",state=\"DOWN\"} 0.*"
+ expect resp.body ~
".*haproxy_server_check_status{proxy=\"be\",server=\"s2\",state=\"HANA\"} 0.*"
+
# test scope
txreq -url "/metrics?scope="
rxresp
--
2.30.0
Re: Apache Proxypass mimicing ?
HI.
On 18.02.21 10:12, spfma.t...@e.mail.fr wrote:
Hi,
I would like to setup a reverse proxy with SSL termination to allow something
like :
https://front1.domain proxying http://back1.otherdomain:8000 (and maybe one day
back2)
https://front2.domain proxying http://back3.otherdomain:5000
>
Common things I already configured using Apache's mod_proxy.
I am not an HAProxy expert, I only used it in tcp mode for simple and efficient
load balancing.
I would suggest to take a look into the following articles.
https://www.haproxy.com/blog/how-to-map-domain-names-to-backend-server-pools-with-haproxy/
https://www.haproxy.com/blog/introduction-to-haproxy-maps/
I have read this very interresting article https://www.haproxy.com/fr/blog/howto-write-apache-proxypass-rules-in-haproxy/
but it seems directives belong to former versions, and I was not able to get the expected result.
>
One of my important use-case is Apache backends hosting WordPress.
There are numerous examples here and there, but I always end with URLs like https://front1.domain/wp-admin
redirected to http://front1.domain:8000/wp-admin or https://back1.otherdomain:8000/wp-admin aso ...
>
I know WP is redirecting to URLs related to it's configured URLs , so I guess some
headers rewriting are required, but I don't know how to do that.
I am looking for a generic way to perform the required rewrites, without depending
on fixed URL patterns. Is it only possible with HAProxy ? Some very old posts
suggested it was not, but there were from around nine years ago.
I have not been able to find answers so far (some search results show appealing
descriptions but sites are not responding) so I am looking for some help here.
Well you will need some pattern that the computer can follow.
For example based on which criteria should a program know what it should to on
the URL?
Request: https://front1.domain/wp-admin
Redirect to http://front1.domain:8000/wp-admin when what happen?
Send request to https://back1.otherdomain:8000/wp-admin when what happen?
I would start with that config
https://github.com/Tyrell66/SoHo/blob/master/haproxy-2020.05.02.cfg
Here a slightly adopted version.
```
frontend http-in
bind *:80
# Prevent DDoS
stick-table type ip size 100k expire 30s store http_req_rate(10s)
http-request track-sc0 src
http-request deny deny_status 429 if { sc_http_req_rate(0) gt 20 }
http-request add-header X-Forwarded-Proto http
redirect scheme https if !{ ssl_fc }
frontend https-in
# /etc/haproxy/certs/ contains both .pem for default and second domain
names.
bind *:443 ...
http-response replace-header Location ^http://(.*)$ https://\1
http-request add-header X-Forwarded-Proto https
http-request set-header X-Forwarded-Proto https
http-request set-header X-Forwarded-Port 443
capture request header X-Forwarded-For len 15
# Strip off Proxy headers to prevent HTTpoxy (https://httpoxy.org/)
http-request del-header Proxy
## Secure headers
https://blog.devcloud.hosting/securing-haproxy-and-nginx-via-http-headers-54020d460283
## Test your config with https://securityheaders.com/
## and https://observatory.mozilla.org/
http-response set-header X-XSS-Protection 1;mode=block
http-response set-header X-Content-Type-Options nosniff
http-response set-header Referrer-Policy no-referrer-when-downgrade
http-response set-header X-Frame-Options SAMEORIGIN
http-response del-header X-Powered-By
http-response del-header Server
# This line is for HSTS:
http-response set-header Strict-Transport-Security "max-age=63072000;
includeSubdomains; preload;"
use_backend %[req.hdr(host),lower,map(hosts.map,be_static)]
backend be_static
server default_static xxx.xxx.xx
backend be_domain1
http-request replace-uri ^/gc/(.*) /guacamole/\1
server host1 192.168.1.13:58080/guacamole/#
...
```
file hosts.map
```
front1.domain be_domain1
front2.domain be_domain2
```
You can also set maps for path and host with ports.
As you can see HAProxy should be able to full fill your requirement as long as
you can
define it for you and the program/Computer ;-)
Maybe this article could also help you to protect the WP installations for
attacks.
https://www.haproxy.com/blog/wordpress-cms-brute-force-protection-with-haproxy/
Thanks
Welcome
Alex
Re: [PATCH] introduce guard for SCTL openssl specific functions
On Thu, Feb 18, 2021 at 07:06:14PM +0500, Илья Шипицин wrote: > ping :) > > On Sat, Feb 13, 2021, 11:48 AM Илья Шипицин wrote: > > > I changed macro name, new patch attached > > Merged, thanks. -- William Lallemand
Re: [PATCH] introduce guard for SCTL openssl specific functions
ping :) On Sat, Feb 13, 2021, 11:48 AM Илья Шипицин wrote: > I changed macro name, new patch attached > > сб, 13 февр. 2021 г. в 03:41, William Lallemand : > >> On Sat, Feb 13, 2021 at 12:21:56AM +0500, Илья Шипицин wrote: >> > Hello, >> > >> > let as switch to feature macro instead of HA_OPENSSL_VERSION. >> > >> > Ilya >> >> Hello Ilya, >> >> For more concistency with the other macros I'd rather use >> "HAVE_SSL_SCTL" instead of "HAVE_OPENSSL_SCTL". >> >> Regards, >> >> -- >> William Lallemand >> >
Re: [PATCH] MINOR: cli: add missing agent commands for set server
Le 15/02/2021 à 17:22, William Dauchy a écrit : we previously forgot to add `agent-*` commands. Take this opportunity to rewrite the help string in a simpler way for readability (mainly removing simple quotes) Now merged, thanks ! -- Christopher Faulet
Re: [PATCH]: BUILD/MEDIUM da pcre2 support
Le 16/02/2021 à 12:47, David Carlier a écrit : Hi, Here a patch proposal to update the DeviceAtlas Detection build in order to support the pcre2 library as option. Would be nice if backported back to the supported stable releases. Now merged, thanks ! -- Christopher Faulet
Re: Segfault in liblua-5.3.so
Hi Willy,
Thanks for the response. Unfortunately we cannot reproduce this in the test
and we have disabled the reload dependent feature in production.
We will test more with the latest build and let you know.
On Sat, Feb 13, 2021 at 1:28 PM Willy Tarreau wrote:
> Hi Sachin,
>
> On Thu, Feb 11, 2021 at 03:11:09AM +0530, Sachin Shetty wrote:
> > Hi,
> >
> > We have a lua block that connects to memcache when a request arrives
> >
> > """
> > function get_from_gds(host, port, key)local sock = core.tcp()
> > sock:settimeout(20)local result = DOMAIN_NOT_FOUNDlocal
> > status, error = sock:connect(host, port)if not status then
> > core.Alert(GDS_LOG_PREFIX .. "GDS_ERROR: Error in connecting:" .. key
> > .. ":" .. port .. ":" .. error)return GDS_ERROR, "Error: " ..
> > errorendsock:send(key .. "\r\n")while true dolocal
> > s, status, partial = sock:receive("*l")if not s then
> > core.Alert(GDS_LOG_PREFIX .. "GDS_ERROR: Error reading:" .. key ..
> > ":" .. port .. ":" .. status)return GDS_ERROR, status
> > endif s == "END" then break endresult = send
> > sock:close()return resultend
> >
> > -- Comment: get_proxy calls get_from_gds
> >
> > core.register_action("get_proxy", { "http-req" }, get_proxy)
> > """
> > The value is cached in a haproxy map so we don't make a memcache
> > connection for every request.
> >
> > At peak traffic if we reload haproxy, that invalidates the map and the
> > surge causes
> > quite a few memcache connections to fail. Error returned is "Can't
> connect"
> >
> > We see the following messages in dmesg
> >
> > [ +0.006924] haproxy[14258]: segfault at 0 ip 7f117fba94c4 sp
> > 7f1179eefe08 error 4 in liblua-5.3.so[7f117fba1000+37000]
> >
> > HA-Proxy version 2.0.18-be8b761 2020/09/30 - https://haproxy.org/
>
> Unfortunately, this is not enough to figure the cause, you'll need to
> enable core dumps and to pass it through gdb to figure a more exploitable
> backtrace. Please take this opportunity for updating, as I'm seeing 117
> patches merged into 2.0 after your version, some of which affect Lua
> and others related to thread safety. One of them is even related to
> Lua+maps.
>
> Note, if that's not urgent on your side, we do have a few more fixes
> pending to be backported to 2.0 that will warrant yet another version.
> However none of them seem related to your issue (but if you're willing
> to retest with the latest 2.0 snapshot you're welcome of course).
>
> Willy
>
Apache Proxypass mimicing ?
Hi, I would like to setup a reverse proxy with SSL termination to allow something like : https://front1.domain proxying http://back1.otherdomain:8000 (and maybe one day back2) https://front2.domain proxying http://back3.otherdomain:5000 Common things I already configured using Apache's mod_proxy. I am not an HAProxy expert, I only used it in tcp mode for simple and efficient load balancing. I have read this very interresting article https://www.haproxy.com/fr/blog/howto-write-apache-proxypass-rules-in-haproxy/ but it seems directives belong to former versions, and I was not able to get the expected result. One of my important use-case is Apache backends hosting WordPress. There are numerous examples here and there, but I always end with URLs like https://front1.domain/wp-admin redirected to http://front1.domain:8000/wp-admin or https://back1.otherdomain:8000/wp-admin aso ... I know WP is redirecting to URLs related to it's configured URLs , so I guess some headers rewriting are required, but I don't know how to do that. I am looking for a generic way to perform the required rewrites, without depending on fixed URL patterns. Is it only possible with HAProxy ? Some very old posts suggested it was not, but there were from around nine years ago. I have not been able to find answers so far (some search results show appealing descriptions but sites are not responding) so I am looking for some help here. Thanks - FreeMail powered by mail.fr
