Re: Availability of HAProxy on Windows Server
I'm afraid Windows isn't a supported platform, please see http://www.haproxy.org/#plat On 26 March 2015 at 21:38, Abhijit Damle abhijit.da...@beca.com wrote: Hi, Do you have any version of HAProxy supported on Windows Server editions (server 2008, server 2012 etc). if so from where can I download it? Thanks and regards, Abhijit Damle Senior Software Engineer Beca www.beca.com --- NOTICE: This email, if it relates to a specific contract, is sent on behalf of the Beca company which entered into the contract. Please contact the sender if you are unsure of the contracting Beca company or visit our web page http://www.beca.com for further information on the Beca Group. If this email relates to a specific contract, by responding you agree that, regardless of its terms, this email and the response by you will be a valid communication for the purposes of that contract, and may bind the parties accordingly. This e-mail together with any attachments is confidential, may be subject to legal privilege and may contain proprietary information, including information protected by copyright. If you are not the intended recipient, please do not copy, use or disclose this e-mail; please notify us immediately by return e-mail and then delete this e-mail. ---
Re: Availability of HAProxy on Windows Server
Use hyperv and a linux VM inside. It works pretty well :) Baptiste On Fri, Mar 27, 2015 at 12:50 PM, Simon Dick sim...@irrelevant.org wrote: I'm afraid Windows isn't a supported platform, please see http://www.haproxy.org/#plat On 26 March 2015 at 21:38, Abhijit Damle abhijit.da...@beca.com wrote: Hi, Do you have any version of HAProxy supported on Windows Server editions (server 2008, server 2012 etc). if so from where can I download it? Thanks and regards, Abhijit Damle Senior Software Engineer Beca www.beca.com --- NOTICE: This email, if it relates to a specific contract, is sent on behalf of the Beca company which entered into the contract. Please contact the sender if you are unsure of the contracting Beca company or visit our web page http://www.beca.com for further information on the Beca Group. If this email relates to a specific contract, by responding you agree that, regardless of its terms, this email and the response by you will be a valid communication for the purposes of that contract, and may bind the parties accordingly. This e-mail together with any attachments is confidential, may be subject to legal privilege and may contain proprietary information, including information protected by copyright. If you are not the intended recipient, please do not copy, use or disclose this e-mail; please notify us immediately by return e-mail and then delete this e-mail. ---
Re: Does HAproxy support sending ServerName TLS extension to backend servers?
Jarno, Thank you your suggestion for setting the default ADFS certificate worked! On Thu, Mar 26, 2015 at 12:44 AM, Jarno Huuskonen jarno.huusko...@uef.fi wrote: Hi, On Wed, Mar 25, Shawn Heisey wrote: On 3/25/2015 10:16 AM, Brandon wrote: Hi, I am trying to deploy HAProxy in HTTP mode in front of a Windows Server 2012 R2 ADFS 3.0 farm. In ADFS 3.0 backend servers require that clients support SNI. In my testing it does not appear that HAProxy is sending the ServerName extension in the TLS handshake and as a result I am receiving a Bad Gateway error. The HAProxy logs just say Connection error during SSL handshake. I captured the traffic with wireshark and the ServerName TLS extension is indeed missing and the ADFS server is sending a RESET packet right after the SSL HELLO packet. Do any of the force-tls10, force-tls11 or force-tls12 (or no-sslv3) make any difference ? Haproxy 1.5 does support SNI, but in order for it to work, the version of openssl used must also support it. If you're running an old OS, it might not have that support. RHEL6 and its derivatives (like CentOS6) include openssl 0.9.8e, and I don't think that version has SNI ... the CentOS6 (6.6) comes with openssl 1.0.1e, but it also has compatibility package: openssl098e. (haproxy -vv should show what version you're using). It should be possible to configure ADFS not to require SNI(=add default binding), we're testing netscaler as adfs proxy (netscaler doesn't suppot SNI on backend). And the default binding seems to work. (For example: http://jesperstahle.azurewebsites.net/?p=1382) -Jarno -- Jarno Huuskonen
Re: Re: Does HAproxy support sending ServerName TLS extension to backend servers?
On 03/26/2015 08:34 AM, Baptiste wrote: HAProxy does not support SNI on backend yet. The biggest problem is not to send the SNI, the problem is what to send :) Do you send the Host header sent by the client, do you want to forge one, what happens if you do rewritting of the Host header, etc... So we could discuss the options here, then we'll be able to code something I guess... Hi, FWIW, Apache HTTPd's mod_proxy sends a server_name value equals to the Host header contained in the request sent to the backend. It may be the request header (possibly rewritten) if the ProxyPreserveHost option is set to On, otherwise it's the backend's hostname. Note that: - rfc6066 section 3 explicitly forbids sending a literal IPv4 or IPv6 address, the server_name value must be a FQDN ; - connection reuse is tricky when SNI is enabled, as the same connection cannot be reused if the server_name value differs. signature.asc Description: OpenPGP digital signature
active/passive with no failback; stick table not 100% sticky?
Hi there - We are evaluating different ways of using the “stick match” and “backup” options in order to achieve certain behaviors for failover, involving a Galera cluster. For reference, we’re picking and choosing from this blog post: http://blog.haproxy.com/2014/01/17/emulating-activepassing-application-clustering-with-haproxy/. We’re basically looking to have all connections on only one server at all times; as soon as a server is available, everyone should be kicked off and blocked from any other servers in the backend. This is because while Galera is a “multi-master” cluster, we’re trying to have the application only use one node as “master” at a time, at least for the moment. it seems like using just the “stick” table alone, as in: backend db-vms-galera option httpchk stick-table type ip size 1 stick on dst timeout server 90m server rhos-node1 rhel7-1:3306 check inter 1s port 9200 on-marked-down shutdown-sessions server rhos-node2 rhel7-2:3306 check inter 1s port 9200 on-marked-down shutdown-sessions server rhos-node3 rhel7-3:3306 check inter 1s port 9200 on-marked-down shutdown-sessions is not enough; from my observations running the “show table” socket command and watching the logs, when a node goes down, its entry still remains in the stick table for some period of time, and new connections, assuming they continue to come in fast, have no choice but to skip stick match altogether (I can provide logs and samples that show this happening). So we would then gather that the best configuration is this: backend db-vms-galera option httpchk stick-table type ip size 1 stick on dst timeout server 90m server rhos-node1 rhel7-1:3306 check inter 1s port 9200 on-marked-down shutdown-sessions server rhos-node2 rhel7-2:3306 check inter 1s port 9200 on-marked-down shutdown-sessions backup server rhos-node3 rhel7-3:3306 check inter 1s port 9200 on-marked-down shutdown-sessions backup this works a lot better; when I kill node1, all the connections go to node2 unambiguously. Then, our galera cluster in an effort to bring node1 back up, puts node2 into “Read only” mode, which bounces all connections to node3. At this point node1 comes back and then the stick table does not appear to be of any use; most connections continue to go to node3 and querying the stick table shows that it’s set to node3, however a handful of requests also go back to node1. So again this is not a pure “active/passive” setup, multiple nodes get hit at the same time. Was wondering if this behavior could be clarified and how we can use the stick table as an absolute “gate” for all requests, where no connections will fall through if a server goes down or comes back up. I had hopes for the unusual setup of just making all three servers a “backup” server: backend db-vms-galera option httpchk timeout server 90m server rhos-node1 rhel7-1:3306 check inter 1s port 9200 on-marked-down shutdown-sessions backup server rhos-node2 rhel7-2:3306 check inter 1s port 9200 on-marked-down shutdown-sessions backup server rhos-node3 rhel7-3:3306 check inter 1s port 9200 on-marked-down shutdown-sessions backup The idea being, no server is “official”, so there’s nothing to “fail back” towards. This sort of seemed to work but still seems like it wants to “fail back” up from node 3 to node2, to node 1; this approach seems to do the best job of making sure all connections are all on one server, though; not perfectly because it doesn’t bump off connections still talking to the being-replaced server, but still fairly well. Any insight on the usage of the stick table here would be appreciated!
