Re: How to compare two haproxy.cfg files?

2015-03-09 Thread Jonathan Matthews
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

2015-03-09 Thread Jonathan Matthews
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

2015-03-09 Thread Cyril Bonté

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

2015-03-09 Thread Thierry FOURNIER
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

2015-03-09 Thread Concetta
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

2015-03-09 Thread Cyril Bonté

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

2015-03-09 Thread Thrawn

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!

2015-03-09 Thread Mr.Jack

  
  
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

2015-03-09 Thread Thierry FOURNIER
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