RE: HAProxy Redirect Domain While Retaining Original Domain Name In URL

2015-06-16 Thread Lukas Tribus
Hi Brian,


 Thanks for your suggestion. Unfortunately it's not clear how I would
 use this command and format it when doing a redirect. I read the
 HAProxy 1.5 documentation, but it wasn't detailed enough.

You don't want a redirect, you explicitly asked for a rewrite:
retaining original domain name in URL.

This is a rewrite, not a redirect.

With my suggestion you are replacing the Host header.

Is that not what you want? What do you want?



Please Replay to All including the mailing list, thank you.


Lukas

  


[Cohesive Networks] Listing HA Proxy published

2015-06-16 Thread Cohesive Networks
Your listing "HA Proxy" is now available at http://cohesive-networks.com/partners/directory/7699/ha-proxy/ and can be viewed by the public.



Re: Receiving HTTP responses to TCP pool

2015-06-16 Thread PiBa-NL

Its a feature, a frontend running with tcp can use a backend using http.
If you want both to use tcp either put that in the defaults, or specify 
it for both frontendbackend.


It seems to me your assumption that the backend automaticaly takes over 
the mode from the frontend is wrong. Perhaps a documentation change 
could prevent this configuration mistake from being made by others.. To 
clarify that setting it in the frontend does not mean it doesnt need to 
also be set in the backend.


CJ Ess schreef op 16-6-2015 om 23:33:
I think that nails the problem. So if its not just me then the 
question is if this is intended behavior or if its a bug. If its 
intended then I don't think its entirely clear from the documentation 
that 'mode tcp' only works under certain circumstances. If we confirm 
that its a bug then I'd be willing to see if I can track it down and 
fix it.



On Tue, Jun 16, 2015 at 4:39 PM, PiBa-NL piba.nl@gmail.com 
mailto:piba.nl@gmail.com wrote:


Which does not prevent the backend from using mode http as the
defaults section sets.

CJ Ess schreef op 16-6-2015 om 22:36:

mode tcp is already present in mainfrontend definition below
the bind statement


On Mon, Jun 15, 2015 at 3:05 PM, PiBa-NL piba.nl@gmail.com
mailto:piba.nl@gmail.com wrote:

CJ Ess schreef op 15-6-2015 om 20:52:

This one has me stumped - I'm trying to proxy SMTP
connections however I'm getting an HTTP response when I try
to connect to port 25 (even though I've done mode tcp).

This is the smallest subset that reproduced the problem - I
can make this work by doing mode tcp in the default
section and then doing mode http in all of the http
frontends (not shown). But doing 'mode http' as default and
then 'mode tcp' in the smtp frontend definition seems to not
work and I'm not certain why.

global
  daemon
  maxconn 10240
  log 127.0.0.1 local0
  log 127.0.0.1 local1 notice
  stats socket /var/run/haproxy.sock user root group root
mode 600 level admin
  stats timeout 2m

defaults
  log global
  modehttp
  timeout client 30s
  timeout server 30s
  timeout connect 4s
  option  socket-stats

frontend mainfrontend
  bind *:25
  mode tcp
  maxconn 10240
  option smtpchk EHLO example.com http://example.com
  default_backend mxpool

backend mxpool

add:
mode tcp

  balance roundrobin
  server mailparser-xxx 172.0.0.51:25 http://172.0.0.51:25
check port 25 weight 20 maxconn 10240
  server mailparser-yyy 172.0.0.67:25 http://172.0.0.67:25
check port 25 weight 20 maxconn 10240











Re: Receiving HTTP responses to TCP pool

2015-06-16 Thread CJ Ess
I think that nails the problem. So if its not just me then the question is
if this is intended behavior or if its a bug. If its intended then I don't
think its entirely clear from the documentation that 'mode tcp' only works
under certain circumstances. If we confirm that its a bug then I'd be
willing to see if I can track it down and fix it.


On Tue, Jun 16, 2015 at 4:39 PM, PiBa-NL piba.nl@gmail.com wrote:

  Which does not prevent the backend from using mode http as the defaults
 section sets.

 CJ Ess schreef op 16-6-2015 om 22:36:

 mode tcp is already present in mainfrontend definition below the bind
 statement


 On Mon, Jun 15, 2015 at 3:05 PM, PiBa-NL piba.nl@gmail.com wrote:

  CJ Ess schreef op 15-6-2015 om 20:52:

 This one has me stumped - I'm trying to proxy SMTP connections however
 I'm getting an HTTP response when I try to connect to port 25 (even though
 I've done mode tcp).

  This is the smallest subset that reproduced the problem - I can make
 this work by doing mode tcp in the default section and then doing mode
 http in all of the http frontends (not shown). But doing 'mode http' as
 default and then 'mode tcp' in the smtp frontend definition seems to not
 work and I'm not certain why.

  global
   daemon
   maxconn 10240
   log 127.0.0.1 local0
   log 127.0.0.1 local1 notice
   stats socket /var/run/haproxy.sock user root group root mode 600 level
 admin
   stats timeout 2m

  defaults
   log global
   modehttp
   timeout client 30s
   timeout server 30s
   timeout connect 4s
   option  socket-stats

  frontend mainfrontend
   bind *:25
   mode tcp
   maxconn 10240
   option smtpchk EHLO example.com
   default_backend mxpool

  backend mxpool

  add:
 mode tcp

balance roundrobin
   server mailparser-xxx 172.0.0.51:25 check port 25 weight 20 maxconn
 10240
   server mailparser-yyy 172.0.0.67:25 check port 25 weight 20 maxconn
 10240







RE: HAProxy Redirect Domain While Retaining Original Domain Name In URL

2015-06-16 Thread BGaudreault Brian
Hi, yes, we do want a rewrite.  The initial request that came to us also 
included a request to redirect at the same time, but now that I think about 
this (since it's my first time trying to accomplish this) I think we can just 
do a rewrite.

EXAMPLE: alias.com  alias.com/path (this path is on backend servers that 
domain.com points to).  Originally I was thinking I would have to do the 
following: alias.com  domain.com/path  replace domain.com with alias.com  
end up with alias.com/path.

If we're connecting to alias.com/path now, would the backend servers for 
domain.com need extra configuration?  Would we need them to accept incoming 
requests for alias.com as another VirtualHost?

Thanks

-Original Message-
From: Lukas Tribus [mailto:luky...@hotmail.com] 
Sent: Tuesday, June 16, 2015 8:28 AM
To: BGaudreault Brian; haproxy@formilux.org
Subject: RE: HAProxy Redirect Domain While Retaining Original Domain Name In URL

Hi Brian,

 Thanks for your suggestion. Unfortunately it's not clear how I would 
 use this command and format it when doing a redirect. I read the 
 HAProxy 1.5 documentation, but it wasn't detailed enough.

You don't want a redirect, you explicitly asked for a rewrite:
retaining original domain name in URL.

This is a rewrite, not a redirect.

With my suggestion you are replacing the Host header.

Is that not what you want? What do you want?



Please Replay to All including the mailing list, thank you.


Lukas

  



Re: Receiving HTTP responses to TCP pool

2015-06-16 Thread PiBa-NL
Which does not prevent the backend from using mode http as the defaults 
section sets.


CJ Ess schreef op 16-6-2015 om 22:36:
mode tcp is already present in mainfrontend definition below the 
bind statement



On Mon, Jun 15, 2015 at 3:05 PM, PiBa-NL piba.nl@gmail.com 
mailto:piba.nl@gmail.com wrote:


CJ Ess schreef op 15-6-2015 om 20:52:

This one has me stumped - I'm trying to proxy SMTP connections
however I'm getting an HTTP response when I try to connect to
port 25 (even though I've done mode tcp).

This is the smallest subset that reproduced the problem - I can
make this work by doing mode tcp in the default section and
then doing mode http in all of the http frontends (not shown).
But doing 'mode http' as default and then 'mode tcp' in the smtp
frontend definition seems to not work and I'm not certain why.

global
  daemon
  maxconn 10240
  log 127.0.0.1 local0
  log 127.0.0.1 local1 notice
  stats socket /var/run/haproxy.sock user root group root mode
600 level admin
  stats timeout 2m

defaults
  log global
  modehttp
  timeout client 30s
  timeout server 30s
  timeout connect 4s
  option  socket-stats

frontend mainfrontend
  bind *:25
  mode tcp
  maxconn 10240
  option smtpchk EHLO example.com http://example.com
  default_backend mxpool

backend mxpool

add:
mode tcp

  balance roundrobin
  server mailparser-xxx 172.0.0.51:25 http://172.0.0.51:25
check port 25 weight 20 maxconn 10240
  server mailparser-yyy 172.0.0.67:25 http://172.0.0.67:25
check port 25 weight 20 maxconn 10240








Re: Receiving HTTP responses to TCP pool

2015-06-16 Thread CJ Ess
mode tcp is already present in mainfrontend definition below the bind
statement


On Mon, Jun 15, 2015 at 3:05 PM, PiBa-NL piba.nl@gmail.com wrote:

  CJ Ess schreef op 15-6-2015 om 20:52:

 This one has me stumped - I'm trying to proxy SMTP connections however I'm
 getting an HTTP response when I try to connect to port 25 (even though I've
 done mode tcp).

  This is the smallest subset that reproduced the problem - I can make
 this work by doing mode tcp in the default section and then doing mode
 http in all of the http frontends (not shown). But doing 'mode http' as
 default and then 'mode tcp' in the smtp frontend definition seems to not
 work and I'm not certain why.

  global
   daemon
   maxconn 10240
   log 127.0.0.1 local0
   log 127.0.0.1 local1 notice
   stats socket /var/run/haproxy.sock user root group root mode 600 level
 admin
   stats timeout 2m

  defaults
   log global
   modehttp
   timeout client 30s
   timeout server 30s
   timeout connect 4s
   option  socket-stats

  frontend mainfrontend
   bind *:25
   mode tcp
   maxconn 10240
   option smtpchk EHLO example.com
   default_backend mxpool

  backend mxpool

 add:
 mode tcp

balance roundrobin
   server mailparser-xxx 172.0.0.51:25 check port 25 weight 20 maxconn
 10240
   server mailparser-yyy 172.0.0.67:25 check port 25 weight 20 maxconn
 10240





Re: Does haproxy use lt or et mode of epoll ?

2015-06-16 Thread Willy Tarreau
On Mon, Jun 15, 2015 at 02:48:13PM +0200, Lukas Tribus wrote:
  Subject: Does haproxy use lt or et mode of epoll ? 
  
  thanks 
 
 Level-triggered, if I understand the following commit correctly:
 
 http://www.haproxy.org/git?p=haproxy.git;a=commit;h=6c11bd2f89eb043fd493d77b784198e90e0a01b2

Confirmed. A long time ago I wanted to implement epoll-et and as time
passed and as the code got smarter, I figured that it would not provide
any benefit anymore given that we don't call epoll_ctl() much. Forwarded
traffic always blocks in the same direction (typically waiting for the
client to read response data), and as haproxy implements an event cache
it doesn't need to change the polling status between a wake-up, the
operation attempt and waiting for its completion. It's quite common to
see around 1-2 epoll_ctl() calls per session, which is the minimum we'd
have using epoll-et anyway.

Willy




Health check of backends without explicit health-check?

2015-06-16 Thread Krishna Kumar (Engineering)
Hi list,

Is there any way to log, or report, or notify, or identify any backend
that is not responding, without using explicit health-checks? The
reason for this is that we are planning a big deployment of LB/servers,
something along the lines of:

LB1, LB2, LB100 or more
^
|
v
Thousands of servers as backends

where many of the LB's could share the same backend. Doing a health-
check from many LB's to the same servers is a possible load issue on
the servers. Is there any other way, based on response timeout, or
something else, to determine which of the backends are not responding,
and be able to retrieve that information?

Thanks,
- Krishna Kumar

-- 


--

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited. Although Flipkart has taken reasonable precautions to ensure no 
viruses are present in this email, the company cannot accept responsibility 
for any loss or damage arising from the use of this email or attachments