Re: Odd warnings when using "option forwarded"

[Aurelien DARRAGON]

> That's interesting, because I already had `option  forwardfor except 
> 127.0.0.1` in the frontend which works perfectly.  Should that be in the 
> backend too? 

No, it's OK to use forwardfor in frontend sections since it is
historical behavior. But forwarded doesn't allow that and requires
explicit backend configuration.

> I was trying to find 'option forwarded' in the documentation, but I couldn't 
> click on it after finding it with the search box and I couldn't search all 
> the documentation with the browser, as it wasn't all on one page.

Here is the relevant config section:
https://docs.haproxy.org/dev/configuration.html#4.2-option%20forwarded

Aurelien

Re: Odd warnings when using "option forwarded"

[Aurelien DARRAGON]

Hi Shawn

On 26/04/2024 18:34, Shawn Heisey wrote:
> I was just reading about the new "option forwarded" capability in 2.9,
> so I added it to my config and now I get warnings when checking the config.
> 
> [WARNING]  (253408) : config : parsing [/etc/haproxy/haproxy.cfg:45] :
> 'option forwarded' ignored because frontend 'web80' has no backend
> capability.
> [WARNING]  (253408) : config : parsing [/etc/haproxy/haproxy.cfg:60] :
> 'option forwarded' ignored because frontend 'web' has no backend
> capability.
> 
> This is the line I added to the frontends:
> 
>     option  forwarded except 127.0.0.1
> 
> I realized I don't need it on 'web80', so I removed that one.
> 
> The 'web' frontend does use backends.  Its default backend has no
> servers and denies all requests -- the request must match one of the
> ACLs to choose a backend that actually does something.
> 
> I suspect that I can ignore this warning, but I want to check here and
> make sure.  Can I set something so it doesn't emit the warning?
> 
> Thanks,
> Shawn
> 
> 

This is expected because forwarded cannot be used on frontends unlike
the good old forwardfor:

This is expected because forwarded cannot be used on frontend unlike
forwardfor:

> -- keyword -- defaults - frontend - listen -- backend 
> -
> option forwardfor X  X X X
> option forwarded (*)  X  - X X

(excerpt from the documentation)

This was done on purpose because in practice the option is only relevant
at the backend side, and supporting forwardfor in both frontend and
backend config sections has caused multiple issues in the past because
of the added complexity (requires extra care to check for the option on
the proper section, depending if it's set in the frontend or the backend
or both...), and we wanted to get rid of that extra complexity from the
start when implementing the new forwarded option.

Thus for the option to be considered, you should add it to your default
or backend sections :)

Does that help?

Regards,
Aurelien

Re: [PATCH] DOC: configuration.txt: add log-balance documentation

[Aurelien DARRAGON]

> Got it, sorry for the noise then.

No worries, thank you for noticing it!


Regards,
Aurelien

Re: [PATCH] DOC: configuration.txt: add log-balance documentation

[Aurelien DARRAGON]

Hi Marko,

Thanks for the heads up,

In fact "log-balance" directive was removed in

> commit b61147fd2a54d4cfc1053a51e87c91cc306bb7ed
> Author: Aurelien DARRAGON 
> Date:   Wed Nov 15 11:15:50 2023 +0100
> 
> MEDIUM: log/balance: merge tcp/http algo with log ones

log load balancing may now be configured using the existing "balance"
directive for log backends as explained in the haproxy-2.9-dev10 release
note.

However I forgot to remove the "log-balance" keyword from the proxy
keyword matrix, which could explain why you thought the documentation
was missing. My bad!

Here is a complementary patch to
b61147fd2a54d4cfc1053a51e87c91cc306bb7ed to remove the documentation
leftovers for "log-balance" directive which doesn't exist anymore in the
code.

AurelienFrom 8e675f826498c5c6d8067d5a77427ee13423d89b Mon Sep 17 00:00:00 2001
From: Aurelien DARRAGON 
Date: Tue, 21 Nov 2023 11:28:26 +0100
Subject: [PATCH] DOC: config: removing "log-balance" references

"log-balance" keyword was removed by b61147f ("MEDIUM: log/balance: merge
tcp/http algo with log ones") but it was still documented.

Removing "log-balance" references in the documentation where needed.
---
 doc/configuration.txt | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index c2f30a944..414bfdc6f 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -4500,7 +4500,6 @@ id-  X X X
 ignore-persist-  - X X
 load-server-state-from-file   X  - X X
 log  (*)  X  X X X
-log-balance   X  - X X
 log-formatX  X X -
 log-format-sd X  X X -
 log-tag   X  X X X
@@ -9115,10 +9114,9 @@ mode { tcp|http|log }
   any "log" directive by using the "backend@" syntax. Log
   messages will be distributed to the servers from the backend
   according to the lb settings which can be configured using the
-  "log-balance" keyword (in place of the "balance" keyword for TCP
-  and HTTP backends). Log backends support UDP servers by prefixing
+  "balance" keyword. Log backends support UDP servers by prefixing
   the server's address with the "udp@" prefix. Common backend and
-  server features are supported, but not TCP or HTTP related ones.
+  server features are supported, but not TCP or HTTP specific ones.
 
   When doing content switching, it is mandatory that the frontend and the
   backend are in the same mode (generally HTTP), otherwise the configuration
-- 
2.34.1

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

[Aurelien DARRAGON]

> On that note, I assume the easiest is to let Willy alter the commit message 
> to update (or remove) the commit reference when merging?
> 
> Asking just in case you were waiting for me to send an amended patch for it.

Yeah I think so, and even if it's not amended, it's not dramatic: the
commit ID simply won't resolve, but we still have its name :)

Aurelien

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

[Aurelien DARRAGON]

> Overall it looks good to me as is. I'll let Aurélien have a quick look
> as well in case he sees anything but I'm personally fine with merging
> this.

Looks good to me as well, nice job Tristan :)

Just a side note regarding the comment from the 2nd patch: it's not
useful to mention the commit ID from the previous patch given that the
effective commit ID will change when the patch will be applied on top of
haproxy master branch.

Regards,
Aurelien

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

[Aurelien DARRAGON]

> https://www.arpalert.org/haproxy-api.html (related txn:log()
> documentation:
> https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#core.log)

Forgot
https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#TXN.log as
well (both txn:log(), core:log() and friends with explicit log level in
the name such as txn.Alert() end up using the hlua_sendlog() function
internally)

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

[Aurelien DARRAGON]

Hi Tristan,

Thanks for the nice work :)

Just my 2 cents, in the second patch, since you change the default
behavior, you forgot to update your comment from the 1st patch in Lua's
doc according to the new behavior:

> diff --git a/doc/lua.txt b/doc/lua.txt
> index 8d5561668..8d244ab3a 100644
> --- a/doc/lua.txt
> +++ b/doc/lua.txt
> @@ -630,6 +630,10 @@ It displays a log during the HAProxy startup:
>  
> [alert] 285/083533 (14465) : Hello World !
>  
> +Note: By default, logs originating from a LUA script are sent to the loggers
> +applicable to the current context, if any, and additionally to stderr. See
> +tune.lua.log and tune.lua.log-stderr for more information.


Note that the lua.txt file is not used much now, and mainly serves as
documentation for developers, not very useful for users. If you're
willing to reach more people you should probably maintain the
doc/lua-api/index.rst file which is used to generate the online
documentation at
https://www.arpalert.org/haproxy-api.html (related txn:log()
documentation:
https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#core.log)

For the rest, I'll leave it to Willy :)


Regards,
Aurelien

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

[Aurelien DARRAGON]

Hi Guys,

I also have a suggestion, while at it:

SEND_ERR() which is used to report unexpected Lua errors (because of
improper API usage, or due to external factors such as IO/memory issues)
currently does a stderr duplication as in hlua_sendlog()

I'm thinking that it could be useful to make this configurable too, but
maybe independently from the txn:log() (hlua_sendlog()) logic since in
this case for errors we might be more interested in stderr reporting by
default instead of regular logging?


One last thing, SEND_ERR() reports to stderr through ha_alert() and
hlua_sendlog() does it through fprintf(stderr, ) by appending a static
header containing the log level, the date and the pid: maybe we should
try to unify those outputs as well?

Aurelien

Re: sc-set-gpt with expression: internal error, unexpected rule->from=0, please report this bug!

[Aurelien DARRAGON]

>> I have no idea what causes it at the moment. A few things you could try,
>> in any order, to help locate the bug:
>>
>>   - check if it accepts it using "http-request sc-set-gpt" instead of
>> "tcp-request connection" so that we know if it's related to the ruleset
>> or something else ;
>>
> 
> Thanks, that seems to narrow the problem down.
> 
> "http-request sc-set-gpt" does work, so does "tcp-request session". I.e.
> the bug seems to depend on "tcp-request connection".
> 
> "session" works for me, for setting session variables it might even be
> necessary, but those might be avoidable by setting the conditional
> directly.
> (But not trivially since "sub()" only takes values or variables
> but not fetches and "-m int gt " only seem to takes direct
> values).

Indeed, according to both doc and code, sc-set-gpt and sc-set-gpt0 are
available from:

- tcp-request session
- tcp-request content
- tcp-response content
- http-request
- http-response
- http-after-response

But, according to the doc, they are also available from:
- tcp-request connection

But the switch-cases in parse_set_gpt(), action_set_gpt(), and
action_set_gpt0() from stick_table.c don't allow this case, so it looks
like it was forgotten indeed when the expr support was added for
sc-set-gpt0 in 0d7712dff0 ("MINOR: stick-table: allow sc-set-gpt0 to set
value from an expression").

We have the same issue for the sc-add-gpc action which was greatly
inspired from set-gpt, where the switch cases defined in parse_add_gpc()
and action_add_gpc() from stick_table.c don't allow tcp-request
connection as origin.

Please find the attached patches that should help solve the above issues.

AurelienFrom b66b401ddb36a4c686fa0df965492da204ba66a8 Mon Sep 17 00:00:00 2001
From: Aurelien DARRAGON 
Date: Wed, 9 Aug 2023 17:39:29 +0200
Subject: [PATCH 2/2] BUG/MINOR: stktable: allow sc-add-gpc from tcp-request
 connection

Following the previous commit's logic, we enable the use of sc-add-gpc
from tcp-request connection since it was probably forgotten in the first
place for sc-set-gpt0, and since sc-add-gpc was inspired from it, it also
lacks its.

As sc-add-gpc was implemented in 5a72d03a58 ("MINOR: stick-table: implement
the sc-add-gpc() action"), this should only be backported to 2.8
---
 src/stick_table.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/stick_table.c b/src/stick_table.c
index 363269f01..b11e94961 100644
--- a/src/stick_table.c
+++ b/src/stick_table.c
@@ -2913,6 +2913,7 @@ static enum act_return action_add_gpc(struct act_rule *rule, struct proxy *px,
 			value = (unsigned int)(rule->arg.gpc.value);
 		else {
 			switch (rule->from) {
+			case ACT_F_TCP_REQ_CON: smp_opt_dir = SMP_OPT_DIR_REQ; break;
 			case ACT_F_TCP_REQ_SES: smp_opt_dir = SMP_OPT_DIR_REQ; break;
 			case ACT_F_TCP_REQ_CNT: smp_opt_dir = SMP_OPT_DIR_REQ; break;
 			case ACT_F_TCP_RES_CNT: smp_opt_dir = SMP_OPT_DIR_RES; break;
@@ -3013,6 +3014,7 @@ static enum act_parse_ret parse_add_gpc(const char **args, int *arg, struct prox
 			return ACT_RET_PRS_ERR;
 
 		switch (rule->from) {
+		case ACT_F_TCP_REQ_CON: smp_val = SMP_VAL_FE_CON_ACC; break;
 		case ACT_F_TCP_REQ_SES: smp_val = SMP_VAL_FE_SES_ACC; break;
 		case ACT_F_TCP_REQ_CNT: smp_val = SMP_VAL_FE_REQ_CNT; break;
 		case ACT_F_TCP_RES_CNT: smp_val = SMP_VAL_BE_RES_CNT; break;
-- 
2.34.1

From 0b3586a30a8181316477140daf56dd3309b1f6f1 Mon Sep 17 00:00:00 2001
From: Aurelien DARRAGON 
Date: Wed, 9 Aug 2023 17:23:32 +0200
Subject: [PATCH 1/2] BUG/MINOR: stktable: allow sc-set-gpt(0) from tcp-request
 connection

Both the documentation and original developer intents seem to suggest
that sc-set-gpt/sc-set-gpt0 actions should be available from
tcp-request connection.

Yet because it was probably forgotten when expr support was added to
sc-set-gpt0 in 0d7712dff0 ("MINOR: stick-table: allow sc-set-gpt0 to
set value from an expression") it doesn't work and will report this
kind of errors:
 "internal error, unexpected rule->from=0, please report this bug!"

Fixing the code to comply with the documentation and the expected
behavior.

This must be backported to every stable versions.

[for < 2.5, as only sc-set-gpt0 existed back then, the patch must be
manually applied to skip irrelevant parts]
---
 src/stick_table.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/stick_table.c b/src/stick_table.c
index a2aa9c451..363269f01 100644
--- a/src/stick_table.c
+++ b/src/stick_table.c
@@ -2656,6 +2656,7 @@ static enum act_return action_set_gpt(struct act_rule *rule, struct proxy *px,
 			value = (unsigned int)(rule->arg.gpt.value);
 		else {
 			switch (rule->from) {
+			case ACT_F_TCP_REQ_CON: smp_opt_dir = SMP_OPT_DIR_REQ; break;
 			case ACT_F_TCP_REQ_SES: smp_opt_dir = SMP_OPT_DIR_REQ; br

Re: [PATCH] REGTESTS: Do not use REQUIRE_VERSION for HAProxy 2.5+ (3)

[Aurelien DARRAGON]

On 07/08/2023 15:46, Tim Duesterhus wrote:
> Introduced in:
> 
> 424981cde REGTEST: add ifnone-forwardfor test
> b015b3eb1 REGTEST: add RFC7239 forwarded header tests
> 
> see also:
> 
> fbbbc33df REGTESTS: Do not use REQUIRE_VERSION for HAProxy 2.5+
> ---
>  reg-tests/http-rules/forwarded-header-7239.vtc | 2 +-
>  reg-tests/http-rules/ifnone-forwardfor.vtc | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Oops indeed, wasn't aware of it, thank you Tim!

Re: haproxy -dKcnv output

[Aurelien DARRAGON]

> What I would find clear:
> 
> bool => iif(str,str) => str 


You're right Tim

But in the long term it could be great to share a common output format
with the doc as well (to find all relevant info from -dKcnv in the doc,
and vice versa)

While

> bool => iif(str,str) => str

and

> bool | iif(str,str) => str

would not fit properly with existing representation for converters
within the doc

> iif(str,str): str <= bool

and

> iif(str,str): bool => str

could be good candidates (fetches are already represented using
"name(arg) : out"), although dconv would have to be patched anyway for
this to work since it does not allow '=' nor '>' or '<' characters after
the ':' because of this regexp:

https://github.com/cbonte/haproxy-dconv/blame/4decf0b72eff0888195c2353ea149cd969110fe5/parser/keyword.py#L31

Re: haproxy -dKcnv output

[Aurelien DARRAGON]

Pardon the few typos in the previous mail

> $> haproxy -f test.conf -dKcnv | grep iif
> iif(string,string): str => bool

Replace iff with iif :)

Regards,
Aurelien

haproxy -dKcnv output

[Aurelien DARRAGON]

Dear haproxy users,

We recently noticed an inconsistency with haproxy -dKcnv output (which
may be used to dump all available sample converters from the cli).

Here is how a converter is currently being represented in -dKcnv output:

  conv_name([arg1 ...]) : output_type => input_type

For instance with the iff converter this would look like this:

> $> haproxy -f test.conf -dKcnv | grep nbsrv
> iif(string,string): str => bool


According to the documentation, iff converter returns a string, either
the first or the second argument, depending on whether the input value
(boolean expected) is true or false.

Here is the catch: with the current output format, "=>" suggests a left
to right transition. Thus it feels more logical to see input => output
instead of output => input.

Input and output were probably mixed when the feature was first
implemented and it was never updated since.

We would like to know your thoughts about this, whether you would be OK
or not with us "inverting" output_type and input_type in -dKcnv output
to remove this ambiguity for the 2.8 release:

  conv_name([arg1 ...]) : input_type => output_type

For the iff converter used as an example, this would result in the
following output being produced:

> iif(string,string): bool => str

As '-dKcnv' support was added in 2.6, we would totally understand if you
rely on the current output format and don't expect nor want it to be
changed, but we would prefer to hear it from you if this is the case.


Thank you very much,

Aurelien

Re: maint, drain: the right approach

[Aurelien DARRAGON]

Hi Matteo,

> Once the activity on the underlying service has been completed and they
> are starting up, I switch back from MAINT to READY (without waiting the
> service to be really up).
> The haproxy backend got immediately back in the roundrobin pool, even if
> the L4 and L7 checks are still validating that the underlying service is
> still DOWN (service is still starting, could take time).

I would wait for others to confirm or infirm, but meanwhile the
situation you described makes me think of an issue that was revived on
Github a few weeks ago: https://github.com/haproxy/haproxy/issues/51
(server assumed UP when leaving MAINT before the checks are performed)


Regards,
Aurelien

Re: HAProxy 2.7.7: Unexpected messages during shutdown after upgrade

[Aurelien DARRAGON]

Hi Dominik,

> The spikes seem to be fixed now
Thanks for the update!

However, we are now observing log messages during shutdown that weren’t
there before:
> 
>  
> 
> May 12, 2023 @ 11:56:24.000   Proxy health_check_http_tcp-scheduler 
> stopped (cumulated conns: FE: 0, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy http-in stopped (cumulated conns: FE: 
> 166, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy st_http_req_rate stopped (cumulated 
> conns: FE: 0, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy https-in stopped (cumulated conns: 
> FE: 29570, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy st_tcp_conn_rate stopped (cumulated 
> conns: FE: 0, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy http-routers-http2 stopped (cumulated 
> conns: FE: 0, BE: 14768).
> 
> May 12, 2023 @ 11:56:24.000   Proxy stats stopped (cumulated conns: FE: 
> 1, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy health_check_http_url stopped 
> (cumulated conns: FE: 1811, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy tcp-frontend_scheduler stopped 
> (cumulated conns: FE: 3, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy  stopped (cumulated 
> conns: FE: 0, BE: 0).
> 
> May 12, 2023 @ 11:56:24.000   Proxy tcp-scheduler stopped (cumulated 
> conns: FE: 0, BE: 3).
> 
> May 12, 2023 @ 11:56:24.000   Proxy http-routers-http1 stopped (cumulated 
> conns: FE: 0, BE: 134385).


These messages are totally inoffensive: they're only informative and are
generated each time a proxy is explicitly disabled.

As for why there weren't there before, it is probably due to this commit
which was shipped with 2.7.5:

> commit 48678e483f4f47e2a212a545399009b87503ea2d
> Author: Christopher Faulet 
> Date:   Tue Mar 14 14:33:11 2023 +0100
> 
> BUG/MEDIUM: proxy: properly stop backends on soft-stop
> 
> On soft-stop, we must properlu stop backends and not only proxies with at
> least a listener. This is mandatory in order to stop the health checks. A
> previous fix was provided to do so (ba29687bc1 "BUG/MEDIUM: proxy: 
> properly
> stop backends"). However, only stop_proxy() function was fixed. When 
> HAproxy
> is stopped, this function is no longer used. So the same kind of fix must 
> be
> done on do_soft_stop_now().
> 
> This patch partially fixes the issue #1874. It must be backported as far 
> as
> 2.4.

(prior to this commit, some of the proxies were not properly /
explicitly disabled during soft-stop)

Regards,
Aurelien

Re: AW: acl using fc_dst_port not working

[Aurelien DARRAGON]

You're welcome!

The same bug was also found in the smp_fetch_dst_is_local() function
(fc_dst_is_local sample fetch).

Attached is the patch that addresses the 2 bugs, it will probably be
included in the next batch of releases.
2.5 and 2.7 are also affected

> Unfortunately, this option doesn't work in my context, because my logs
> show that it contains a different port (not the one I need)
Oh ok :/

> But I can wait for a release with the bug fixed, it's not urgent.
Thank you for you patience :)

Aurelien
From 69aaeeb8a54e60ddd66481f91354f0d99c75ec05 Mon Sep 17 00:00:00 2001
From: Aurelien DARRAGON 
Date: Fri, 10 Mar 2023 16:53:43 +0100
Subject: [PATCH] BUG/MINOR: tcp_sample: fix a bug in fc_dst_port and
 fc_dst_is_local sample fetches

There is a bug in the function smp_fetch_dport() which affects the 'f' case, also
known as 'fc_dst_port' sample fetch.

conn_get_src() is used to retrieve the address prior to calling conn_dst().
But this is wrong: conn_get_dst() should be used instead.

Because of that, conn_dst() may return unexpected results since the dst address
is not guaranteed to be set depending on the conn state at the time the sample
fetch is used.

This was reported by Corin Langosch on the ML:

during his tests he noticed that using fc_dst_port in a log-format string
resulted in the correct value being printed in the logs but when he used it
in an ACL, the ACL did not evaluate properly.

This can be easily reproduced with the following test conf:
|frontend test-http
|  bind 127.0.0.1:8080
|  mode http
|
|  acl test fc_dst_port eq 8080
|  http-request return status 200 if test
|  http-request return status 500 if !test

A request on 127.0.0.1:8080 should normally return 200 OK, but here it
will return a 500.

The same bug was also found in smp_fetch_dst_is_local() (fc_dst_is_local sample
fetch) by reading the code: the fix was applied twice.

This needs to be backported up to 2.5
[both sample fetches were introduced in 2.5 with 888cd70 ("MINOR: tcp-sample:
Add samples to get original info about client connection")]
---
 src/tcp_sample.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/tcp_sample.c b/src/tcp_sample.c
index 925b93291..12eb25c4e 100644
--- a/src/tcp_sample.c
+++ b/src/tcp_sample.c
@@ -176,7 +176,7 @@ int smp_fetch_dst_is_local(const struct arg *args, struct sample *smp, const cha
 	if (kw[0] == 'f') { /* fc_dst_is_local */
 		struct connection *conn = objt_conn(smp->sess->origin);
 
-		if (conn && conn_get_src(conn))
+		if (conn && conn_get_dst(conn))
 			dst = conn_dst(conn);
 	}
 	else /* dst_is_local */
@@ -232,10 +232,10 @@ smp_fetch_dport(const struct arg *args, struct sample *smp, const char *kw, void
 		if (conn && conn_get_dst(conn))
 			dst = conn_dst(conn);
 	}
-	else if (kw[0] == 'f') { /* fc_dst_post */
+	else if (kw[0] == 'f') { /* fc_dst_port */
 		struct connection *conn = objt_conn(smp->sess->origin);
 
-		if (conn && conn_get_src(conn))
+		if (conn && conn_get_dst(conn))
 			dst = conn_dst(conn);
 	}
 else /* dst_port */
-- 
2.34.1

Re: acl using fc_dst_port not working

[Aurelien DARRAGON]

Hi,

> During my tests I can see in the logs that fc_dst_port is 8080. However,
> the ACL isn't set to true. If I try the same with "acl test
> fc_dst 127.0.0.2" it works as expected. However, this is not what I
> need. I also tried different matchers like "acl test fc_dst_port -m int
> 8080", "acl test fc_dst_port -m str 8080", "acl test fc_dst_port eq
> 8080" but nothing works. What am I doing wrong? Or is it a bug? haproxy
> version is 2.6.7-c55bfdb. Thank you for any help.
> 
> Corin


Indeed, there is a bug in the function smp_fetch_dport(): conn_get_src()
is used where conn_get_dst() should be used instead.

> diff --git a/src/tcp_sample.c b/src/tcp_sample.c
> index 925b93291..45a8e0f38 100644
> --- a/src/tcp_sample.c
> +++ b/src/tcp_sample.c
> @@ -235,7 +235,7 @@ smp_fetch_dport(const struct arg *args, struct sample 
> *smp, const char *kw, void
>   else if (kw[0] == 'f') { /* fc_dst_post */
>   struct connection *conn = objt_conn(smp->sess->origin);
>  
> - if (conn && conn_get_src(conn))
> + if (conn && conn_get_dst(conn))
>   dst = conn_dst(conn);
>   }
>  else /* dst_port */


Thank you for telling us, I'm working on the patch
Meanwhile, maybe "dst_port" could work as a workaround depending on your
needs?

Regards,
Aurelien

Re: stick-table replication not working anymore after Version-Upgrade

[Aurelien DARRAGON]

> Yes, your assumption is correct. I've now added "localpeer" global
> option to the config to make this more robust/more independent from
the OS.
Glad to know you were able to work around it.
Thanks for confirming

Regards,
Aurelien

Re: stick-table replication not working anymore after Version-Upgrade

[Aurelien DARRAGON]

> In the HAProxy configuration i'm using the FQDN name, and it seems
> HAProxy is just using the short hostname.
This seems to be true indeed, "localpeer" default value is retrieved
thanks to gethostname() in haproxy

However, since no obvious changes around "localpeer" handling occurred
between 2.4.15 and 2.4.22 it looks like your previous system (ubuntu
18.04) behaved differently and used to return "s017.domain.local" with
gethostname() and 'hostname' command (without the -f)

(Please note that hostname command relies on uname() internally, and not
on gethostname(), but the manual confirms that hostname command without
arguments "will print the name of the system as returned by the
gethostname(2) function.")

Could you confirm?

Thanks

Re: MQTT mqtt_field_value for CONNACK messages

[Aurelien DARRAGON]

Hi,

> log-format "%{+Q}[var(txn.pv)]"

Could you please try adding %B to your log-format string as well?
example:
> log-format "%{+Q}[var(txn.pv)] (%B)"

What I suspect is that the logline is builded before the tcp-response
rules are actually evaluated.
Some haproxy log format specifiers/variables add the LW_BYTES flag to
px->to_log to prevent the log from being emitted too early (ie: if some
of the variables depend on the response: %B, %TR...), but as far as I
know this flag cannot be set manually when using custom log-format
variables.

Adding "%B" or response-oriented log variables (that enables LW_BYTES
flag) to your custom log-format should act as a workaround to make sure
the logline is builded after the response rules have been evaluated
(at the end of the session, unless "option logasap" is specified).

Regards,
Aurelien

Re: question for issue

[Aurelien DARRAGON]

Hi Massimiliano,

> i see ,
>
> https://www.haproxy.org/download/2.0/src/
> 

>
>
> but there is not the rpm version for doing
>
> a yum localinstall ?
>
>
> thanx a lot

Using http://haproxy.org/download you will only get access to haproxy
source code for manual compiling.

You might want to take a look at
https://github.com/haproxy/wiki/wiki/Packages if you're looking for
precompiled packages for your system.

Regards,
Aurelien

Re: Issues with dynamic inserted servers

[Aurelien DARRAGON]

> In fact at some point I had a backend with 5 srv from config + 3
> dynamically inserted. Those new ones got about 50 requests pushed to
> them, until they reaches the slowstart delay(I think, must investigate
> more), when they stopped being selected for new connection. The status
> was L7OK for the 8 srv regardless of the way they arrived.
You're right, I made the same observation during the tests but I forgot
to mention it:
A server that is in STARTING phase is immune to this issue: it only
occurs when server state is RUNNING (either when no slowstart delay is
specified, or at the end of the slowstart period if specified)

Also, last observation: if you remove the maxconn on a "buggy" server
(that previously had the maxconn set using the cli):

echo "set maxconn server farm/t1 0" | nc -U /tmp/ha.sock

The issue is gone: you can set the maxconn back to a positive value
without problems.

I'll keep investigating by looking at the code :)

Re: Issues with dynamic inserted servers

[Aurelien DARRAGON]

Hi,

I don't know if it could help, but based on Thomas instructions/example,
I'm able to reproduce:

As weird as it may seem, the 'maxconn' parameter used with dynamic
server seems to trigger the issue.

Below is a minimal reproducer:


> global
>   stats socket /tmp/ha.sock mode 660 level admin expose-fd listeners
>
> defaults
> timeout client 5s
> timeout server 5s
> timeout connect 5s
>
> frontend test
>   mode http
>   bind *:8081
>   use_backend farm
>
> listen dummyok
>   bind localhost:18999
>   mode http
>   http-request return status 200 hdr test "ok"
>
> backend farm
>   mode http


(it doesn't matter if the backend starts with empty server list)


Step 1 (optional), test the reference behavior without maxconn:

Start haproxy and perform the following :

echo "add server farm/t1 127.0.0.1:18999" | nc -U /tmp/ha.sock
echo "enable server farm/t1" | nc -U /tmp/ha.sock

curl localhost:8081 -> OK


Step 2, compare behavior when maxconn is in play:

Start haproxy and perform the following :

echo "add server farm/t1 127.0.0.1:18999 maxconn 100" | nc -U /tmp/ha.sock
echo "enable server farm/t1" | nc -U /tmp/ha.sock

curl localhost:8081 -> 503 after 5s connect timeout


Regards,
Aurelien

Re: Haproxy (2.2.26) Wont Start - cannot find default_backend

[Aurelien DARRAGON]

Hi,

> I am having trouble with Haproxy using a configuration was previously
> worked and am getting a very odd to me error
>
>
>
> Jan 11 13:58:00 ca04vlhaproxy01 haproxy[16077]: [ALERT] 010/135800
> (16077) : Proxy 'graylog_back': unable to find required default_backend:
> '#002'.

You might want to manually update your haproxy from the tip of 2.2
branch while waiting for a new version:

A regression only affecting 2.2.26 was recently discovered (see below),
and the fix is available on top of 2.2.26
(https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=a7d662bda95c33131126b2ad45bbb073d93b85d3)


Regards,
Aurelien

> On 05/01/2023 14:44, Christopher Faulet wrote:
>> Le 1/5/23 à 13:20, Julien Thomas a écrit :
>>> Hello,
>>>
>>> I have an issue with haproxy 2.2.26 that I do not have in 2.2.25, it
>>> seams to be related to the ring object I use in my configuration for
>>> logs.
>>>
>>> I do not think it is due to my build
>>> (https://github.com/zenetys/rpm-haproxy/commits/haproxy22z) because we
>>> did not change it in that branch.
>>>
>>> I get "unable to find required use_backend: ''" errors.
>>>
>>> [root@zelk-prod-01 haproxy]# haproxy -f
>>> /etc/haproxy/haproxy-extract.cfg -c
>>> [NOTICE] 004/130824 (2015177) : haproxy version is 2.2.26-97059ba
>>> [NOTICE] 004/130824 (2015177) : path to executable is /usr/sbin/haproxy
>>> [ALERT] 004/130824 (2015177) : Proxy 'ft_rsyslog_514': unable to find
>>> required use_backend: ''.
>>> [ALERT] 004/130824 (2015177) : Fatal errors found in configuration.
>>>
>>
>> Thanks for the report! Indeed, there is a bug, specific to the 2.2.26. A
>> regression was introduced when the commit 7af321580 ("BUG/MEDIUM: sink:
>> bad init sequence on tcp sink from a ring.") was backported.
>>
>> I pushed a fix.
> 
> Thank you Christopher, it's working like a charm with your patch 
> 
> Julien
> 

Re: Blocking IO in "lua tasks"

[Aurelien DARRAGON]

I really appreciate the response. This confirms, that "everything in 
runtime mode" uses the same thread pool as HTTP workers. This also says 
that the onlytime we can use "blocking IO" is in "initialization mode", 
ie, at HAproxy startup/reloads.


Happy to help!

Considering what we've already established in this email, it looks like 
HAProxy has no way to serve a "static file" which changes after HAproxy 
has been initialized. @Aurelien, please confirm! This seems like a  big 
limitation, there has to be a workaround. Is it just acceptable in 
HAproxy world to "reload instead", every time a file is modified on disk?


Right now I can think about 2 different options:

You could have a basic webserver on the host serving those files locally 
via HTTP.
And from your task use core.httpclient to safely fetch/parse the file 
and update your global variable periodically.


Or

Register a custom cli from lua script (core.register_cli).
Then from a custom system script watch for files changes (or check 
periodically), and when updating is required, use local haproxy

stats socket from your script to execute your custom lua cli
that is in charge of updating the global variable.
(Passing arguments to custom lua cli is supported)
Note: Alternatively this solution can be implemented with lua service + 
local curl/wget with payload from the system script to trigger the service.


But if anyone out there knows about a better approach, please feel free 
to share your thoughts on this.



The only non-blocking functions available to use is via "socket class".
Is it too crazy if we use "socket object" to do network IO to a process
we write that acts as a proxy to do disk operations? 



Considering SPOE requires much more efforts to setup compared to lua,
depending on your needs you could consider sticking to lua coupled with 
a basic tcp or http middleware that does the file to tcp/http proxy 
(either existing webserver or custom script using socat/netcat).


Aurelien

Re: Blocking IO in "lua tasks"

[Aurelien DARRAGON]

Hi,

it feels like that shouldn't be true for "background tasks" as it is 
mentioned that they run in separate threads
That's not 100% true. Lua tasks do run concurrently with the rest of 
HAProxy processing.
But they don't run in separate "threads": they run in separate haproxy 
tasks.

What this mean is that lua task must follow haproxy task constraints:

Within HAProxy, a task is implemented as a function that gets called 
from the scheduler.

If the function needs to wait for some event/data to continue processing,
it must give the hand back and might be rescheduled later to continue 
processing.

If the function fails to do so (blocks for too long), haproxy watchdog
will suspect that a thread is stuck, and will cause the whole process to 
crash unconditionally.

That is because of HAProxy event-driven nature.

From lua task:

 * core.* methods do respect this constraint
 * io.* methods don't


This example 
 was 
linked on the arpalert.org  website but it seems 
to use *"io.* methods in runtime"*.
To demonstrate this, I used the example you provided (lua task that uses 
io.* methods),
and I modified it to make sure IO calls were blocking (ie: trying to 
read from /dev/zero):

https://gist.github.com/Darlelet/5768628e40c0d960fce8c20649877e12

It does not take long for the watchdog to trigger and crash the process.

Thus, if you were to use io.* from Lua task, you could be fine for some 
time, but as long
as some io takes too long due to io.* blocking nature (and it will 
happen), you

would cause the whole process to fail.

I would highly recommend sticking to core.add_acl/core.del_acl for acl 
management from lua task.
Maybe you could also leverage haproxy stats socket directly from the 
task using core.tcp facility if

core.add_acl/core.del_acl is not what you're looking for.

Regards,
Aurelien