RE: Question on feature stability in 1.5

2013-04-09 Thread Lukas Tribus
Hi Ahmed,

 I wanted to find out if the features I'm using can be considered
 complete for 1.5.
 [...]
 if these are feature complete (or stable)

The latest 1.5 snapshot should be fairly usable also in production, 
but since there is no feature freeze, that will very likely change
with new features beeing commited to 1.5.

If you would like to run development software in production, you need
to do extensive testing prior to deploying it and be aware that
troubleshooting bugs will likely be needed. If thats something you are
willing to do - great (that way you help making 1.5 more stable). On
the other hand, if you would like a stable solution which is as stable
as possibile, you better not use to haproxy 1.5. Nginx may be a solution
an alternative at that point (it does not have all those fancy load-
balancing features haproxy has, but it may be enough for your deployment).


Regards,
Lukas 


Re: Header whitelist possible?

2013-04-09 Thread Hannes Haug
Thanks Baptiste

But ACLs seem to work only on header values and not on header names.

Regard
 Hannes

Am Montag, 8. April 2013 schrieb Baptiste :

 Hi,

 You can add conditions through ACLs and decide to reqdel/reqdeny IF or
 UNLESS the acl matched.
 It may worth a try.

 Baptiste

 On Mon, Apr 8, 2013 at 2:56 PM, Hannes Haug han...@haug.comjavascript:;
 wrote:
  Hi all
 
  Reqdel/reqidel delete all headers matching a regex and reqdeny/reqideny
 deny
  an HTTP request if a line matches a regex. That's a blacklist approach.
 
  Are whitelists denying a request if a line _doesn't_ match a regex and
  deleting all headers _not_ matching a regex also possible?
 
  Thanks
Hannes



Re: Question on parsing request body, URL re-writing

2013-04-09 Thread David Coulson


On Apr 9, 2013, at 1:53 PM, Connelly, Zachary (CGI Federal) wrote:

 HAProxy Mail List,
  
 I am a new user of the HAProxy software. I am attempting to set it up for the 
 first time and am interested to see if the tool is able to parse the body of 
 a request. I saw in the configuration document that “…HAProxy never touches 
 data contents, it stops analysis at the end of headers,” but was curious if 
 there is any way to parse the body contents, not to change the info but to 
 use for routing the request to an appropriate endpoint. My guess from this 
 statement and reviewing the configuration document is no but wanted to see if 
 I’m missing anything.

I was actually going to ask the same thing - I have a 'security' application 
with hard-coded absolute URLs in the body that need to be rewritten. We do some 
funky stuff with HAProxy 1.5-dev to get it to work at all, but the absolute 
URLs are breaking a few use cases.

David

Re: Two HAProxy instances with a shared IP

2013-04-09 Thread Jérôme Benoit
On Mon, 8 Apr 2013 14:36:52 +0100 (BST) in 
564091370.1183442.1365428212786.javamail.r...@innovot.com, 
Phil Daws Phil Daws ux...@splatnix.net wrote:

 Hello,

Hello, 

 am making my first foray into setting up a test lab to play around with 
 HAProxy.  Ideally I am hoping to build an environment which consists of two 
 HAProxy nodes that share an IP address, and each node then offloads HTTP 
 connections to two backend web servers. Basically build a meshed architecture 
 for no single point of failure.  

A mesh for a shared IP ? How ? Encapsulating the IP datagram ? 

It looks like the best route would be to use Wackamole and Spread for the 
shared IP address. 

or keepalived or carp.  

 Am building on CentOS 6.4 so would be grateful for your thoughts on this 
 setup or whether there is a more appropriate one.  If all works well then 
 hopefully can start to look at LB/HA for other services.

The wackamole solution seem only valuable if you have more than one shared IP. 

++. 

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D


signature.asc
Description: PGP signature


Re: Two HAProxy instances with a shared IP

2013-04-09 Thread Phil Daws
Thank you Jerome. Am looking at KeepAlived, UCARP and VRRP though not sure 
which way to go at the moment from a pro/cons perspective. Thanks.
- Original Message -
From: Jérôme Benoit jerome.ben...@grenouille.com
To: haproxy@formilux.org
Cc: Phil Daws ux...@splatnix.net
Sent: Tuesday, 9 April, 2013 9:42:53 PM
Subject: Re: Two HAProxy instances with a shared IP

On Mon, 8 Apr 2013 14:36:52 +0100 (BST) in 
564091370.1183442.1365428212786.javamail.r...@innovot.com, 
Phil Daws Phil Daws ux...@splatnix.net wrote:

 Hello,

Hello, 

 am making my first foray into setting up a test lab to play around with 
 HAProxy.  Ideally I am hoping to build an environment which consists of two 
 HAProxy nodes that share an IP address, and each node then offloads HTTP 
 connections to two backend web servers. Basically build a meshed architecture 
 for no single point of failure.  

A mesh for a shared IP ? How ? Encapsulating the IP datagram ? 

It looks like the best route would be to use Wackamole and Spread for the 
shared IP address. 

or keepalived or carp.  

 Am building on CentOS 6.4 so would be grateful for your thoughts on this 
 setup or whether there is a more appropriate one.  If all works well then 
 hopefully can start to look at LB/HA for other services.

The wackamole solution seem only valuable if you have more than one shared IP. 

++. 

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D



Re: Two HAProxy instances with a shared IP

2013-04-09 Thread Jeff Zellner
Hey Phil,

I've recently been evaluating all of the above. Wackamole + Spread
have so far worked the best for me (distributing a number of VIP's
across a cluster of HAProxy machines with, allowing failover).
Heartbeat didn't seem to work well in my environment, and I had a lot
of trouble getting ucarp configured just-right.

It could be that I was just doing-it-wrong, but Wackamole + Spread
have been relatively painless other than some oddities declaring
spread segments (requiring me to only list one host per segment).

Cheers,
Jeff

On Tue, Apr 9, 2013 at 4:51 PM, Phil Daws ux...@splatnix.net wrote:
 Thank you Jerome. Am looking at KeepAlived, UCARP and VRRP though not sure 
 which way to go at the moment from a pro/cons perspective. Thanks.
 - Original Message -
 From: Jérôme Benoit jerome.ben...@grenouille.com
 To: haproxy@formilux.org
 Cc: Phil Daws ux...@splatnix.net
 Sent: Tuesday, 9 April, 2013 9:42:53 PM
 Subject: Re: Two HAProxy instances with a shared IP

 On Mon, 8 Apr 2013 14:36:52 +0100 (BST) in 
 564091370.1183442.1365428212786.javamail.r...@innovot.com,
 Phil Daws Phil Daws ux...@splatnix.net wrote:

 Hello,

 Hello,

 am making my first foray into setting up a test lab to play around with 
 HAProxy.  Ideally I am hoping to build an environment which consists of two 
 HAProxy nodes that share an IP address, and each node then offloads HTTP 
 connections to two backend web servers. Basically build a meshed 
 architecture for no single point of failure.

 A mesh for a shared IP ? How ? Encapsulating the IP datagram ?

It looks like the best route would be to use Wackamole and Spread for the 
shared IP address.

 or keepalived or carp.

 Am building on CentOS 6.4 so would be grateful for your thoughts on this 
 setup or whether there is a more appropriate one.  If all works well then 
 hopefully can start to look at LB/HA for other services.

 The wackamole solution seem only valuable if you have more than one shared IP.

 ++.

 --
 Jérôme Benoit aka fraggle
 La Météo du Net - http://grenouille.com
 OpenPGP Key ID : 9FE9161D
 Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D




Re: Two HAProxy instances with a shared IP

2013-04-09 Thread David Coulson


On 4/9/13 5:27 PM, Jeff Zellner wrote:

Hey Phil,

I've recently been evaluating all of the above. Wackamole + Spread
have so far worked the best for me (distributing a number of VIP's
across a cluster of HAProxy machines with, allowing failover).
Heartbeat didn't seem to work well in my environment, and I had a lot
of trouble getting ucarp configured just-right.
Not sure what environment you're in, but we run HAProxy with Pacemaker 
on RHEL, and it works pretty much flawlessly. In some cases we do 
active/passive VIPs the way most HA systems do, but others we use BGP to 
advertise /32 routes into the network and use that to get traffic to our 
load balancers. Works nicely, especially since not everything has to be 
on the same VLAN to support it.


David



Re: Cross Domain persistence

2013-04-09 Thread Duncan Hall

Willy,

Thanks for your reply, it is appreciated. I have this working behind an 
old F5 at the moment with an iRule to try and recreate the users 
jsession cookie, it works but is a bit of a mess. I think I can 
replicate the way that works in HAproxy but I was hoping that there may 
be some magic feature! Eventually I will get the sites rebuilt to use 
backend session persistence and this will all become very simple.


Regards,

Duncan







On 08/04/13 15:47, Willy Tarreau wrote:

Hi Duncan,

On Mon, Apr 08, 2013 at 02:53:06PM +1000, Duncan Hall wrote:

Hi,

I have a website that acts as the SSL ecommerce checkout for several
other sites.  All of the sites are on the same public IP and live in a
cluster of tomcat servers.

I need to maintain session persistence when moving from one domain to
the SSL enabled domain and from http to https. Can anyone point me at a
config example for this using Haproxy 1.5dev?

It's not a matter of configuration but of application architecture,
and only that. The browser will try hard not to share anything between
multiple domains, including cookies  SSLID.

So first, you need to find a way to communicate between your sites.
Sometimes people use shop.$domain instead of www.$domain so that
cookies are kept between the two. Other methods consist in passing a
signed token in links or redirected URLs between the domains.

As you can see it's mainly a matter of designing the application for
that. Once you have choosen a way for your application to work, then
we can imagine various methods to keep the persistence between the
servers ; if the element that is passed between the two is available
in requests/responses on both sides, it should be doable to stick on
it. Sometimes an URL parameter can be very effective for this : the
server just has to pass its name in a URL param, and it's then easy
to pick it on the next request.

Hoping this helps,
Willy