disabling test if ipv6 not supported ?
Hello, seems, freebsd images on cirrus-ci run with no ipv6 support https://cirrus-ci.com/task/6613883307687936 any idea how we can skip such tests ? Cheers, Ilya Shipitcin
[PR] The agent-check fail state is represented as "fail"
Dear list! Author: Jack Neely Number of patches: 1 This is an automated relay of the Github pull request: The agent-check fail state is represented as "fail" Patch title(s): The agent-check fail state is represented as "fail" Link: https://github.com/haproxy/haproxy/pull/642 Edit locally: wget https://github.com/haproxy/haproxy/pull/642.patch && vi 642.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/642.patch | git am - Description: Documentation has stated the string is "failed" and this doesn't match the source code. An agent-check returning "failed" causes HAProxy to not make state changes. Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
Re: [PATCH] fix libslz url in travis
Hi Ilya, On Tue, May 19, 2020 at 01:51:29AM +0500, ??? wrote: > Hello, > > travis timed out when downloading libslz > > fatal: unable to access 'http://git.1wt.eu/git/libslz.git/': Failed to > connect to git.1wt.eu port 80: Connection timed out > > The command "git clone http://git.1wt.eu/git/libslz.git/; failed and > exited with 128 during . > > it is something related to travis. I can access that URL. Now pushed, thanks. I've seen this error reported as well while it does work for me, I don't know why. Maybe they don't allow to connect to port 80 anymore, I have no idea. As long as it work with the alternate URL it's fine. Willy
Re: [PR] Add verfied chain
On Mon, May 18, 2020 at 08:09:36PM +0200, William Dauchy wrote: > Hi Arjen, > > On Mon, May 18, 2020 at 6:02 PM Arjen Nienhuis wrote: > > I used PKCS7 because I did not know how to parse concatenated blobs. > > Mathilde, how did we planned to use it? :) > > > I think you should use SSL_get_peer_cert_chain because: > > - BoringSSL has no SSL_get0_verified_chain. > > - For debugging having all the certs is better. Especially if the chain > > is not valid. > > - In theory it's not always possible to do OCSP with the verified chain. > > OCSP is part of finding a valid chain. OpenSSL could choose a cert chain > > that doesn't pass OCSP while an other chain exists that can pass OCSP. > > Thank you for your feedbacks. > Do you want to handle the changes? Otherwise we can handle them and > mention you as the original proposition in the commit message. As you > wish. Hello guys, I just wanted to notify you that we are soon reaching the release of the 2.2 version. If the patches are ready before the end of the month, I'm okay with taking them for this branch since this is not a major change. -- William Lallemand
Re: 2.0.14 + htx / retry-on all-retryable-errors -> sometimes wrong backend/server used
Hi Jarno, On Tue, May 19, 2020 at 03:26:22PM +, Jarno Huuskonen wrote: > Hi, > > On Tue, 2020-05-19 at 15:58 +0200, Christopher Faulet wrote: > > It was already reported on github and seems to be fixed. We are just > > waiting a > > feedback to be sure it is fixed before backporting the patch. See > > https://github.com/haproxy/haproxy/issues/623. > > > > If you try the latest 2.2 snapshot, it should be good. You may also > > try to > > cherry-pick the commit 8cabc9783 to the 2.0. > > Thanks Christopher (and Tim), I'll try with 2.2 snapshot (and/or) > 8cabc9783 and report how it goes. Note, regarding this, I'd like us to emit another set of stable versions but we've got a report of a very tricky situation involving l7 retries and HTTP reuse which can sometimes lead to a crash in versions prior to 2.0, and I'd really like to understand it fully, reproduce it and fix it. So in the mean time, it's possible that 2.2 would be more reliable than 2.0 when it comes to l7 retries. Cheers, Willy
Re: [PATCH 0/6] Lua variable handling
On Tue, May 19, 2020 at 05:39:25PM +0200, Christopher Faulet wrote: > Le 19/05/2020 à 16:06, Tim Düsterhus a écrit : > > > > > > Now back on topic. Instead of adding more parameters to set_var(), I'd > > > prefer a warning instead. > > > > > > If someone is using set_var() from Lua, and that variable is never used > > > or set in the rest of the config, we would know that. Additionally, one > > > can set "zero-warning" option to prevent abuse by Lua scripts or to > > > prevent bugs. > > > > This would break my use case for haproxy-auth-request. The plan is that > > the Lua script unconditionally sets are variable for all response > > headers and that HAProxy with my patches applied drops the variables > > that are never going to be read. I specifically want to avoid that the > > administrator needs to configure the headers to expose. Details are in: > > https://github.com/TimWolla/haproxy-auth-request/pull/13 > > > > I agree with Tim. It is pretty handy to let the set_var silently fail. This > way, a script can expose many variables and let the user choose those he > needs. The same is already done in the SPOE. > Then, we've chosen to be backward compatible and let any variable be > dynamically registered from LUA. There is a warning in the LUA > documentation. It is now the developers responsibility to be careful. I > doubt it will be a source of problems. But if so, it could be changed. Well, it's exactly the same in shell scripts, you set and read variables and if you misspell them it's the developer's problem. And this is very convenient and flexible. Willy
