Re: undefined symbol: lua_getmetatable in using luasocket
Thankyou Cyril. I could not get it work with 5.3 either, I am now trying to use built in sockets with core.tcp(). On 7/19/16, 4:00 AM, "Cyril Bonté" wrote: >Hi Sachin, > >Le 18/07/2016 à 16:16, Sachin Shetty a écrit : >> (...) >> However when starting haproxy, I get this error: >> >> [ALERT] 199/063903 (7106) : parsing >> [/home/egnyte/haproxy/conf/haproxy.conf:9] : lua runtime error: error >> loading module 'socket.core' from file >> '/usr/local/lib/lua/5.1/socket/core.so': >> >> /usr/local/lib/lua/5.1/socket/core.so: undefined symbol: >>lua_getmetatable > > From this previous line, it's not a haproxy issue. It looks like you >are using a lua library for the wrong lua version. >Try to use the library for lua 5.3. > >> >> >> Standalone lua scripts is fine with the require ³socket² line and I do >> see the output, but it fails to load within haproxy. >> >> >> Thanks >> >> Sachin >> >> >> >> >> > > >-- >Cyril Bonté
Wrong http_err_rate on standby peer
Hi all, i'm using a stick-table with HAProxy 1.6.7 on an active/standby configuration like this: stick-table type ipv6 size 500k expire 60s peers hacluster store gpc0,conn_cur,http_req_rate(10s),http_err_rate(10s) http-request track-sc0 On the standby peer the table obviously shows wrong http_err_rates: 0xe6ce10: key=xxx use=0 exp=59598 gpc0=0 conn_cur=1 http_req_rate(1)=1 http_err_rate(1)=346 0xe3ed80: key=xxx use=0 exp=58440 gpc0=0 conn_cur=1 http_req_rate(1)=27 http_err_rate(1)=38841809 The active peer seems to behave as expected and shows very low error rates. I'm no programmer, but i think it has to do with "frqp->curr_tick" in "peers.c" which seems to have the value "0" if the very first error appears. This leads to sending "now_ms" to the peer. If i check "frqp->curr_tick" before the encoding like if (frqp->curr_tick == 0) frqp->curr_tick = now_ms; the error rates seems reasonable on the standby peer. Kay Fuchs
Dynamic backends decided by an external service
Hi,
We always had a unique requirement of picking a backend based on response
from a external http service. In the past we have got this working by
routing requests via a modified apache and caching the headers in maps for
further request, but now I am trying to simplify our topology and trying to
get this done using just haproxy and lua.
I am running in to some problems:
Lua method:
function choose_backend(txn)
local host = txn.http:req_get_headers()["host"][0]
core.Alert("Getting Info:" .. host)
local sock = core.tcp()
sock:connect("127.0.0.1", 6280)
sock:send("GET /eos/rest/private/gds/l1/1.0/domain/" .. host ..
"\r\n")
result = sock:receive("*a")
sock:close()
core.Alert("Received Response:" .. result .. "<")
core.set_map("/tmp/proxy_webui.map", host, result)
core.Alert("Map Set:" .. host .. "-->" .. result .. "<")
end
core.register_action("choose_backend", { "http-req" }, choose_backend)
Haprpxy Conf:
frontend luatest
mode http
maxconn 1
bind *:9000
use_backend %[hdr(host),lower,map(/tmp/proxy_webui.map)] if FALSE #
To declare the map
http-request lua.choose_backend
tcp-request content capture hdr(host),map(/tmp/proxy_webui.map) len
80
acl is_ez_pod capture.req.hdr(0) http://127.0.0.1:6280
use_backend ez_pod if is_ez_pod
backend ez_pod
server ez_pod 192.168.56.101:6280 maxconn 2
There are some issues:
1. I do see Map Set called correctly in the logs, but the haproxy capture
does not find the key in the map for the first request. Is this related to
async execution of luna routine?
2. I expected subsequent requests to see the value atleast, but even that is
not consistent, some request see the value in the map and some don¹t
Is there a better way to do this? I already found that I cannot invoke the
luna routine with use_backend because yield is not allowed in a sample fetch
context.
What would be the best way to achieve this, our requirement is similar to
what can be done with redis+nginx here:
http://openresty.org/en/dynamic-routing-based-on-redis.html except for we
have an http service that decides the backend instead of a redis service.
Thanks
Sachin
IT decision makers list 2016
Hi , Hope you are having a pleasant day. Would you be interested in acquiring our recently complied 1 Million+ IT Decision makers list across EMEA and APAC or even across the globe with complete information for your marketing initiatives? Some of the Title': IT manager, IT Director, CIO, CTO, IT Security, IT Service, CEO, CISO. Data Intelligence: - Contact Name, title, email, phone, fax, company -name, web, physical address (City, state, country), revenue, employee size, SIC code, LinkedIn links and Primary industry. If interested, let me know so that I can send more information in my next email. Await your response, Best regards, David Christopher Marketing Executive Technology Data | Healthcare Data| Industrial Data| Consumer Data| Email appending | Email campaigns |Lead Generation | Data Cleansing | Tele Marketing | Digital Marketing Services If you wish to stop receiving emails from us, please reply with the email subject line as "Leave out".
Re: Host name resolution in IPv6 only entry in /etc/hosts
Makes sense, I assumed that the Debian package was compiled with that
option by default...it's a PITA that it is not, do you think this is
something to be reported to the maintainers of the package?
HA-Proxy version 1.6.6 2016/06/26
Copyright 2000-2016 Willy Tarreau
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -g -O2 -fPIE -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2
OPTIONS = USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.1t 3 May 2016
Running on OpenSSL version : OpenSSL 1.0.1t 3 May 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.35 2014-04-04
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
On Mon, Jul 18, 2016 at 11:53 PM, Nenad Merdanovic wrote:
> Dropped ML by mistake
>
> On 07/18/2016 11:47 PM, Nenad Merdanovic wrote:
> > Hello,
> >
> > On 07/18/2016 02:41 PM, Albert Casademont wrote:
> >> Hi!
> >>
> >> I was trying to configure am IPv6 only backend using the hostname in
> >> /etc/hosts and the HAProxy kept failing to initialize. As soon as I put
> >> an IPV4 address for that hostname in /etc/hosts it worked. I have
> >> resorted to manualy putting the IPV6 address in the HAProxy config file,
> >> but ideally an IPV6 only hostname should work.
> >>
> >> Sample config:
> >>
> >> server test1 test1.domain:80
> >>
> >> In /etc/hosts
> >>
> >> ::1 test1.domain
> >>
> >> It will fail to initialize
> >>
> >
> > Can you check 'haproxy -vv' to see if HAproxy is compiled with
> > USE_GETADDRINFO, if not, compile it with that option "make TARGET=...
> > USE_GETADDRINFO=1"
> >
> > It should work then, if gai.conf is OK.
> >
> > Regards,
> > Nenad
> >
>
1.6 vs 1.5 http-request add-header format
Hi,
The following construction worked in 1.5.4 and doesn't work in 1.6.7:
http-request add-header X-Haproxy-ACL
%[req.fhdr(X-Haproxy-ACL,-1)]over-3-connections-in-10-seconds, if {
src_conn_rate gt 3 }
while the one w/o the comma in the end works in 1.6.7 well:
http-request add-header X-Haproxy-ACL
%[req.fhdr(X-Haproxy-ACL,-1)]over-3-connections-in-10-seconds if {
src_conn_rate gt 3 }
There're no errors, it just doesn't put the value of the custom header
X-Haproxy-ACL in the log.
Is it a bug or a syntax change? What's the new syntax?
--
Best regards,
Alex
Re: Host name resolution in IPv6 only entry in /etc/hosts
Adding Vincent here, as he maintains the Debian package. On 7/19/2016 2:21 PM, Albert Casademont wrote: > Makes sense, I assumed that the Debian package was compiled with that > option by default...it's a PITA that it is not, do you think this is > something to be reported to the maintainers of the package? I am in favor of this change, especially since there are command line and configuration options to disable gai() even though it is enabled during build time. That being said, this change could break current configurations in such a way that IPv6 starts being used over IPv4, leading to backends not being available or silently breaking (RPAF/mod_realip or MySQL grants don't get updated are the first breakages that come to mind) Regards, Nenad
Re: undefined symbol: lua_getmetatable in using luasocket
Hi, Le 19/07/2016 à 10:10, Sachin Shetty a écrit : Thankyou Cyril. I could not get it work with 5.3 either, I am now trying to use built in sockets with core.tcp(). You should recheck your installation and verify that you are still not loading some 5.1 libraries. After a quick test on my laptop, I don't see any issue, everything works well. On 7/19/16, 4:00 AM, "Cyril Bonté" wrote: Hi Sachin, Le 18/07/2016 à 16:16, Sachin Shetty a écrit : (...) However when starting haproxy, I get this error: [ALERT] 199/063903 (7106) : parsing [/home/egnyte/haproxy/conf/haproxy.conf:9] : lua runtime error: error loading module 'socket.core' from file '/usr/local/lib/lua/5.1/socket/core.so': /usr/local/lib/lua/5.1/socket/core.so: undefined symbol: lua_getmetatable From this previous line, it's not a haproxy issue. It looks like you are using a lua library for the wrong lua version. Try to use the library for lua 5.3. Standalone lua scripts is fine with the require ³socket² line and I do see the output, but it fails to load within haproxy. Thanks Sachin -- Cyril Bonté -- Cyril Bonté
Re: rate limiting question
Hi,
Le 18/07/2016 à 11:30, hapr...@abisoft.biz a écrit :
Hello,
I have a sticky table for ip checks against high connection rate (for testing
purposes it's set now to 3 connections in 10 seconds):
frontend lb-useast
...
tcp-request content track-sc0 src
stick-table type ip size 500k expire 30s store
conn_cur,conn_rate(10s),http_req_rate(10s),http_err_rate(10s)
http-request add-header X-Haproxy-ACL
%[req.fhdr(X-Haproxy-ACL,-1)]over-3-connections-in-10-seconds, if {
src_conn_rate gt 3 }
...
default_backend logger
backend logger
server localhost localhost:5 send-proxy
frontend logger
...
acl whitelisted req.fhdr(X-Haproxy-ACL) -m beg whitelisted,
acl fail-validation req.fhdr(X-Haproxy-ACL) -m found
http-request deny if !whitelisted fail-validation
...
When I run 3 curl requests in a row, the table shows there were 5 connections
with 1 failed:
# echo "show table lb-useast" | socat - unix:/var/lib/haproxy/stats
# table: lb-useast, type: ip, size:512000, used:1
0x24b3628: key=x.y.222.4 use=0 exp=26100 conn_rate(1)=5 conn_cur=0
http_req_rate(1)=3 http_err_rate(1)=1
After doing some tests, indeed, it appears that with mode http and a
frontend/backend, conn_rate counters are incremented twice (before and
after).
The curl command is pretty straightforward:
for ((i=1;i<=3;i++)); do curl -s http://uat.my.com/privacy.html > /dev/null;
echo $i; done
With this loop, conn_rate will be 1, then 3, then 5.
I couldn't spend more time on the issue and won't have much time for it
next days, but you can try a workaround, by replacing tcp-request
content with tcp-request connection :
tcp-request connection track-sc0 src
How does haproxy count connections, so it gets 5 instead of 3?
PS haproxy version is 1.5.4
--
Cyril Bonté
Re: 1.6 vs 1.5 http-request add-header format
Hi again,
Le 19/07/2016 à 14:45, hapr...@abisoft.biz a écrit :
Hi,
The following construction worked in 1.5.4 and doesn't work in 1.6.7:
http-request add-header X-Haproxy-ACL
%[req.fhdr(X-Haproxy-ACL,-1)]over-3-connections-in-10-seconds, if {
src_conn_rate gt 3 }
while the one w/o the comma in the end works in 1.6.7 well:
http-request add-header X-Haproxy-ACL
%[req.fhdr(X-Haproxy-ACL,-1)]over-3-connections-in-10-seconds if {
src_conn_rate gt 3 }
There're no errors, it just doesn't put the value of the custom header
X-Haproxy-ACL in the log.
Is it a bug or a syntax change? What's the new syntax?
Sorry but I can't reproduce your issue, everything works well for both
1.5, 1.6 and 1.7 branches.
Can you provide your whole configuration for each of your tests, and the
steps to reproduce it ?
--
Cyril Bonté
consistent hash-mapping on header?
Hi Is it possible to do consistent hashing on information other than the IP address i.e. X-Forwarded-For header? I'm using Haproxy 1.5.17. Thank you Paul
Re: consistent hash-mapping on header?
Hello Paul, On 7/20/2016 2:59 AM, Paul McIntire wrote: > Hi > > Is it possible to do consistent hashing on information other than the IP > address i.e. X-Forwarded-For header? I'm using Haproxy 1.5.17. > > Thank you > Paul > I think you are looking for: balance hdr(X-Forwarded-For) hash-type consistent ... Regards, Nenad
tcp-mode session hangs on server restart
Hi, I'm looking for any enlightenment or suggestions on pursuing the following problem. After bouncing a server with two tcp-mode sessions, my second reconnecting session hangs, even though the frontend socket recv buffer is full and the server is connected. netstat shows all parties connected with data on haproxy's doorstep. It may very well be that the client code is doing something bad, but my final hung state appears as if haproxy has stopped processing the session even though the frontend and backend are connected. Based on the traces below, it appears to me that in the failure case, the frontend fd is removed from polling, even though netstat says data is available and the server is connected. Again, sorry if our client is messing up somehow, but in that case I need to figure out what it might be doing wrong. I added some print statements to trace the polling of the file descriptors within haproxy. Only changes in the polling state are logged. The problem is intermittent, and so I expect it depends on timing of connections. But it usually fails. First the failure case, followed by a successful test. Failure Run === root@ip-172-31-31-59:~# /usr/sbin/haproxy-1.6.7a -f /etc/haproxy/haproxy.cfg [WARNING] 200/231358 (30736) : mode incompatible with , and . Keeping only. Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result FAILED Total: 3 (2 usable), will use epoll. Using epoll() as the polling mechanism. epoll_ctl: op=1, fd=4, ev=2001, eo=01, en=05 epoll_ctl: op=1, fd=5, ev=2001, eo=01, en=05 epoll_ctl: op=1, fd=7, ev=2001, eo=01, en=05 == do_poll == ... start with two successful sessions :test_og_in.accept(0007)=0008 from [10.59.159.20:47616] epoll_ctl: op=1, fd=8, ev=2001, eo=21, en=25 == do_poll == epoll_ctl: op=1, fd=9, ev=4, eo=12, en=52 == do_poll == epoll_ctl: op=2, fd=9, ev=0, eo=63, en=23 == do_poll == epoll_ctl: op=1, fd=9, ev=2001, eo=21, en=25 == do_poll == 0001:test_og_in.accept(0007)=000a from [10.59.159.20:47617] epoll_ctl: op=1, fd=10, ev=2001, eo=21, en=25 == do_poll == epoll_ctl: op=1, fd=11, ev=4, eo=12, en=52 == do_poll == epoll_ctl: op=2, fd=11, ev=0, eo=63, en=23 == do_poll == epoll_ctl: op=1, fd=11, ev=2001, eo=21, en=25 == do_poll == epoll_ctl: op=3, fd=11, ev=2005, eo=15, en=55 == do_poll == epoll_ctl: op=3, fd=9, ev=2005, eo=15, en=55 == do_poll == epoll_ctl: op=3, fd=11, ev=2001, eo=65, en=25 == do_poll == epoll_ctl: op=3, fd=9, ev=2001, eo=65, en=25 == do_poll == epoll_ctl: op=3, fd=11, ev=2005, eo=15, en=55 == do_poll == epoll_ctl: op=3, fd=9, ev=2005, eo=15, en=55 == do_poll == epoll_ctl: op=3, fd=11, ev=2001, eo=65, en=25 == do_poll == epoll_ctl: op=3, fd=9, ev=2001, eo=65, en=25 == do_poll == epoll_ctl: op=3, fd=9, ev=2005, eo=15, en=55 == do_poll == epoll_ctl: op=3, fd=9, ev=2001, eo=65, en=25 == do_poll == epoll_ctl: op=3, fd=11, ev=2005, eo=15, en=55 == do_poll == epoll_ctl: op=3, fd=11, ev=2001, eo=65, en=25 == do_poll == ... server bounced epoll_ctl: op=2, fd=11, ev=0, eo=26, en=22 == do_poll == epoll_ctl: op=2, fd=9, ev=0, eo=26, en=22 == do_poll == :test_og.srvcls[0008:0009] :test_og.clicls[0008:0009] :test_og.closed[0008:0009] 0001:test_og.srvcls[000a:000b] 0001:test_og.clicls[000a:000b] 0001:test_og.closed[000a:000b] ... client reconnects two sessions ... (note that in the failure case, ... the new sessions have sequential frontend file descriptors 0002:_test_og_in.accept(0007)=0008 from [10.59.159.20:47629] epoll_ctl: op=1, fd=8, ev=2001, eo=21, en=25 == do_poll == epoll_ctl: op=1, fd=9, ev=4, eo=12, en=52 == do_poll == 0003:test_og_in.accept(0007)=0009 from [10.59.159.20:47630] epoll_ctl: op=1, fd=9, ev=2001, eo=21, en=25 == do_poll == epoll_ctl: op=1, fd=10, ev=4, eo=12, en=52 == do_poll == epoll_ctl: op=2, fd=9, ev=0, eo=24, en=20<-- fe fd is deleted from polling and never added again == do_poll == epoll_ctl: op=2, fd=8, ev=0, eo=26, en=22 == do_poll == epoll_ctl: op=1, fd=10, ev=4, eo=12, en=52 == do_poll == epoll_ctl: op=1, fd=8, ev=2001, eo=21, en=25 == do_poll == epoll_ctl: op=3, fd=10, ev=2005, eo=51, en=55 == do_poll == epoll_ctl: op=3, fd=10, ev=2001, eo=65, en=25 == do_poll == epoll_ctl: op=1, fd=11, ev=4, eo=12, en=52 == do_poll == epoll_ctl: op=2, fd=11, ev=0, eo=63, en=23 == do_poll == epoll_ctl: op=1, fd=11, ev=2001, eo=21, en=25 == do_poll == ... The session with frontend fd=9 is hung. ... client killed (hung session remains) epoll_ctl: op=2, fd=8, ev=0, eo=26, en=22 == do_poll == 0002:test_og.srvcls[0008:000a] 0002:test_og.clicls[0008:000a] 0002:test_og.closed[0008:000a] Successful Run == root@ip-172-31-31-59:~# /usr/sbin/haproxy-1.6.7a -f /etc/haproxy/haproxy.cfg [WARNING] 200/231228 (30735) : mode incompatible with , and . Keeping only. Available polling systems : epoll : pref=300, test result OK poll : pref=200
Re: Haproxy with SNI and http2 seperation
Hi Cyril, Am 19.07.2016 um 00:27 schrieb Cyril Bonté: > You probably have an issue here : hdr(host) won't work with mode tcp. > If you wan't to check the domain provided by SNI, you should use > req.ssl_sni instead. > > Have a look to the example provided in the documentation : > http://cbonte.github.io/haproxy-dconv/1.6/configuration.html#req.ssl_sni thanks a lot! I got it working using ssl_fc_sni. As haproxy terminates the ssl connection I think it should be save to use ssl_fc_sni. Or is there I reason I should prefer req_ssl_sni instead? Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook
