Re: Proxy Protocol in 1.4.x ?

[Benjamin Pineau]

Hi,
As a matter of feedback, I use this patch (on HAProxy 1.4.16, for HTTPS
connexions unwrapped by Stud) in production for almost 4 months, and it
works like a charm.

On 08/07/2011 09:34, Brane F. Gračnar wrote:

On Thursday 07 of July 2011 18:30:10 Sebastien Estienne wrote:

Hello,

I'd like to use stud https://github.com/bumptech/stud with Haproxy for
SSL support.
Stud implement the haproxy proxy protocol, and i'd like to know if
this will be backported to haproxy 1.4 ?


First, thanks for pointing out stud, looks very promising!

I'm using accept-proxy patch with haproxy 1.4.15 in production for two months
without any problems on moderate loaded instance (cca 3k concurrent
connections, 700-800 reqs/sec)...

Patch was written by Cyril Bonte, i'm just providing patch file.

Willy, i've been thinking about extending proxy protocol - it would be very
useful if protocol would allow additional, optional fields like tls_cipher,
tls_client_cert info etc... What is your opinion?

I'm also missing ability in haproxy (some kind of built-in acl) if connection
was accepted from listener with accept-proxy flag set.


Best regards, Brane

Re: SSL best option for new deployments

[Vincent Bernat]

OoO La  nuit ayant déjà recouvert  d'encre ce jour du  mardi 13 décembre
2011, vers 23:20, "Brane F. Gračnar"  disait :

> It also uses much less memory than stunnel (openssl >= 1.x.x).

stunnel has also enabled  the SSL_MOD_RELEASE_BUFFERS on recent versions
(since 4.45). I think this would amend the difference with stud.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: SSL best option for new deployments

[Vincent Bernat]

OoO La  nuit ayant déjà recouvert  d'encre ce jour du  mardi 13 décembre
2011, vers 23:43, "John Lauro"  disait :

> Found this with google comparing the two (only a few months old):
> http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html

> In summary, performance appears to be close as long as you only have 1 core, 
> but stud scales better with multiple cores.  However, as noted in the 
> replies, newer version of stunnel probably perform better.

There is an updated benchmark here:
 http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html

Now, stunnel and  stud have the same performance.  For stunnel, you need
to  use OpenSSL  1.0.0c  or later  to  fix a  performance problem.  With
hyperthreading, I even got better results with stunnel.

If you use stunnel, use at least 4.45. It features sendproxy support.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)

Re: route !HTTP connections to tcp backend instead of dropping in HTTP mode

[Willy Tarreau]

On Tue, Dec 13, 2011 at 10:00:50AM +0100, Lukasz Michalski wrote:
> On 12/13/2011 07:59 AM, Willy Tarreau wrote:
> 
> Many thanks for your help! It is great that it is possible to use
> haproxy instead of adding another software for frontend.
> 
> >
> > I did not know about this patch. If this way of requesting flash
> policy files
> > is well defined and standard, then we should merge this patch as it
> may ease
> > some setups.
> 
> Yes, this is described here:
> http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html
> 
> (see: "Socket policy request process")

OK thanks for the pointer. Indeed, it looks well specified enough.

Cheers,
Willy

Re: Slowness in establishing connections from ruby to Haproxy after upgrading from 1.4.8 to 1.4.18

[Timothy Garnett]

Hi Willy,

Thanks very much for your response.  It looks like it does have something
to do with TCP_NODELAY.

Setting "option http-server-close" had no effect on this problem.  However,
if I set "option http-no-delay" in haproxy then the problem goes away.  It
also goes away if I patch Ruby's net::http library to set the the
TCP_NODELAY flag on the socket.

(In case anyone google's this and is curious, this is how you can do so, at
least in ruby 1.9.1)
class Net::HTTP
  def on_connect()
@socket.io.setsockopt(Socket::IPPROTO_TCP, Socket::TCP_NODELAY, 1)
  end
end

I don't know if there's a good reason to favor one solution over the other.
 I'll attach tcpdumps in a separate e-mail.

Thanks!
Tim

On Tue, Dec 13, 2011 at 1:42 AM, Willy Tarreau  wrote:

> Hi Tim,
>
> On Mon, Dec 12, 2011 at 02:33:53PM -0500, Timothy Garnett wrote:
> > Hi all,
> >
> > We've been using Haproxy for a couple of years now to load balance our
> > external traffic and our internal backend services.  We recently upgraded
> > from version 1.4.8 to 1.4.18 and we noticed some connection
> initialization
> > performance issues when connecting from Ruby's standard net::http
> library,
> > specifically it takes about 200ms longer for the connection to establish
> > then it used to.  It's unclear if the issue comes from Ruby or Haproxy.
> >  We're interested if anyone has run into similar problems and if there
> are
> > things we can do to help identify the issue for fixing.
>
> Not specifically this one but 200ms sounds like a missing TCP_NODELAY on
> the client side. What I *suspect* (tcpdump on loopback could confirm) is
> that ruby sends HTTP request in small writes (eg: one write per line) and
> for this, disables TCP_NODELAY instead of sending many packets, but fails
> to enable it on the last packet.
>
> Alternatively, something else is possible. Maybe it's not the connection
> time which is huge but the total response time due to similar issues the
> other way around. Please add "option http-server-close" to your defaults
> section to see if it changes anything. Right now your config is in tunnel
> mode which is not very good, although it should not cause this.
>
> Another possibility that comes to mind, since you're sending data, is that
> ruby sends multiple small packets. Due to TCP, it needs an ACK every two
> packet. During a POST, haproxy does a "bulk" forward of data, which sends
> blocks as large as possible, without TCP_NODELAY, to save network
> resources.
> It's possible that this results in ACKs being delayed for incomplete
> packets
> then. Really, a tcpdump between ruby and haproxy would immensely help.
>
> You can also test with "option http-no-delay" which is mainly used for
> chunked-encoding transfers, when either direction is sensible to the
> framing
> (which is a direct violation of HTTP spec).
>
> If you happen to take a network capture, please use "tcpdump -s0" to
> capture
> full packets and save them to a file using "-w file.cap".
>
> Regards,
> Willy
>
>

Re: SSL best option for new deployments

[Baptiste]

And stud is still young and does not have all the features stunnel owns ;)

cheers

On Tue, Dec 13, 2011 at 11:43 PM, John Lauro
 wrote:
> Interesting.
>
> Found this with google comparing the two (only a few months old):
> http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html
>
> In summary, performance appears to be close as long as you only have 1 core,
> but stud scales better with multiple cores.  However, as noted in the
> replies, newer version of stunnel probably perform better.
>
>
>
>
>> -Original Message-
>> From: "Brane F. Gračnar" [mailto:brane.grac...@tsmedia.si]
>> Sent: Tuesday, December 13, 2011 5:21 PM
>> To: David Prothero
>> Cc: John Lauro; haproxy@formilux.org
>> Subject: Re: SSL best option for new deployments
>>
>> On 12/13/2011 10:43 PM, David Prothero wrote:
>> > I've been using stunnel with the X-Forwarded-For patch. Is stud
>> preferable to stunnel for some reason?
>>
>> Stunnel usually uses thread-per-connection architecture - as you
>> probably know this programming model has serious scaling issues. Stud is
>> single-threaded and runs as single-master/multiple-workers process,
>> meaning that it can efficiently utilize power of multi-core cpus without
>> context-switching overheaded resulting from hundreds (possibly
>> thousands) of threads competing for cpu time slice.
>>
>> Stud is implemented on top of libev, one of the most efficient event
>> loops available.
>>
>> It also uses much less memory than stunnel (openssl >= 1.x.x).
>>
>> Best regards, Brane
>

RE: SSL best option for new deployments

[John Lauro]

Interesting.

Found this with google comparing the two (only a few months old):
http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html

In summary, performance appears to be close as long as you only have 1 core, 
but stud scales better with multiple cores.  However, as noted in the 
replies, newer version of stunnel probably perform better.




> -Original Message-
> From: "Brane F. Gračnar" [mailto:brane.grac...@tsmedia.si]
> Sent: Tuesday, December 13, 2011 5:21 PM
> To: David Prothero
> Cc: John Lauro; haproxy@formilux.org
> Subject: Re: SSL best option for new deployments
>
> On 12/13/2011 10:43 PM, David Prothero wrote:
> > I've been using stunnel with the X-Forwarded-For patch. Is stud
> preferable to stunnel for some reason?
>
> Stunnel usually uses thread-per-connection architecture - as you
> probably know this programming model has serious scaling issues. Stud is
> single-threaded and runs as single-master/multiple-workers process,
> meaning that it can efficiently utilize power of multi-core cpus without
> context-switching overheaded resulting from hundreds (possibly
> thousands) of threads competing for cpu time slice.
>
> Stud is implemented on top of libev, one of the most efficient event
> loops available.
>
> It also uses much less memory than stunnel (openssl >= 1.x.x).
>
> Best regards, Brane

Re: SSL best option for new deployments

[Brane F. Gračnar]

On 12/13/2011 10:43 PM, David Prothero wrote:
> I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to 
> stunnel for some reason?

Stunnel usually uses thread-per-connection architecture - as you
probably know this programming model has serious scaling issues. Stud is
single-threaded and runs as single-master/multiple-workers process,
meaning that it can efficiently utilize power of multi-core cpus without
context-switching overheaded resulting from hundreds (possibly
thousands) of threads competing for cpu time slice.

Stud is implemented on top of libev, one of the most efficient event
loops available.

It also uses much less memory than stunnel (openssl >= 1.x.x).

Best regards, Brane

RE: SSL best option for new deployments

[David Prothero]

I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to 
stunnel for some reason?

David


-Original Message-
From: "Brane F. Gračnar" [mailto:brane.grac...@tsmedia.si] 
Sent: Tuesday, December 13, 2011 1:36 PM
To: John Lauro
Cc: haproxy@formilux.org
Subject: Re: SSL best option for new deployments

On 12/13/2011 09:02 PM, John Lauro wrote:
> Been using haproxy for some time…  but have not used it with SSL yet.
> 
> I do need to preserve the IP address of the original client.  So 
> either transparent (is that possible when going through stunnel or 
> other and haproxy on the same box), or X-Forwarded-for or similar added.

You should probably put stud (https://github.com/bumptech/stud) in front of 
haproxy. It supports sendproxy protocol from haproxy 1.5, supports
ipv6 and scaling out.

There's also a patch for sendproxy protocol that pplies to haproxy 1.4.
However, you shouldn't be afraid of running haproxy 1.5-devXX, it is really, 
really very stable.

Best regards, Brane

Re: SSL best option for new deployments

[Brane F. Gračnar]

On 12/13/2011 09:02 PM, John Lauro wrote:
> Been using haproxy for some time…  but have not used it with SSL yet.
> 
> I do need to preserve the IP address of the original client.  So either
> transparent (is that possible when going through stunnel or other and
> haproxy on the same box), or X-Forwarded-for or similar added.

You should probably put stud (https://github.com/bumptech/stud) in front
of haproxy. It supports sendproxy protocol from haproxy 1.5, supports
ipv6 and scaling out.

There's also a patch for sendproxy protocol that pplies to haproxy 1.4.
However, you shouldn't be afraid of running haproxy 1.5-devXX, it is
really, really very stable.

Best regards, Brane

SSL best option for new deployments

[John Lauro]

Been using haproxy for some time.  but have not used it with SSL yet.

 

What is the best option to implement SSL?  There seems to be several
options, some requiring 1.5 (which isn't exactly ideal as 1.5 isn't
considered stable yet).

 

I do need to route based on the incoming request, so decode before haproxy
as opposed to the MODE TCP options.  Also, would like persistent between
client and haproxy, but allow different back-ends per request.

 

I do need to preserve the IP address of the original client.  So either
transparent (is that possible when going through stunnel or other and
haproxy on the same box), or X-Forwarded-for or similar added.

 

 

Re: Unable to perform routing using HA Proxy on Linux machine post reboot

[Baptiste]

Thanks for keeping us updated and happy to see your issue fixed.

cheers

On Tue, Dec 13, 2011 at 12:38 PM, Avinash  wrote:
> Hi Baptiste and Willy,
>
> Thank you so much for your prompt responses and help. We have finally been
> able to get our server up and running. The problem was with certain rules on
> the IP Tables on the linux instance which added automatically on system
> reboot and bypassed all HA Proxy configs. We have now permanently deleted
> those rules.
>
> Once again thank you so much for your help.
>
> Regards,
> Avinash Anandan
> www.qureka.com
>
>
> On Tue, Dec 13, 2011 at 4:51 PM, Baptiste  wrote:
>>
>> What does haproxy tells you when you start it manually?
>> haproxy -d -f haproxy.cfg ?
>>
>> cheers
>>
>> On Tue, Dec 13, 2011 at 8:27 AM, Avinash 
>> wrote:
>> > Hi Willy,
>> >
>> > My default section is =>
>> >
>> > defaults
>> >         log     global
>> >         mode    http
>> >         option  httplog
>> >         option  dontlognull
>> >         retries 3
>> >         option redispatch
>> >         maxconn 2000
>> >         contimeout      5000
>> >         clitimeout      5
>> >         srvtimeout      5
>> >
>> > My iptable rules => sudo iptables -L
>> >
>> > Chain INPUT (policy ACCEPT)
>> > target     prot opt source               destination
>> >
>> > Chain FORWARD (policy ACCEPT)
>> > target     prot opt source               destination
>> >
>> > Chain OUTPUT (policy ACCEPT)
>> > target     prot opt source               destination
>> >
>> > netstat status => netstat --tcp --listening -n -p
>> > (Not all processes could be identified, non-owned process info
>> >  will not be shown, you would have to be root to see it all.)
>> > Active Internet connections (only servers)
>> > Proto Recv-Q Send-Q Local Address           Foreign Address
>> > State
>> >     PID/Program name
>> > tcp        0      0 127.0.0.1:8005          0.0.0.0:*
>> > LISTEN
>> >    12303/java
>> > tcp        0      0 0.0.0.0:8009            0.0.0.0:*
>> > LISTEN
>> >    12303/java
>> > tcp        0      0 0.0.0.0:3306            0.0.0.0:*
>> > LISTEN
>> >    -
>> > tcp        0      0 0.0.0.0:6379            0.0.0.0:*
>> > LISTEN
>> >    1646/redis-server
>> > tcp        0      0 10.211.154.49:80        0.0.0.0:*
>> > LISTEN
>> >    -
>> > tcp        0      0 0.0.0.0:8080            0.0.0.0:*
>> > LISTEN
>> >    12303/java
>> > tcp        0      0 0.0.0.0:22              0.0.0.0:*
>> > LISTEN
>> >    -
>> > tcp6       0      0 :::8081                 :::*
>> >  LISTEN
>> >    -
>> > tcp6       0      0 :::22                   :::*
>> >  LISTEN
>> >    -
>> >
>> > Firewall status =>sudo ufw status
>> > Status: inactive
>> >
>> > Problem is even after shutting down haproxy, req for 80 getting
>> > forwarded to
>> > 8080, that means request is getting diverted before it reaches to
>> > haproxy.
>> > But in actual no one listening to port 80 except haproxy. My tomcat is
>> > running on 8080 (server.xml)
>> >
>> >
>> >
>> > On Tue, Dec 13, 2011 at 11:58 AM, Willy Tarreau  wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Tue, Dec 13, 2011 at 12:27:25AM +0530, Avinash wrote:
>> >> > Hi,
>> >> >
>> >> > We have a Linux machine on which are installed 2 servers (tomcat @
>> >> > 8080,
>> >> > lighthttpd @ 8081). I am using HAProxy ( @ 80 ) to perform domain
>> >> > base
>> >> > routing to these servers.
>> >> >
>> >> > After a reboot, we restarted the apps(haproxy, lighthttpd, tomcat)
>> >> > and
>> >> > found that haproxy is no longer able to perform routing. Before
>> >> > reboot
>> >> > things were working fine and we did not perform any config/software
>> >> > changes
>> >> > from our end.
>> >> >
>> >> > Here are our haproxy settings :
>> >> >
>> >> >
>> >> >    - frontend http_proxy
>> >> >    - bind 10.211.154.49:80 
>> >> >    - option forwardfor
>> >> >    - acl is_resource hdr_dom(host) -i resource.qureka.com
>> >> >    - acl is_app hdr_dom(host) -i www.qureka.com
>> >> >    - use_backend resource_cluster if is_resource
>> >> >    - use_backend app_cluster if is_app
>> >> >
>> >> > backend resource_cluster
>> >> > server server1 127.0.0.1:8081
>> >> >
>> >> > backend app_cluster
>> >> > server server1 127.0.0.1:8080
>> >>
>> >> What does your defaults section look like ? Maybe you accidentely
>> >> removed a line and are not running in HTTP mode anymore ?
>> >>
>> >> Also, one thing which often starts at boot is the firewall. Maybe
>> >> you were running a firewall on the machine which you manually disabled
>> >> and forgot to remove it from startup. So after a reboot it starts again
>> >> and prevents haproxy from connecting to your servers.
>> >>
>> >> Those are just a few guesses of course, as it's not very clear what
>> >> changed during the reboot.
>> >>
>> >> Regards,
>> >> Willy
>> >>
>> >
>
>

Re: Unable to perform routing using HA Proxy on Linux machine post reboot

[Avinash]

Hi Baptiste and Willy,

Thank you so much for your prompt responses and help. We have finally been
able to get our server up and running. The problem was with certain rules
on the IP Tables on the linux instance which added automatically on system
reboot and bypassed all HA Proxy configs. We have now permanently deleted
those rules.

Once again thank you so much for your help.

Regards,
Avinash Anandan
www.qureka.com


On Tue, Dec 13, 2011 at 4:51 PM, Baptiste  wrote:

> What does haproxy tells you when you start it manually?
> haproxy -d -f haproxy.cfg ?
>
> cheers
>
> On Tue, Dec 13, 2011 at 8:27 AM, Avinash 
> wrote:
> > Hi Willy,
> >
> > My default section is =>
> >
> > defaults
> > log global
> > modehttp
> > option  httplog
> > option  dontlognull
> > retries 3
> > option redispatch
> > maxconn 2000
> > contimeout  5000
> > clitimeout  5
> > srvtimeout  5
> >
> > My iptable rules => sudo iptables -L
> >
> > Chain INPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain FORWARD (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > netstat status => netstat --tcp --listening -n -p
> > (Not all processes could be identified, non-owned process info
> >  will not be shown, you would have to be root to see it all.)
> > Active Internet connections (only servers)
> > Proto Recv-Q Send-Q Local Address   Foreign Address State
> > PID/Program name
> > tcp0  0 127.0.0.1:8005  0.0.0.0:*
> LISTEN
> >12303/java
> > tcp0  0 0.0.0.0:80090.0.0.0:*
> LISTEN
> >12303/java
> > tcp0  0 0.0.0.0:33060.0.0.0:*
> LISTEN
> >-
> > tcp0  0 0.0.0.0:63790.0.0.0:*
> LISTEN
> >1646/redis-server
> > tcp0  0 10.211.154.49:800.0.0.0:*
> LISTEN
> >-
> > tcp0  0 0.0.0.0:80800.0.0.0:*
> LISTEN
> >12303/java
> > tcp0  0 0.0.0.0:22  0.0.0.0:*
> LISTEN
> >-
> > tcp6   0  0 :::8081 :::*
>  LISTEN
> >-
> > tcp6   0  0 :::22   :::*
>  LISTEN
> >-
> >
> > Firewall status =>sudo ufw status
> > Status: inactive
> >
> > Problem is even after shutting down haproxy, req for 80 getting
> forwarded to
> > 8080, that means request is getting diverted before it reaches to
> haproxy.
> > But in actual no one listening to port 80 except haproxy. My tomcat is
> > running on 8080 (server.xml)
> >
> >
> >
> > On Tue, Dec 13, 2011 at 11:58 AM, Willy Tarreau  wrote:
> >>
> >> Hi,
> >>
> >> On Tue, Dec 13, 2011 at 12:27:25AM +0530, Avinash wrote:
> >> > Hi,
> >> >
> >> > We have a Linux machine on which are installed 2 servers (tomcat @
> 8080,
> >> > lighthttpd @ 8081). I am using HAProxy ( @ 80 ) to perform domain base
> >> > routing to these servers.
> >> >
> >> > After a reboot, we restarted the apps(haproxy, lighthttpd, tomcat) and
> >> > found that haproxy is no longer able to perform routing. Before reboot
> >> > things were working fine and we did not perform any config/software
> >> > changes
> >> > from our end.
> >> >
> >> > Here are our haproxy settings :
> >> >
> >> >
> >> >- frontend http_proxy
> >> >- bind 10.211.154.49:80 
> >> >- option forwardfor
> >> >- acl is_resource hdr_dom(host) -i resource.qureka.com
> >> >- acl is_app hdr_dom(host) -i www.qureka.com
> >> >- use_backend resource_cluster if is_resource
> >> >- use_backend app_cluster if is_app
> >> >
> >> > backend resource_cluster
> >> > server server1 127.0.0.1:8081
> >> >
> >> > backend app_cluster
> >> > server server1 127.0.0.1:8080
> >>
> >> What does your defaults section look like ? Maybe you accidentely
> >> removed a line and are not running in HTTP mode anymore ?
> >>
> >> Also, one thing which often starts at boot is the firewall. Maybe
> >> you were running a firewall on the machine which you manually disabled
> >> and forgot to remove it from startup. So after a reboot it starts again
> >> and prevents haproxy from connecting to your servers.
> >>
> >> Those are just a few guesses of course, as it's not very clear what
> >> changed during the reboot.
> >>
> >> Regards,
> >> Willy
> >>
> >
>

Re: Unable to perform routing using HA Proxy on Linux machine post reboot

[Baptiste]

What does haproxy tells you when you start it manually?
haproxy -d -f haproxy.cfg ?

cheers

On Tue, Dec 13, 2011 at 8:27 AM, Avinash  wrote:
> Hi Willy,
>
> My default section is =>
>
> defaults
>         log     global
>         mode    http
>         option  httplog
>         option  dontlognull
>         retries 3
>         option redispatch
>         maxconn 2000
>         contimeout      5000
>         clitimeout      5
>         srvtimeout      5
>
> My iptable rules => sudo iptables -L
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
>
> netstat status => netstat --tcp --listening -n -p
> (Not all processes could be identified, non-owned process info
>  will not be shown, you would have to be root to see it all.)
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State
>     PID/Program name
> tcp        0      0 127.0.0.1:8005          0.0.0.0:*               LISTEN
>    12303/java
> tcp        0      0 0.0.0.0:8009            0.0.0.0:*               LISTEN
>    12303/java
> tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN
>    -
> tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN
>    1646/redis-server
> tcp        0      0 10.211.154.49:80        0.0.0.0:*               LISTEN
>    -
> tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN
>    12303/java
> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
>    -
> tcp6       0      0 :::8081                 :::*                    LISTEN
>    -
> tcp6       0      0 :::22                   :::*                    LISTEN
>    -
>
> Firewall status =>sudo ufw status
> Status: inactive
>
> Problem is even after shutting down haproxy, req for 80 getting forwarded to
> 8080, that means request is getting diverted before it reaches to haproxy.
> But in actual no one listening to port 80 except haproxy. My tomcat is
> running on 8080 (server.xml)
>
>
>
> On Tue, Dec 13, 2011 at 11:58 AM, Willy Tarreau  wrote:
>>
>> Hi,
>>
>> On Tue, Dec 13, 2011 at 12:27:25AM +0530, Avinash wrote:
>> > Hi,
>> >
>> > We have a Linux machine on which are installed 2 servers (tomcat @ 8080,
>> > lighthttpd @ 8081). I am using HAProxy ( @ 80 ) to perform domain base
>> > routing to these servers.
>> >
>> > After a reboot, we restarted the apps(haproxy, lighthttpd, tomcat) and
>> > found that haproxy is no longer able to perform routing. Before reboot
>> > things were working fine and we did not perform any config/software
>> > changes
>> > from our end.
>> >
>> > Here are our haproxy settings :
>> >
>> >
>> >    - frontend http_proxy
>> >    - bind 10.211.154.49:80 
>> >    - option forwardfor
>> >    - acl is_resource hdr_dom(host) -i resource.qureka.com
>> >    - acl is_app hdr_dom(host) -i www.qureka.com
>> >    - use_backend resource_cluster if is_resource
>> >    - use_backend app_cluster if is_app
>> >
>> > backend resource_cluster
>> > server server1 127.0.0.1:8081
>> >
>> > backend app_cluster
>> > server server1 127.0.0.1:8080
>>
>> What does your defaults section look like ? Maybe you accidentely
>> removed a line and are not running in HTTP mode anymore ?
>>
>> Also, one thing which often starts at boot is the firewall. Maybe
>> you were running a firewall on the machine which you manually disabled
>> and forgot to remove it from startup. So after a reboot it starts again
>> and prevents haproxy from connecting to your servers.
>>
>> Those are just a few guesses of course, as it's not very clear what
>> changed during the reboot.
>>
>> Regards,
>> Willy
>>
>

Re: route !HTTP connections to tcp backend instead of dropping in HTTP mode

[Lukasz Michalski]

On 12/13/2011 07:59 AM, Willy Tarreau wrote:

Many thanks for your help! It is great that it is possible to use
haproxy instead of adding another software for frontend.

>
> I did not know about this patch. If this way of requesting flash
policy files
> is well defined and standard, then we should merge this patch as it
may ease
> some setups.

Yes, this is described here:
http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html

(see: "Socket policy request process")

>
> In theory it should. However with what is above, you don't need it,
> which saves you from maintaining a patch.
>

I am trying it now. Thanks again!

Regards,
Łukasz

Re: haproxy and interaction with VRRP

[Sander Klein]

On 12.12.2011 14:32, Vincent Bernat wrote:

On Mon, 12 Dec 2011 13:23:11 +0100, Sander Klein wrote:

I started doing this because there is no nonlocal_bind option 
for

IPv6 (or I didn't search well enough (-: )


From the source code, it seems that IPv4 non local bind sysctl 
also

applies to IPv6. Since 2.6.30.


Hmmm, then I'm going to look into it again. I'm running 2.6.39 and 
it

doesn't seem to work. Could be a problem on my side.


You are right. It only applies to v4-mapped addresses.


It would have been nice if it did work though... It's one of those
features I'm missing.

Binding ip's to the dummy interface works, but it always feels a bit
hacky and brings up a lot of administration if you have lots of vrrp
addresses.


Here is a patch for this (only slightly tested):

http://marc.info/?l=linux-netdev&m=132369656811468&w=2

It is targeted at the net-next branch and will not apply cleanly on a
vanilla kernel: you just need to remove the check on inet->freebind
which is not yet present in vanilla kernels.


Thanks! I'll have a look if I can get it working.