Re: [PATCH v2 0/4] add set server ssl command

2020-10-07 Thread William Dauchy
Hello, adding some more thoughts we discussed internally with Pierre: - we started to use `show servers state`, as it was the only way to get the current config for the parameters we wanted to change with the existing runtime API. - even if it was not necessarily designed for that purpose, we need

Re: [PATCH v2 0/4] add set server ssl command

2020-10-06 Thread William Dauchy
Hello William, Thank you for your answer. On Tue, Oct 6, 2020 at 7:17 PM William Lallemand wrote: > The problem with activating SSL on-the-fly is that SSL is not only an > on/off option but there are a lot of parameters that can be configured, > and that won't fit the server state file. I fear i

[PATCH] DOC: ssl: fix typo about ocsp files

2020-10-06 Thread William Dauchy
one of the last I saw in this section while working on github issue #872 might be backported in all still supported versions Signed-off-by: William Dauchy --- doc/configuration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/configuration.txt b/doc/configuration.txt

Re: [PATCH v2 3/4] MINOR: ssl: create common ssl_ctx init

2020-10-05 Thread William Dauchy
On Mon, Oct 5, 2020 at 9:45 AM Tim Düsterhus wrote: > Unfortunately this still does not build without USE_OPENSSL=1. I'll give > my log output in case you misunderstood me the first time: dumb me, I was so sure of the issue, that I tested with USE_OPENSSL=0 hopefully a CI can review those things

[PATCH v3 4/4] MINOR: cli/ssl: configure ssl on server at runtime

2020-10-05 Thread William Dauchy
init ctx when enabling ssl - call `destroy_srv` to deinit ctx when disabling ssl - update doc Signed-off-by: William Dauchy --- doc/management.txt | 3 +++ include/haproxy/ssl_sock.h | 1 + src/server.c | 16 +++- src/ssl_sock.c | 23

[PATCH v3 3/4] MINOR: ssl: create common ssl_ctx init

2020-10-05 Thread William Dauchy
so we can reuse it later Signed-off-by: William Dauchy --- include/haproxy/ssl_sock.h | 1 + src/cfgparse-ssl.c | 46 -- 2 files changed, 20 insertions(+), 27 deletions(-) diff --git a/include/haproxy/ssl_sock.h b/include/haproxy/ssl_sock.h index

[PATCH v3 0/4] add set server ssl command

2020-10-05 Thread William Dauchy
anged in v2: - patch1/4: reorder parameters to match format string - patch3/4: reorder includes, error introduced while splitting my patch. changed in v3: - reorg to allow build without USE_OPENSSL --- William Dauchy (4): MINOR: cli/proxy: add `srv_use_ssl` to `show servers state` MINOR

[PATCH v3 1/4] MINOR: cli/proxy: add `srv_use_ssl` to `show servers state`

2020-10-05 Thread William Dauchy
The aim is to be able to hot change `ssl` parameter for each server. Signed-off-by: William Dauchy --- doc/management.txt | 1 + include/haproxy/server-t.h | 3 ++- src/proxy.c| 5 +++-- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/management.txt b

[PATCH v3 2/4] MINOR: ssl: protect ssl_sock_prepare_srv_ctx from double ctx allocation

2020-10-05 Thread William Dauchy
this will be useful if we want to be able to call it at runtime through the CLI. Not 100% mandatory but might be a good protection for future use. Signed-off-by: William Dauchy --- src/ssl_sock.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src

[PATCH v2 0/4] add set server ssl command

2020-10-04 Thread William Dauchy
anged in v2: - patch1/4: reorder parameters to match format string - patch3/4: reorder includes, error introduced while splitting my patch. --- William Dauchy (4): MINOR: cli/proxy: add `srv_use_ssl` to `show servers state` MINOR: ssl: protect ssl_sock_prepare_srv_ctx from double ctx alloc

[PATCH v2 4/4] MINOR: cli/ssl: configure ssl on server at runtime

2020-10-04 Thread William Dauchy
init ctx when enabling ssl - call `destroy_srv` to deinit ctx when disabling ssl - update doc Signed-off-by: William Dauchy --- doc/management.txt | 3 +++ include/haproxy/server.h | 1 + src/server.c | 33 - 3 files changed, 36 insertions

[PATCH v2 2/4] MINOR: ssl: protect ssl_sock_prepare_srv_ctx from double ctx allocation

2020-10-04 Thread William Dauchy
this will be useful if we want to be able to call it at runtime through the CLI. Not 100% mandatory but might be a good protection for future use. Signed-off-by: William Dauchy --- src/ssl_sock.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src

[PATCH v2 3/4] MINOR: ssl: create common ssl_ctx init

2020-10-04 Thread William Dauchy
so we can reuse it later Signed-off-by: William Dauchy --- include/haproxy/server.h | 1 + src/cfgparse-ssl.c | 32 +++- src/server.c | 22 ++ 3 files changed, 26 insertions(+), 29 deletions(-) diff --git a/include/haproxy

[PATCH v2 1/4] MINOR: cli/proxy: add `srv_use_ssl` to `show servers state`

2020-10-04 Thread William Dauchy
The aim is to be able to hot change `ssl` parameter for each server. Signed-off-by: William Dauchy --- doc/management.txt | 1 + include/haproxy/server-t.h | 3 ++- src/proxy.c| 5 +++-- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/management.txt b

Re: [PATCH 3/4] MINOR: ssl: create common ssl_ctx init

2020-10-04 Thread William Dauchy
Hi Tim, Thank you for your answer. On Sun, Oct 4, 2020 at 12:46 PM Tim Düsterhus wrote: > This commit fails to build if USE_OPENSSL is not defined. good catch, I wrongly split my patch. fixed in v2. -- William

Re: [PATCH 1/4] MINOR: cli/proxy: add `srv_use_ssl` to `show servers state`

2020-10-04 Thread William Dauchy
Hi Tim, Thanks for your answer. On Sun, Oct 4, 2020 at 12:38 PM Tim Düsterhus wrote: > > - srvrecord ? srvrecord : "-"); > > + srvrecord ? srvrecord : "-", > > srv->use_ssl); > > But here you don't. From what I am seeing the line

[PATCH 1/4] MINOR: cli/proxy: add `srv_use_ssl` to `show servers state`

2020-10-03 Thread William Dauchy
The aim is to be able to hot change `ssl` parameter for each server. Signed-off-by: William Dauchy --- doc/management.txt | 1 + include/haproxy/server-t.h | 3 ++- src/proxy.c| 5 +++-- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/management.txt b

[PATCH 4/4] MINOR: cli/ssl: configure ssl on server at runtime

2020-10-03 Thread William Dauchy
init ctx when enabling ssl - call `destroy_srv` to deinit ctx when disabling ssl - update doc Signed-off-by: William Dauchy --- doc/management.txt | 3 +++ include/haproxy/server.h | 1 + src/server.c | 34 +- 3 files changed, 37 insertions

[PATCH 2/4] MINOR: ssl: protect ssl_sock_prepare_srv_ctx from double ctx allocation

2020-10-03 Thread William Dauchy
this will be useful if we want to be able to call it at runtime through the CLI. Not 100% mandatory but might be a good protection for future use. Signed-off-by: William Dauchy --- src/ssl_sock.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src

[PATCH 0/4] add set server ssl command

2020-10-03 Thread William Dauchy
facilitate the review. `ssl_sock_prepare_srv_ctx` protection is not mandatory but I found it safer while writing my patch. - the last one is adding the new command. I'm not 100% sure of the consequences of`prepare_srv` and `destroy_srv` but from what I read and tested, it seems ok. Wi

[PATCH 3/4] MINOR: ssl: create common ssl_ctx init

2020-10-03 Thread William Dauchy
so we can reuse it later Signed-off-by: William Dauchy --- include/haproxy/server.h | 1 + src/cfgparse-ssl.c | 31 ++- src/server.c | 21 + 3 files changed, 24 insertions(+), 29 deletions(-) diff --git a/include/haproxy

[PATCH] MINOR: ssl: remove uneeded check in crtlist_parse_file

2020-10-02 Thread William Dauchy
this condition is never true as we either break or goto error, so those two lines could be removed in the current state of the code. this is fixing github issue #862 Signed-off-by: William Dauchy --- src/ssl_crtlist.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/ssl_crtlist.c b

[PATCH 2/2] DOC: crt: advise to move away from cert bundle

2020-09-26 Thread William Dauchy
issue #872 this should probably be backported in >= v2.2 in order to encourage people to move away from bundle certificates loading. Signed-off-by: William Dauchy --- doc/configuration.txt | 7 ++- doc/management.txt| 4 2 files changed, 10 insertions(+), 1 deletion(-) diff --

[PATCH 1/2] DOC: agent-check: fix typo in "fail" word expected reply

2020-09-26 Thread William Dauchy
`tcpcheck_agent_expect_reply` expects "fail" not "failed" This should fix github issue #876 This can be backported to all maintained versions (i.e >= 1.6) as of today. Signed-off-by: William Dauchy --- doc/configuration.txt | 2 +- 1 file changed, 1 insertion(+), 1 de

Re: `ssl_fc_has_early` fetcher and 0rtt

2020-09-09 Thread William Dauchy
> > That seems strange indeed but looking at the code that's what I'm > > seeing. Was your access to ssl_fc_has_early placed before or after the > > rule above ? If it's after it must indeed report false. fetcher is placed before the rule > > I seem to remember there was one but can't find it, so

Re: `ssl_fc_has_early` fetcher and 0rtt

2020-09-09 Thread William Dauchy
Hello Willy, Thank you for your answer, On Wed, Sep 9, 2020 at 4:39 PM Willy Tarreau wrote: > If I remember well, the principle consists in detecting whether or not > the request was received using TLS early data (0-rtt) before the handshake > was completed. The problem is that early data may tr

Re: `ssl_fc_has_early` fetcher and 0rtt

2020-09-09 Thread William Dauchy
On Wed, Sep 9, 2020 at 10:48 AM William Dauchy wrote: > I'm trying to understand `ssl_fc_has_early` fetcher behavior as I'm > unable to find a single request where it returns 1. (sorry, forgot to mention, all of these tests were done on v2.2.x) -- William

`ssl_fc_has_early` fetcher and 0rtt

2020-09-09 Thread William Dauchy
Hello, I'm trying to understand `ssl_fc_has_early` fetcher behavior as I'm unable to find a single request where it returns 1. Our config has 0rtt enabled and it is as follow: ``` global log 127.0.0.1 format rfc5424 local0 info daemon stats socket /var/lib/haproxy/stats level admin m

Re: Logging using %HP (path) produce different results with H1 and H2

2020-08-21 Thread William Dauchy
Hello Pierre, On Fri, Aug 21, 2020 at 7:46 PM Pierre Cheynier wrote: > We're running HAProxy 2.2.2. > It turns out logging requests paths using "%HP" var produce a different > results on H1 vs. H2. > > H1: /path > H2: https://hostname.domain/path (< I consider this one buggy) > > No idea where d

Re: [PATCH v3 1/2] CLEANUP: ssl: ssl_sock_crt2der semicolon and spaces

2020-08-11 Thread William Dauchy
On Tue, Aug 11, 2020 at 11:36 AM William Lallemand wrote: > I just pushed this fix on top on your patch, the sk_X509_pop_free() was > provoking a double free in the session release. > > e3a5f84 BUG/MINOR: ssl: double free w/ smp_fetch_ssl_x_chain_der() ok sorry for that and thanks for the fix. St

[PATCH] CLEANUP: fix all duplicated semicolons

2020-08-07 Thread William Dauchy
trivial commit, does not change the code behaviour Signed-off-by: William Dauchy --- src/mux_fcgi.c | 2 +- src/mux_h2.c | 2 +- src/ring.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mux_fcgi.c b/src/mux_fcgi.c index 875049884..ab9ddf095 100644 --- a/src

[PATCH v3 1/2] CLEANUP: ssl: ssl_sock_crt2der semicolon and spaces

2020-08-06 Thread William Dauchy
trivial commit, does not change the code behaviour Signed-off-by: William Dauchy --- src/ssl_utils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ssl_utils.c b/src/ssl_utils.c index 510b5da80..0a12fea5b 100644 --- a/src/ssl_utils.c +++ b/src/ssl_utils.c

[PATCH v3 2/2] MINOR: ssl: add ssl_{c,s}_chain_der fetch methods

2020-08-06 Thread William Dauchy
%[ssl_c_chain_der,hex] One can parse it with any lib accepting ASN.1 DER data, such as in go: bin, err := encoding/hex.DecodeString(cert) certs_parsed, err := x509.ParseCertificates(bin) Cc: Arjen Nienhuis Signed-off-by: Mathilde Gilles Signed-off-by: William Dauchy --- v2: - add missing check

Re: [PATCH 2/2] MINOR: ssl: add ssl_c_chain_der fetch method

2020-08-05 Thread William Dauchy
On Wed, Aug 5, 2020 at 3:20 PM Emeric Brun wrote: > I think this code could be useful to declare also a "ssl_s_chain_der" using > minor changes as this is done on ssl_c_serial: true, I can do a v3 to handle this. -- William

[PATCH v2 2/2] MINOR: ssl: add ssl_c_chain_der fetch method

2020-08-05 Thread William Dauchy
%[ssl_c_chain_der,hex] One can parse it with any lib accepting ASN.1 DER data, such as in go: bin, err := encoding/hex.DecodeString(cert) certs_parsed, err := x509.ParseCertificates(bin) Cc: Arjen Nienhuis Signed-off-by: Mathilde Gilles Signed-off-by: William Dauchy --- Changes: v2: add return

[PATCH v2 1/2] CLEANUP: ssl: ssl_sock_crt2der semicolon and spaces

2020-08-05 Thread William Dauchy
trivial commit, does not change the code behaviour Signed-off-by: William Dauchy --- src/ssl_utils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ssl_utils.c b/src/ssl_utils.c index 510b5da80..0a12fea5b 100644 --- a/src/ssl_utils.c +++ b/src/ssl_utils.c

Re: [PATCH 0/2] ssl chain fetcher

2020-08-05 Thread William Dauchy
Hello William, Thanks for your quick answer. On Wed, Aug 5, 2020 at 2:41 PM William Lallemand wrote: > I don't know if this is possible to fix it, but I think must of the SSL > fetches have > the problem. ok makes sense in that case. So for now I assume there is no easy way to get the informat

[PATCH 0/2] ssl chain fetcher

2020-08-05 Thread William Dauchy
haproxy, and in which way. Indeed, as pointed by Emeric in https://www.mail-archive.com/haproxy@formilux.org/msg37380.html `SSL_get_peer_cert_chain` returns NULL in case of resumed session. Thanks, William Dauchy (2): CLEANUP: ssl: ssl_sock_crt2der semicolon and spaces MINOR: ssl: add

[PATCH 1/2] CLEANUP: ssl: ssl_sock_crt2der semicolon and spaces

2020-08-05 Thread William Dauchy
trivial commit, does not change the code behaviour Signed-off-by: William Dauchy --- src/ssl_utils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ssl_utils.c b/src/ssl_utils.c index 510b5da80..0a12fea5b 100644 --- a/src/ssl_utils.c +++ b/src/ssl_utils.c

[PATCH 2/2] MINOR: ssl: add ssl_c_chain_der fetch method

2020-08-05 Thread William Dauchy
%[ssl_c_chain_der,hex] One can parse it with any lib accepting ASN.1 DER data, such as in go: bin, err := encoding/hex.DecodeString(cert) certs_parsed, err := x509.ParseCertificates(bin) Cc: Arjen Nienhuis Signed-off-by: Mathilde Gilles Signed-off-by: William Dauchy --- doc/configuration.txt

Re: Haproxy 2.2 LTS package for Debian Stretch oldstable

2020-08-03 Thread William Dauchy
On Mon, Aug 3, 2020 at 10:31 PM Artur wrote: > It would be nice to have a Debian Stretch package for the current LTS > 2.2 branch in backports. It seems it's not available for now. CCing Vincent who is maintaining those packages. -- William

[PATCH 1/2] BUG/MINOR: spoa-server: fix size_t format printing

2020-08-01 Thread William Dauchy
ment. This should fix github issue #702 This should be backported to >= v2.2 Signed-off-by: William Dauchy --- contrib/spoa_server/ps_python.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/spoa_server/ps_python.c b/contrib/spoa_server/ps_python.c index 00cb0e

[PATCH 2/2] DOC: spoa-server: fix false friends `actually`

2020-08-01 Thread William Dauchy
it seems like `actually` was wrongly used instead of `currently` Signed-off-by: William Dauchy --- contrib/spoa_server/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/spoa_server/README b/contrib/spoa_server/README index f654a2321..a6c696c78 100644 --- a

Re: [ANNOUNCE] haproxy-2.3-dev1

2020-07-17 Thread William Dauchy
On Fri, Jul 17, 2020 at 3:33 PM Willy Tarreau wrote: > We'll try to emit more frequent -dev releases from now on, typically > every 2 weeks, as the end of the 2.2 cycle showed that it improves accuracy > in bug reports, brings less risks to users, and shortens the time needed to > write the announ

Re: [ANNOUNCE] haproxy-2.2-dev12

2020-07-04 Thread William Dauchy
Hello Willy, On Sat, Jul 4, 2020 at 8:11 AM Willy Tarreau wrote: > HAProxy 2.2-dev12 was released on 2020/07/04. It added 72 new commits > after version 2.2-dev11. maybe the package is being uploaded but I can't find it on http://www.haproxy.org/download/2.2/src/devel/ > - for developers, bui

Re: dev 2.2 High CPU Constantly

2020-07-02 Thread William Dauchy
Hi Igor, On Thu, Jul 2, 2020 at 9:57 AM Igor Pav wrote: > By using dev11, the CPU consumption drops a lot, but when connections > reach ~1000, the CPU would still go high, remove the 0rtt-rejected > from conf, the CPU becomes normal... if you have the opportunity to test the last HEAD of the rep

Re: [PATCH] BUG/MAJOR: Fix bogus free() during deinit() for http-request rules

2020-06-14 Thread William Dauchy
hat the configuration above no longer crashes. > It has also been verified that the configuration in > ff78fcdd7f15c8626c7e70add7a935221ee2920c > does not leak. Reported-by: William Dauchy > --- > src/haproxy.c | 1 - > src/vars.c| 7 +++ > 2 files changed, 7 insertions(+), 1 deletion(-) Best, -- William

Re: [PATCH 3/3] BUG/MINOR: haproxy: Free rule->arg.vars.expr during deinit_act_rules

2020-06-14 Thread William Dauchy
Hello, On Sun, Jun 14, 2020 at 7:40 AM Willy Tarreau wrote: > On Sun, Jun 14, 2020 at 12:37:43AM +0200, Tim Duesterhus wrote: > > careful with this one: I don't know whether it's safe to simply free the > > expression there or whether I need to somehow check whether there actually > > is some exp

Re: No access to git.haproxy.org from Travis CI

2020-06-13 Thread William Dauchy
Hi, On Thu, Jun 11, 2020 at 1:10 PM Willy Tarreau wrote: > Sure but what I wanted to say was that travis seems to be the only > point experiencing such difficulties and we don't know how it works > nor what are the rules in place. I don't know whether this is related to the issue described here

Re: dev 2.2 High CPU Constantly

2020-06-11 Thread William Dauchy
Hello Igor, On Thu, Jun 11, 2020 at 5:25 PM Igor Pav wrote: > We got a very high CPU constantly while using 2.2dev. Any suggestion? Thanks. Do you have more inputs of what you are doing to trigger that? does it end at some point with an abort? e.g do you have in logs things like "Thread X is abo

Re: [ANNOUNCE] haproxy-2.1.5

2020-06-03 Thread William Dauchy
Hello Arthur, On Wed, Jun 3, 2020 at 11:38 AM Artur wrote: > What is the risk to trigger this bug in real life ? How to avoid it > before the next haproxy release ? > In my setup haproxy 2.1.5 has threads enabled by default (Debian Buster > backports). You will trigger this issue if you are in t

Re: [ANNOUNCE] haproxy-2.1.5

2020-06-02 Thread William Dauchy
On Tue, Jun 2, 2020 at 12:13 PM William Dauchy wrote: > it seems like I broke something with this commit, but I did not have > it in v2.2 small followup: Sorry for that one, the backport was not exactly as I thought, and so no test were done before release outside of 2.2 branch: - a

[v2.0 PATCH] Revert "BUG/MEDIUM: connections: force connections cleanup on server changes"

2020-06-02 Thread William Dauchy
As explained by Christopher on github issue #665: In 2.2, srv->idle_conns and srv->safe_conns are thread-safe lists. But not in 2.1. So the patch must be reverted or the lists must be changed to use mt_list instead. The same must be done in 2.0, but the mt_list does not exist on this version. I ch

[v2.1 PATCH] Revert "BUG/MEDIUM: connections: force connections cleanup on server changes"

2020-06-02 Thread William Dauchy
As explained by Christopher on github issue #665: In 2.2, srv->idle_conns and srv->safe_conns are thread-safe lists. But not in 2.1. So the patch must be reverted or the lists must be changed to use mt_list instead. The same must be done in 2.0, but the mt_list does not exist on this version. I ch

Re: [ANNOUNCE] haproxy-2.1.5

2020-06-02 Thread William Dauchy
On Fri, May 29, 2020 at 4:31 PM William Lallemand wrote: > William Dauchy fixed the connection idle cleanup upon a server maintenance or > an ip/port change. > BUG/MEDIUM: connections: force connections cleanup on server changes it seems like I broke something with this commit,

Re: haproxy 2.2-dev8-7867525 - 100% cpu usage on 1 core after config 'reload'

2020-05-29 Thread William Dauchy
Hello Christopher, On Fri, May 29, 2020 at 9:02 AM Christopher Faulet wrote: > I was able to reproduce the bug. Thanks for the reproducer. I've fixed it. It > should be ok now. I believe you are referring to https://git.haproxy.org/?p=haproxy.git;a=commit;h=56192cc60b786f2c82925411d8b2ccd7d9f97d

Re: RFC: set minimum default TLS version to 1.2 for HAProxy 2.2

2020-05-29 Thread William Dauchy
On Wed, May 27, 2020 at 12:42 PM William Lallemand wrote: > So in my opinion we should do the same, and set the minimum version to > TLSv12 by default on bind lines. It's still configurable with > min-ssl-ver if you want the support for prior TLS versions. > Does anybody have any objections? Even

Re: [PR] Add verfied chain

2020-05-18 Thread William Dauchy
Hi Arjen, On Mon, May 18, 2020 at 6:02 PM Arjen Nienhuis wrote: > I used PKCS7 because I did not know how to parse concatenated blobs. Mathilde, how did we planned to use it? :) > I think you should use SSL_get_peer_cert_chain because: > - BoringSSL has no SSL_get0_verified_chain. > - For debug

Re: [PR] Add verfied chain

2020-05-18 Thread William Dauchy
On Mon, May 18, 2020 at 3:58 PM William Lallemand wrote: > I suppose it was put in a PKCS7 container to be able to distinguish each > DER part of the chain easily? So It can be used by an external tool. I'm not > sure of what is done with the result of this. > > The two patches seem to have differ

Re: [PR] Add verfied chain

2020-05-18 Thread William Dauchy
Hello William L., On Wed, Dec 4, 2019 at 4:24 PM PR Bot wrote: > Patch title(s): >MINOR: add fetch 'ssl_c_verified_chain' >Merge branch 'master' of https://github.com/haproxy/haproxy > Link: >https://github.com/haproxy/haproxy/pull/396 > Edit locally: >wget https://github.com/hapr

[PATCH] BUILD: ssl: include buffer common headers for ssl_sock_ctx

2020-05-17 Thread William Dauchy
: include/types/ssl_sock.h:240:16: error: field ‘early_buf’ has incomplete type 240 | struct buffer early_buf; /* buffer to store the early data received */ no backport needed. Fixes: c0cdaffaa338 ("REORG: ssl: move ssl_sock_ctx and fix cross-dependencies issues") Signed-of

Re: [PATCH 1/3] BUG/MINOR: pollers: remove uneeded free in global init

2020-05-13 Thread William Dauchy
On Wed, May 13, 2020 at 03:52:54PM +0200, Willy Tarreau wrote: > > This one breaks clang builds because it removes the fail_revt label but it > > is > > still declared as a local label, and clang errors on it. > > Ah crap! I didn't notice this part which didn't appear in the context > of the patc

Re: [PATCH 2/3] BUG/MINOR: select: remove uneeded free in thread init

2020-05-13 Thread William Dauchy
On Wed, May 13, 2020 at 11:50:50AM +0200, Willy Tarreau wrote: > It's not a bug, it's just a way to ensure a common error path undoes > everything that was done before reaching it. If another operation is > added after the DIR_WR malloc, it will only have to add its own undo > operation to the fail

Re: [RFC PATCH 1/1] MEDIUM: ssl: add alternative way to load certificates with io_uring

2020-05-11 Thread William Dauchy
On Mon, May 11, 2020 at 5:32 PM William Lallemand wrote: > By removing, it just means: > - In the case of a directory there is basicaly nothing to do but remove > the bundle code, everything will be loaded as usual, it will just be > done in separate SSL_CTX. > - In the configuration, if you s

Re: [RFC PATCH 1/1] MEDIUM: ssl: add alternative way to load certificates with io_uring

2020-05-11 Thread William Dauchy
Hello William L. Thank you for your answer. On Mon, May 11, 2020 at 1:01 PM William Lallemand wrote: > I'm wondering if we coud have the timing directly in the logs or on the > CLI, because I'm actually also doing this kind of things, and people > could probably optimize the loading if they coul

Re: [RFC PATCH 0/1] using io_uring to load certificates

2020-05-11 Thread William Dauchy
Hello Willy, Thank you for your feedbacks. On Sat, May 9, 2020 at 6:39 AM Willy Tarreau wrote: > Your work could be extended to other files, like errorfiles, maps, ACLs, > etc. However with the config parser being very linear, it's extremely > unlikely that we could actually benefit from this in

[PATCH 3/3] CLEANUP: select: enhance readability in init

2020-05-11 Thread William Dauchy
while reading the code, I thought it was clearer to put one instruction per line as it is mostly done elsewhere Signed-off-by: William Dauchy --- src/ev_select.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/ev_select.c b/src/ev_select.c index 167bb7eb7

[PATCH 1/3] BUG/MINOR: pollers: remove uneeded free in global init

2020-05-11 Thread William Dauchy
lper for all threads, making those free uneeded. Only poll and select are affected by this very minor issue. it could be backported from v1.8 to v2.1. Fixes: cd7879adc2c4 ("BUG/MEDIUM: threads: Run the poll loop on the main thread too") Signed-off-by: William Dauchy --- src/ev_poll.

[PATCH 2/3] BUG/MINOR: select: remove uneeded free in thread init

2020-05-11 Thread William Dauchy
we wrongly free `tmp_evts[DIR_RD]` in error case. it could be backported from v1.8 to v2.1. Fixes: d4604adeaa8c ("MAJOR: threads/fd: Make fd stuffs thread-safe") Signed-off-by: William Dauchy --- src/ev_select.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff -

[PATCH 0/3] minor fixes for pollers

2020-05-11 Thread William Dauchy
Hello, Here are a few minor fixes on pollers as I'm currently spending some time in this area. William Dauchy (3): BUG/MINOR: pollers: remove uneeded free in global init BUG/MINOR: select: remove uneeded free in thread init CLEANUP: select: enhance readability in init src/ev_p

Re: Proposal to resolve (again) the include dependency hell

2020-05-09 Thread William Dauchy
On Sat, May 09, 2020 at 12:48:30PM +0200, Willy Tarreau wrote: > I prefer to warn, this is long and only of interest for those who code, > so don't force yourself to digest this if not necessary :-) nice summary as always! > In the end I think that would leave us more or less with this: > - cre

[RFC PATCH 1/1] MEDIUM: ssl: add alternative way to load certificates with io_uring

2020-05-08 Thread William Dauchy
sts were performed on >= v5.7rc4 as the time of writing. it introduces three build parameters: - USE_IO_URING - IO_URING_INC - IO_URING_LIB Signed-off-by: William Dauchy --- Makefile | 10 +- doc/io_uring.txt | 18 +++ include/proto/ssl_load.h | 23 include/types

[RFC PATCH 0/1] using io_uring to load certificates

2020-05-08 Thread William Dauchy
se of async, but that's another story. see also https://kernel.dk/io_uring.pdf for more info about io_uring. William Dauchy (1): MEDIUM: ssl: add alternative way to load certificates with io_uring Makefile | 10 +- doc/io_uring.txt | 18 +++ include/proto/ssl_lo

Re: [ANNOUNCE] haproxy-2.2-dev7

2020-05-05 Thread William Dauchy
Hello, Thank you for this release update! On Tue, May 5, 2020 at 11:46 PM Willy Tarreau wrote: > HAProxy 2.2-dev7 was released on 2020/05/05. It added 205 new commits > after version 2.2-dev6. > > The most visible changes in this version is the rework of the health checks > that was started by G

Re: [PATCH] CLEANUP: connections: align function declaration

2020-05-04 Thread William Dauchy
On Mon, May 04, 2020 at 01:56:10PM +0200, William Dauchy wrote: > Sorry for this one, I originally did update the server.h file, but I > don't know why I forgot to add it in my patch submission :/ > then I saw you fixed it while pushing my commit, thank you for this. I'm talki

Re: [PATCH] CLEANUP: connections: align function declaration

2020-05-04 Thread William Dauchy
Hello Olivier, Sorry for this one, I originally did update the server.h file, but I don't know why I forgot to add it in my patch submission :/ then I saw you fixed it while pushing my commit, thank you for this. On Mon, May 04, 2020 at 01:52:40PM +0200, William Dauchy wrote: > this patc

[PATCH] CLEANUP: connections: align function declaration

2020-05-04 Thread William Dauchy
this patch should be backported where commit 6318d33ce625 ("BUG/MEDIUM: connections: force connections cleanup on server changes") will be backported, that is to say v1.9 to v2.1. Fixes: 6318d33ce625 ("BUG/MEDIUM: connections: force connections cleanup on server changes") Si

Re: [PATCH 1/1] BUG/MEDIUM: connections: force connections cleanup on server changes

2020-05-02 Thread William Dauchy
On Sat, May 02, 2020 at 10:17:01PM +0200, Olivier Houchard wrote: > If that's the only change you have for a v2, don't bother, I already > integrated it in what I plan to push :) ok, thanks a lot! -- William

Re: [PATCH 0/1] fix idle connections cleanup

2020-05-02 Thread William Dauchy
Hello Olivier, On Sat, May 02, 2020 at 10:11:26PM +0200, Olivier Houchard wrote: > And I think your fix is correct, so I will apply it as-is. However, I > think it should be applied to previous branches, that also had idle > connection pools. It is probably less noticable before 079cb9af22da6, > b

Re: [PATCH 1/1] BUG/MEDIUM: connections: force connections cleanup on server changes

2020-05-02 Thread William Dauchy
On Sat, May 02, 2020 at 09:52:36PM +0200, William Dauchy wrote: > +void srv_cleanup_connections(struct server *srv) > +{ > + struct connection *conn; > + int did_remove; > + int i; > + int j; > + > + HA_SPIN_LOCK(OTHER_LOCK, &idle_conn_srv_

[PATCH 0/1] fix idle connections cleanup

2020-05-02 Thread William Dauchy
pproach is most likely not the good one but feel free to advise so I may improve it. William Dauchy (1): BUG/MEDIUM: connections: force connections cleanup on server changes include/proto/server.h | 1 + src/server.c | 37 - 2 files changed, 37 insert

[PATCH 1/1] BUG/MEDIUM: connections: force connections cleanup on server changes

2020-05-02 Thread William Dauchy
are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server

Re: [ANNOUNCE] haproxy-2.2-dev6

2020-04-28 Thread William Dauchy
On Tue, Apr 28, 2020 at 8:50 PM Willy Tarreau wrote: > So just to let you know, we could finally nail the issue down to a > change I did on mux-h1 at the end of dev4 (so dev5 is also affected). > Only front connections dying in a dirty way were affected (i.e. users > disappearing from the net afte

Re: [ANNOUNCE] haproxy-2.2-dev6

2020-04-27 Thread William Dauchy
Hello Willy, On Mon, Apr 27, 2020 at 7:29 PM Willy Tarreau wrote: > just a quick note, be careful with -dev6, monitor your FDs from time > to time. Today it caused an outage on haproxy.org after all FDs were > in use. Sadly we had skipped a number of -dev in the past, jumping > from something bet

Re: [PATCH] MINOR: config: make strict limits enabled by default

2020-03-28 Thread William Dauchy
On Sat, Mar 28, 2020 at 7:29 PM Lukas Tribus wrote: > master is still for 2.2 which is in development. If you want to target > v2.3, you have to wait until 2.2 is released. oh true, I'm mixing versions, probably because we already started to deploy part of v2.2... Sorry for that, please ignore t

[PATCH v2] MINOR: config: make strict limits enabled by default

2020-03-28 Thread William Dauchy
as agreed a few months ago, enable strict-limits for v2.3 update configuration manual accordingly Signed-off-by: William Dauchy --- doc/configuration.txt | 11 +-- src/cfgparse-global.c | 2 -- src/haproxy.c | 17 +++-- 3 files changed, 12 insertions(+), 18

[PATCH] MINOR: config: make strict limits enabled by default

2020-03-28 Thread William Dauchy
as agreed a few months ago, enable strict-limits for v2.3 Signed-off-by: William Dauchy --- src/cfgparse-global.c | 2 -- src/haproxy.c | 17 +++-- 2 files changed, 7 insertions(+), 12 deletions(-) diff --git a/src/cfgparse-global.c b/src/cfgparse-global.c index 0e6905976

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

2020-02-12 Thread William Dauchy
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 s

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

2020-02-12 Thread William Dauchy
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 1/2] BUG/MINOR: namespace: avoid closing fd when socket failed in my_socketat

2020-02-12 Thread William Dauchy
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: W

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

2020-02-12 Thread William Dauchy
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 +

[PATCH 0/2] namespace cleaning in my_socketat

2020-02-12 Thread William Dauchy
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

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

2020-02-12 Thread William Dauchy
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

2020-02-12 Thread William Dauchy
Signed-off-by: William Dauchy --- src/proto_tcp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/proto_tcp.c b/src/proto_tcp.c index a9d5229c9..044ade430 100644 --- a/src/proto_tcp.c +++ b/src/proto_tcp.c @@ -906,9 +906,9 @@ int tcp_bind_listener(struct listener *listener,

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

2020-02-12 Thread William Dauchy
Signed-off-by: William Dauchy --- src/proto_tcp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/proto_tcp.c b/src/proto_tcp.c index a9d5229c9..e509a17bc 100644 --- a/src/proto_tcp.c +++ b/src/proto_tcp.c @@ -906,9 +906,9 @@ int tcp_bind_listener(struct listener *listener,

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

2020-02-12 Thread William Dauchy
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: W

Re: [PATCH v2] BUG/MINOR: connection: fix ip6 dst_port copy in make_proxy_line_v2

2020-01-26 Thread William Dauchy
On Sun, Jan 26, 2020 at 11:06 PM Lukas Tribus wrote: > Just because commit 456 fixes something that has been introduced with > commit 123 DOES NOT mean we backport 456 to all the branches that 123 > was committed to - instead we backport 456 to a certain branch if it > *actually* makes sense to do

Re: [PATCH v2] BUG/MINOR: connection: fix ip6 dst_port copy in make_proxy_line_v2

2020-01-26 Thread William Dauchy
On Sun, Jan 26, 2020 at 8:17 PM Julien Pivotto wrote: > That will not work with cherry-picked commits. that's what I nuanced in the previous email you quoted indeed. -- William

Re: [PATCH v2] BUG/MINOR: connection: fix ip6 dst_port copy in make_proxy_line_v2

2020-01-26 Thread William Dauchy
On Sun, Jan 26, 2020 at 7:56 PM Tim Düsterhus wrote: > Yes, and because this is so easy to look up I simply add both the commit > and the first version to my commit message to save the person doing the > backporting the brain cycles. Backporting appears to mostly be a bulk > process and I can imag

[PATCH v4] BUG/MINOR: dns: allow 63 char in hostname

2020-01-26 Thread William Dauchy
: William Dauchy --- src/dns.c | 31 +-- 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/src/dns.c b/src/dns.c index eefd8d0dc..28d47d26c 100644 --- a/src/dns.c +++ b/src/dns.c @@ -1470,7 +1470,6 @@ int dns_str_to_dn_label(const char *str, int str_len, char

<    1   2   3   4   5   >