subscribe
3DES & TLS
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
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
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: SSL patches
Hi, I applied your patchs and then launch haproxy with this minimal conf : global tune.ssl.default-dh-param 4096 defaults timeout check 10s timeout client 180s timeout connect 2s timeout http-keep-alive 15s timeout http-request 10s timeout queue 60s timeout server 180s timeout tarpit 10s timeout tunnel 600s listen tmp bind 127.0.0.1:8443 ssl crt tmp/ssl strict-sni redirect location https://www.google.fr and test all mode : $ openssl s_client -connect 127.0.0.1:8443 -CApath /etc/ssl/certs -servername dsa.toto.fr 2>/dev/null | openssl x509 -noout -text | grep "Public Key Algorithm:" Public Key Algorithm: dsaEncryption $ openssl s_client -connect 127.0.0.1:8443 -CApath /etc/ssl/certs -servername ec.toto.fr 2>/dev/null | openssl x509 -noout -text | grep "Public Key Algorithm:" Public Key Algorithm: id-ecPublicKey $ openssl s_client -connect 127.0.0.1:8443 -CApath /etc/ssl/certs -servername rsa.toto.fr 2>/dev/null | openssl x509 -noout -text | grep "Public Key Algorithm:" Public Key Algorithm: rsaEncryption is that enough for you ? Regards, 2016-10-23 14:49 GMT+02:00 Thierry Fournier : > Hi list, > > I'm currently workibng on dynamic load of certificates, and I see somme > minor bug. There are a few Patches. > > The first of them add some useful traces for debuging SSL > (typically explain the reason of an handshake failure). > > The second and the third are 2 minor bug with return code not > controlled. > > The fourth is the main patch. It remove some entries tore twice in the > SNI tree. This bug is really minor. > > I valid my patches with a classic single certificate, and with dual > certificate (DSA/RSA). I can't test dual or three certificates with > ECDSA. > > My patches can be applied on the current master branch, and there > are easy to apply on the 1.6 branch. > > Anyone can test the mode DSA + RSA + ECDSA ? > > Thanks > Thierry
Re: Cetrtificates dynamic update
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
# ls /srv/178/ssl/ | wc -l 85192 2016-07-07 16:38 GMT+02:00 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,
haproxy systemd wrapper && SIGUSR2
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
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
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 : > 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 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 : >> > 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 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
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 : > 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 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
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
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 : > It's working, server is UP. > > 2016-02-10 17:21 GMT+01:00 Baptiste : >> On Wed, Feb 10, 2016 at 5:11 PM, Beluc 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
Re: check ssl
It's working, server is UP. 2016-02-10 17:21 GMT+01:00 Baptiste : > On Wed, Feb 10, 2016 at 5:11 PM, Beluc 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
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: lua core.register_task
Hi, Thank you for answering ! Le 8 févr. 2016 9:05 PM, "Thierry FOURNIER" a écrit : > > On Mon, 8 Feb 2016 18:36:38 +0100 > Beluc 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
lua core.register_task
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,