Re: HAProxy 2.0 "stick on src table mypeers/mytable" does not result in peers binding to socket address

2019-09-02 Thread Willy Tarreau
Hi Fred,

On Mon, Sep 02, 2019 at 02:23:19PM +0200, Frederic Lecaille wrote:
> On 8/31/19 12:20 PM, Willy Tarreau wrote:
> > Hi Bruno,
> > 
> > On Sat, Aug 31, 2019 at 12:49:15AM +, Bruno Henc wrote:
> > > Greetings,
> > > 
> > > Using "stick on src table mypeers/stickysrc" in a backend results in 
> > > HAProxy
> > > deciding not to bind to the appropriate peers address for the local host
> > > (i.e. HAProxy thinks there are no stick tables in use). However using a
> > > http-request track-sc0 line will result in haproxy listening on the peers
> > > address. Also, defining the stick table in the backend itself or in a 
> > > dummy
> > > backend also works.
> > 
> > That's interesting. I suspect that the modifications to make the
> > stick-table name resolution work recently overlooked the "stick" keyword.
> > It's possible that it used to work differently from what was done later
> > with the track-* keyword, since "stick" was the very first implementation
> > of the stick tables. We'll see this with Fred on Monday.
> 
> Willy,
> 
> You are completely true. Some initializations were missing in relation with
> "stick" keyword.
> 
> Here is a patch to fix this issue.

Now merged, thank you!
Willy



Re: HAProxy 2.0 "stick on src table mypeers/mytable" does not result in peers binding to socket address

2019-09-02 Thread Frederic Lecaille

On 8/31/19 12:20 PM, Willy Tarreau wrote:

Hi Bruno,

On Sat, Aug 31, 2019 at 12:49:15AM +, Bruno Henc wrote:

Greetings,

Using "stick on src table mypeers/stickysrc" in a backend results in HAProxy
deciding not to bind to the appropriate peers address for the local host
(i.e. HAProxy thinks there are no stick tables in use). However using a
http-request track-sc0 line will result in haproxy listening on the peers
address. Also, defining the stick table in the backend itself or in a dummy
backend also works.


That's interesting. I suspect that the modifications to make the
stick-table name resolution work recently overlooked the "stick" keyword.
It's possible that it used to work differently from what was done later
with the track-* keyword, since "stick" was the very first implementation
of the stick tables. We'll see this with Fred on Monday.


Willy,

You are completely true. Some initializations were missing in relation 
with "stick" keyword.


Here is a patch to fix this issue.

Fred.
>From f2e2968b46e7a1e98c9a52f2abb419b7650990eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 2 Sep 2019 14:02:28 +0200
Subject: [PATCH] BUG/MEDIUM: peers: local peer socket not bound.

This bug came with 015e4d7 commit: "MINOR: stick-tables: Add peers process
binding computing" where the "stick" rules cases were missing when computing
the peer local listener process binding. At parsing time we store in the
stick-table struct ->proxies_list the proxies which refer to this stick-table.
The process binding is computed after having parsed the entire configuration file
with this simple loop in cfgparse.c:

 /* compute the required process bindings for the peers from 
  * for all the stick-tables, the ones coming with "peers" sections included.
  */
 for (t = stktables_list; t; t = t->next) {
 struct proxy *p;

 for (p = t->proxies_list; p; p = p->next_stkt_ref) {
 if (t->peers.p && t->peers.p->peers_fe) {
 t->peers.p->peers_fe->bind_proc |= p->bind_proc;
 }
 }
 }

Note that if this process binding is not correctly initialized, the child forked
by the master-worker stops the peer local listener. Should be also the case
when daemonizing haproxy.

Must be backported to 2.0.
---
 src/cfgparse.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index ecf62f997..9c2ac141b 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -2726,6 +2726,10 @@ int check_config_validity()
 mrule->table.t = target;
 stktable_alloc_data_type(target, STKTABLE_DT_SERVER_ID, NULL);
 stktable_alloc_data_type(target, STKTABLE_DT_SERVER_NAME, NULL);
+if (!in_proxies_list(target->proxies_list, curproxy)) {
+	curproxy->next_stkt_ref = target->proxies_list;
+	target->proxies_list = curproxy;
+}
 			}
 		}
 
@@ -2760,6 +2764,10 @@ int check_config_validity()
 mrule->table.t = target;
 stktable_alloc_data_type(target, STKTABLE_DT_SERVER_ID, NULL);
 stktable_alloc_data_type(target, STKTABLE_DT_SERVER_NAME, NULL);
+if (!in_proxies_list(target->proxies_list, curproxy)) {
+	curproxy->next_stkt_ref = target->proxies_list;
+	target->proxies_list = curproxy;
+}
 			}
 		}
 
-- 
2.20.1



Re: HAProxy 2.0 "stick on src table mypeers/mytable" does not result in peers binding to socket address

2019-08-31 Thread Willy Tarreau
Hi Bruno,

On Sat, Aug 31, 2019 at 12:49:15AM +, Bruno Henc wrote:
> Greetings,
> 
> Using "stick on src table mypeers/stickysrc" in a backend results in HAProxy
> deciding not to bind to the appropriate peers address for the local host
> (i.e. HAProxy thinks there are no stick tables in use). However using a
> http-request track-sc0 line will result in haproxy listening on the peers
> address. Also, defining the stick table in the backend itself or in a dummy
> backend also works.

That's interesting. I suspect that the modifications to make the
stick-table name resolution work recently overlooked the "stick" keyword.
It's possible that it used to work differently from what was done later
with the track-* keyword, since "stick" was the very first implementation
of the stick tables. We'll see this with Fred on Monday.

Thanks!
Willy



HAProxy 2.0 "stick on src table mypeers/mytable" does not result in peers binding to socket address

2019-08-30 Thread Bruno Henc
Greetings,

Using "stick on src table mypeers/stickysrc" in a backend results in HAProxy 
deciding not to bind to the appropriate peers address for the local host (i.e. 
HAProxy thinks there are no stick tables in use). However using a http-request 
track-sc0 line will result in haproxy listening on the peers address. Also, 
defining the stick table in the backend itself or in a dummy backend also works.

The configuration below illustrates the issue:
peers mypeers
bind 159.65.21.107:1024
#peer hpx01 159.65.21.142:1024
#peer hpx02 159.65.21.107:1024
server hpx01 159.65.21.142:1024
server hpx02
table src_tracking type string size 10m store 
http_req_rate(10s),http_req_cnt
table stickysrc type ip size 1m expire 1h store gpc0

listen ft_main
mode http
bind *:80
stick on src table mypeers/stickysrc #peers mypeers #DOES NOT WORK
#stick-table type ip size 1m expire 1h store gpc0 peers mypeers
#stick on src #WORKS
#stick on src track_src #WORKS
#http-request track-sc0 src table mypeers/src_tracking #WORKS
#http-request track-sc0 src table mypeers/stickysrc#WORKS
server local 127.0.0.1:81 check

#backend track_src
#stick-table type ip size 1m expire 1h store gpc0 peers mypeers

Issue affects old (peers) and new (server/bind) peers section syntax. The issue 
only appears where there is only stick tables defined in the peers section - 
defining a dummy backend results in HAProxy binding to the peers socket address.

Limited testing shows that the mypeers/stickysrc isn't being populated on new 
connections either.

Issue reported by duggles on freenode.
The new syntax was introduced in 
[https://github.com/haproxy/haproxy/commit//1b8e68e89a](https://github.com/haproxy/haproxy/commit/1b8e68e89a)

Regards,

Bruno Henc