Termination state IR--
Hi all,
I'm asking this question here since I read in the docs that if I see "Ixxx"
in the session "termination_state" log I should do so :-)
The error I got while experimenting with the HAP config is as follows:
Jan 29 03:33:44 ip-172-31-45-201 haproxy[124024]: :44296
[29/Jan/2020:03:33:44.952] fe_https~ host.mydomain.com/
-1/-1/-1/-1/0 500 0 - - IR-- 1/1/5/0/3 0/0 "GET /api/search HTTP/1.1"
The command that produced it:
$ curl -vsSNiL -H "Host: host.mydomain.com"
https://haproxy.example.com:8443/api/search
And the relevant haproxy-2.0.12 configuration (it's in AWS):
resolvers vpc
nameserver dns1 172.31.0.2:53
accepted_payload_size 8192
resolve_retries 30
timeout resolve 1s
timeout retry 2s
hold valid30s
hold other30s
hold refused 30s
hold nx 30s
hold timeout 30s
hold obsolete 30s
frontend fe_https
bind *:8443 ssl crt /etc/haproxy/ssl.d/ alpn h2,http/1.1
mode http
option httplog
use_backend %[req.hdr(host),word(1,:),lower]
backend host.mydomain.com
mode tcp
option tcp-check
tcp-check connect port 443 ssl
balance source
default-server inter 60s downinter 30s rise 2 fall 2 slowstart 10s
weight 100 ca-file /etc/ssl/certs/ca-certificates.crt on-marked-down
shutdown-sessions
server myhost host.mydomain.com:443 verify none check resolvers vpc
resolve-prefer ipv4
Haproxy version dump:
# haproxy -vv
HA-Proxy version 2.0.12-1ppa~xenial 2019/12/21 - https://haproxy.org/
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -O2 -fPIE -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits
OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_REGPARM=1 USE_OPENSSL=1
USE_LUA=1 USE_ZLIB=1 USE_SYSTEMD=1
Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE
-PCRE_JIT +PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED
+REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE
+LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4
-MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS
-51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_THREADS=64, default=1).
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.1
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE2 version : 10.21 2016-01-12
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with the Prometheus exporter as a service
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTXside=FE|BE mux=H2
h2 : mode=HTTP side=FEmux=H2
: mode=HTXside=FE|BE mux=H1
: mode=TCP|HTTP side=FE|BE mux=PASS
Available services :
prometheus-exporter
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
I'm sure I've done something wrong since I have exactly the same backend
working fine with frontend in TCP mode using "ssl_sni" like so:
frontend fe_https_tcp
bind *:8443
mode tcp
option tcplog
tcp-request connection reject if !{ src -f /etc/haproxy/whitelist.lst }
tcp-request inspect-delay 5s
tcp-request content accept if { req.ssl_hello_type 1 }
use_backend host.mydomain.com if { req.ssl_sni -i host.mydomain.com }
Thanks,
Igor
Re: "check-sni" doesn't seems to have effect on "tcp-check connect ssl"
On Mon, Jan 27, 2020 at 10:24:31PM +, Nelson Branco wrote: > I meant, I was expecting to have the server_name TLS extension sent as it > happens if we use a httpcheck. I don't see why it wouldn't be sent (except for a bug indeed), if you don't specify the port, as with no port, the check is expected to use all the parameters needed to connect to the server. What's your config exactly ? Do you have "check-ssl" on your server line ? Willy
Re: [PATCH v4] BUG/MINOR: dns: allow 63 char in hostname
On Tue, Jan 28, 2020 at 12:19 AM Miroslav Zagorac wrote: > On 01/28/2020 12:02 AM, Baptiste wrote: > > On Sun, Jan 26, 2020 at 7:53 PM William Dauchy > wrote: > > > >> hostname were limited to 62 char, which is not RFC1035 compliant; > >> - the parsing loop should stop when above max label char > >> - fix len label test where d[i] was wrongly used > >> - simplify the whole function to avoid using two extra char* variable > >> > >> this should fix github issue #387 > >> ... > > > > This patch is "approved". > > Willy, you can apply. > > > > Baptiste > > > > Hello, > > whether in this function is sufficient to check the length of the label > and its contents (uppercase and lowercase letters, numbers and hyphen) > or whether RFC1035 should be followed where it states the following: > > "The labels must follow the rules for ARPANET host names. They must > start with a letter, end with a letter or digit, and have as interior > characters only letters, digits, and hyphen. There are also some > restrictions on the length. Labels must be 63 characters or less." > > -- > Zaga > > What can change the nature of a man? > Thanks Miroslav for the feedback. I am creating a github issue with this content so we can track it. Baptiste
Re: Disabling regtests in Travis ?
On Tue, Jan 28, 2020 at 06:16:58PM +0500, ??? wrote: > ??, 28 ???. 2020 ?. ? 18:15, Willy Tarreau : > > > On Tue, Jan 28, 2020 at 06:02:16PM +0500, ??? wrote: > > > ??, 28 ???. 2020 ?. ? 16:02, Willy Tarreau : > > > > > > > On Tue, Jan 28, 2020 at 02:13:15PM +0500, ??? wrote: > > > > > btw, we can remove "allowed failure" since this test is slow and > > excluded > > > > > > > > > > https://travis-ci.com/haproxy/haproxy/jobs/280882138 > > > > > > > > My understanding of the commit message was that it was excluded because > > > > of issue #429. Am I wrong ? > > > > > > > > > > it was excluded 2 times. > > > > > > first, we marked openssl-1.0.2 as "allowed failure" because of #429 > > > second, it was excluded, because it is "slow" test > > > > Hmmm no, we instead disabled slow regtests, but I'm not seeing anything > > > > yep. > > Skip reg-tests/ssl/set_ssl_cert.vtc because its type 'slow' is excluded Ah got it. Well, that's just a coicidence because the problem met in this test is not that it is slow but that it fails on 1.0.2, so even if we were to re-enable slow tests later, it would fail again. Let's wait for #429 to be addressed first. Thanks, Willy
Re: Disabling regtests in Travis ?
вт, 28 янв. 2020 г. в 18:15, Willy Tarreau : > On Tue, Jan 28, 2020 at 06:02:16PM +0500, ??? wrote: > > ??, 28 ???. 2020 ?. ? 16:02, Willy Tarreau : > > > > > On Tue, Jan 28, 2020 at 02:13:15PM +0500, ??? wrote: > > > > btw, we can remove "allowed failure" since this test is slow and > excluded > > > > > > > > https://travis-ci.com/haproxy/haproxy/jobs/280882138 > > > > > > My understanding of the commit message was that it was excluded because > > > of issue #429. Am I wrong ? > > > > > > > it was excluded 2 times. > > > > first, we marked openssl-1.0.2 as "allowed failure" because of #429 > > second, it was excluded, because it is "slow" test > > Hmmm no, we instead disabled slow regtests, but I'm not seeing anything > yep. Skip reg-tests/ssl/set_ssl_cert.vtc because its type 'slow' is excluded > specific there under the allow_failures section : > > allow_failures: > - os: linux > arch: ppc64le > if: type == cron > compiler: gcc > env: TARGET=linux-glibc OPENSSL_VERSION=1.0.2u > > So my understanding is that it's still valid due to the error on > "set ssl cert". > > Or maybe you mean something different ? > > Willy >
Re: Disabling regtests in Travis ?
On Tue, Jan 28, 2020 at 06:02:16PM +0500, ??? wrote: > ??, 28 ???. 2020 ?. ? 16:02, Willy Tarreau : > > > On Tue, Jan 28, 2020 at 02:13:15PM +0500, ??? wrote: > > > btw, we can remove "allowed failure" since this test is slow and excluded > > > > > > https://travis-ci.com/haproxy/haproxy/jobs/280882138 > > > > My understanding of the commit message was that it was excluded because > > of issue #429. Am I wrong ? > > > > it was excluded 2 times. > > first, we marked openssl-1.0.2 as "allowed failure" because of #429 > second, it was excluded, because it is "slow" test Hmmm no, we instead disabled slow regtests, but I'm not seeing anything specific there under the allow_failures section : allow_failures: - os: linux arch: ppc64le if: type == cron compiler: gcc env: TARGET=linux-glibc OPENSSL_VERSION=1.0.2u So my understanding is that it's still valid due to the error on "set ssl cert". Or maybe you mean something different ? Willy
Re: Disabling regtests in Travis ?
вт, 28 янв. 2020 г. в 16:02, Willy Tarreau : > On Tue, Jan 28, 2020 at 02:13:15PM +0500, ??? wrote: > > btw, we can remove "allowed failure" since this test is slow and excluded > > > > https://travis-ci.com/haproxy/haproxy/jobs/280882138 > > My understanding of the commit message was that it was excluded because > of issue #429. Am I wrong ? > it was excluded 2 times. first, we marked openssl-1.0.2 as "allowed failure" because of #429 second, it was excluded, because it is "slow" test > > Willy >
Re: [PATCH] MINOR: proxy: clarify number of connections log when stopping
On Sat, Jan 25, 2020 at 11:45:18PM +0100, William Dauchy wrote: > this log could be sometimes a bit confusing (depending on the number in > fact) when you read it (e.g is it the number of active connection?) - > only trained eyes knows haproxy output a different log when closing > active connections while stopping. (...) good point, now merged, thanks! Willy
Re: [PATCH v4] BUG/MINOR: dns: allow 63 char in hostname
On Tue, Jan 28, 2020 at 12:02:18AM +0100, Baptiste wrote: > On Sun, Jan 26, 2020 at 7:53 PM William Dauchy wrote: > > > hostname were limited to 62 char, which is not RFC1035 compliant; > > - the parsing loop should stop when above max label char > > - fix len label test where d[i] was wrongly used > > - simplify the whole function to avoid using two extra char* variable > > > > this should fix github issue #387 > > > > Signed-off-by: William Dauchy (...) > This patch is "approved". > Willy, you can apply. OK now applied, thanks! Willy
Re: [PATCH v2] BUG/MINOR: connection: fix ip6 dst_port copy in make_proxy_line_v2
On Sun, Jan 26, 2020 at 07:31:25PM +0100, Tim Düsterhus wrote:
> William,
> Willy,
>
> Am 26.01.20 um 19:28 schrieb Tim Düsterhus:
> >> Fixes: 7fec02153712 ("MEDIUM: proxy_protocol: Convert IPs to v6 when
> >> protocols are mixed")
>
> One more thing:
>
> Backport information are missing (without looking up that commit). 1.8+
> it is.
Now merged with your reviewed-by tag and this backport info.
Thanks guys!
Willy
Re: Disabling regtests in Travis ?
On Tue, Jan 28, 2020 at 02:13:15PM +0500, ??? wrote: > btw, we can remove "allowed failure" since this test is slow and excluded > > https://travis-ci.com/haproxy/haproxy/jobs/280882138 My understanding of the commit message was that it was excluded because of issue #429. Am I wrong ? Willy
Re: [PATCH v2] BUG/MINOR: connection: fix ip6 dst_port copy in make_proxy_line_v2
On Sun, Jan 26, 2020 at 10:40:02PM +, William Dauchy wrote: > 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 so. > > This is not something a VCS will figure out for us, but is a human > > decision. The author should be suggesting it's intention regarding the > > backport in the commit message, because it's the one person that spend > > the most time with the issue and probably has the best understanding > > of its impacts as well as the complexity and necessity of a backport. > > That does not mean the author needs to tests the fix with those > > branches, send branch-specific diff's, or do other research regarding > > the backport, but *the intention needs to be stated* (based on the > > research already conducted for the matter at hand). I wouldn't have said it better. That's exactly the point, and is the reason why there are a lot of "should be backported" or "seems to be affected" in our commit messages. It's important to keep in mind that for one commit to master, there are sometimes up to 4-5 ones replicated to older branches, done by different people, who usually don't know much (if at all) about the area being fixed, and doing this effort each an every time the fix gets backported is painful and counter-productive because it adds to the error rate. So any hint the person fixing the bug can give in human language, including "in version 1.6 the function has a different name", or "in version 1.8 an additional null check will be needed" are very helpful. > yes, that's why I was more talking about a semi automatic process, > which only suggests to do a backport with this tag. For now (sadly), the code is still not isolated enough to warrant a semi automatic process. Usually in the 3 months that follow a major release, all cherry-picks from master to this release work without any effort. But then, between refactoring, code moves, name changes, API changes etc, even if the patch applies it doesn't imply that it will work, so we need to read the change in its context (and obviously to perform basic testing). > I am thinking about examples like on netdev linux kernel subsystem, a > "Fixes:" tag suggests that it is a possible candidate for stable > branches, but then it's up to the maintainer to decide whether to > backport it or not. Many times I've been wondering if we should start to add a Fixes tag, but very often I figured it would not map well. Often we don't fix a bug introduced by one patch but *revealed* by one patch while it was already there. This is related to the long history of this code being extremely monolithic in the past and progressively becoming more modular. While in Linux all drivers are independent, each network protocol is independent, and bugs area really isolated, it's still not the case for us eventhough it's progressively starting to appear. So for now, placing a Fixes tag would not bring much value. Also, having to issue "git describe --contains" and/or "git log --grep $ID" for each of them is more time consuming than simply skipping the patch being reviewed based on its commit message. In Linux, the Fixes tag started to become really useful to me when adding "# 3.4, 3.10 ..." after it because it was a convenient way to indicate "drop that". I know our process is far from being perfect, but I'm trying to keep it optimally efficient for those doing the work so that we can continue to deliver timely fixes for all supported branches. > Anyway, that being said, I have nothing against adding those messages, > it was a suggestion. Thanks for the suggestion. It's sometimes useful to question whether what's been done for a while is still valid or not. Willy
Re: Disabling regtests in Travis ?
btw, we can remove "allowed failure" since this test is slow and excluded https://travis-ci.com/haproxy/haproxy/jobs/280882138 пн, 27 янв. 2020 г. в 17:35, Martin Grigorov : > > > On Fri, Jan 24, 2020 at 6:43 PM Willy Tarreau wrote: > >> On Fri, Jan 24, 2020 at 09:12:58PM +0500, ??? wrote: >> > >> + - make reg-tests VTEST_PROGRAM=../vtest/vtest >> > >> REGTESTS_TYPES=default,bug,devel >> > >> >> > > >> > > let us try that. >> >> OK, now pushed. >> >> > > I will have a look at "racy" tests. >> > > Maybe we'll enable them on Github Actions. >> > > >> > > >> > the good thing about Github Actions, it is possible to attach own build >> > agents. So, if we >> > have dedicated hardware and we not want to depend on travis-ci >> neighbours, >> > it might be an option. >> >> That's good to know, even if I doubt we'd need it, at least it >> opens possibilities. >> > > The regtests run fine on my ARM64 VM. I run them daily. > If HAProxy team decides to move to GitHub Actions and to use an external > build agent for ARM64 then just ping me! > > Regards, > Martin > > >> >> Willy >> >>
