Quick question where the answer is probably no :-).
The new stunnel proxy functionality got me thinking (which is normally a bad thing): With HAProxy is it possible to insert an x-forwarded (or similar) in SMTP? F5 suggest: You could insert the IP in the optional comments field, assuming exchange can access it there. Comments: [IP::client_addr] Or from the postfix documentation: XFORWARD Example In the following example, information sent by the client is shown in bold font. 220 server.example.com ESMTP Postfix EHLO client.example.com 250-server.example.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-XFORWARD NAME ADDR PROTO HELO 250 8BITMIME XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2 PROTO=ESMTP 250 Ok XFORWARD HELO=spike.porcupine.org 250 Ok MAIL FROM:wie...@porcupine.org 250 Ok RCPT TO:u...@example.com 250 Ok DATA 354 End data with CRLF.CRLF . . .message content. . . . 250 Ok: queued as 3CF6B2AAE8 QUIT 221 Bye -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
Re: Quick question where the answer is probably no :-).
No you can't, as Haproxy don't know SMTP protocol, but it can be great to add if someone is inspired by this :) Hervé. On Wed, 8 Dec 2010 09:58:40 + Malcolm Turnbull malc...@loadbalancer.org wrote: The new stunnel proxy functionality got me thinking (which is normally a bad thing): With HAProxy is it possible to insert an x-forwarded (or similar) in SMTP? F5 suggest: You could insert the IP in the optional comments field, assuming exchange can access it there. Comments: [IP::client_addr] Or from the postfix documentation: XFORWARD Example In the following example, information sent by the client is shown in bold font. 220 server.example.com ESMTP Postfix EHLO client.example.com 250-server.example.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-XFORWARD NAME ADDR PROTO HELO 250 8BITMIME XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2 PROTO=ESMTP 250 Ok XFORWARD HELO=spike.porcupine.org 250 Ok MAIL FROM:wie...@porcupine.org 250 Ok RCPT TO:u...@example.com 250 Ok DATA 354 End data with CRLF.CRLF . . .message content. . . . 250 Ok: queued as 3CF6B2AAE8 QUIT 221 Bye -- 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
Strange session affinity behaviour
Hi all, I am having a very strange issue with HAProxy in that I wanted to setup a simple sample that delegates to two instances of Jetty on my machine. Each Jetty instance works perfectly when accessed directly and increments a value in the session as it should. However, when I access through HAP, I see the following in my log file: Dec 8 12:26:06 127.0.0.1 haproxy[2937]: 127.0.0.1:52325 [08/Dec/2010:12:26:06.131] yourdomain_cluster yourdomain_cluster/server1 0/0/0/4/4 200 646 - JSESSIONID=HZEEB54EBF02B24933A0825 0/0/0/0/0 0/0 GET / HTTP/1.1 Dec 8 12:26:06 127.0.0.1 haproxy[2938]: 127.0.0.1:52327 [08/Dec/2010:12:26:06.182] yourdomain_cluster yourdomain_cluster/server1 0/0/0/2/2 200 542 JSESSIONID=HZEEB54EBF02B24933A0825 - 0/0/0/0/0 0/0 GET /favicon.ico HTTP/1.1 Dec 8 12:26:13 127.0.0.1 haproxy[2937]: 127.0.0.1:52350 [08/Dec/2010:12:26:13.429] yourdomain_cluster yourdomain_cluster/server1 0/0/0/2/2 200 542 JSESSIONID=HZEEB54EBF02B24933A0825 - 0/0/0/0/0 0/0 GET / HTTP/1.1 Dec 8 12:26:13 127.0.0.1 haproxy[2938]: 127.0.0.1:52353 [08/Dec/2010:12:26:13.479] yourdomain_cluster yourdomain_cluster/server2 0/0/0/32/32 200 646 JSESSIONID=HZEEB54EBF02B24933A0825 JSESSIONID=HZ4ECA6F75E7FE4D1C980EA 0/0/0/0/0 0/0 GET /favicon.ico HTTP/1.1 Dec 8 12:26:17 127.0.0.1 haproxy[2937]: 127.0.0.1:52364 [08/Dec/2010:12:26:17.137] yourdomain_cluster yourdomain_cluster/server2 0/0/0/5/5 200 542 JSESSIONID=HZ4ECA6F75E7FE4D1C980EA - 0/0/0/0/0 0/0 GET / HTTP/1.1 Dec 8 12:26:17 127.0.0.1 haproxy[2938]: 127.0.0.1:52366 [08/Dec/2010:12:26:17.161] yourdomain_cluster yourdomain_cluster/server2 0/0/0/2/2 200 542 JSESSIONID=HZ4ECA6F75E7FE4D1C980EA - 0/0/0/0/0 0/0 GET /favicon.ico HTTP/1.1 Dec 8 12:26:21 127.0.0.1 haproxy[2937]: 127.0.0.1:52379 [08/Dec/2010:12:26:21.145] yourdomain_cluster yourdomain_cluster/server1 0/0/0/6/6 200 646 JSESSIONID=HZ4ECA6F75E7FE4D1C980EA JSESSIONID=HZ15E85FFF814E4D068808B 0/0/0/0/0 0/0 GET / HTTP/1.1 Dec 8 12:26:21 127.0.0.1 haproxy[2938]: 127.0.0.1:52381 [08/Dec/2010:12:26:21.166] yourdomain_cluster yourdomain_cluster/server1 0/0/0/1/1 200 542 JSESSIONID=HZ15E85FFF814E4D068808B - 0/0/0/0/0 0/0 GET /favicon.ico HTTP/1.1 Notice how it serves a couple of requests and despite reading the JSESSIONID cookie on the incoming request, assigns a new session in the response (because it delegated to the wrong server i'm guessing?) This is my config: global daemon maxconn 1 nbproc 2 log 127.0.0.1 local2 defaults log global clitimeout 6 srvtimeout 3 contimeout 4000 retries 3 option redispatch option http-server-close option abortonclose option httplog listen yourdomain_cluster 127.0.0.1: mode http balance roundrobin capture cookie JSESSIONID len 34 appsession JSESSIONID len 34 timeout 3h option forwardfor server server1 127.0.0.1:3000 cookie s1 weight 1 maxconn 2000 check server server2 127.0.0.1:3001 cookie s2 weight 1 maxconn 2000 check listen lb1_stats 127.0.0.1:9090 mode http stats uri / stats auth admin:password stats refresh 5s Anything there that looks funky that could be causing this? Cheers, Tim
Re: config : 'option forwardfor' ignored for proxy
Hi Willy, Those changes has been done into config generate script, is it working good now. Thanks for suggestions and haproxy version 1.4.10 is really working great, still working on the benchmarking stuff. -Ravi On Wed, Dec 8, 2010 at 11:51 AM, Willy Tarreau w...@1wt.eu wrote: Ravi, On Mon, Dec 06, 2010 at 05:55:59PM +0530, Ravi Bhure wrote: I mean to, we are using 1.3.x since long time, and all these things (haproxy config files) generated through script that we have built, and its very nicely handled through-out the new config generate as we require. Since, no matter for changes those you suggested, but again there is few errors remains ... . Those warnings are precisely here to tell you that your config will not work as you think it should. In the past, such configs were common and caused some bug reports here on the list. Each time we can find an obviously non-working config that haproxy can detect by itself, we add such a warning. You can safely ignore them if you want, but I'd really suggest that you fix your config at one point because it is misleading. Having a forwardfor in a TCP section will do nothing. While most users will not have a trouble with that, some less experimented will believe it works and will waste their time debugging the config. Think about the people who'll handle the setup for you when you're on holidays. If you're using a script to generate the confs, then it's as simple as not adding stats or any HTTP-specific option when generating a TCP section. Regards, Willy -- Thanks Regards, Ravi Bhure http://www.indianGNU.org Register Linux user # 463269
monitor-uri does not respond
Setup a monitor-uri /status on one of the frontends, however, GET http://host:port/status returns nothing and health checks fail for a load balancer. Security permissions are verified and OK. mode is http in the defaults section. I was expecting that 200 is returned. What am I missing? -- Dmitri Smirnov Y!IM: ia_slepukhin
Re: monitor-uri does not respond
I think it is a bug. The manual said that monitor requests are responded to before ACLs are evaluated. By ACLs I mean the acls like this: monitor-uri /status acl valid_src1 hdr_ip(X-Forwarded-For) xx acl valid_src2 hdr_ip(X-Forwarded-For) xx tcp-request content reject unless valid_src1 or valid_src2 As soon as I remove ACL check monitor-uri starts responding. I am running 1.4.8 On 12/08/2010 10:22 AM, Dmitri Smirnov wrote: Setup a monitor-uri /status on one of the frontends, however, GET http://host:port/status returns nothing and health checks fail for a load balancer. Security permissions are verified and OK. mode is http in the defaults section. I was expecting that 200 is returned. What am I missing?
Re: stunnel patch updates
Le mercredi 8 décembre 2010 13:11:10, Craig a écrit : Am 06.12.2010 22:31, Cyril Bonté wrote: I don't know if you still need them, but as I'll also need them soon, I've rediffed both patches. You'll find in attachment : - stunnel-4.34-listen-queue.diff - stunnel-4.34-xforwared-for.diff Hope this helps. Thanks from me, too! I think we still need the patches until 1.5 is stable and included in linux distributions. Willy, can you put them on the haproxy page? Just notice that I forgot to cleanup my working directory for the listen-queue patch :-/ It's not a problem when applying the patch but prototypes.h~ and stunnel.c~ lines should be removed from the file. -- Cyril Bonté
PROXY protocol for stunnel 4.34 + haproxy 1.4.10
Hi all,
For my needs, I've updated the sendproxy patch for stunnel 4.34 and prepared
another one to backport the PROXY protocol in haproxy 1.4.10.
Maybe it can interest someone else than me.
--
Cyril Bonté
diff -ru haproxy-1.4.10/doc/configuration.txt haproxy-1.4.10-accept-proxy/doc/configuration.txt
--- haproxy-1.4.10/doc/configuration.txt 2010-11-29 07:36:47.0 +0100
+++ haproxy-1.4.10-accept-proxy/doc/configuration.txt 2010-12-07 22:31:24.721186953 +0100
@@ -1318,6 +1318,7 @@
bind [address]:port_range [, ...] id id
bind [address]:port_range [, ...] name name
bind [address]:port_range [, ...] defer-accept
+bind [address]:port_range [, ...] accept-proxy
Define one or several listening addresses and/or ports in a frontend.
May be used in sections : defaults | frontend | listen | backend
no |yes | yes | no
@@ -1398,6 +1399,19 @@
with front firewalls which would see an established
connection while the proxy will only see it in SYN_RECV.
+accept-proxy is an optional keyword which enforces use of the PROXY
+ protocol over any connection accepted by this listener. The
+ PROXY protocol dictates the layer 3/4 addresses of the
+ incoming connection to be used everywhere an address is used,
+ with the only exception of tcp-request connection rules
+ which will only see the real connection address. Logs will
+ reflect the addresses indicated in the protocol, unless it is
+ violated, in which case the real address will still be used.
+ This keyword combined with support from external components
+ can be used as an efficient and reliable alternative to the
+ X-Forwarded-For mechanism which is not always reliable and
+ not even always usable.
+
It is possible to specify a list of address:port combinations delimited by
commas. The frontend will then listen on all of these addresses. There is no
fixed limit to the number of addresses and ports which can be listened on in
@@ -1408,8 +1422,10 @@
listen http_proxy
bind :80,:443
bind 10.0.0.1:10080,10.0.0.1:10443
+bind 127.0.0.1:8443 accept-proxy
- See also : source.
+ See also : source, option forwardfor and the PROXY protocol
+ documentation.
bind-process [ all | odd | even | number 1-32 ] ...
@@ -7116,7 +7132,9 @@
Detailed fields description :
- client_ip is the IP address of the client which initiated the TCP
-connection to haproxy.
+connection to haproxy. Note that when the connection is accepted on a
+socket configured with accept-proxy and the PROXY protocol is correctly
+used, then the logs will reflect the forwarded connection's information.
- client_port is the TCP port of the client which initiated the connection.
@@ -7289,7 +7307,9 @@
Detailed fields description :
- client_ip is the IP address of the client which initiated the TCP
-connection to haproxy.
+connection to haproxy. Note that when the connection is accepted on a
+socket configured with accept-proxy and the PROXY protocol is correctly
+used, then the logs will reflect the forwarded connection's information.
- client_port is the TCP port of the client which initiated the connection.
diff -ru haproxy-1.4.10/include/common/standard.h haproxy-1.4.10-accept-proxy/include/common/standard.h
--- haproxy-1.4.10/include/common/standard.h 2010-11-29 07:36:47.0 +0100
+++ haproxy-1.4.10-accept-proxy/include/common/standard.h 2010-12-07 22:00:46.959888470 +0100
@@ -262,6 +262,28 @@
return i;
}
+/* This function reads an unsigned integer from the string pointed to by s
+ * and returns it. The s pointer is adjusted to point to the first unread
+ * char. The function automatically stops at end.
+ */
+static inline unsigned int __read_uint(const char **s, const char *end)
+{
+ const char *ptr = *s;
+ unsigned int i = 0;
+ unsigned int j, k;
+
+ while (ptr end) {
+ j = *ptr - '0';
+ k = i * 10;
+ if (j 9)
+ break;
+ i = k + j;
+ ptr++;
+ }
+ *s = ptr;
+ return i;
+}
+
extern unsigned int str2ui(const char *s);
extern unsigned int str2uic(const char *s);
extern unsigned int strl2ui(const char *s, int len);
@@ -269,6 +291,7 @@
extern int strl2ic(const char *s, int len);
extern int strl2irc(const char *s, int len, int *ret);
extern int strl2llrc(const char *s, int len, long long *ret);
+extern unsigned int read_uint(const char **s, const char *end);
unsigned int inetaddr_host(const char *text);
unsigned int inetaddr_host_lim(const char *text, const char *stop);
unsigned int inetaddr_host_lim_ret(const char *text, char *stop, const char **ret);
diff -ru haproxy-1.4.10/include/proto/client.h haproxy-1.4.10-accept-proxy/include/proto/client.h
---
Re: Strange session affinity behaviour
Thanks very much for the reply. Interesting about nbproc - its in nearly every example online. Moreover, what are the guidelines for using appsession vs cookie? Would be good to understand this a little more. In my testing earlier, I added request-learn to the end of appsession and that fixed it, why is that? Cheers, Tim On 8 December 2010 18:49, Cyril Bonté cyril.bo...@free.fr wrote: Hi Tim, Le mercredi 8 décembre 2010 13:44:47, Tim Perrett a écrit : Hi all, I am having a very strange issue with HAProxy in that I wanted to setup a simple sample that delegates to two instances of Jetty on my machine. Each Jetty instance works perfectly when accessed directly and increments a value in the session as it should. (...) Notice how it serves a couple of requests and despite reading the JSESSIONID cookie on the incoming request, assigns a new session in the response (because it delegated to the wrong server i'm guessing?) This is my config: global daemon maxconn 1 nbproc 2 (...) Anything there that looks funky that could be causing this? nbproc is the culprit, it is generally not needed, and with appsession it must not be used : memory is not shared between the processes and your requests sometimes goes to one process, sometimes to the other (one doesn't the session hash of the other). You'll find an explanation in the archives (btw, formilux.org archives misses some messages) : http://www.mail-archive.com/haproxy@formilux.org/msg03843.html Also, do you really need appsession ? Can't you use cookie insert or cookie prefix which doesn't require hashing the sessions in memory ? -- Cyril Bonté
hot reconfiguration, how to?
I found: http://serverfault.com/questions/165883/is-there-a-way-to-add-more-backend-server-to-haproxy-without-restarting-haproxy http://sysbible.org/2008/07/26/haproxy-hot-reconfiguration/ However, these options are last documented in version 1.2: http://haproxy.1wt.eu/download/1.2/doc/haproxy-en.txt A brief search did not uncover any similar documentation in newer versions: http://haproxy.1wt.eu/download/1.3/doc/configuration.txt http://haproxy.1wt.eu/download/1.4/doc/configuration.txt What is the current approved way to do hot reconfiguration?
Re: Strange session affinity behaviour
Le mercredi 8 décembre 2010 21:37:31, Tim Perrett a écrit : Thanks very much for the reply. Interesting about nbproc - its in nearly every example online. Despite Willy often asks to remove nbproc to solve many problems :-) Moreover, what are the guidelines for using appsession vs cookie? Would be good to understand this a little more. cookie is somewhat the standard : it doesn't require memory. HAProxy only has to parse the request to know on which server to send it. appsession is mainly there for cases where cookies are not supported by the client. The drawbacks : - can't work correctly with multiple processes for your frontend (to simplify, mainly with nbproc 1). - the more sessions you have, the more memory you use. - doesn't like haproxy reloads/restarts (session hash is cleared). As a third persistance solution, you've also got the stick tables introduced in HAProxy 1.4. In my testing earlier, I added request-learn to the end of appsession and that fixed it, why is that? Because request-learn sometimes can help to repair the session hash. It depends on the balancing algorithm used : it looks like you were alone on the servers during your tests so it's easier to repair with your round robin algorithm. With several concurrent users it can't always work. To analyze your logs : * Without request-learn : ### Request 1 ### Process : 1 Client cookie : none Server used (round robin) : SERVER 1 Server cookie : JSESSIONID=HZEEB54EBF02B24933A0825 = SERVER 1 creates the session HZEEB54EBF02B24933A0825 = PROCESS 1 associates HZEEB54EBF02B24933A0825 to SERVER 1 ### Request 2 ### Process : 2 Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server used (round robin) : SERVER 1 Server cookie : none = PROCESS 2 doesn't know HZEEB54EBF02B24933A0825 but hopefully load balance to SERVER 1 which knows the session ### Request 3 ### Process : 1 Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server retrieved (session hash entry) : SERVER 1 Server cookie : - = PROCESS 1 knows that HZEEB54EBF02B24933A0825 is for SERVER 1 ### Request 4 ### Process : 2 Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server used (round robin) : SERVER 2 Server cookie : JSESSIONID=HZ4ECA6F75E7FE4D1C980EA = PROCESS 2 still doesn't know HZEEB54EBF02B24933A0825 and sadly load balance to SERVER 2 (round robin in action) = SERVER 2 creates the session HZ4ECA6F75E7FE4D1C980EA = PROCESS 2 associates HZ4ECA6F75E7FE4D1C980EA to SERVER 2 * With request-learn : ### Request 1 ### Process : 1 Client cookie : none Server used (round robin) : SERVER 1 Server cookie : JSESSIONID=HZEEB54EBF02B24933A0825 = SERVER 1 creates the session HZEEB54EBF02B24933A0825 = PROCESS 1 associates HZEEB54EBF02B24933A0825 to SERVER 1 ### Request 2 ### Process : 2 Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server used (round robin) : SERVER 1 Server cookie : none = PROCESS 2 doesn't know HZEEB54EBF02B24933A0825 but hopefully load balance to SERVER 1 which knows the session = request-learn repairs the session hash : HZEEB54EBF02B24933A0825 is associated to SERVER 1 ### Request 3 ### Process : 1 Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server retrieved (session hash entry) : SERVER 1 Server cookie : none = PROCESS 1 knows that HZEEB54EBF02B24933A0825 is for SERVER 1 Next request will be OK because request-learn previously repaired the session hash and could be like this : ### Request 4 ### Process : 2 Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server retrieved (session hash entry) : SERVER 1 Server cookie : none -- Cyril Bonté
Re: hot reconfiguration, how to?
See the architecture doc section 4.3 http://haproxy.1wt.eu/download/1.3/doc/architecture.txt -Bryan On Wed, Dec 8, 2010 at 12:51 PM, Joshua N Pritikin jos...@paloalto.comwrote: I found: http://serverfault.com/questions/165883/is-there-a-way-to-add-more-backend-server-to-haproxy-without-restarting-haproxy http://sysbible.org/2008/07/26/haproxy-hot-reconfiguration/ However, these options are last documented in version 1.2: http://haproxy.1wt.eu/download/1.2/doc/haproxy-en.txt A brief search did not uncover any similar documentation in newer versions: http://haproxy.1wt.eu/download/1.3/doc/configuration.txt http://haproxy.1wt.eu/download/1.4/doc/configuration.txt What is the current approved way to do hot reconfiguration?
Re: stunnel patch updates
Hi guys, On Wed, Dec 08, 2010 at 07:54:19PM +0100, Cyril Bonté wrote: Le mercredi 8 décembre 2010 13:11:10, Craig a écrit : Am 06.12.2010 22:31, Cyril Bonté wrote: I don't know if you still need them, but as I'll also need them soon, I've rediffed both patches. You'll find in attachment : - stunnel-4.34-listen-queue.diff - stunnel-4.34-xforwared-for.diff Hope this helps. Thanks from me, too! I think we still need the patches until 1.5 is stable and included in linux distributions. Willy, can you put them on the haproxy page? Just notice that I forgot to cleanup my working directory for the listen-queue patch :-/ It's not a problem when applying the patch but prototypes.h~ and stunnel.c~ lines should be removed from the file. OK, thanks Cyril. I'll try to update that tomorrow or this week-end. Cheers, Willy
Re: monitor-uri does not respond
On Wed, Dec 08, 2010 at 10:42:42AM -0800, Dmitri Smirnov wrote: I think it is a bug. The manual said that monitor requests are responded to before ACLs are evaluated. By ACLs I mean the acls like this: monitor-uri /status acl valid_src1 hdr_ip(X-Forwarded-For) xx acl valid_src2 hdr_ip(X-Forwarded-For) xx tcp-request content reject unless valid_src1 or valid_src2 As soon as I remove ACL check monitor-uri starts responding. That's expected, but the doc needs to be updated then. Monitor-uri is handled before any other HTTP processing. But the tcp-request ACLs are processed before HTTP, thus before monitor-uri. Also, it's dangerous to put your tcp-request rules that way, because they involve some HTTP. I hope you have an inspect-delay and a rule that ensures you don't accept the request until the request is completely parsed (accept if HTTP or WAIT_END). Regards, Willy
Re: TCP mode intelligence
Hi Nick, On Fri, Oct 01, 2010 at 02:40:34PM -0500, Nick Hadaway wrote: Hi All, I am running HAProxy 1.4.8 doing lots of things but one of my uses is a reverse TCP proxy. My issue is I would like to have a server taken out of the listen directive's rotation if any warnings or errors or denied instances occur or X number of any or all of those parameters... Is this possible? My reading of the 1.4 configuration.txt and list troving has been unsuccessful over the past 9 months... Wouldn't the observe and on-error server options match your need ? Regards, Willy
Re: hot reconfiguration, how to?
On Wed, Dec 8, 2010 at 6:13 PM, Bryan Talbot btal...@aeriagames.com wrote: See the architecture doc section 4.3 http://haproxy.1wt.eu/download/1.3/doc/architecture.txt -Bryan When a new haproxy pid is started after it sends a SIGTTOU to the prior running haproxy pid, what is the state of the backends? If one backend was in a down state due to failed health checks, will it be marked up by the new process until it fails the configured number of checks? On Wed, Dec 8, 2010 at 12:51 PM, Joshua N Pritikin jos...@paloalto.com wrote: I found: http://serverfault.com/questions/165883/is-there-a-way-to-add-more-backend-server-to-haproxy-without-restarting-haproxy http://sysbible.org/2008/07/26/haproxy-hot-reconfiguration/ However, these options are last documented in version 1.2: http://haproxy.1wt.eu/download/1.2/doc/haproxy-en.txt A brief search did not uncover any similar documentation in newer versions: http://haproxy.1wt.eu/download/1.3/doc/configuration.txt http://haproxy.1wt.eu/download/1.4/doc/configuration.txt What is the current approved way to do hot reconfiguration?
Re: hot reconfiguration, how to?
Hi David, On Wed, Dec 08, 2010 at 06:30:21PM -0500, David Birdsong wrote: On Wed, Dec 8, 2010 at 6:13 PM, Bryan Talbot btal...@aeriagames.com wrote: See the architecture doc section 4.3 http://haproxy.1wt.eu/download/1.3/doc/architecture.txt -Bryan When a new haproxy pid is started after it sends a SIGTTOU to the prior running haproxy pid, what is the state of the backends? If one backend was in a down state due to failed health checks, will it be marked up by the new process until it fails the configured number of checks? They're marked UP for one single check (as if they failed all checks but the last one). That way, the first check fixes the status. Regards, Willy
HAProxy Cookie/Host Forwarding
Hey, I was wondering if anyone could be of any assistance? I'm trying to use HAProxy to forward based on cookie and host. As it stands, I want HAProxy to see if a cookie is set and if it is, forward to a development server and if it isn't just push out to production. The main issue being, we have multiple production servers and a few thousand domains, so hard coding everything doesn't seem very efficient. Is there a way to have HAProxy forward the production request based on the host the person is attempting to initially connect to without it being static in the configuration file? Here's what I have so far... global daemon defaults mode http timeout connect 1 # default 10 second time out if a backend is not found timeout client 30 timeout server 30 maxconn 6 retries 3 frontend read_cookies bind:80 acl is_servermagic hdr_reg(Cookie) dev_magic=.* use_backend development if is_servermagic default_backend production backend development modehttp option forwardfor balance source option httpclose server dev1 192.168.1.100:80 backend production modehttp option forwardfor balance source option httpclose server prod1 example.com:80
Re: Any chance of a brief introduction and example of the new PROXy protocol?
Hi Malcolm, On Tue, Dec 07, 2010 at 01:40:40PM +, Malcolm Turnbull wrote: Willy, New PROXY protocol sounds great, I've just patched stunnel 4.34 and running it with HAProxy 1.5-dev3... but what commands do I need? How would you use it for SMTPS OR IMAPS for example? It will work just as for HTTPS. The principle of the PROXY protocol is to prepend a unique line in the data before any other data, and not to alter the transported payload. The recipient (here haproxy) simply removes the line before processing the connection as if it were not there. The principle is a bit similar to the XCLIENT protocol introduced with Postfix, except that it was specific to SMTP. For a long time I thought we could easily adapt it but it looks too much flexible for ensuring we do the thing right in pure TCP, and not necessarily suited for transporting low-level information, hence the new protocol. Any chance of a brief introduction and example of the new PROXy protocol? I won't repeat what other kind posters have already proposed before me :-) Cheers, Willy
Re: disable-on-404 and tracking
Hi Joe, On Mon, Dec 06, 2010 at 03:19:36PM -0800, Joe Williams wrote: On Dec 6, 2010, at 2:45 PM, Bryan Talbot wrote: I worked around this issue by including the option httpchk in the backend but never using the check option for the servers in that backend that are tracked. The server lines do contain the track option. backend be1 balance roundrobin http-check disable-on-404 option httpchk HEAD /online.php HTTP/1.1\r\nHost:\ healthcheck server 1.2.3.4 1.2.3.4:80 check backend be2 balance roundrobin http-check disable-on-404 option httpchk HEAD /online.php HTTP/1.1\r\nHost:\ healthcheck server 1.2.3.4 1.2.3.4:80 track be1/1.2.3.4 Thanks Bryan, that should hold me over for now. This seems like a bug IMHO, track should cause the backend to inherit http-check disable-on-404 from the main backend. I just glanced over that thread and I agree we should get this fixed one way or another. It's not really a bug but a side effect of dependencies between features. At the very least, we should document the matrix of all tracked/tracking modes with their possible options (even if we explicitly have to enable httpchk and disable-on-404 in both backends for whatever reason). Willy
Re: stunnel patch updates
Thank you Cyril and bartavelle! On Wed, Dec 8, 2010 at 3:24 PM, Willy Tarreau w...@1wt.eu wrote: Hi guys, On Wed, Dec 08, 2010 at 07:54:19PM +0100, Cyril Bonté wrote: Le mercredi 8 décembre 2010 13:11:10, Craig a écrit : Am 06.12.2010 22:31, Cyril Bonté wrote: I don't know if you still need them, but as I'll also need them soon, I've rediffed both patches. You'll find in attachment : - stunnel-4.34-listen-queue.diff - stunnel-4.34-xforwared-for.diff Hope this helps. Thanks from me, too! I think we still need the patches until 1.5 is stable and included in linux distributions. Willy, can you put them on the haproxy page? Just notice that I forgot to cleanup my working directory for the listen-queue patch :-/ It's not a problem when applying the patch but prototypes.h~ and stunnel.c~ lines should be removed from the file. OK, thanks Cyril. I'll try to update that tomorrow or this week-end. Cheers, Willy
Re: disable-on-404 and tracking
On Dec 8, 2010, at 3:53 PM, Willy Tarreau wrote: Hi Joe, On Mon, Dec 06, 2010 at 03:19:36PM -0800, Joe Williams wrote: On Dec 6, 2010, at 2:45 PM, Bryan Talbot wrote: I worked around this issue by including the option httpchk in the backend but never using the check option for the servers in that backend that are tracked. The server lines do contain the track option. backend be1 balance roundrobin http-check disable-on-404 option httpchk HEAD /online.php HTTP/1.1\r\nHost:\ healthcheck server 1.2.3.4 1.2.3.4:80 check backend be2 balance roundrobin http-check disable-on-404 option httpchk HEAD /online.php HTTP/1.1\r\nHost:\ healthcheck server 1.2.3.4 1.2.3.4:80 track be1/1.2.3.4 Thanks Bryan, that should hold me over for now. This seems like a bug IMHO, track should cause the backend to inherit http-check disable-on-404 from the main backend. I just glanced over that thread and I agree we should get this fixed one way or another. It's not really a bug but a side effect of dependencies between features. At the very least, we should document the matrix of all tracked/tracking modes with their possible options (even if we explicitly have to enable httpchk and disable-on-404 in both backends for whatever reason). Cool, I'm glad we agree. :) I'm happy to work on a patch if you have time to give me some guidance. -Joe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe
