Re: Question: How to not reset the TTL on a stick table entry?
Hi Nick, On 11/2/20 10:26 PM, Nick Ramirez wrote: > Hello, > > In my HAProxy config, I would like to ban people for a certain amount of time > by setting a general-purpose counter from 0 to 1, where 1 = banned, in a > stick table. When the stick table entry expires, the counter is reset to 0 > and the person is un-banned. This works fine. However, I would like to ignore > this person's requests while they're banned. That way, as they make requests, > they are not continuously banning themselves. > > Consider if I use this ACL and "track" line: > > ``` > acl is_banned sc_get_gpc1(0) gt 0 > http-request track-sc0 be_name unless is_banned > ``` > > This ACL uses `sc_get_gpc1(0)` to read the value of the general-purpose > counter. When this ACL is used by the `track-sc0` line, it *resets the TTL* > on the stick table entry, which means that a person will be banned forever > unless they stop making requests. I don't want this. I want to ban them for > only 10 seconds. So, instead, I use this ACL: > > ``` > acl is_banned be_name,table_gpc1 gt 0 > http-request track-sc0 be_name unless is_banned > ``` > > By using the `table_gpc1` conveter, the TTL is *not* reset when the ACL is > used, which is good. > > My question is, is this an undocumented feature? A bug that may one day be > "fixed"? Why is there a difference between `sc_get_gpc1(0)` and > `table_table_gpc1gpc1`, where the former resets the TTL on the stick table > entry, but the latter does not? > > Also, if this is a bug, would it be helpful to have a parameter on the > track-sc0 line that allows me to opt in to not resetting the TTL? > > Thank you, > Nick Ramirez > Reading the code I didn't see any fetches sc_get_gpc1 nor table_gpc1 updating entry expiration. Only the evaluation of the http-request trasck-sc0 will do. R, Emeric
Re: [PATCH] use better ec curves manipulation detection
ср, 4 нояб. 2020 г. в 20:43, Willy Tarreau : > On Wed, Nov 04, 2020 at 08:37:12PM +0500, ??? wrote: > > code full of "ifdefs" is not a mess. > > Yes it is, really. It's very hard to visually follow execution there. And > with your cleanups it's already way better. > > > the mess is to depend on OPENSSL_VERSION, every fork has it's own opinion > > what its own version should be. > > Agreed! > > > as far as we depend on macros we are safe. > > Yes definitely. > > > I'm ok to move that condition to openssl-compat.h if you think it is > better > > I think it will be better, it simplifies the conditions and that's exactly > the purpose of openssl-compat, to abstract what really deserves to be > abstracted. And quite frankly when it's just one library renaming a macro > for a NIH syndrome, that perfectly fits in this purpose :-) > > But if you don't have time to do it now for this one, I won't object > anyway, > so no worries. I was just suggesting the direction to follow based on a > concrete example. > > if you think to regroup define into openssl-compat.h, I suggest to do it on the fly. no need to send new patch > Thanks! > Willy >
Re: [PATCH] use better ec curves manipulation detection
On Wed, Nov 04, 2020 at 08:37:12PM +0500, ??? wrote: > code full of "ifdefs" is not a mess. Yes it is, really. It's very hard to visually follow execution there. And with your cleanups it's already way better. > the mess is to depend on OPENSSL_VERSION, every fork has it's own opinion > what its own version should be. Agreed! > as far as we depend on macros we are safe. Yes definitely. > I'm ok to move that condition to openssl-compat.h if you think it is better I think it will be better, it simplifies the conditions and that's exactly the purpose of openssl-compat, to abstract what really deserves to be abstracted. And quite frankly when it's just one library renaming a macro for a NIH syndrome, that perfectly fits in this purpose :-) But if you don't have time to do it now for this one, I won't object anyway, so no worries. I was just suggesting the direction to follow based on a concrete example. Thanks! Willy
Re: [PATCH] use better ec curves manipulation detection
ср, 4 нояб. 2020 г. в 20:14, Willy Tarreau :
> Hi Ilya,
>
> On Wed, Nov 04, 2020 at 12:43:44AM +0500, ??? wrote:
> > Hi,
> >
> > let us use macros instead of openssl versions.
> >
> > Cheers,
> > Ilya
>
> > From 278857e7d21e593e1b5a05a05605c89bdb08581d Mon Sep 17 00:00:00 2001
> > From: Ilya Shipitsin
> > Date: Wed, 4 Nov 2020 00:39:07 +0500
> > Subject: [PATCH 1/2] BUILD: ssl: use feature macros for detecting ec
> curves
> > manipulation support
> >
> > let us use SSL_CTX_set1_curves_list (OpenSSL), SSL_CTRL_SET_CURVES_LIST
> (BoringSSL)
> > for feature detection instead of versions
> > ---
> > include/haproxy/ssl_sock-t.h | 2 +-
> > src/cfgparse-ssl.c | 8
> > src/ssl_sock.c | 2 +-
> > 3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/haproxy/ssl_sock-t.h b/include/haproxy/ssl_sock-t.h
> > index c8c8616ea..1f9045cb9 100644
> > --- a/include/haproxy/ssl_sock-t.h
> > +++ b/include/haproxy/ssl_sock-t.h
> > @@ -274,7 +274,7 @@ struct global_ssl {
> > char *listen_default_ciphersuites;
> > char *connect_default_ciphersuites;
> > #endif
> > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x1000200fL) ||
> defined(LIBRESSL_VERSION_NUMBER))
> > +#if (defined SSL_CTX_set1_curves_list || defined
> SSL_CTRL_SET_CURVES_LIST)
>
> I could run that from 0.9.8 to 1.1.1 and confirm it gives the same
> resultss (not tested on libressl though). However given that it results
> in yet another "OR" between two variables supposedly identical, I think
> we should remap the boringssl one to the SSL_CTX_set1_curves_list in
> openssl-compat.h, something like this:
>
> #if !defined(SSL_CTX_set1_curves_list) && defined(SSL_CTRL_SET_CURVES_LIST)
> // boringSSL only sets SSL_CTRL_SET_CURVES_LIST
> #define SSL_CTX_set1_curves_list
> #endif
>
> This way it's cleaner to only test on the canonical name through the
> code (SSL_CTX_set1_curves_list).
>
> Not very important, I'll let William decide, it's just a suggestion,
> because as you've certainly figured by yourself now, this code full
> of #ifdef has become a real mess.
>
code full of "ifdefs" is not a mess.
the mess is to depend on OPENSSL_VERSION, every fork has it's own opinion
what its own version should be.
as far as we depend on macros we are safe.
I'm ok to move that condition to openssl-compat.h if you think it is better
>
> Cheers,
> Willy
>
Re: [PATCH] use better ec curves manipulation detection
Hi Ilya,
On Wed, Nov 04, 2020 at 12:43:44AM +0500, ??? wrote:
> Hi,
>
> let us use macros instead of openssl versions.
>
> Cheers,
> Ilya
> From 278857e7d21e593e1b5a05a05605c89bdb08581d Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin
> Date: Wed, 4 Nov 2020 00:39:07 +0500
> Subject: [PATCH 1/2] BUILD: ssl: use feature macros for detecting ec curves
> manipulation support
>
> let us use SSL_CTX_set1_curves_list (OpenSSL), SSL_CTRL_SET_CURVES_LIST
> (BoringSSL)
> for feature detection instead of versions
> ---
> include/haproxy/ssl_sock-t.h | 2 +-
> src/cfgparse-ssl.c | 8
> src/ssl_sock.c | 2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/haproxy/ssl_sock-t.h b/include/haproxy/ssl_sock-t.h
> index c8c8616ea..1f9045cb9 100644
> --- a/include/haproxy/ssl_sock-t.h
> +++ b/include/haproxy/ssl_sock-t.h
> @@ -274,7 +274,7 @@ struct global_ssl {
> char *listen_default_ciphersuites;
> char *connect_default_ciphersuites;
> #endif
> -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x1000200fL) ||
> defined(LIBRESSL_VERSION_NUMBER))
> +#if (defined SSL_CTX_set1_curves_list || defined SSL_CTRL_SET_CURVES_LIST)
I could run that from 0.9.8 to 1.1.1 and confirm it gives the same
resultss (not tested on libressl though). However given that it results
in yet another "OR" between two variables supposedly identical, I think
we should remap the boringssl one to the SSL_CTX_set1_curves_list in
openssl-compat.h, something like this:
#if !defined(SSL_CTX_set1_curves_list) && defined(SSL_CTRL_SET_CURVES_LIST)
// boringSSL only sets SSL_CTRL_SET_CURVES_LIST
#define SSL_CTX_set1_curves_list
#endif
This way it's cleaner to only test on the canonical name through the
code (SSL_CTX_set1_curves_list).
Not very important, I'll let William decide, it's just a suggestion,
because as you've certainly figured by yourself now, this code full
of #ifdef has become a real mess.
Cheers,
Willy
Re: [PATCH] do not run "slow" and "broken" tests for openssl no-deprecated builds
On Wed, Nov 04, 2020 at 12:45:11AM +0500, ??? wrote: > Hi, > > occasionely all tests were run (weekly) for openssl special mode tests. > let us remove "broken" and "slow" from those runs. Merged, thanks! Willy
Re: DNS Load balancing needs feedback and advice.
On Wed, Nov 04, 2020 at 03:07:22PM +0100, Emeric Brun wrote: > Hi Dinko, > > > Sadly I haven't had Kube-DNS anywhere and i think that CoreDNS is supposed > > to be way to go from Kube-DNS. Hope this helps. > It does. > > Really appreciate! Actually this tends to confirm our preliminary thoughts, which are that if some people absolutely want to load-balance DNS on haproxy, they'll have to comply with some supported features, or look for something else. I think it's a reasonable tradeoff because those who insist on this are also those who want to use so-called "modern" tools (placing "modern" and DNS in the same sentence always leaves me a strange feeling that something 37 years old is still modern). @Lukas, to respond to your concern, I don't like DNS either, but I much stronger hate the noise that some people regularly make about "UDP support" which when you ask is for syslog and dns (both being the wrong way to proceed, proving they don't even understand what they're asking for). Now with 2.3, syslog is handled like a proxy should do, which is not by blindly forwarding datagrams and causing trouble on the server, but instead by passing the messages, possibly re-encoding them according to the desired RFC level and adapting udp/tcp/stdout/whatever in any sense. The other one that remains now is DNS. I personally consider that it's stupid to want to LB inbound DNS with no added value, LVS will do it better and will scale better. In addition, if the reason is a matter of load, then one should really wonder if the LB will not reach limits before the server, having more than twice the work to do. However there could be a few compelling cases where doing it correctly could add some value. By correctly I mean that we'd typically receive mostly UDP datagrams and aggregate them over TCP connections. In this case it could make sense as a protocol accelerator/offloader/translator like haproxy already does for HTTP or TLS. In addition it might be possible to implement some short time caching to save on the internal bandwidth. Maybe later some of the DNSSEC job could be offloaded by haproxy, I don't know. So that's where I draw the frontier. Blind UDP, no, only morons want this in a userland proxy. Value-added UDP-based services, why not if it can be demonstrated that it does really bring some value and aligns well with what we already do around. Cheers, Willy
Re: DNS Load balancing needs feedback and advice.
Hi Dinko, > Sadly I haven’t had Kube-DNS anywhere and i think that CoreDNS is supposed to > be way to go from Kube-DNS. Hope this helps. It does. Really appreciate! R, Emeric
Re: Heath check responds up even when server is down
Hi, On Fri, 2020-10-30 at 00:49 +, Wesley Lukehart wrote: > To recap; > Exchange says component is Inactive > IIS is up and still serving content > healthcheck.htm page does not load, is down, unavailable, what have you > haproxy gets 200 response from health check that supposedly isn’t > available Have you tested with curl / wget from haproxy server if IIS/Exchange returns stautus=200 for /oab/healthcheck.htm ? curl -v -k https://ip.addr.e.ss/oab/healthcheck.htm and # this probably sends "correct" iis.exchange.domain.com SNI to iis server, # maybe iis/exchange needs SNI to serve correct file/status ? curl -v -k --resolve iis.exchange.domain.com:443:iis.ip.here https://iis.exchange.domain.com/oab/healthcheck.htm > Here are relevant haproxy logs showing the health check as good and > content still being proxied, even though the component is inactive (ie > health check page is not accessible) > Oct 29 14:51:39 haproxy: [WARNING] 302/145139 (93952) : > Health check for server be_ex2019_oab/ succeeded, reason: > Layer7 check passed, code: 200, info: "HTTP status check returned code > <3C>200<3E>", check duration: 8ms, status: 3/3 UP. > Looking at the IIS logs, when the component is active, I see the GET > requests from my workstations IP. When the component is inactive, no GET > request is logged from my workstation. > In addition, weather the service is active or inactive, IIS logs GET > requests from the haproxy servers: > 2020-10-30 00:13:01 10.168.99.91 GET /oab/healthcheck.htm - 443 - > - - 200 0 0 1 > 2020-10-30 00:13:11 10.168.99.91 GET /oab/healthcheck.htm - 443 - > - - 200 0 0 1 So both haproxy and IIS log show that /oab/healthcheck.htm is served with status=200 to haproxy ? When you test /oab/healthcheck.htm with browser what url do you use: https://correct.domain.com/oab/healthcheck.htm or https://ip.addr.es.s/oab/healthcheck.htm ? Do you get different result with ip or hostname ? -Jarno -- Jarno Huuskonen
need haproxy related information
hi team, As we wanto to implement haproxy in customer's cloud environment I have below questions 01) how to check maximum message processing capacity of haproxy version-wise ? 02) In a cloud environment of client haproxy will have to distribute mixed kind of requests. If load gets increased beyond handling capacity of haproxy, then how will we scale haproxy itself. How we will add another haproxy dynamically? It would be great if you supply answers of these questions today. Regards, Avinash
Re: DNS Load balancing needs feedback and advice.
On 3 Nov 2020, at 16:38, Emeric Brun wrote: > > […] > > But the question is targeting also DNS servers found in cloud environments > such as kube-dns, coreDNS or consul. > > They seem supporting TCP but I'm not sure about pipelined queries Hi Emeric, I had CoreDNS 1.6.6 and Consul v1.8.5 around. To my great surprise, both seem to be supporting TCP pipelined requests and a persistent TCP connection. I have tested with getdns_query (https://getdnsapi.net/) and with few hundred requests send with: getdns_query @IPADDR -s -a -A -l T -O -I < input Sadly I haven’t had Kube-DNS anywhere and i think that CoreDNS is supposed to be way to go from Kube-DNS. Hope this helps. Kind regards, D. -- Dinko Korunic ** Standard disclaimer applies ** Sent from OSF1 osf1v4b V4.0 564 alpha
