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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 --
`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
> > 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
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
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
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
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
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
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
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
%[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
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
%[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
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
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
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
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
%[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
:
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
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
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
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
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
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
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
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.
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 -
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
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
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
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
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
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
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
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
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 +
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
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 :
>
>
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,
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,
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
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
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
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
: 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
201 - 300 of 414 matches
Mail list logo