Re: lua function core.get_info() broken in haproxy 2.2.7
Ah, never mind, I see that this was already fixed in master in 3ddec3ee7d344112b4e4fbde317f8886a20d66a0. On Fri, Jan 29, 2021 at 6:01 PM James Brown wrote: > As of haproxy 2.2.7, the core.get_info() lua function no longer works. > Calling it raises a runtime error of the following: > > [ALERT] 029/015726 (65429) : lua init: runtime error: table index is nil > from [C] field 'get_info', test.lua:2 C function line 1. > > This worked in haproxy 2.2.6 and all previous versions. > > I did a `git bisect` of the history between v2.2.6 and v2.2.7 and it > claims that the offending commit > is ce3e98eb1f9240b7633c5de6855dd115e61708ae; I can verify that the > reproduction below is OK with b50434 and fails with ce3e98eb although I > can't for the life of me tell you why, since ce3e98eb looks pretty > innocuous to me. > > Reproduction files: > > *test.lua* > > function poc() > local info = core.get_info() > end > > core.register_init(poc) > > > *test.cfg* > > global > log stdout user > lua-load "test.lua" > > defaults > log global > timeout client 9s > timeout server 10s > timeout connect 1s > > frontend test_fe > mode http > bind localhost: > default_backend test_be > > > backend test_be > mode http > server localhost 127.0.0.1:9998 > > > -- > James Brown > Engineer > -- James Brown Engineer
lua function core.get_info() broken in haproxy 2.2.7
As of haproxy 2.2.7, the core.get_info() lua function no longer works. Calling it raises a runtime error of the following: [ALERT] 029/015726 (65429) : lua init: runtime error: table index is nil from [C] field 'get_info', test.lua:2 C function line 1. This worked in haproxy 2.2.6 and all previous versions. I did a `git bisect` of the history between v2.2.6 and v2.2.7 and it claims that the offending commit is ce3e98eb1f9240b7633c5de6855dd115e61708ae; I can verify that the reproduction below is OK with b50434 and fails with ce3e98eb although I can't for the life of me tell you why, since ce3e98eb looks pretty innocuous to me. Reproduction files: *test.lua* function poc() local info = core.get_info() end core.register_init(poc) *test.cfg* global log stdout user lua-load "test.lua" defaults log global timeout client 9s timeout server 10s timeout connect 1s frontend test_fe mode http bind localhost: default_backend test_be backend test_be mode http server localhost 127.0.0.1:9998 -- James Brown Engineer
Re: Makefile, environment variables and REGTESTS_TYPES
On Fri, Jan 29, 2021 at 2:46 PM William Lallemand
wrote:
> According to `make reg-tests-help` the REGTESTS_TYPES parameter must be
> configured as an environment variable and not a make argument.
> However since patch 3bad3d5 ("BUILD: Makefile: exclude broken tests by
> default"), it does not work anymore with an environment variable.
> Looking at the several CI files we have, it is used as a make
> argument everywhere.
wow indeed, I did not realise that; yet another thing I broke ;-)
> I'm going to update the `make reg-tests-help` command with the correct
> syntax if there isn't any complain.
Thanks for looking into this!
--
William
Makefile, environment variables and REGTESTS_TYPES
Hello List,
According to `make reg-tests-help` the REGTESTS_TYPES parameter must be
configured as an environment variable and not a make argument.
However since patch 3bad3d5 ("BUILD: Makefile: exclude broken tests by
default"), it does not work anymore with an environment variable.
Looking at the several CI files we have, it is used as a make
argument everywhere.
I'm going to update the `make reg-tests-help` command with the correct
syntax if there isn't any complain.
We could fix the issue by using "?=" when setting the default value, but
it would make it the only variable that use "?=" in the Makefile and I'm
not sure we want to proceed this way.
Regards,
--
William Lallemand
Re: Question about rfc8441 (Bootstrapping WebSockets with HTTP/2)
On 29.01.21 12:27, Christopher Faulet wrote: Le 22/01/2021 à 07:08, Willy Tarreau a écrit : On Thu, Jan 21, 2021 at 11:09:33PM +0100, Aleksandar Lazic wrote: On 21.01.21 21:57, Christopher Faulet wrote: Le 21/01/2021 à 21:19, Aleksandar Lazic a écrit : Hi. I'm not sure if I have missed something, because there are so many great features now in HAProxy, therefore I just ask here. Is the rfc8441 (Bootstrapping WebSockets with HTTP/2) possible in HAProxy now? Hi, It is not possible right now. But it will be very very soon. Amaury implemented the H2 websocket support and it works pretty well. Unfortunately, this relies on some tricky fixes on the tunnel management that must be carefully reviewed. It is a nightmare to support all tunnel combinations. But I've almost done the review. I must split a huge patch in 2 or 3 smaller and more manageable ones. I'm on it and I will do my best to push it very soon. Anyway, it will be a feature for the 2.4. Wow that sounds really great. Thank you for your answer. And by the way initially we thought we'd backport Amaury's work to 2.3, but give the dependency with the tunnel stuff that opened this pandora box, now I'm pretty sure we won't :-) One nice point is that he managed to natively support the WS handshake, it's not just a blind tunnel anymore, so that it's possible to have WS using either H1 or H2 on the frontend, and either H1 or H2 on the backend. Now we're really seeing the benefits of HTX because while at each extremity we have a very specific WS handshake, in the middle we just have a tunnel using a WS protocol, which allows a CONNECT on one side to become a GET on the other side. As Christopher said, the tunnel changes are extremely complicated because these uncovered some old limitations at various levels, and each time we reviewed the pending changes we could imagine a situation where an odd use case would break if we don't recursively go into another round of refactoring at yet another deeper level. But we're on the right track now, things start to look good. FYI, the HTTP/2 websockets support is now available and will be part of the next 2.4-dev release (2.4-dev7) Cool thanks.
Re: Inquiry
Hi, On Tue, 2021-01-26 at 15:55 +0100, Alexander Rossow wrote: > Im currently using HAProxy as a http proxy infront of another http > superproxy. HAProxy is used for authentication and then changes the Proxy > credentials to those of the superproxy. However, we need to keep track of > the data usage for each user. Since the superproxy is not made from our > end, we cannot influence it at all and it ignores any "Connection: Close" > headers. Therefore if a client uses our proxy (haproxy) and the client > does not close the socket, the socket can stay open for multiple minutes. > During this time we will not be able to account for the usage as the usage > is only logged once the socket is closed. This then leads to the user > being able to use our service for a greatly longer duration that he/she is > supposed to. This is why theres 2 solutions I can think of. Have thought about using stick-tables to track clients/users: https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#stick-table -Jarno > Solution A) > A way that haproxy logs frequently during the entire socket duration so we > can then reload haproxy to close all sockets once a user runs out of data > to use. > > Solution B) > A way to use LUA during the actual tunneling (after the HTTP tunnel is > established) so that we can reauthenticate users and log the usage > ourselves. > > Am Di., 26. Jan. 2021 um 15:12 Uhr schrieb Jarno Huuskonen < > jarno.huusko...@uef.fi>: > > Hi, > > > > On Tue, 2021-01-26 at 14:32 +0100, Alexander Rossow wrote: > > > Hi there, > > > I would like to know if it is possible to update the logs while the > > socket > > > is open. Currently the logs are updated only after closing the socket, > > > which causes issues. We have already tried the http close and the > > https > > > close server options. Unfortunately without success > > > Thanks in advance > > > > > > > option logasap ? > > ( > > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-option%20logasap > > ) -- Jarno Huuskonen
Re: Question about rfc8441 (Bootstrapping WebSockets with HTTP/2)
Le 22/01/2021 à 07:08, Willy Tarreau a écrit : On Thu, Jan 21, 2021 at 11:09:33PM +0100, Aleksandar Lazic wrote: On 21.01.21 21:57, Christopher Faulet wrote: Le 21/01/2021 à 21:19, Aleksandar Lazic a écrit : Hi. I'm not sure if I have missed something, because there are so many great features now in HAProxy, therefore I just ask here. Is the rfc8441 (Bootstrapping WebSockets with HTTP/2) possible in HAProxy now? Hi, It is not possible right now. But it will be very very soon. Amaury implemented the H2 websocket support and it works pretty well. Unfortunately, this relies on some tricky fixes on the tunnel management that must be carefully reviewed. It is a nightmare to support all tunnel combinations. But I've almost done the review. I must split a huge patch in 2 or 3 smaller and more manageable ones. I'm on it and I will do my best to push it very soon. Anyway, it will be a feature for the 2.4. Wow that sounds really great. Thank you for your answer. And by the way initially we thought we'd backport Amaury's work to 2.3, but give the dependency with the tunnel stuff that opened this pandora box, now I'm pretty sure we won't :-) One nice point is that he managed to natively support the WS handshake, it's not just a blind tunnel anymore, so that it's possible to have WS using either H1 or H2 on the frontend, and either H1 or H2 on the backend. Now we're really seeing the benefits of HTX because while at each extremity we have a very specific WS handshake, in the middle we just have a tunnel using a WS protocol, which allows a CONNECT on one side to become a GET on the other side. As Christopher said, the tunnel changes are extremely complicated because these uncovered some old limitations at various levels, and each time we reviewed the pending changes we could imagine a situation where an odd use case would break if we don't recursively go into another round of refactoring at yet another deeper level. But we're on the right track now, things start to look good. FYI, the HTTP/2 websockets support is now available and will be part of the next 2.4-dev release (2.4-dev7) -- Christopher Faulet
Re: [PATCH 2/2] CI: Fix DEBUG_STRICT definition for Coverity
14 issues "eliminated" by BUG_ON visibility. [image: Screenshot from 2021-01-29 13-08-49.png] пт, 29 янв. 2021 г. в 01:42, Илья Шипицин : > > > пт, 29 янв. 2021 г. в 00:39, Willy Tarreau : > >> On Fri, Jan 29, 2021 at 12:37:55AM +0500, ??? wrote: >> > ??, 29 ???. 2021 ?. ? 00:05, Willy Tarreau : >> > >> > > On Thu, Jan 28, 2021 at 07:11:15PM +0100, Tim Düsterhus wrote: >> > > > During dinner I had an idea how to fix this without introducing much >> > > > additional complexity, I simply modify the Makefile in the Coverity >> > > > workflow before starting the Coverity check. For the DEBUG variable >> this >> > > > is fairly clean. >> > > >> > > Yep, good idea. And that's an area we've not changed often over time >> so >> > > it should not require much maintenance. >> > > >> > > Let's wait for Ilya's test before claiming victory ;-) >> > > >> > >> > I confirm couple of things >> > >> > 1) patch works: >> > >> > >> > https://github.com/chipitsine/haproxy/runs/1786473668 >> > https://github.com/chipitsine/haproxy/runs/1786473668 >> > >> > 2) BUG_ON now seen by coverity >> >> Perfect, thank you Ilya, so I'm merging it. >> > > We are very close to fixing all coverity issues, btw > around 20 issues left. > > > >> >> Good job guys! >> Willy >> >
