Haproxy filter by destination ip
Hi all, I found a way to filter by domain name "hdr_dom(host)", I need to filter by domain public IP instead. What's the syntax for that? Thanks in advanced.
Re: Haproxy filter by destination ip
Isn't this just done by configuring seperate listen section: listen IP1 172.200.17.3:80 default_backend backend1 listen IP2 172.17.200.17.4:80 default_backend backend2 Or is there something further about your solution that I'm missing here? Chris Gerardo Corro wrote: Hi all, I found a way to filter by domain name "hdr_dom(host)", I need to filter by domain public IP instead. What's the syntax for that? Thanks in advanced.
Re: strange issues with IE 6
Hello,
You can't have a HTTP 200 in all your log and a HTTP 404 in your web
browser, or IE6 really became a bunch of crap.
you can disable IE crap about friendly 404 error page with this :
1. Go to Tools Menu in the Internet Explorer and click the Internet
Options.
2. You will be displayed with the Internet Options dialog box. Click
the Advanced tab.
3. Uncheck the "Show friendly HTTP error messages" check box and then
click the OK button at the end.
Regards,
Hervé.
On Wed, 04 Aug 2010 15:58:48 +0200
eni-urgence wrote:
> Hello all.
>
>
> I have some strange issue with ie6 (I know it's quite old but our
> customer don't want to upgrade for now). A page that works through
> the proxy with last release of webrowser (IE8, firefox, Safari...)
> don't want to work with IE6. The http request go on the proxy and
> it's forwarded to the apache server but the browser display a 404
> error (Page not found)
>
> you can find the haproxy trace
> Aug 4 15:54:16 web0103 haproxy[19109]: 127.0.0.1:35663
> [04/Aug/2010:15:54:16.535] public-http-applicatif-prod
> webfarm-http-applicatif-prod-Avignon/web0103-applicatif-10084
> 0/0/0/85/86 200 5046 - - --NI 0/0/0/0/0 0/0 {192.168.1.8|} {|Apache}
> "GET /scanweb/custom/demo/index.php HTTP/1.1"
>
>
>
> and the apache trace
>
> secure.scan-prod.com 192.168.1.8 192.168.1.8 192.168.100.41 - -
> [04/Aug/2010:15:54:16 +0200] "GET /scanweb/custom/demo/index.php
> HTTP/1.1" 200 4547 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
> 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR
> 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET
> CLR 3.5.30729)"
>
> I have seen in haproxy doc that the return code 200 said all is ok.
> The information --NI said that no cookie have been set. I don't
> understand why.
>
>
> Is anyone have seen it before?
>
> Thanks for your help
>
> NICOLE Emerik
> Newbie french user of haproxy.
>
>
>
>
--
Hervé COMMOWICK, EXOSEC (http://www.exosec.fr/)
ZAC des Metz - 3 Rue du petit robinson - 78350 JOUY EN JOSAS
Tel: +33 1 30 67 60 65 - Fax: +33 1 75 43 40 70
mailto:hcommow...@exosec.fr
Re: HAProxy Setup not talking to Passenger/Apache
On Aug 3, 2010, at 11:41 AM, Willy Tarreau wrote: > Hi Nick, > > On Tue, Aug 03, 2010 at 10:11:53AM -0500, Nick Hilem wrote: >> >> On Aug 3, 2010, at 1:52 AM, Willy Tarreau wrote: >> >>> Hi Nick, >>> >>> On Mon, Aug 02, 2010 at 11:13:29PM -0500, Nick Hilem wrote: I have HAProxy, 1.3.15, on the frontend of a few Ubuntu 9.04 instances with the following haproxy.cfg that are distributing to a couple apache/passenger instances. My problem is that if I... curl http://localhost/ It sits for awhile then returns a 504 Gateway Timeout. However if I... curl http://localhost:7000/ Which passenger is listening on, it returns fairly quickly with the page I would expect to see. >>> >>> That's kinda weird. One (unlikely) possibility would be that the server >>> responds differently when it does not see its port in the request. Could >>> you force it to see if it changes anything : >>> >>> curl -H "Host: localhost" http://localhost:7000/ >> >> Works. >> >>> curl -H "Host: localhost:7000" http://localhost/ >> >> Fails. > > OK > >> I get the following errors when I add the -d, and reload HAProxy. >> >> [ALERT] 214/100529 (26463) : Starting proxy passenger_proxy: cannot bind >> socket >> *** [err :: web01.mydomain.com] [ALERT] 214/100529 (26463) : Starting proxy >> passenger_proxy: cannot bind socket >> *** [err :: web01.mydomain.com] [ALERT] 214/100529 (26463) : Starting proxy >> health_check: cannot bind socket >> *** [err :: web01.mydomain.com] [ALERT] 214/100529 (26463) : Starting proxy >> admin: cannot bind socket >> >> :( > > No, that's very cool, it means there is something wrong somewhere > else because the ports are already bound. Either an older version > of haproxy is still running with an old conf, or something is bound > to the port, preventing it from starting. I think that for a long > time you've been running your tests on an old broken config while > you were believing it was the new one. > > Using "netstat -lntp" you'll be able to figure what process is bound > to the ports and kill it before restarting haproxy with -d. > > Regards, > Willy r...@web01:/var/log# ps aux | grep haproxy root 13026 0.0 0.0 2420 524 ?Ss 20:05 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid root 14442 0.0 0.0 3420 764 pts/1R+ 20:50 0:00 grep haproxy r...@web01:/var/log# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 0.0.0.0:60001 0.0.0.0:* LISTEN 13026/haproxy tcp0 0 0.0.0.0:91000.0.0.0:* LISTEN 13026/haproxy tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 13026/haproxy tcp0 0 0.0.0.0:49490.0.0.0:* LISTEN 17349/munin-node tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1069/sshd tcp0 0 0.0.0.0:70000.0.0.0:* LISTEN 12693/apache2 tcp0 0 0.0.0.0:70010.0.0.0:* LISTEN 12693/apache2 tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN 13600/master tcp0 0 0.0.0.0:443 0.0.0.0:* LISTEN 13026/haproxy tcp0 0 0.0.0.0:28120.0.0.0:* LISTEN 13033/monit tcp6 0 0 :::22 :::*LISTEN 1069/sshd The netstat only appears to show the latest HAProxy being run and the config file that I've been using is the one specified in the command. You were right that the errors above seem to indicate an older HAProxy not being shut down properly, but even if I ensure a full stop and removal of pid before issuing a start... that particular error goes away but the initial problem still persists. After doing some more digging, I've noticed that if I... curl http://localhost/ ...immediately after a restart/start it will go through successfully, but then subsequent calls and/or if I don't issue the command quick enough, will timeout. But the calls to... curl http://localhost:7000/ ...will still go through. So it appears as though it can bind, but then relinquishes control to something else?
Re: HAProxy Setup not talking to Passenger/Apache
On Aug 3, 2010, at 4:18 AM, Anze wrote: > > Nick, try rather: > $ curl 10.202.197.103:7000 > $ curl 10.208.202.70:7000 Using the internal IPs had the same result as using localhost or the web01/web02 names. Thanks for the suggestion though. > You are not using localhost:7000 in your config, but web02:7000 and > web01:7000 > instead. > > Anze > > On Tuesday 03 August 2010, Willy Tarreau wrote: >> Hi Nick, >> >> On Mon, Aug 02, 2010 at 11:13:29PM -0500, Nick Hilem wrote: >>> I have HAProxy, 1.3.15, on the frontend of a few Ubuntu 9.04 instances >>> with the following haproxy.cfg that are distributing to a couple >>> apache/passenger instances. My problem is that if I... curl >>> http://localhost/ >>> It sits for awhile then returns a 504 Gateway Timeout. However if I... >>> curl http://localhost:7000/ >>> Which passenger is listening on, it returns fairly quickly with the page >>> I would expect to see. >> >> That's kinda weird. One (unlikely) possibility would be that the server >> responds differently when it does not see its port in the request. Could >> you force it to see if it changes anything : >> >> curl -H "Host: localhost" http://localhost:7000/ >> curl -H "Host: localhost:7000" http://localhost/ >> >>> I've also included the lsof results and hosts file on web01, everything >>> is the same on web02. Anyone have any guess as to why my haproxy and >>> passenger setup aren't talking to each other? Is my haproxy.cfg file >>> misconfigured somehow? >> >> No, it looks fine. You don't even have "option httpclose", so that >> means that the connection passes unmodified. >> >> Please run it in debug mode if you can (using -d) and check the output >> for request/responses. Maybe we'll see something odd, but I have no >> idea what. >> >> Also you could try to switch to "mode tcp" and see if that changes >> anything. If so, that means that it blocks in the HTTP protocol. If >> it does not work either, then it will be more likely a problem >> handling the Host header. >> >> Regards, >> Willy >> > >
Re: strange issues with IE 6
Hello.
I have removed the friendly error message from IE and it display a
blank page.
I have not mentionned that i have stunnel in front of haproxy for ssl
termination. I have made some test and capture packet and i think that
it's stunnel that don't work.
I will make more test.
Cheers
Hervé COMMOWICK a écrit :
Hello,
You can't have a HTTP 200 in all your log and a HTTP 404 in your web
browser, or IE6 really became a bunch of crap.
you can disable IE crap about friendly 404 error page with this :
1. Go to Tools Menu in the Internet Explorer and click the Internet
Options.
2. You will be displayed with the Internet Options dialog box. Click
the Advanced tab.
3. Uncheck the "Show friendly HTTP error messages" check box and then
click the OK button at the end.
Regards,
Hervé.
On Wed, 04 Aug 2010 15:58:48 +0200
eni-urgence wrote:
Hello all.
I have some strange issue with ie6 (I know it's quite old but our
customer don't want to upgrade for now). A page that works through
the proxy with last release of webrowser (IE8, firefox, Safari...)
don't want to work with IE6. The http request go on the proxy and
it's forwarded to the apache server but the browser display a 404
error (Page not found)
you can find the haproxy trace
Aug 4 15:54:16 web0103 haproxy[19109]: 127.0.0.1:35663
[04/Aug/2010:15:54:16.535] public-http-applicatif-prod
webfarm-http-applicatif-prod-Avignon/web0103-applicatif-10084
0/0/0/85/86 200 5046 - - --NI 0/0/0/0/0 0/0 {192.168.1.8|} {|Apache}
"GET /scanweb/custom/demo/index.php HTTP/1.1"
and the apache trace
secure.scan-prod.com 192.168.1.8 192.168.1.8 192.168.100.41 - -
[04/Aug/2010:15:54:16 +0200] "GET /scanweb/custom/demo/index.php
HTTP/1.1" 200 4547 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR
3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET
CLR 3.5.30729)"
I have seen in haproxy doc that the return code 200 said all is ok.
The information --NI said that no cookie have been set. I don't
understand why.
Is anyone have seen it before?
Thanks for your help
NICOLE Emerik
Newbie french user of haproxy.
Re: HAProxy Setup not talking to Passenger/Apache
On Wed, Aug 04, 2010 at 09:40:35AM -0500, Nick Hilem wrote: > The netstat only appears to show the latest HAProxy being run and the config > file that I've been using is the one specified in the command. You were > right that the errors above seem to indicate an older HAProxy not being shut > down properly, but even if I ensure a full stop and removal of pid before > issuing a start... that particular error goes away but the initial problem > still persists. After doing some more digging, I've noticed that if I... > curl http://localhost/ > ...immediately after a restart/start it will go through successfully, but > then subsequent calls and/or if I don't issue the command quick enough, will > timeout. > But the calls to... > curl http://localhost:7000/ > ...will still go through. So it appears as though it can bind, but then > relinquishes control to something else? could you disable health checks ? I wonder if your "quick enough" above means "before the first health check". Willy
Re: strange issues with IE 6
Hello, On Wed, Aug 04, 2010 at 05:24:26PM +0200, eni-urgence wrote: > Hello. > >I have removed the friendly error message from IE and it display a > blank page. > I have not mentionned that i have stunnel in front of haproxy for ssl > termination. I have made some test and capture packet and i think that > it's stunnel that don't work. > I will make more test. IE6 does not like SSL much. I remember about an option in Stunnel to be MSIE-friendly when closing connections (basically, send a close packet before closing). Since IE6 can display arbitrary error pages unrelated to what it got on the wire, it's hard to debug. Still, there is one possibility we've not examined : the page which returns 200 might return a JS-based redirect which immediately tries to fetch from another site then gets the 404. Regards, Willy
Re: Haproxy filter by destination ip
On Wed, Aug 04, 2010 at 01:03:28PM +0100, Chris Sarginson wrote: > Isn't this just done by configuring seperate listen section: > > listen IP1 172.200.17.3:80 > default_backend backend1 > > listen IP2 172.17.200.17.4:80 > default_backend backend2 > > Or is there something further about your solution that I'm missing here? also if it's for combining with ACLs, it's possible to use the "dst" match to check the destination IP address. Regards, Willy
Re: HAProxy Setup not talking to Passenger/Apache
On Aug 4, 2010, at 4:09 PM, Willy Tarreau wrote: > On Wed, Aug 04, 2010 at 09:40:35AM -0500, Nick Hilem wrote: >> The netstat only appears to show the latest HAProxy being run and the config >> file that I've been using is the one specified in the command. You were >> right that the errors above seem to indicate an older HAProxy not being shut >> down properly, but even if I ensure a full stop and removal of pid before >> issuing a start... that particular error goes away but the initial problem >> still persists. After doing some more digging, I've noticed that if I... >> curl http://localhost/ >> ...immediately after a restart/start it will go through successfully, but >> then subsequent calls and/or if I don't issue the command quick enough, will >> timeout. >> But the calls to... >> curl http://localhost:7000/ >> ...will still go through. So it appears as though it can bind, but then >> relinquishes control to something else? > > could you disable health checks ? I wonder if your "quick enough" above > means "before the first health check". Not sure how to determine if it was before or not... but I disabled the health checks and it appears to respond the same. > Willy >
Re: clarification of CD termination code
In the tcpdump listed below, isn't the next-to-the-last RST also include an ACK of the data previously sent? If that is the case, then the client has received all of the data and ACK'd it but then rudely closed the TCP connection without the normal FIN exchange. Is my reading correct? 19:03:33.106842 IP 10.79.25.20.4266 > 10.79.6.10.80: S 2041799057:2041799057(0) win 65535 19:03:33.106862 IP 10.79.6.10.80 > 10.79.25.20.4266: S 266508528:266508528(0) ack 2041799058 win 5840 19:03:33.106945 IP 10.79.25.20.4266 > 10.79.6.10.80: . ack 1 win 65535 19:03:33.107045 IP 10.79.25.20.4266 > 10.79.6.10.80: P 1:269(268) ack 1 win 65535 19:03:33.107060 IP 10.79.6.10.80 > 10.79.25.20.4266: . ack 269 win 6432 19:03:33.134401 IP 10.79.6.10.80 > 10.79.25.20.4266: P 1:270(269) ack 269 win 6432 19:03:33.134442 IP 10.79.6.10.80 > 10.79.25.20.4266: F 270:270(0) ack 269 win 6432 19:03:33.134548 IP 10.79.25.20.4266 > 10.79.6.10.80: R 269:269(0) ack 270 win 0 19:03:33.134562 IP 10.79.25.20.4266 > 10.79.6.10.80: R 2041799326:2041799326(0) win 0 -Bryan On Mon, Aug 2, 2010 at 10:45 PM, Willy Tarreau wrote: > On Wed, Jul 28, 2010 at 05:51:18PM -0700, Bryan Talbot wrote: > > I'm trying to figure out what _exactly_ the CD termination code means. > The > > docs says: > > > > CD The client unexpectedly aborted during data transfer. This can > be > > caused by a browser crash, by an intermediate equipment between > the > > client and haproxy which decided to actively break the > connection, > > by network routing issues between the client and haproxy, or by > a > > keep-alive session between the server and the client terminated > first > > by the client. > > > > > > Does this mean that clients MUST have not received some of the data or > > could a client have received all of the data from the response? > > it means that the client closed the response socket before all data was > consumed. > > > What's an unexpected abortion vs a normal termination? > > An unexpected abortion is when the system reports a socket error while > there were still some data to send in the buffer. A normal termination > is when there is no error and that all pending data were sent before > the client closed. > > > I have a client (windows using a MS xml library to make http requests) > > which always ends up with CD-- terminations, but the software seems to > > work properly otherwise. > > It is possible that this client only needs something at the very > beginning of the response and that it aborts connections once it > gets what it needs. This is what happens with health checks too > if too large objects are sent in response. From a protocol point > of view this can be seen as dirty, but if the client does not need > anything else, it results in cheaper network use because less data > get transferred. > > If you're sure to see this for every request, it would be nice to > get a capture of a full request/response from both sides to see > what it looks like (use tcpdump -s0 to get full packets). I suspect > that you'll see an RST packet coming from the client to haproxy > while haproxy is sending data. > > Regards, > Willy > >
Re: clarification of CD termination code
On Thu, Aug 5, 2010 at 7:29 AM, Bryan Talbot wrote: > In the tcpdump listed below, isn't the next-to-the-last RST also include an > ACK of the data previously sent? If that is the case, then the client has > received all of the data and ACK'd it but then rudely closed the TCP > connection without the normal FIN exchange. Is my reading correct? > > 19:03:33.106842 IP 10.79.25.20.4266 > 10.79.6.10.80: S > 2041799057:2041799057(0) win 65535 > 19:03:33.106862 IP 10.79.6.10.80 > 10.79.25.20.4266: S > 266508528:266508528(0) ack 2041799058 win 5840 > 19:03:33.106945 IP 10.79.25.20.4266 > 10.79.6.10.80: . ack 1 win 65535 > 19:03:33.107045 IP 10.79.25.20.4266 > 10.79.6.10.80: P 1:269(268) ack 1 win > 65535 > 19:03:33.107060 IP 10.79.6.10.80 > 10.79.25.20.4266: . ack 269 win 6432 > 19:03:33.134401 IP 10.79.6.10.80 > 10.79.25.20.4266: P 1:270(269) ack 269 > win 6432 > 19:03:33.134442 IP 10.79.6.10.80 > 10.79.25.20.4266: F 270:270(0) ack 269 > win 6432 > 19:03:33.134548 IP 10.79.25.20.4266 > 10.79.6.10.80: R 269:269(0) ack 270 > win 0 > 19:03:33.134562 IP 10.79.25.20.4266 > 10.79.6.10.80: R > 2041799326:2041799326(0) win 0 > > yes - i've encountered this myself, and after looking into the traffic, observed the very same thing from windows clients... Definitely frustrating behaviour in terms of causing all these alerts in the logs... -jf -- "Every nonfree program has a lord, a master -- and if you use the program, he is your master." --Richard Stallman "It's so hard to write a graphics driver that open-sourcing it would not help." -- Andrew Fear, Software Product Manager, NVIDIA Corporation http://kerneltrap.org/node/7228
Re: HAProxy Setup not talking to Passenger/Apache
On Wed, Aug 04, 2010 at 04:24:56PM -0500, Nick Hilem wrote: > Not sure how to determine if it was before or not... but I disabled the > health checks and it appears to respond the same. you mean the same as with checks or the same as without haproxy ? Willy
Re: clarification of CD termination code
On Wed, Aug 04, 2010 at 04:29:08PM -0700, Bryan Talbot wrote: > In the tcpdump listed below, isn't the next-to-the-last RST also include an > ACK of the data previously sent? If that is the case, then the client has > received all of the data and ACK'd it but then rudely closed the TCP > connection without the normal FIN exchange. Is my reading correct? Yes, that looks like it, though the RST's ACK does not seem to cover the FIN (otherwise it would be 271). While "rude", doing this is unfortutenately necessary when the client has to close the connection itself, otherwise if it closes cleanly, it will be subject to the 2-MSL TCP delay which prevents it from reusing the same source port for a few minutes. So closing that way ensures that the connection is aborted and that the port can be reused ASAP. If you take a trace between a haproxy and a server when haproxy is configured with "option forceclose", you will see the same termination sequence. BTW, for better traces, you should use the '-S' option with tcpdump, so that it does not try to use relative sequence numbers, because here we have a mix of absolute and relative, which is harder to read. > 19:03:33.106842 IP 10.79.25.20.4266 > 10.79.6.10.80: S > 2041799057:2041799057(0) win 65535 > 19:03:33.106862 IP 10.79.6.10.80 > 10.79.25.20.4266: S 266508528:266508528(0) > ack 2041799058 win 5840 > 19:03:33.106945 IP 10.79.25.20.4266 > 10.79.6.10.80: . ack 1 win 65535 > 19:03:33.107045 IP 10.79.25.20.4266 > 10.79.6.10.80: P 1:269(268) ack 1 win > 65535 > 19:03:33.107060 IP 10.79.6.10.80 > 10.79.25.20.4266: . ack 269 win 6432 > 19:03:33.134401 IP 10.79.6.10.80 > 10.79.25.20.4266: P 1:270(269) ack 269 win > 6432 > 19:03:33.134442 IP 10.79.6.10.80 > 10.79.25.20.4266: F 270:270(0) ack 269 win > 6432 > 19:03:33.134548 IP 10.79.25.20.4266 > 10.79.6.10.80: R 269:269(0) ack 270 win > 0 > 19:03:33.134562 IP 10.79.25.20.4266 > 10.79.6.10.80: R > 2041799326:2041799326(0) win 0 > > > -Bryan Regards, Willy
Re: HAProxy Setup not talking to Passenger/Apache
I think something else is going on - do you have iptables running? Is it redir-ing from 80 to 7000 or something? What if you just run haproxy on web01 and apache/blah on web02 and comment out web01 in your haproxy config so you have just one path to debug to start. On 8/4/10 9:44 PM, Willy Tarreau wrote: On Wed, Aug 04, 2010 at 04:24:56PM -0500, Nick Hilem wrote: Not sure how to determine if it was before or not... but I disabled the health checks and it appears to respond the same. you mean the same as with checks or the same as without haproxy ? Willy
