Fail to send unique-id by using proxy-v2-options
Hi,
I have compiled haproxy of version2.2-dev8 using Cygwin, in order to use it as
a load balancer in Windows 10. I want to send a unique ID generated using the
frontend's "unique-id-format" within the PROXYv2 header. However, it reports an
error:
0 [main] haproxy 1076 cygwin_exception::open_stackdumpfile: Dumping stack trace
to haproxy.exe.stackdump
Please help me solving this problem. Thank you so much!
Here is my configuration:
global
maxconn 1592
nbproc 1
log 127.0.0.1 local0 info
daemon
defaults
logglobal
log-format |%ts|%T|%ms|%Tt|%ci|%Tc|%Td|%Th|%Tw|%U|%b|%bi|%bp|%cp|%rt|%ID
timeout connect 5000
timeout client 5
timeout server 5
frontend local
mode tcp
bind *:443
unique-id-format %{+X}o\ %ci:%cp_%fi:%fp_%Ts_%rt:%pid
unique-id-header X-Unique-ID
default_backend web_servers
backend web_servers
mode tcp
balance roundrobin
server server1 XXX.XXX.XXX.XXX:443 send-proxy-v2 proxy-v2-options unique-id
check inter 1500 rise 3 fall 3 weight 1
listen admin_stats
stats enable
bind*:8200
modehttp
maxconn 10
stats refresh 30s
stats uri /admin?stats
stats realm haproxys
stats hide-version
timeout connect 10s
timeout client 1m
timeout server 1m
Best regards,
Lu
Re: haproxy 2.2-dev8-7867525 - 100% cpu usage on 1 core after config 'reload'
Pieter, Am 29.05.20 um 00:45 schrieb PiBa-NL: > I 'suspect' it has something to do with the healthchecks though... (and > their refactoring as i think happened.?.) This appears to be correct. > Anyhow perhaps this is already enough for someone to take a closer look.? > If more info is needed ill try and provide :). > > Regards, > PiBa-NL (Pieter) > > *Reproduction (works 99% of the time..):* > haproxy -W -f /var/etc/haproxy-2020/haproxy.cfg > kill -s USR2 17683 > > *haproxy.cfg* > frontend www > bind 127.0.0.1:81 > mode http > backend testVPS_ipv4 > mode http > retries 3 > option httpchk OPTIONS /Test HTTP/1.1\r\nHost:\ test.test.nl > server vps2a 192.168.30.10:80 id 10109 check inter 15000 > backend O365mailrelay > mode tcp > option smtpchk HELO > no option log-health-checks > server-template O365smtp 2 > test.mail.protection.outlook.com:25 id 122 check inter 1 > I can reproduce the issue with your configuration on > HA-Proxy version 2.2-dev8-fa9d78-30 2020/05/28 - https://haproxy.org/ > Status: development branch - not safe for use in production. > Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open > Running on: Linux 4.4.0-179-generic #209-Ubuntu SMP Fri Apr 24 17:48:44 UTC > 2020 x86_64 Backtrace is as follows: > (gdb) bt full > #0 eb_next (node=0x19e2e60) at ebtree/ebtree.h:571 > t = 0x19e2e61 > #1 ebpt_next (ebpt=0x19e2e60) at ebtree/ebpttree.h:77 > No locals. > #2 deinit_tcpchecks () at src/checks.c:5523 > rs = > r = > rb = > node = 0x19e2e60 > #3 0x004d1da3 in deinit () at src/haproxy.c:2762 strace does not show any further activity. Best regards Tim Düsterhus
haproxy 2.2-dev8-7867525 - 100% cpu usage on 1 core after config 'reload'
Hi List,
I noticed a issue with 2.2-dev8-release and with 2.2-dev8-7867525 the
issue is still there that when a reload is 'requested' it fails to stop
the old worker.. The old worker shuts down most of its threads, but 1
thread starts running at 100% cpu usage of a core. Not sure yet 'when'
the issue was introduced exactly.. Ive skiped quite a few dev releases
and didnt have time to disect it to a specific version/commit yet. Ill
try and do that during the weekend i noone does it earlier ;)..
Normally dont use -W but am 'manually' restarting haproxy with -sf
parameters.. but this seemed like the easier reproduction..
Also i 'think' i noticed once that dispite the -W parameter and logging
output that a worker was spawned that there was only 1 process running,
but couldnt reproduce that one sofar again... Also i havnt tried to see
if and how i can connect through the master to the old worker process
yet... perhaps also something i can try later..
I 'suspect' it has something to do with the healthchecks though... (and
their refactoring as i think happened.?.)
Anyhow perhaps this is already enough for someone to take a closer look.?
If more info is needed ill try and provide :).
Regards,
PiBa-NL (Pieter)
*Reproduction (works 99% of the time..):*
haproxy -W -f /var/etc/haproxy-2020/haproxy.cfg
kill -s USR2 17683
*haproxy.cfg*
frontend www
bind 127.0.0.1:81
mode http
backend testVPS_ipv4
mode http
retries 3
option httpchk OPTIONS /Test HTTP/1.1\r\nHost:\ test.test.nl
server vps2a 192.168.30.10:80 id 10109 check inter 15000
backend O365mailrelay
mode tcp
option smtpchk HELO
no option log-health-checks
server-template O365smtp 2
test.mail.protection.outlook.com:25 id 122 check inter 1
*haproxy -vv*
HA-Proxy version 2.2-dev8-7867525 2020/05/28 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: FreeBSD 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri
Jul 21 02:08:28 UTC 2017
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
Build options :
TARGET = freebsd
CPU = generic
CC = cc
CFLAGS = -pipe -g -fstack-protector -fno-strict-aliasing
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-fno-strict-overflow -Wno-null-dereference -Wno-unused-label
-Wno-unused-parameter -Wno-sign-compare -Wno-ignored-qualifiers
-Wno-unused-command-line-argument -Wno-missing-field-initializers
-Wno-address-of-packed-member -DFREEBSD_PORTS -DFREEBSD_PORTS
OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_STATIC_PCRE=1
USE_GETADDRINFO=1 USE_OPENSSL=1 USE_LUA=1 USE_ACCEPT4=1 USE_ZLIB=1
Feature list : -EPOLL +KQUEUE -NETFILTER +PCRE +PCRE_JIT -PCRE2
-PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -BACKTRACE
+STATIC_PCRE -STATIC_PCRE2 +TPROXY -LINUX_TPROXY -LINUX_SPLICE +LIBCRYPT
-CRYPT_H +GETADDRINFO +OPENSSL +LUA -FUTEX +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=16).
Built with OpenSSL version : OpenSSL 1.0.2k-freebsd 26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k-freebsd 26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.4
Built with clang compiler version 4.0.0 (tags/RELEASE_400/final 297347)
Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY
Built with PCRE version : 8.40 2017-01-11
Running on PCRE version : 8.40 2017-01-11
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Available polling systems :
kqueue : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use kqueue.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTTP side=FE|BE mux=H2
fcgi : mode=HTTP side=BE mux=FCGI
: mode=HTTP side=FE|BE mux=H1
: mode=TCP side=FE|BE mux=PASS
Available services : none
Available filters :
[SPOE] spoe
[CACHE] cache
[FCGI] fcgi-app
[TRACE] trace
[COMP] compression
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
On Thu, May 28, 2020 at 01:53:10AM +0500, Илья Шипицин wrote:
> Hello,
>
> let us skip new test on CentOS6
>
>
> Cheers,
> Ilya Shipitcin
> From 4585b4f3b3f6dcbef071b36e7a589cd89757818e Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin
> Date: Thu, 28 May 2020 01:50:57 +0500
> Subject: [PATCH] CI: cirrus-ci: skip
> reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
>
> as reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc requires ALPN,
> which is not
> supported on CentOS 6, let us skip that test
> ---
> .cirrus.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 07e1bb285..4e2a3330f 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -27,5 +27,5 @@ centos_6_task:
> - ./haproxy -vv
> - ldd haproxy
> # remove some reg-tests (CentOS 6 does not support alpn)
> -- rm reg-tests/connection/proxy_protocol_random_fail.vtc
> reg-tests/checks/tcp-check-ssl.vtc
> +- rm
> reg-tests/{connection/proxy_protocol_random_fail,checks/tcp-check-ssl,connection/proxy_protocol_send_unique_id_alpn}.vtc
> - env VTEST_PROGRAM=../vtest/vtest make reg-tests || (for folder in
> /tmp/*regtest*/vtc.*; do cat $folder/INFO $folder/LOG; done && exit 1)
Thanks I pushed it.
--
William Lallemand
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
On Thu, May 28, 2020 at 02:26:50PM +0200, Willy Tarreau wrote:
> I'm seeing other benefits of adopting a feature-based model. One of
> them is that we could report them based not only on what was enabled,
> but the real usability status which involves haproxy, the system and
> the libraries. For example we could report "+0RTT" to indicate that
> 0RTT is enabled and supposed to work or "-TFO" to indicate that TFO
> was built in but was detected as non-functional (e.g. OS limitation).
> The pollers could be reported there as well.
That would be confusing I think, because if you show +/- in the
dump, when looking at it you will suppose that every options are there.
For example, if we follow this reasoning, if you have an openssl with
OPENSSL_NO_OCSP, you can't display "-SSL_OCSP" because the support was
not built in haproxy since it requires to link with an ocsp function.
> Just as what we currently have to register build options using
> hap_register_build_opts(), we could have another one to register a
> simple word representing a feature with a boolean to indicate the
> working status, and an equivalent of REGISTER_BUILD_OPTS() to make
> them always available (useful inside #ifdefs). This could become
> really nice 1) to take into account library variants at build time,
> and 2) to mention the availability of certain new features that some
> could want to backport later. For example we've had some VTCs which
> couldn't be backported recently because they were using the new
> "http-after-response" rules, though if a user backports them for his
> own use, it makes sense to report that it's available.
>
> However I think we'd rather report such features in a different
> output from haproxy -vv, which was still made for the end user. Here
> we're now talking about a technical output. I'd be fine with a line
> such as "extra-features" which lists the stuff that's not necessarily
> the base for a given version though, in order to easily spot backports
> or optional stuff.
>
Well, it could be haproxy -vvv, It doesn't bother me if it's in -vv
either honestly. Look at vim for example, vim --version gives you every
feature activated or not. But I agree that is should be on a new line,
because they are inherited options, not build one activated on build.
> That even makes me think that a register line could look like this:
>
> hap_register_feature(name, base_version, status);
>
> where:
> - name is the feature name ("SSL_ALPN", "HTTP_AFTER_RESPONSE", ...)
> - base_version is the haproxy base version expected to expose that
> feature (eg "2.2") resulting in all earlier versions to report it
> on the line of "-vv". This will be particularly nice during
> development because all features added before the final release
> will appear there, and this can be particularly helpful in issue
> reports
>
> And with the full dump, the whole list of features (and their base
> version) would be listed, which shows backports and also helps admins
> figure that the feature they're relying on is fresh new and will
> possibly not be usable if they have to roll back to a previous version.
>
> This should still remain a bit limited so that we don't spend our time
> registering features for each and every new option. Possibly that the
> main driver for this should remain VTC first, and we'll see how that
> evolves.
>
> I'm not suggesting we go down that route immediately, that's just food
> for a possibly durable design. Maybe as a first step we should at least
> plan for a dedicated command line option to list them all and implement
> very basic registration (without target version) as mentioned above.
>
I agree, could be a good idea.
--
William Lallemand
Re: Redefine 401 error page
Le 27/05/2020 à 19:55, Willy Tarreau a écrit : Hi Christopher, On Wed, May 27, 2020 at 07:03:58PM +0200, Christopher Faulet wrote: Here are patches to handle customizable 401/407 messages. In fact, only the second patch is really meaningful. There is no change for the http-request auth rule from the configuration point of view. Internally, we rely on the proxy's error messages. It means 401 and 407 status codes are allowed on "errorfile" and "http-error" lines. I love patches like this which remove more code than they add :-) I'd have a minor request, which is to remove the empty www-authenticate and proxy-authenticate headers from the default response templates. Since the header is not edited in place but removed, it will make no difference, and at least if someone sends them as-is with http-request deny, we won't be sending an empty realm nor enforcing basic auth, but the browser will be free to do whatever it wants. In addition it would allow the user to manually append the header in a deny or return rule. Looks pretty good otherwise. Thanks Willy. I updated and pushed my patches. -- Christopher Faulet
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
On Thu, May 28, 2020 at 01:30:56PM +0200, William Lallemand wrote:
> On Thu, May 28, 2020 at 03:39:50PM +0500, ??? wrote:
> > anyway, I can install for example openssl-1.1.0 without APLN support.
> > version is not very good indicator (and we try to
> > use features in ifdef wherever possible)
>
> Also, some features in SSL could be enabled only by rebuilding HAProxy,
> so it can be kind of confusing if you have the right openssl lib with
> this feature, but without the feature activated in haproxy. It's 3not a
> common case but it could happen. For example few days ago we rebuilt an
> OpenSSL version with SSLv3 support, but without rebuilding haproxy. So
> haproxy -vv wasn't showing the SSLv3 feature. But if you disable
> something else, let's say OCSP for example, you won't be able to see it
> in haproxy -vv.
I'm seeing other benefits of adopting a feature-based model. One of
them is that we could report them based not only on what was enabled,
but the real usability status which involves haproxy, the system and
the libraries. For example we could report "+0RTT" to indicate that
0RTT is enabled and supposed to work or "-TFO" to indicate that TFO
was built in but was detected as non-functional (e.g. OS limitation).
The pollers could be reported there as well.
Just as what we currently have to register build options using
hap_register_build_opts(), we could have another one to register a
simple word representing a feature with a boolean to indicate the
working status, and an equivalent of REGISTER_BUILD_OPTS() to make
them always available (useful inside #ifdefs). This could become
really nice 1) to take into account library variants at build time,
and 2) to mention the availability of certain new features that some
could want to backport later. For example we've had some VTCs which
couldn't be backported recently because they were using the new
"http-after-response" rules, though if a user backports them for his
own use, it makes sense to report that it's available.
However I think we'd rather report such features in a different
output from haproxy -vv, which was still made for the end user. Here
we're now talking about a technical output. I'd be fine with a line
such as "extra-features" which lists the stuff that's not necessarily
the base for a given version though, in order to easily spot backports
or optional stuff.
That even makes me think that a register line could look like this:
hap_register_feature(name, base_version, status);
where:
- name is the feature name ("SSL_ALPN", "HTTP_AFTER_RESPONSE", ...)
- base_version is the haproxy base version expected to expose that
feature (eg "2.2") resulting in all earlier versions to report it
on the line of "-vv". This will be particularly nice during
development because all features added before the final release
will appear there, and this can be particularly helpful in issue
reports
And with the full dump, the whole list of features (and their base
version) would be listed, which shows backports and also helps admins
figure that the feature they're relying on is fresh new and will
possibly not be usable if they have to roll back to a previous version.
This should still remain a bit limited so that we don't spend our time
registering features for each and every new option. Possibly that the
main driver for this should remain VTC first, and we'll see how that
evolves.
I'm not suggesting we go down that route immediately, that's just food
for a possibly durable design. Maybe as a first step we should at least
plan for a dedicated command line option to list them all and implement
very basic registration (without target version) as mentioned above.
Just my two cents,
Willy
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
On Thu, May 28, 2020 at 03:39:50PM +0500, Илья Шипицин wrote: > anyway, I can install for example openssl-1.1.0 without APLN support. > version is not very good indicator (and we try to > use features in ifdef wherever possible) Also, some features in SSL could be enabled only by rebuilding HAProxy, so it can be kind of confusing if you have the right openssl lib with this feature, but without the feature activated in haproxy. It's 3not a common case but it could happen. For example few days ago we rebuilt an OpenSSL version with SSLv3 support, but without rebuilding haproxy. So haproxy -vv wasn't showing the SSLv3 feature. But if you disable something else, let's say OCSP for example, you won't be able to see it in haproxy -vv. > > as for current failures, as a short term solution, I think we can merge > patch and figure out "feature" approach later. > I agree for now, but once we have something we should remove all these "rm vtc" in the CI. -- William Lallemand
Re: Debian packaging note
❦ 28 mai 2020 12:48 +02, Tim Düsterhus: >> Okay, I've done what I really wanted to avoid and built my own HAProxy. >> I'm now running HAProxy 2.1.5-1~~~timwolla+1 and I hope that it will >> smoothly upgrade to Vincent's build once it is released. >> > > While researching how to build a 2.1.5 .deb based off your 2.1.4 sources > I noticed that Debian QA complained that HAProxy's compiler flags were > hidden [1]. You should be able to fix that by adjusting MAKEARGS in > debian/rules to include 'V=1': Thanks. I have added that for the next build on both 2.0 and 2.1. -- Patch griefs with proverbs. -- William Shakespeare, "Much Ado About Nothing"
Re: stable-bot: Bugfixes waiting for a release 2.1 (52), 2.0 (45)
On Thu, May 28, 2020 at 12:41:44PM +0200, Tim Düsterhus wrote: > My Postfix + Dovecot still works as evidenced by the fact that I am able > read your email and send a reply. My HTTP services also work. Thanks very much, that's exactly what I needed to know! William proposed me to handle the 2.1.5 release. I know we still have a minor fix to do there about the log fix (or revert it if it causes any difficulty) but we can release very soon now. Cheers, Willy
Debian packaging note (was: stable-bot: Bugfixes waiting for a release 2.1 (52), 2.0 (45))
Vincent, Am 28.05.20 um 12:41 schrieb Tim Düsterhus: > Okay, I've done what I really wanted to avoid and built my own HAProxy. > I'm now running HAProxy 2.1.5-1~~~timwolla+1 and I hope that it will > smoothly upgrade to Vincent's build once it is released. > While researching how to build a 2.1.5 .deb based off your 2.1.4 sources I noticed that Debian QA complained that HAProxy's compiler flags were hidden [1]. You should be able to fix that by adjusting MAKEARGS in debian/rules to include 'V=1': > MAKEARGS=V=1\ >DESTDIR=debian/haproxy \ >PREFIX=/usr \ >IGNOREGIT=true \ >MANDIR=/usr/share/man \ >DOCDIR=/usr/share/doc/haproxy \ >USE_PCRE2=1 \ >USE_PCRE2_JIT=1 \ >USE_OPENSSL=1 \ >USE_ZLIB=1 \ >USE_LUA=1 \ >LUA_INC=/usr/include/lua5.3 \ >EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o" Best regards Tim Düsterhus [1] https://qa.debian.org/bls/packages/h/haproxy.html
Re: stable-bot: Bugfixes waiting for a release 2.1 (52), 2.0 (45)
Willy,
Am 28.05.20 um 09:23 schrieb Willy Tarreau:
> Please do me a favor, just check that this pre-release is OK for you:
>
>http://git.haproxy.org/?p=haproxy-2.1.git;a=snapshot;h=HEAD;sf=tgz
>
> I'd really hate having to release it just to have to emit yet another
> one to fix the same issue again :-/
>
Okay, I've done what I really wanted to avoid and built my own HAProxy.
I'm now running HAProxy 2.1.5-1~~~timwolla+1 and I hope that it will
smoothly upgrade to Vincent's build once it is released.
> [root@~]haproxy -vv
> HA-Proxy version 2.1.5-1~~~timwolla+1 2020/05/28 - https://haproxy.org/
> Status: stable branch - will stop receiving fixes around Q1 2021.
> Known bugs: http://www.haproxy.org/bugs/bugs-2.1.5.html
> Running on: Linux 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64
> Build options :
> TARGET = linux-glibc
> CPU = generic
> CC = gcc
> CFLAGS = -O2 -g -O2 -fdebug-prefix-map=/pwd/haproxy-2.1.5=.
> -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 -Wshift-negative-value
> -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
> 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 +BACKTRACE +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=8).
> Built with OpenSSL version : OpenSSL 1.1.0l 10 Sep 2019
> Running on OpenSSL version : OpenSSL 1.1.0l 10 Sep 2019
> 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.3
> Built with network namespace support.
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
> IP_FREEBIND
> Built with PCRE2 version : 10.22 2016-07-29
> PCRE2 library supports JIT : yes
> Encrypted password support via crypt(3): yes
> 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 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=HTTP side=FE|BE mux=H2
> fcgi : mode=HTTP side=BEmux=FCGI
> : mode=HTTP side=FE|BE mux=H1
> : mode=TCPside=FE|BE mux=PASS
>
> Available services :
> prometheus-exporter
>
> Available filters :
> [SPOE] spoe
> [CACHE] cache
> [FCGI] fcgi-app
> [TRACE] trace
> [COMP] compression
My Postfix + Dovecot still works as evidenced by the fact that I am able
read your email and send a reply. My HTTP services also work.
Best regards
Tim Düsterhus
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
чт, 28 мая 2020 г. в 14:35, William Lallemand : > On Thu, May 28, 2020 at 09:32:25AM +0200, Willy Tarreau wrote: > > On Thu, May 28, 2020 at 12:21:20AM +0200, Tim Düsterhus wrote: > > > Ilya, > > > > > > Am 27.05.20 um 22:53 schrieb ???: > > > > Hello, > > > > > > > > let us skip new test on CentOS6 > > > > > > > > > > There definitely should be a smarter solution than "delete test" to > skip > > > tests that depend on OpenSSL's features. > > > > Ideally we'd need to add a REQUIRE_OPENSSL_VERSION directive I think. > > We'd make a special case of openssl but it simply matches the reality > > which is that we have a very tight relation with it. I wouldn't be > > surprized if in the future we also have to add a kernel version test > > for certain advanced features. > > > > > Or maybe we should just get rid of CentOS 6 tests, it will be end of > > > life on November, 30th anyway. > > > > It depends. Extended support is still valid for 4 more years, however > > I can't imagine users running a newer haproxy version on that old a > > system. Those relying on old systems just do that because they can't > > afford to have moving pieces in mission critical deployments. They'd > > definitely not upgrade haproxy on such a system! > > > > So yes, I think it can make sense to remove RHEL6 from the tests if > > it's too much of a burden to maintain. Or maybe we can adopt Ilya's > > workaround until 2.2 is released, and completely drop it afterwards ? > > > I'm against it, because it allows us to check if HAProxy still builds > with old version of OpenSSL, even if they are not supported anymore, and > even if no new features are available. HAProxy is an toolbox which is > useful sometimes in old environments. People could use an old version > of HAProxy, of course, but honestly it's not that painful to check if > 0.9.8 still build. > > In my opinion it's not Centos 6 the problem, but the fact that we don't > check the features available in OpenSSL during the tests. And we will > have more problems with that in the future if we use features available > only in newer versions of OpenSSL. And we probably already remove > manually some tests because of that. > > We could also have this problem with BoringSSL etc. What I'm seeing in > the sourcecode is that we still have a lot of #ifdef with checks on the > version and the library. > > Instead we could do a cleaner thing, set constants for SSL features > depending on the lib and version, and checks these constants instead of > the version in the code. The constant could then be reported like the > build options in haproxy -vv, and use that in REQUIRE_OPTIONS or in a > new variable like REQUIRE_FEATURES. > > For example we could have in the .vtc: > > REQUIRE_FEATURES=SSL_ALPN > "require features" is something that will come with openssl 3.0, there will be no version anymore. anyway, I can install for example openssl-1.1.0 without APLN support. version is not very good indicator (and we try to use features in ifdef wherever possible) as for current failures, as a short term solution, I think we can merge patch and figure out "feature" approach later. > > -- > William Lallemand >
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
On Thu, May 28, 2020 at 09:32:25AM +0200, Willy Tarreau wrote: > On Thu, May 28, 2020 at 12:21:20AM +0200, Tim Düsterhus wrote: > > Ilya, > > > > Am 27.05.20 um 22:53 schrieb ???: > > > Hello, > > > > > > let us skip new test on CentOS6 > > > > > > > There definitely should be a smarter solution than "delete test" to skip > > tests that depend on OpenSSL's features. > > Ideally we'd need to add a REQUIRE_OPENSSL_VERSION directive I think. > We'd make a special case of openssl but it simply matches the reality > which is that we have a very tight relation with it. I wouldn't be > surprized if in the future we also have to add a kernel version test > for certain advanced features. > > > Or maybe we should just get rid of CentOS 6 tests, it will be end of > > life on November, 30th anyway. > > It depends. Extended support is still valid for 4 more years, however > I can't imagine users running a newer haproxy version on that old a > system. Those relying on old systems just do that because they can't > afford to have moving pieces in mission critical deployments. They'd > definitely not upgrade haproxy on such a system! > > So yes, I think it can make sense to remove RHEL6 from the tests if > it's too much of a burden to maintain. Or maybe we can adopt Ilya's > workaround until 2.2 is released, and completely drop it afterwards ? > I'm against it, because it allows us to check if HAProxy still builds with old version of OpenSSL, even if they are not supported anymore, and even if no new features are available. HAProxy is an toolbox which is useful sometimes in old environments. People could use an old version of HAProxy, of course, but honestly it's not that painful to check if 0.9.8 still build. In my opinion it's not Centos 6 the problem, but the fact that we don't check the features available in OpenSSL during the tests. And we will have more problems with that in the future if we use features available only in newer versions of OpenSSL. And we probably already remove manually some tests because of that. We could also have this problem with BoringSSL etc. What I'm seeing in the sourcecode is that we still have a lot of #ifdef with checks on the version and the library. Instead we could do a cleaner thing, set constants for SSL features depending on the lib and version, and checks these constants instead of the version in the code. The constant could then be reported like the build options in haproxy -vv, and use that in REQUIRE_OPTIONS or in a new variable like REQUIRE_FEATURES. For example we could have in the .vtc: REQUIRE_FEATURES=SSL_ALPN -- William Lallemand
Re: range queries (my favourite)
On Thu, May 28, 2020 at 10:18:58AM +0200, Olivier D wrote: > Le jeu. 28 mai 2020 à 09:48, Willy Tarreau a écrit : > > > No you're not :-) hdr_cnt() counts *values*. So : > > > > Range: bytes=0-,0-,0-,0- > > > > decomposes as the following values around the comma delimiter: > > > > "bytes=0-", "0-", "0-", "0-" > > > > And actually if you'd send several Range headers with such values they > > could be remerged and interpreted as above. So in this case it's quite > > convenient for us. > > > > My bad :( > You made me realize I never used correctly this function. I was "counting" > duplicate headers with it, and it worked because headers are merged and > final behaviour matches what I was expecting. If you need to count multiple occurrences of a given header field, instead please use req.fhdr_cnt() which counts full headers (hence consider any value as a single value and doesn't try to iterate around commas). > Thank you ! You're welcome :-) Willy
Re: range queries (my favourite)
Le jeu. 28 mai 2020 à 09:48, Willy Tarreau a écrit : > No you're not :-) hdr_cnt() counts *values*. So : > > Range: bytes=0-,0-,0-,0- > > decomposes as the following values around the comma delimiter: > > "bytes=0-", "0-", "0-", "0-" > > And actually if you'd send several Range headers with such values they > could be remerged and interpreted as above. So in this case it's quite > convenient for us. > My bad :( You made me realize I never used correctly this function. I was "counting" duplicate headers with it, and it worked because headers are merged and final behaviour matches what I was expecting. Thank you ! Olivier
Re: range queries (my favourite)
Hi Olivier,
On Thu, May 28, 2020 at 09:44:13AM +0200, Olivier D wrote:
> Hello,
>
>
> Le jeu. 28 mai 2020 à 09:17, Willy Tarreau a écrit :
>
> > http-request del-header range if { req.hdr_cnt(range) gt 1 }
> >
>
> This will only filter if header "Range" is present multiple times, not this
> one :
> Range: bytes=0-,0-,0-,0-
>
> Am I correct ?
No you're not :-) hdr_cnt() counts *values*. So :
Range: bytes=0-,0-,0-,0-
decomposes as the following values around the comma delimiter:
"bytes=0-", "0-", "0-", "0-"
And actually if you'd send several Range headers with such values they
could be remerged and interpreted as above. So in this case it's quite
convenient for us.
Willy
Re: range queries (my favourite)
Hello,
Le jeu. 28 mai 2020 à 09:17, Willy Tarreau a écrit :
> http-request del-header range if { req.hdr_cnt(range) gt 1 }
>
This will only filter if header "Range" is present multiple times, not this
one :
Range: bytes=0-,0-,0-,0-
Am I correct ?
Olivier
Re: [PATCH] skip reg-tests/connection/proxy_protocol_send_unique_id_alpn.vtc on CentOS 6
On Thu, May 28, 2020 at 12:21:20AM +0200, Tim Düsterhus wrote: > Ilya, > > Am 27.05.20 um 22:53 schrieb ???: > > Hello, > > > > let us skip new test on CentOS6 > > > > There definitely should be a smarter solution than "delete test" to skip > tests that depend on OpenSSL's features. Ideally we'd need to add a REQUIRE_OPENSSL_VERSION directive I think. We'd make a special case of openssl but it simply matches the reality which is that we have a very tight relation with it. I wouldn't be surprized if in the future we also have to add a kernel version test for certain advanced features. > Or maybe we should just get rid of CentOS 6 tests, it will be end of > life on November, 30th anyway. It depends. Extended support is still valid for 4 more years, however I can't imagine users running a newer haproxy version on that old a system. Those relying on old systems just do that because they can't afford to have moving pieces in mission critical deployments. They'd definitely not upgrade haproxy on such a system! So yes, I think it can make sense to remove RHEL6 from the tests if it's too much of a burden to maintain. Or maybe we can adopt Ilya's workaround until 2.2 is released, and completely drop it afterwards ? Willy
Re: stable-bot: Bugfixes waiting for a release 2.1 (52), 2.0 (45)
Hi again Tim, On Thu, May 28, 2020 at 06:15:04AM +0200, Willy Tarreau wrote: > Hi Tim, > > On Wed, May 27, 2020 at 04:33:47PM +0200, Tim Düsterhus wrote: > > I already asked 2 weeks ago [1], but I'll ask again: > > > > > Is there any date planned for 2.1.5? I'm still running 2.1.3 on one > > > machine, because I use Dovecot. > > > > And I only just realize that 2.1.3 is affected by CVE-2020-11100 which > > makes the current situation especially ugly. Either I run a version with > > a critical bug without workaround, I break Dovecot or I compile my own > > HAProxy. > > Thanks for the ping. I'm trying :-/ I've been stuck doing only janitor > work for the last 3 months with zero development at all and am still > having a number of things to do before the release. I'll try to emit a > new one today or tomorrow. Please do me a favor, just check that this pre-release is OK for you: http://git.haproxy.org/?p=haproxy-2.1.git;a=snapshot;h=HEAD;sf=tgz I'd really hate having to release it just to have to emit yet another one to fix the same issue again :-/ Thanks! Willy
Re: range queries (my favourite)
Hi Ilya,
On Wed, May 27, 2020 at 10:48:28PM +0500, ??? wrote:
> hello,
>
> how does haproxy serves queries like that:
>
> Range: bytes=0-,0-,0-,0-,
>
> more info:
> https://www.zdnet.com/article/rangeamp-attacks-can-take-down-websites-and-cdn-servers/
Well, range attacks are pretty common, this is just yet-another one.
Haproxy has no use of the Range header so it's not sensitive to this.
However, it could trivially stop such attacks at the edge by deleting
Range headers if they appear with multiple values (which is not common
quite frankly). I guess something like this would do it pretty efficiently:
http-request del-header range if { req.hdr_cnt(range) gt 1 }
The effect will be that those requesting more than one range will simply
get the whole file once instead.
Willy
