Heimtextil Frankfurt

[sales-1]

Dear Sirs/Madam: We hereby sincerely invite you and your company representatives to visit our booth at The Exhibition Centre Frankfurt from Jan 9th to 12th 2018 for textile.We provide throw blanket,cushion,baby products and knit toys.We are factory and we have an advantage in price.We through the BSCI and Oeke-Tex100 certification. It would be a great pleasure to meet you at the exhibition.We expect to establish long-term business relations with your company in future.  Exhibition center：Exhibition Centre FrankfurtBooth number：6.3D60DDate：Jan 9th to 12th 2018Sincerely Yours, Nina /JanyChangshu Winning Knitting Textile Co.Ltd.E-mail：sale...@jswntex.comTel ：+86-0512-52830161   Mobile：15370159252Address：Room809,Zhongkai International Building 58th Haiyu North Rode,Changshu City,jiangsu Provence,China
点击这里取消订阅click to unsubscribe

Re: Haproxy 1.8 version help

[Lukas Tribus]

Hi Angelo,


On Thu, Jan 4, 2018 at 11:11 PM, Angelo Hongens  wrote:
> On 03-01-2018 17:39, Lukas Tribus wrote:
>>
>> To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
>> CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
>> You can disable thread support, by adding USE_THREAD= to the make
>> command (nothing comes after the equal sign):
>
>
> I'm no packaging expert, but 1.8 seems to build fine on my CentOS6 build box
> without any errors.
>
> I'm running gcc version 4.4.7 20120313 on CentOS 6.9.
>
> Here's my spec file for building RPM packages:
>
> https://github.com/AxisNL/haproxy-rpmbuild/blob/master/SPECS/haproxy-1.8.3.el6.spec
>
> Am I doing something strange?? :-)

Your are using the older build TARGET=linux26, which is for kernels
older than 2.6.28. It doesn't enable newer features for example thread
support (which would cause the build issue).
For kernels >= 2.6.28 (which CentOs 6 is) we have the linux2628 build target.

Willy is working on thread support for the older kernel though, so the
build issue will be fixed soon.


cheers,
lukas

Re: Haproxy 1.8 version help

[Angelo Hongens]

On 03-01-2018 17:39, Lukas Tribus wrote:

To compile Haproxy 1.8 with threads, at least GCC 4.7 is needed.
CentOs 6 only ships GCC 4.4.7, therefor compilation fails.
You can disable thread support, by adding USE_THREAD= to the make
command (nothing comes after the equal sign):


I'm no packaging expert, but 1.8 seems to build fine on my CentOS6 build 
box without any errors.


I'm running gcc version 4.4.7 20120313 on CentOS 6.9.

Here's my spec file for building RPM packages:

https://github.com/AxisNL/haproxy-rpmbuild/blob/master/SPECS/haproxy-1.8.3.el6.spec

Am I doing something strange?? :-)


--

met vriendelijke groet,

Angelo Höngens

Re: HAProxy 1.8.3 SSL caching regression

[Jeffrey J. Persch]

Hi William,

Verified.

Thanks for the quick fix,
Jeffrey J. Persch


On Wed, Jan 3, 2018 at 2:02 PM, Jeffrey J. Persch 
wrote:

> Hi William,
>
> The test case now works. I will do load testing with the patch today.
>
> Thanks,
> Jeffrey J. Persch
>
> On Wed, Jan 3, 2018 at 1:25 PM, William Lallemand 
> wrote:
>
>> On Wed, Jan 03, 2018 at 06:41:01PM +0100, William Lallemand wrote:
>> > I'm able to reproduce the problem thanks to your detailed example, it
>> looks
>> > like a regression in the code.
>> >
>> > I will check the code to see what's going on.
>>
>> I found the issue, would you mind trying the attached patch?
>>
>> Thanks.
>>
>> --
>> William Lallemand
>>
>
>

Re: Haproxy 1.8 version help

[Willy Tarreau]

Hi Devendra,

Here's a patch that I tested a little bit and apparently work for me.
Fell free to test it as well on your machine and to report here. It
fixes the build issue and allows you to run with threads.

Cheers,
Willy
>From c27bba26e5bcd772aa8b1c9a1319a2919df13f34 Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Thu, 4 Jan 2018 18:49:31 +0100
Subject: MINOR: hathreads: add support for gcc < 4.7

Till now the use of __atomic_* gcc builtins required gcc >= 4.7. Since
some supported and quite common operating systems like CentOS 6 still
come with older versions (4.4) and the mapping to the older builtins
is reasonably simple, let's implement it.

This code is only used for gcc < 4.7. It has been quickly tested on a
machine using gcc 4.4.4 and provided expected results.

This patch should be backported to 1.8.
---
 include/common/hathreads.h | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/include/common/hathreads.h b/include/common/hathreads.h
index 9782ca9..503abbe 100644
--- a/include/common/hathreads.h
+++ b/include/common/hathreads.h
@@ -99,6 +99,58 @@ extern THREAD_LOCAL unsigned long tid_bit; /* The bit 
corresponding to the threa
 
 /* TODO: thread: For now, we rely on GCC builtins but it could be a good idea 
to
  * have a header file regrouping all functions dealing with threads. */
+
+#if defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 7)
+/* gcc < 4.7 */
+
+#define HA_ATOMIC_ADD(val, i)__sync_add_and_fetch(val, i)
+#define HA_ATOMIC_SUB(val, i)__sync_sub_and_fetch(val, i)
+#define HA_ATOMIC_AND(val, flags)__sync_and_and_fetch(val, flags)
+#define HA_ATOMIC_OR(val, flags) __sync_or_and_fetch(val,  flags)
+
+/* the CAS is a bit complicated. The older API doesn't support returning the
+ * value and the swap's result at the same time. So here we take what looks
+ * like the safest route, consisting in using the boolean version guaranteeing
+ * that the operation was performed or not, and we snoop a previous value. If
+ * the compare succeeds, we return. If it fails, we return the previous value,
+ * but only if it differs from the expected one. If it's the same it's a race
+ * thus we try again to avoid confusing a possibly sensitive caller.
+ */
+#define HA_ATOMIC_CAS(val, old, new)  \
+   ({ \
+   typeof((val)) __val = (val);   \
+   typeof((old)) __oldp = (old);  \
+   typeof(*(old)) __oldv; \
+   typeof((new)) __new = (new);   \
+   int __ret; \
+   do {   \
+   __oldv = *__val;   \
+   __ret = __sync_bool_compare_and_swap(__val, *__oldp, 
__new); \
+   } while (!__ret && *__oldp == __oldv); \
+   if (!__ret)\
+   *__oldp = __oldv;  \
+   __ret; \
+   })
+
+#define HA_ATOMIC_XCHG(val, new)  \
+   ({ \
+   typeof((val)) __val = (val);   \
+   typeof(*(val)) __old;  \
+   typeof((new)) __new = (new);   \
+   do { __old = *__val;   \
+   } while (!__sync_bool_compare_and_swap(__val, __old, __new));  \
+   __old; \
+   })
+#define HA_ATOMIC_STORE(val, new)   \
+   ({ \
+   typeof((val)) __val = (val);   \
+   typeof(*(val)) __old;  \
+   typeof((new)) __new = (new);   \
+   do { __old = *__val;   \
+   } while (!__sync_bool_compare_and_swap(__val, __old, __new));  \
+   })
+#else
+/* gcc >= 4.7 */
 #define HA_ATOMIC_CAS(val, old, new) __atomic_compare_exchange_n(val, old, 
new, 0, 0, 0)
 #define HA_ATOMIC_ADD(val, i)__atomic_add_fetch(val, i, 0)
 #define HA_ATOMIC_SUB(val, i)__atomic_sub_fetch(val, i, 0)
@@ -106,6 +158,8 @@ extern THREAD_LOCAL 

[PATCH 1/2] BUG/MINOR: lua: Fix default value for pattern in Socket.receive

[Tim Duesterhus]

The default value of the pattern in `Socket.receive` is `*l` according
to the documentation and in the `socket.tcp.receive` method of Lua.

The default value of `wanted` in `int hlua_socket_receive(struct lua_State *)`
reflects this requirement, but the function fails to ensure this
nonetheless:

If no parameter is given the top of the Lua stack will have the index 1.
`lua_pushinteger(L, wanted);` then pushes the default value onto the stack
(with index 2).
The following `lua_replace(L, 2);` then pops the top index (2) and tries to
replace the index 2 with it.
I am not sure why exactly that happens (possibly, because one cannot replace
non-existent stack indicies), but this causes the stack index to be lost.

`hlua_socket_receive_yield` then tries to read the stack index 2, to
determine what to read and get the value `0`, instead of the correct
HLSR_READ_LINE, thus taking the wrong branch.

Fix this by ensuring that the top of the stack is not replaced by itself.

This bug was introduced in commit 7e7ac32dad1e15c19152d37aaf9ea6b3f00a7226
(which is the very first commit adding the Socket class to Lua). This
bugfix should be backported to every branch containing that commit:
- 1.6
- 1.7
- 1.8

A test case for this bug is as follows:

The 'Test' response header will contain an HTTP status line with the
patch applied and will be empty without the patch applied. Replacing
the `sock:receive()` with `sock:receive("*l")` will cause the status
line to appear with and without the patch

http.lua:
  core.register_action("bug", { "http-req" }, function(txn)
local sock = core.tcp()
sock:settimeout(60)
sock:connect("127.0.0.1:80")
sock:send("GET / HTTP/1.0\r\n\r\n")
response = sock:receive()
sock:close()
txn:set_var("txn.foo", response)
  end)

haproxy.cfg (bits omitted for brevity):
  global
lua-load /scratch/haproxy/http.lua

  frontend fe
bind 127.0.0.1:8080
http-request lua.bug
http-response set-header Test %[var(txn.foo)]

default_backend be

  backend be
server s 127.0.0.1:80
---
 src/hlua.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/hlua.c b/src/hlua.c
index abd096d03..285d25589 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -1869,7 +1869,10 @@ __LJMP static int hlua_socket_receive(struct lua_State 
*L)
 
/* Set pattern. */
lua_pushinteger(L, wanted);
-   lua_replace(L, 2);
+
+   /* Check if we would replace the top by itself. */
+   if (lua_gettop(L) != 2)
+   lua_replace(L, 2);
 
/* init bufffer, and fiil it wih prefix. */
luaL_buffinit(L, >b);
-- 
2.15.1

[PATCH 2/2] DOC: lua: Fix typos in comments of hlua_socket_receive

[Tim Duesterhus]

---
 src/hlua.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/hlua.c b/src/hlua.c
index 285d25589..3b4fc3b54 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -1810,19 +1810,19 @@ connection_empty:
return 0;
 }
 
-/* This Lus function gets two parameters. The first one can be string
- * or a number. If the string is "*l", the user require one line. If
- * the string is "*a", the user require all the content of the stream.
+/* This Lua function gets two parameters. The first one can be string
+ * or a number. If the string is "*l", the user requires one line. If
+ * the string is "*a", the user requires all the contents of the stream.
  * If the value is a number, the user require a number of bytes equal
  * to the value. The default value is "*l" (a line).
  *
- * This paraeter with a variable type is converted in integer. This
+ * This parameter with a variable type is converted in integer. This
  * integer takes this values:
  *  -1 : read a line
  *  -2 : read all the stream
- *  >0 : amount if bytes.
+ *  >0 : amount of bytes.
  *
- * The second parameter is optinal. It contains a string that must be
+ * The second parameter is optional. It contains a string that must be
  * concatenated with the read data.
  */
 __LJMP static int hlua_socket_receive(struct lua_State *L)
@@ -1874,7 +1874,7 @@ __LJMP static int hlua_socket_receive(struct lua_State *L)
if (lua_gettop(L) != 2)
lua_replace(L, 2);
 
-   /* init bufffer, and fiil it wih prefix. */
+   /* init buffer, and fill it with prefix. */
luaL_buffinit(L, >b);
 
/* Check prefix. */
-- 
2.15.1

[PATCH] Remove rbtree.[ch]

[Olivier Houchard]

Hi guys,

The rbtree implementation as found in haproxy, is currently unused, and has
been for quite some time.
I don't think we will need it again, so the attached patch just removes it.

Regards,

Olivier
>From 4ce3bce732fd816a835e4896646f260f0b7e6e7c Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Thu, 4 Jan 2018 17:59:02 +0100
Subject: [PATCH] MINOR/CLEANUP: rbtree: remove

Remove the rbtree implementation. It's not used, it's not even connected to
the build, and we probably have no use for it .
---
 include/common/rbtree.h | 150 --
 src/rbtree.c| 399 
 2 files changed, 549 deletions(-)
 delete mode 100644 include/common/rbtree.h
 delete mode 100644 src/rbtree.c

diff --git a/include/common/rbtree.h b/include/common/rbtree.h
deleted file mode 100644
index 107e8d237..0
--- a/include/common/rbtree.h
+++ /dev/null
@@ -1,150 +0,0 @@
-/*
-  Red Black Trees
-  (C) 1999  Andrea Arcangeli 
-
-  This program is free software; you can redistribute it and/or modify
-  it under the terms of the GNU General Public License as published by
-  the Free Software Foundation; either version 2 of the License, or
-  (at your option) any later version.
-
-  This program is distributed in the hope that it will be useful,
-  but WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-  GNU General Public License for more details.
-
-  You should have received a copy of the GNU General Public License
-  along with this program; if not, write to the Free Software
-  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-
-  linux/include/linux/rbtree.h
-
-  To use rbtrees you'll have to implement your own insert and search cores.
-  This will avoid us to use callbacks and to drop drammatically performances.
-  I know it's not the cleaner way,  but in C (not in C++) to get
-  performances and genericity...
-
-  Some example of insert and search follows here. The search is a plain
-  normal search over an ordered tree. The insert instead must be implemented
-  int two steps: as first thing the code must insert the element in
-  order as a red leaf in the tree, then the support library function
-  rb_insert_color() must be called. Such function will do the
-  not trivial work to rebalance the rbtree if necessary.
-

-static inline struct page * rb_search_page_cache(struct inode * inode,
-unsigned long offset)
-{
-   struct rb_node * n = inode->i_rb_page_cache.rb_node;
-   struct page * page;
-
-   while (n)
-   {
-   page = rb_entry(n, struct page, rb_page_cache);
-
-   if (offset < page->offset)
-   n = n->rb_left;
-   else if (offset > page->offset)
-   n = n->rb_right;
-   else
-   return page;
-   }
-   return NULL;
-}
-
-static inline struct page * __rb_insert_page_cache(struct inode * inode,
-  unsigned long offset,
-  struct rb_node * node)
-{
-   struct rb_node ** p = >i_rb_page_cache.rb_node;
-   struct rb_node * parent = NULL;
-   struct page * page;
-
-   while (*p)
-   {
-   parent = *p;
-   page = rb_entry(parent, struct page, rb_page_cache);
-
-   if (offset < page->offset)
-   p = &(*p)->rb_left;
-   else if (offset > page->offset)
-   p = &(*p)->rb_right;
-   else
-   return page;
-   }
-
-   rb_link_node(node, parent, p);
-
-   return NULL;
-}
-
-static inline struct page * rb_insert_page_cache(struct inode * inode,
-unsigned long offset,
-struct rb_node * node)
-{
-   struct page * ret;
-   if ((ret = __rb_insert_page_cache(inode, offset, node)))
-   goto out;
-   rb_insert_color(node, >i_rb_page_cache);
- out:
-   return ret;
-}

-*/
-
-#ifndef_LINUX_RBTREE_H
-#define_LINUX_RBTREE_H
-
-/*
-#include 
-#include 
-*/
-
-struct rb_node
-{
-   struct rb_node *rb_parent;
-   int rb_color;
-#defineRB_RED  0
-#defineRB_BLACK1
-   struct rb_node *rb_right;
-   struct rb_node *rb_left;
-};
-
-struct rb_root
-{
-   struct rb_node *rb_node;
-};
-
-// Copy from linux kernel 2.6 source (kernel.h, stddef.h)
-#define container_of(ptr, type, member) ({  \
-   const typeof( ((type *)0)->member ) *__mptr = (ptr);  \
-   (type *)( (char *)__mptr - 

Re: 1.8.3: Slow posts on H2 (IE only?)

[Willy Tarreau]

On Thu, Jan 04, 2018 at 04:03:29PM +0100, Peter Lindegaard Hansen wrote:
> Hi Willy & Lukas,
> 
> I did on a test VM using the latest git version
> # haproxy -v
> HA-Proxy version 1.8.3-646d23-1 2018/01/04
> Copyright 2000-2017 Willy Tarreau 
> 
> And can confirm that the issues related to post+redirects are fixed for us.
> 
> And the other issue that we found seems to be resolved too.
> 
> Perfect, thanks much! :)

Oh that's great. Thanks for testing!

Willy

Re: [PATCH] BUILD/SMALL Fixed build on macOS with lua

[Thierry Fournier]

> On 4 Jan 2018, at 15:16, Kirill A. Korinsky  wrote:
> 
> Honestly, I didn't.
> 
> If I right understand how export-dynamic works and how haproxy use integrated 
> LUA, it shouldn't have any impact.
> 
> Honestly I see only one case when export-dynamic requests: when some 
> application load haproxy over dlopen, and use some function from haproxy 
> binary object.
> 
> I expect that it isn't true, is it?



Hi Kirill,

This option is usefull for load Lua extensions as .so files. Something
like the openSSL Lua bindings is provided as .so Lua module. These kind
of modules requires some Lua symbol which are not used by HAProxy, so
without the option “ --export-dynamic” the load of these libraries fail
with a message explaining that some symbols are missing.

Note: I’m not specialised in the compilation options, and maybe something
following is wrong.

The flag --export-dynamic force all the symbols (of the Lua library) to
be exported in the ELF binary. I guess that this option force the linker
to embed also the unused symbols from the Lua library.

The man on my mac compiler shows the option “-export_dynamic” (with
underscore in place of dash). Maybe a solution is to detect the platform
and set the right option.

br,
Thierry

> 
> -- 
> wbr, Kirill
> 
> 
>> On 4 Jan 2018, at 01:10, Willy Tarreau  wrote:
>> 
>> Hi Kirill,
>> 
>> On Thu, Dec 28, 2017 at 04:13:38AM +0400, Kirill A. Korinsky wrote:
>>> Last macOS hasn't support export-dynamic, just remove it
>>> ---
>>> Makefile | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/Makefile b/Makefile
>>> index 2acf5028..19234897 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -630,7 +630,7 @@ check_lua_inc = $(shell if [ -d $(2)$(1) ]; then echo 
>>> $(2)$(1); fi;)
>>> 
>>> BUILD_OPTIONS   += $(call ignore_implicit,USE_LUA)
>>> OPTIONS_CFLAGS  += -DUSE_LUA $(if $(LUA_INC),-I$(LUA_INC))
>>> -LUA_LD_FLAGS := -Wl,--export-dynamic $(if $(LUA_LIB),-L$(LUA_LIB))
>>> +LUA_LD_FLAGS := $(if $(LUA_LIB),-L$(LUA_LIB))
>> 
>> Hmmm how can you be sure you didn't break anything else ? I'm pretty
>> sure that there was a reason for adding this --export-dynamic, maybe
>> certain things will still not work on your platform, or others won't
>> work at all. We need to run some checks before taking this one.
>> 
>> I'm CCing Thierry in case he reminds why we need this.
>> 
>> Regards,
>> Willy
> 

Re: 1.8.3: Slow posts on H2 (IE only?)

[Peter Lindegaard Hansen]

Hi Willy & Lukas,

I did on a test VM using the latest git version
# haproxy -v
HA-Proxy version 1.8.3-646d23-1 2018/01/04
Copyright 2000-2017 Willy Tarreau 

And can confirm that the issues related to post+redirects are fixed for us.

And the other issue that we found seems to be resolved too.

Perfect, thanks much! :)



Med venlig hilsen


*Peter Lindegaard Hansen*

*Softwareudvikler / Partner*

Telefon: +45 96 500 300 | Direkte: 69 14 97 04 | Email: p...@tigermedia.dk
Tiger Media A/S | Gl. Gugvej 17C | 9000 Aalborg | Web: www.tigermedia.dk

For supportspørgsmål kontakt os da på supp...@tigermedia.dk eller på tlf.
96 500 300
og din henvendelse vil blive besvaret af første ledige medarbejder.

2018-01-04 14:52 GMT+01:00 Willy Tarreau :

> Hi Peter,
>
> On Wed, Jan 03, 2018 at 11:04:03PM +0100, Peter Lindegaard Hansen wrote:
> > I will try to apply the patch (i am no expert at this) and see the
> results.
>
> Well, don't waste your time trying to figure stuff you're not comfortable
> with. I've just committed the fix and backported it. If you're familiar
> with git, pulling the latest version will give you the fixed code.
> Otherwise
> just wait for tomorrow morning, the next nightly snapshot will
> automatically
> contain the fix.
>
> > I did find another h2-related issue, but where unable to pinpoint exactly
> > why as it where deep in ajax application, but i will see with this patch
> if
> > its the same issue.
>
> OK, let's wait for new tests with the patch first, and otherwise once
> you have more info, do not hesitate to open another report.
>
> Thanks!
> Willy
>

Re: [PATCH] BUILD/SMALL Fixed build on macOS with lua

[Kirill A. Korinsky]

Honestly, I didn't.

If I right understand how export-dynamic works and how haproxy use integrated 
LUA, it shouldn't have any impact.

Honestly I see only one case when export-dynamic requests: when some 
application load haproxy over dlopen, and use some function from haproxy binary 
object.

I expect that it isn't true, is it?

-- 
wbr, Kirill


> On 4 Jan 2018, at 01:10, Willy Tarreau  wrote:
> 
> Hi Kirill,
> 
> On Thu, Dec 28, 2017 at 04:13:38AM +0400, Kirill A. Korinsky wrote:
>> Last macOS hasn't support export-dynamic, just remove it
>> ---
>> Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/Makefile b/Makefile
>> index 2acf5028..19234897 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -630,7 +630,7 @@ check_lua_inc = $(shell if [ -d $(2)$(1) ]; then echo 
>> $(2)$(1); fi;)
>> 
>> BUILD_OPTIONS   += $(call ignore_implicit,USE_LUA)
>> OPTIONS_CFLAGS  += -DUSE_LUA $(if $(LUA_INC),-I$(LUA_INC))
>> -LUA_LD_FLAGS := -Wl,--export-dynamic $(if $(LUA_LIB),-L$(LUA_LIB))
>> +LUA_LD_FLAGS := $(if $(LUA_LIB),-L$(LUA_LIB))
> 
> Hmmm how can you be sure you didn't break anything else ? I'm pretty
> sure that there was a reason for adding this --export-dynamic, maybe
> certain things will still not work on your platform, or others won't
> work at all. We need to run some checks before taking this one.
> 
> I'm CCing Thierry in case he reminds why we need this.
> 
> Regards,
> Willy

Re: 1.8.3: Slow posts on H2 (IE only?)

[Willy Tarreau]

Hi Peter,

On Wed, Jan 03, 2018 at 11:04:03PM +0100, Peter Lindegaard Hansen wrote:
> I will try to apply the patch (i am no expert at this) and see the results.

Well, don't waste your time trying to figure stuff you're not comfortable
with. I've just committed the fix and backported it. If you're familiar
with git, pulling the latest version will give you the fixed code. Otherwise
just wait for tomorrow morning, the next nightly snapshot will automatically
contain the fix.

> I did find another h2-related issue, but where unable to pinpoint exactly
> why as it where deep in ajax application, but i will see with this patch if
> its the same issue.

OK, let's wait for new tests with the patch first, and otherwise once
you have more info, do not hesitate to open another report.

Thanks!
Willy

Re: Bug or misconfig on path_reg?

[Arnaud B.]

so it appears that OR is implicit and foo was matched as 3 acl :-)

Thank's meineerde for the help


Le 04/01/2018 à 11:45, Arnaud B. a écrit :
> Hi there,
>
> Recently, a misrouting has been found on our haproxy config. We had two
> ACL mismatching :
>
> acl foo   path_reg -i
> ^/(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$ OR path_reg -i
> ^//(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$
>
> and
>
> acl bar    path_reg
> ^/(w|a|i)\/(.*)\/barbaz\/(.*)\/(install|custom)\/(.*)
>
>
> So, if the called url is
> https://foo.bar/i/1.9.0/barbaz/path/custom/foo
>
> acl bar is matched and this is "normal", now, if I hit
> https://foo.bar/i/1.9.0/barbaz/path/custom/-i
>
> it matches bar, even if the latter part of the regex is not matching. We
> tried with https://foo.bar/i/1.9.0/barbaz/path/custom/-a and a set of
> different chars, this anomaly is only raised when hitting /-i
>
> our config has been fixed by removing the -i flag on the foo acl, but it
> doesn't explain this "bug".
>
>

Bug or misconfig on path_reg?

[Arnaud B.]

Hi there,

Recently, a misrouting has been found on our haproxy config. We had two
ACL mismatching :

acl foo   path_reg -i
^/(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$ OR path_reg -i
^//(w|a|i)\/([0-9]+\.){0,3}([0-9]+)?\/(ats|atc)\/.*$

and

acl bar    path_reg
^/(w|a|i)\/(.*)\/barbaz\/(.*)\/(install|custom)\/(.*)


So, if the called url is
https://foo.bar/i/1.9.0/barbaz/path/custom/foo

acl bar is matched and this is "normal", now, if I hit
https://foo.bar/i/1.9.0/barbaz/path/custom/-i

it matches bar, even if the latter part of the regex is not matching. We
tried with https://foo.bar/i/1.9.0/barbaz/path/custom/-a and a set of
different chars, this anomaly is only raised when hitting /-i

our config has been fixed by removing the -i flag on the foo acl, but it
doesn't explain this "bug".

Re: Quick question on HA Proxy cluster management

[Marco Corte]

We use ansible without any GUI.

On the managed nodes just ssh access is needed, no agent.

This let us manage 16 haproxy 2-node-clusters (32 nodes in total) 
running on two diferent linux flavors; some of the clusters have a 
similar configuration, some others are completely different.
In our experience any configuration change (not only for haproxy, but 
also for other) can be deployed in a few seconds on one, few, many or 
all nodes, even over slow satellite links.


All configurations are versioned with Git.

.marcoc

Re: Quick question on HA Proxy cluster management

[Michael Schwartzkopff]

Am 03.01.2018 um 23:39 schrieb Muthukumar Srinivasan - Consultant:
> Dear Sir
>
> I am looking for HA Proxy cluster management open source. we have over 100
> HA Proxy instances used for Load balancing, SSL termination etc. we need to
> manage all of them in one unified place.
>
>
> let me know if you have any products
>
> thank you
>
Any config management system like puppet, salt or ansible.


Configs in git.


Orchestration GUI i.e. with "the foreman".


Mit freundlichen Grüßen,

-- 

[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein




signature.asc
Description: OpenPGP digital signature

Redispatching of connections

[Walecki, Jakub (Nokia - PL/Wroclaw)]

Hi,

If the connection is redispatched, does it go to queue and wait to be served, 
or is it prioritized and connected to first free slot?

Best regards,
Jakub Walecki