On Thu, May 23, 2024 at 03:58:45PM +0100, William Manley wrote:
> I can also report that I no longer need to avoid `nbthread 1` in the config
> on the node. Presumably thanks to ceebb09744df367ad84586a341d9336f84f72bce
> "rhttp: fix preconnect on single-thread".
BTW keep in mind that connections
{
/* first cache line */
enum obj_type obj_type; /* differentiates connection from applet context */
unsigned char err_code; /* CO_ER_* */
- signed short send_proxy_ofs; /* <0 = offset to (re)send from the end, >0 = send all (reused for SOCKS4) */
+ signed short send_proxy_o
quot;rhttp: fix preconnect on single-thread".
Indeed. I completely forgot this issue and re-stumbled onto it while
implementing the latest rhttp features.
--
Amaury Denoyelle
On Thu, May 23, 2024, at 3:52 PM, William Manley wrote:
> On Thu, May 23, 2024, at 3:45 PM, Amaury Denoyelle wrote:
> > On Thu, May 23, 2024 at 02:47:15PM +0100, William Manley wrote:
> > > On Thu, May 23, 2024, at 2:08 PM, Amaury Denoyelle wrote:
> > > > On Thu, May 23, 2024 at 11:55:13AM +0100,
On Thu, May 23, 2024, at 3:45 PM, Amaury Denoyelle wrote:
> On Thu, May 23, 2024 at 02:47:15PM +0100, William Manley wrote:
> > On Thu, May 23, 2024, at 2:08 PM, Amaury Denoyelle wrote:
> > > On Thu, May 23, 2024 at 11:55:13AM +0100, William Manley wrote:
> > > > On Thu, May 23, 2024, at 11:34 AM,
On Thu, May 23, 2024 at 02:47:15PM +0100, William Manley wrote:
> On Thu, May 23, 2024, at 2:08 PM, Amaury Denoyelle wrote:
> > On Thu, May 23, 2024 at 11:55:13AM +0100, William Manley wrote:
> > > On Thu, May 23, 2024, at 11:34 AM, William Manley wrote:
> > > > On Thu, May 23, 2024, at 10:08 AM,
On Thu, May 23, 2024, at 2:08 PM, Amaury Denoyelle wrote:
> On Thu, May 23, 2024 at 11:55:13AM +0100, William Manley wrote:
> > On Thu, May 23, 2024, at 11:34 AM, William Manley wrote:
> > > On Thu, May 23, 2024, at 10:08 AM, Amaury Denoyelle wrote:
> > > > On Wed, May 22, 2024 at 04:58:44PM
On Thu, May 23, 2024 at 11:55:13AM +0100, William Manley wrote:
> On Thu, May 23, 2024, at 11:34 AM, William Manley wrote:
> > On Thu, May 23, 2024, at 10:08 AM, Amaury Denoyelle wrote:
> > > On Wed, May 22, 2024 at 04:58:44PM +0100, William Manley wrote:
> > > > On Wed, May 22, 2024, at 1:06 PM,
On Thu, May 23, 2024, at 11:34 AM, William Manley wrote:
> On Thu, May 23, 2024, at 10:08 AM, Amaury Denoyelle wrote:
> > On Wed, May 22, 2024 at 04:58:44PM +0100, William Manley wrote:
> > > On Wed, May 22, 2024, at 1:06 PM, Amaury Denoyelle wrote:
> > > > FYI, I just merged a series of fix to
On Thu, May 23, 2024, at 10:08 AM, Amaury Denoyelle wrote:
> On Wed, May 22, 2024 at 04:58:44PM +0100, William Manley wrote:
> > On Wed, May 22, 2024, at 1:06 PM, Amaury Denoyelle wrote:
> > > FYI, I just merged a series of fix to improve reverse HTTP. It is now
> > > possible to use PROXY
On Wed, May 22, 2024 at 04:58:44PM +0100, William Manley wrote:
> On Wed, May 22, 2024, at 1:06 PM, Amaury Denoyelle wrote:
> > FYI, I just merged a series of fix to improve reverse HTTP. It is now
> > possible to use PROXY protocol on preconnect stage. Also, you have the
> > availability to use
On Wed, May 22, 2024, at 1:06 PM, Amaury Denoyelle wrote:
> FYI, I just merged a series of fix to improve reverse HTTP. It is now
> possible to use PROXY protocol on preconnect stage. Also, you have the
> availability to use PROXY v2 TLV to differentiate connections. Note
> however that PROXY
On Tue, May 14, 2024, at 3:48 PM, Amaury Denoyelle wrote:
> On Wed, May 08, 2024 at 11:43:11AM +0100, William Manley wrote:
> > An attach-srv config line usually looks like this:
> > tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
> > while a rhttp server line usually looks like
On Wed, May 15, 2024 at 09:41:42PM +0200, Ilia Shipitsin wrote:
> Subject: [PATCH] CI: scripts/build-ssl.sh: loudly fail on unsupported
> platforms
> ---
> scripts/build-ssl.sh | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/build-ssl.sh b/scripts/build-ssl.sh
> index
On Tue, May 14, 2024 at 04:48:16PM +0200, Amaury Denoyelle wrote:
> On Wed, May 08, 2024 at 11:43:11AM +0100, William Manley wrote:
> > An attach-srv config line usually looks like this:
> > tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
> > while a rhttp server line usually looks
Hi.
I have added fcgi trace
```
global
log stdout format raw daemon debug
pidfile /data/haproxy/run/haproxy.pid
# maxconn auto config from hap
# nbthread auto config from hap
master-worker
#tune.comp.maxlevel 5
expose-experimental-directives
trace fcgi sink stdout
On Sun, May 12, 2024 at 05:08:34PM +0200, Tim Duesterhus wrote:
> When support for UUIDv7 was added in commit
> aab6477b67415c4cc260bba5df359fa2e6f49733
> the specification still was a draft.
>
> It has since been published as RFC 9562.
Excellent timing ;-)
Now merged, thank you Tim!
Willy
Hi Guys,
Was this something you needed?
I'd appreciate an answer. Happy to help.
Best wishes,
Sami
On Mon, May 6, 2024 at 1:10 PM M Sami Kerrouche <
s...@londonmedialounge.co.uk> wrote:
> Hi,
>
> I am waiting for you on our call that you booked.
>
> Let me know if you'd like to reschedule.
>
On Wed, May 08, 2024 at 11:43:11AM +0100, William Manley wrote:
> An attach-srv config line usually looks like this:
> tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
> while a rhttp server line usually looks like this:
> server srv rhttp@ sni req.hdr(host)
> The server sni
пн, 13 мая 2024 г. в 11:29, William Lallemand :
> On Thu, May 09, 2024 at 10:24:55PM +0200, Илья Шипицин wrote:
> > sorry for th delay.
> >
> > indeed, it's better to drop asan redirection. I sent a patch to the list.
> >
> > for my defence I can say that in my experiments asan.log worked as
>
On Thu, May 09, 2024 at 10:19:17PM +0200, Ilia Shipitsin wrote:
> for some reasons it appeared to be a good idea
> to collect ASAN log separately from VTest error logs,
> but also it appeared to work poorly in real life (compared to
> specially prepared synthetic environments).
>
> let drop
On Thu, May 09, 2024 at 10:24:55PM +0200, Илья Шипицин wrote:
> sorry for th delay.
>
> indeed, it's better to drop asan redirection. I sent a patch to the list.
>
> for my defence I can say that in my experiments asan.log worked as expected
> :)
>
No worries, we had a change of distribution
an HTTP-Enpoint, reporting the MySQL-state.
Then haproxy is making a HTTP-Request for monitoring and allows us to configure
expected response code & content.
Cheers
Marno
Von: Willy Tarreau
Datum: Freitag, 10. Mai 2024 um 14:28
An: Iglesias Paz, Jaime
Cc: haproxy@formilux.org
Betreff: [EXT
Hello,
On Fri, May 10, 2024 at 12:00:17PM +, Iglesias Paz, Jaime wrote:
> Hey guys, I have a problem with HAProxy and Galera Cluster v4 MySQL (3
> nodes). I boot the HAProxy server and it returns the following error:
>
> may 10 13:48:20 phaproxysql1 haproxy[661]: Proxy stats started.
> may
On Mon, May 06, 2024 at 08:16:34PM +0200, Björn Jacke wrote:
> On 06.05.24 15:34, Shawn Heisey wrote:
> > On 5/6/24 06:02, Björn Jacke wrote:
> > > frontend ft_443
> > > bind :::443 ssl crt /ssl/combined.pem
> > > bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
> > > option
On Wed, May 08, 2024 at 01:19:22PM +, Dorian Craps wrote:
> first of all, thank you for your interest.
>
> I already made a version with an option to enable MPTCP
> -https://github.com/CrapsDorian/haproxy/pull/1
>
> I'm working on a new version with "mptcp@address" as Willy requested.
OK,
first of all, thank you for your interest.
I already made a version with an option to enable MPTCP
-https://github.com/CrapsDorian/haproxy/pull/1
I'm working on a new version with "mptcp@address" as Willy requested.
Dorian
On Thu, Apr 25, 2024, at 2:07 PM, Amaury Denoyelle wrote:
> Sorry for the delay. We have rediscussed this issue this morning and
> here is my answer on your patch.
Sorry for the even larger delay in responding :). Thanks for looking at this.
> It is definitely legitimate to want to be able to
Hi Dominik,
On Thu, 2 May 2024 at 17:14, Froehlich, Dominik
wrote:
The closest I’ve gotten is the “curves” property:
https://docs.haproxy.org/2.8/configuration.html#5.1-curves
However, I think it only restricts the available elliptic curves in a ECDHE
handshake, but it does not prevent a
Hi!
On Tue, May 07, 2024 at 02:23:02AM +, PR Bot wrote:
> Author: zhibin.zhu
> Number of patches: 1
>
> This is an automated relay of the Github pull request:
>fix show-sess-to-flags.sh cob fd state
(...)
> From 95be08c6f4f382ec1b0e34765d4c1f09ddcdebb6 Mon Sep 17 00:00:00 2001
> From:
hi and sorry for the long reply.
I will let you know once it is officially release, it needs to pass our QA
test still.
Kind regards.
On Mon, 6 May 2024 at 22:52, Mahendra Patil
wrote:
> any update when we can get 3.2.3 release
>
> On Wed, Apr 3, 2024 at 10:51 AM David CARLIER wrote:
>
>>
any update when we can get 3.2.3 release
On Wed, Apr 3, 2024 at 10:51 AM David CARLIER wrote:
> Hi all,
>
> Thanks for your report. This is a known issue the 3.2.3 release is
> scheduled within this month.
>
> Regards.
>
> On Wed, 3 Apr 2024 at 04:38, Willy Tarreau wrote:
>
>> Hello,
>>
>> On
On 06.05.24 15:34, Shawn Heisey wrote:
On 5/6/24 06:02, Björn Jacke wrote:
frontend ft_443
bind :::443 ssl crt /ssl/combined.pem
bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
option tcp-smart-accept
http-after-response add-header alt-svc 'h3=":443"; ma=600;
persistent=1'
On 5/6/24 06:02, Björn Jacke wrote:
frontend ft_443
bind :::443 ssl crt /ssl/combined.pem
bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
option tcp-smart-accept
http-after-response add-header alt-svc 'h3=":443"; ma=600; persistent=1'
frontend ft_quic_test
mode tcp
, and we can
likely consider that new attacks targeting this protocol will pop up as
it becomes widespread.
In fact, that's already the case:
See: CVE-2024-26708: mptcp: really cope with fastopen race
or CVE-2024-26826: mptcp: fix data re-injection from stale subflow
or CVE-2024-26782 kernel
On Sun, May 05, 2024 at 01:43:33PM +0200, ??? wrote:
> updated patches.
Cool, thanks, now applied.
> I'll address reorg to "compat.h" a bit later, once it is settled in my head
No worries, I've seen your other comment about the need to include
pthread.h, and this alone would be a good
updated patches.
I'll address reorg to "compat.h" a bit later, once it is settled in my head
вс, 5 мая 2024 г. в 12:48, Илья Шипицин :
> I will test and send simplified patch, i.e. I'll patch directly clock.c
>
> if we want to move that macro to compat.h, I'd postpone that for some
>
I will test and send simplified patch, i.e. I'll patch directly clock.c
if we want to move that macro to compat.h, I'd postpone that for some
investigation
1) we will need to include "pthread.h" from compat.h (currently it's not
true)
2) we will need to make sure compat.h is included everywhere
On Sun, May 05, 2024 at 11:15:24AM +0200, ??? wrote:
> ??, 5 ??? 2024 ?. ? 10:42, Willy Tarreau :
>
> > On Sun, May 05, 2024 at 09:12:41AM +0200, Miroslav Zagorac wrote:
> > > On 05. 05. 2024. 08:32, Willy Tarreau wrote:
> > > > On Sun, May 05, 2024 at 07:49:55AM +0200, ???
вс, 5 мая 2024 г. в 10:42, Willy Tarreau :
> On Sun, May 05, 2024 at 09:12:41AM +0200, Miroslav Zagorac wrote:
> > On 05. 05. 2024. 08:32, Willy Tarreau wrote:
> > > On Sun, May 05, 2024 at 07:49:55AM +0200, ??? wrote:
> > >> ??, 5 ??? 2024 ?. ? 02:05, Miroslav Zagorac :
> > >>> I think
On Sun, May 05, 2024 at 09:12:41AM +0200, Miroslav Zagorac wrote:
> On 05. 05. 2024. 08:32, Willy Tarreau wrote:
> > On Sun, May 05, 2024 at 07:49:55AM +0200, ??? wrote:
> >> ??, 5 ??? 2024 ?. ? 02:05, Miroslav Zagorac :
> >>> I think that this patch is not satisfactory because, for
On Sun, May 05, 2024 at 08:52:08AM +0200, ??? wrote:
> > I'm wondering what the point of defining _POSIX_THREAD_CPUTIME can be
> > then :-/
> >
> > Just guessing, are you sure you're building with -pthread -lrt ? Just in
> > case, please double-check with V=1. Solaris sets USE_RT, but
On 05. 05. 2024. 08:32, Willy Tarreau wrote:
> On Sun, May 05, 2024 at 07:49:55AM +0200, ??? wrote:
>> ??, 5 ??? 2024 ?. ? 02:05, Miroslav Zagorac :
>>> I think that this patch is not satisfactory because, for example, Solaris
>>> 11.4.0.0.1.15.0 (from 2018) has _POSIX_TIMERS and
вс, 5 мая 2024 г. в 08:32, Willy Tarreau :
> On Sun, May 05, 2024 at 07:49:55AM +0200, ??? wrote:
> > ??, 5 ??? 2024 ?. ? 02:05, Miroslav Zagorac :
> >
> > > On 04. 05. 2024. 17:36, Ilya Shipitsin wrote:
> > > > this function is considered optional for POSIX and not implemented
> > > >
On Sun, May 05, 2024 at 07:49:55AM +0200, ??? wrote:
> ??, 5 ??? 2024 ?. ? 02:05, Miroslav Zagorac :
>
> > On 04. 05. 2024. 17:36, Ilya Shipitsin wrote:
> > > this function is considered optional for POSIX and not implemented
> > > on Illumos
> > >
> > > Reference:
> >
вс, 5 мая 2024 г. в 02:05, Miroslav Zagorac :
> On 04. 05. 2024. 17:36, Ilya Shipitsin wrote:
> > this function is considered optional for POSIX and not implemented
> > on Illumos
> >
> > Reference:
> https://www.gnu.org/software/gnulib/manual/html_node/pthread_005fgetcpuclockid.html
> >
On 04. 05. 2024. 17:36, Ilya Shipitsin wrote:
> this function is considered optional for POSIX and not implemented
> on Illumos
>
> Reference:
> https://www.gnu.org/software/gnulib/manual/html_node/pthread_005fgetcpuclockid.html
> According to
>
On Thu, 2 May 2024 at 19:50, Lukas Tribus wrote:
>
> On Thu, 2 May 2024 at 17:14, Froehlich, Dominik
> wrote:
> > The closest I’ve gotten is the “curves” property:
> > https://docs.haproxy.org/2.8/configuration.html#5.1-curves
> >
> > However, I think it only restricts the available elliptic
On Tue, Apr 30, 2024 at 04:11:25PM +0200, Ilia Shipitsin wrote:
> NetBSD image was updated to 10.0, pcre2 is available out
> of box now
(...)
Both merged now, thank you Ilya!
Willy
On Thu, 2 May 2024 at 17:14, Froehlich, Dominik
wrote:
> The closest I’ve gotten is the “curves” property:
> https://docs.haproxy.org/2.8/configuration.html#5.1-curves
>
> However, I think it only restricts the available elliptic curves in a ECDHE
> handshake, but it does not prevent a TLS 1.3
On Thu, 2 May 2024 at 15:22, Roberto Carna wrote:
>
> Dear all, I have HAproxy in front of a web server node.
>
> I want the web server node to accept just 1000 concurrent connections.
>
> So I want to use the maxconn parameter in order to let new connections
> above 1000 to wait until the web
I'd try openssl.cnf
чт, 2 мая 2024 г. в 17:17, Froehlich, Dominik :
> Hello everyone,
>
>
>
> I’m hardening HAProxy for CVE-2002-20001 (DHEAT attack) at the moment.
>
>
>
> For TLS 1.2 I’m using the “tune.ssl.default-dh-param” option to limit the
> key size to 2048 bit so that an attacker can’t
Hi,
I can forward the pricing and other details for your consideration.
awaiting for positive response.
Bonny Rodger
From: Bonny Rodger
Sent: Monday, April 22, 2024 4:37 PM
To: haproxy@formilux.org
Subject: Updated list RSA Conference 2024
Hi,
Recently updated Attendees contacts of RSA
Hi there,
Hope all is well!
I'm following up on my previous email.
Just wondering if you received it.
Please let me know if you are interested in a new article for your website.
Cheers,
*Raddie Kalytenko*
On Thu, Apr 25, 2024 at 5:45 PM Raddie Kalytenko
wrote:
> Hi there,
> I hope you are
Hi,
On Sat, Apr 27, 2024 at 02:06:54AM +0200, Aleksandar Lazic wrote:
> Hi Lokesh.
>
> On 2024-04-27 (Sa.) 01:41, Lokesh Jindal wrote:
> > Hey folks
> >
> > I have found that there is no operator "del-cookie" in HAProxy to delete
> > cookies from the request. (HAProxy does support the operator
Hi Lokesh.
On 2024-04-27 (Sa.) 01:41, Lokesh Jindal wrote:
Hey folks
I have found that there is no operator "del-cookie" in HAProxy to delete cookies
from the request. (HAProxy does support the operator "del-header").
Can you explain why such an operator is not supported? Is it due to
> 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
On 4/26/24 10:51, Aurelien DARRAGON wrote:
This is expected because forwarded cannot be used on frontend unlike
forwardfor:
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?
I was
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'
v1 addresses them, and we can
>> likely consider that new attacks targeting this protocol will pop up as
>> it becomes widespread.
>>
>> In fact, that's already the case:
>>
>> See: CVE-2024-26708: mptcp: really cope with fastopen race
>> or CVE-2024-26826: m
becomes widespread.
Indeed, any new features (or code in general) can bring security issues.
Same for the protocol. Here it looks like MPTCPv1 addressed all reported
issues [1].
> In fact, that's already the case:
>
> See: CVE-2024-26708: mptcp: really cope with fastopen race
> or C
On Thu, Apr 25, 2024 at 08:15:30PM +0200, Tim Düsterhus wrote:
> Hi
>
> On 4/24/24 08:39, Willy Tarreau wrote:
> > Just thinking about all the shifts above, I think you could have
> > gone through less efforts by acting on 64-bit randoms (less shifts).
> > But the difference is probably not that
Hi
On 4/24/24 08:39, Willy Tarreau wrote:
Just thinking about all the shifts above, I think you could have
gone through less efforts by acting on 64-bit randoms (less shifts).
But the difference is probably not that much anyway.
I've used the existing implementation for UUIDv4 as the basis,
Hi William !
Sorry for the delay. We have rediscussed this issue this morning and
here is my answer on your patch.
It is definitely legitimate to want to be able to use reverse HTTP
without SSL on the server line. However, the way that haproxy currently
uses idle connection is that at least the
spread.
>
> In fact, that's already the case:
>
> See: CVE-2024-26708: mptcp: really cope with fastopen race
> or CVE-2024-26826: mptcp: fix data re-injection from stale subflow
> or CVE-2024-26782 kernel: mptcp: fix double-free on socket dismantle
>
> The three CVEs above are all
fix data re-injection from stale subflow
or CVE-2024-26782 kernel: mptcp: fix double-free on socket dismantle
The three CVEs above are all from April 2024.
Given that MPTCP v1 is relatively new (2020), and that we do not have
real assurances that it is at least as secure as plain TCP, I would
hum
On Wed, Apr 24, 2024 at 09:53:04AM +0100, David CARLIER wrote:
> -- Forwarded message -
> From: David CARLIER
> Date: Wed, 24 Apr 2024 at 07:56
> Subject: Re: [PATCH] MEDIUM: shctx naming shared memory context
> To: Willy Tarreau
>
>
> Here a
Hi David,
On Sat, Apr 20, 2024 at 07:33:16AM +0100, David CARLIER wrote:
> From d49d9d5966caead320f33f789578cb69f2aa3787 Mon Sep 17 00:00:00 2001
> From: David Carlier
> Date: Sat, 20 Apr 2024 07:18:48 +0100
> Subject: [PATCH] MEDIUM: shctx: Naming shared memory context
>
> From Linux 5.17,
Hi Tim!
On Fri, Apr 19, 2024 at 09:01:26PM +0200, Tim Duesterhus wrote:
> +/* Generates a draft-ietf-uuidrev-rfc4122bis-14 version 7 UUID into chunk
> + * which must be at least 37 bytes large.
> + */
> +void ha_generate_uuid_v7(struct buffer *output)
> +{
> + uint32_t rnd[3];
> +
Hi Tim,
On Tue, Apr 23, 2024 at 09:03:32PM +0200, Tim Düsterhus wrote:
> Hi
>
> On 4/19/24 21:07, Willy Tarreau wrote:
> > it! I'll have a look on Monday, I'm really done for this week, need to
>
> Monday is gone. So here's a friendly reminder :-)
Yeah and I'm sorry, my week started with two
Hi
On 4/19/24 21:07, Willy Tarreau wrote:
it! I'll have a look on Monday, I'm really done for this week, need to
Monday is gone. So here's a friendly reminder :-)
Best regards
Tim Düsterhus
I'll postpone for a while.
I thought that value of "2" is the same as "1", I'll try to find better doc.
seems that I didn''t specify "march" and that might be the cause.
сб, 20 апр. 2024 г. в 15:21, Willy Tarreau :
> On Sat, Apr 20, 2024 at 03:11:19PM +0200, ??? wrote:
> > ??, 20 ???.
On Sat, Apr 20, 2024 at 03:11:19PM +0200, ??? wrote:
> ??, 20 ???. 2024 ?. ? 15:07, Willy Tarreau :
>
> > On Sat, Apr 20, 2024 at 02:49:38PM +0200, ??? wrote:
> > > ??, 11 ???. 2024 ?. ? 21:05, Willy Tarreau :
> > >
> > > > Hi Ilya,
> > > >
> > > > On Thu, Apr 11, 2024 at
сб, 20 апр. 2024 г. в 15:07, Willy Tarreau :
> On Sat, Apr 20, 2024 at 02:49:38PM +0200, ??? wrote:
> > ??, 11 ???. 2024 ?. ? 21:05, Willy Tarreau :
> >
> > > Hi Ilya,
> > >
> > > On Thu, Apr 11, 2024 at 08:27:39PM +0200, ??? wrote:
> > > > do you know maybe how this was
On Sat, Apr 20, 2024 at 02:49:38PM +0200, ??? wrote:
> ??, 11 ???. 2024 ?. ? 21:05, Willy Tarreau :
>
> > Hi Ilya,
> >
> > On Thu, Apr 11, 2024 at 08:27:39PM +0200, ??? wrote:
> > > do you know maybe how this was supposed to work ?
> > > haproxy/Makefile at master ·
чт, 11 апр. 2024 г. в 21:05, Willy Tarreau :
> Hi Ilya,
>
> On Thu, Apr 11, 2024 at 08:27:39PM +0200, ??? wrote:
> > do you know maybe how this was supposed to work ?
> > haproxy/Makefile at master · haproxy/haproxy (github.com)
> >
On Mon, Apr 15, 2024 at 10:18:19AM +0200, Aleksandar Lazic wrote:
> Hi.
>
> The "https://github.com/criteo/haproxy-spoe-go; is archived since Nov 7,
> 2023 and there is a fork from that repo https://github.com/go-spop/spoe
> Can we add this info to the wiki page?
>
> There is also a rust
Hi Tim!
On Fri, Apr 19, 2024 at 09:01:24PM +0200, Tim Duesterhus wrote:
> Willy,
>
> as requested in the thread "[ANNOUNCE] haproxy-3.0-dev7":
>
> > Regarding UUIDs, though, I've recently come across UUIDv7 which I found
> > particularly interesting, and that I think would be nice to implement
On Fri, Apr 19, 2024 at 07:16:44AM +0200, Ilya Shipitsin wrote:
> let's modernize macos CI build matrix since macos-14 is available
Merged, thank you Ilya!
willy
on my experiments, asan log was grouped under "show vtest results".
on provided branch indeed there are no grouping.
I'll play a bit, maybe we'll end with dropping that log redirection
ср, 17 апр. 2024 г. в 21:17, William Lallemand :
> On Sun, Apr 14, 2024 at 09:23:51AM +0200, Ilya Shipitsin
On Sun, Apr 14, 2024 at 09:23:51AM +0200, Ilya Shipitsin wrote:
> previously ASAN_OPTIONS=log_path=asan.log was intended for VTest
> execution only, it should not affect "haproxy -vv" and hsproxy
> config smoke testing
> ---
> .github/workflows/vtest.yml | 5 +++--
> 1 file changed, 3
On Sun, Apr 14, 2024 at 09:23:50AM +0200, Ilya Shipitsin wrote:
> the main part is reducing ASAN_OPTIONS scope, it was supposed
> only to capture output of vtests, accidently it covered "config smoke tests"
> as well
(...)
Both merged, thank you Ilya!
willy
Hi Abhijeet,
On Mon, Apr 15, 2024 at 09:48:25PM -0700, Abhijeet Rastogi wrote:
> Hi Willy,
>
> Thank you for your patience with my questions.
You're welcome!
> > It happens that the global struct is only changed during startup
>
> I used cli_parse_set_maxconn_global as a reference for my
Hi Willy,
Thank you for your patience with my questions.
> It happens that the global struct is only changed during startup
I used cli_parse_set_maxconn_global as a reference for my patch and my
understanding is, it does have a race as I do not see
thread_isolate().
Hi Abhijeet,
On Mon, Apr 08, 2024 at 08:11:28PM -0700, Abhijeet Rastogi wrote:
> Hi HAproxy community,
>
> Let's assume that HAproxy starts with non-zero values for close-spread-time
> and hard-stop-after, and soft-stop is used to initiate the shutdown during
> deployments.
> There are times
d user). They can be justified for ultra-complex
> projects but quite frankly, having to imagine not being able to flip
> an option without rebuilding everything, not having something as simple
> as "V=1" to re-run the failed file and see exactly what was tried,
> having to f
re really really a pain to deal with, at every
stage (development and user). They can be justified for ultra-complex
projects but quite frankly, having to imagine not being able to flip
an option without rebuilding everything, not having something as simple
as "V=1" to re-run the failed fil
On Sat, Apr 13, 2024 at 09:50:33AM +0200, ??? wrote:
> It has been resolved on image generation side
> https://github.com/actions/runner-images/issues/9491
>
> It is no harm to keep it on our side as well, but we can drop it
Perfect, now merged, thank you Ilya!
Willy
It has been resolved on image generation side
https://github.com/actions/runner-images/issues/9491
It is no harm to keep it on our side as well, but we can drop it
On Fri, Apr 12, 2024, 18:55 Willy Tarreau wrote:
> On Fri, Apr 12, 2024 at 12:42:51PM +0200, ??? wrote:
> > ping :)
>
>
On Fri, Apr 12, 2024 at 10:23:02AM +, PR Bot wrote:
> Dear list!
>
> Author: Andrey Lebedev
> Number of patches: 1
>
> This is an automated relay of the Github pull request:
>DOC: management: fix typos
(...)
Now merged, thank you Andrey!
Willy
On Fri, Apr 12, 2024 at 12:42:51PM +0200, ??? wrote:
> ping :)
Ah thanks for the reminder. I noticed it a few days ago and I wanted to
ask you to please include a commit message explaining why it's no longer
necessary. We don't need much, just to understand the rationale for the
removal.
On Fri, Apr 12, 2024, at 4:01 PM, Amaury Denoyelle wrote:
> I have a doubt though, will this kind of configuration really works ? I
> though that for the moment if name parameter is specified, it is
> mandatory to use a server with SSL+SNI.
It may be mandatory according to the RFC, but I'm not
On Fri, Apr 12, 2024 at 05:01:07PM +0200, Amaury Denoyelle wrote:
> On Fri, Apr 12, 2024 at 03:37:56PM +0200, Willy Tarreau wrote:
> > Hi!
> > On Fri, Apr 12, 2024 at 02:29:30PM +0100, William Manley wrote:
> > > An attach-srv config line usually looks like this:
> > > > tcp-request session
On Fri, Apr 12, 2024, at 2:37 PM, Willy Tarreau wrote:
> Well, I consider that any valid (and useful) configuration must be
> writable without a warning. So if you have a valid use case with a
> different expression, here you still have no way to express it without
> the warning. In this case I'd
On Fri, Apr 12, 2024 at 03:37:56PM +0200, Willy Tarreau wrote:
> Hi!
> On Fri, Apr 12, 2024 at 02:29:30PM +0100, William Manley wrote:
> > An attach-srv config line usually looks like this:
> > > tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
> > > The name is a key that is used
Hi!
On Fri, Apr 12, 2024 at 02:29:30PM +0100, William Manley wrote:
> An attach-srv config line usually looks like this:
>
> tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
>
> The name is a key that is used when looking up connections in the
> connection pool. Without this patch
ping :)
сб, 6 апр. 2024 г. в 15:38, Ilya Shipitsin :
> hack introduced in 3a0fc8641b1549b00cd3125107545b6879677801 might be
> reverted
>
> Ilya Shipitsin (1):
> CI: revert kernel entropy introduced in
> 3a0fc8641b1549b00cd3125107545b6879677801
>
> .github/workflows/vtest.yml | 11
Hi Willy,
> On 11 Apr 2024, at 18:18, Willy Tarreau wrote:
>
> Some distros simply found that stuffing their regular CFLAGS into
> DEBUG_CFLAGS or CPU_CFLAGS does the trick most of the time. Others use
> other combinations depending on the tricks they figured.
Good to know I wasn’t alone
On Thu, Apr 11, 2024 at 11:43:14PM +0200, Dinko Korunic wrote:
> Subject: Re: Changes in HAProxy 3.0's Makefile and build options
>
> > On 11.04.2024., at 21:32, William Lallemand wrote:
> >
> > If I remember correctly github actions VMs only had 2 vCPU in the past,
&
> On 11.04.2024., at 21:32, William Lallemand wrote:
>
> If I remember correctly github actions VMs only had 2 vCPU in the past,
> I think they upgraded to 4 vCPU last year but I can't find anything in
> their documentation.
Hi William,
GitHub runners Instance sizes for public repositories
1 - 100 of 28959 matches
Mail list logo
