Re: [PATCH] ubuntu-22.04 related ssl fixes (SECLEVEL related and ec curves renamed)
On Sat, Aug 06, 2022 at 10:50:15PM +0500, ??? wrote: > I accidently lost "-E' flag on grep. > follow up patch attached. No problem, thanks for the quic response. At least it seems to work for me locally, I've just pushed it and we'll see. Thanks! Willy
Re: [PATCH] CI: enable weekly "m32" builds
пн, 1 авг. 2022 г. в 22:40, Tim Düsterhus : > Ilya, > > On 7/29/22 20:25, Илья Шипицин wrote: > > not sure. it is not 32 bit, it is 32 bit built on x86_64. > > but I'm fine with "32 Bits" > > > > My understanding is that the primary thing that this tests is the > pointer / maximum object size. That shouldn't change depending on the > architecture as I understand it. > > >> Do we actually need the container overhead? Can't we test this directly > >> on the Ubuntu itself? > >> > > > > I was only able to set this up on Fedora. > > if someone can switch it to Ubuntu, I'm fine. > > no particular reason for Fedora > > Okay, fair enough. > our build uses "-lcrypt" by default. such library presents on Fedora, but it is missing on Ubuntu (for i686). I've managed to build on Ubuntu by adding USE_LIBCRYPT= it requires some investigation what we can benefit from such builds > > - > > The updated patches LGTM. > > Best regards > Tim Düsterhus >
[PATCH] spell fixes
Hello,
yet another spell fixes.
Ilya
From ce1dc66eeb1ab7e73426c0fa41dbb6e7655ce951 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Sat, 6 Aug 2022 23:01:00 +0500
Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments
This is 32nd iteration of typo fixes
---
doc/design-thoughts/thread-group.txt | 6 +++---
include/haproxy/quic_tp-t.h | 2 +-
include/haproxy/quic_tp.h| 6 +++---
include/import/ebmbtree.h| 2 +-
src/cfgparse-quic.c | 2 +-
src/quic_tp.c| 24
src/xprt_quic.c | 2 +-
7 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/doc/design-thoughts/thread-group.txt b/doc/design-thoughts/thread-group.txt
index 9ab1f556d..e845230fa 100644
--- a/doc/design-thoughts/thread-group.txt
+++ b/doc/design-thoughts/thread-group.txt
@@ -339,18 +339,18 @@ fd_takeover():|do {
old = {running, thread}; | return -1;
new = {tid_bit, tid_bit}; | new = { running | tid_bit, old.thread }
if (owner != expected) { |} while (!dwcas({running, thread}, , ));
- atomic_and(runnning, ~tid_bit); |
+ atomic_and(running, ~tid_bit); |
return -1; // fail | fd_clr_running():
} |return atomic_and_fetch(running, ~tid_bit);
|
while (old == {tid_bit, !=0 }) | poll():
if (dwcas({running, thread}, , )) { |if (!owner)
- atomic_and(runnning, ~tid_bit); | continue;
+ atomic_and(running, ~tid_bit); | continue;
return 0; // success |
} |if (!(thread_mask & tid_bit)) {
} | epoll_ctl_del();
| continue;
- atomic_and(runnning, ~tid_bit);|}
+ atomic_and(running, ~tid_bit); |}
return -1; // fail |
|// via fd_update_events()
fd_delete(): |if (fd_set_running() != -1) {
diff --git a/include/haproxy/quic_tp-t.h b/include/haproxy/quic_tp-t.h
index 77b05e32a..24859e73e 100644
--- a/include/haproxy/quic_tp-t.h
+++ b/include/haproxy/quic_tp-t.h
@@ -27,7 +27,7 @@ struct tp_preferred_address {
};
struct tp_version_information {
- uint32_t choosen;
+ uint32_t chosen;
const uint32_t *others;
size_t nb_others;
const struct quic_version *negotiated_version;
diff --git a/include/haproxy/quic_tp.h b/include/haproxy/quic_tp.h
index 192460217..9ec559f84 100644
--- a/include/haproxy/quic_tp.h
+++ b/include/haproxy/quic_tp.h
@@ -13,7 +13,7 @@ void quic_transport_params_init(struct quic_transport_params *p, int server);
int quic_transport_params_encode(unsigned char *buf,
const unsigned char *end,
struct quic_transport_params *p,
- const struct quic_version *choosen_version,
+ const struct quic_version *chosen_version,
int server);
int quic_transport_params_store(struct quic_conn *conn, int server,
@@ -46,10 +46,10 @@ static inline void quic_tp_cid_dump(struct buffer *buf,
static inline void quic_tp_version_info_dump(struct buffer *b,
const struct tp_version_information *tp, int local)
{
- if (!tp->choosen)
+ if (!tp->chosen)
return;
- chunk_appendf(b, "\n\tversion_information:(choosen=0x%08x", tp->choosen);
+ chunk_appendf(b, "\n\tversion_information:(chosen=0x%08x", tp->chosen);
if (tp->nb_others) {
int i = 0;
const uint32_t *ver;
diff --git a/include/import/ebmbtree.h b/include/import/ebmbtree.h
index 0e23539d1..b2dd1447a 100644
--- a/include/import/ebmbtree.h
+++ b/include/import/ebmbtree.h
@@ -111,7 +111,7 @@ static inline struct ebmb_node *ebmb_lookup_shorter(struct ebmb_node *start)
eb_troot_t *t = start->node.leaf_p;
struct ebmb_node *node;
- /* first, chcek for duplicates */
+ /* first, check for duplicates */
node = ebmb_next_dup(start);
if (node)
return node;
diff --git a/src/cfgparse-quic.c b/src/cfgparse-quic.c
index 5268e9ada..a9ec0740a 100644
--- a/src/cfgparse-quic.c
+++ b/src/cfgparse-quic.c
@@ -22,7 +22,7 @@ static int bind_parse_quic_cc_algo(char **args, int cur_arg, struct proxy *px,
struct quic_cc_algo *cc_algo;
if (!*args[cur_arg + 1]) {
- memprintf(err, "'%s' : missing control congestion algorith", args[cur_arg]);
+ memprintf(err, "'%s' : missing control congestion algorithm", args[cur_arg]);
Re: [PATCH] ubuntu-22.04 related ssl fixes (SECLEVEL related and ec curves renamed)
I accidently lost "-E' flag on grep.
follow up patch attached.
сб, 6 авг. 2022 г. в 21:50, Илья Шипицин :
>
>
> сб, 6 авг. 2022 г. в 20:59, Willy Tarreau :
>
>> On Sat, Aug 06, 2022 at 05:48:56PM +0200, Willy Tarreau wrote:
>> > On Fri, Jul 29, 2022 at 09:37:46PM +0500, ??? wrote:
>> > > gentle ping
>> >
>> > Sorry Ilya, but William is in vacation right now. Since I don't think
>> > there's any risk with your patch, I took it. In the worst case should
>> > William disagree with it, we could still patch later.
>>
>> Hmmm I should have been more careful, that broke half of the SSL tests
>> on ssl_generate_cert, for example:
>>
>>
>> https://github.com/haproxy/haproxy/runs/7705930410?check_suite_focus=true
>>
>> It's exactly on the last changed grep expression. I need to go right now,
>> so I'll do dev3 later. In the worst case I'll temporarily revert the
>> series.
>>
>
> I'll have a look soon
>
>
>>
>> Cheers,
>> Willy
>>
>
From 73ec541d93af8598dc9afb1a84149bb88e3661c4 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Sat, 6 Aug 2022 22:40:41 +0500
Subject: [PATCH] REGTESTS: ssl: fix grep invocation to use extended regex in
ssl_generate_certificate.vtc
in 2f2a2884b7464ccb56469cb94d8a1ae4015a8cb6 grep should have use regex flag -E, but flag
was lost by mistake
---
reg-tests/ssl/ssl_generate_certificate.vtc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/reg-tests/ssl/ssl_generate_certificate.vtc b/reg-tests/ssl/ssl_generate_certificate.vtc
index b3d9201ae..96549df54 100644
--- a/reg-tests/ssl/ssl_generate_certificate.vtc
+++ b/reg-tests/ssl/ssl_generate_certificate.vtc
@@ -164,5 +164,5 @@ shell {
}
shell {
-echo "Q" | openssl s_client -unix "${tmpdir}/ssl_P-384.sock" -servername server.ecdsa.com 2>/dev/null| grep "Temp Key: ECDH,.+, 384 bits"
+echo "Q" | openssl s_client -unix "${tmpdir}/ssl_P-384.sock" -servername server.ecdsa.com 2>/dev/null| grep -E "Temp Key: ECDH,.+, 384 bits"
}
--
2.37.1
Re: Server timeouts since HAProxy 2.2
Vincent Bernat schreef op 2022-08-04 12:14:
On 2022-08-04 10:35, William Edwards wrote:
However,
https://haproxy.debian.net/#distribution=Debian=buster=2.2
says:
"The Debian HAProxy packaging team provides various versions of
HAProxy packages for use on different Debian or Ubuntu systems. The
following wizard helps you to find the package suitable for your
system. [...] You will get a stable release of HAProxy 2.2: you may
not get the latest version but important fixes from later versions are
included. Moreover, regressions are unlikely."
The bugs page tries to get users to ALWAYS use the latest version. But
the haproxy.debian.org page says that it's okay not to use the latest
version.
That's two different point of views, one from Debian, one from
upstream. They are difficult to reconcile. That's why you (as a user)
have to choose: an old version with only "important" fixes (security
fixes mostly) and with known bugs but unlikely regressions on upgrade,
or a recent version of a stable branch with fixes and sometimes
regressions.
Upstream is unlikely to help debug old versions. The Debian solution
is to report the issue on bugs.debian.org, but this does not scale
well and I am likely to just ignore the bug because I am too short on
time.
The statement on the HAProxy bugs page implies that there is only one
right way. That same website refers to haproxy.debian.org, which
contradicts the former. I understand that the points of view are
difficult to reconcile. I do not think that -when the user is actively
pointed towards both sources- they should contradict each other,
however.
If 2.2.9 as in official Debian repository does not work for you,
the easiest path is to upgrade to 2.2.25 using the second set of
instructions.
I found this bug[1] on the bugs page which looks promising. I'll do
some more investigation today. Perhaps someone could corroborate that
that bug's symptoms match what I'm seeing.
Note that if this patch fixes this bug, this is a lot of work to
integrate it into the current release of Debian. This will have to
wait for the next point release (not a security issue), I would need
to ask people to authorize the patch, explain, ask again, prepare,
upload, then upload the backports until you get the resulting package
available as 2.2.9-2+deb11u4~bpo10+1. Backporting a random patch may
trigger regressions as it may need other patches to be backported.
This is a nest of problems. So, if this patch solves your issue, you
are on your own maintaining a fork of the package.
The commit mentioned in the patch (eddcfbc1911c when backported) is
introduced in 2.2.23, so it's likely not the patch you need or you
need other patches as well.
According to http://www.haproxy.org/bugs, 2.2.9 is affected by the
bug[1]. However, the changelog[2] only shows the causing commit
("BUG/MEDIUM: mux-h2: make use of http-request and keep-alive timeouts")
to be included in 2.2.23. How could 2.2.9 be affected by a bug which was
introduced by a commit that is included in 2.2.23?
[1]: http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff;h=3e2434e
[2]: http://git.haproxy.org/?p=haproxy-2.2.git;a=blob_plain;f=CHANGELOG
--
With kind regards,
William Edwards
Re: [PATCH] ubuntu-22.04 related ssl fixes (SECLEVEL related and ec curves renamed)
сб, 6 авг. 2022 г. в 20:59, Willy Tarreau : > On Sat, Aug 06, 2022 at 05:48:56PM +0200, Willy Tarreau wrote: > > On Fri, Jul 29, 2022 at 09:37:46PM +0500, ??? wrote: > > > gentle ping > > > > Sorry Ilya, but William is in vacation right now. Since I don't think > > there's any risk with your patch, I took it. In the worst case should > > William disagree with it, we could still patch later. > > Hmmm I should have been more careful, that broke half of the SSL tests > on ssl_generate_cert, for example: > > > https://github.com/haproxy/haproxy/runs/7705930410?check_suite_focus=true > > It's exactly on the last changed grep expression. I need to go right now, > so I'll do dev3 later. In the worst case I'll temporarily revert the > series. > I'll have a look soon > > Cheers, > Willy >
Re: [PATCH] ubuntu-22.04 related ssl fixes (SECLEVEL related and ec curves renamed)
On Sat, Aug 06, 2022 at 05:48:56PM +0200, Willy Tarreau wrote: > On Fri, Jul 29, 2022 at 09:37:46PM +0500, ??? wrote: > > gentle ping > > Sorry Ilya, but William is in vacation right now. Since I don't think > there's any risk with your patch, I took it. In the worst case should > William disagree with it, we could still patch later. Hmmm I should have been more careful, that broke half of the SSL tests on ssl_generate_cert, for example: https://github.com/haproxy/haproxy/runs/7705930410?check_suite_focus=true It's exactly on the last changed grep expression. I need to go right now, so I'll do dev3 later. In the worst case I'll temporarily revert the series. Cheers, Willy
Re: [PATCH] ubuntu-22.04 related ssl fixes (SECLEVEL related and ec curves renamed)
On Fri, Jul 29, 2022 at 09:37:46PM +0500, ??? wrote: > gentle ping Sorry Ilya, but William is in vacation right now. Since I don't think there's any risk with your patch, I took it. In the worst case should William disagree with it, we could still patch later. Thanks! Willy
Re: Server timeouts since HAProxy 2.2
On Thu, Aug 04, 2022 at 12:14:04PM +0200, Vincent Bernat wrote: > On 2022-08-04 10:35, William Edwards wrote: > > > However, > > https://haproxy.debian.net/#distribution=Debian=buster=2.2 > > says: > > > > "The Debian HAProxy packaging team provides various versions of HAProxy > > packages for use on different Debian or Ubuntu systems. The following > > wizard helps you to find the package suitable for your system. [...] You > > will get a stable release of HAProxy 2.2: you may not get the latest > > version but important fixes from later versions are included. Moreover, > > regressions are unlikely." > > > > The bugs page tries to get users to ALWAYS use the latest version. But > > the haproxy.debian.org page says that it's okay not to use the latest > > version. > > That's two different point of views, one from Debian, one from upstream. > They are difficult to reconcile. They will not for the simple reason that both have different goals and difficulties: - a project's goal is to reduce the number of bugs because bugs have direct impact on users experience, cause insatisfaction, and waste development time trying to analyse already fixed issues. - a distro's goal is to limit the risk of *regressions*, because a distro doesn't have the manpower nor skills to fix issues in every project, and they're on the first line of bug reports. As such they prefer to keep known bugs, than risking to break something for existing users. Users continually experiencing issues will naturally try another project / distro / version. The only way for distros to limit the amount of bugs without risking regressions currently is to ship proven stable versions. But in the perpetually evolving world of the WWW, standards are dictated by users (browsers, application componetns etc) and it's not always simple for users to accept to stay on an older but much stable version. The best solution to address the needs of users that are in between is what you're doing, Vincent, with your packages on https://haproxy.debian.net/. This is by far the best offer one can think of, and I confess that we're extremely lucky as a project to benefit from this. I understand that not all projects in a distro could have this, it's a significant extra work. But it perfectly plugs the hole, and that's why I strongly encourage users to switch to these packages. They remove some hassle from the distro since upstream can handle bugs, and improve the users' experience by delivering fixes for all known bugs. If that would help, we could even add links to alternate repositories in the output of "haproxy -v" so that users are more naturally invited to switch if they feel like it better matches their needs. Regards, Willy
Re: Server timeouts since HAProxy 2.2
Igor Cicimov schreef op 2022-08-04 01:46:
Because of keep-alive?
Disabling keepalive on the server side using `option http-server-close`
fixes the issue. I've yet to figure out why.
-
From: William Edwards
Sent: Thursday, 4 August 2022, 00:26
To: haproxy@formilux.org
Subject: Server timeouts since HAProxy 2.2
[You don't often get email from wedwa...@cyberfusion.nl. Learn why
this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi,
Two days ago, I upgraded my first production system from HAProxy
1.8.19
to 2.2.9. Since then, many HTTP requests are hitting the server
timeout.
Before upgrade:
root@lb0-0:~# zgrep 'sD--' /var/log/haproxy.log.5.gz | wc -l
0
root@lb0-0:~# zgrep 'sD--' /var/log/haproxy.log.4.gz | wc -l
0
root@lb0-0:~# zgrep 'sD--' /var/log/haproxy.log.3.gz | wc -l
0
After upgrade:
# Day of upgrade
root@lb0-0:~# zgrep 'sD--' /var/log/haproxy.log.2.gz | wc -l
3798
# Yesterday
root@lb0-0:~# grep 'sD--' /var/log/haproxy.log.1 | wc -l
127176
# Today, so far
root@lb0-0:~# grep 'sD--' /var/log/haproxy.log | wc -l
85063
For this specific request, Ta ("total active time for the HTTP
request")
is 3, and Tt ("total TCP session duration time, between the moment the
proxy accepted it and the moment both ends were closed") is 34 (5
minutes, the server timeout):
Aug 3 00:31:05 lb0-0 haproxy[16884]: $ip:62223
[03/Aug/2022:00:26:05.337] fr_other~
bk_http.lyr_http-lyr02.cf.ha.cyberfusion.cloud/http-lyr02.cf.ha.cyberfusion.cloud
0/0/0/3/34 200 27992 - - sD-- 616/602/226/226/0 0/0 "GET
https://$domain/wp-content/uploads/2022/07/20220712_155022-300x300.jpg
HTTP/2.0"
The backend server indeed served the request within Ta:
$domain $ip - - [03/Aug/2022:00:26:05 +0200] "GET
/wp-content/uploads/2022/07/20220712_155022-300x300.jpg HTTP/1.1" 200
28008 "https://$domain/stoffen/; "Mozilla/5.0 (Windows NT 10.0; Win64;
x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0
Safari/537.36"
The timeouts only occur with 5 out of 13 backends. There is no clear
pattern, i.e. the timeouts don't come in bursts, and they aren't
caused
by fixed clients.
Does anyone know why the TCP session is kept open, and the HTTP
request
is not responded to by HAProxy after the backend server responded to
the
HTTP request, but only after the server timeout is reached?
--
With kind regards,
William Edwards
Know Your Customer due diligence on demand, powered by intelligent
process automation
Blogs [1] | LinkedIn [2] | Twitter [3]
Encompass Corporation UK Ltd | Company No. SC493055 | Address: Level
3, 33 Bothwell Street, Glasgow, UK, G2 6NL
Encompass Corporation Pty Ltd | ACN 140 556 896 | Address: Level 10,
117 Clarence Street, Sydney, New South Wales, 2000
Encompass Corporation US Ltd | Company No. 7946259 | Address: 5th
floor, 1460 Broadway, New York, New York, 10036
This email and any attachments is intended only for the use of the
individual or entity named above and may contain confidential
information
If you are not the intended recipient, any dissemination, distribution
or copying of this email is prohibited.
If received in error, please notify us immediately by return email and
destroy the original message.
Links:
--
[1] https://www.encompasscorporation.com/blog/
[2] https://www.linkedin.com/company/encompass-corporation/
[3] https://twitter.com/EncompassCorp
--
With kind regards,
William Edwards
Re: haproxy listening on lots of UDP ports
Hi Shawn, On Fri, Aug 05, 2022 at 05:18:06PM -0600, Shawn Heisey wrote: > I am running haproxy in a couple of places. It is listening on multiple > seemingly random high UDP ports. These typically are syslog sockets. In fact the ports are not really "listening", it's just that in UDP there's no direction so as soon as the socket is bound, it appears. I think that using "netstat -anu" or "ss -anu" you should see your syslog servers' addresses in the peer column. Note that for syslog, we still take care of setting the rcvbuf to zero and shutting down the read side so that in the event any datagram would appear there, it wouldn't uselessly consume socket buffers. Regards, Willy
Re: [PATCH] CI: enable weekly "m32" builds
On Mon, Aug 01, 2022 at 07:40:43PM +0200, Tim Düsterhus wrote: > The updated patches LGTM. Thanks guys, now applied! Willy
Re: [PATCH] speling fixes
On Fri, Jul 29, 2022 at 10:30:39PM +0500, ??? wrote: > Hello, > > yet another spell check fiexs. Now applied, thanks Ilya! Willy
Improve config with lots of distinct matching types
Hello list, tl;dr is: How can I avoid configuring dozens of http-request with
the same acl?
My use case is a haproxy cluster receiving requests for hundreds of distinct
hostnames, several of them with a dozen or so distinct paths, and a few more
than 5k distinct backends that sends these requests to a cluster of about 15k
containers. In the very beginning we were adding one http-request per rule but
this wasn't scaling well, so changed the approach to a map() converter with
something like `# ` which improved performance a
lot.
Now we're starting to add other dimensions to that host+path matching, which is
at least query params and header matching, so starting again with one
http-request keyword per rule, which we already know that will not scale.
My starting idea was to evolve the map() converter strategy to add these new
matching rules but couldn't figure out a way to do it. I thought about making
two levels of map() but it doesn't allow dynamic input, so I wouldn't have a
way to configure the second one.
Another idea was to mimic how other proxies do their configuration: an outer
block defines the hostname level, everything inside that block already have an
implicit `{ hdr(host) host1 }`. A second block within the first one defines the
path, so everything inside it has already an implicit `{ path /bar }`.
Maybe haproxy has already a keyword or configuration for that use case, if so
I'd love to hear some advices. If not this is a draft of a proposal that I'd
love to hear from you if it's something doable:
case (acl-name|anonymous-acl) {
http-request bar # outer acl implicit
http-request baz if { hdr(x-bar) baz } # outer acl implicitly ANDed here
case (acl-name|anonymous-acl) {
http-request bazz # both outer acls ANDing here
}
}
case keyword starts a block, a closing brace alone in the line closes the inner
block. Indentation doesn't matter at all. haproxy now knows that if the outer
acl doesn't match, all the inner keywords should be ignored. Does it make sense?
~jm
