Re: How to verify HAProxy build on Solaris/SPARC ?
Hi, I tried Willy's suggestion with -pthread in the OPTIONS_CFLAGS and it didn't make any difference. Same errors. I haven't tried looking at it anymore other than to try Willy's test. Although I didn't mention it previously, I had seen that suggestion of trying USE_PTHREAD_SHARED=1. It also didn't help with 1.8.9, but I haven't tried with 1.8.13. If you think of any other tests you'd like me to try, let me know. Thanks, -- Tom On Fri, Aug 31, 2018 at 5:24 AM Olivier Houchard wrote: > Hi Lukas, > > On Fri, Aug 31, 2018 at 02:03:47PM +0200, Lukas Tribus wrote: > > Hello, > > > > > > On Fri, 31 Aug 2018 at 04:30, Willy Tarreau wrote: > > > I'd like to ask you to test something just in case it helps. Could > > > you please modify your makefile to add "-pthread" to "-DUSE_THREAD" > > > like this : > > > > > > ifneq ($(USE_THREAD),) > > > BUILD_OPTIONS += $(call ignore_implicit,USE_THREAD) > > > -OPTIONS_CFLAGS += -DUSE_THREAD > > > +OPTIONS_CFLAGS += -DUSE_THREAD -pthread > > > OPTIONS_LDFLAGS += -lpthread > > > endif > > > > Note that in a thread from July Oliver concluded that > > USE_PTHREAD_PSHARED=1 is needed under Solaris: > > > > https://www.mail-archive.com/haproxy@formilux.org/msg30696.html > > > > > > Not sure if we are talking about the same exact issue here though. > > > > I think in this case it is fine, as its gcc is recent enough to have > the required builtins. > > Regards, > > Olivier >
haproxy-auth-request
Hi Gurus; I was in the IRC channel the other day looking for a way to get authentication through apache's authnz-external working from haproxy; specifically I have a few nodejs applications and I want to put an authentication system using imap in front. I already have authnz-external working so it would be convenient to continue using it. dcorbett suggested I investigate lua, which led me to finding https://github.com/TimWolla/haproxy-auth-request. seems like just the thing I need. After I checked that I met all the criteria and installed it and got every thing setup and worked out my mistakes, I was left with log entries like: Lua function 'auth-request': runtime error: haproxy.auth.lua:48: bad argument #1 to 'old_settimeout' (number expected, got nil) from [C] field 'request', haproxy.auth.lua:95 C function line 56. Fortunately, the author was most excellent and documented the history of this script here: https://bl.duesterhus.eu/20180119/, specifically the section regarding haproxy's sockets. Through that post and also comments in the github script containing links to https://www.mail-archive.com/haproxy@formilux.org/msg28604.html and https://www.mail-archive.com/haproxy@formilux.org/msg28574.html, I am lead to believe this should be an fixed in my apt-installed version of haproxy 1.8.13-1. I have been investigating, commenting code, and hacking by trial and error to find a solution, but so far I am not able to get past this point. Clearly my skills and understanding are not yet where they need to be, being relatively new to both haproxy and lua. It occurs that this could be a lua problem (as opposed to haproxy), but according to what I have read and understood, it seems that this is related to haproxy's implementation of lua more than lua itself. Hence I am asking here first. Wondering if anyone can offer some insight, or point me at some required reading that might shed some light on this but isn't aimed at a developer level of understanding? I have read through https://www.arpalert.org/haproxy-lua.html#h211 a time or two, but if there is a shining light bulb in there it hasn't blinded me yet. -- Bob Miller Cell: 867-334-7117 Office: 867-633-3760 www.computerisms.ca
RE: URL rewrite
I just realized that this isn't actually correct: in their web browser it gets proxied to a backend running at https://.cloud.example.com/main?query I need this request: https://cloud.example.com/[/]?query to be sent to the backend server directly as http://.cloud.example.com/?query I assume I can use http-request set-uri to rewrite the incoming URL. I assume I can grab the host name thus: http-request set-var(req.header_host) req.hdr(host) But how do I grab the path? And separate the remainder of the path if necessary, so I can reassemble the URL as described above? -Original Message- From: Norman Branitsky Sent: Monday, August 27, 2018 6:53 PM To: 'Tim Düsterhus' ; haproxy Subject: RE: URL rewrite Your examples are all correct. -Original Message- From: Tim Düsterhus Sent: Monday, August 27, 2018 6:22 PM To: Norman Branitsky ; haproxy Subject: Re: URL rewrite Norman, Am 27.08.2018 um 23:45 schrieb Norman Branitsky: > I need to rewrite my URLs according to the following pattern: > cloud.example.com/?query > becomes: > .cloud.example.com/main?query > > HAProxy will terminate SSL - I have a wildcard certificate for > *.cloud.example.com. > As the target servers are running Docker Enterprise, I do not need DNS > entries for every possible instance of as Docker EE will handle > this internally. > Is there a way to do this? > What exactly do you mean by rewrite? Do you want that when a user requests https://cloud.example.com/?query in their web browser it gets proxied to a backend running at https://.cloud.example.com/main?query ? Is it possible that there follows a path that you need to preserve: https://cloud.example.com///?query to https://.cloud.example.com/main//?query ? Best regards Tim Düsterhus
Re: How to verify HAProxy build on Solaris/SPARC ?
Hi Lukas, On Fri, Aug 31, 2018 at 02:03:47PM +0200, Lukas Tribus wrote: > Hello, > > > On Fri, 31 Aug 2018 at 04:30, Willy Tarreau wrote: > > I'd like to ask you to test something just in case it helps. Could > > you please modify your makefile to add "-pthread" to "-DUSE_THREAD" > > like this : > > > > ifneq ($(USE_THREAD),) > > BUILD_OPTIONS += $(call ignore_implicit,USE_THREAD) > > -OPTIONS_CFLAGS += -DUSE_THREAD > > +OPTIONS_CFLAGS += -DUSE_THREAD -pthread > > OPTIONS_LDFLAGS += -lpthread > > endif > > Note that in a thread from July Oliver concluded that > USE_PTHREAD_PSHARED=1 is needed under Solaris: > > https://www.mail-archive.com/haproxy@formilux.org/msg30696.html > > > Not sure if we are talking about the same exact issue here though. > I think in this case it is fine, as its gcc is recent enough to have the required builtins. Regards, Olivier
Re: [PATCH] REGTEST: stick-tables: Test expiration when used with table_*
On Fri, Aug 31, 2018 at 11:14:00AM +0200, Frederic Lecaille wrote: > Hi, > > I am coming back to this reg testing sent by Daniel which was very > interesting because very complete and because there was a little > detail to fix. (...) applied, thanks Fred. Willy
Re: [PATCH] REGTEST: stick-tables: Test expiration when used with table_*
Hi,
I am coming back to this reg testing sent by Daniel which was very
interesting because very complete and because there was a little
detail to fix.
On 06/21/2018 04:53 AM, Willy Tarreau wrote:
Hi Daniel,
On Wed, Jun 20, 2018 at 10:28:43AM -0400, Daniel Corbett wrote:
+shell -expect "used:0" {
+echo "show table http1" |socat ${tmpdir}/h1/stats.sock -
As mentioned in previous mails, but after the first version of
this reg testing file, we can now use -cli argument to send commands
to the CLI which is automatically created for each script without
having to mention it in the configuration file (with -conf argument).
So the shell command above may be replaced by this section:
haproxy h1 -cli {
send "show table http1"
expect ~ "used: 0"
} -wait
The little detail to fix is that on my PC the CLI expect command may
sometimes fail because the unique stick-table entry created during
this script may sometime still be present when we dump the stick-table.
So here we expect to have no entry at all, or an entry with a null "use"
counter (use=0).
A correct regex would be something like 'used: (0|1\n.*use=0.*)\n$'.
Find attached to this mail Daniel's reg testing file with
the fixes mentioned above.
Fred.
>From 18692c4dd350ff6ef3609a56bd0162517590f2f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Fri, 31 Aug 2018 11:05:39 +0200
Subject: [PATCH] REGTEST/MINOR: Add a reg testing file for 3e60b11.
Thank you to Daniel for having worked on this one.
---
reg-tests/stick-table/b1.vtc | 70
1 file changed, 70 insertions(+)
create mode 100644 reg-tests/stick-table/b1.vtc
diff --git a/reg-tests/stick-table/b1.vtc b/reg-tests/stick-table/b1.vtc
new file mode 100644
index ..43e25eb2
--- /dev/null
+++ b/reg-tests/stick-table/b1.vtc
@@ -0,0 +1,70 @@
+# commit 3e60b11
+# BUG/MEDIUM: stick-tables: Decrement ref_cnt in table_* converters
+#
+# When using table_* converters ref_cnt was incremented
+# and never decremented causing entries to not expire.
+#
+# The root cause appears to be that stktable_lookup_key()
+# was called within all sample_conv_table_* functions which was
+# incrementing ref_cnt and not decrementing after completion.
+#
+# Added stktable_release() to the end of each sample_conv_table_*
+# function and reworked the end logic to ensure that ref_cnt is
+# always decremented after use.
+#
+# This should be backported to 1.8
+
+varnishtest "stick-tables: Test expirations when used with table_*"
+
+# As some macros for haproxy are used in this file, this line is mandatory.
+feature ignore_unknown_macro
+
+# Do nothing.
+server s1 {
+} -start
+
+haproxy h1 -conf {
+# Configuration file of 'h1' haproxy instance.
+defaults
+mode http
+timeout connect 5s
+timeout server 30s
+timeout client 30s
+
+frontend http1
+bind "fd@${my_frontend_fd}"
+stick-table size 1k expire 1ms type ip store conn_rate(10s),http_req_cnt,http_err_cnt,http_req_rate(10s),http_err_rate(10s),gpc0,gpc0_rate(10s),gpt0
+http-request track-sc0 req.hdr(X-Forwarded-For)
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_http_req_cnt(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_trackers(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),in_table(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_bytes_in_rate(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_bytes_out_rate(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_conn_cnt(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_conn_cur(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_conn_rate(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_gpt0(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_gpc0(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_gpc0_rate(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if { req.hdr(X-Forwarded-For),table_http_err_cnt(http1) -m int lt 0 }
+http-request redirect location https://${s1_addr}:${s1_port}/ if {
