Re: [PATCH] CI: enable weekly "m32" builds
пт, 29 июл. 2022 г. в 22:48, Tim Düsterhus :
> Ilya,
>
> On 7/29/22 18:53, Илья Шипицин wrote:
> > another exotic (but hopefully useful) CI job.
> >
>
> In the first patch you have an indentation mixup. The script uses
> spaces, but the modified line now uses tabs. This will look incorrectly
> depending on the tab width.
>
done
>
> For the second patch:
>
> > +name: m32
>
> I believe '32 Bit' would be a little more descriptive, however:
>
not sure. it is not 32 bit, it is 32 bit built on x86_64.
but I'm fine with "32 Bits"
>
> > + test:
> Please rename this to "build", because it doesn't test anything (other
> than the build).
>
> done
> Please also add a 'name:' for the job. 'name: Fedora' would be
> consistent, but ...
>
> > +container:
> > + image: fedora:rawhide
>
> 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
>
> > +- name: Compile QUICTLSroxy
>
> Is there a copy and paste mistake in 'QUICTLSroxy' here?
>
oops.
>
> > make CC=gcc ERR=1 TARGET=linux-glibc USE_OPENSSL=1 USE_QUIC=1
> DEBUG_CFLAGS="-m32" LDFLAGS="-m32" SSL_LIB=${HOME}/opt/lib
> SSL_INC=${HOME}/opt/include
>
> Can you please split this across multiple lines using a backslash, like
> here:
>
done
>
>
> https://github.com/haproxy/haproxy/blob/dc07751ed7ebad10f49081d28a9a5ae785f53d76/.github/workflows/windows.yml#L57-L61
>
> It is more readable if the line isn't that long.
>
> Best regards
> Tim Düsterhus
>
From 39d22d37779dfed94890d39a2741c26f6de695f0 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 29 Jul 2022 23:13:21 +0500
Subject: [PATCH 1/2] BUILD: SSL: allow to pass additional configure args to
QUICTLS
this allows to pass QUICTLS_EXTRA_ARGS to QUICTLS builds. if no
additional arg is passed, behaviour is kept unchanged
--
v2 indentation fixed
---
scripts/build-ssl.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/build-ssl.sh b/scripts/build-ssl.sh
index d143cec55..42eef1902 100755
--- a/scripts/build-ssl.sh
+++ b/scripts/build-ssl.sh
@@ -134,11 +134,10 @@ fi
if [ ! -z ${QUICTLS+x} ]; then
(
-
download_quictls
cd download-cache/quictls
-./config shared --prefix="${HOME}/opt" --openssldir="${HOME}/opt" --libdir=lib -DPURIFY
+./config shared ${QUICTLS_EXTRA_ARGS:-} --prefix="${HOME}/opt" --openssldir="${HOME}/opt" --libdir=lib -DPURIFY
make -j$(nproc) build_sw
make install_sw
--
2.37.1
From 544284d5907e3fc9fd995586571de6a6abe1076d Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 29 Jul 2022 23:21:37 +0500
Subject: [PATCH 2/2] CI: enable weekly "m32" builds on x86_64
this is build only workflow, catches potential "size_t" mismatches
--
v2 job name added, various markup changes
---
.github/workflows/m32.yml | 42 +++
1 file changed, 42 insertions(+)
create mode 100644 .github/workflows/m32.yml
diff --git a/.github/workflows/m32.yml b/.github/workflows/m32.yml
new file mode 100644
index 0..1b61f1e7a
--- /dev/null
+++ b/.github/workflows/m32.yml
@@ -0,0 +1,42 @@
+#
+# special purpose CI: test build on x86_64 with "m32" flag enabled
+# let us run those builds weekly
+#
+# some details might be found at GH: https://github.com/haproxy/haproxy/issues/1760
+#
+
+name: 32 Bit
+
+on:
+ schedule:
+- cron: "0 0 * * 5"
+
+
+permissions:
+ contents: read
+
+jobs:
+ build:
+name: Fedora
+runs-on: ubuntu-latest
+container:
+ image: fedora:rawhide
+steps:
+- uses: actions/checkout@v3
+- name: Install dependencies
+ run: |
+dnf -y groupinstall "Development Tools"
+dnf -y install 'perl(FindBin)' 'perl(File::Compare)' perl-IPC-Cmd 'perl(File::Copy)' glibc-devel.i686
+- name: Compile QUICTLS
+ run: |
+QUICTLS=yes QUICTLS_EXTRA_ARGS="-m32 linux-generic32" ./scripts/build-ssl.sh
+- name: Compile HAProxy
+ run: |
+make -j$(nproc) CC=gcc ERR=1 \
+ TARGET=linux-glibc \
+ USE_OPENSSL=1 \
+ USE_QUIC=1 \
+ DEBUG_CFLAGS="-m32" \
+ LDFLAGS="-m32" \
+ SSL_LIB=${HOME}/opt/lib \
+ SSL_INC=${HOME}/opt/include
--
2.37.1
Re: [PATCH] CI: enable weekly "m32" builds
Ilya,
On 7/29/22 18:53, Илья Шипицин wrote:
another exotic (but hopefully useful) CI job.
In the first patch you have an indentation mixup. The script uses
spaces, but the modified line now uses tabs. This will look incorrectly
depending on the tab width.
For the second patch:
+name: m32
I believe '32 Bit' would be a little more descriptive, however:
+ test:
Please rename this to "build", because it doesn't test anything (other
than the build).
Please also add a 'name:' for the job. 'name: Fedora' would be
consistent, but ...
> +container:
> + image: fedora:rawhide
Do we actually need the container overhead? Can't we test this directly
on the Ubuntu itself?
+- name: Compile QUICTLSroxy
Is there a copy and paste mistake in 'QUICTLSroxy' here?
make CC=gcc ERR=1 TARGET=linux-glibc USE_OPENSSL=1 USE_QUIC=1 DEBUG_CFLAGS="-m32"
LDFLAGS="-m32" SSL_LIB=${HOME}/opt/lib SSL_INC=${HOME}/opt/include
Can you please split this across multiple lines using a backslash, like
here:
https://github.com/haproxy/haproxy/blob/dc07751ed7ebad10f49081d28a9a5ae785f53d76/.github/workflows/windows.yml#L57-L61
It is more readable if the line isn't that long.
Best regards
Tim Düsterhus
Re: [PATCH] DOC: add info about ssl-engine for 2.6
Alex, [adding William to Cc, as he requested that you update your patch based on my review] On 7/27/22 15:30, Aleksandar Lazic wrote: Thank you for your feedback. Attached the new version Please apologize the delay in getting back to you. I'm not sure if I'd drop the ... > In case that the ssl-engine is required can HAProxy be rebuild with USE_ENGINE=1 build flag. ... part, as it goes without saying that the feature will be available when setting the required flag. It's a little redundant. I don't have a strong preference, though. I suggest that William drops the sentence himself when applying the patch if he doesn't like that sentence. Best regards Tim Düsterhus
[PATCH] speling fixes
Hello, yet another spell check fiexs. Ilya From fa2f99b1b2e5b30987db9eba77e1a59479610915 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Fri, 29 Jul 2022 22:26:53 +0500 Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments This is 31st iteration of typo fixes --- addons/deviceatlas/dummy/dac.h | 2 +- doc/configuration.txt| 4 ++-- doc/design-thoughts/thread-group.txt | 4 ++-- doc/internals/api/appctx.txt | 4 ++-- doc/internals/api/pools.txt | 2 +- include/haproxy/ncbuf-t.h| 2 +- include/haproxy/proxy-t.h| 4 ++-- include/haproxy/task.h | 2 +- include/haproxy/xprt_quic-t.h| 4 ++-- include/haproxy/xprt_quic.h | 2 +- src/cfgparse.c | 2 +- src/check.c | 2 +- src/flt_bwlim.c | 6 +++--- src/http_client.c| 4 ++-- src/mux_fcgi.c | 2 +- src/mux_quic.c | 8 src/ncbuf.c | 4 ++-- src/quic_sock.c | 4 ++-- src/stconn.c | 8 src/xprt_quic.c | 12 ++-- 20 files changed, 41 insertions(+), 41 deletions(-) diff --git a/addons/deviceatlas/dummy/dac.h b/addons/deviceatlas/dummy/dac.h index 55bc6c025..bf166ae54 100644 --- a/addons/deviceatlas/dummy/dac.h +++ b/addons/deviceatlas/dummy/dac.h @@ -227,7 +227,7 @@ da_status_t da_atlas_open(da_atlas_t *atlas, da_property_decl_t *extra_props, co * @brief read from a mapped data which then replace da_atlas_compile call * * @param dumppath, anonymous if NULL - * @param map for anonymous, it is the responsability of the caller to unmap it, ignored otherwise + * @param map for anonymous, it is the responsibility of the caller to unmap it, ignored otherwise * @param maplen for anonymous, it is the size of the mapped data, ignored otherwise * @param ptr Pointer dynamically allocated if the mapping happened normally * @param len size of the atlas image diff --git a/doc/configuration.txt b/doc/configuration.txt index 36046d569..95055eb30 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -23091,7 +23091,7 @@ filter bwlim-out limit key [table ] [min-size is the default time period used to evaluate the bandwidth -limitation rate. It can be speficied for per-stream bandwidth +limitation rate. It can be specified for per-stream bandwidth limitation filters only. It follows the HAProxy time format and is expressed in milliseconds. @@ -23166,7 +23166,7 @@ some experimentations. # of 10m/s with all other streams with the same source address. filter bwlim-out limit-by-src key src table limit-by-src limit 10m -# If this filter is enalbed, the stream will be limited to download at 1m/s, +# If this filter is enabled, the stream will be limited to download at 1m/s, # independently of all other streams. filter bwlim-out limit-by-strm default-limit 1m default-period 1s diff --git a/doc/design-thoughts/thread-group.txt b/doc/design-thoughts/thread-group.txt index 8d218e072..9ab1f556d 100644 --- a/doc/design-thoughts/thread-group.txt +++ b/doc/design-thoughts/thread-group.txt @@ -319,7 +319,7 @@ thread mask due to takeover ?), the same FD may appear at the same time: - in the global update_list. In this case, fd_rm_from_fd_list() already performs an attachment check, so it's safe to always call it before closing -(since noone else may be in the process of changing anything). +(since no one else may be in the process of changing anything). ### @@ -481,7 +481,7 @@ the FD, and all those with a bit in it ought to do it. - thread_mask (in bind_conf->rx_settings) should become an array of MAX_TGROUP longs. - when parsing "thread 123" or "thread 2/37", the proper bit is set, -assuming the array is either a contigous bitfield or a tgroup array. +assuming the array is either a contiguous bitfield or a tgroup array. An option RX_O_THR_PER_GRP or RX_O_THR_PER_PROC is set depending on how the thread num was parsed, so that we reject mixes. - end of parsing: entries translated to the cleanest form (to be determined) diff --git a/doc/internals/api/appctx.txt b/doc/internals/api/appctx.txt index 0597e10d9..137ec7b6c 100644 --- a/doc/internals/api/appctx.txt +++ b/doc/internals/api/appctx.txt @@ -20,7 +20,7 @@ context that was allowed to use extra fields of various types. Other applets preferred to use their own context definition. All this resulted in the appctx->ctx to contain a myriad of definitions of -vairous service contexts, and in some services abusing other services' +various service contexts, and in some services abusing other services'
[PATCH] CI: enable weekly "m32" builds
Hello,
another exotic (but hopefully useful) CI job.
Ilya
From d6185a3e972c0e04d86e8b7ddc075a08d115031a Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 29 Jul 2022 21:42:12 +0500
Subject: [PATCH 1/2] BUILD: SSL: allow to pass additional configure args to
QUICTLS
this allows to pass QUICTLS_EXTRA_ARGS to QUICTLS builds. if no
additional arg is passed, behaviour is kept unchanged
---
scripts/build-ssl.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/build-ssl.sh b/scripts/build-ssl.sh
index d143cec55..8cd827edb 100755
--- a/scripts/build-ssl.sh
+++ b/scripts/build-ssl.sh
@@ -134,11 +134,10 @@ fi
if [ ! -z ${QUICTLS+x} ]; then
(
-
download_quictls
cd download-cache/quictls
-./config shared --prefix="${HOME}/opt" --openssldir="${HOME}/opt" --libdir=lib -DPURIFY
+ ./config shared ${QUICTLS_EXTRA_ARGS:-} --prefix="${HOME}/opt" --openssldir="${HOME}/opt" --libdir=lib -DPURIFY
make -j$(nproc) build_sw
make install_sw
--
2.37.1
From 1dc093064bb69dba78a029083b4884f1bbe78eb8 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 29 Jul 2022 21:49:22 +0500
Subject: [PATCH 2/2] CI: enable weekly "m32" builds on x86_64
this is build only workflow, catches potential "size_t" mismatches
---
.github/workflows/m32.yml | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 .github/workflows/m32.yml
diff --git a/.github/workflows/m32.yml b/.github/workflows/m32.yml
new file mode 100644
index 0..09ecd24d3
--- /dev/null
+++ b/.github/workflows/m32.yml
@@ -0,0 +1,34 @@
+#
+# special purpose CI: test build on x86_64 with "m32" flag enabled
+# let us run those builds weekly
+#
+# some details might be found at GH: https://github.com/haproxy/haproxy/issues/1760
+#
+
+name: m32
+
+on:
+ schedule:
+- cron: "0 0 * * 5"
+
+
+permissions:
+ contents: read
+
+jobs:
+ test:
+runs-on: ubuntu-latest
+container:
+ image: fedora:rawhide
+steps:
+- uses: actions/checkout@v3
+- name: Install dependencies
+ run: |
+dnf -y groupinstall "Development Tools"
+dnf -y install 'perl(FindBin)' 'perl(File::Compare)' perl-IPC-Cmd 'perl(File::Copy)' glibc-devel.i686
+- name: Compile QUICTLSroxy
+ run: |
+QUICTLS=yes QUICTLS_EXTRA_ARGS="-m32 linux-generic32" ./scripts/build-ssl.sh
+- name: Compile HAProxy
+ run: |
+make CC=gcc ERR=1 TARGET=linux-glibc USE_OPENSSL=1 USE_QUIC=1 DEBUG_CFLAGS="-m32" LDFLAGS="-m32" SSL_LIB=${HOME}/opt/lib SSL_INC=${HOME}/opt/include
--
2.37.1
Re: [PATCH] ubuntu-22.04 related ssl fixes (SECLEVEL related and ec curves renamed)
gentle ping вс, 24 июл. 2022 г. в 00:12, Илья Шипицин : > Hello, > > Ubuntu 22.04 is shipped with "openssl" command line 3.0.5, also SECLEVEL=2 > is set by default. > > "SECLEVEL=2" has uncovered an interesting issue with DH length, which was > set to 1024 for EC keys. While better strategy for DH on EC keys needs to > be discussed, let us set it to configured dh value now. > > also, ec curves were renamed (but curves are still the same), as we invoke > "openssl" from command line, we need to adjust test cases. > > > Ilya >
Re: Buffer limits when adding a large number of CA certs into one ca-file via socket
On Tue, Jul 26, 2022 at 03:04:41PM +, Lais, Alexander wrote: > Dear all, > > We are now using the new feature of adding CA files dynamically via the stats > / admin socket. > > Assuming that the CA file does not exist yet, our understanding is that we: > > 1. Create a CA file (new ssl ca-file customer-cas.pem) > > 2. Set the content of the CA file with payload notation; > "set ssl ca-file customer-cas.pem <<\n[a bunch of PEM blocks]\n” > > 3. Commit the CA file (commit ssl ca-file customer-cas.pem) > > In step 2 we are reaching the limit of the global buffer size (defined via > tune.bufsize, ours is tuned to ca. 71k, allowing for a comfortable 64k of > headers). > Some of the CA files that we want to add are larger than this buffer and are > not properly processed by the CLI. > > It is understandable that the CLI socket needs some buffer and that this > buffer is limited. > That said, reading the CA files data from disk does not pose any > (perceivable) size limit. We recently implemented a dynamic update to avoid > having to reload the HAProxy process whenever there was a change, and ran > into this issue. > > We’ve added a feature request on GitHub: > https://github.com/haproxy/haproxy/issues/1805 > > This e-mail is to ask whether maybe we have overlooked something in terms of > configuration possibilities, either for the socket or on how to use the CLI > for creating ca-files? > You are indeed reaching a limitation of the current system, I'll reply directly on your feature request. Thanks, -- William Lallemand
Re: "Success" logs in HTTP frontends
On Fri, Jul 29, 2022 at 11:10:32AM +0200, Christopher Faulet wrote: > Le 7/29/22 à 10:13, Christian Ruppert a écrit : > > Hi list, > > > > so I noticed on my private HAProxy I have 2 of those logs within the > > past ~1-2 months: > > haproxy[28669]: 1.2.3.4:48596 [17/Jun/2022:13:55:18.530] public/HTTPSv4: > > Success > > > > So that's nothing so far but still no idea what that means. > > At work, of 250 mio log entries per day, there are about 600k of those > > "Success" ones. > > haproxy[27892]: 192.168.70.102:7904 [29/May/2022:00:13:37.316] > > genfrontend_35310-foobar/3: Success > > > > I'm not sure what it means by "3". Is it the third bind? > > > > I couldn't trigger those "Success" logs by either restarting or > > reloading. What is it for / where does it come from? > > > > Hi Christian, > > What is your version ? At first glance, I can't find such log message in the > code. It could come from a lua module. > > In fact, I found something. It is probably because an "embryonic" session is > killed with no connection/ssl error. For instance, an SSL connection rejected > because of a "tcp-request session" rule (so after the SSL handshake). The > same > may happen with a listener using the PROXY protocol. > > Regards, Could be something like that indeed, the "Success" message is the string for CO_ER_NONE in the fc_err_str fetch. (The default error string) Maybe we lack some intermediate state, or we could just change the string ? It is only the string for the handshake status so this is confusing when used as an error. -- William Lallemand
Re: "Success" logs in HTTP frontends
Le 7/29/22 à 11:21, Tim Düsterhus a écrit : Hi On 7/29/22 11:10, Christopher Faulet wrote: What is your version ? At first glance, I can't find such log message in the code. It could come from a lua module. I'm seeing the same for both 2.4.x and 2.6.x. Christian and I had a short chat about this in IRC. In fact, I found something. It is probably because an "embryonic" session is killed with no connection/ssl error. For instance, an SSL connection rejected because of a "tcp-request session" rule (so after the SSL handshake). The same may happen with a listener using the PROXY protocol. On one of the machines I'm seeing it, we neither have 'tcp-' rules, nor do we use PROXY protocol: Well, it may have several reason to kill an embryonic session with no error. a reject at the session level is one of them. Probably the most common. It may also be an error when we try to install the client mux. The configuration may help in this case. I don't know if it is possible to have an handshake failure without setting any error. However, at first glance, the error is always set in this case. Of course, it may be a bug. If not, such messages can be removed by setting "dontlognull" option. -- Christopher Faulet
option redispatch, http/tcp
Hello everyone, I'm not sure about something related to the redispatch option. When I search the internet, many people indicate that the redispatch option only works with http mode. But the main purpose of the "redispatch option" is to redispatch to another server when you can't establish a TCP connection with a server, so it seems that it is also applicable to a TCP mode. Can you clarify this point please (the documentation is a bit unclear on this subject) ? Thanks.
Re: "Success" logs in HTTP frontends
Hi On 7/29/22 11:10, Christopher Faulet wrote: What is your version ? At first glance, I can't find such log message in the code. It could come from a lua module. I'm seeing the same for both 2.4.x and 2.6.x. Christian and I had a short chat about this in IRC. In fact, I found something. It is probably because an "embryonic" session is killed with no connection/ssl error. For instance, an SSL connection rejected because of a "tcp-request session" rule (so after the SSL handshake). The same may happen with a listener using the PROXY protocol. On one of the machines I'm seeing it, we neither have 'tcp-' rules, nor do we use PROXY protocol: $ cat /etc/haproxy/haproxy.cfg |grep proxy |grep -v /etc/haproxy chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners user haproxy group haproxy $ cat /etc/haproxy/haproxy.cfg |grep tcp- > $ Best regards Tim Düsterhus
Re: "Success" logs in HTTP frontends
Le 7/29/22 à 10:13, Christian Ruppert a écrit : Hi list, so I noticed on my private HAProxy I have 2 of those logs within the past ~1-2 months: haproxy[28669]: 1.2.3.4:48596 [17/Jun/2022:13:55:18.530] public/HTTPSv4: Success So that's nothing so far but still no idea what that means. At work, of 250 mio log entries per day, there are about 600k of those "Success" ones. haproxy[27892]: 192.168.70.102:7904 [29/May/2022:00:13:37.316] genfrontend_35310-foobar/3: Success I'm not sure what it means by "3". Is it the third bind? I couldn't trigger those "Success" logs by either restarting or reloading. What is it for / where does it come from? Hi Christian, What is your version ? At first glance, I can't find such log message in the code. It could come from a lua module. In fact, I found something. It is probably because an "embryonic" session is killed with no connection/ssl error. For instance, an SSL connection rejected because of a "tcp-request session" rule (so after the SSL handshake). The same may happen with a listener using the PROXY protocol. Regards, -- Christopher Faulet
