Re: [PATCH] MINOR: tcp_sample: extend support for get_tcp_info to OpenBSD
On 8/23/2022 11:22 PM, Willy Tarreau wrote:
On Tue, Aug 23, 2022 at 10:37:28PM -0400, Brad Smith wrote:
On 8/23/2022 10:22 PM, Willy Tarreau wrote:
Hi Brad,
On Sat, Aug 13, 2022 at 11:25:32PM -0400, Brad Smith wrote:
I'm not sure if MINOR is right. Currently the build is broken since TCP_INFO
was added.
Just to be certain, you mean the build is broken without your patch or
with it ? If it's broken without, it means that your patch is a build
fix, but it also indicates there's something wrong in the whole code's
arrangement there that we'll have to re-adjust, because we must not
break things for operating systems that are not explicitely handled.
The build is broken without the diff. I was looking at older releases and
this
only affects 2.7 and 2.6.
It looks like this changed things in such a way that if TCP_INFO is added
but the OS is not added to the list of OS's it will not build.
http://git.haproxy.org/?p=haproxy-2.6.git;a=commitdiff;h=5c83e3a1563cd7face299bf08037e51f976eb5e3;hp=39e436e36c4e6c0efe95c304fe89fd01e111
Oh I see... What a mess! Thanks for the clarifiation.
I'll merge your patch as a build fix and with such indications. It's
suitable for backporting. As a next step for 2.7 and further, we should
change this to have a new USE_TCP_INFO build options that will be set
by default in the makefile for supported operating systems and tested
instead of testing all OS combinations.
If you want to work on this, you're welcome :-)
BTW, the exact error is..
src/tcp_sample.c:503:24: fatal error: use of undeclared identifier
'smp_fetch_fc_rtt'
{ "fc_rtt", smp_fetch_fc_rtt, ARG1(0,STR),
val_fc_time_value, SMP_T_SINT, SMP_USE_L4CLI },
^
1 error generated.
Re: [PATCH] MINOR: tcp_sample: extend support for get_tcp_info to OpenBSD
On Tue, Aug 23, 2022 at 10:37:28PM -0400, Brad Smith wrote: > On 8/23/2022 10:22 PM, Willy Tarreau wrote: > > Hi Brad, > > > > On Sat, Aug 13, 2022 at 11:25:32PM -0400, Brad Smith wrote: > > > I'm not sure if MINOR is right. Currently the build is broken since > > > TCP_INFO > > > was added. > > Just to be certain, you mean the build is broken without your patch or > > with it ? If it's broken without, it means that your patch is a build > > fix, but it also indicates there's something wrong in the whole code's > > arrangement there that we'll have to re-adjust, because we must not > > break things for operating systems that are not explicitely handled. > > The build is broken without the diff. I was looking at older releases and > this > only affects 2.7 and 2.6. > > It looks like this changed things in such a way that if TCP_INFO is added > but the OS is not added to the list of OS's it will not build. > > http://git.haproxy.org/?p=haproxy-2.6.git;a=commitdiff;h=5c83e3a1563cd7face299bf08037e51f976eb5e3;hp=39e436e36c4e6c0efe95c304fe89fd01e111 Oh I see... What a mess! Thanks for the clarifiation. I'll merge your patch as a build fix and with such indications. It's suitable for backporting. As a next step for 2.7 and further, we should change this to have a new USE_TCP_INFO build options that will be set by default in the makefile for supported operating systems and tested instead of testing all OS combinations. If you want to work on this, you're welcome :-) Thanks! Willy
Re: [PATCH] MINOR: tcp_sample: extend support for get_tcp_info to OpenBSD
On 8/23/2022 10:22 PM, Willy Tarreau wrote: Hi Brad, On Sat, Aug 13, 2022 at 11:25:32PM -0400, Brad Smith wrote: I'm not sure if MINOR is right. Currently the build is broken since TCP_INFO was added. Just to be certain, you mean the build is broken without your patch or with it ? If it's broken without, it means that your patch is a build fix, but it also indicates there's something wrong in the whole code's arrangement there that we'll have to re-adjust, because we must not break things for operating systems that are not explicitely handled. The build is broken without the diff. I was looking at older releases and this only affects 2.7 and 2.6. It looks like this changed things in such a way that if TCP_INFO is added but the OS is not added to the list of OS's it will not build. http://git.haproxy.org/?p=haproxy-2.6.git;a=commitdiff;h=5c83e3a1563cd7face299bf08037e51f976eb5e3;hp=39e436e36c4e6c0efe95c304fe89fd01e111 If you mean that the build is broken on certain versions once your patch is applied, that means we'll need to re-adjust it or to ease configuration of the feature. Thanks, Willy
Re: [PATCH] MINOR: tcp_sample: extend support for get_tcp_info to OpenBSD
Hi Brad, On Sat, Aug 13, 2022 at 11:25:32PM -0400, Brad Smith wrote: > I'm not sure if MINOR is right. Currently the build is broken since TCP_INFO > was added. Just to be certain, you mean the build is broken without your patch or with it ? If it's broken without, it means that your patch is a build fix, but it also indicates there's something wrong in the whole code's arrangement there that we'll have to re-adjust, because we must not break things for operating systems that are not explicitely handled. If you mean that the build is broken on certain versions once your patch is applied, that means we'll need to re-adjust it or to ease configuration of the feature. Thanks, Willy
Re: preliminary email for position: Software Engineer (Frontend/JS) at HAProxy Technologies
Hi On 8/20/22 01:45, supp...@hypothesisbase.com wrote: […] Just to let you know: You emailed the *public mailing list* for the HAProxy Community Edition Open Source project. This is not the correct target for job applications at HAProxy Technologies-the-company. Please note that I'm not affiliated with HAProxy Technologies-the-company and thus I won't be able to help you any further. Best regards Tim Düsterhus
Re: Lua: processing expired on timeout when using core.msleep
--- Original Message --- On Tuesday, August 23rd, 2022 at 4:26 AM, Christopher Faulet wrote: > It could be good to share your config, at least the part calling your lua > script. I think these are the only relevant bits: tcp-request inspect-delay 10s http-request lua.delay_request 15000 3 I'm delaying requests a random number of ms between 15000 and 3. > But this error can be triggered when the inspect-delay for tcp rules > evaluation is expires. Perhaps this is what is happening? Bren
Re: Understanding show table output and rate limiting weirdness
Hi Corin,
On Fri, Aug 19, 2022 at 08:55:17AM +, Corin Langosch wrote:
> Hello guys,
>
> I'm using the docker image 2.5.7-2ef551d with basic rate limiting configured
> like this:
>
> backend test
> acl test_rate_limit_by_ip_exceeds_limit
> src,table_http_req_rate(test_rate_limit_by_ip) gt 5
> http-request deny deny_status 429 if test_rate_limit_by_ip_exceeds_limit
> http-request track-sc0 src table test_rate_limit_by_ip
>
> acl test_rate_limit_api_exceeds_limit
> req.hdr(authorization),table_http_req_rate(test_rate_limit_api) gt 100
> http-request deny deny_status 429 if test_rate_limit_api_exceeds_limit
> http-request track-sc1 req.hdr(authorization) table test_rate_limit_api
> if { path -i -m beg "/api" }
>
> acl test_rate_limit_graphql_exceeds_limit
> req.hdr(x-api-key),table_http_req_rate(test_rate_limit_graphql) gt 100
> http-request deny deny_status 429 if test_rate_limit_graphql_exceeds_limit
> http-request track-sc2 req.hdr(authorization) table
> test_rate_limit_graphql if { path -i -m beg "/graphql" }
>
> server s1 10.0.0.1:80
> server s2 10.0.0.2:80
>
> backend test_rate_limit_by_ip
> stick-table type ipv6 size 1m expire 24h store http_req_rate(5m)
>
> backend test_rate_limit_api
> stick-table type string size 1m expire 24h store http_req_rate(3m)
>
> backend test_rate_limit_graphql
> stick-table type string size 1m expire 24h store http_req_rate(3m)
>
> Now I have some users reporting they are blocked (getting a 429) even though
> they don't perform a lot of requests. To analyze I ran "show table
> table_rate_limit_by_ip", but the output looks a bit weierd to me. Here's an
> anonymized extract:
>
> 0x55cfd58df130: key=:::1.2.3.1 use=0 exp=1498762521
> http_req_rate(30)=1181926
> 0x55cfd627f840: key=:::1.2.3.2 use=0 exp=1599966154
> http_req_rate(30)=80740
> 0x55cfda287e00: key=:::1.2.3.3 use=0 exp=58273431
> http_req_rate(30)=0
> 0x55cfd5cd5320: key=:::1.2.3.4 use=0 exp=2006327751
> http_req_rate(30)=1606589
>
> I wonder what's the value of exp? It doesn't seem to be a unix timestamp (not
> even in milliseconds), nor does it seem to be the number of (milli)seconds
> till the entry expires. Unfortunately, I can't find any documentation about
> it.
For me it was the remaining time before expiration in milliseconds, and
I've just rechecked the code to be sure, it's this. It obviously doesn't
fit with your tables. Your tables have 24h expirations and these ones are
up to 23 days.
> The http_req_rate (which should be the rate within the last 5 minutes for
> this table) is extremely (unrealistic) high for many entries. How is this
> possible?
It makes me think that something is wrong with the date, though I can't
imagine what. Is it entirely reproducible or does it happen spuriously ?
I'm wondering if it could be a memory corruption for example. Could you
please share the output of "show info" ? (beware there's the host name
there that you might want to delete if it's sensitive to you). Maybe
we'll find something weird there.
> Is my configuration broken? Is it a bug? ...?
Just thinking, would it be possible that you first started with a very
high expiration value (by accident) and that you then adjusted the
config and reloaded ? From what I remember, the time left is preserved
in exchanges between peers, so having, say, a 24 days value, then a
reconfig to 24 hours and a reload would preserve the 24 days one
(arguably we should enforce the new limit), but that's definitely
something that would make sense to me.
> Thanks for any help,
> Corin
>
> PS: Is there any way to filter the output of show table
> table_rate_limit_by_ip by key (by ip in my case)? In the docs, I only find
> how to filter by value (by http_req_rate in my case).
Yes, there's "key" (look at the end of the line):
show table [ data. [data. ...]] | [ key
]
So you should be able to issue:
show table test_rate_limit_by_ip key :::1.2.3.1
And it should work.
Willy
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
On Mon, Aug 22, 2022 at 04:33:51PM +, Bren wrote: > --- Original Message --- > On Monday, August 22nd, 2022 at 7:03 AM, William Lallemand > wrote: > > > I'm going to issue a 2.6.4 today with the patch. > > Just rolled out 2.6.4 and everything appears to be working as expected now. > Thanks! > Great! Thanks for the feedback! -- William Lallemand
Re: Lua: processing expired on timeout when using core.msleep
Le 8/22/22 à 18:53, Bren a écrit : Greetings, This is a minor issue I've been meaning to ask about. I have a fairly simple Lua script that simply runs core.msleep on certain requests for a random number of ms to slow them down. I've noticed this in the logs: [ALERT] (3650884) : Lua function 'delay_request': aborting Lua processing on expired timeout. I've always been under the impression that a sleep shouldn't cause any timeouts. Both tune.lua.session-timeout and tune.lua.service-timeout says: If the Lua does a sleep, the sleep is not taken in account. Am I missing something? Bren Hi, It could be good to share your config, at least the part calling your lua script. But this error can be triggered when the inspect-delay for tcp rules evaluation is expires. It can also happen when a read error is detected or an abort with abortonclose option. -- Christopher Faulet
Re: Possible problem with custom error pages -- backend server returns 503, haproxy logs 503, but the browser gets 403
Le 8/22/22 à 16:37, Shawn Heisey a écrit :
The same problem also happens with 2.6.4, built with the same options as
the dev version.
HAProxy version 2.6.4 2022/08/22 - https://haproxy.org/
I have documentation for the problem details in another project's bug
tracker:
https://issues.apache.org/jira/browse/SOLR-16327?focusedCommentId=17582990=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17582990
It appears so far as if haproxy is getting a 503 from the backend,
logging a 503, but actually sending a 403. Here is the config snippet
when it works correctly:
A top-level config section:
http-errors myerrors
errorfile 404 /etc/haproxy/errors/404.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/50x.http
errorfile 503 /etc/haproxy/errors/50x.http
errorfile 504 /etc/haproxy/errors/50x.http
In the frontend:
errorfiles myerrors
http-response return status 404 default-errorfiles if
!real_errors { status 404 }
http-response return status 403 default-errorfiles if
!real_errors { status 403 }
http-response return status 500 default-errorfiles if
!real_errors { status 500 }
http-response return status 502 default-errorfiles if
!real_errors { status 502 }
http-response return status 503 default-errorfiles if
!real_errors { status 503 }
http-response return status 504 default-errorfiles if
!real_errors { status 504 }
Removing the "!real_errors" part and restarting haproxy is when the
problem occurs. I created and used the real_errors acl as a working
bandaid for the issue -- turn off the custom error pages for the solr
hostname.
Hi,
It could be good to share your configuration and not only a snippet. However I'm
puzzled because in your case, the status code must be the one returned by the
server if no return rule matches or the one specified by the applied return rule.
There is also something I don't understand. In your bug report on solr project,
HAProxy logs report HTTP/3.0 requests but the screenshots show HTTP/2.0
requests. And the payload for the 403 response is talking about 50x errors. What
is the 50x.http error file content ?
--
Christopher Faulet
