Re: About the SPOE

Hi Christopher, Thank you for starting the discussion here. >Worst, other parts of HAProxy evolved, especially applets part, making maintenance ever more expensive. Can we elaborate on what makes maintenance expensive? >We must be realistic on the subject, there was no real adoption on the

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

v_addr.addr.v4.s_addr); > -key ^= addr_key + 0x9e3779b9 + (key << 6) + (key >> 2); > +key = full_hash(key + srv_addr.addr.v4.s_addr); > break; > case AF_INET6: > key = XXH32(srv_addr.addr.v6.s6_addr, 16, key); Yeay I think it addresses everything. I'll re-test your updated patch tomorrow hoping that this time I'll merge it :-) Thanks for your patience! Willy

RE: RSA Conference Attendees Emails List-2024

Hi, Hope you're doing well. Would you be interested in acquiring RSA Conference Attendees Emails List-2024 List Includes:- Company/Org-Name, First Name, Last Name, Contact Job Title, Verified Email Address, Website URL, Mailing Address, Phone Number, Industry and many more. Number of

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Willy, My original concern was that if two servers had values of lb_server_key that are close to each other, then there could be some overlap in their values of lb_server_key + node_index;, which is why I was looking for a reasonable hash function to combine them. I based it on

Re: Fix haproxy build on recent FreeBSD

On Mon, Mar 11, 2024 at 07:00:26PM +0100, Willy Tarreau wrote: > On Mon, Mar 11, 2024 at 05:56:35PM +, Brooks Davis wrote: > > > OK that works for me. Do you want to send a new patch or should I adapt > > > yours ? If you have a 12 somewhere that would save me time to verify I > > > don't mess

Re: Revisiting CVE-2023-45539

Hi Ryan, On Mon, Mar 04, 2024 at 12:13:48PM -0600, Ryan O'Hara wrote: > I am looking at CVE-2023-45539 as it affects older versions of haproxy (ie. > haproxy-1.8). At this point I have verified that 1.8 is affected by this > issue, which is in agreement with the original bug/commit which states >

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Anthony, On Tue, Mar 12, 2024 at 07:10:42PM -0400, Anthony Deschamps wrote: > Hi Willy, > > Thanks for the feedback. I had been testing with smaller numbers of > servers (usually between 4 and 32) so I hadn't noticed the performance > impact. Not surprised. I'm used to testing with some

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Willy, Thanks for the feedback. I had been testing with smaller numbers of servers (usually between 4 and 32) so I hadn't noticed the performance impact. Here's an updated patch (as an attachment, until I figure out how to make sure things are formatted correctly!) that should address that. I

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

> + > + /* First we need to remove all of the server's entries from its tree > + * because a) the realloc will change all node pointers and b) the keys > + * may change. > + */ > + chash_dequeue_srv(s); This part above. It completely removes the server from

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

On Mon, Mar 11, 2024 at 11:24:34PM -0400, Anthony Deschamps wrote: > Sorry for the trouble! I'll have to sort out what's happening. No problem, some mailers are well-known for mangling what looks like text. > Here it is as an attachment. Looks good as-is, thank you! I'll review it (hopefully

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Sorry for the trouble! I'll have to sort out what's happening. Here it is as an attachment. Thanks! Anthony On Mon, Mar 11, 2024 at 11:06 PM Willy Tarreau wrote: > Hi Anthony, > > On Mon, Mar 11, 2024 at 08:58:17PM -0400, Anthony Deschamps wrote: > > > I'm not sure the scripts will help me

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Anthony, On Mon, Mar 11, 2024 at 08:58:17PM -0400, Anthony Deschamps wrote: > > I'm not sure the scripts will help me (at least :-)). I was thinking that > > a test could just be "set server XXX addr YYY" on the CLI to change the > > server's address and verify that the hashing follows the

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

> I'm not sure the scripts will help me (at least :-)). I was thinking that > a test could just be "set server XXX addr YYY" on the CLI to change the > server's address and verify that the hashing follows the address not the > server number. Oh, good point -- I wasn't testing what happens when

Re: Fix haproxy build on recent FreeBSD

On Mon, Mar 11, 2024 at 05:56:35PM +, Brooks Davis wrote: > > OK that works for me. Do you want to send a new patch or should I adapt > > yours ? If you have a 12 somewhere that would save me time to verify I > > don't mess up with the ifdefs, otherwise I can probably handle it and > > we'll

Re: Fix haproxy build on recent FreeBSD

On Sat, Mar 09, 2024 at 06:12:12AM +0100, Willy Tarreau wrote: > Hi Brooks, > > On Fri, Mar 08, 2024 at 09:47:39PM +, Brooks Davis wrote: > > On Fri, Mar 08, 2024 at 06:19:42PM +0100, Willy Tarreau wrote: > > > Hi Dmitry, > > > > > > first, sorry for the long delay but these days I've been

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

On 09/03/2024 18:09, Tristan wrote: Hi Willy, On 09/03/2024 16:51, Willy Tarreau wrote: Hi Tristan, On Sat, Mar 09, 2024 at 04:20:21PM +, Tristan wrote: To be honest, I don't think this is unfixable. It's just a matter of how much code change we think is acceptable for it. I don't

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

Hi Willy, On 09/03/2024 16:51, Willy Tarreau wrote: Hi Tristan, On Sat, Mar 09, 2024 at 04:20:21PM +, Tristan wrote: To be honest, I don't think this is unfixable. It's just a matter of how much code change we think is acceptable for it. I don't mind about the amount of changes. "we've

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

Hi Tristan, On Sat, Mar 09, 2024 at 04:20:21PM +, Tristan wrote: > To be honest, I don't think this is unfixable. It's just a matter of how > much code change we think is acceptable for it. I don't mind about the amount of changes. "we've always done it like this" is never a valid excuse to

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

Hi Willy, On 08/03/2024 18:01, Willy Tarreau wrote: The problem with default values is that a single behavior cannot be deduced from reading a single config statement. That's quite painful for lots of people (including those who copy config blocks from stackoverflow), and for API tools. And it

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Anthony, On Wed, Feb 21, 2024 at 11:49:45AM -0500, Anthony Deschamps wrote: > Hi Willy, thanks for the thoughtful feedback. > > Here's a new patch that makes this configurable via a "hash-key" server > argument, which defaults to "id" as you suggested. Thanks. > I'm struggling to test the

Re: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server

Hi Anthony, it seems I forgot about this thread, being sidetracked on other stuff... On Wed, Feb 21, 2024 at 04:41:04PM -0500, Anthony Deschamps wrote: > Hi Willy, > > I wonder if I could accomplish what I'm looking to do by changing the > behaviour of "maxqueue" (without making a breaking

Re: [PR] BUILD: solaris: fix compilation errors

On Tue, Feb 27, 2024 at 10:23:02AM +, PR Bot wrote: > Dear list! > > Author: matthias sweertvaegher <178714+mx...@users.noreply.github.com> > Number of patches: 1 > > This is an automated relay of the Github pull request: >BUILD: solaris: fix compilation errors Now merged, thank you

Re: Fix haproxy build on recent FreeBSD

Hi Brooks, On Fri, Mar 08, 2024 at 09:47:39PM +, Brooks Davis wrote: > On Fri, Mar 08, 2024 at 06:19:42PM +0100, Willy Tarreau wrote: > > Hi Dmitry, > > > > first, sorry for the long delay but these days I've been drained in a > > bunch of meetings and reviews that took more time than I

Re: Fix haproxy build on recent FreeBSD

On Fri, Mar 08, 2024 at 06:19:42PM +0100, Willy Tarreau wrote: > Hi Dmitry, > > first, sorry for the long delay but these days I've been drained in a > bunch of meetings and reviews that took more time than I expected! > > On Wed, Feb 28, 2024 at 11:06:00PM +0300, Dmitry Sivachenko wrote: > >

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

On Fri, Mar 08, 2024 at 05:38:32PM +, Tristan wrote: > Hi Willy, > > On 08/03/2024 17:05, Willy Tarreau wrote: > > We could just have "abns2" and declare that it's the second version of the > > abns format and know that this one is interoperable with a number of other > > components. > >

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

Hi Willy, On 08/03/2024 17:05, Willy Tarreau wrote: We could just have "abns2" and declare that it's the second version of the abns format and know that this one is interoperable with a number of other components. Having abns@ and abns2@ strictly for that one difference seems like a lot to

Re: Fix haproxy build on recent FreeBSD

Hi Dmitry, first, sorry for the long delay but these days I've been drained in a bunch of meetings and reviews that took more time than I expected! On Wed, Feb 28, 2024 at 11:06:00PM +0300, Dmitry Sivachenko wrote: > Hello! > > Recently FreeBSD has moved some things out from libc to libsys (see

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

Hi Tristan, On Wed, Mar 06, 2024 at 07:32:55AM +, Tristan wrote: > Hello, > > Earlier, I ran into the issue outlined in > https://github.com/haproxy/haproxy/issues/977 > > Namely, that HAProxy will NUL-pad (as suffix) abstract unix socket paths, > causing interop issues with other programs.

Re: [PATCH 1/1] CI: skip scheduled builds on forks

On Wed, Feb 21, 2024 at 05:05:39PM +0100, Ilya Shipitsin wrote: > tracking bleeding edge changes with some rare platforms or modern > compilers on scheduled basis is not what usually forks do. let's > skip by default in forks, if some fork is interested, it might be > enabled locally Thank you!

Re: [PATCH 1/1] CI: enable monthly build only test on netbsd-9.3

On Mon, Feb 19, 2024 at 10:14:59PM +0100, Ilya Shipitsin wrote: > it is interesting to try https://github.com/vmactions/netbsd-vm actions Now merged, thanks! Willy

Re: [PATCH 1/1] CI: run more smoke tests on config syntax to check memory related issues

On Sat, Feb 17, 2024 at 08:42:28PM +0100, Ilya Shipitsin wrote: > config syntax check seems add a value on testing code path not > covered by VTest, also checks are very fast Applied, thanks! We'll see if it triggers anything, that could indeed be helpful. Willy

Re: [PATCH] CLEANUP: assorted typo fixes in the code and comments

On Thu, Feb 22, 2024 at 10:12:27AM +0100, Ilya Shipitsin wrote: > This is 39th iteration of typo fixes Now merged, thank you! I split it in two because the one on resolvers and stick-tables directly affects the code (it renames a function argument) and I want to make it easy to drop it in case

Re: [PATCH 0/1] CI: additional ASAN smoke tests

Hi Ilya, On Mon, Mar 04, 2024 at 10:41:12PM +0100, ??? wrote: > ping :) sorry, I wanted to double-check with others but forgot. Will do ASAP, thanks! Willy

Re: [PATCH 0/1] CI: additional ASAN smoke tests

ping :) сб, 17 февр. 2024 г. в 20:43, Ilya Shipitsin : > > > Ilya Shipitsin (1): > CI: run more smoke tests on config syntax to check memory related > issues > > .github/workflows/vtest.yml | 4 > 1 file changed, 4 insertions(+) > > -- > 2.43.2 > >

Re: RSA Conference Attendees Data List-2024

Hi, Would you be interested in acquiring RSA Conference Attendees Data List-2024? List Includes: Company Name, First Name, Last Name, Full Name, Contact Job Title, Verified Email Address, Website URL, Mailing address, Phone number, Industry and many more. Number of Contacts: 30,285

RE: RE: RSA Conference Attendees Emails List 2024

Hi, Hope you're doing well. Do you have any updates for me!? Please let me know if you require any further information. With Regards Naomi Stubbs From: Naomi Stubbs [mailto:www.bestdatabi...@gmail.com] Sent: Thursday, February 22, 2024 6:43 AM To: 'haproxy@formilux.org' Subject: RE

RE: RSA Conference Attendees Emails List 2024

Hi, Hope you're doing well. Would you be interested in acquiring RSA Conference Attendees Emails List 2024? List Includes:- Company/Org-Name, First Name, Last Name, Contact Job Title, Verified Email Address, Website URL, Mailing Address, Phone Number, Industry and many more. Number

Re: http/3 flow control equivalent

On Thu, Feb 22, 2024 at 12:47:04PM +1100, Miles Hampson wrote: > Hi, > I have noticed that transferring large files with http/2 to a backend > server through HAProxy 2.9 (and earlier) over a network link with a bit of > latency can be extremely slow unless the HTTP/2 Flow Control window size is >

Re: http/3 flow control equivalent

Hi. On 2024-02-22 (Do.) 02:47, Miles Hampson wrote: Hi, I have noticed that transferring large files with http/2 to a backend server through HAProxy 2.9 (and earlier) over a network link with a bit of latency can be extremely slow unless the HTTP/2 Flow Control window size is increased quite

Re: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server

Hi Willy, I wonder if I could accomplish what I'm looking to do by changing the behaviour of "maxqueue" (without making a breaking change, ideally). Currently, "maxqueue 0" is interpreted as "unlimited". However, the system I'm working with has long-running WebSocket connections, so a queued

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Willy, thanks for the thoughtful feedback. Here's a new patch that makes this configurable via a "hash-key" server argument, which defaults to "id" as you suggested. I'm struggling to test the last case you described. A quick description of my test setup: I have multiple instances of a simple

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

On Fri, Feb 16, 2024 at 05:03:56PM -0500, Anthony Deschamps wrote: > >From a031cf97da759eb2c2f9b6e191065ad503f821ed Mon Sep 17 00:00:00 2001 > From: Anthony Deschamps > Date: Fri, 16 Feb 2024 16:00:35 -0500 > Subject: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server > address

Re: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server

Hi Anthony, On Tue, Feb 13, 2024 at 07:49:06PM -0500, Anthony Deschamps wrote: > >From 3fc983b719bd4d8af80037c36e7032e0af383557 Mon Sep 17 00:00:00 2001 > From: Anthony Deschamps > Date: Tue, 13 Feb 2024 18:11:56 -0500 > Subject: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server >

Re: [PATCH] DOC/MINOR: userlists: musl performance

On Mon, Feb 12, 2024 at 06:42:25PM +0100, Lukas Tribus wrote: > On Mon, 12 Feb 2024 at 18:10, Nicolas CARPi wrote: > > > > Dear Lukas, Willy, > > > > Please find another patch attached, addressing your comments. > > > > Willy: s/gcc/glibc/ > > > > Lukas: I shifted the focus on the rounds/cost

Re: Haproxy accross LDAPS

s, Willy *De :* Aleksandar Lazic *Envoyé :* jeudi 15 février 2024 15:20 *À :* TINK-LONG-KI Willy *Cc :* haproxy@formilux.org *Objet :* Re: Haproxy accross LDAPS Hi Willy. On 2024-02-15 (Do.) 09:07, TINK-LONG-KI Willy wrote: Hello All, I trying  to configure

Re: Haproxy accross LDAPS

Hi Willy. On 2024-02-15 (Do.) 09:07, TINK-LONG-KI Willy wrote: Hello All, I trying  to configure a backend on a HAPROXY (release 2.4.25) with LDAPS in order to authenticate user by the LDAPS. Any chance to use the latest 2.8 or 2.9? Below informations about my configuration : -Port use

Re: unsubscribe

Hi. Here can you find the right way to Unsubscribe from the list https://www.haproxy.org/#tact Regards Alex On 2024-02-12 (Mo.) 23:02, Nicolas Grilly wrote: *Nicolas Grilly* Managing Partner +33 6 03 00 25 34 Recrutez plus rapidement avec VocationCity.com

Re: [PATCH] DOC/MINOR: userlists: musl performance

On Mon, 12 Feb 2024 at 18:10, Nicolas CARPi wrote: > > Dear Lukas, Willy, > > Please find another patch attached, addressing your comments. > > Willy: s/gcc/glibc/ > > Lukas: I shifted the focus on the rounds/cost solution, while still > mentioning the musl issue, as this problem is clearly more

Re: [PATCH] DOC/MINOR: userlists: musl performance

Dear Lukas, Willy, Please find another patch attached, addressing your comments. Willy: s/gcc/glibc/ Lukas: I shifted the focus on the rounds/cost solution, while still mentioning the musl issue, as this problem is clearly more visible on Alpine Linux, as the github issues show. Cheers,

Re: [PATCH] DOC/MINOR: userlists: musl performance

On Mon, 12 Feb 2024 at 14:13, Nicolas CARPi wrote: > > Hello everyone, > > Please find attached my very first patch to the documentation. Hope I > did everything good! :) > > Based on a comment from @bugre: > https://github.com/haproxy/haproxy/issues/2251#issuecomment-1716594046 > > (and also

Re: [PATCH] DOC/MINOR: userlists: musl performance

Hi Nicolas, On Mon, Feb 12, 2024 at 02:13:18PM +0100, Nicolas CARPi wrote: > Hello everyone, > > Please find attached my very first patch to the documentation. Hope I > did everything good! :) Thank you! I have one comment below: > + Furthermore, there is a significant performance penalty

Re: WolfSSL builds for use with HAProxy

On Fri, Feb 09, 2024 at 11:00:24PM +, Tristan wrote: > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to

Re: WolfSSL builds for use with HAProxy

On Thu, Feb 08, 2024 at 02:46:46PM +, Tristan wrote: > Hi all, > Hello, > With the ever-increasing threat of one day needing to give up on OpenSSL > 1.1.1 (whenever the next bad CVE is found on QuicTLS 1.1.1w, essentially) I > was looking at alternatives a bit closer. > > Based on the

Re: WolfSSL builds for use with HAProxy

сб, 10 февр. 2024 г. в 00:00, Tristan : > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to current QuicTLS? >

Re: [PATCH] CI: Update to actions/cache@v4

Hi Tim! On Thu, Feb 08, 2024 at 07:55:23PM +0100, Tim Duesterhus wrote: > No functional change, but this upgrade is required, due to the v3 runtime > being > deprecated: > > > Node.js 16 actions are deprecated. Please update the following actions to > > use > > Node.js 20: actions/cache@v3.

Re: WolfSSL builds for use with HAProxy

Hi Ilya, On 09/02/2024 20:31, Илья Шипицин wrote: I run QUIC Interop from time to time, WolfSSL shows the best compatibility compared to LibreSSL and aws-lc. it really looks like a winner today And in comparison to current QuicTLS? I'm afraid it practice it works in a different way. First,

Re: WolfSSL builds for use with HAProxy

чт, 8 февр. 2024 г. в 15:49, Tristan : > Hi all, > > With the ever-increasing threat of one day needing to give up on OpenSSL > 1.1.1 (whenever the next bad CVE is found on QuicTLS 1.1.1w, > essentially) I was looking at alternatives a bit closer. > > Based on the wiki, >

Re: Managing haproxy configs at scale

Hi Zach, (Replying on the ML since your reply was directly to me only) On 08/02/2024 21:10, Zach Pearson wrote: Thanks for the reply, Tristan, and sorry for the late reply! To add a little more context for our haproxy setup, we currently deploy haproxy along with a sidecar control-plane that

Re: pcre vs pcre2, which one to use?

On Wed, Feb 07, 2024 at 07:07:13PM -0800, Abhijeet Rastogi wrote: > Hi Willy, > > Thanks for the quick clarification. I've sent a patch. > > I also changed the "Quick build & install" section in the INSTALL doc to > use USE_PCRE2, so folks don't accidently use the older version. I hope that >

Re: pcre vs pcre2, which one to use?

Hi Willy, Thanks for the quick clarification. I've sent a patch. I also changed the "Quick build & install" section in the INSTALL doc to use USE_PCRE2, so folks don't accidently use the older version. I hope that was an intended change. On Wed, Feb 7, 2024 at 2:08 PM Willy Tarreau wrote: >

Re: pcre vs pcre2, which one to use?

Hi Abhijeet, On Wed, Feb 07, 2024 at 01:19:27PM -0800, Abhijeet Rastogi wrote: > Hi HAproxy community, > > I see that Makefile > suggests that > pcre1 is a recommended version to use, is that still true or a comment that > got out of

Re: [PATCH] DOC: install: clarify WolfSSL chroot requirements

On Fri, Feb 02, 2024 at 05:33:08PM +, Lukas Tribus wrote: > Subject: [PATCH] DOC: install: clarify WolfSSL chroot requirements > --- > INSTALL | 12 > 1 file changed, 12 insertions(+) > > diff --git a/INSTALL b/INSTALL > index 18eb67f311..8ebf8d298c 100644 > --- a/INSTALL > +++

Re: [PATCH 0/2] CI cleanup and improvement

On Fri, Feb 02, 2024 at 08:33:14PM +0100, Ilya Shipitsin wrote: > Subject: [PATCH 0/2] CI cleanup and improvement > remove redundant function, improve openssl download helper > > Ilya Shipitsin (2): > CI: cleanup: abandon asan matrix.py helper > BUILD: SSL: add yet another OpenSSL download

Re: ACL and operator

On Sat, Feb 03, 2024 at 01:18:30PM +, Tristan wrote: > > > > On 3 Feb 2024, at 15:18, Willy Tarreau wrote: > > > > Quite honestly, we've though about it several times but you can't enforce > > such a change on 20 years of configs everywhere. > > That is why I directly mentioned it being

Re: ACL and operator

> On 3 Feb 2024, at 15:18, Willy Tarreau wrote: > > Quite honestly, we've though about it several times but you can't enforce > such a change on 20 years of configs everywhere. That is why I directly mentioned it being some form of opt-in behavior, because indeed we can’t expect everyone to

Re: ACL and operator

On Sat, Feb 03, 2024 at 10:31:02AM +, Tristan wrote: > Hi Willy, > > > On 3 Feb 2024, at 12:48, Willy Tarreau wrote: > > > in fact we could check for > >> the presence of "and" or "or" on a line, or some other suspicious > >> constructs > > Another approach might be to optionally enforce

Re: ACL and operator

Hi Willy, > On 3 Feb 2024, at 12:48, Willy Tarreau wrote: > in fact we could check for >> the presence of "and" or "or" on a line, or some other suspicious >> constructs Another approach might be to optionally enforce quotes around strings. While it’d be a breaking change and sounds a bit

Re: ACL and operator

On Sat, Feb 03, 2024 at 09:10:42AM +0100, Willy Tarreau wrote: > On Fri, Feb 02, 2024 at 06:43:12PM +, Lukas Tribus wrote: > > On Fri, 2 Feb 2024 at 18:42, John Lauro wrote: > > > > > > Seems like a lint style checker that doesn't require AI. > > > For example, it could recognize that the /

Re: ACL and operator

On Fri, Feb 02, 2024 at 06:43:12PM +, Lukas Tribus wrote: > On Fri, 2 Feb 2024 at 18:42, John Lauro wrote: > > > > Seems like a lint style checker that doesn't require AI. > > For example, it could recognize that the / in /api isn't valid for > > req.hdr(host) > > [...] > > The _ in path_beg

Re: ACL and operator

On Fri, 2 Feb 2024 at 18:42, John Lauro wrote: > > Seems like a lint style checker that doesn't require AI. > For example, it could recognize that the / in /api isn't valid for > req.hdr(host) > [...] > The _ in path_beg is also questionable. You can have _ in dns names, > but are not valid in

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On 2024-02-02 16:38, Lukas Tribus wrote: WolfSSL support in HAProxy is experimental to the point that not only does it require compiling library and application from source, it also requires tinkering with LD paths to be able to even start the binary, so it's not like the INSTALL instructions

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On Fri, 2 Feb 2024 at 08:43, Willy Tarreau wrote: > > Hi Lukas! > > On Thu, Feb 01, 2024 at 02:52:10PM +, Lukas Tribus wrote: > > On Thu, 1 Feb 2024 at 12:08, William Lallemand > > wrote: > > > > > > That's interesting, however I'm surprised the init does not work before > > > the chroot,

Re: ACL and operator

On Fri, 2 Feb 2024 at 15:09, Tom Braarup wrote: > > Hi, > > The config validator does not seems to catch this error in syntax and Haproxy > ignores the second part of the expression: > > use_backend api.example.com if { req.hdr(host) -i example.com and path_beg > /api } This is correct syntax

RE: Formilux - Bio-IT Conference & Expo 2024 engage leads

Hi There, I see you're too busy to reply Could you please just hit me back "Interested or Not interested" So that I can send you "Free Samples and Counts" Thanks Amelia Jones - Trade show coordinator If you don't want to receive further emails revert with Take Out in the subject From:

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

Hi Lukas! On Thu, Feb 01, 2024 at 02:52:10PM +, Lukas Tribus wrote: > On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > > > That's interesting, however I'm surprised the init does not work before the > > chroot, > > we are doing a RAND_bytes() with OpenSSL before the chroot to

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

Hello William, On Thu, 1 Feb 2024 at 17:52, William Lallemand wrote: > > I consider getrandom() a modern and simple solution to all those problems. > > Unfortunately this is still a fallback solution if getrandom() is not > accessible or if the support is not built, as this is a fallback in >

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On 2024-02-01 15:52, Lukas Tribus wrote: On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > That's interesting, however I'm surprised the init does not work before the chroot, > we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this. This approach can actually hide

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > That's interesting, however I'm surprised the init does not work before the > chroot, > we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this. This approach can actually hide chroot issues leading to nasty

Re: Optimizing HAProxy CPU usage for SSL

Hi Willy, Thanks for your response, I learned a lot from reading it. > So that would give roughly 4000 SSL req/sec max over all cores, or only > 166 per core, that sounds quite low! > > Normally on a modern x86 CPU core, you should expect roughly 500 RSA2048/s > per core and per GHz (or keep in

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On 2024-01-30 20:45, Lukas Tribus wrote: Suggest enabling getrandom() syscall in wolfssl to avoid chroot problems when using wolfssl. --- Also see: https://discourse.haproxy.org/t/haproxy-no-responses-when-built-with-wolfssl-while-working-with-openssl/9320/15 --- INSTALL | 3 ++- 1 file

Re: Optimizing HAProxy CPU usage for SSL

Hi Miles, On Thu, Feb 01, 2024 at 05:09:20PM +1100, Miles Hampson wrote: > Hi, > > We recently hit an issue where we observed the > haproxy_frontend_current_sessions reported by the prometheus endpoint > plateau at 4095 and some requests start dropping. Increasing the global and > listen maxconn

Re: [RFC PATCH] DOC: httpclient: add dedicated httpclient section

Hello Lukas, On 2024-01-30 22:17, Lukas Tribus wrote: Move httpclient keywords into its own section and explain adding an introductory paragraph. Also see Github issue #2409 Should be backported to 2.6 ; but note that: 2.7 does not have httpclient.resolvers.disabled 2.6 does not have

Re: [PATCH] CLEANUP: log: deinitialization of the log buffer in one function

Hi Miroslav, On Tue, Jan 30, 2024 at 03:42:20AM +0100, Miroslav Zagorac wrote: > Hello all, > > In several places in the source, there was the same block of code that was > used to deinitialize the log buffer. There were even two functions that > did this, but they were called only from the

Re: [PATCH] DOC: configuration: clarify http-request wait-for-body

Hi Thayne, On Sun, Jan 28, 2024 at 10:07:32PM -0700, Thayne McCombs wrote: > Make it more explicit what happens in the various scenarios that cause > HAProxy to stop waiting when "http-request wait-for-body" is used. > > Also fix a couple of grammatical errors. > > Fixes: #2410 > Signed-Off-By:

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

On Fri, Jan 26, 2024 at 09:22:58PM +0100, ??? wrote: > ??, 26 ???. 2024 ?. ? 20:01, Willy Tarreau : > > > On Fri, Jan 26, 2024 at 05:30:31PM +0100, Willy Tarreau wrote: > > > On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > > > > it is very fast check, should not affect

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

пт, 26 янв. 2024 г. в 20:01, Willy Tarreau : > On Fri, Jan 26, 2024 at 05:30:31PM +0100, Willy Tarreau wrote: > > On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > > > it is very fast check, should not affect developer velocity much > > > > OK now pushed, thank you Ilya! > > Ilya,

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

On Fri, Jan 26, 2024 at 05:30:31PM +0100, Willy Tarreau wrote: > On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > > it is very fast check, should not affect developer velocity much > > OK now pushed, thank you Ilya! Ilya, I reverted the last one (automatic check on push) for

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 06:35:09PM +, David Carlier wrote: > > > > It broke the CI on the "all features" build: > > > > > > https://github.com/haproxy/haproxy/actions/runs/7671640626/job/20910459829 > > > > /usr/bin/ld: cannot find -lcurl: No such file or directory > > /usr/bin/ld: cannot find

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

> > It broke the CI on the "all features" build: > > > https://github.com/haproxy/haproxy/actions/runs/7671640626/job/20910459829 > > /usr/bin/ld: cannot find -lcurl: No such file or directory > /usr/bin/ld: cannot find -lzip: No such file or directory > > I'm surprised because CURL_LDFLAGS and

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 06:57:57PM +0100, Willy Tarreau wrote: > On Fri, Jan 26, 2024 at 05:38:20PM +, David Carlier wrote: > > I m good with your version. Thanks ! > > Great, now merged, thanks! > Willy It broke the CI on the "all features" build:

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 05:38:20PM +, David Carlier wrote: > I m good with your version. Thanks ! Great, now merged, thanks! Willy

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

I m good with your version. Thanks ! On Fri, Jan 26, 2024 at 5:35 PM Willy Tarreau wrote: > On Fri, Jan 26, 2024 at 04:41:36PM +, David Carlier wrote: > > Hi, > > > > Please find the revised patch. > > OK thanks, it looks good and addresses the build issue. > > I noticed that when building

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 04:41:36PM +, David Carlier wrote: > Hi, > > Please find the revised patch. OK thanks, it looks good and addresses the build issue. I noticed that when building with the dummy lib, we continue to link with -lstdc++ even if it's not used (unless DEVICEATLAS_NOCACHE=1)

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

Hi, Please find the revised patch. Regards. On Fri, Jan 26, 2024 at 4:28 PM Willy Tarreau wrote: > Hi David, > > On Thu, Jan 25, 2024 at 09:26:24AM +, David Carlier wrote: > > Finally the last piece related to the da's dummy update and da.c changes. > > Thanks. I'm getting the following

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > it is very fast check, should not affect developer velocity much OK now pushed, thank you Ilya! Willy

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

Hi David, On Thu, Jan 25, 2024 at 09:26:24AM +, David Carlier wrote: > Finally the last piece related to the da's dummy update and da.c changes. Thanks. I'm getting the following build error: addons/deviceatlas/da.c: In function 'da_haproxy_checkinst': addons/deviceatlas/da.c:284:25:

Re: USE_QUIC=1 support for awslc

On 1/24/24 05:58, Yaacov Akiba Slama wrote: > So right now, the only thing missing in aws_lc in order to fully support > quic is the implementation of EVP_chacha20() ? This is one of the *identified* things which are missing in addition to TLS_AES_128_CCM_SHA256 which cannot be enabled. This does

Re: USE_QUIC=1 support for awslc

So right now, the only thing missing in aws_lc in order to fully support quic is the implementation of EVP_chacha20() ? Thanks a lot for your work, --yas On 23/01/2024 17:18, Frederic Lecaille wrote: FYI, I have just pushed 4 patches to master to make haproxy support 0-RTT when built against

Re: Managing haproxy configs at scale

On 23/01/2024 22:44, Zach Pearson wrote: Hello, We are using haproxy in a few different environments/functions and the configurations are getting complicated to manage. We are already using Jinja2 to generate environment specific configs but was wondering if anyone has suggestions on tools

Re: USE_QUIC=1 support for awslc

On 1/15/24 17:16, Yaacov Akiba Slama wrote: > On 04/10/2023 18:38, William Lallemand wrote: >> Hello, >> >> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya >> mentionned. >> >> For now: >> >>     - 0RTT was disabled. >>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256,

<    1   2   3   4   5   6   7   8   9   10   >