date:20150324

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "Jarno Huuskonen"  
To: "Klavs Klavsen"  
Cc: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 9:23:04 AM 
Subject: Re: limiting conn-curs per-ip using x-forwarded-for 

Hi, 

On Tue, Mar 24, Klavs Klavsen wrote: 
> #create a stick-table of 30 IPs for storing active IPs, 5 minute timeout 
> stick-table type ip size 30 expire 5m store gpc0 
> #populate the table with the X-Forwarded-For header 
> stick store-request hdr(X-Forwarded-For) 

You've created type ip stick table, but I think hdr(X-Forwarded-For) 
returns a string. Do you see any entries in the stick table: 
show table nocache -> to stats socket 

Maybe it's possible to use one of the converters 
to map str -> ip 
(http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.1-map) 

or try with a string stick table: 
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-stick-table 

-Jarno 

-- 
Jarno Huuskonen

Re: How can i get haproxy reload its configuration

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "jeff saremi"  
To: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 8:52:20 AM 
Subject: RE: How can i get haproxy reload its configuration 


> Subject: Re: How can i get haproxy reload its configuration > From: Vincent 
> Bernat > Date: 2015-03-24 12:07:34 > Message-ID: 87619q61kp.fsf () zoro ! 
> exoscale ! ch > â�¦ 24 mars 2015 07:45 -0400, jeff saremi Â : > > #!/bin/sh > 
> > pidfile=/data/haproxy.pidhaproxy -db \ > > -f /haproxy-1.5.8/haproxy.cfg -p 
> $pidfile \ > > -sf $(cat $pidfile) > The shell does variable substitution 
> first, then execute the > line. Hence, $pidfile is expanded to "", not to 
> "/data/haproxy.pid". Put > pidfile=... on its own line. > -- > I'll burn my 
> books. > -- Christopher Marlowe Sorry that was just how my email got through. 
> Those are separate lines. So here it is again: #!/bin/sh 
> pidfile=/data/haproxy.pid haproxy -db \ -f /haproxy-1.5.8/haproxy.cfg -p 
> $pidfile \ -sf $(cat $pidfile) What i'm wondering is how this could have ever 
> worked? since the "$(cat $pidfile) and the creation of the $pidfile are both 
> on the same line. Is it possible that when the pidfile is concatenated for 
> the sake of "-sf" the file does not exist or contains old pids?

Re: timeout values for redis?

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "Jim Gronowski"  
To: "haproxy@formilux.org"  
Sent: Tuesday, March 24, 2015 1:25:33 PM 
Subject: timeout values for redis? 

Does anyone have any feedback on sane timeout values for load balancing redis? 

The testing config I was using had ‘timeout client 5’ and I was getting 
consistent client disconnects in the logs. I increased it to two minutes and 
things have improved significantly, though I do see client disconnects every 
few hours (but the application is behaving normally). Client is 
StackExchange.Redis if that helps. 

Google wasn’t much use. HA-Proxy version 1.5.10. Full config: 

global 
log /dev/log local0 
log /dev/log local1 notice 
chroot /var/lib/haproxy 
stats socket /run/haproxy/admin.sock mode 660 level admin 
stats timeout 30s 
user haproxy 
group haproxy 
daemon 

defaults 
log global 
mode tcp 
option tcplog 
option dontlognull 
timeout connect 5000 
timeout client 2m 
timeout server 12 
errorfile 400 /etc/haproxy/errors/400.http 
errorfile 403 /etc/haproxy/errors/403.http 
errorfile 408 /etc/haproxy/errors/408.http 
errorfile 500 /etc/haproxy/errors/500.http 
errorfile 502 /etc/haproxy/errors/502.http 
errorfile 503 /etc/haproxy/errors/503.http 
errorfile 504 /etc/haproxy/errors/504.http 

frontend redisFE 
bind *:6379 
mode tcp 
maxconn 10240 
default_backend redisBE 

backend redisBE 
mode tcp 
option tcplog 
balance source 
option tcp-check 
tcp-check send PING\r\n 
tcp-check expect string +PONG 
tcp-check send info\ replication\r\n 
tcp-check expect string role:master 
tcp-check send QUIT\r\n 
tcp-check expect string +OK 
server A-redis-01 X:6379 maxconn 1024 check inter 1s 
server A-redis-02 X:6379 maxconn 1024 check inter 1s 
server B-redis-01 X:6379 maxconn 1024 check inter 1s 
server B-redis-02 X:6379 maxconn 1024 check inter 1s 

Jim Gronowski 
Network Administrator 
DiTronics, LLC. 

Ditronics, LLC email disclaimer: 
This communication, including attachments, is intended only for the exclusive 
use of addressee and may contain proprietary, confidential, or privileged 
information. Any use, review, duplication, disclosure, dissemination, or 
distribution is strictly prohibited. If you were not the intended recipient, 
you have received this communication in error. Please notify sender immediately 
by return e-mail, delete this communication, and destroy any copies.

Re: limiting conn-curs per-ip using x-forwarded-for

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "Klavs Klavsen"  
To: "Mark S." , haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 10:56:03 AM 
Subject: Re: limiting conn-curs per-ip using x-forwarded-for 

Mark S. wrote on 03/24/2015 03:36 PM: 
> Hi Klavs, 
> 
> Try using this in the backend section for the track-sc2 statement to use 
> the previous instance of the Forwarded-For header. 
> 
> I have a version of this working in a similar fashion, but I am using a 
> "stick-table type binary" instead of string - it probably works both 
> ways, but I haven't tested type string. I'm using http_req_rate as I'm 
> concerned about the rate rather than the number of active connections. 
> 
> stick-table type binary len 32 size 5k expire 5m store 
> http_req_rate(10s),gpc0 
> tcp-request content track-sc2 hdr(X-Forwarded-For,-1) 
> 

Thank you Mark, 

It did help.. somewhat.. now first connection is allowed :) 

I now have: 
stick-table type string size 100k store conn_cur,gpc0 
stick store-request hdr(X-Forwarded-For,-1) 
tcp-request content track-sc2 hdr(X-Forwarded-For) 
acl allowed sc2_conn_cur lt 2 
block unless allowed 

But everyone gets blocked - when one connection is active.. (ie. not 
just the source of that one connection). 

show table shows this: 
table: kk.dk-ds-backend, type: string, size:102400, used:2 
0x1304dfc: key=10.27.174.10 use=1 exp=0 server_id=1 gpc0=0 conn_cur=1 

shouldn't the key - be the x-forwarded-for header? 

[CUT] 
-- 
Regards, 
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 

"Those who do not understand Unix are condemned to reinvent it, poorly." 
--Henry Spencer

Re: HAProxy signal queue not working correctly

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "Alan Fitton"  
To: "Willy Tarreau"  
Cc: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 2:01:59 PM 
Subject: RE: HAProxy signal queue not working correctly 

Hi, 

I've been trying out this logging, and a few variations of my own, on one of 
the RHEL5 (2.6.18-371.9.1.el5) systems that was exhibiting the problem more 
frequently. 

I am seeing what you saw, signals queued and processed without any issue.. It's 
strange, I can't figure out why the problem isn't reproducible from a large 
amount of signals on the command line, yet would be happening every few days 
through occasional use of the reload command. 

I will keep looking. Probably by deploying a patched version which logs the 
below and some more to syslog, so I can look out for the problem in a more 
"realistic" setting. 

Since deploying my workaround patch which traverses the signal_queue instead of 
checking signal_state[sig].count, the problem hasn't been seen in our test 
environment. 

Agree it's probably a bug which needs fixing from a signal handling point of 
view, and I'm definitely up for trying to find the cause. My thoughts about 
queueing reloads on the automation side were because it seems unnecessary and 
not optimal (for us anyway) for the automation to potentially reload HAProxy 
more than once every few seconds. 

while true; do kill -QUIT 28292; kill -TTOU 28292; kill -QUIT 28292; kill -TTIN 
28292; done 

leave loop: signal_queue_len=3, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0 
signal handler: signal_queue_len=0, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0 
signal handler: signal_queue_len=0, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0 
signal handler: signal_queue_len=0, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0 
enter loop: signal_queue_len=3, count[SIGTTOU]=1, count[SIGTTIN]=1, 
count[SIGQUIT]=1 
leave loop: signal_queue_len=3, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0 

Regards, 
Alan 

-Original Message- 
From: Willy Tarreau [mailto:w...@1wt.eu] 
Sent: 19 March 2015 15:17 
To: Alan Fitton 
Cc: haproxy@formilux.org 
Subject: Re: HAProxy signal queue not working correctly 

Hi Alan, 

On Thu, Mar 19, 2015 at 10:56:35AM +, Alan Fitton wrote: 
> Hi Willy, 
> 
> Thank you for your reply and your work on HAProxy. I will add some 
> instrumentation and hopefully be able to demonstrate your theory. I agree, 
> it's the one I had arrived at too :) It seemed unlikely at first since the 
> signals are masked inside __signal_process_queue, but it's still possible if 
> timing goes against you. 

I don't think we're sensitive to timing here. I've done this to try to 
reproduce the issue : 

diff --git a/src/signal.c b/src/signal.c 
index e9301ed..241feac 100644 
--- a/src/signal.c 
+++ b/src/signal.c 
@@ -37,6 +37,7 @@ int signal_pending = 0; /* non-zero if t least one signal 
remains unprocessed */ 
*/ 
void signal_handler(int sig) 
{ 
+ fprintf(stderr, "received signal %d\n", sig); 
if (sig < 0 || sig >= MAX_SIGNAL) { 
/* unhandled signal */ 
signal(sig, SIG_IGN); 
@@ -77,6 +78,7 @@ void __signal_process_queue() 
* handler. That allows real signal handlers to redistribute signals 
* to tasks subscribed to signal zero. 
*/ 
+ fprintf(stderr, "enter loop: signal_queue_len=%d, count[%d]=%d\n", 
signal_queue_len, SIGUSR1, signal_state[SIGUSR1].count); 
for (cur_pos = 0; cur_pos < signal_queue_len; cur_pos++) { 
sig = signal_queue[cur_pos]; 
desc = &signal_state[sig]; 
@@ -90,7 +92,9 @@ void __signal_process_queue() 
} 
desc->count = 0; 
} 
+ sleep(1); 
} 
+ fprintf(stderr, "leave loop: signal_queue_len=%d, count[%d]=%d\n", 
signal_queue_len, SIGUSR1, signal_state[SIGUSR1].count); 
signal_queue_len = 0; 

/* restore signal delivery */ 

Then I'm doing that : 

$ killall -QUIT haproxy;killall -1 haproxy; kill -USR1 $(pidof haproxy) $(pidof 
haproxy) $(pidof haproxy) $(pidof haproxy) $(pidof haproxy) $(pidof haproxy) 
$(pidof haproxy) $(pidof haproxy); 

(SIGQUIT send a large response, and SIGHUP talks as well). The sleep(1) 
is here to ensure that signals get delivered and queued before we 
re-enable signals. I'm clearly seeing my messages being queued : 

received signal 3 
enter loop: signal_queue_len=1, count[10]=0 
Dumping pools usage. Use SIGQUIT to flush them. 
- Pool pipe (32 bytes) : 5 allocated (160 bytes), 5 used, 4 users [SHARED] 
- Pool hlua_com (48 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] 
- Pool capture (64 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] 
- Pool task (112 bytes) : 2 allocated (224 bytes), 2 used, 1 users [SHARED] 
- Pool uniqueid (128 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] 
- Pool connection (336 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] 
- Pool hdr_idx (416 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] 
- Pool requri (1024 bytes) : 0 allocated (0 bytes), 0 used, 1

Re: How can i get haproxy reload its configuration

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "jeff saremi"  
To: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 3:22:09 PM 
Subject: RE: How can i get haproxy reload its configuration 

From: jeffsar...@hotmail.com To: haproxy@formilux.org Subject: RE: How can i 
get haproxy reload its configuration Date: Tue, 24 Mar 2015 08:52:20 -0400 > 
Subject: Re: How can i get haproxy reload its configuration> From: Vincent 
Bernat> Date: 2015-03-24 12:07:34> Message-ID: 87619q61kp.fsf () zoro ! 
exoscale ! ch> â�¦ 24 mars 2015 07:45 -0400, jeff saremi Â :> > #!/bin/sh> > 
pidfile=/data/haproxy.pidhaproxy -db \> > -f /haproxy-1.5.8/haproxy.cfg -p 
$pidfile \> > -sf $(cat $pidfile)> The shell does variable substitution first, 
then execute the> line. Hence, $pidfile is expanded to "", not to 
"/data/haproxy.pid". Put> pidfile=... on its own line.> --> I'll burn my 
books.> -- Christopher Marlowe Sorry that was just how my email got through. 
Those are separate lines. So here it is again: #!/bin/sh 
pidfile=/data/haproxy.pid haproxy -db \ -f /haproxy-1.5.8/haproxy.cfg -p 
$pidfile \ -sf $(cat $pidfile) What i'm wondering is how this could have ever 
worked? since the "$(cat $pidfile) and the creation of the $pidfile are both on 
the same line. Is it possible that when the pidfile is concatenated for the 
sake of "-sf" the file does not exist or contains old pids? So my suspicion 
around the -sf was correct. Each time i run the haproxy command I get the 
following printed on the console: cat: /data/haproxy.pid: No such file or 
directory which seems to be a result of "-sf $(cat $pidfile)" in the command 
line. Has anyone successfully done this in practice? is there possibly other 
ways of achieving this with having to restart the haproxy process? thanks

Re: limiting conn-curs per-ip using x-forwarded-for

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "Jarno Huuskonen"  
To: "Klavs Klavsen"  
Cc: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 12:58:21 PM 
Subject: Re: limiting conn-curs per-ip using x-forwarded-for 

Hi, 

On Tue, Mar 24, Klavs Klavsen wrote: 
> I now have: 
> stick-table type string size 100k store conn_cur,gpc0 
> stick store-request hdr(X-Forwarded-For,-1) 
> tcp-request content track-sc2 hdr(X-Forwarded-For) 
> acl allowed sc2_conn_cur lt 2 
> block unless allowed 

tcp-request inspect-delay ? 
Most of the examples seem to use inspect-delay: 
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-tcp-request%20content

> shouldn't the key - be the x-forwarded-for header? 

Have you checked that the requests have (one) x-forwarded-for header ? 
hdr(X-Forwarded-For) = first header, and hdr(X-Forwarded-For,-1) = last header. 
(http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.6-req.hdr) 

And is the haproxy ip the only one thats in the stick table ? 

-Jarno 

-- 
Jarno Huuskonen

Re: using backend node details in acls/response manipulation

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "Martin Nikolov"  
To: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 3:36:36 PM 
Subject: using backend node details in acls/response manipulation 

Hi guys, 
I'm wondering if it is possible to use things like selected backend node's ip, 
name or port as variables. My goal is to set a header in the http response with 
the selected backend's details to a certain set of source ip addresses (hence 
the acl, which is the easy part). I searched in the documentation, but was not 
able to find a solution. 

Thanks in advance. 

Regards.

Re: Retrying a request on other servers

Thanks, I sent request previously to you but I have done it. 
Ha. 

- Original Message -

From: "jeff saremi"  
To: haproxy@formilux.org 
Sent: Tuesday, March 24, 2015 4:12:32 PM 
Subject: Retrying a request on other servers 

Is this a feature of HaProxy? and if so what is the corresponding option to 
enable it. 
Basically, i want Harpoxy to resend the request which as already received a 503 
from one server, to another server in the same backend. 
And i'd like to control how many tries to do. 
I looked at that options: "retries" and "redispatch" but they don't seem to be 
doing this. 
thanks 
Jeff

RE: Retrying a request on other servers

2015-03-24 Thread Lukas Tribus

> Is this a feature of HaProxy? and if so what is the corresponding  
> option to enable it. 
> Basically, i want Harpoxy to resend the request which as already  
> received a 503 from one server, to another server in the same backend. 

Thats not supported, no.

Lukas

Retrying a request on other servers

Is this a feature of HaProxy? and if so what is the corresponding option to 
enable it.
Basically, i want Harpoxy to resend the request which as already received a 503 
from one server, to another server in the same backend.
And i'd like to control how many tries to do.
I looked at that options: "retries" and "redispatch" but they don't seem to be 
doing this.
thanksJeff

using backend node details in acls/response manipulation

2015-03-24 Thread Martin Nikolov

Hi guys,
I'm wondering if it is possible to use things like selected backend node's
ip, name or port as variables. My goal is to set a header in the http
response with the selected backend's details to a certain set of source ip
addresses (hence the acl, which is the easy part). I searched in the
documentation, but was not able to find a solution.

Thanks in advance.
Regards.

RE: How can i get haproxy reload its configuration

From: jeffsar...@hotmail.com
To: haproxy@formilux.org
Subject: RE: How can i get haproxy reload its configuration
Date: Tue, 24 Mar 2015 08:52:20 -0400

> Subject: Re: How can i get haproxy reload its configuration> From: Vincent 
> Bernat> Date: 2015-03-24 12:07:34> Message-ID: 87619q61kp.fsf () zoro ! 
> exoscale ! ch> â¦ 24 mars 2015 07:45 -0400, jeff saremi Â :> > #!/bin/sh> > 
> pidfile=/data/haproxy.pidhaproxy -db \> > -f /haproxy-1.5.8/haproxy.cfg -p 
> $pidfile \> > -sf $(cat $pidfile)> The shell does variable substitution 
> first, then execute the> line. Hence, $pidfile is expanded to "", not to 
> "/data/haproxy.pid". Put> pidfile=... on its own line.> --> I'll burn my 
> books.> -- Christopher Marlowe Sorry that was just how my email got through. 
> Those are separate lines. So here it is again: #!/bin/sh 
> pidfile=/data/haproxy.pid haproxy -db \ -f /haproxy-1.5.8/haproxy.cfg -p 
> $pidfile \ -sf $(cat $pidfile) What i'm wondering is how this could have 
> ever worked? since the "$(cat $pidfile) and the creation of the $pidfile are 
> both on the same line. Is it possible that when the pidfile is concatenated 
> for the sake of "-sf" the file does not exist or contains old pids?


So my suspicion around the -sf was correct. Each time i run the haproxy command 
I get the following printed on the console:

cat: /data/haproxy.pid: No such file or directory


which seems to be a result of "-sf $(cat $pidfile)" in the command line.


Has anyone successfully done this in practice? is there possibly other ways of 
achieving this with having to restart the haproxy process?
thanks

RE: HAProxy signal queue not working correctly

2015-03-24 Thread Alan Fitton

Hi,

I've been trying out this logging, and a few variations of my own, on one of 
the RHEL5 (2.6.18-371.9.1.el5) systems that was exhibiting the problem more 
frequently.

I am seeing what you saw, signals queued and processed without any issue.. It's 
strange, I can't figure out why the problem isn't reproducible from a large 
amount of signals on the command line, yet would be happening every few days 
through occasional use of the reload command.

I will keep looking. Probably by deploying a patched version which logs the 
below and some more to syslog, so I can look out for the problem in a more 
"realistic" setting.

Since deploying my workaround patch which traverses the signal_queue instead of 
checking signal_state[sig].count, the problem hasn't been seen in our test 
environment.

Agree it's probably a bug which needs fixing from a signal handling point of 
view, and I'm definitely up for trying to find the cause. My thoughts about 
queueing reloads on the automation side were because it seems unnecessary and 
not optimal (for us anyway) for the automation to potentially reload HAProxy 
more than once every few seconds.

while true; do kill -QUIT 28292; kill -TTOU 28292; kill -QUIT 28292; kill -TTIN 
28292; done

leave loop: signal_queue_len=3, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0
signal handler: signal_queue_len=0, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0
signal handler: signal_queue_len=0, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0
signal handler: signal_queue_len=0, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0
enter loop: signal_queue_len=3, count[SIGTTOU]=1, count[SIGTTIN]=1, 
count[SIGQUIT]=1
leave loop: signal_queue_len=3, count[SIGTTOU]=0, count[SIGTTIN]=0, 
count[SIGQUIT]=0

Regards,
Alan

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: 19 March 2015 15:17
To: Alan Fitton
Cc: haproxy@formilux.org
Subject: Re: HAProxy signal queue not working correctly

Hi Alan,

On Thu, Mar 19, 2015 at 10:56:35AM +, Alan Fitton wrote:
> Hi Willy,
>
> Thank you for your reply and your work on HAProxy. I will add some
> instrumentation and hopefully be able to demonstrate your theory. I agree,
> it's the one I had arrived at too :) It seemed unlikely at first since the
> signals are masked inside __signal_process_queue, but it's still possible if
> timing goes against you.

I don't think we're sensitive to timing here. I've done this to try to
reproduce the issue :

diff --git a/src/signal.c b/src/signal.c
index e9301ed..241feac 100644
--- a/src/signal.c
+++ b/src/signal.c
@@ -37,6 +37,7 @@ int signal_pending = 0; /* non-zero if t least one signal 
remains unprocessed */
  */
 void signal_handler(int sig)
 {
+   fprintf(stderr, "received signal %d\n", sig);
if (sig < 0 || sig >= MAX_SIGNAL) {
/* unhandled signal */
signal(sig, SIG_IGN);
@@ -77,6 +78,7 @@ void __signal_process_queue()
 * handler. That allows real signal handlers to redistribute signals
 * to tasks subscribed to signal zero.
 */
+   fprintf(stderr, "enter loop: signal_queue_len=%d, count[%d]=%d\n", 
signal_queue_len, SIGUSR1, signal_state[SIGUSR1].count);
for (cur_pos = 0; cur_pos < signal_queue_len; cur_pos++) {
sig  = signal_queue[cur_pos];
desc = &signal_state[sig];
@@ -90,7 +92,9 @@ void __signal_process_queue()
}
desc->count = 0;
}
+   sleep(1);
}
+   fprintf(stderr, "leave loop: signal_queue_len=%d, count[%d]=%d\n", 
signal_queue_len, SIGUSR1, signal_state[SIGUSR1].count);
signal_queue_len = 0;

/* restore signal delivery */

Then I'm doing that :

$ killall -QUIT haproxy;killall -1 haproxy; kill -USR1 $(pidof haproxy) $(pidof 
haproxy) $(pidof haproxy) $(pidof haproxy) $(pidof haproxy) $(pidof haproxy) 
$(pidof haproxy) $(pidof haproxy);

(SIGQUIT send a large response, and SIGHUP talks as well). The sleep(1)
is here to ensure that signals get delivered and queued before we
re-enable signals. I'm clearly seeing my messages being queued :

received signal 3
enter loop: signal_queue_len=1, count[10]=0
Dumping pools usage. Use SIGQUIT to flush them.
  - Pool pipe (32 bytes) : 5 allocated (160 bytes), 5 used, 4 users [SHARED]
  - Pool hlua_com (48 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED]
  - Pool capture (64 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED]
  - Pool task (112 bytes) : 2 allocated (224 bytes), 2 used, 1 users [SHARED]
  - Pool uniqueid (128 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED]
  - Pool connection (336 bytes) : 0 allocated (0 bytes), 0 used, 1 users 
[SHARED]
  - Pool hdr_idx (416 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED]
  - Pool requri (1024 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED]
  - Pool session (1072 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED]

timeout values for redis?

2015-03-24 Thread Jim Gronowski

Does anyone have any feedback on sane timeout values for load balancing redis?

The testing config I was using had 'timeout client 5' and I was getting 
consistent client disconnects in the logs.  I increased it to two minutes and 
things have improved significantly, though I do see client disconnects every 
few hours (but the application is behaving normally).  Client is 
StackExchange.Redis if that helps.

Google wasn't much use.  HA-Proxy version 1.5.10.   Full config:

global
log /dev/loglocal0
log /dev/loglocal1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon

defaults
 log global
modetcp
option  tcplog
option  dontlognull
timeout connect 5000
timeout client  2m
timeout server  12
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

frontend redisFE
bind *:6379
mode tcp
maxconn 10240
default_backend redisBE

backend redisBE
mode tcp
option tcplog
balance source
option tcp-check
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check send info\ replication\r\n
tcp-check expect string role:master
tcp-check send QUIT\r\n
tcp-check expect string +OK
server A-redis-01 X:6379 maxconn 1024 check inter 1s
server A-redis-02 X:6379 maxconn 1024 check inter 1s
server B-redis-01 X:6379 maxconn 1024 check inter 1s
server B-redis-02 X:6379 maxconn 1024 check inter 1s



Jim Gronowski
Network Administrator
DiTronics, LLC.



Ditronics, LLC email disclaimer:
This communication, including attachments, is intended only for the exclusive 
use of addressee and may contain proprietary, confidential, or privileged 
information. Any use, review, duplication, disclosure, dissemination, or 
distribution is strictly prohibited. If you were not the intended recipient, 
you have received this communication in error. Please notify sender immediately 
by return e-mail, delete this communication, and destroy any copies.

Re: limiting conn-curs per-ip using x-forwarded-for

2015-03-24 Thread Jarno Huuskonen

Hi,

On Tue, Mar 24, Klavs Klavsen wrote:
> I now have:
>   stick-table  type string size 100k store conn_cur,gpc0
>   stick store-request  hdr(X-Forwarded-For,-1)
>   tcp-request content  track-sc2 hdr(X-Forwarded-For)
>   acl allowed  sc2_conn_cur lt 2
>   block unless allowed

tcp-request inspect-delay ?
Most of the examples seem to use inspect-delay:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-tcp-request%20content

> shouldn't the key - be the x-forwarded-for header?

Have you checked that the requests have (one) x-forwarded-for header ?
hdr(X-Forwarded-For) = first header, and hdr(X-Forwarded-For,-1) = last header.
(http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.6-req.hdr)

And is the haproxy ip the only one thats in the stick table ?

-Jarno

-- 
Jarno Huuskonen

Re: limiting conn-curs per-ip using x-forwarded-for


Mark S. wrote on 03/24/2015 03:36 PM:

Hi Klavs,

Try using this in the backend section for the track-sc2 statement to use
the previous instance of the Forwarded-For header.

I have a version of this working in a similar fashion, but I am using a
"stick-table type binary" instead of string - it probably works both
ways, but I haven't tested type string.  I'm using http_req_rate as I'm
concerned about the rate rather than the number of active connections.

stick-table type binary len 32 size 5k expire 5m store
http_req_rate(10s),gpc0
tcp-request content track-sc2 hdr(X-Forwarded-For,-1)



Thank you Mark,

It did help.. somewhat.. now first connection is allowed :)

I now have:
  stick-table  type string size 100k store conn_cur,gpc0
  stick store-request  hdr(X-Forwarded-For,-1)
  tcp-request content  track-sc2 hdr(X-Forwarded-For)
  acl allowed  sc2_conn_cur lt 2
  block unless allowed

But everyone gets blocked - when one connection is active.. (ie. not 
just the source of that one connection).


show table shows this:
 table: kk.dk-ds-backend, type: string, size:102400, used:2
0x1304dfc: key=10.27.174.10 use=1 exp=0 server_id=1 gpc0=0 conn_cur=1

shouldn't the key - be the x-forwarded-for header?

[CUT]
--
Regards,
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer

Re: limiting conn-curs per-ip using x-forwarded-for


hmm. it says:
: 'stick' ignored because frontend 'nocache' has no backend capability.

it seems it has to be on the backend..

When set on the backend, I get an entry in the list:
# table: kk.dk-ds-backend, type: ip, size:1024, used:1
0x14b25c8: key=10.27.174.10 use=0 exp=296637 server_id=0 gpc0=0

(with stick table of type ip)

and with stable table type string:
# table: kk.dk-ds-backend, type: string, size:1024, used:1
0x1d84d18: key=10.27.174.10 use=0 exp=267770 server_id=1 gpc0=0

the key (10.27.174.10) is the ip of the haproxy server.. :(

And no matter - it denied EVERY request to the server when I set the 
block.. :(



So when I have 3 backends - behind the same frontend, I have
Jarno Huuskonen wrote on 03/24/2015 02:23 PM:

Hi,

On Tue, Mar 24, Klavs Klavsen wrote:

#create a stick-table of 30 IPs for storing active IPs, 5 minute timeout
stick-table type ip size 30 expire 5m store gpc0
#populate the table with the X-Forwarded-For header
stick store-request hdr(X-Forwarded-For)


You've created type ip stick table, but I think hdr(X-Forwarded-For)
returns a string. Do you see any entries in the stick table:
show table nocache -> to stats socket

Maybe it's possible to use one of the converters
to map str -> ip
(http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.1-map)

or try with a string stick table:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-stick-table

-Jarno




--
Regards,
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer

Re: limiting conn-curs per-ip using x-forwarded-for


Tried converting it to type: string.. but its always empty :(

# table: nocache, type: string, size:1024, used:0
# table: nocache, type: ip, size:30, used:0

The frontend config is:
  mode  http
  acl allowed  sc2_conn_cur lt 2
  balance  roundrobin
  default_backend  ds-backend
  option  httplog
  option  accept-invalid-http-reques
   stick store-request  hdr(X-Forwarded-For)
   stick-table  type string len 20 expire 5m store gpc0
   tcp-request content  track-sc2 hdr(X-Forwarded-For)


Jarno Huuskonen wrote on 03/24/2015 02:23 PM:

Hi,

On Tue, Mar 24, Klavs Klavsen wrote:

#create a stick-table of 30 IPs for storing active IPs, 5 minute timeout
stick-table type ip size 30 expire 5m store gpc0
#populate the table with the X-Forwarded-For header
stick store-request hdr(X-Forwarded-For)


You've created type ip stick table, but I think hdr(X-Forwarded-For)
returns a string. Do you see any entries in the stick table:
show table nocache -> to stats socket

Maybe it's possible to use one of the converters
to map str -> ip
(http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.1-map)

or try with a string stick table:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-stick-table

-Jarno




--
Regards,
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer

Re: limiting conn-curs per-ip using x-forwarded-for

2015-03-24 Thread Jarno Huuskonen

Hi,

On Tue, Mar 24, Klavs Klavsen wrote:
> #create a stick-table of 30 IPs for storing active IPs, 5 minute timeout
> stick-table type ip size 30 expire 5m store gpc0
> #populate the table with the X-Forwarded-For header
> stick store-request hdr(X-Forwarded-For)

You've created type ip stick table, but I think hdr(X-Forwarded-For)
returns a string. Do you see any entries in the stick table:
show table nocache -> to stats socket

Maybe it's possible to use one of the converters
to map str -> ip
(http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.1-map)

or try with a string stick table:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-stick-table

-Jarno

-- 
Jarno Huuskonen

RE: How can i get haproxy reload its configuration

> Subject: Re: How can i get haproxy reload its configuration
> From: Vincent Bernat 
> Date: 2015-03-24 12:07:34
> Message-ID: 87619q61kp.fsf () zoro ! exoscale ! ch

> â¦ 24 mars 2015 07:45 -0400, jeff saremi Â :

> > #!/bin/sh
> > pidfile=/data/haproxy.pidhaproxy -db \
> > -f /haproxy-1.5.8/haproxy.cfg -p $pidfile \
> > -sf $(cat $pidfile)

> The shell does variable substitution first, then execute the
> line. Hence, $pidfile is expanded to "", not to "/data/haproxy.pid". Put
> pidfile=... on its own line.
> -- 
> I'll burn my books.
> -- Christopher Marlowe


Sorry that was just how my email got through. Those are separate lines.
So here it is again:
#!/bin/sh
pidfile=/data/haproxy.pid
haproxy -db \
-f /haproxy-1.5.8/haproxy.cfg -p $pidfile \
-sf $(cat $pidfile)

What i'm wondering is how this could have ever worked? since the "$(cat 
$pidfile) and the creation of the $pidfile are both on the same line. Is it 
possible that when the pidfile is concatenated for the sake of "-sf" the file 
does not exist or contains old pids?

Re: limiting conn-curs per-ip using x-forwarded-for

I tried

acl allowed sc2_conn_cur lt 2
block unless allowed

it blocked every access :(

Klavs Klavsen wrote on 03/24/2015 01:19 PM:

Can I perhaps do something like:

tcp-request content track-sc2 hdr(X-Forwarded-For)
acl conn_limit_hit sc2_conn_cur gt 2

Klavs Klavsen wrote on 03/24/2015 01:11 PM:

Hi,

We would like to limit how many connections a given IP can send to our
backend.

Our setup is like this:
haproxy -> varnish -> haproxy -> webservers

and we'd like to have the frontend behind varnish (we call it nocache :)
limit concurrent connections any IP can have.. (to 1 or 2 is the idea)..

I've googled and read.. and it seems stick-table should be used..

My current setup looks something like this (based/stolen from
http://fotoarkiv.com/wordpress/limiting-the-number-of-active-users-on-a-site-using-haproxy/

frontend nocache
..
#create a stick-table of 30 IPs for storing active IPs, 5 minute timeout
stick-table type ip size 30 expire 5m store gpc0
#populate the table with the X-Forwarded-For header
stick store-request hdr(X-Forwarded-For)
#allow new users if we have more than 1 available slot in the stick table
acl allowed table_avl(nocache) gt 1

#if not allowed above, go away
block unless allowed

but it looks for "available slots in stick-table".. I'd like to simply
block if the ip already has more than 2 connections..

I figured I could use src_conn_cnt.. but I need it to use the ip in
X-Forwarded-For..

How can I do that?

Thank you in advance

--
Regards,
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer

Re: OCSP stappling full support

2015-03-24 Thread Jeff Mitchell

No, Ha just replied with that same message to a ton of different
threads on the mailing list.

On Tue, Mar 24, 2015 at 6:10 AM, Pierre Ozoux  wrote:
> Hi!
>
> I don't understand, do you mean that HAProxy OCSPStappling is easier now?
> Can you point to the documentation?
>
> Thanks,
>
> Pierre
>
> Written with a mobile device, sorry for typos..
>
> On 23 mars 2015, at 22:36, Ha Quan Le  wrote:
>
> Thank you for support, we have fixed our issues.
> Ha.
>
> 
> From: "Pierre Ozoux" 
> To: haproxy@formilux.org
> Sent: Friday, March 20, 2015 11:59:16 AM
> Subject: OCSP stappling full support
>
> Hi,
>
> HAProxy provides OCSP stapling since v1.5 and this is nice!
>
> Although, it is still difficult to setup compared to Apache or Nginx.
> I had to do this little script:
> https://wiki.mozilla.org/Talk:Security/Server_Side_TLS#OCSP_in_HAProxy
>
> It would be really nice if it was as easy as Apache and Nginx.
> Is it planned in the roadmap?
>
> Thanks a lot for your work,
>
> Pierre
>
> --
> I use PGP to protect our privacy, if you want to know more, you can
> follow this
> https://emailselfdefense.fsf.org/en/
>
> If you have further questions, please do not hesitate to ask.
> You can verify my public key here: https://keybase.io/pierreozoux
>
>

Re: limiting conn-curs per-ip using x-forwarded-for

Can I perhaps do something like:

tcp-request content track-sc2 hdr(X-Forwarded-For)
acl conn_limit_hit sc2_conn_cur gt 2

Klavs Klavsen wrote on 03/24/2015 01:11 PM:

Hi,

We would like to limit how many connections a given IP can send to our
backend.

Our setup is like this:
haproxy -> varnish -> haproxy -> webservers

and we'd like to have the frontend behind varnish (we call it nocache :)
limit concurrent connections any IP can have.. (to 1 or 2 is the idea)..

I've googled and read.. and it seems stick-table should be used..

My current setup looks something like this (based/stolen from
http://fotoarkiv.com/wordpress/limiting-the-number-of-active-users-on-a-site-using-haproxy/
):

#if not allowed above, go away
block unless allowed

but it looks for "available slots in stick-table".. I'd like to simply
block if the ip already has more than 2 connections..

I figured I could use src_conn_cnt.. but I need it to use the ip in
X-Forwarded-For..

How can I do that?

Thank you in advance

--
Regards,
Klavs Klavsen, GSEC, kl...@enableit.dk - Tlf. +45 612 812 00
EnableIT - Open Source Server, Security and Network Consulting

"Open Source Software - Sometimes you get more than you paid for."

limiting conn-curs per-ip using x-forwarded-for


Hi,

We would like to limit how many connections a given IP can send to our 
backend.


Our setup is like this:
haproxy -> varnish -> haproxy -> webservers

and we'd like to have the frontend behind varnish (we call it nocache :) 
limit concurrent connections any IP can have.. (to 1 or 2 is the idea)..


I've googled and read.. and it seems stick-table should be used..

My current setup looks something like this (based/stolen from 
http://fotoarkiv.com/wordpress/limiting-the-number-of-active-users-on-a-site-using-haproxy/ 
):


frontend nocache
..
#create a stick-table of 30 IPs for storing active IPs, 5 minute timeout
stick-table type ip size 30 expire 5m store gpc0
#populate the table with the X-Forwarded-For header
stick store-request hdr(X-Forwarded-For)
#allow new users if we have more than 1 available slot in the stick table
acl allowed table_avl(nocache) gt 1

#if not allowed above, go away
block unless allowed

but it looks for "available slots in stick-table".. I'd like to simply 
block if the ip already has more than 2 connections..


I figured I could use src_conn_cnt.. but I need it to use the ip in 
X-Forwarded-For..


How can I do that?

Thank you in advance

--
Regards,
Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer

Re: How can i get haproxy reload its configuration

2015-03-24 Thread Vincent Bernat

 ❦ 24 mars 2015 07:45 -0400, jeff saremi  :

> #!/bin/sh
> pidfile=/data/haproxy.pidhaproxy -db  \
>   -f /haproxy-1.5.8/haproxy.cfg   -p $pidfile   \
>   -sf $(cat $pidfile)

The shell does variable substitution first, then execute the
line. Hence, $pidfile is expanded to "", not to "/data/haproxy.pid". Put
pidfile=... on its own line.
-- 
I'll burn my books.
-- Christopher Marlowe

250 euros offerts pour parier sur le GNT Ã Marseille

2015-03-24 Thread ZEturf

Title: Grand National du Trot - Marseille Borely






  

  
  
Si vous ne voyez pas correctement ce message, visualisez notre version en ligne.
Pour être sûr de recevoir tous nos emails, ajoutez newslet...@email.zeturf.com à votre carnet d´adresses
Pour ne plus recevoir de messages de notre part, rendez-vous sur cette page.
  

  


  

  

  

  

  

  
  

  

  
  

  

  

  


  

  
 

 

 
  

  




  
  
  

  
  

  
  Mot de passe oublié ?     | 
     Désinscription Newsletter    |  
    Jeu responsable   |
  Contactez-nous
  

  
  

  
  
  

  


  Offre valable sur la réunion de Marseille Borely, mercredi 25 mars 2015. Voir conditions sur le site.

À tout moment, vous disposez d'un droit d'accès, de modification, de rectification et de suppression des données qui vous concernent.

Jouer comporte des risques : endettement, isolement… Pour être aidé, appelez le 09-74-75-13-13 (appel non surtaxé).
  


  

  
  Vous devez avoir plus de 18 ans pour jouer sur ZEturf

How can i get haproxy reload its configuration