subscribe

[Beluc]

3DES & TLS

[Beluc]

Hi,

does anyone know a way to disable 3DES ciphers only on tls version >= 1.1 ?

Regards,

Re: HAProxy reloads lets old and outdated processes

[Beluc]

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 until a
>> reload is in progress.
>
> Unfortunately, even when doing this you can end up in the situation described 
> before, because for systemd a reload is basically a SIGUSR2 to send. You do 
> not wait for some callback saying "I'm now OK and fully reloaded" (if I'm 
> wrong, I could be interested in your systemd setup).
>
> I naively tried such approach by adding a grace period of 2s (sleep) and 
> avoid to send another reload during that period, but at some point you'll 
> encounter the same issue when upstream contention will be higher (meaning 
> that you'll have ton of things to reload, you'll then add delay and decrease 
> real-time aspect of your solution etc etc).

Re: HAProxy reloads lets old and outdated processes

[Beluc]

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:
>> > Same for all of them. Very interesting, SIGUSR2 (12) is set
>> > in SigIgn :-)  One question is "why", but at least we know we
>> > have a workaround consisiting in unblocking these signals in
>> > haproxy-systemd-wrapper, as we did in haproxy.
>>
>> > Care to retry with the attached patch ?
>>
>> Same behaviour.
>>
>> SigIgn is still 1000 (which is probably normal, I assume the 
>> goal was to ignore that).
>
> No, the goal was to ensure we don't block anything. I was a bit quicky at
> copy-pasting it from haproxy before going to a meeting, I can recheck, but
> there's something odd here.
>
> Willy
>

Re: Cetrtificates dynamic update

[Beluc]

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 websites, and it
> should ne great if we can replace / add certificate without restarting
> HAProxy.
>
> I'm looking for some opinions or advices.
>
> I need to:
>
>  - list the currently loaded certificates ID (embedding ECDSA).
>
>  - add or replace certificates embedding the 3 certificates version
>RSA/DSA/ECDSA and the sni filter.
>
>  - Delete SNI entries (and the certificates if it is the last one)
>
> For the listing of the certificate, I need to scan the content of  the
> OpenSSL SSL_CTX and extract the certificates ID. It seems impossible,
> Openssl not seems to give method fo doing this. So I proposed to
> memorize the certificates ID when each certificate is added in a
> SSL_CTX.
>
> For the list:
>
>show ssl [proxy/listener]
>
> This command lst all certificates by SNI for a listener. If the
> proxy/listener is not precised, the command list availables proxy, and
> listeners.
>
>
> For the replacement or update, I propose some CLI commands like this:
>
>set ssl certificate begin proxy/listener [sni filters]
>
> This commande creates a new SSL context will be filled with the
> following commands. If a previous context exists it is destroyed. This
> is incompatible with concurrent access to the cli.
>
>set ssl certificate (any|rsa|ecdsa|dsa)
>
>EOF
>
> The difficulty is to mark the end of the certificate, so I propose to
> mark en end with the string "\nEOF\n".
>
>set ssl certificate commit
>
> This command validates, install new certificates and remove old
> certificates.
>
>
> And finaly this command destroy existing certificate:
>
>del ssl certificate proxy/listener id
>
> Any ideas or comments ?
>
> Thanks
> Thierry
>
> --
> Thierry Fournier
> m: +33 6 68 69 21 85  | e: thierry.fourn...@ozon.io
> w: http://www.ozon.io/| b: http://blog.ozon.io/
>

Re: haproxy systemd wrapper && SIGUSR2

[Beluc]

# 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 did not and will never received SIGUSR1
> signal (and will keep going listening until server reboot or manual
> fix) because theirs pid were overwritten by second reload sons (here
> 73185 & 73187) :
>
> # ps auxwwf | grep /178/
> root  81178  0.0  0.0   4216  1240 ?Ss   Jul04   0:00
> /usr/sbin/haproxy-systemd-wrapper -f /srv/178/haproxy.cfg -p
> /srv/178/haproxy.pid -L 178
> haproxy   72071  8.0  1.3 3639044 3604856 ? S16:08   1:36  \_
> /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid -L
> 178 -Ds -sf 126588 126589
> haproxy   73185  9.6  1.3 3667888 3622752 ? Ss   16:10   1:46  |
> \_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
> -L 178 -Ds -sf 126588 126589
> haproxy   73187 13.5  1.3 3677504 3631228 ? Ss   16:10   2:29  |
> \_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
> -L 178 -Ds -sf 126588 126589
> haproxy   72244  8.1  1.3 3639044 3604692 ? S16:09   1:37  \_
> /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid -L
> 178 -Ds -sf 126588 126589
> haproxy   73205  9.6  1.3 3668912 3622984 ? Rs   16:10   1:46
> \_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
> -L 178 -Ds -sf 126588 126589
> haproxy   73206 13.5  1.3 3676512 3629092 ? Ss   16:10   2:28
> \_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
> -L 178 -Ds -sf 126588 126589
>
> # cat /srv/178/haproxy.pid
> 73205
> 73206
>
> # haproxy -vv
> HA-Proxy version 1.6.5 2016/05/10
> Copyright 2000-2016 Willy Tarreau <wi...@haproxy.org>
>
> Build options :
>   TARGET  = linux2628
>   CPU = native
>   CC  = gcc
>   CFLAGS  = -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2
>   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_STATIC_PCRE=1
> USE_PCRE_JIT=1 USE_TFO=1
>
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Encrypted password support via crypt(3): yes
> Built with zlib version : 1.2.8
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with OpenSSL version : OpenSSL 1.0.1k 8 Jan 2015
> Running on OpenSSL version : OpenSSL 1.0.1k 8 Jan 2015
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports prefer-server-ciphers : yes
> Built with PCRE version : 8.35 2014-04-04
> PCRE library supports JIT : yes
> Built with Lua version : Lua 5.3.1
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
>
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
>
> Regards,

haproxy systemd wrapper && SIGUSR2

[Beluc]

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 were overwritten by second reload sons (here
73185 & 73187) :

# ps auxwwf | grep /178/
root  81178  0.0  0.0   4216  1240 ?Ss   Jul04   0:00
/usr/sbin/haproxy-systemd-wrapper -f /srv/178/haproxy.cfg -p
/srv/178/haproxy.pid -L 178
haproxy   72071  8.0  1.3 3639044 3604856 ? S16:08   1:36  \_
/usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid -L
178 -Ds -sf 126588 126589
haproxy   73185  9.6  1.3 3667888 3622752 ? Ss   16:10   1:46  |
\_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
-L 178 -Ds -sf 126588 126589
haproxy   73187 13.5  1.3 3677504 3631228 ? Ss   16:10   2:29  |
\_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
-L 178 -Ds -sf 126588 126589
haproxy   72244  8.1  1.3 3639044 3604692 ? S16:09   1:37  \_
/usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid -L
178 -Ds -sf 126588 126589
haproxy   73205  9.6  1.3 3668912 3622984 ? Rs   16:10   1:46
\_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
-L 178 -Ds -sf 126588 126589
haproxy   73206 13.5  1.3 3676512 3629092 ? Ss   16:10   2:28
\_ /usr/sbin/haproxy -f /srv/178/haproxy.cfg -p /srv/178/haproxy.pid
-L 178 -Ds -sf 126588 126589

# cat /srv/178/haproxy.pid
73205
73206

# haproxy -vv
HA-Proxy version 1.6.5 2016/05/10
Copyright 2000-2016 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = native
  CC  = gcc
  CFLAGS  = -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_STATIC_PCRE=1
USE_PCRE_JIT=1 USE_TFO=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.1k 8 Jan 2015
Running on OpenSSL version : OpenSSL 1.0.1k 8 Jan 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.35 2014-04-04
PCRE library supports JIT : yes
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Regards,

Re: Graceful restart of Haproxy with SystemD

[Beluc]

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 écrit :
> > Just add ExecReload=/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -c
> > -q
> > before the existing ExecReload.
>
> Indeed:
>
> [root@arch64-f5ff6f8ea5472b3f ~]# rm /tmp/*
> rm: cannot remove '/tmp/*': No such file or directory
> [root@arch64-f5ff6f8ea5472b3f ~]# systemctl cat test.service
> # /etc/systemd/system/test.service
> [Unit]
> Description=test
>
> [Service]
> Type=simple
> ExecStart=/usr/bin/sleep 3600
> ExecReload=/usr/bin/touch /tmp/ExecReload1
> ExecReload=/usr/bin/touch /tmp/ExecReload2
> [root@arch64-f5ff6f8ea5472b3f ~]# systemctl start test.service
> [root@arch64-f5ff6f8ea5472b3f ~]# systemctl reload test.service
> [root@arch64-f5ff6f8ea5472b3f ~]# ls /tmp/
> ExecReload1  ExecReload2
>
> Also you will not be able to change the commande line argument (e.g.
> adding a file with `-f …`) of the haproxy process with `systemctl
> reload`.
> But you can now load a directory with `-f`, add files in it and load
> them (without service interruption) with a reload.
>
> http://git.haproxy.org/?p=haproxy.git;a=commit;h=379d9c7c14e684ab1dcdb6467a6bf189153c2b1d
>
> Regards
> Maxime de Roucy

Re: servers multiple sources

[Beluc]

Hi,
@James Brown : sure ;)

I configure a server to use source a.b.c.d:1-6 and I got
"Connect() failed for backend abcd: no free ports."

Maybe a problem with kernel I use ...

Regards,

2016-03-22 18:45 GMT+01:00 James Brown <jbr...@easypost.com>:
> Templating 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 server and source :)
>> but sure, it works !
>>
>> 2016-03-21 19:21 GMT+01:00 James Brown <jbr...@easypost.com>:
>> > Why not just add each server multiple times with a different src
>> > parameter
>> > and a different name.
>> >
>> > Something like
>> >
>> > 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 AM, Beluc <belu...@gmail.com> wrote:
>> >>
>> >> 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 ip, so only one source ip nated is used (aka same as using
>> >> one different source per server).
>> >>
>> >> Any idea on achieving this ? maybe in lua ?
>> >>
>> >> Regards,
>> >>
>> >
>> >
>> >
>> > --
>> > James Brown
>> > Engineer
>
>
>
>
> --
> James Brown
> Engineer

Re: servers multiple sources

[Beluc]

well, it's can become a real mess with lot of server and source :)
but sure, it works !

2016-03-21 19:21 GMT+01:00 James Brown <jbr...@easypost.com>:
> Why not just add each server multiple times with a different src parameter
> and a different name.
>
> Something like
>
> 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 AM, Beluc <belu...@gmail.com> wrote:
>>
>> 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 ip, so only one source ip nated is used (aka same as using
>> one different source per server).
>>
>> Any idea on achieving this ? maybe in lua ?
>>
>> Regards,
>>
>
>
>
> --
> James Brown
> Engineer

servers multiple sources

[Beluc]

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 ip, so only one source ip nated is used (aka same as using
one different source per server).

Any idea on achieving this ? maybe in lua ?

Regards,

Re: check ssl

[Beluc]

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+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.
>>>
>>> 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
>>> /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem
>>>
>>>
>>> # echo Q | openssl s_client -connect 1.2.3.4:443 -CAfile
>>> /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem -cipher
>>> 'kEECDH+aECDSA+AES:kEECDH+aRSA+AES:kRSA+AES:+AES256:!kEDH:!LOW:!EXP:!MD5:!RC4:!aNULL:!eNULL'
>>> CONNECTED(0003)
>>> depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
>>> verify return:1
>>> depth=1 O = AlphaSSL, CN = AlphaSSL CA - G2
>>> verify return:1
>>> depth=0 C = FR, OU = Domain Control Validated, CN = sslABC
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:/C=FR/OU=Domain Control Validated/CN=sslABC
>>>i:/O=AlphaSSL/CN=AlphaSSL CA - G2
>>>  1 s:/O=AlphaSSL/CN=AlphaSSL CA - G2
>>>i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>>>  2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>>>i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>>> ---
>>> Server certificate
>>> -BEGIN CERTIFICATE-
>>> [...]
>>> -END CERTIFICATE-
>>> subject=/C=FR/OU=Domain Control Validated/CN=sslABC
>>> issuer=/O=AlphaSSL/CN=AlphaSSL CA - G2
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 3289 bytes and written 523 bytes
>>> ---
>>> New, TLSv1/SSLv3, Cipher is AES256-SHA
>>> Server public key is 2048 bit
>>> Secure Renegotiation IS supported
>>> Compression: NONE
>>> Expansion: NONE
>>> SSL-Session:
>>> Protocol  : TLSv1
>>> Cipher: AES256-SHA
>>> Session-ID:
>>> Session-ID-ctx:
>>> Master-Key: [...]
>>> Key-Arg   : None
>>> PSK identity: None
>>> PSK identity hint: None
>>> SRP username: None
>>> Start Time: 1455120471
>>> Timeout   : 300 (sec)
>>> Verify return code: 0 (ok)
>>> ---
>>> DONE
>>>
>>> I also forced tlsv1 use without success.
>>>
>>> Did I miss something ?
>>>
>>> Regards
>>>
>>
>> What happens when you use "verify none" ?
>>
>> Baptiste

check ssl

[Beluc]

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
/etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem


# echo Q | openssl s_client -connect 1.2.3.4:443 -CAfile
/etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem -cipher
'kEECDH+aECDSA+AES:kEECDH+aRSA+AES:kRSA+AES:+AES256:!kEDH:!LOW:!EXP:!MD5:!RC4:!aNULL:!eNULL'
CONNECTED(0003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 O = AlphaSSL, CN = AlphaSSL CA - G2
verify return:1
depth=0 C = FR, OU = Domain Control Validated, CN = sslABC
verify return:1
---
Certificate chain
 0 s:/C=FR/OU=Domain Control Validated/CN=sslABC
   i:/O=AlphaSSL/CN=AlphaSSL CA - G2
 1 s:/O=AlphaSSL/CN=AlphaSSL CA - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-
subject=/C=FR/OU=Domain Control Validated/CN=sslABC
issuer=/O=AlphaSSL/CN=AlphaSSL CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 3289 bytes and written 523 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: [...]
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1455120471
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
DONE

I also forced tlsv1 use without success.

Did I miss something ?

Regards

Re: check ssl

[Beluc]

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.
>>
>> 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
>> /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem
>>
>>
>> # echo Q | openssl s_client -connect 1.2.3.4:443 -CAfile
>> /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem -cipher
>> 'kEECDH+aECDSA+AES:kEECDH+aRSA+AES:kRSA+AES:+AES256:!kEDH:!LOW:!EXP:!MD5:!RC4:!aNULL:!eNULL'
>> CONNECTED(0003)
>> depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
>> verify return:1
>> depth=1 O = AlphaSSL, CN = AlphaSSL CA - G2
>> verify return:1
>> depth=0 C = FR, OU = Domain Control Validated, CN = sslABC
>> verify return:1
>> ---
>> Certificate chain
>>  0 s:/C=FR/OU=Domain Control Validated/CN=sslABC
>>i:/O=AlphaSSL/CN=AlphaSSL CA - G2
>>  1 s:/O=AlphaSSL/CN=AlphaSSL CA - G2
>>i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>>  2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>>i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
>> ---
>> Server certificate
>> -BEGIN CERTIFICATE-
>> [...]
>> -END CERTIFICATE-
>> subject=/C=FR/OU=Domain Control Validated/CN=sslABC
>> issuer=/O=AlphaSSL/CN=AlphaSSL CA - G2
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 3289 bytes and written 523 bytes
>> ---
>> New, TLSv1/SSLv3, Cipher is AES256-SHA
>> Server public key is 2048 bit
>> Secure Renegotiation IS supported
>> Compression: NONE
>> Expansion: NONE
>> SSL-Session:
>> Protocol  : TLSv1
>> Cipher: AES256-SHA
>> Session-ID:
>> Session-ID-ctx:
>> Master-Key: [...]
>> Key-Arg   : None
>> PSK identity: None
>> PSK identity hint: None
>> SRP username: None
>> Start Time: 1455120471
>> Timeout   : 300 (sec)
>> Verify return code: 0 (ok)
>> ---
>> DONE
>>
>> I also forced tlsv1 use without success.
>>
>> Did I miss something ?
>>
>> Regards
>>
>
> What happens when you use "verify none" ?
>
> Baptiste

lua core.register_task

[Beluc]

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 possible ?
any idea ?

Regards,

Re: lua core.register_task

[Beluc]

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 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 ...
>
>
> Hello,
>
> I confirm: it is not recommended also in tasks. The tasks executions
> are scheduled between the I/O access, so we cannot not block the
> process.

What about SQLite access ? Acceptable or better do it with redis for
example ?

>
>
> > second question, I cannot find out how to retrieve backends and
> > servers status (UP or DOWN) in core.register_task. is that possible ?
> > any idea ?
>
>
> Its not possible for the moment. I hope to find any time to do this in
> the next HAProxy version.

Great !
I managed to access haproxy socket using core.tcp for now. Is that
acceptable too or better do this using http stats socket ?

Regards,

>
>
> Thierry