Re: [PATCH] DOC: config: fix error-log-format example
On Thu, Dec 09, 2021 at 01:27:14AM +0100, Lukas Tribus wrote:
> In commit 6f7497616 ("MEDIUM: connection: rename fc_conn_err and
> bc_conn_err to fc_err and bc_err"), fc_conn_err became fc_err, so
> update this example.
Ah good catch! Both patches applied now, thank you Lukas!
Willy
[PATCH] DOC: config: fix error-log-format example
In commit 6f7497616 ("MEDIUM: connection: rename fc_conn_err and
bc_conn_err to fc_err and bc_err"), fc_conn_err became fc_err, so
update this example.
---
Should be backported to 2.5.
---
doc/configuration.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 1e049012b..b8a40d574 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -21405,7 +21405,7 @@ would have passed through a successful stream, hence
will be available as
regular traffic log (see option httplog or option httpslog).
# detailed frontend connection error log
- error-log-format "%ci:%cp [%tr] %ft %ac/%fc %[fc_conn_err]/\
+ error-log-format "%ci:%cp [%tr] %ft %ac/%fc %[fc_err]/\
%[ssl_fc_err,hex]/%[ssl_c_err]/%[ssl_c_ca_err]/%[ssl_fc_is_resumed] \
%[ssl_fc_sni]/%sslv/%sslc"
--
2.17.1
Re: [PATCH] DOC: config: retry-on list is space-delimited
Hello, On Wed, 8 Dec 2021 at 17:50, Tim Düsterhus wrote: > > Lukas, > > On 12/8/21 11:33 AM, Lukas Tribus wrote: > > We are using comma-delimited list for init-addr for example, let's > > document that this is space-delimited to avoid the guessing game. > > Shouldn't this rather be fixed by unifying the delimiter instead of > updating the docs? e.g. add support for the comma as the delimiter and > then deprecate the use of spaces with a warning? I agree, but I'm also not able to contribute more than a doc change here. Also there is more than just those 2 uses of lists, here just a few, certainly incomplete, some space delimited, some comma delimited, some undocumented: user/group ssl-engine [algo] wurfl-information-list []* 51degrees-property-name-list [ ...] So first of all we would have to find all existing lists users in the haproxy configuration and then make a determination about what to do (and which parts to touch). That requires more work than a single line doc patch, which is all I can contribute at the moment. Lukas
Re: [PATCH] DOC: config: retry-on list is space-delimited
On Wed, Dec 08, 2021 at 05:50:50PM +0100, Tim Düsterhus wrote: > Lukas, > > On 12/8/21 11:33 AM, Lukas Tribus wrote: > > We are using comma-delimited list for init-addr for example, let's > > document that this is space-delimited to avoid the guessing game. > > Shouldn't this rather be fixed by unifying the delimiter instead of updating > the docs? e.g. add support for the comma as the delimiter and then deprecate > the use of spaces with a warning? This would indeed be an improvement but at the very least we need to merge Lukas' patch so that the doc reflects how to deal with current deployments. Willy
Re: [PATCH] DOC: config: retry-on list is space-delimited
Lukas, On 12/8/21 11:33 AM, Lukas Tribus wrote: We are using comma-delimited list for init-addr for example, let's document that this is space-delimited to avoid the guessing game. Shouldn't this rather be fixed by unifying the delimiter instead of updating the docs? e.g. add support for the comma as the delimiter and then deprecate the use of spaces with a warning? Best regards Tim DÜsterhus
Re: [ANNOUNCE] haproxy-2.5.0
Hello Cyril, On Tue, 23 Nov 2021 at 17:18, Willy Tarreau wrote: > > Hi, > > HAProxy 2.5.0 was released on 2021/11/23. It added 9 new commits after > version 2.5-dev15, fixing minor last-minute details (bind warnings > that turned to errors, and an incorrect free in the backend SSL cache). could you run haproxy-dconv for haproxy 2.5 again? The last update is from May and lots of doc updates (regarding new features) have been submitted since then. You could also add the new 2.6-dev branch at that point. Thank you! Lukas
Re: [PATCH] BUILD: unbreak the build with newer libressl
ср, 8 дек. 2021 г. в 17:40, Daniel Jakots :
> Hey Ilya,
>
> Unfortunately, vtest isn't ported on OpenBSD and I try to avoid
> building software outside of the ports tree. That said, I think it
> could be useful for libressl devs to check haproxy regress test so I'll
> look into making a port for vtest.
>
> While checking the mailing list for other submission to see if I was
> doing the correct thing, I saw your
>
> [PATC H] adjust vtc for cert revocation check
> https://www.mail-archive.com/haproxy@formilux.org/msg41553.html
>
> Is the regression test you're talking about addressed by this patch of
> yours?
>
>
> Either way, can you share with me the output of the regression tests?
> (privately or not)
> I'll ask a friendly libressl developers about it :)
>
your patch makes sense.
my question is not related to your patch directly but rather to openbsd
"porting" process.
I'll share details privately to split email threads.
>
> Cheers,
> Daniel
>
> On Wed, 8 Dec 2021 09:11:01 +0500, Илья Шипицин
> wrote:
>
> > Daniel, can you try regtests ?
> > reg-tests/ssl/ssl_client_samples.vtc is failing for me on the latest
> > LibreSSL
> >
> > ср, 8 дек. 2021 г. в 06:37, Daniel Jakots :
> >
> > > Hi,
> > >
> > > Here's the file inline generated with `git format-patch -1`. Is it
> > > ok?
> > >
> > > I'm not subscribed to the mailing list, please keep me in Cc:.
> > >
> > > Thanks,
> > > Daniel
> > >
> > > From bc44099cb32a95d3a8895a6232b5b0ce5c9cb5c0 Mon Sep 17 00:00:00
> > > 2001 From: Daniel Jakots
> > > Date: Sun, 5 Dec 2021 17:30:57 -0500
> > > Subject: [PATCH] BUILD: unbreak the build with newer libressl
> > >
> > > In LibreSSL 3.5.0, BIO is going to become opaque, so haproxy's
> > > compat macros will no longer work. The functions they substitute
> > > have been available since LibreSSL 2.7.0.
> > > ---
> > > include/haproxy/openssl-compat.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/haproxy/openssl-compat.h
> > > b/include/haproxy/openssl-compat.h
> > > index 17d073d51..123b76ede 100644
> > > --- a/include/haproxy/openssl-compat.h
> > > +++ b/include/haproxy/openssl-compat.h
> > > @@ -417,7 +417,7 @@ static inline X509
> > > *X509_STORE_CTX_get0_cert(X509_STORE_CTX *ctx)
> > > #define SSL_CTX_get_extra_chain_certs(ctx, chain) do { *(chain) =
> > > (ctx)->extra_certs; } while (0)
> > > #endif
> > >
> > > -#if HA_OPENSSL_VERSION_NUMBER < 0x1010L
> > > +#if HA_OPENSSL_VERSION_NUMBER < 0x1010L &&
> > > (!defined(LIBRESSL_VERSION_NUMBER) || LIBRESSL_VERSION_NUMBER <
> > > 0x207fL) #define BIO_get_data(b)(b)->ptr
> > > #define BIO_set_data(b, v) do { (b)->ptr = (v); } while
> > > (0) #define BIO_set_init(b, v) do { (b)->init = (v); }
> > > while (0) --
> > > 2.32.0
> > >
> > >
> > >
>
>
Re: [PATCH] BUILD: unbreak the build with newer libressl
Hey Ilya,
Unfortunately, vtest isn't ported on OpenBSD and I try to avoid
building software outside of the ports tree. That said, I think it
could be useful for libressl devs to check haproxy regress test so I'll
look into making a port for vtest.
While checking the mailing list for other submission to see if I was
doing the correct thing, I saw your
[PATC H] adjust vtc for cert revocation check
https://www.mail-archive.com/haproxy@formilux.org/msg41553.html
Is the regression test you're talking about addressed by this patch of
yours?
Either way, can you share with me the output of the regression tests?
(privately or not)
I'll ask a friendly libressl developers about it :)
Cheers,
Daniel
On Wed, 8 Dec 2021 09:11:01 +0500, Илья Шипицин
wrote:
> Daniel, can you try regtests ?
> reg-tests/ssl/ssl_client_samples.vtc is failing for me on the latest
> LibreSSL
>
> ср, 8 дек. 2021 г. в 06:37, Daniel Jakots :
>
> > Hi,
> >
> > Here's the file inline generated with `git format-patch -1`. Is it
> > ok?
> >
> > I'm not subscribed to the mailing list, please keep me in Cc:.
> >
> > Thanks,
> > Daniel
> >
> > From bc44099cb32a95d3a8895a6232b5b0ce5c9cb5c0 Mon Sep 17 00:00:00
> > 2001 From: Daniel Jakots
> > Date: Sun, 5 Dec 2021 17:30:57 -0500
> > Subject: [PATCH] BUILD: unbreak the build with newer libressl
> >
> > In LibreSSL 3.5.0, BIO is going to become opaque, so haproxy's
> > compat macros will no longer work. The functions they substitute
> > have been available since LibreSSL 2.7.0.
> > ---
> > include/haproxy/openssl-compat.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/haproxy/openssl-compat.h
> > b/include/haproxy/openssl-compat.h
> > index 17d073d51..123b76ede 100644
> > --- a/include/haproxy/openssl-compat.h
> > +++ b/include/haproxy/openssl-compat.h
> > @@ -417,7 +417,7 @@ static inline X509
> > *X509_STORE_CTX_get0_cert(X509_STORE_CTX *ctx)
> > #define SSL_CTX_get_extra_chain_certs(ctx, chain) do { *(chain) =
> > (ctx)->extra_certs; } while (0)
> > #endif
> >
> > -#if HA_OPENSSL_VERSION_NUMBER < 0x1010L
> > +#if HA_OPENSSL_VERSION_NUMBER < 0x1010L &&
> > (!defined(LIBRESSL_VERSION_NUMBER) || LIBRESSL_VERSION_NUMBER <
> > 0x207fL) #define BIO_get_data(b)(b)->ptr
> > #define BIO_set_data(b, v) do { (b)->ptr = (v); } while
> > (0) #define BIO_set_init(b, v) do { (b)->init = (v); }
> > while (0) --
> > 2.32.0
> >
> >
> >
Re: Is it expected that "capture response" does not get headers when "http-request return" is used
On 08.12.21 10:20, Christopher Faulet wrote:
Le 12/6/21 à 08:25, Christopher Faulet a écrit :
Le 12/4/21 à 13:25, Aleksandar Lazic a écrit :
Hi.
I try to capture the response header "dst_conn" from "http-request return" but
in %hs isn't the value.
```
podman logs -f haproxy-dest
[NOTICE] (1) : New worker #1 (3) forked
<6>[04/Dec/2021:12:14:34.437] 200 58 - - LR-- {} "GET / HTTP/1.1"
<6>[04/Dec/2021:12:14:34.437] 200 58 - - LR-- {} "GET / HTTP/1.1"
<6>[04/Dec/2021:12:14:34.438] 200 58 - - LR-- {} "GET / HTTP/1.1"
```
I haven't seen any "capture" in "http-after-response".
The question is also makes sense to have a capture after "http-request return"
as in the documenation is
written that return stops the evaluation of any other rules also from capture?
http://cbonte.github.io/haproxy-dconv/2.4/configuration.html#http-response%20return
"This stops the evaluation of the rules and immediately returns a response."
Hi Alex,
Unfortunately, it is indeed not possible for now. First, the captures via
"capture request" and "capture response" directives are performed very early,
and on received messages only. Thus it is not possible to capture info from
generated responses at this stage. However, it is probably possible to add a
"capture" action to the "http-afer-response" ruleset. This would able to you to
capture your header with the following config:
declare capture response len 4
http-after-response capture hdr(dst_conn) id 0
At first glance it seems trivial. I will check that.
Hi,
I added it to 2.6-DEV. The patch is small enough to be backported to 2.5.
Cool thank you.
[PATCH] DOC: config: retry-on list is space-delimited
We are using comma-delimited list for init-addr for example, let's document that this is space-delimited to avoid the guessing game. --- doc/configuration.txt | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 1e049012b..c810fa918 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -10124,17 +10124,18 @@ retries See also : "option redispatch" -retry-on [list of keywords] +retry-on [space-delimited list of keywords] Specify when to attempt to automatically retry a failed request. This setting is only valid when "mode" is set to http and is silently ignored otherwise. May be used in sections:defaults | frontend | listen | backend yes |no| yes | yes Arguments : - is a list of keywords or HTTP status codes, each representing a -type of failure event on which an attempt to retry the request -is desired. Please read the notes at the bottom before changing -this setting. The following keywords are supported : + is a space-delimited list of keywords or HTTP status codes, each +representing a type of failure event on which an attempt to +retry the request is desired. Please read the notes at the +bottom before changing this setting. The following keywords are +supported : none never retry @@ -10207,6 +10208,9 @@ retry-on [list of keywords] The default is "conn-failure". + Example: +retry-on 503 504 + See also: "retries", "option redispatch", "tune.bufsize" server [:[port]] [param*] -- 2.17.1
Re: Is it expected that "capture response" does not get headers when "http-request return" is used
Le 12/6/21 à 08:25, Christopher Faulet a écrit :
Le 12/4/21 à 13:25, Aleksandar Lazic a écrit :
Hi.
I try to capture the response header "dst_conn" from "http-request return" but
in %hs isn't the value.
```
podman logs -f haproxy-dest
[NOTICE] (1) : New worker #1 (3) forked
<6>[04/Dec/2021:12:14:34.437] 200 58 - - LR-- {} "GET / HTTP/1.1"
<6>[04/Dec/2021:12:14:34.437] 200 58 - - LR-- {} "GET / HTTP/1.1"
<6>[04/Dec/2021:12:14:34.438] 200 58 - - LR-- {} "GET / HTTP/1.1"
```
I haven't seen any "capture" in "http-after-response".
The question is also makes sense to have a capture after "http-request return"
as in the documenation is
written that return stops the evaluation of any other rules also from capture?
http://cbonte.github.io/haproxy-dconv/2.4/configuration.html#http-response%20return
"This stops the evaluation of the rules and immediately returns a response."
Hi Alex,
Unfortunately, it is indeed not possible for now. First, the captures via
"capture request" and "capture response" directives are performed very early,
and on received messages only. Thus it is not possible to capture info from
generated responses at this stage. However, it is probably possible to add a
"capture" action to the "http-afer-response" ruleset. This would able to you to
capture your header with the following config:
declare capture response len 4
http-after-response capture hdr(dst_conn) id 0
At first glance it seems trivial. I will check that.
Hi,
I added it to 2.6-DEV. The patch is small enough to be backported to 2.5.
--
Christopher Faulet
I need guest post on your website-https://us-cert.cisa.gov
What is guest post price at-https://us-cert.cisa.gov I am waiting for your good reply Thanks
Re: Help with peer setup and "srv_conn(bk_customer/haproxy-dest1)"
Hi. Anyone which can help to protect the backen with backend states? Regards Alex On 05.12.21 11:42, Aleksandar Lazic wrote: Hi. I try to protect an backend server against a overload within a master/master setup. The test setup looks like this lb1: 8081 \ -hap-dest: 8080 lb2: 8082 / When I now call lb1 with curl the "tracker/quota1" gpc is increased and the second request is denied. The problem is that the peer on lb2 does not get the counter data to protect the backend on lb2 too. Please can anybody help me to fix my mistake and find a proper solution. ``` curl -v http://127.0.0.1:8081/; curl -v http://127.0.0.1:8081 * Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0) > GET / HTTP/1.1 > Host: 127.0.0.1:8081 > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < dest_dst_conn: 1 < content-length: 0 < * Connection #0 to host 127.0.0.1 left intact * Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0) > GET / HTTP/1.1 > Host: 127.0.0.1:8081 < HTTP/1.1 403 Forbidden < content-length: 93 < cache-control: no-cache < content-type: text/html ``` ``` lb1 echo "show peers;show table tracker/quota1;show table tracker/quota2"|socat - tcp4-connect:127.0.0.1:9990 0x55bb71554dc0: [05/Dec/2021:10:27:17] id=tracker disabled=0 flags=0x33 resync_timeout= task_calls=5 0x55bb71558350: id=tracker(remote,inactive) addr=127.0.0.1:20001 last_status=NAME last_hdshk=5m36s reconnect= heartbeat= confirm=0 tx_hbt=0 rx_hbt=0 no_hbt=0 new_conn=1 proto_err=0 coll=0 flags=0x0 shared tables: 0x55bb7156f1e0 local_id=2 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x55bb71556a50 id=tracker/quota1 update=3 localupdate=3 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict") 0x55bb7156f090 local_id=1 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x55bb71556c60 id=tracker/quota2 update=2 localupdate=2 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict") 0x55bb71557300: id=h1(local,inactive) addr=127.0.0.1:2 last_status=NONE last_hdshk= reconnect= heartbeat= confirm=0 tx_hbt=0 rx_hbt=0 no_hbt=0 new_conn=0 proto_err=0 coll=0 flags=0x0 shared tables: 0x55bb7156f230 local_id=2 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x55bb71556a50 id=tracker/quota1 update=3 localupdate=3 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict") 0x55bb7156f0e0 local_id=1 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x55bb71556c60 id=tracker/quota2 update=2 localupdate=2 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict") # table: tracker/quota1, type: string, size:100, used:1 0x55bb71772888: key=0 use=0 exp=53297 server_id=0 gpc0=1 # table: tracker/quota2, type: string, size:100, used:1 0x55bb71772958: key=0 use=0 exp=53297 server_id=0 gpc1=0 ``` ``` lb2 echo "show peers;show table tracker/quota1;show table tracker/quota2"|socat - tcp4-connect:127.0.0.1:9991 0x5618ae836dc0: [05/Dec/2021:10:27:12] id=tracker disabled=0 flags=0x33 resync_timeout= task_calls=5 0x5618ae83a350: id=tracker(remote,inactive) addr=127.0.0.1:2 last_status=NAME last_hdshk=5m31s reconnect= heartbeat= confirm=0 tx_hbt=0 rx_hbt=0 no_hbt=0 new_conn=2 proto_err=0 coll=0 flags=0x0 shared tables: 0x5618ae8511e0 local_id=2 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x5618ae838a50 id=tracker/quota1 update=0 localupdate=0 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict") 0x5618ae851090 local_id=1 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x5618ae838c60 id=tracker/quota2 update=0 localupdate=0 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict") 0x5618ae839300: id=h2(local,inactive) addr=127.0.0.1:20001 last_status=NONE last_hdshk= reconnect= heartbeat= confirm=0 tx_hbt=0 rx_hbt=0 no_hbt=0 new_conn=0 proto_err=0 coll=0 flags=0x0 shared tables: 0x5618ae851230 local_id=2 remote_id=0 flags=0x0 remote_data=0x0 last_acked=0 last_pushed=0 last_get=0 teaching_origin=0 update=0 table:0x5618ae838a50 id=tracker/quota1 update=0 localupdate=0 commitupdate=0 refcnt=1 Dictionary cache not dumped (use "show peers dict")
