[PATCH] DOC: update INSTALL with supported OpenBSD / FreeBSD versions
Update INSTALL with the OpenBSD / FreeBSD versions that are supported. diff --git a/INSTALL b/INSTALL index 04b034908..f562a7102 100644 --- a/INSTALL +++ b/INSTALL @@ -375,10 +375,10 @@ and assign it to the TARGET variable : - linux-glibc-legacy for Linux kernel 2.6.28 and above without new features - linux-musl for Linux kernel 2.6.28 and above with musl libc - solaris for Solaris 10 and above - - freebsd for FreeBSD 5 to 12 (others untested) + - freebsd for FreeBSD 10 and above - netbsd for NetBSD - osx for Mac OS/X - - openbsd for OpenBSD 5.7 and above + - openbsd for OpenBSD 6.3 and above - aix51 for AIX 5.1 - aix52 for AIX 5.2 - aix72-gcc for AIX 7.2 (using gcc)
Re: [PATCH] MINOR: ssl: remove uneeded check in crtlist_parse_file
On Fri, Oct 02, 2020 at 03:27:20PM +0200, William Dauchy wrote: > 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/src/ssl_crtlist.c > index 3c94bcf99..3f09c8673 100644 > --- a/src/ssl_crtlist.c > +++ b/src/ssl_crtlist.c > @@ -599,9 +599,6 @@ int crtlist_parse_file(char *file, struct bind_conf > *bind_conf, struct proxy *cu > } > } > } > - if (cfgerr & ERR_CODE) > - goto error; > - > entry = NULL; > } > Thanks, merged. -- William Lallemand
[PATCH] MINOR: ssl: remove uneeded check in crtlist_parse_file
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/src/ssl_crtlist.c index 3c94bcf99..3f09c8673 100644 --- a/src/ssl_crtlist.c +++ b/src/ssl_crtlist.c @@ -599,9 +599,6 @@ int crtlist_parse_file(char *file, struct bind_conf *bind_conf, struct proxy *cu } } } - if (cfgerr & ERR_CODE) - goto error; - entry = NULL; } -- 2.28.0
Incomplete Chunked Answer
Hi everyone, I have a problem very similar to this one https://github.com/haproxy/haproxy/issues/231 and I need help how to approach it correctly. This issue is sporadic, and occurs far more often with 2.1.8 than with 2.2.3. But in the LTS it is still present. I have a FastCGI Backend, that is providing a big response (KBs to MBs) which will be forwarded as a chunked HTTP answer by the haproxy. A Wireshark dump shows that sometimes the haproxy will close the connection after sending two chunks (~16KB each) and no end chunk (no idea how big the answer should have been). This issue occurs during automatic tests in my company. But with just a simple, minimal FastCGI example I was not able to reproduce it. Do you have any recommendations how I can approach this and how to isolate this problem? Thanks and best regards, Harris
Re: [PR] SOCKS4(A)
Le 02/10/2020 à 08:58, Willy Tarreau a écrit :
So if anyone currently uses socks4 to talk to servers, I suggest you
run a quick test on 2.2 or 2.3 to see if health checks continue to work
over socks4 or not, in which case it's likely you'll be able to provide
an easier reproducer that will allow to fix the problem. This will save
everyone time and protect our eyeballs by keeping them away from this
blinking patch.
There is indeed a bug. The flag CO_FL_SOCKS4 is set after the connect() for
tcp-checks, making the health-checks though a socks4 proxy fail. Here is a patch
to fix this bug. I will push it very soon.
Remains the support of the SOCKS4A in Alex patches. But I will let anyone
motivated by this part working on it :)
--
Christopher Faulet
>From 18c4c8b281c0a5ee9b345dadbb13c1559f0c254b Mon Sep 17 00:00:00 2001
From: Christopher Faulet
Date: Fri, 2 Oct 2020 13:41:55 +0200
Subject: [PATCH] BUG/MINOR: tcpcheck: Set socks4 and send-proxy flags before
the connect call
Since the health-check refactoring in the 2.2, the checks through a socks4 proxy
are broken. To fix this bug, CO_FL_SOCKS4 flag must be set on the connection
before calling the connect() callback function because this flags is checked to
use the right destination address. The same is done for the CO_FL_SEND_PROXY
flag for a consistency purpose.
This patch must be backported to 2.2.
---
src/tcpcheck.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/tcpcheck.c b/src/tcpcheck.c
index 5bd237ad6..b9ef3802b 100644
--- a/src/tcpcheck.c
+++ b/src/tcpcheck.c
@@ -1073,6 +1073,24 @@ enum tcpcheck_eval_ret tcpcheck_eval_connect(struct check *check, struct tcpchec
conn_prepare(conn, proto, xprt);
cs_attach(cs, check, &check_conn_cb);
+ if ((connect->options & TCPCHK_OPT_SOCKS4) && s && (s->flags & SRV_F_SOCKS4_PROXY)) {
+ conn->send_proxy_ofs = 1;
+ conn->flags |= CO_FL_SOCKS4;
+ }
+ else if ((connect->options & TCPCHK_OPT_DEFAULT_CONNECT) && s && s->check.via_socks4 && (s->flags & SRV_F_SOCKS4_PROXY)) {
+ conn->send_proxy_ofs = 1;
+ conn->flags |= CO_FL_SOCKS4;
+ }
+
+ if (connect->options & TCPCHK_OPT_SEND_PROXY) {
+ conn->send_proxy_ofs = 1;
+ conn->flags |= CO_FL_SEND_PROXY;
+ }
+ else if ((connect->options & TCPCHK_OPT_DEFAULT_CONNECT) && s && s->check.send_proxy && !(check->state & CHK_ST_AGENT)) {
+ conn->send_proxy_ofs = 1;
+ conn->flags |= CO_FL_SEND_PROXY;
+ }
+
status = SF_ERR_INTERNAL;
next = get_next_tcpcheck_rule(check->tcpcheck_rules, rule);
if (proto && proto->connect) {
@@ -1102,23 +1120,6 @@ enum tcpcheck_eval_ret tcpcheck_eval_connect(struct check *check, struct tcpchec
else if ((connect->options & TCPCHK_OPT_DEFAULT_CONNECT) && s && s->check.alpn_str)
ssl_sock_set_alpn(conn, (unsigned char *)s->check.alpn_str, s->check.alpn_len);
#endif
- if ((connect->options & TCPCHK_OPT_SOCKS4) && s && (s->flags & SRV_F_SOCKS4_PROXY)) {
- conn->send_proxy_ofs = 1;
- conn->flags |= CO_FL_SOCKS4;
- }
- else if ((connect->options & TCPCHK_OPT_DEFAULT_CONNECT) && s && s->check.via_socks4 && (s->flags & SRV_F_SOCKS4_PROXY)) {
- conn->send_proxy_ofs = 1;
- conn->flags |= CO_FL_SOCKS4;
- }
-
- if (connect->options & TCPCHK_OPT_SEND_PROXY) {
- conn->send_proxy_ofs = 1;
- conn->flags |= CO_FL_SEND_PROXY;
- }
- else if ((connect->options & TCPCHK_OPT_DEFAULT_CONNECT) && s && s->check.send_proxy && !(check->state & CHK_ST_AGENT)) {
- conn->send_proxy_ofs = 1;
- conn->flags |= CO_FL_SEND_PROXY;
- }
if (conn_ctrl_ready(conn) && (connect->options & TCPCHK_OPT_LINGER)) {
/* Some servers don't like reset on close */
--
2.26.2
Re: [PATCH v2 1/2] CLEANUP: ssl: Use structured format for error line report during crt-list parsing
On Tue, Sep 29, 2020 at 06:00:27PM +0200, Tim Duesterhus wrote: > This reuses the known `parsing [%s:%d]:` from regular config file error > reporting. On Tue, Sep 29, 2020 at 06:00:28PM +0200, Tim Duesterhus wrote: > Similar to warning during the parsing of the regular configuration file > that was added in 2fd5bdb439da29f15381aeb57c51327ba57674fc this patch adds > a warning to the parsing of a crt-list if the file does not end in a > newline (and thus might have been truncated). > > The logic essentially just was copied over. It might be good to refactor > this in the future, allowing easy re-use within all line-based config > parsers. > > see https://github.com/haproxy/haproxy/issues/860#issuecomment-693422936 > see 0354b658f061d00d5ab4b728d7deeff2c8f1503a > > This should be backported as a warning to 2.2. Thanks, both merged. -- William Lallemand
Re: [PR] SOCKS4(A)
On Fri, Oct 02, 2020 at 01:51:36PM +0500, ??? wrote: > vtc is not very well suited for complex things like frontend + socks + > backend I disagree. It's possible to send/receive hex, we don't need more. We can simply have a server which first receives the socks4 preface, then the request, then sends back the socks4 preface and the response. It's enough to do the job fine and detect breakage. > I'm thinking of "multi container github actions" (it is announced, but we > never tried it yet) I don't know how that works, but I don't see how having multiple containers helps doing things that we couldn't do in a single one. But let's see once someone has time for this :-) Willy
Re: [PR] SOCKS4(A)
пт, 2 окт. 2020 г. в 12:58, Willy Tarreau : > On Fri, Oct 02, 2020 at 12:49:02PM +0500, ??? wrote: > > > Alex also sent me a piece of config supposed to reproduce the socks4 > > > regression regarding the checks, but I haven't tested yet, and since it > > > seems to include some private parts, it will have to be cleaned up > first. > > > > > > > > > can we add a ticket for that ? > > I asked him to add one but instead he sent me his config. Feel free to do > so if you want so that we don't forget. In the worst case we'll close it > if it was a false alarm. > > > looks like we can add automated testing based on that (like low priority > > weekly job on github) > > Or it could simply be yet-another-vtc. > vtc is not very well suited for complex things like frontend + socks + backend I'm thinking of "multi container github actions" (it is announced, but we never tried it yet) > > Willy >
Re: [PR] SOCKS4(A)
On Fri, Oct 02, 2020 at 12:49:02PM +0500, ??? wrote: > > Alex also sent me a piece of config supposed to reproduce the socks4 > > regression regarding the checks, but I haven't tested yet, and since it > > seems to include some private parts, it will have to be cleaned up first. > > > > > can we add a ticket for that ? I asked him to add one but instead he sent me his config. Feel free to do so if you want so that we don't forget. In the worst case we'll close it if it was a false alarm. > looks like we can add automated testing based on that (like low priority > weekly job on github) Or it could simply be yet-another-vtc. Willy
Re: [PR] SOCKS4(A)
пт, 2 окт. 2020 г. в 11:58, Willy Tarreau : > Guys, > > quick note, Alex contacted me offline saying his PR will be deleted > soon, asked me to save it before this happens (which I did) and not to > be contacted anymore (which I totally respect and kindly ask anyone else > to respect). > > He insisted that socks4 with tcp-checks is currently broken, which is > perfectly possible. It's impossible to figure anything from his mind- > blowing patch set anyway, since more than 95% of it is pure obfuscation > achieved using automatic and bogus reindent by an editor obviously not > configured for the C language, making the patches huge and extremely > unreadable, as tiny changes are probably hidden there. The only way to > figure the changes would actually be to compile and compare the binaries > to figure what changed! The remaining 5% seem to be debug code, hacks > such as reserving some hard-coded IP addresses to flag certain features, > and some features I don't even understand given that the code goes back > and forth along the patches and changes do not even match what the title > suggests. Also it was apparently only built on 32-bit as I spotted a few > "%u" with a size_t. Some sample fetches seem to have been removed by > accident during the refactoring. I have the series still available as > an mbox if someone ever wants to dig into it by curiosity or to learn > how not to contribute to any project, but quite frankly, whoever deployed > this in production must be extremely embarrassed now, knowing they will > never be able to apply the tiniest fix on top of this anymore, but hey, > we cannot save the world from fools and it's not our job :-/ > > Alex also sent me a piece of config supposed to reproduce the socks4 > regression regarding the checks, but I haven't tested yet, and since it > seems to include some private parts, it will have to be cleaned up first. > can we add a ticket for that ? looks like we can add automated testing based on that (like low priority weekly job on github) > > So if anyone currently uses socks4 to talk to servers, I suggest you > run a quick test on 2.2 or 2.3 to see if health checks continue to work > over socks4 or not, in which case it's likely you'll be able to provide > an easier reproducer that will allow to fix the problem. This will save > everyone time and protect our eyeballs by keeping them away from this > blinking patch. > > Thanks, > Willy >
