[PATCH] BUG/MINOR: tcp: don't try to set defaultmss when value is negative

when `getsockopt` previously failed, we were trying to set defaultmss with -2 value. this is a followup of github issue #499 this should be backported to all versions >= v1.8 Fixes: 153659f1ae69a1 ("MINOR: tcp: When binding socket, attempt to reuse one from the old proc.") Signed-off-by:

[PATCH] BUG/MINOR: tcp: avoid closing fd when socket failed in tcp_bind_listener

we were trying to close file descriptor even when `socket` call was failing. this should fix github issue #499 this should be backported to all versions >= v1.8 Fixes: 153659f1ae69a1 ("MINOR: tcp: When binding socket, attempt to reuse one from the old proc.") Signed-off-by: William Dauchy ---

Re : haproxy.com: New ways to improve your google Ranking.

Hi* haproxy.com * Warm greetings of the day. We hope this email finds you well as this is concerning your website *haproxy.com .* We had a glance at the current status of your *haproxy.com * and came across a huge room of improvement.

Re: payload inspection using req.payload

Hi Micha, > My problem is that the "req.payload(0,10)" fetch, which I am using for > that purpose, does not seem to reliably have access to the payload at > all times. The problem is not the fetch per se, it is the timing of the evaluation of the rule: tcp-request content rules are evaluated

payload inspection using req.payload

Hi everyone, writing to get some help on a setup I am building with haproxy. Part of the setup is a content inspection of the tcp payload (binary stream), for which the load balancing will be done. Testing with content inspection based on simple ACL pattern matches but also tried evaluating the

Re: payload inspection using req.payload

Hey Mathias, wow, brilliant! Made my day, really! - I was about getting frustrated during troubleshooting :) That was exactly what I needed. Thanks a bunch! Failed to find something like that, because I was not exactly knowing what to search for. > As a side note: In case you want to match the

Re: spoa-mirror

Hi Dmitry. Please keep the mailing-list in the loop, thanks. On 12.02.20 08:17, Дмитрий Меркулов wrote: Hello Aleks Information about version, haproxy and spoa-agent conf in the attachment. HA-Proxy version 2.1.0 2019/11/25 - https://haproxy.org/ Status: stable branch - will stop receiving

Re: [PATCH] BUG/MINOR: tcp: don't try to set defaultmss when value is negative

On Wed, Feb 12, 2020 at 01:16:15PM +0100, William Dauchy wrote: > getsockopt(fd, IPPROTO_TCP, TCP_MAXSEG, , ); > - if (tmpmaxseg != defaultmss && setsockopt(fd, IPPROTO_TCP, > - TCP_MAXSEG, , > -

Re: [PATCH v2] BUG/MINOR: tcp: don't try to set defaultmss when value is negative

On Wed, Feb 12, 2020 at 03:53:04PM +0100, William Dauchy wrote: > when `getsockopt` previously failed, we were trying to set defaultmss > with -2 value. Now merged, thanks William. Willy

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

List, Willy, [removed bot from Cc] Am 09.02.20 um 01:00 schrieb stable-...@haproxy.com: > This is a friendly bot that watches fixes pending for the next haproxy-stable > release! One such e-mail is sent periodically once patches are waiting in > the last maintenance branch, and an ideal

Re: [PATCH] travis-ci: remove "allow failures", add ERR=1, modernize build-ssl.sh script

Hi Ilya, series now applied, thanks! Willy

Re: [PATCH] BUG/MINOR: tcp: don't try to set defaultmss when value is negative

On Wed, Feb 12, 2020 at 03:32:07PM +0100, Willy Tarreau wrote: > I'd do it differently so that we neither try nor report an error if > the default mss was not set. Indeed, if it already failed earlier, > we already had an issue, so no need to fail again. So if you agree > I'll change it to : > >

[PATCH v2] BUG/MINOR: tcp: don't try to set defaultmss when value is negative

when `getsockopt` previously failed, we were trying to set defaultmss with -2 value. this is a followup of github issue #499 this should be backported to all versions >= v1.8 Fixes: 153659f1ae69a1 ("MINOR: tcp: When binding socket, attempt to reuse one from the old proc.") Signed-off-by:

Re: [PATCH] BUG/MINOR: tcp: avoid closing fd when socket failed in tcp_bind_listener

On Wed, Feb 12, 2020 at 10:09:14AM +0100, William Dauchy wrote: > we were trying to close file descriptor even when `socket` call was > failing. > this should fix github issue #499 > > this should be backported to all versions >= v1.8 Now merged, thanks! Willy

Re: [PATCH v3] MINOR: build: add aix72-gcc build TARGET and power{8,9} CPUs

Hi Chris, On Wed, Feb 12, 2020 at 08:25:36AM +0100, Chris wrote: > I agree! I just made a new patch which adds the missing documentation > for the new build-TARGET as well as the two new CPU-types. Perfect, now applied. Thanks for taking care of the doc as well! Don't worry for the "newbie

unsubscribe

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

Willy, Am 12.02.20 um 16:36 schrieb Tim Düsterhus: > 1. Can we get a 2.1 release in the next days? I'm primarily asking > because of the backported Lua package path patches :-) Talk about timing. I'm seeing a 2.1.3 tag in git now. So ignore that point (1). Best regards Tim Düsterhus

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

Hi Tim, On Wed, Feb 12, 2020 at 04:36:58PM +0100, Tim Düsterhus wrote: > > Thus the computed ideal release date for 2.1.3 would be 2020/02/03, which > > was one week ago. > > [...] > > --- > > The haproxy stable-bot is freely provided by HAProxy Technologies to help > > improve the quality of

[ANNOUNCE] haproxy-2.1.3

Hi, HAProxy 2.1.3 was released on 2020/02/12. It added 86 new commits after version 2.1.2. It's clear that 2.1 has been one of the calmest releases in a while, to the point of making us forget that it still had a few fixes pending that would be pleasant to have in a released version! So after

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

Willy, Am 12.02.20 um 18:09 schrieb Willy Tarreau: > Hi Tim, > > On Wed, Feb 12, 2020 at 04:36:58PM +0100, Tim Düsterhus wrote: >>> Thus the computed ideal release date for 2.1.3 would be 2020/02/03, which >>> was one week ago. >>> [...] >>> --- >>> The haproxy stable-bot is freely provided by

Re: [PATCH 2/2] CLEANUP: namespace: remove uneeded ns check in my_socketat

On Thu, Feb 13, 2020 at 01:31:51AM +0500, Илья Шипицин wrote: > we "use" it. > depending on true/false we either return -1 or not I guess it is present in the first condition to be able to access `ns->fd` safely in setns; but the second condition does not acces `ns` later. -- William

[PATCH 2/2] CLEANUP: namespace: remove uneeded ns check in my_socketat

we check ns variable but we don't use it later Signed-off-by: William Dauchy --- src/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/namespace.c b/src/namespace.c index 89a968e36..3536629bc 100644 --- a/src/namespace.c +++ b/src/namespace.c @@ -120,7 +120,7

[PATCH 0/2] namespace cleaning in my_socketat

Two minor patches for namespace. William Dauchy (2): BUG/MINOR: namespace: avoid closing fd when socket failed in my_socketat CLEANUP: namespace: remove uneeded ns check in my_socketat src/namespace.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.25.0

[PATCH 1/2] BUG/MINOR: namespace: avoid closing fd when socket failed in my_socketat

we cannot return right after socket opening as we need to move back to the default namespace first this should fix github issue #500 this might be backported to all version >= 1.6 Fixes: b3e54fe387c7c1 ("MAJOR: namespace: add Linux network namespace support") Signed-off-by: William Dauchy ---

Re: [PATCH 2/2] CLEANUP: namespace: remove uneeded ns check in my_socketat

чт, 13 февр. 2020 г. в 01:26, William Dauchy : > we check ns variable but we don't use it later > we "use" it. depending on true/false we either return -1 or not > > Signed-off-by: William Dauchy > --- > src/namespace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Mirror concepts

Hi I need quick helping for HAproxy mirroring concepts Thanks Panneer

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

Hi Daniel, On Wed, Feb 12, 2020 at 06:47:07PM -0500, Daniel Corbett wrote: > I'll do what I can to improve it starting with working on moving these items > to a thread and increasing the calculations for expected release dates for > older branches. Probably we can start simple for the

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

Hello, On 2/12/20 12:55 PM, Tim Düsterhus wrote: Threading would solve most of the pain points for me, because the emails will nicely be merged on both my computer and my phone. For the remaining points I don't really care that much. I'll leave this up to the people that actually read the

Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1

On 12 Feb 18:47, Daniel Corbett wrote: > Hello, > > > On 2/12/20 12:55 PM, Tim Düsterhus wrote: > > > > Threading would solve most of the pain points for me, because the emails > > will nicely be merged on both my computer and my phone. For the > > remaining points I don't really care that

Re: Mirror concepts

Hi. Feb 13, 2020 1:04:58 AM Panneer Selvam : > Hi I need quick helping for HAproxy mirroring concepts Please can you tell us a little bit more what you need and please answer to all, thanks. Have you read an understand the post?

is it allowed to bind both http and https on the same port ?

hello, while playing with dataplane api (I copy-pasted code), accidentally I created the following config frontend git_example_com_https_frontend mode http bind 10.216.7.1:7080 name http bind 10.216.7.1:7080 name https crt /etc/haproxy/bundle.pem ssl alpn h2,http/1.1 default_backend

Re: how to properly reload haproxy (from systemd + master-worker) ?

I confirm that adding "no option start-on-reload" resolves the reload issue. I'll report to dataplane documentation. вт, 4 февр. 2020 г. в 16:01, William Lallemand : > On Tue, Feb 04, 2020 at 12:48:18AM +0500, Илья Шипицин wrote: > > > > вс, 2 февр. 2020 г. в 22:58, Tim Düsterhus : > > > > > >

Re: [PATCH 2/2] CLEANUP: namespace: remove uneeded ns check in my_socketat

On Thu, Feb 13, 2020 at 07:48:03AM +0100, Willy Tarreau wrote: > For me it's different, it's not related to the fact that it's used > later but to the fact that we only need to undo the namespace change > if it was changed in the first call. Indeed "ns" is not null only > when the caller wants to

Re: [PATCH 2/2] CLEANUP: namespace: remove uneeded ns check in my_socketat

On Wed, Feb 12, 2020 at 09:42:06PM +0100, William Dauchy wrote: > On Thu, Feb 13, 2020 at 01:31:51AM +0500, ??? wrote: > > we "use" it. > > depending on true/false we either return -1 or not > > I guess it is present in the first condition to be able to access > `ns->fd` safely in setns;

Re: is it allowed to bind both http and https on the same port ?

On Thu, Feb 13, 2020 at 11:40:08AM +0500, ??? wrote: > hello, > while playing with dataplane api (I copy-pasted code), accidentally I > created the following config > > frontend git_example_com_https_frontend > mode http > bind 10.216.7.1:7080 name http > bind 10.216.7.1:7080 name