Hi,
does anyone know a way to disable 3DES ciphers only on tls version >= 1.1 ?
Regards,
Hi,
here is the idea :
[...]
ExecReload=
ExecReload=/bin/kill -USR2 $MAINPID
[...]
not the sexiest solution but it do the job and I never got the problem
anymore ;)
2016-10-24 17:43 GMT+02:00 Pierre Cheynier :
>> A solution I use is to delay next reload in systemd unit
Hi,
I had similar issues when reloading haproxy with lot of ssl (long to fork).
A solution I use is to delay next reload in systemd unit until a
reload is in progress.
2016-10-24 17:06 GMT+02:00 Willy Tarreau :
> On Mon, Oct 24, 2016 at 01:09:59PM +, Pierre Cheynier wrote:
>> >
It would be great : tons of ssl that make haproxy very long to
start/restart/reload.
2016-10-11 10:04 GMT+02:00 Thierry Fournier :
> Hi list,
>
> I have for projet to write a dynamic update of the SSL certificates. I
> encountered some cases where haproxy deals with many
# ls /srv/178/ssl/ | wc -l
85192
2016-07-07 16:38 GMT+02:00 Beluc <belu...@gmail.com>:
> Hi,
>
> when issuing SIGUSR2 to haproxy systemd wrapper configured with lot
> of ssl certificate two times , I got "unknown/zombie" haproxy
> processes aka haproxy that
Hi,
when issuing SIGUSR2 to haproxy systemd wrapper configured with lot
of ssl certificate two times , I got "unknown/zombie" haproxy
processes aka haproxy that did not and will never received SIGUSR1
signal (and will keep going listening until server reboot or manual
fix) because theirs pid
Hi, speaking of conf check, we recently had issue because socket
bind-ability is not checked using "-c" parameter. So systemd was reload
looping.
Regards.
Le 8 juin 2016 9:43 PM, "Maxime de Roucy" a
écrit :
> Le mercredi 08 juin 2016 à 21:21 +0200, Vincent Bernat a
ng out (or entirely-procedurally-generating) your HAproxy config
> file is a must once you exceed the bare minimum of complexity. :-)
>
> Best of luck!
>
> On Tue, Mar 22, 2016 at 3:16 AM, Beluc <belu...@gmail.com> wrote:
>>
>> well, it's can become a real mess with lot of ser
>
> backend my_be
> mode tcp
> server server1_src1 10.1.0.1 source 10.0.0.1
> server server1_src2 10.1.0.1 source 10.0.0.2
> server server2_src1 10.1.0.2 source 10.0.0.1
> server server2_src2 10.1.0.2 source 10.0.0.2
>
> On Mon, Mar 21, 2016 at 8:20
Hi,
We're trying to find a way to have multiple sources per server and
thus bypass 64k connections per server.
We already tried with SNAT iptables :
iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to 10.0.0.1-10.0.10
without success because kernel is hashing real source ip and real
destination
Hi,
well, i finally find the problem : I was using bad CAfile (good one is
/etc/ssl/certs/GlobalSign_Root_CA.pem)
damned openssl that did not tell anything :(
Regards,
2016-02-10 17:26 GMT+01:00 Beluc <belu...@gmail.com>:
> It's working, server is UP.
>
> 2016-02-10 17:21 GMT
Hi,
I can't find out why ssl check is not working while openssl return is ok.
global
ssl-default-bind-ciphers
kEECDH+aECDSA+AES:kEECDH+aRSA+AES:kRSA+AES:+AES256:!kEDH:!LOW:!EXP:!MD5:!RC4:!aNULL:!eNULL
backend ABC
mode http
server 1.2.3.4 1.2.3.4:443 check ssl verify required ca-file
It's working, server is UP.
2016-02-10 17:21 GMT+01:00 Baptiste <bed...@gmail.com>:
> On Wed, Feb 10, 2016 at 5:11 PM, Beluc <belu...@gmail.com> wrote:
>> Hi,
>>
>> I can't find out why ssl check is not working while openssl return is ok.
>>
>> glo
Hi,
I have few questions about that :
is that annoying to do fs i/o in a core.register_task ? I read that
everywhere else, it's not recommended but here, I'm not sure ...
second question, I cannot find out how to retrieve backends and
servers status (UP or DOWN) in core.register_task. is that
Hi,
Thank you for answering !
Le 8 févr. 2016 9:05 PM, "Thierry FOURNIER" <thierry.fourn...@arpalert.org>
a écrit :
>
> On Mon, 8 Feb 2016 18:36:38 +0100
> Beluc <belu...@gmail.com> wrote:
>
> > Hi,
> >
> > I have few question
16 matches
Mail list logo