[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