[PATCH] MINOR: build: Allow linking to device-atlas library file
DeviceAtlas might be installed in a location where a user might not have enough permissions to write json.o and dac.o --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 0ce4b325305c..a10d2e4c1040 100644 --- a/Makefile +++ b/Makefile @@ -622,8 +622,12 @@ endif DEVICEATLAS_SRC = DEVICEATLAS_INC = $(DEVICEATLAS_SRC) DEVICEATLAS_LIB = $(DEVICEATLAS_SRC) +ifeq ($(DEVICEATLAS_LIB),) +OPTIONS_LDFLAGS += -lda +else OPTIONS_OBJS += $(DEVICEATLAS_LIB)/json.o OPTIONS_OBJS += $(DEVICEATLAS_LIB)/dac.o +endif OPTIONS_OBJS += src/da.o OPTIONS_CFLAGS += -DUSE_DEVICEATLAS $(if $(DEVICEATLAS_INC),-I$(DEVICEATLAS_INC)) BUILD_OPTIONS += $(call ignore_implicit,USE_DEVICEATLAS)
Lua support
I am trying to setup a lua script that can intercept redis commands. If the
user runs the AUTH command in redis, then I want to log a message on haproxy
and then make sure that command does not get passed back to redis.
Where I am getting hung up is understanding the lifecycle of the different
register commands.
It seems like when I call core.register_action, the action function does not
get called for every request. It only gets called on the initial request and
then if I am idle for a bit it might get called again. However many times I
get a strange error that says Lua function ‘hello_world’: yield not allowed. I
am not sure why that is occurring.
hello_world.lua
——
core.register_action("hello_world", { "tcp-req", "http-req" }, function(txn)
local request = txn.req:get()
txn.req:set(request)
txn:Info(request)
txn:Info("Action initiated")
end)
Haproxy.cfg
——
global
lua-load /usr/local/etc/hello_world.lua
defaults REDIS
mode tcp
timeout connect 3s
timeout server 6s
timeout client 6s
frontend ft_redis
bind *:6379 name redis
tcp-request content lua.hello_world
default_backend bk_redis
backend bk_redis
option tcp-check
tcp-check connect
tcp-check send PING\r\n
tcp-check expect string +PONG
server redis_6380 localhost:6380 check inter 1s
If instead I try to register a service using core.register_service. It appears
that I can get every request, but that the data never gets sent to the backend
redis server because I do not have access to the
channel
objects which seem tied to
TXN. It appears
like I could use the redis example from here
(http://www.arpalert.org/src/haproxy-lua-api/1.7dev/#external-lua-libraries)
but I am a little concerned with the scalability of such a solution.
hello_world.service.lua
——
core.register_service("hello_world", "tcp", function(applet)
local command = applet:getline()
core.Info("Runs on every request but does not send to backend")
core.Info(command)
end)
Haproxy.service.cnf
——
global
lua-load /usr/local/etc/hello_world.service.lua
defaults REDIS
mode tcp
timeout connect 3s
timeout server 6s
timeout client 6s
frontend ft_redis
bind *:6379 name redis
tcp-request content use-service lua.hello_world
default_backend bk_redis
backend bk_redis
option tcp-check
tcp-check connect
tcp-check send PING\r\n
tcp-check expect string +PONG
server redis_6380 localhost:6380 check inter 1s
Any assistance would be greatly appreicated.
Thanks,
Matt
Strange behavior of sample fetches in http-response replace-header option
Hi there, I observed some strange behavior when trying to use a `http-response replace-header` rule. As soon as I start using fetched samples in the replace-fmt string, the resulting header value is garbled or empty (depending on the HAProxy version). Please consider the config in the attachment of this mail (in order to preserve newlines properly). As you can see, we add a Set-Cookie header to the response in the backend which is altered again in the frontend. Specifically, the configuration intends to replace the expires tag of the cookie as set by the backend and set a new value. With this configuration, I observe the following headers when running a `curl http://127.0.0.1:8000`: HAProxy 1.5.14 and haproxy-1.5 master: Set-Cookie: WeWeWeWeWeWeWeWeWeWeWeWeWeWeWeW X-Expires: Wed, 05 Oct 2016 11:51:01 GMT haproxy-1.6 master and current haproxy master: Set-Cookie: X-Expires: Wed, 05 Oct 2016 11:51:01 GMT The `http-response replace-header` rule works fine if we replace the sample fetch with a variable like %T. In that case, the value is properly replaced. Any use of a sample fetch results in the above garbled output. The exact same behavior can be observed if a "real" backend is setting the original Set-Cookie header instead of using the listen / backend hack in the self-contained config I posted. Am I doing something wrong here or is it possible that there is an issue with applying sample fetches here? I tested with both on freshly compiles HAProxies on MacOS with `make TARGET=generic` as well as on a HAProxy 1.5.14 with the following stats: HA-Proxy version 1.5.14 2015/07/02 Copyright 2000-2015 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.8 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.2j 26 Sep 2016 Running on OpenSSL version : OpenSSL 1.0.2j 26 Sep 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 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. Thanks for your help, Holger defaults mode http timeout client 5s timeout server 5s timeout connect 5s frontend fe bind :8000 http-response add-header X-Expires %[date(3600),http_date] http-response replace-header Set-Cookie ^(.*expires=).*$ \1%[date(3600),http_date] use_backend be backend be http-response add-header Set-Cookie key=value;\ path=/;\ expires=Wed,\ 1-Jan-2020\ 23:59:59\ GMT server empty 127.0.0.1:8081 listen empty bind 127.0.0.1:8081
Re: Multiple url parameter based session limiting
On 04/10/16 18:21, Veiko Kukk wrote: Lets say, we have URL http://domain.tld?foo=abc&bar=def. I'd like to have current session limiting with sticky tables when both foo and bar values match, but I'm not sure how to achieve this (in most optimal way). I found similar post from 2013. Not exactly what I need, but similar by the means that it also requires matching several query parameters. https://www.mail-archive.com/haproxy@formilux.org/msg11680.html Are the per-request variables now awailable and how to use them? Regards, Veiko
