Re: Failed to use the source address for outgoing connections
Hi,
(it's strange I didn't get the original e-mail).
On Tue, Apr 23, 2013 at 6:27 AM, Godbach nylzhao...@gmail.com wrote:
Hi, all
I have tested 'source' config in haproxy-1.5-dev18, but it didn't work
with the following line in default section:
source 0.0.0.0 usesrc clientip
Other related settings by iptables and ip rule have been set correctly.
There are some codes in cfg_parse_listen() (Line 1812-1815 in lastest
commit) to do source function init for a new backend proxy as below
if (defproxy.conn_src.iface_name)
curproxy-conn_src.iface_name =
strdup(defproxy.conn_src.iface_name);
curproxy-conn_src.iface_len = defproxy.conn_src.iface_len;
curproxy-conn_src.opts = defproxy.conn_src.opts ~CO_SRC_TPROXY_MASK;
The last line of codes will set the value of opts represents such as
'client', 'clientip' and so on in defproxy to current backend proxy. But
I was confused that why clear the low three bits. CO_SRC_TPROXY_MASK is
defined in include/types/connection.h as below:
/* source address settings for outgoing connections */
enum {
/* Tproxy exclusive values from 0 to 7 */
CO_SRC_TPROXY_ADDR = 0x0001,/* bind to this non-local address
when connecting */
CO_SRC_TPROXY_CIP = 0x0002,/* bind to the client's IP address
when connecting */
CO_SRC_TPROXY_CLI = 0x0003,/* bind to the client's IP+port
when connecting */
CO_SRC_TPROXY_DYN = 0x0004,/* bind to a dynamically computed
non-local address */
CO_SRC_TPROXY_MASK = 0x0007,/* bind to a non-local address when
connecting */
CO_SRC_BIND= 0x0008,/* bind to a specific source
address when connecting */
};
The low three bits store the configuration of usesrc, they should be
copied to the backend proxy without modified. But they were clear in
backend proxy actually.
Then I put source configuration 'source 0.0.0.0 usesrc clientip' in
backend section, the source function can work well.
So in my opinion, the code
curproxy-conn_src.opts = defproxy.conn_src.opts ~CO_SRC_TPROXY_MASK;
shoulde be modifed as below:
curproxy-conn_src.opts = defproxy.conn_src.opts;
Godbach, thanks for your analysis, you're perfectly right. I've looked
at the code and before dev15, the bind options were set in the proxy's
options, covered by PR_O_TPXY_MASK, and these bits were not cleared when
creating a new backend from the default section. Since commit ef9a3605,
we have dedicated options for this and indeed the bits are cleared.
Please confirm the modification you suggest works (specifically binding
to an explicit sources address such as source 0.0.0.0 usesrc 1.2.3.4),
and if that's OK, please send a patch which I'll happily apply. You can
reuse your analysis above as the commit message, it's perfectly clear!
Best regards,
Willy
Hi, Willy
I have tested the configuration you suggested with the following patch:
diff --git a/src/cfgparse.c b/src/cfgparse.c
index cc515a2..3514e83 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1812,7 +1812,7 @@ int cfg_parse_listen(const char *file, int
linenum, char **args, int kwm)
if (defproxy.conn_src.iface_name)
curproxy-conn_src.iface_name =
strdup(defproxy.conn_src.iface_name);
curproxy-conn_src.iface_len =
defproxy.conn_src.iface_len;
- curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
+ curproxy-conn_src.opts = defproxy.conn_src.opts;
}
if (curproxy-cap PR_CAP_FE) {
With explicit source address set, it still can not work well in default
section, and can work well in backend section.
Wiht 'usesrc client' configuration, it can work well both in default and
backend section after applying the above patch.
I will go on debugging this problem.
Best Regards,
Godbach
Re: Implementing a simplest load balancer for socket based servers
On Tue, Apr 23, 2013 at 10:31:52AM +0400, Md Mahbubul Islam wrote: Hi Willy, Thank you very much for your reply. Your assumption is correct . I am using TCP. The load-balancer and all other servers are Java socket servers. From your mail I got the idea that if I could pass the client's file descriptor to the desired server and establish connection between the client and the new server , it might be possible to disconnect the load balancer from client. I will do some more research on it. And if you have any idea about how I can pass the file descriptor between different servers and establish connection between the new server and the client , will be helpful. As I said, this can only be done over UNIX sockets, not over TCP sockets. Someone has asked here some time ago that we implement this into haproxy and it's not that far from being possible. You should look at man 7 unix and search for SCM_RIGHTS, you'll find there everything you need to pass an fd over a unix socket. Willy
Re: Failed to use the source address for outgoing connections
On Tue, Apr 23, 2013 at 02:44:17PM +0800, Godbach wrote:
Hi,
(it's strange I didn't get the original e-mail).
On Tue, Apr 23, 2013 at 6:27 AM, Godbach nylzhao...@gmail.com wrote:
Hi, all
I have tested 'source' config in haproxy-1.5-dev18, but it didn't work
with the following line in default section:
source 0.0.0.0 usesrc clientip
Other related settings by iptables and ip rule have been set correctly.
There are some codes in cfg_parse_listen() (Line 1812-1815 in lastest
commit) to do source function init for a new backend proxy as below
if (defproxy.conn_src.iface_name)
curproxy-conn_src.iface_name =
strdup(defproxy.conn_src.iface_name);
curproxy-conn_src.iface_len = defproxy.conn_src.iface_len;
curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
The last line of codes will set the value of opts represents such as
'client', 'clientip' and so on in defproxy to current backend proxy. But
I was confused that why clear the low three bits. CO_SRC_TPROXY_MASK is
defined in include/types/connection.h as below:
/* source address settings for outgoing connections */
enum {
/* Tproxy exclusive values from 0 to 7 */
CO_SRC_TPROXY_ADDR = 0x0001,/* bind to this non-local
address
when connecting */
CO_SRC_TPROXY_CIP = 0x0002,/* bind to the client's IP
address
when connecting */
CO_SRC_TPROXY_CLI = 0x0003,/* bind to the client's IP+port
when connecting */
CO_SRC_TPROXY_DYN = 0x0004,/* bind to a dynamically
computed
non-local address */
CO_SRC_TPROXY_MASK = 0x0007,/* bind to a non-local address
when
connecting */
CO_SRC_BIND= 0x0008,/* bind to a specific source
address when connecting */
};
The low three bits store the configuration of usesrc, they should be
copied to the backend proxy without modified. But they were clear in
backend proxy actually.
Then I put source configuration 'source 0.0.0.0 usesrc clientip' in
backend section, the source function can work well.
So in my opinion, the code
curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
shoulde be modifed as below:
curproxy-conn_src.opts = defproxy.conn_src.opts;
Godbach, thanks for your analysis, you're perfectly right. I've looked
at the code and before dev15, the bind options were set in the proxy's
options, covered by PR_O_TPXY_MASK, and these bits were not cleared when
creating a new backend from the default section. Since commit ef9a3605,
we have dedicated options for this and indeed the bits are cleared.
Please confirm the modification you suggest works (specifically binding
to an explicit sources address such as source 0.0.0.0 usesrc 1.2.3.4),
and if that's OK, please send a patch which I'll happily apply. You can
reuse your analysis above as the commit message, it's perfectly clear!
Best regards,
Willy
Hi, Willy
I have tested the configuration you suggested with the following patch:
diff --git a/src/cfgparse.c b/src/cfgparse.c
index cc515a2..3514e83 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1812,7 +1812,7 @@ int cfg_parse_listen(const char *file, int
linenum, char **args, int kwm)
if (defproxy.conn_src.iface_name)
curproxy-conn_src.iface_name =
strdup(defproxy.conn_src.iface_name);
curproxy-conn_src.iface_len =
defproxy.conn_src.iface_len;
- curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
+ curproxy-conn_src.opts = defproxy.conn_src.opts;
}
if (curproxy-cap PR_CAP_FE) {
With explicit source address set, it still can not work well in default
section, and can work well in backend section.
Wiht 'usesrc client' configuration, it can work well both in default and
backend section after applying the above patch.
I will go on debugging this problem.
Thanks, so maybe that was the reason for clearing the flags, which was
still a stupid solution in my opinion :-/
I *believe* we don't keep the address in the default proxy, this is something
to be confirmed anyway, as it would be possible that we simply don't copy it
in fact.
Best regards,
Willy
Re: To detect when TCP connection goes down
Hi, Baptiste Hi, 1. you can use a client timeout (and a server timeout too) 2. You can use the observe feature for this purpose. Read the doc, it points to a few other keyword which may help as well. Baptiste Thanks for your answer If a client ( socket ) tries to connect to HA Proxy and all backend servers are DOWN , neither connection error (checking layer 4) or timeout happens because HA Proxy returns an EOF (better explained, my underlaying networking software returns EOF ) OK , I can detect this case but I don't like it , because I don't know what is returning an EOF ( HA Proxy / backend server ) The real problem is when a backend server goes DOWN after client sent data Client ( socket ) doesn't receive a Connection reset because it is still connected to HA Proxy I guess the underlaying networking software discards an incomplete data and returns an EOF . So, in the worst option, I can check if client gets an EOF and , in this case, to retry the connection I just wonder if it would be possible to transfer the connection errors when happening in HA-Proxy ---backend link, to client . For example, Connection reset by peer, Connect refused , etc. Thanks On Mon, Apr 22, 2013 at 6:26 PM, Jose María Zaragoza demablo...@gmail.com wrote: Hi: I've got basic questions about HA Proxy ( 1.4.22, 64 bit ) , running as TCP proxy 1) My haproxy.cfg is like backend servers mode tcp balance roundrobin server machine1 machine1:4101 weight 50 check server machine2 machine2:4102 weight 50 check default-server slowstart 3000 When both of servers are DOWN , and a client opens a new connection, it never receives a 'Connection refused' . I guess that this client can connect to haproxy, so that error doesn't happen How I can detect that all of servers are DOWN when a client (socket) opens a connection ? 2) If both of servers are UP, and, suddenly, one of them goes DOWN , I would like a client ( TCP socket) who sent data by this connection, could know that response can contain corrupt data How I can detect that a current TCP connection went down ? So, I could to implement a retry Thanks and regards
Re: Failed to use the source address for outgoing connections
On Tue, Apr 23, 2013 at 02:44:17PM +0800, Godbach wrote:
Hi,
(it's strange I didn't get the original e-mail).
On Tue, Apr 23, 2013 at 6:27 AM, Godbach nylzhao...@gmail.com wrote:
Hi, all
I have tested 'source' config in haproxy-1.5-dev18, but it didn't work
with the following line in default section:
source 0.0.0.0 usesrc clientip
Other related settings by iptables and ip rule have been set correctly.
There are some codes in cfg_parse_listen() (Line 1812-1815 in lastest
commit) to do source function init for a new backend proxy as below
if (defproxy.conn_src.iface_name)
curproxy-conn_src.iface_name =
strdup(defproxy.conn_src.iface_name);
curproxy-conn_src.iface_len = defproxy.conn_src.iface_len;
curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
The last line of codes will set the value of opts represents such as
'client', 'clientip' and so on in defproxy to current backend proxy. But
I was confused that why clear the low three bits. CO_SRC_TPROXY_MASK is
defined in include/types/connection.h as below:
/* source address settings for outgoing connections */
enum {
/* Tproxy exclusive values from 0 to 7 */
CO_SRC_TPROXY_ADDR = 0x0001,/* bind to this non-local
address
when connecting */
CO_SRC_TPROXY_CIP = 0x0002,/* bind to the client's IP
address
when connecting */
CO_SRC_TPROXY_CLI = 0x0003,/* bind to the client's IP+port
when connecting */
CO_SRC_TPROXY_DYN = 0x0004,/* bind to a dynamically
computed
non-local address */
CO_SRC_TPROXY_MASK = 0x0007,/* bind to a non-local address
when
connecting */
CO_SRC_BIND= 0x0008,/* bind to a specific source
address when connecting */
};
The low three bits store the configuration of usesrc, they should be
copied to the backend proxy without modified. But they were clear in
backend proxy actually.
Then I put source configuration 'source 0.0.0.0 usesrc clientip' in
backend section, the source function can work well.
So in my opinion, the code
curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
shoulde be modifed as below:
curproxy-conn_src.opts = defproxy.conn_src.opts;
Godbach, thanks for your analysis, you're perfectly right. I've looked
at the code and before dev15, the bind options were set in the proxy's
options, covered by PR_O_TPXY_MASK, and these bits were not cleared when
creating a new backend from the default section. Since commit ef9a3605,
we have dedicated options for this and indeed the bits are cleared.
Please confirm the modification you suggest works (specifically binding
to an explicit sources address such as source 0.0.0.0 usesrc 1.2.3.4),
and if that's OK, please send a patch which I'll happily apply. You can
reuse your analysis above as the commit message, it's perfectly clear!
Best regards,
Willy
Hi, Willy
I have tested the configuration you suggested with the following patch:
diff --git a/src/cfgparse.c b/src/cfgparse.c
index cc515a2..3514e83 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1812,7 +1812,7 @@ int cfg_parse_listen(const char *file, int
linenum, char **args, int kwm)
if (defproxy.conn_src.iface_name)
curproxy-conn_src.iface_name =
strdup(defproxy.conn_src.iface_name);
curproxy-conn_src.iface_len =
defproxy.conn_src.iface_len;
- curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
+ curproxy-conn_src.opts = defproxy.conn_src.opts;
}
if (curproxy-cap PR_CAP_FE) {
With explicit source address set, it still can not work well in default
section, and can work well in backend section.
Wiht 'usesrc client' configuration, it can work well both in default and
backend section after applying the above patch.
I will go on debugging this problem.
Thanks, so maybe that was the reason for clearing the flags, which was
still a stupid solution in my opinion :-/
I *believe* we don't keep the address in the default proxy, this is something
to be confirmed anyway, as it would be possible that we simply don't copy it
in fact.
Best regards,
Willy
Hi, Willy
Here is the patch to fix the bug of source function in attachment for
your information.
Commit log as below:
Bugfix: copy conn_src.opts and conn_src.tproxy_addr from
defproxy to backend proxy correctly
Source function will not work with the following line in default section:
source 0.0.0.0 usesrc clientip
even that related settings by iptables and ip rule have been set correctly.
But it can work well in backend setcion.
The reason is that the operation in line 1815 in cfgparse.c as below:
curproxy-conn_src.opts = defproxy.conn_src.opts
~CO_SRC_TPROXY_MASK;
clears three low bits of conn_src.opts which stores the configuration of
SV: VS: Haparoxy hangs in one minute on config reload
Hi Willy. I am sorry it took so long. We got another problem that got my full attention for months. Firewall issues with database connections. This is now solved and today this HAProxy reload problem occurred again. We have checked the logs and it's not the first time after we added option nolinger. You mentioned that using port 8080 could be part of the problem. Our other setup which runs on port 80 have never had this problem. Do You think changing the listen port to eg 85 might solve the problem? Best regards Terje -Opprinnelig melding- Fra: Borgen, Terje Sendt: torsdag, desember 06, 2012 16:56 Til: Willy Tarreau Kopi: haproxy@formilux.org Emne: SV: VS: Haparoxy hangs in one minute on config reload Hi Willy, Nice to know that a fix is on its way. Looking forward to that. We are in a process of migrating from Windows/WebSphere and have another twenty-five Jetty-apps that will run on this environment. With health checks from all these applications the problem might be bigger than it is today. I have put option nolinger in all the backends with backend-check in our test-environment. This change will be merged into production on Monday, but it might take some time before we know for sure if this has improved the situation. Its only one week left to do changes before Christmas, so I am an not sure how many reloads there will be before next Year. Thanks for great help so far. I will update You as soon as we get five or more successful reloads (or worst case, a reload that hangs in one minute again) Regards Terje -Opprinnelig melding- Fra: Willy Tarreau [mailto:w...@1wt.eu] Sendt: 5. desember 2012 22:43 Til: Borgen, Terje Kopi: haproxy@formilux.org Emne: Re: VS: Haparoxy hangs in one minute on config reload Hi Terje, On Wed, Dec 05, 2012 at 09:33:19AM +0100, Borgen, Terje wrote: Hi Willy, Thanks for Your quick response. I think You might be onto something here. We have a similar setup with haproxy using port 80 and have never experienced this problem in that environment. OK. /proc/sys/net/ipv4/ip_local_port_range says 32768-61000, so nothing special here. We have another similar problem when restarting the Jetty-servers on the same server. We always get an error saying that the port is in use and we have to wait one minute before it can start again. The Jetty ports (as You can see in the config) are also outside the ip_local_port_range. But this might be another problem since it happens every restart. Yes, typically a listening port bound without SO_REUSEADDR. Very common in fact. Some additional info: - We have two identical servers running apache http server, haproxy and jetty servers. Most of the traffic hits the main server, and the reload problem have never happened on the failover server. So this problem might be traffic-related. - For one week we changed the inter-parameter on the clusters from default 2000 to 6 leaving rise/fall as default. In that period the problem never occurred. OK, I see. The health checks are causing too many time-wait sockets. This issue was very recently fixed (in 1.5-dev14) as haproxy now closes health check sockets with a TCP reset, thus avoiding the TIME_WAIT. I'm pretty sure they're the one causing the issue as I've experienced a similar one recently (reason why I fixed it :-)). I have not backported this yet as I wanted to keep an observation period. However you can try something : put option nolinger in your BACKENDS, not your frontends, otherwise some clients will experience truncated responses!!! All backend connections (including checks) will be closed by a reset and you should see much less TIME_WAIT sockets between haproxy and the servers. Regards, Willy
fullconn
Hello: I'm reading about fullconn parameter in https://code.google.com/p/haproxy-docs/wiki/fullconn and I don't get the example # The servers will accept between 100 and 1000 concurrent connections each # and the maximum of 1000 will be reached when the backend reaches 1 # connections. backend dynamic fullconn 1 server srv1 dyn1:80 minconn 100 maxconn 1000 server srv2 dyn2:80 minconn 100 maxconn 1000 I don't understand what minconn is for . Is it a lower limit for concurrent connections? The server will accept between 100 and 1000 concurrent connections And if is there 50 concurrent connections to backend ? If the server accepts up to 1000 concurrent connections, I guess 1000 is always the upper limit So, what fullconn is for ? is for concurrent connections to backend ? I don't understand this limits Thanks and regards
Re: SV: VS: Haparoxy hangs in one minute on config reload
Hi Terje, On Tue, Apr 23, 2013 at 11:17:13AM +0200, Borgen, Terje wrote: Hi Willy. I am sorry it took so long. We got another problem that got my full attention for months. Firewall issues with database connections. This is now solved and today this HAProxy reload problem occurred again. We have checked the logs and it's not the first time after we added option nolinger. You mentioned that using port 8080 could be part of the problem. Our other setup which runs on port 80 have never had this problem. Do You think changing the listen port to eg 85 might solve the problem? Yes definitely, please try this. Regards, Willy
SV: SV: VS: Haparoxy hangs in one minute on config reload
Hi Willy, Thanks, we will try this ASAP. Regards Terje -Opprinnelig melding- Fra: Willy Tarreau [mailto:w...@1wt.eu] Sendt: tirsdag, april 23, 2013 11:26 Til: Borgen, Terje Kopi: 'haproxy@formilux.org' Emne: Re: SV: VS: Haparoxy hangs in one minute on config reload Hi Terje, On Tue, Apr 23, 2013 at 11:17:13AM +0200, Borgen, Terje wrote: Hi Willy. I am sorry it took so long. We got another problem that got my full attention for months. Firewall issues with database connections. This is now solved and today this HAProxy reload problem occurred again. We have checked the logs and it's not the first time after we added option nolinger. You mentioned that using port 8080 could be part of the problem. Our other setup which runs on port 80 have never had this problem. Do You think changing the listen port to eg 85 might solve the problem? Yes definitely, please try this. Regards, Willy
appsession not sticking?
Hi, I'm setting up a new haproxy deployment, and am having some problems trying to get sessions correctly sticking to backend servers. Since it's new, it's worth firstly checking that I haven't made any configuration mistakes, I'm currently testing with this: https://gist.github.com/mwild1/19560e39196f49da4ae2 I've done some debugging, and this is the usual flow I see: -- Connection 1 OPTIONS-OK (backend 1) ; cross-domain pre-flight request POST-OK (backend 1) (cookie is set in this response) POST-OK (backend 1) POST- (backend 1) ; Here backend 1 holds the connection open (long poll) ; The client makes a new request, and the browser opens a new connection because connection 1 is blocked -- Connection 2 POST-ERROR (backend 2) All the POST requests made by the browser (Chrome) have the correct cookie once it is set in the first POST response. One possibility - perhaps haproxy only stores the cookie value when the connection closes? Since connection 1 doesn't close, connection 2 does not get associated with the correct backend. Just a theory... Any advice or suggestions? I hope it is something simple I'm missing :) Regards, Matthew
Re: HA Proxy FTP Load Balancing Timeout
Hi Ben, Is there any suggestion, that I can try in our HA Proxy config. Regards, Alok From: Ben Timby bti...@gmail.com To: Alok Kumar a_sa...@yahoo.com Cc: haproxy@formilux.org haproxy@formilux.org Sent: Thursday, April 18, 2013 3:46 PM Subject: Re: HA Proxy FTP Load Balancing Timeout On Thu, Apr 18, 2013 at 3:38 PM, Alok Kumar a_sa...@yahoo.com wrote: Hi Ben, In my case we are load balancing across FTP servers. FTP uses two data channel and command channel port for data transfer. I use haproxy for the same purpose. Closing the command channel will not affect a transfer in any way, unless you have something else set up wrong. In other words, the command channel is needed only to START the upload, once started the data channel will complete the upload. If the command channel closes in the meantime, what does it matter? I am trying to understand WHY this is a problem, as in my experience closing the idle command channel is a GOOD thing with no negative side-effects.
Re: Haproxy support for passing HTTP CONNECT requests directly to the backend
On Tue, Apr 23, 2013 at 07:50:56AM +0200, Willy Tarreau wrote: Hi, On Tue, Apr 23, 2013 at 05:29:26AM +0300, Pasi Kärkkäinen wrote: Hello, Is it currently possible to pass HTTP CONNECT requests directly to the backend server? So haproxy itself shouldn't try to connect anywhere, but instead directly pass the request to the backend, and let backend handle it. Not only it is possible, but it is the only thing it can do :-) Keep in mind that haproxy is a reverse-proxy and not a proxy, so it will not try to resolve a host to connect to a specific location for example. Thus, if it receives a request such as CONNECT foo:443 HTTP/1.1, it will not try to resolved foo, it will send it to one of the servers declared in the backend. And it is the same for all methods, there is nothing specific to CONNECT. Hmm, I remember trying it earlier (a couple of years ago), and then it didn't work.. I'll have to try it again! Thanks a lot, -- Pasi
Unable to load SSL private key from PEM file
Hi, I'm trying to get haproxy 1.5 dev18 to load my production certificate (it is working fine with a self-signed one). And I'm getting this error: [ALERT] 112/151354 (11224) : parsing [/etc/haproxy/haproxy.cfg:69] : 'bind ip:443' : unable to load SSL private key from PEM file '/etc/pki/tls/certs/prodcrt.pem'. [ALERT] 112/151354 (11224) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 112/151354 (11224) : Proxy 'https-in': no SSL certificate specified for bind 'ip:443' at [/etc/haproxy/haproxy.cfg:69] (use 'crt'). [ALERT] 112/151354 (11224) : Fatal errors found in configuration. Errors in configuration file, check with haproxy check. This cert is a EV multidomain one from Digicert and uses a intermediate cert. I'm made the pem file by concatenting all the keys and certs like this : -BEGIN RSA PRIVATE KEY- -END RSA PRIVATE KEY- -BEGIN CERTIFICATE- -END CERTIFICATE- -BEGIN INTERMEDIATE CERTIFICATE- -END INTERMEDIATE CERTIFICATE- -BEGIN ROOT CERTIFICATE- -END ROOT CERTIFICATE- I'm using the identical PEM file successfully with vsftpd and I've also tested it with Apache mod_ssl where is also worked fine. So why is haproxy giving me this error? How can I debug this issue? Thanks, Tim -- Tim Verhoeven - tim.verhoeven...@gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the microsoft approach to programming and should never be allowed. (Linus Torvalds)
Re: Haproxy support for passing HTTP CONNECT requests directly to the backend
On Tue, Apr 23, 2013 at 04:30:12PM +0300, Pasi Kärkkäinen wrote: On Tue, Apr 23, 2013 at 07:50:56AM +0200, Willy Tarreau wrote: Hi, On Tue, Apr 23, 2013 at 05:29:26AM +0300, Pasi Kärkkäinen wrote: Hello, Is it currently possible to pass HTTP CONNECT requests directly to the backend server? So haproxy itself shouldn't try to connect anywhere, but instead directly pass the request to the backend, and let backend handle it. Not only it is possible, but it is the only thing it can do :-) Keep in mind that haproxy is a reverse-proxy and not a proxy, so it will not try to resolve a host to connect to a specific location for example. Thus, if it receives a request such as CONNECT foo:443 HTTP/1.1, it will not try to resolved foo, it will send it to one of the servers declared in the backend. And it is the same for all methods, there is nothing specific to CONNECT. Hmm, I remember trying it earlier (a couple of years ago), and then it didn't work.. There is no reason. It's been used since maybe version 1.1 (10 years ago) in front of proxies where this was already working. So if you see any failure, please report ! Thanks, Willy
Re: Haproxy support for passing HTTP CONNECT requests directly to the backend
On Tue, Apr 23, 2013 at 04:10:55PM +0200, Willy Tarreau wrote: On Tue, Apr 23, 2013 at 04:30:12PM +0300, Pasi Kärkkäinen wrote: On Tue, Apr 23, 2013 at 07:50:56AM +0200, Willy Tarreau wrote: Hi, On Tue, Apr 23, 2013 at 05:29:26AM +0300, Pasi Kärkkäinen wrote: Hello, Is it currently possible to pass HTTP CONNECT requests directly to the backend server? So haproxy itself shouldn't try to connect anywhere, but instead directly pass the request to the backend, and let backend handle it. Not only it is possible, but it is the only thing it can do :-) Keep in mind that haproxy is a reverse-proxy and not a proxy, so it will not try to resolve a host to connect to a specific location for example. Thus, if it receives a request such as CONNECT foo:443 HTTP/1.1, it will not try to resolved foo, it will send it to one of the servers declared in the backend. And it is the same for all methods, there is nothing specific to CONNECT. Hmm, I remember trying it earlier (a couple of years ago), and then it didn't work.. There is no reason. It's been used since maybe version 1.1 (10 years ago) in front of proxies where this was already working. So if you see any failure, please report ! Ok, will do. -- Pasi
Re: Unable to load SSL private key from PEM file
On 04/23/2013 06:31 AM, Tim Verhoeven wrote: Hi, I'm trying to get haproxy 1.5 dev18 to load my production certificate (it is working fine with a self-signed one). And I'm getting this error: [ALERT] 112/151354 (11224) : parsing [/etc/haproxy/haproxy.cfg:69] : 'bind ip:443' : unable to load SSL private key from PEM file '/etc/pki/tls/certs/prodcrt.pem'. [ALERT] 112/151354 (11224) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 112/151354 (11224) : Proxy 'https-in': no SSL certificate specified for bind 'ip:443' at [/etc/haproxy/haproxy.cfg:69] (use 'crt'). [ALERT] 112/151354 (11224) : Fatal errors found in configuration. Errors in configuration file, check with haproxy check. This cert is a EV multidomain one from Digicert and uses a intermediate cert. I'm made the pem file by concatenting all the keys and certs like this : -BEGIN RSA PRIVATE KEY- -END RSA PRIVATE KEY- -BEGIN CERTIFICATE- -END CERTIFICATE- -BEGIN INTERMEDIATE CERTIFICATE- -END INTERMEDIATE CERTIFICATE- -BEGIN ROOT CERTIFICATE- -END ROOT CERTIFICATE- The private key should go after your certificate, not before. The rest of your order is OK. So: cat mycrt.pem mykey.pem intermediate.pem root.pem combined.pem Ian
Re: tcp loadbalancing
Hi, Could you take a capture of this check from the server? In TCP mode, HAProxy manages buffers and just forward them in both ways (client to server and vice-versa). Baptiste On Wed, Apr 24, 2013 at 4:59 AM, ZeN z...@pix.co.id wrote: Hello please bear with because i'm new with haproxy. recently i tried to loadbalance tcp base applications which bind/listen into specific ports. the behavior of the applications ( server side ) is : check time out to the connected client ( 20 seconds), than close/terminated the staled clients connections. but with haproxy, i still cannot manage this behavior to work, because the server send the time out checking to the haproxy server, not directly to the clients. may be some of you who has more expertize with haproxy could point me what is wrong with my setup. i'm running HA-Proxy version 1.4.23 2013/04/03 from FreeBSD ports under FreeBSD 9.1-RELEASE-p2 here is my simple haproxy conf: global log 127.0.0.1 local0 debug maxconn 4096 #ulimit-n 1024 uid 1 gid 1 daemon pidfile /var/run/haproxy.pid listen stats :8081 balance mode http stats enable stats auth blah:blahpass stats refresh 5s listen TEST :5150 ##bind to all interfaces## mode tcp option tcpka option clitcpka option srvtcpka option tcp-smart-accept option tcplog timeout client 320s timeout connect 30s timeout server 30s timeout check 30s option abortonclose option redispatch retries 3 log global balance roundrobin server piglet 192.168.5.18:5150 maxconn 2000 server tigger 192.168.5.30:5150 maxconn 2000 any help will be much appreciated TIA ZeN
Re: fullconn
Hi, Long time nobody asked for fullconn information :) fullconn allows HAProxy to manage connections on your server. It means that HAProxy will increase connection opened on the server, from minconn to maxconn. And maxconn will be reached when the number of connection on the backend is equal to fullconn. I hope this is a bit more clearer. Baptiste On Tue, Apr 23, 2013 at 11:22 AM, Jose María Zaragoza demablo...@gmail.com wrote: Hello: I'm reading about fullconn parameter in https://code.google.com/p/haproxy-docs/wiki/fullconn and I don't get the example # The servers will accept between 100 and 1000 concurrent connections each # and the maximum of 1000 will be reached when the backend reaches 1 # connections. backend dynamic fullconn 1 server srv1 dyn1:80 minconn 100 maxconn 1000 server srv2 dyn2:80 minconn 100 maxconn 1000 I don't understand what minconn is for . Is it a lower limit for concurrent connections? The server will accept between 100 and 1000 concurrent connections And if is there 50 concurrent connections to backend ? If the server accepts up to 1000 concurrent connections, I guess 1000 is always the upper limit So, what fullconn is for ? is for concurrent connections to backend ? I don't understand this limits Thanks and regards
Re: appsession not sticking?
Hi Mattew, You can first send us your configuration :) Browser are supposed to send cookies over 2 different connections for the same domain. So maybe you could log the Host header and the Set-Cookie header as well. Baptiste On Tue, Apr 23, 2013 at 11:54 AM, Matthew Wild mwi...@gmail.com wrote: Hi, I'm setting up a new haproxy deployment, and am having some problems trying to get sessions correctly sticking to backend servers. Since it's new, it's worth firstly checking that I haven't made any configuration mistakes, I'm currently testing with this: https://gist.github.com/mwild1/19560e39196f49da4ae2 I've done some debugging, and this is the usual flow I see: -- Connection 1 OPTIONS-OK (backend 1) ; cross-domain pre-flight request POST-OK (backend 1) (cookie is set in this response) POST-OK (backend 1) POST- (backend 1) ; Here backend 1 holds the connection open (long poll) ; The client makes a new request, and the browser opens a new connection because connection 1 is blocked -- Connection 2 POST-ERROR (backend 2) All the POST requests made by the browser (Chrome) have the correct cookie once it is set in the first POST response. One possibility - perhaps haproxy only stores the cookie value when the connection closes? Since connection 1 doesn't close, connection 2 does not get associated with the correct backend. Just a theory... Any advice or suggestions? I hope it is something simple I'm missing :) Regards, Matthew
