Re: How to compare two haproxy.cfg files?
On 8 March 2015 at 18:46, Tom Limoncelli tlimonce...@stackexchange.com wrote: The first step is to put the sections in a fixed order: First general, the defaults, then each listen/frontend/backend sorted by name. That works fine and has been a big help. Not a huge amount of help with your task, but don't forget that multiple default sections are valid, and take effect on the non-defaults sections following them - but only up to the /next/ defaults section. I.e. (IIRC!) with this: defaultsA backend #1 listener #2 frontend #3 defaults B listener #4 A's settings affect #1, #2 and #3, and B's settings affect #4. It would be different and quite possibly materially different if you concatenated all the defaults together at the top, and only then defined #1-#4. HTH, Jonathan
Re: Sharing configuration between multiple backends
On 9 March 2015 at 00:12, Thrawn shell_layer-git...@yahoo.com.au wrote: Hi, all. Is there a way to share configuration between multiple backends? The use case for this is that we would like to configure different response headers for different parts of our application, based on the request URL, but otherwise route traffic the same way. Specifically, we want to specify 'X-Frame-Options: ALLOW-FROM some site' across most of the application, but just use 'X-Frame-Options: DENY' on the admin area. We could do this, of course, by sending the admin traffic to a different backend, and setting the response header differently in that backend, but then we'd need to repeat our server configuration, hich is otherwise the same. Something like this: frontend foo listen x.x.x.x acl admin url_beg /admin default_backend foo use_backend foo_admin if admin backend foo rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com potentially complex configuration goes here backend foo_admin rspadd X-Frame-Options: DENY same configuration goes here To reduce the duplication, is it possible to have one backend delegate to another, or specify a named list of servers that can be referenced from different places? I don't know about your specific *question*, but to solve your specific *problem*, you might just use rspadd's conditional form: frontend foo acl admin url_beg /admin rspadd X-Frame-Options: DENY if admin rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com unless admin default_backend whatever As per https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#rspadd. Dictated but not tested ;-) Jonathan
Re: Lua patchset merged
Hi Thierry, Le 04/03/2015 21:20, Cyril Bonté a écrit : Hi Thierry, Le 04/03/2015 11:51, Thierry FOURNIER a écrit : Thank you Cyril for the bug repport. I join the patch that fix this issue. Great ! I didn't have time to investigate further. I can confirm that the patch works well ;-) I've seen new commits that have been merged on the git repository. The bad news are that the previous test that I reported (sending a response larger than the buffer) doesn't work anymore :-/ Resulting in : [ALERT] 067/220744 (27176) : Lua function 'hello_world': execution timeout. I've also seen this commit : MEDIUM: lua: use the Lua-5.3 version of the library [1] This one may be annoying in the short term for some users, because Lua 5.3 is not available in all distributions (for example debian, ubuntu, ...). Currently for such distributions, it requires to recompile Lua 5.3 with a small patch to generate the .so dynamic library. For those who want to make some tests, you can have a look at [2] and [3] and the patches they both provide. Also, we'll have to : - modify the haproxy Makefile in order to effectively detect Lua 5.3 and not 5.2 anymore (only the comment was modified) - modify the version check in src/hlua.c to trigger an error if the version number is lesser than 503. [1] http://www.haproxy.org/git?p=haproxy.git;a=commit;h=f90838b71a3c7f84e1d8b4ff85760a35d60c6910 [2] http://www.linuxfromscratch.org/blfs/view/svn/general/lua.html [3] https://aur.archlinux.org/packages/lua53/ -- Cyril Bonté
Re: Lua patchset merged
On Mon, 09 Mar 2015 22:11:56 +0100 Cyril Bonté cyril.bo...@free.fr wrote: Hi Thierry, Le 04/03/2015 21:20, Cyril Bonté a écrit : Hi Thierry, Le 04/03/2015 11:51, Thierry FOURNIER a écrit : Thank you Cyril for the bug repport. I join the patch that fix this issue. Great ! I didn't have time to investigate further. I can confirm that the patch works well ;-) I've seen new commits that have been merged on the git repository. The bad news are that the previous test that I reported (sending a response larger than the buffer) doesn't work anymore :-/ Resulting in : [ALERT] 067/220744 (27176) : Lua function 'hello_world': execution timeout. Hi cyril, This is due to the implementation of the Lua execution timeout. This is a system used to prevent loops in scripts. The Timeout is set by default to 4s. You can see tune.lua.session-timeout, tune.lua.task-timeout and tune.lua.forced-yield http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#tune.lua.session-timeout I've also seen this commit : MEDIUM: lua: use the Lua-5.3 version of the library [1] This one may be annoying in the short term for some users, because Lua 5.3 is not available in all distributions (for example debian, ubuntu, ...). Currently for such distributions, it requires to recompile Lua 5.3 with a small patch to generate the .so dynamic library. For those who want to make some tests, you can have a look at [2] and [3] and the patches they both provide. Arg, you're right :(. The Lua 5.3 is required for the session timeout. In the same way, it is necessary for the forced-yield. This system forces a yield and permits to haproxy to get the hand for processing other things than Lua. With the version 5.2, this is not possible without frequently Lua error. Maybe I can do cohabitation for 5.2 and 5.3 version. The forced yield will be deactivated with compilation 5.2. The execution timeout remain active. BUt, I'm not sure that is a good idea. Also, we'll have to : - modify the haproxy Makefile in order to effectively detect Lua 5.3 and not 5.2 anymore (only the comment was modified) - modify the version check in src/hlua.c to trigger an error if the version number is lesser than 503. You're right. The patch is writed and attached. Thank you Thierry [1] http://www.haproxy.org/git?p=haproxy.git;a=commit;h=f90838b71a3c7f84e1d8b4ff85760a35d60c6910 [2] http://www.linuxfromscratch.org/blfs/view/svn/general/lua.html [3] https://aur.archlinux.org/packages/lua53/ -- Cyril Bonté From 0d2bfc50892b1b09e3eb78ebaced9c0ed4334063 Mon Sep 17 00:00:00 2001 From: Thierry FOURNIER tfourn...@exceliance.fr Date: Tue, 10 Mar 2015 00:35:36 +0100 Subject: [PATCH] BUG/BUILD: lua: The strict Lua 5.3 version check is not done. This patch fix the Lua library check. Only the version 5.3 or later is allowed. This bug is added by the patch MEDIUM: lua: use the Lua-5.3 version of the library with commit id f90838b71a3c7f84e1d8b4ff85760a35d60c6910 --- Makefile |4 ++-- src/hlua.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 1a31792..a12e4c9 100644 --- a/Makefile +++ b/Makefile @@ -569,9 +569,9 @@ OPTIONS_CFLAGS += -DUSE_LUA $(if $(LUA_INC),-I$(LUA_INC)) LUA_LD_FLAGS := $(if $(LUA_LIB),-L$(LUA_LIB)) ifeq ($(LUA_LIB_NAME),) # Try to automatically detect the Lua library -LUA_LIB_NAME := $(firstword $(foreach lib,lua5.2 lua52 lua,$(call check_lua_lib,$(lib),$(LUA_LD_FLAGS +LUA_LIB_NAME := $(firstword $(foreach lib,lua5.3 lua53 lua,$(call check_lua_lib,$(lib),$(LUA_LD_FLAGS ifeq ($(LUA_LIB_NAME),) -$(error unable to automatically detect the Lua library name, you can enforce its name with LUA_LIB_NAME=name (where name can be lua5.2, lua52, lua, ...)) +$(error unable to automatically detect the Lua library name, you can enforce its name with LUA_LIB_NAME=name (where name can be lua5.3, lua53, lua, ...)) endif endif diff --git a/src/hlua.c b/src/hlua.c index 564f5ba..fb39dc1 100644 --- a/src/hlua.c +++ b/src/hlua.c @@ -4,8 +4,8 @@ #include lua.h #include lualib.h -#if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM 502 -#error Requires Lua 5.2 or later. +#if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM 503 +#error Requires Lua 5.3 or later. #endif #include ebpttree.h -- 1.7.10.4
[SPAM] Hello haproxy
Hello) My name is Olga. Ilive in Moscow. I found out your page onthe Internet and I was curious about you. Tell me, please, what are you doing now and how do you spend your life ingeneral? In fact, you're interesting to me as a personality, and Iwant to communicate with you http://tuzlaelektrik.com/backup.html in the future.
Re: Lua patchset merged
Hi again, Le 10/03/2015 00:40, Thierry FOURNIER a écrit : On Mon, 09 Mar 2015 22:11:56 +0100 Cyril Bonté cyril.bo...@free.fr wrote: I've seen new commits that have been merged on the git repository. The bad news are that the previous test that I reported (sending a response larger than the buffer) doesn't work anymore :-/ Resulting in : [ALERT] 067/220744 (27176) : Lua function 'hello_world': execution timeout. Hi cyril, This is due to the implementation of the Lua execution timeout. This is a system used to prevent loops in scripts. The Timeout is set by default to 4s. You can see tune.lua.session-timeout, tune.lua.task-timeout and tune.lua.forced-yield http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#tune.lua.session-timeout Of course, but it shouldn't take 4 seconds, the answer is immediate in my test case. Actually, I could find that it was reproducible beginning with a response greater or equal to 16392 bytes (I've not read the code yet). haproxy.cfg: global lua-load hello_world.lua listen proxy bind 127.0.0.1:10001 tcp-request content lua hello_world hello_world.lua: function hello_world(txn) local res = txn:res_channel() s = for i = 1,16392 do s = s .. x end res:send(s) end -- Cyril Bonté
Re: Sharing configuration between multiple backends
Hi, Jonathan. Thanks for your reply. Unfortunately we can't use a request ACL to perform actions on a response, as per http://marc.info/?l=haproxym=138384425604641w=1 (and our own experience confirms it). The request object is not available any more when the response is being altered. Willy's suggested approach was to use a request ACL to send traffic to a different backend, which can then apply the response action. So, in the case where that backend is almost a duplicate of the first, is there (or should there be) some way to reduce the duplication? Regards Thrawn On 2015-03-09 14:27:09, Jonathan Matthews wrote: I don't know about your specific *question*, but to solve your specific *problem*, you might just use rspadd's conditional form: frontend foo acl admin url_beg /admin rspadd X-Frame-Options: DENY if admin rspadd X-Frame-Options: ALLOW-FROM some-trusted-server.com unless admin default_backend whatever As per https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#rspadd= . Dictated but not tested ;-) Jonathan
Re: aluminum sheetcoilrelated products, superior quality, good price!
Dear director, This is Mr.Jack, general manager of WANXINYUAN ALUMINUM INDUSTRY CO.,LIMITED from Shenzhen city, China. We are a professional manufacturer of Aluminum sheet/plate and coil/roll and have been exporting our products to overseas markets in the past 10years. We know you are searching for large quantity of aluminum sheets and coils in your market for long term. So how to reduce your cost and earn more profit will be a key problem of your side. Wanxinyuans aluminum sheets+coils will makes your own products price more competitive in your market. Waiting for your email for further discussion. Best regards! Mr.Jack (General Manager) SHENZHEN WANXINYUAN ALUMINUM INDUSTRY CO.,LTD http://wanxinyuanaluminum.en.made-in-china.com/ E-mailjack.al@gdwa nxin.com Mobile: 0086-18502085515 Fax:0086-0755-23033800 Skype: jackwxy88
Re: Lua patchset merged
On Tue, 10 Mar 2015 01:05:50 +0100 Cyril Bonté cyril.bo...@free.fr wrote: Hi again, Le 10/03/2015 00:40, Thierry FOURNIER a écrit : On Mon, 09 Mar 2015 22:11:56 +0100 Cyril Bonté cyril.bo...@free.fr wrote: I've seen new commits that have been merged on the git repository. The bad news are that the previous test that I reported (sending a response larger than the buffer) doesn't work anymore :-/ Resulting in : [ALERT] 067/220744 (27176) : Lua function 'hello_world': execution timeout. Hi cyril, This is due to the implementation of the Lua execution timeout. This is a system used to prevent loops in scripts. The Timeout is set by default to 4s. You can see tune.lua.session-timeout, tune.lua.task-timeout and tune.lua.forced-yield http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#tune.lua.session-timeout Of course, but it shouldn't take 4 seconds, the answer is immediate in my test case. Actually, I could find that it was reproducible beginning with a response greater or equal to 16392 bytes (I've not read the code yet). Thank you Cyril, the bug is partially reproduced and fixed (the buffer is not sent, but the error timeout is after 4 seconds as expected). I attach the patch. I think that Willy must check this patch, because it is possible than the comparison which I modify, did make sense. Thierry haproxy.cfg: global lua-load hello_world.lua listen proxy bind 127.0.0.1:10001 tcp-request content lua hello_world hello_world.lua: function hello_world(txn) local res = txn:res_channel() s = for i = 1,16392 do s = s .. x end res:send(s) end -- Cyril Bonté From f0185cae264f0309e386b500be115051a30e120b Mon Sep 17 00:00:00 2001 From: Thierry FOURNIER tfourn...@exceliance.fr Date: Tue, 10 Mar 2015 01:55:01 +0100 Subject: [PATCH] BUG/MEDIUM: buffer: one byte miss in buffer free space check Space is not avalaible only if the end of the data inserted is strictly greater than the end of buffer. If these two value are equal, the space is avamaible. --- src/buffer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/buffer.c b/src/buffer.c index e156991..3c7f6cc 100644 --- a/src/buffer.c +++ b/src/buffer.c @@ -75,7 +75,7 @@ int buffer_replace2(struct buffer *b, char *pos, char *end, const char *str, int delta = len - (end - pos); - if (bi_end(b) + delta = b-data + b-size) + if (bi_end(b) + delta b-data + b-size) return 0; /* no space left */ if (buffer_not_empty(b) -- 1.7.10.4