Summer Vacations in Puerto Vallarta

2009-05-29 Thread Las Palmas by the Sea 




	
		
			

		
	



	
		
			

		
	



	
		
			

		
	



	
		
			

		
	



	
		
			

		
	



	
		
			

		
	



	
		
			
This is an exclusive promotion by Las Palmas by the Sea
Telephone in Mexico     +52 (322) 224 0347
Los Angeles, CA     (310) 598 2091
New York, NY     (212) 845 9362
All reservations are subject to availability
Click here to receive more promotions
Click here to unsubscribe from our mailing list

RE: An IE bug and HAproxy?

2009-05-29 Thread John Lauro 
Are you certain there is no issue with the web server?  I have seen (years
ago, prior to my use with haproxy) apache produce strange problems like this
for ie that firefox was able to cope with if it's access_log file reached
2GB.  On a busy server, that is easily reached in days or sooner, and
typically it's only rotated weekly by default.  Have you tried bypassing
haproxy to whichever server(s) you are certain you are seeing the issue on?


> none of which can be seen between Stunnel and the browser. Of course
> the
> problem could also be Stunnel? But a further piece of data points to
> HAproxy: one of the web servers is installed in the same machine as
> HAproxy
> and that specific server doesn't seem to suffer from this same problem.
> If
> the culprit was Stunnel I should imagine that there couldn't be any
> differences between servers as all the data it gets is from HAproxy.
> These
> computers have firewall (Shorewall), but firewalls were temporary not
> in use
> when this data was collected. And as the capture shows the ACKs send by
> the
> machine B hosting the web server were received on the computer A
> hosting
> HAproxy & Stunnel.
> 
> This is admittedly a difficult bug to trace as IE works OK most of the
> time
> and so the problem is difficult to reproduce. It is also possible that
> this
> has nothing to do with IE and it has only been a coindicence that IE is
> affected.
> 
> I am soon leaving for a trip for but will join the discussion when I am
> back. You all have a nice early summer.

RE: An IE bug and HAproxy?

2009-05-29 Thread John Doe 
Hi. I forgot to tell that we are using version 1.3.17.
 

__ Information from ESET NOD32 Antivirus, version of virus signature
database 4115 (20090529) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: An IE bug and HAproxy?

2009-05-29 Thread John Doe 
Hi

>-Original Message-
>From: pet...@gmx-ist-cool.de [mailto:pet...@gmx-ist-cool.de] 
>Sent: 28. toukokuuta 2009 18:12
>To: haproxy@formilux.org
>Subject: Re: An IE bug and HAproxy?
>I run into a similar problem, when using haproxy version greater 1.3.16 in
conjunction with ssl (stunnel). After a >post no data was sent back to IE.
Using firefox everything is fine. 
>
>I also noticed that the order of the entries on the statistic's page
changed with the new versions.

I have hopefully some additional info. I managed to collect data with
Wireshark on the same computer HAproxy and Stunnel is installed. 

Here's the data between the browser (xxx.xxx.xxx.xxx) and Stunnel
(10.1.1.111):

"4991","12:00:16.127353","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TCP"
,"4191 > https [ACK] Seq=1 Ack=1 Win=17520 Len=0"
"4992","12:00:16.129101","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Client Hello, [Unreassembled Packet] "
"4993","12:00:16.129110","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=1 Ack=103 Win=5840 Len=0"
"4994","12:00:16.129254","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TLSv
1","Server Hello, [Packet size limited during capture]"
"4995","12:00:16.144093","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Change Cipher Spec, Encrypted Handshake Message, [Unreassembled Packet]
"
"4996","12:00:16.154336","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Application Data, [Unreassembled Packet] "
"4997","12:00:16.154344","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=123 Ack=1272 Win=7882 Len=0"
"5003","12:00:16.159832","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Application Data, [Unreassembled Packet] "
"5004","12:00:16.165080","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5005","12:00:16.165086","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=123 Ack=4192 Win=13140 Len=0"
"5006","12:00:16.173575","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5007","12:00:16.178821","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5008","12:00:16.178827","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=123 Ack=7112 Win=18980 Len=0"
"5009","12:00:16.184443","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5010","12:00:16.189565","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5011","12:00:16.189571","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=123 Ack=10032 Win=24820 Len=0"
"5012","12:00:16.194812","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5013","12:00:16.200184","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5014","12:00:16.200190","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=123 Ack=12952 Win=30660 Len=0"
"5015","12:00:16.205556","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Encrypted Alert, [Unreassembled Packet] "
"5016","12:00:16.208180","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TLSv
1","Ignored Unknown Record, [Packet size limited during capture]"
"5017","12:00:16.208185","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TCP"
,"https > 4191 [ACK] Seq=123 Ack=15258 Win=33580 Len=0"
"23637","12:01:17.141752","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TLS
v1","Application Data, [Unreassembled Packet] "
"23641","12:01:17.141894","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TLS
v1","Application Data, [Unreassembled Packet] "
"23642","12:01:17.141977","10.1.1.111","https","xxx.xxx.xxx.xxx","4191","TLS
v1","Ignored Unknown Record, [Packet size limited during capture]"
"23650","12:01:17.162884","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TCP
","4191 > https [ACK] Seq=15258 Ack=1898 Win=17520 Len=0"
"23653","12:01:17.163960","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TCP
","4191 > https [ACK] Seq=15258 Ack=2116 Win=17303 Len=0"
"23654","12:01:17.164606","xxx.xxx.xxx.xxx","4191","10.1.1.111","https","TCP
","4191 > https [RST, ACK] Seq=15258 Ack=2116 Win=0 Len=0"

and here the data between HAproxy (10.1.1.200) and the web server
(10.1.1.222):

"4998","12:00:16.154462","10.1.1.200","53757","10.1.1.222","http","TCP","537
57 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=3515036725 TSER=0 WS=0"
"4999","12:00:16.154586","10.1.1.222","http","10.1.1.200","53757","TCP","htt
p > 53757 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=445520735
TSER=3515036725 WS=2"
"5000","12:00:16.154604","10.1.1.200","53757","10.1.1.222","http","TCP","537
57 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=3

migrate from mod_proxy_balancer to haproxy ?

2009-05-29 Thread Jan-Frode Myklebust 
We have 2 loadbalancers in failover configuration, using
mod_proxy_balancer for web and haproxy for pop/imap. I
want to move to using haproxy also for the web-part, but
am a bit uncertain how to most smoothly accomplish this.

The mod_proxy_balancer is balancing over 5 backend hosts,
using a cookie the backend host sets by this apache config:

RewriteEngine On
RewriteRule .* - [CO=altiatmailbalance:balancer.hostX:.example.net:70]

and this is the mod_proxy_balancer config:

ProxyStatus On

BalancerMember  http://host1.example.net:80 route=host1 
loadfactor=100 retry=10
BalancerMember  http://host2.example.net:80 route=host2 
loadfactor=100 retry=10
BalancerMember  http://host3.example.net:80 route=host3 
loadfactor=100 retry=10
BalancerMember  http://host4.example.net:80 route=host4 
loadfactor=100 retry=10
BalancerMember  http://host5.example.net:80 route=host5 
loadfactor=10 retry=10

ProxyPass /mail/ balancer://atmailcluster/mail/ lbmethod=byrequests 
stickysession=altiatmailbalance
ProxyPassReverse /mail/ balancer://atmailcluster/mail/

So mod_proxy_balancer looks at the cookie altiatmailbalance,
and route the request to the hostname listed in after the dot
in the value (balancer.host1 goes to host1). I've no idea what 
the point of the "balancer." part is..

So, my questions: 

o Can haproxy use the same cookie to select backend worker ? I don't
  want it to set it, just use it.

o What's the suggested way of handling https here? Should I
  keep apache, and have it proxy everything to hapr...@localhost 
  (with hapr...@loadbalancer2 as backup), or is a stunnel from
  port 443 -> 80 a better alternativ ?


  -jf