Re: UP 2/3 status
How many server elements does the backend have? That sounds like 2 out of 3 of my servers are up to me. -Robin On Sat, Sep 28, 2013 at 03:37:43AM +0200, Mark Ruys wrote: Hi, I'm using a Nagios plugin to monitor the HAProxy status. Now and then, HAProxy reports UP 2/3 as a backend status in the statistics. I wonder, what does 2/3 mean? Mark Ruys --- dr M.P.J. Ruys (PhD) ::Peercode Oudenhof 4c, 4191NW Geldermalsen, The Netherlands Web site and travel directions: www.peercode.nl Phone +31.88.0084124 :: Mobile +31.6.51298623
Re: Please help to configure Haproxy with SSL support
As a starting point, the short version is: have an haproxy that supports ssl like so: [rlpowell@mtsinai01 ~]$ /opt/haproxy/usr/local/sbin/haproxy -vv | grep -i ssl OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Built with OpenSSL version : OpenSSL 1.0.1c 10 May 2012 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes and use a config line like this: bind 192.168.0.1:443 ssl crt /etc/haproxy/cert.pem ca-file /path/to/bundle.crt I actually started with http://blog.exceliance.fr/2012/09/10/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound/ , but that's out of date; the sni options have changed. Lukas is correct, though, in that configuring haproxy is a rather intense project; you probably should let someone else do it if you're not willing to read at least tens of pages of documentation, and possibly much more. -Robin On Thu, Mar 21, 2013 at 03:27:34PM +0100, Lukas Tribus wrote: SSL is possible in the 1.5 development branch only. You can find all the necessary informations on the website http://haproxy.1wt.eu/ If you need someone guiding you step by step trough the configuration, I would suggest you acquire commercial support: http://www.exceliance.fr/en/haproxy-professional-services Lukas Date: Thu, 21 Mar 2013 19:35:37 +0530 Subject: Please help to configure Haproxy with SSL support From: ram.eas...@gmail.com To: haproxy@formilux.org Dear Team, We are trying to load balance two app servers running on tomcat with ssl enabled using HAPROXY , but we couldn’t find proper resources to configure the same Please share us the steps to configure the same which will help us a lot Thank you..! Regards, Eswar
Re: Please help to configure Haproxy with SSL support
On Thu, Mar 21, 2013 at 08:02:03PM +0100, Baptiste wrote: I actually started with http://blog.exceliance.fr/2012/09/10/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound/ , but that's out of date; the sni options have changed. Hi Robin I fixed the article today. :D Thanks so much! -Robin
Re: Default certificate wrongly delivered.
Are you *only* selecting based on SNI? I ask because our setup uses cookies as well, specifically to get around SNI issues (we store the cookie on normal HTTP as well as HTTPS, and use it as a fallback if SNI fails). If you have other things going on besides SNI, that could explain that behaviour. -Robin On Fri, Feb 22, 2013 at 01:20:12PM +0100, Kenneth Mutka wrote: Hi, As I mentioned in my original email - The problem is intermittent, i.e. it works sometimes and other times not. And I do not mean with different clients - A page refresh is sufficient for HAProxy to return the correct certificate. All clients that connect use TLS1.1 and have support for SNI. On Fri, Feb 22, 2013 at 1:15 PM, Jonathan Matthews cont...@jpluscplusm.comwrote: On 22 February 2013 08:29, Kenneth Mutka slay...@gmail.com wrote: Hi, I'm having a bit of a problem with my certificates. I have about 15 separate certificates, including the default one. Apart from listening to 443, I also have a bunch of regular HTTP sites. Now, obviously I am using the SNI features here and most of the time it works just as intended, but every now and then, highly intermittently, the default certificate is being handed out instead of the correct one. Not all HTTP clients support SNI. I would strongly suspect you're handing out the default cert to clients that don't provide SNI hints. Other than moving to IP-per-SSL-site, I don't believe there's anything you can do to avoid this when you don't control the clients. Jonathan -- Jonathan Matthews // Oxford, London, UK http://www.jpluscplusm.com/contact.html
Re: installing SSL, and backend communication is non-ssl
On Thu, Feb 07, 2013 at 11:54:56AM -0500, S Ahmed wrote: Is it hard to install SSL with haproxy? I want all incoming connections to use SSL, but when haproxy communicates with the backends I don't want them to be ssl based. ANy tutorials on setting this up? With 1.5-dev17 (or whatever's the latest) that's fairly easy. Here's a config snippet. The :::443 thing is to make it bind to ipv6, which *:443 doesn't. The cert file has to be all the relevant certs concatenated; see the docs for more info. # Listen for ssl requests # 443, but get passed on to http-based ports for Apache listen https balance roundrobin mode http option http-server-close option forwardfor option httpchk HEAD /cytobank/images/logo_bigger.gif bind :::443 ssl crt /opt/haproxy/etc/wildcard.cert default_backend https_apache_localhost backend https_apache_localhost server server_0 localhost:83 check inter 3000 rise 1 fall 1 error-limit 1 on-error mark-down -Robin
Re: Backend Configuration Templating
This is what we do, using puppet's erb templating system:
% haproxy_https_servers.keys.each do |server| %
% haproxy_https_servers[server].each do |subserver| %
% extra_conditions=''
if subserver.has_key?('extra_conditions')
extra_conditions=subserver['extra_conditions']
end %
# content switching based on cookie, having had them set in
previous sessions
use_backend %= server %-https-%= subserver['name'] % if {
hdr_sub(cookie) SITE=%= server % } %= extra_conditions %
# content switching based on SNI
use_backend %= server %-https-%= subserver['name'] % if {
ssl_fc_sni -i %= server % } %= extra_conditions %
% end %
% end %
-Robin
On Tue, Feb 05, 2013 at 02:53:13PM -0700, William Attwood wrote:
I would imagine you would dynamically create the haproxy configuration
based on the sources you're using to fill your variables. I'll be doing
something similar, soon, where the configuration is dynamically built based
on entries in a database.
Thank you,
William Attwood
System Engineer, Co-Founder
Open Box I.T. Solutions, LLC
c. 801-634-6479
On Tue, Feb 5, 2013 at 2:50 PM, Joel Krauska jkrau...@gmail.com wrote:
I know there's been some pushback about adding 'include' support in to
haproxy config files.
One of the main reasons I would like that feature is to allow for more
dynamic configs.
I've come to wonder if some templating/loops couldn't be built in to the
haproxy config parser itself.
eg.
backend foo
# List of servers
%
for (var i=1;i8;i++)
{server app-$i app-$1:8080 maxconn 255 weight 10}
%
Any other interest in seeing this?
I imagine there are standardized approaches for doing this sort of thing.
--Joel
Trick: Sneaky workaround for SNI
Just something I thought the rest of the interwebs might find
useful.
If you can get your users to first connect to an http:// address,
and then have that URL redirect them to https://, you can work
around a lack of SNI support on the client end like so:
# content switching based on host name
use_backend dvs-staging.cytobank.org-http if { hdr(host) -i
dvs-staging.cytobank.org }
backend dvs-staging.cytobank.org-http
cookie SITE insert
server server_1 2607:f700:2bff:bb:225:90ff:fe6c:3308:82 cookie
dvs-staging.cytobank.org check inter 3000 rise 1 fall 1 error-limit 1 on-error
mark-down
[snip]
# content switching based on cookie, having had them set in previous sessions
use_backend dvs-staging.cytobank.org-https-apache if { hdr_sub(cookie)
SITE=dvs-staging.cytobank.org }
# content switching based on SNI
use_backend dvs-staging.cytobank.org-https-apache if { ssl_fc_sni -i
dvs-staging.cytobank.org }
backend dvs-staging.cytobank.org-https-apache
cookie SITE insert
server server_1 2607:f700:2bff:bb:225:90ff:fe6c:3308:83 cookie
dvs-staging.cytobank.org check inter 3000 rise 1 fall 1 error-limit 1 on-error
mark-down
So whenever dvs-staging is reached, the cookie is set, and we fall
back to SNI if we don't have that cookie. If the same user might be
going to more than one host, then you'd want to prefer SNI to the
cookie, but that isn't the case for use, so we prefer the cookie for
speed (I'm assuming a cookie check is faster than SNI, based on zero
research; I could certainly be wrong).
-Robin
Re: Problems with sni and big connections.
[reordered] On Fri, Jan 11, 2013 at 07:14:05PM +0100, Lukas Tribus wrote: If you are running -dev, its probably a good idea to follow the mailing list closely and eventually read the commit message on git. It's hard because I only give one day a week to this company, but I'll see what I can do; thanks for the warning. Its this line in the changelog: BUG/MEDIUM: stream interface: fix possible stalls during transfers The changelog comes from the commit line, but that line explains the fix itself, not the possible symptoms of the bug it addresses. To understand all the details of a change, I suggest your read the commit message [1]. [1] http://haproxy.1wt.eu/git?p=haproxy.git;a=commit;h=ca00fbcb91165e5d8d64ba7b53000ffac77f44c9 That sounds like an intermittent sort of thing; it also doesn't sound tied to the acl choices. What I'm seeing is that this happens *every* time with *every* user if the sni acl is used, and never with any user if it isn't. Having said that, I know nothing whatsoever about haproxy internals, so I'll try dev17 and let you know. :) -Robin
Re: Problems with sni and big connections.
On Fri, Jan 11, 2013 at 10:36:43PM +0100, Willy Tarreau wrote: Hi Robin, On Fri, Jan 11, 2013 at 11:10:06AM -0800, Robin Lee Powell wrote: [reordered] On Fri, Jan 11, 2013 at 07:14:05PM +0100, Lukas Tribus wrote: If you are running -dev, its probably a good idea to follow the mailing list closely and eventually read the commit message on git. It's hard because I only give one day a week to this company, but I'll see what I can do; thanks for the warning. Yes indeed, people running -dev should subscribe to the list. You'll get some spam, so use a dedicated folder for this and you'll be fine. If you don't have time, only read the announces, the mails that seem to discuss concerns related to yours, and the very long threads which generally indicate a hard to reproduce bug. Most other posts are assistance and suggestions you probably don't care about for one day a week ! If following the list is too hard at this rhythm, maybe you'd better avoid -dev instead. Well, we really need SNI, and all the other routes to it suck, so, I guess I'll keep up with the list. :) Love the product, by the way. -Robin
Re: Problems with sni and big connections.
On Fri, Jan 11, 2013 at 10:36:43PM +0100, Willy Tarreau wrote: Indeed, there were multiple bugs with the POST issue, each one hiding another. For Sander (the reporter), the problem was very reproducible, while I could never get it. I suspect you're hitting the same one. Note that the fix above was finally not the last one, but all were merged in dev17. A few minor bugs were fixed since, all of them are fine in haproxy-ss-20130108.tar.gz. So you may use this one instead to get rid of any possible known issue. It works! \o/ Go you all! -Robin
Problems with sni and big connections.
Context: SSL stuff, haproxy HA-Proxy version 1.5-dev15 2012/12/12 ;
complete haproxy info at the bottom.
Our app does large file uploads via an ancillary java applet thingy;
these look like so:
0009:https.accept(0006)=000f from [64.236.139.254:35763]
0009:https.clireq[000f:]: POST /cytobank/uploadServlet HTTP/1.1
0009:https.clihdr[000f:]: User-Agent: Cytobank Upload
0009:https.clihdr[000f:]: Content-Type: multipart/form-data;
boundary=756zrpPEjQyIs1KS9cHjGzvox7mMfeCZR0
0009:https.clihdr[000f:]: Cache-Control: no-cache
0009:https.clihdr[000f:]: Pragma: no-cache
0009:https.clihdr[000f:]: Host: dvs-staging.cytobank.org
0009:https.clihdr[000f:]: Accept: text/html, image/gif, image/jpeg, *;
q=.2, */*; q=.2
0009:https.clihdr[000f:]: Connection: keep-alive
0009:https.clihdr[000f:]: Content-Length: 6451523
0009:https.clihdr[000f:]: Cookie:
__utma=51498683.1371821700.1307729573.1357763653.1357770695.223;
__utmz=51498683.1348737696.200.4.utmcsr=localhost|utmccn=(referral)|utmcmd=referral|utmcct=/cytobank/subscriptions/subscribe;
__utma=20047853.812597310.1357601503.1357799042.1357864337.4;
__utmz=20047853.1357601503.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=20047853.32.10.1357864337; __utmc=20047853; openid_provider=Google;
user_credentials=ff9ed09a5a08f5103cdce0bcf9c7eda9d9bcee3e2e5a392b0e0b066780f5cfdb2a505a8bdd17d505057b751b20a96989ed61f6435a057d751958f034c095be50%3A%3A2
0009:dvs-staging.cytobank.org-https-tomcat.srvrep[000f:0010]: HTTP/1.1 200
OK
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Server:
Apache-Coyote/1.1
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Content-Type:
text/html;charset=ISO-8859-1
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]:
Transfer-Encoding: chunked
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Date: Fri, 11
Jan 2013 01:13:19 GMT
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Connection:
close
0009:https.clicls[000f:]
0009:https.closed[000f:]
I'm using haproxy's ssl, like so:
bind 0.0.0.0:443 ssl crt /opt/haproxy/etc/wildcard.cert
If the config for this backend is like this:
use_backend dvs-staging.cytobank.org-https-tomcat if { path_reg -i
^/cytobank/ }
everything works fine, but if it's like this:
use_backend dvs-staging.cytobank.org-https-tomcat if { ssl_fc_sni -i
dvs-staging.cytobank.org } { path_reg -i ^/cytobank/ }
The upload goes very slowly and then fails.
There is no obvious difference between the outputs in these cases;
the above was successful, this is a failed one:
0009:https.accept(0006)=000f from [64.236.139.254:45900]
0009:https.clireq[000f:]: POST /cytobank/uploadServlet HTTP/1.1
0009:https.clihdr[000f:]: User-Agent: Cytobank Upload
0009:https.clihdr[000f:]: Content-Type: multipart/form-data;
boundary=qKulbQFAOI0yUOyRv5tJ8Itzvy4aMPqP58
0009:https.clihdr[000f:]: Cache-Control: no-cache
0009:https.clihdr[000f:]: Pragma: no-cache
0009:https.clihdr[000f:]: Host: dvs-staging.cytobank.org
0009:https.clihdr[000f:]: Accept: text/html, image/gif, image/jpeg, *;
q=.2, */*; q=.2
0009:https.clihdr[000f:]: Connection: keep-alive
0009:https.clihdr[000f:]: Content-Length: 6451523
0009:https.clihdr[000f:]: Cookie:
__utma=51498683.1371821700.1307729573.1357763653.1357770695.223;
__utmz=51498683.1348737696.200.4.utmcsr=localhost|utmccn=(referral)|utmcmd=referral|utmcct=/cytobank/subscriptions/subscribe;
__utma=20047853.812597310.1357601503.1357799042.1357864337.4;
__utmz=20047853.1357601503.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=20047853.28.10.1357864337; __utmc=20047853; openid_provider=Google;
user_credentials=ff9ed09a5a08f5103cdce0bcf9c7eda9d9bcee3e2e5a392b0e0b066780f5cfdb2a505a8bdd17d505057b751b20a96989ed61f6435a057d751958f034c095be50%3A%3A2
0007:http.clicls[000e:]
0007:http.closed[000e:]
0005:https.clicls[000a:]
0005:https.closed[000a:]
0002:https.clicls[0009:]
0002:https.closed[0009:]
0004:https.clicls[000c:]
0004:https.closed[000c:]
0003:https.clicls[000b:]
0003:https.closed[000b:]
0001:https.clicls[0008:]
0001:https.closed[0008:]
0006:https.clicls[000d:]
0006:https.closed[000d:]
0009:dvs-staging.cytobank.org-https-tomcat.srvrep[000f:0010]: HTTP/1.1 200
OK
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Server:
Apache-Coyote/1.1
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Content-Type:
text/html;charset=ISO-8859-1
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]:
Transfer-Encoding: chunked
0009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Date: Fri, 11
Jan 2013 01:08:39 GMT
