Re: load 'drain' with load-server-state-from-file fails ?

[Nenad Merdanovic]

Hello Peter,

On 6/14/2016 6:37 PM, PiBa-NL wrote:
> Hi list,
> 
> While trying out how to use load-server-state-from-file i noticed that
> 'drain' state set through the stats page is not restored after loading
> the state back.
> 
> I'm using haproxy 1.6.4 / 1.7-dev2 . I realize these are not the latest
> (1.6.5 has dns resolver issues), but am wondering is it 'by design' or
> should the administrative state be restored by this as well?

This is still present in HEAD and the "offending" part of code is:

/* The SRV_ADMF_FDRAIN flag is inherited when srv->iweight is 0
 * (srv->iweight is the weight set up in configuration)
 * so we don't want to apply it when srv_iweight is 0 and
 * srv->iweight is greater than 0. Purpose is to give the
 * chance to the admin to re-enable this server from configuration
 * file by setting a new weight > 0.
 */
if ((srv_iweight == 0) && (srv->iweight > 0)) {
srv_adm_set_drain(srv);
}

This doesn't set the state to DRAIN as srv_iweight is not 0. Now,
looking at the comment and the code, they don't really match IMO, but
I've CCed Baptiste to check this as he developed this part.

That being said, I don't agree with this approach in general, as I think
the state file should be authoritative in all cases and we shouldn't
care if the weight was changed in the configuration. Same thing happens
with applying the weight a little further in the code.

Regards,
Nenad

load 'drain' with load-server-state-from-file fails ?

[PiBa-NL]

Hi list,

While trying out how to use load-server-state-from-file i noticed that 
'drain' state set through the stats page is not restored after loading 
the state back.


I'm using haproxy 1.6.4 / 1.7-dev2 . I realize these are not the latest 
(1.6.5 has dns resolver issues), but am wondering is it 'by design' or 
should the administrative state be restored by this as well?


When putting a server into 'maintenance' state is does load that back 
properly, which seems to confirm my configuration is correct.


Basically the config i was using turns out to the one below after 
stripping most (irrelevant?) parts..


Regards,

Pieter

global
server-state-file /tmp/haproxy_server_state
defaults
modetcp
frontend webgui
bind192.168.0.133:10443
default_backend webgui_https_ipvANY

backend webgui_https_ipvANY
load-server-state-from-file global
server  webgui 192.168.0.133:444

http_conn_rate

[Predrag Aleksic]

Is it possible to reset http_conn_rate counter to 0 , 
so we dont have to wait for interval timer.

Re: Setting OCSP response via socket

[Thijs Kinkhorst]

On 14-06-16 20:10, Lukas Tribus wrote:
> Am 14.06.2016 um 18:31 schrieb Thijs Kinkhorst:
>> If so, I'd like it to become possible, because I'd prefer to be able to
>> set this entirely via the socket approach, and not having to special
>> case the initial condition where the response was not present.
> 
> But then you will have a race condition between the haproxy
> start/reload/restart and when you actually insert the OCSP response in
> haproxy; a time frame where haproxy won't serve ocsp responses to the
> client and that seems like it would defeat the purpose of OCSP.

In that case it would indeed not staple, but that would not defeat the
purpose OCSP itself per se, I think. I was looking for a way to not have
to handle these two cases separately. But perhaps it's indeed not so big
of a burden and it is more correct to not have this short window where
nothing is being stapled.

> If you use must-stable, then you are actually self-DoSing your self.

Although we're not using that now, it surely is a fair point to keep in
mind.

Thanks for your helpful answers.


Cheers,
Thijs

Re: Setting OCSP response via socket

[Lukas Tribus]

Hello,


Am 14.06.2016 um 18:31 schrieb Thijs Kinkhorst:

If so, I'd like it to become possible, because I'd prefer to be able to
set this entirely via the socket approach, and not having to special
case the initial condition where the response was not present.


But then you will have a race condition between the haproxy 
start/reload/restart and when you actually insert the OCSP response in 
haproxy; a time frame where haproxy won't serve ocsp responses to the 
client and that seems like it would defeat the purpose of OCSP.


If you use must-stable, then you are actually self-DoSing your self.


But yes, PiBa-NL is right, just leave the file empty if thats what you 
want [1].




Regards,

Lukas


[1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-crt

Re: Setting OCSP response via socket

[PiBa-NL]

Op 14-6-2016 om 18:31 schreef Thijs Kinkhorst:

Hi all,

First, thanks for haproxy which is really valuable to us.

I'm trying to set up HAproxy so it does OCSP stapling. This works when I
create the $certname.ocsp file and reload haproxy, but I'm trying to get
it to work by using the socket.

The following works for me:
1. Create .ocsp file
2. Reload haproxy (requests are served with OCSP stapled)
3. Issue "set ssl ocsp-response " to socket.
4. HAproxy responds with "OCSP Response updated!"

However, the following does not work:
1. Start HAproxy without the .ocsp file present.
2. Issue "set ssl ocsp-response " to socket.
3. HAproxy responds with "OCSP single response: Certificate ID does not
match any certificate or issuer.", requests lack OCSP stapled.

So am I right to conclude that you can only use the socket based
approach to update OCSP responses if one was already present on-disk
previously? The source code seems to confirm this reading.

If so, I'd like it to become possible, because I'd prefer to be able to
set this entirely via the socket approach, and not having to special
case the initial condition where the response was not present. If not,
am I doing something wrong?


Cheers,
Thijs

Afaik, it is possible to simply create a empty .ocsp file for all 
certificates you want to use it with.


Then as you already do set the actual ocsp response over the unix socket.

Regards,

PiBa-NL

Setting OCSP response via socket

[Thijs Kinkhorst]

Hi all,

First, thanks for haproxy which is really valuable to us.

I'm trying to set up HAproxy so it does OCSP stapling. This works when I
create the $certname.ocsp file and reload haproxy, but I'm trying to get
it to work by using the socket.

The following works for me:
1. Create .ocsp file
2. Reload haproxy (requests are served with OCSP stapled)
3. Issue "set ssl ocsp-response " to socket.
4. HAproxy responds with "OCSP Response updated!"

However, the following does not work:
1. Start HAproxy without the .ocsp file present.
2. Issue "set ssl ocsp-response " to socket.
3. HAproxy responds with "OCSP single response: Certificate ID does not
match any certificate or issuer.", requests lack OCSP stapled.

So am I right to conclude that you can only use the socket based
approach to update OCSP responses if one was already present on-disk
previously? The source code seems to confirm this reading.

If so, I'd like it to become possible, because I'd prefer to be able to
set this entirely via the socket approach, and not having to special
case the initial condition where the response was not present. If not,
am I doing something wrong?


Cheers,
Thijs

[BUMP] Re: external-check stdout ends up in load-balanced traffic, destroying tcp sessions

[Lukas Erlacher]

BUMP

The patch looks good to me and should be merged.

Best,
Luke

On 08.06.2016 03:17, Simon Horman wrote:
> On Tue, Jun 07, 2016 at 08:18:21PM +0200, Willy Tarreau wrote:
>> On Tue, Jun 07, 2016 at 12:01:31PM +0200, Benoit Garnier wrote:
>>> You can always open /dev/null before chrooting and dup() it into FD 0 and 1 
>>> after chroot() has been called.
>>
>> I'd be more tempted to simply close those FDs after the fork(). That
>> may improve the ability to detect faulty scripts which try to dump
>> GBs of data.
>>
>> A very long time ago I've seen a health check perform an LDAP search
>> retrieving all the hundreds of thousands of members of a group, and
>> the people in charge for the server were complaining that the health
>> checks were hurting the server... Better have the script fail with a
>> broken pipe in this case.
>>
>> Just a suggestion.
> 
> Thanks, I think that is reasonable. I particularly like its simplicity.
> 
> Lukas, could you try this?
> 
> diff --git a/src/checks.c b/src/checks.c
> index c4ac947b6051..e65d28f7c3c6 100644
> --- a/src/checks.c
> +++ b/src/checks.c
> @@ -1836,6 +1836,12 @@ static int connect_proc_chk(struct task *t)
>   if (pid == 0) {
>   /* Child */
>   extern char **environ;
> +
> + if ((global.mode & MODE_QUIET) && !(global.mode & 
> MODE_VERBOSE)) {
> + close(0);
> + close(1);
> + }
> +
>   environ = check->envp;
>   extchk_setenv(check, EXTCHK_HAPROXY_SERVER_CURCONN, 
> ultoa_r(s->cur_sess, buf, sizeof(buf)));
>   execvp(px->check_command, check->argv);
> 



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] MINOR: systemd: Use variable for config and pidfile paths

[Pavlos Parissis]

Hi,

Please consider merging the attached patch which allows users to set the 
location of
haproxy.cfg and pidfile files by providing a systemd overwrite file
/etc/systemd/system/haproxy.service.d/overwrite.conf with the following content:

[Service]
Environment=CONFIG=/etc/foobar/haproxy.cfg


Cheers,
Pavlos
From 9ddd9e802cbd86d30acb56053b513b18253c4892 Mon Sep 17 00:00:00 2001
From: Pavlos Parissis 
Date: Tue, 14 Jun 2016 13:28:20 +0200
Subject: [PATCH] MINOR: systemd: Use variable for config and pidfile paths

Users can set the location of haproxy.cfg and pidfile files by providing
a systemd overwrite file /etc/systemd/system/haproxy.service.d/overwrite.conf
with the following content:

[Service]
Environment=CONFIG=/etc/foobar/haproxy.cfg
---
 contrib/systemd/haproxy.service.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/contrib/systemd/haproxy.service.in b/contrib/systemd/haproxy.service.in
index 85937e4..5f6c7d9 100644
--- a/contrib/systemd/haproxy.service.in
+++ b/contrib/systemd/haproxy.service.in
@@ -3,8 +3,9 @@ Description=HAProxy Load Balancer
 After=network.target
 
 [Service]
-ExecStartPre=@SBINDIR@/haproxy -f /etc/haproxy/haproxy.cfg -c -q
-ExecStart=@SBINDIR@/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
+Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
+ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q
+ExecStart=@SBINDIR@/haproxy-systemd-wrapper -f $CONFIG -p $PIDFILE
 ExecReload=/bin/kill -USR2 $MAINPID
 KillMode=mixed
 Restart=always
-- 
2.1.4



signature.asc
Description: OpenPGP digital signature

Re: HTTP Keep Alive : Limit number of sessions in a connection

[Willy Tarreau]

Hi Manas,

On Thu, Jun 09, 2016 at 08:15:56AM -0700, Manas Gupta wrote:
> On Wed, Jun 8, 2016 at 10:44 PM, Willy Tarreau  wrote:
> > At the moment, haproxy checks the frontend's stopped state to decide if it
> > needs to force to disable keep-alive on client connections. By the way that
> > makes me realize that we should also check for the "full" state to optimize
> > early release of client connections when the frontend is full. But we could
> > imagine having an extra "stopping" state that could be turned from the CLI
> > to have the exact same effect.
> >
> 
> I am not sure I understand your last comment.

I meant we could imagine to make it possible to turn a flag from the CLI
indicating that we are switching to a graceful stop mode where persistent
connections are disabled, but it should at least be per frontend (per-
process may also be useful of course).

> As a side, is there some doc which explains everything I see when I
> run 'show sess'
> 
> for example
> 
> 0xfdf780: proto=tcpv4 src=10.193.248.156:51384 fe=ingress be=webs
> srv=web2 ts=08 age=2s calls=2
> rq[f=8848080h,i=0,an=2000h,rx=,wx=,ax=]
> rp[f=8040h,i=0,an=6h,rx=4m57s,wx=,ax=] s0=[7,8h,fd=1997,ex=]
> s1=[7,118h,fd=1998,ex=]exp=4m57s

No, there's no such doc and that's intentional, because these elements
are subject to change at any time. They're used only by developers to
help post-mortem analysis. The only way to get their meaning is by
reading dumpstats.c and find where they're extracted. Some of them are
more or less obvious (src, fe, be, srv), some possibly less (age, exp)
and most others are clearly not. You can perform "show sess 0xX" to
have a more detailed dump of a specific session's state if you're curious.

Regards,
willy

Re: SNI healthcheck on backend?

[Willy Tarreau]

Hi Ray,

On Fri, Jun 10, 2016 at 02:15:56PM -0400, Ray Cote wrote:
> Can the Health Check be driven by the SNI parameter in the server line?

No because the SNI parameter takes an expression. People will typically
use "ssl_fc_sni" here, meaning that the SNI of the front connection has
to be extracted and reused. Others will extract the Host header and emit
the SNI based on this.

> When configuring several backend servers, you???d likely need a
> different SNI for each server, and also have servers for which SNI is not
> configured.

Yes, which is another reason why the SNI parameter should not be used as-is.

> If SNI is declared for the server itself, I???d want to use the same SNI value
> for the health check. Don???t think there would be a situation where a
> different SNI would be used for the health check since technically it
> would be checking a different service.

Yes there is such a situation and it will very likely be the most common one,
users configure the SNI with "ssl_fc_sni" to pass the SNI provided by the
client, and will force a specific value for the checks.

> ???Ray
> (not an HAProxy expert by any stretch of the imagination???simply loving how
> many problems it solves)

:-)

Willy