Re: http-response redirect

[Willy Tarreau]

Hi Igor,

On Sun, Jan 31, 2016 at 07:39:02PM +1100, Igor Cicimov wrote:
> Any chance for this to get back-ported into 1.5?

Not at all. We don't backport features anymore into stable releases,
we've had to deal with too many painful issues in 1.4 because of this
bad practise. This appear to work until the first bug report where
you discover it cannot reliably work because substantial amounts of
core changes would have been needed, and you can't revert the change
because users use it... So now we fix bugs and update the doc only
in stable. And that's already a tough job :-)

Best regards,
Willy

Stick-table peers expiration time

[Igor Cicimov]

Hi all,

I have the following entry in a stick-table:

0x87bf54: key=09643F891F0C6F7BE467E619952E327E use=0 exp=1938168 server_id=1

and on the peer after doing a restart:

0x806934: key=09643F891F0C6F7BE467E619952E327E use=0 exp=4795722 server_id=1

can see the same entry with different expiration time. I thought that upon
restart the server syncs the stick-table from the active peer including the
expiration time. Shouldn't this be in sync between the peers?

My stick-table definition:

stick-table type string len 32 size 30k expire 80m peers LB
stick store-response res.cook(JSESSIONID)
stick on req.cook(JSESSIONID)
tcp-request content track-sc0 req.cook(JSESSIONID)

Thanks,
Igor

Unexpected haproxy 1.6.3 behaviour with -sf

[Cain]

Hi,

Sometimes I find i am left with zombie haproxy instances that are *still
listening* and do *not* have any established connections (netstat told me
so), even though those particular pids have been told to die.

I.e.

 141 ?Ss 0:00 /usr/sbin/haproxy -D -f /proxy.conf -p /proxy.pid
-sf 139
 143 ?Ss 0:00 /usr/sbin/haproxy -D -f /proxy.conf -p /proxy.pid
-sf 141

It is worth mentioning this is running in a Dockerfile with a go
application as the parent (interlock).

I've tried ensuring that new haproxy instances are only started at most
once every 5 seconds (or even 10 seconds), in an attempt to rule out a race
condition, but no dice.

Below are pastes of two strace outputs. The first is tracing (just
capturing signal related calls) the parent (pid 1) and all the children,
note that process 284 gets nothing even when PID 285 kills it. In the
second trace, im capturing everything, note that the process gets the
SIGUSR1 signal, but continues on anyway. Hopefully these shed some light on
what is occurring?

*First trace:*

Process 1 attached with 9 threads
Process 283 attached
[pid   283] rt_sigaction(SIGRTMIN, {0x7fcacff949f0, [],
SA_RESTORER|SA_SIGINFO, 0x7fcacff9d8d0}, NULL, 8) = 0
[pid   283] rt_sigaction(SIGRT_1, {0x7fcacff94a80, [],
SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fcacff9d8d0}, NULL, 8) = 0
[pid   283] rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
[pid   283] rt_sigaction(SIGQUIT, {0x46bb90, [QUIT],
SA_RESTORER|SA_RESTART, 0x7fcad03e4180}, {SIG_DFL, [], 0}, 8) = 0
[pid   283] rt_sigaction(SIGUSR1, {0x46bb90, [USR1],
SA_RESTORER|SA_RESTART, 0x7fcad03e4180}, {SIG_DFL, [], 0}, 8) = 0
[pid   283] rt_sigaction(SIGHUP, {0x46bb90, [HUP], SA_RESTORER|SA_RESTART,
0x7fcad03e4180}, {SIG_DFL, [], 0}, 8) = 0
[pid   283] rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART,
0x7fcad03e4180}, {SIG_DFL, [], 0}, 8) = 0
[pid   283] rt_sigaction(SIGTTOU, {0x46bb90, [TTOU],
SA_RESTORER|SA_RESTART, 0x7fcad03e4180}, {SIG_DFL, [], 0}, 8) = 0
[pid   283] rt_sigaction(SIGTTIN, {0x46bb90, [TTIN],
SA_RESTORER|SA_RESTART, 0x7fcad03e4180}, {SIG_DFL, [], 0}, 8) = 0
[pid   283] kill(176, SIGUSR1)  = 0
[pid   283] +++ exited with 0 +++
[pid66] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=283,
si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid66] rt_sigreturn()  = 283
Process 284 attached
Process 285 attached
[pid   285] rt_sigaction(SIGRTMIN, {0x7f2be16d39f0, [],
SA_RESTORER|SA_SIGINFO, 0x7f2be16dc8d0}, NULL, 8) = 0
[pid   285] rt_sigaction(SIGRT_1, {0x7f2be16d3a80, [],
SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f2be16dc8d0}, NULL, 8) = 0
[pid   285] rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
[pid   285] rt_sigaction(SIGQUIT, {0x46bb90, [QUIT],
SA_RESTORER|SA_RESTART, 0x7f2be1b23180}, {SIG_DFL, [], 0}, 8) = 0
[pid   285] rt_sigaction(SIGUSR1, {0x46bb90, [USR1],
SA_RESTORER|SA_RESTART, 0x7f2be1b23180}, {SIG_DFL, [], 0}, 8) = 0
[pid   285] rt_sigaction(SIGHUP, {0x46bb90, [HUP], SA_RESTORER|SA_RESTART,
0x7f2be1b23180}, {SIG_DFL, [], 0}, 8) = 0
[pid   285] rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART,
0x7f2be1b23180}, {SIG_DFL, [], 0}, 8) = 0
[pid   285] rt_sigaction(SIGTTOU, {0x46bb90, [TTOU],
SA_RESTORER|SA_RESTART, 0x7f2be1b23180}, {SIG_DFL, [], 0}, 8) = 0
[pid   285] rt_sigaction(SIGTTIN, {0x46bb90, [TTIN],
SA_RESTORER|SA_RESTART, 0x7f2be1b23180}, {SIG_DFL, [], 0}, 8) = 0
[pid   285] kill(284, SIGUSR1)  = 0
Process 286 attached
[pid   285] +++ exited with 0 +++
[pid66] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=285,
si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
[pid66] rt_sigreturn()  = 285
^CProcess 1 detached
* <- nothing of interest after this point (waited awhile)*
*Second trace:*

epoll_wait(0, 2191e30, 200, 1000)   = -1 EINTR (Interrupted system call)
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=1120, si_uid=0} ---
rt_sigaction(SIGUSR1, {0x46bb90, [USR1], SA_RESTORER|SA_RESTART,
0x7f437988c180}, {0x46bb90, [USR1], SA_RESTORER|SA_RESTART,
0x7f437988c180}, 8) = 0
rt_sigreturn()  = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_SETMASK, ~[PROF RTMIN RT_1], [], 8) = 0
brk(0x21d9000)  = 0x21d9000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
epoll_ctl(0, EPOLL_CTL_DEL, 4, 6be6e0)  = 0
close(4)= 0
epoll_ctl(0, EPOLL_CTL_DEL, 5, 6be6e0)  = 0
close(5)= 0
epoll_ctl(0, EPOLL_CTL_DEL, 6, 6be6e0)  = 0
close(6)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, {{EPOLLIN, {u32=2, u64=2}}}, 200, 386) = 1
recvfrom(2,
"\301*\252V*\311/\310LV\262R\312HR\322QJI,IT\2622415\2664507"..., 16384, 0,
NULL, NULL) = 44
sendto(1, "\301*\252V*\311/\310LV\262R\312HR\322QJI,IT\2622415\2664507"...,
44, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 44
epoll_wait(0, {{EPOLLIN, {u32=9, 

Re: http-response redirect

[Igor Cicimov]

On 01/02/2016 8:32 AM, "Willy Tarreau"  wrote:
>
> Hi Igor,
>
> On Sun, Jan 31, 2016 at 07:39:02PM +1100, Igor Cicimov wrote:
> > Any chance for this to get back-ported into 1.5?
>
> Not at all. We don't backport features anymore into stable releases,
> we've had to deal with too many painful issues in 1.4 because of this
> bad practise. This appear to work until the first bug report where
> you discover it cannot reliably work because substantial amounts of
> core changes would have been needed, and you can't revert the change
> because users use it... So now we fix bugs and update the doc only
> in stable. And that's already a tough job :-)
>
> Best regards,
> Willy
>
Thanks Willy, that makes sense and I have already updated my staging
servers to 1.6.3 yesterday. And thanks for the great job you and your team
are doing with this fantastic piece of software.

Cheers,
Igor

Re: SSL acceleration

[Willy Tarreau]

On Sat, Jan 30, 2016 at 04:09:43PM +0100, Nenad Merdanovic wrote:
> In a decent;y sized environment getting several tens of millions
> requests per day, statistics I gathered show that there is about 85-88%
> of clients that support ECDSA. Using that and TLS keys, switching to
> full HTTPS was barely noticeable when examining the CPU usage.

I'd like to add that I tested a well-known acceleration card a few
months ago, and that RSA acceleration required a *lot* of processes
(more than 40) for the card to start to provide any benefit over
software, that the key generation latency was *much* higher than in
software, and that ECDSA was slowed down to an unusable rate around
2 or 3 keys per second. Not to mention that there were a lot of
patches to apply on top of openssl to make it barely usable, and
that prevented us from easily following openssl security updates. So
the only usage this card has is now to take space on the table in
the R lab next to the test machines.

The final point on this is that hardware doesn't follow specification
updates fast enough, and can very quickly end up being counter-productive.
I've already seen some SSL servers being limited by their hardware SSL
accelerators. CPUs are fast and cheap nowadays. Often you'd better
install a heavily multi-core CPU than waste a PCIe slot with such a
card, unless this card is extremely good and you are certain that it
can be flashed to support future algorithms efficiently.

Just my two cents,
Willy

Re: http-response redirect

[Igor Cicimov]

On Sun, Jan 31, 2016 at 7:07 PM, Willy Tarreau  wrote:

> On Sun, Jan 31, 2016 at 08:30:57AM +0100, Björn Zettergren wrote:
> > > http-response redirect code 302 location https://blabla if { status
> 404 }
> > > statement in my haproxy 1.5.15 config but on reload I get:
> >
> > If i make proper sense of the documentation; the "http-response" does
> > not support "redirect" in 1.5.
> >
> https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-http-response
> >
> > But as you noted, the source-code contain the "redirect" in list of
> > expected options. I'm no coder, so i'm not sure i read the source
> > right, but it seems like the functions for "redirect" in
> > "http-response" are not available in 1.5.15 but the errormessage
> > contain it as a possibility, and it seem to be available in 1.6.
> >
> > I suspect that this is a bug in 1.5 (either error message is wrong, or
> > the redirect-functions are not properly implemented).
>
> We implemented it very late in 1.6, I'm surprized that the keyword is
> listed in 1.5. Let me check...
>
> OK I found it, it was accidently added in 1.5-dev19 when http-response
> was introduced :  e365c0b ("MEDIUM: http: add a new "http-response"
> ruleset")
>
> This one needs to be removed from the error message.
>
> Thanks,
> Willy
>
>
Hi Willy,

Any chance for this to get back-ported into 1.5?

Cheers,
Igor

-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000

Re: http-response redirect

[Willy Tarreau]

On Sun, Jan 31, 2016 at 08:30:57AM +0100, Björn Zettergren wrote:
> > http-response redirect code 302 location https://blabla if { status 404 }
> > statement in my haproxy 1.5.15 config but on reload I get:
> 
> If i make proper sense of the documentation; the "http-response" does
> not support "redirect" in 1.5.
> https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-http-response
> 
> But as you noted, the source-code contain the "redirect" in list of
> expected options. I'm no coder, so i'm not sure i read the source
> right, but it seems like the functions for "redirect" in
> "http-response" are not available in 1.5.15 but the errormessage
> contain it as a possibility, and it seem to be available in 1.6.
> 
> I suspect that this is a bug in 1.5 (either error message is wrong, or
> the redirect-functions are not properly implemented).

We implemented it very late in 1.6, I'm surprized that the keyword is
listed in 1.5. Let me check...

OK I found it, it was accidently added in 1.5-dev19 when http-response
was introduced :  e365c0b ("MEDIUM: http: add a new "http-response" ruleset")

This one needs to be removed from the error message.

Thanks,
Willy

help

[haproxy]

Mailers SMTP authentication

[Igor Cicimov]

Hi,

Wonder if the mailers can support smtp authentication?

Thanks,
Igor

Re: SSL acceleration

[Eric Chan]

Thanks Willy.

We also see very bad performance with HW acceleration (but better than what you 
said).
We attribute it to the fact that we can launch only 1 operation at a time in 
synchronous manner coupled with the high latency of getting data in and out of 
the VMs.
That is why we hope to enable asynchronous mode so we can launch multiple 
operations simultaneously to the HW and get much better overall throughput 
despite the latency problem.

Thanks,
Eric

Sent from my iPhone

> On Jan 31, 2016, at 12:16 AM, Willy Tarreau  wrote:
>
>> On Sat, Jan 30, 2016 at 04:09:43PM +0100, Nenad Merdanovic wrote:
>> In a decent;y sized environment getting several tens of millions
>> requests per day, statistics I gathered show that there is about 85-88%
>> of clients that support ECDSA. Using that and TLS keys, switching to
>> full HTTPS was barely noticeable when examining the CPU usage.
>
> I'd like to add that I tested a well-known acceleration card a few
> months ago, and that RSA acceleration required a *lot* of processes
> (more than 40) for the card to start to provide any benefit over
> software, that the key generation latency was *much* higher than in
> software, and that ECDSA was slowed down to an unusable rate around
> 2 or 3 keys per second. Not to mention that there were a lot of
> patches to apply on top of openssl to make it barely usable, and
> that prevented us from easily following openssl security updates. So
> the only usage this card has is now to take space on the table in
> the R lab next to the test machines.
>
> The final point on this is that hardware doesn't follow specification
> updates fast enough, and can very quickly end up being counter-productive.
> I've already seen some SSL servers being limited by their hardware SSL
> accelerators. CPUs are fast and cheap nowadays. Often you'd better
> install a heavily multi-core CPU than waste a PCIe slot with such a
> card, unless this card is extremely good and you are certain that it
> can be flashed to support future algorithms efficiently.
>
> Just my two cents,
> Willy
>
>
This email and any attachments thereto may contain private, confidential, 
and/or privileged material for the sole use of the intended recipient. Any 
review, copying, or distribution of this email (or any attachments thereto) by 
others is strictly prohibited. If you are not the intended recipient, please 
contact the sender immediately and permanently delete the original and any 
copies of this email and any attachments thereto.

Restituez la propreté de l'air de votre maison avec le purificateur d'air ionique Puripod

[Le PRO du net]