Re: Haproxy and UTF8-encoded chars
On 07/25/2012 08:22 AM, Stojan Rancic (Iprom) wrote: Hello, we're experiencing issues with HAproxy 1.5-dev11 rejecting GET requests with UTF8-encoded characters. The encoding happens with Javascript's Encode function for east european characters (š, č, ž, etc) . The requests (as seen from 'echo show errors | socat stdio unix-connect:/var/run/haproxy.sock') are: Total events captured on [25/Jul/2012:08:10:16.070] : 1347 [25/Jul/2012:08:10:16.033] frontend http-in (#2): invalid request backend NONE (#-1), server NONE (#-1), event #1346 src 91.216.172.145:40752, session #527199, session flags 0x HTTP msg state 27, msg flags 0x, tx flags 0x HTTP chunk len 0 bytes, HTTP body len 0 bytes buffer flags 0x00809002, out 0 bytes, total 873 bytes pending 873 bytes, wrapping at 16384, error at position 51: 0 GET /XXX/YYY?z=39;t=js;sid=index;ssid=\xC2\xA7=index;m=ZZ 00064+ ZZ;ref=http://www.ZZZ.com/lala;num=9;kw=;flash=0;res=lala;r 00134+ e=http%3A%2F%2Fwww.QQQ.com%2Fsi%2FZZZ.html;rmc=1343196615443;cpre 00204+ mium=false;url=http%3A//www.ZZZ.com/lala HTTP/1.1\r\n I think that you should urlencode utf8 strings you want to put into URI or query string. Check out encodeURIComponent() -- Brane F. Gračnar skrbnik aplikacij/applications manager e: brane.grac...@tsmedia.si TSmedia, d.o.o. a: Cigaletova 15, 1000 Ljubljana; Slovenia t: +386 1 473 00 10 f: +386 1 473 00 16
Re: acl routing/redirect to specific backend system
On 06/26/2012 10:17 AM, Joeri Blokhuis | DongIT wrote: Thank you for your reply Bapiste. My setup is using HTTPS so I can't use your suggestion. Is there any other solution when using HTTPS? Yes, you can put ssl offloader (stud, stunnel, nginx) in front of haproxy. Cheers, Brane
Re: [ANNOUNCE] haproxy 1.5-dev10
10x for great progress!!! I have a question regarding IP based stick tables. Currently i have the following setup: backend some_backend BEGIN: Session stickyness stick on src table STICK_some_backend stick on src6 table STICK6_some_backend backend STICK_some_backend stick-table type ip size 200k expire 2h backend STICK6_some_backend stick-table type ipv6 size 200k expire 2h This works great for IPv4 and IPv6 clients. Since -dev9 src6 is gone, but stick type ipv6 is still there; i'd like to upgrade to -dev10 but i'm confused about stick tables. Are two backends for session stickyness still necessary or can i have only one for both address families? Best regards, Brane
Re: [ANNOUNCE] haproxy 1.5-dev10
On 05/14/2012 11:15 AM, Willy Tarreau wrote: IPv4 addresses can be cast to IPv6 addresses, so if you need to store both IPv4 and IPv6 addresses, just use the IPv6 one and your IPv4 entries will automatically be converted when stored : backend some_backend BEGIN: Session stickyness stick on src table STICK_some_backend backend STICK_some_backend stick-table type ipv6 size 200k expire 2h Thanks alot, tried and works! Smooth upgrade! Best regards, Brane
Re: haproxy 1.5dev7 server check failed with IPv6
On 03/29/2012 10:20 PM, Sander Klein wrote: Are you sure it's not an config error on the webserver side? I've been running dev7 for quite some time and do a lot of IPv6 checks. Never had any problems with it. Same here. Best regards, Brane
Re: [PATCH] MEDIUM: stats: Add `show events` command.
On 03/25/2012 07:55 AM, Aman Gupta wrote: A 1 127.0.0.1:50869 - 127.0.0.1:9418 F 1 127.0.0.1:50869 - 127.0.0.1:9418 | 127.0.0.1:50870 - 127.0.0.1:6000 C 1 127.0.0.1:50869 - 127.0.0.1:9418 Is it possible to use [IP]:port format? We're already living in IPv6 world... Best regards, Brane
Re: question about reloading haproxy
On 02/10/2012 10:53 AM, Michele Mazzucco wrote: Hello Brane, yes, but that is equivalent to running the script as root... the effective user ID is 0. Nope, it's not :) You can configure sudo to allow specific user to run only /etc/init.d/haproxy reload without entering password. Your script can run without any special privileges and is still able to perform some task which requires root privileges. Brane
Re: Haproxy crashes?
On 01/24/2012 09:55 AM, Łukasz Michalski wrote: W dniu 2012-01-23 12:44, Thomas Bender pisze: I have no idea why haproxy stops working from time to time..There is not much traffic on this system and I can not see any reasons (no peaks, etc) why it randomly crashes up to 10 times a day (see attached screenshots from zabbix, red marks are the times where i get the failure email and monit restarted haproxy) Any ideas or approaches to locate the error? If you installed it from package then the first check I would do is to recompile it from sources and see if it still crashes. +1 ~ i would recompile haproxy from source too. I've encountered only 1 (one) haproxy process crash on a quite busy server in one year (1.4.14). 1.5-dev[5-7] never crashed on my setups. Server was a cheap box without ECC ram and i think that lack of ECC support was the issue. Best regards, Brane
Re: ACL to IPv6
On 01/18/2012 01:59 PM, Agustin Lopez wrote: Hello! I will like to know if it is possible set one ACL to filter IPv6 addresses. I have read that IPv4 is Ok. Some like: frontend ... acl ipv6_ok src :XXX::0:0:0:0:0/48 Nope, matching ipv6 addresses is currently unsupported in 1.4.x and in 1.5-devX. Too bad, i'd like to have that too. Best regards, Brane
Re: SSL best option for new deployments
On 12/13/2011 09:02 PM, John Lauro wrote: Been using haproxy for some time… but have not used it with SSL yet. I do need to preserve the IP address of the original client. So either transparent (is that possible when going through stunnel or other and haproxy on the same box), or X-Forwarded-for or similar added. You should probably put stud (https://github.com/bumptech/stud) in front of haproxy. It supports sendproxy protocol from haproxy 1.5, supports ipv6 and scaling out. There's also a patch for sendproxy protocol that pplies to haproxy 1.4. However, you shouldn't be afraid of running haproxy 1.5-devXX, it is really, really very stable. Best regards, Brane
Re: SSL best option for new deployments
On 12/13/2011 10:43 PM, David Prothero wrote: I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to stunnel for some reason? Stunnel usually uses thread-per-connection architecture - as you probably know this programming model has serious scaling issues. Stud is single-threaded and runs as single-master/multiple-workers process, meaning that it can efficiently utilize power of multi-core cpus without context-switching overheaded resulting from hundreds (possibly thousands) of threads competing for cpu time slice. Stud is implemented on top of libev, one of the most efficient event loops available. It also uses much less memory than stunnel (openssl = 1.x.x). Best regards, Brane
Re: git clone hangs?
On Wednesday 23 of November 2011 07:58:26 Willy Tarreau wrote: It is possible there are random network issue from time to time, I remember that git is particularly sensible to this as I've already had trouble cloning kernels in the past. Willy, have you considered migration of git repository to github? Git over http seems to have considerable overhead comparing to git native protocol or git+ssh. Best regards, Brane
Re: Using HAProxy for ldap
On Monday 24 of October 2011 14:29:07 Danie Weideman wrote: Is it possible to loadbalance between two active master ldap servers? If so I would like for one to be always persistent. Something like: frontend FE_ldap bind1.2.3.4:389 modetcp defailt_server BE_ldap backend BE_ldap modetcp server node_1 1.2.3.4:389 server node_2 5.6.7.8:389 backup If both nodes can act as masters, and you want persistence based on client's source, just add the following into backend section: stick-table type ip size 200k expire 60m stick on src Best regards, Brane
Re: php $_server variable when using haproxy stunnel
On Monday 24 of October 2011 20:48:33 Amol wrote: Hi, i was trying to check on my php variables using the following code on both my servers ?php if($_SERVER['HTTPS']) echo 'https'; else echo 'Not Https'; echo BR; $port = $_SERVER['SERVER_PORT']; echo $port; echo BR; $protocol = $_SERVER[SERVER_PROTOCOL]; echo $protocol; ? my output would be: Not Https 80 HTTP/1.1 my stunnel config is : --- [https-load] cert=/etc/stunnel/ssl/group-wildcard.pem key = /etc/stunnel/ssl/name.key accept=100.00.10.10:443 connect=11.10.51.231:8000 TIMEOUTclose=0 xforwardedfor=yes and haproxy config is : --- listen webcluster1 11.10.51.231:8000 mode http stats enable balance roundrobin cookie BALANCEID insert indirect nocache option httpclose option forwardfor except 127.0.0.1 option httpchk HEAD /check.txt HTTP/1.0 #http-check disable-on-404 server load1-app 11.10.42.17:80 cookie A check server load2-app 11.10.55.90:80 cookie B check How can i get my $_server variable to be 'https? and is my connection secure as of this arrangement? Between client and 100.00.10.10:443 = YES; between 100.00.10.10 and 11.10.51.231 = NO. If you want to have SERVER_PROTOCOL set to 'https' you should add this to your config: reqidel ^Server-Protocol: reqadd Server-Protocol:\ https if src 127.0.0.1 Regards, Brane
Re: php $_server variable when using haproxy stunnel
On Monday 24 of October 2011 23:13:54 Amol wrote: Thanks Brane for the reply but setting these options in my haproxy config reqidel ^Server-Protocol: reqadd Server-Protocol:\ https if src 127.0.0.1 gives me these errors $ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ALERT] 296/171242 (1024) : parsing [/etc/haproxy/haproxy.cfg:91] : error detected while parsing a 'reqadd' condition. [ALERT] 296/171242 (1024) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 296/171242 (1024) : Fatal errors found in configuration. Oh, ofcourse, acl should be named or anonymous in braces... Try this: acl trusted_source src 127.0.0.1 reqidel ^Server-Protocol: reqadd Server-Protocol:\ https if trusted_source Best regards, Brane
Re: Communicating with HA Proxy using Python
On Wednesday 05 of October 2011 20:54:24 Deepak Jha wrote: Hi, I am new to HaProxy, so I need some information regarding HAProxy. Basically I want to communicate with HAProxy in a virtual environment. This may include requesting it for some data or giving it some data. I want to know is it possible to do such operation ? If yes, can I get some pointer for this containing APIs? There is simple interface available by issuing commands via stats unix domain socket. I'm also in the process of creating rest/json interface... Best regards, Brane
Re: 500s with 1.4.18 and 1.5d7
On Monday 03 of October 2011 20:09:17 Hank A. Paulson wrote: I am not sure if these counts are exceeding the never threshold 500 when haproxy encounters an unrecoverable internal error, such as a memory allocation failure, which should never happen I am not sure what I can do to troubleshoot this since it is in prod :( Is there a way to set it to core dump and die when it has a 500? Are you sure, that these are not upstream server 500 errors? Best regards, Brane
Re: Source based session stickyness
On Tuesday 27 of September 2011 21:13:01 Willy Tarreau wrote: Hi Brane, You can have only one type per stick-table but one stick-table per backend. So you can arbitrarily declare that the first backend stores IPv4 addresses and the second one stores IPv6 addresses. You can have several (I think 4) stick on rules and only the ones that match will apply. So you could very well do something like this : backend BACK option http-server-close stick on src table IPv4 stick on src6 table IPv6 backend IPv4 # not used, just a table holder stick-table type ip size 200k expire 15m backend IPv6 # not used, just a table holder stick-table type ipv6 size 200k expire 15m Works flawlessly! After several more readings of stick* directives docs everything now makes sense. Thanks ALOT! Best regards, Brane
Source based session stickyness
Hello! Is there a possibility to use source-based session stickyness when same backend is shared between many frontends, some with ipv6, some with ipv4 listeners? Something like: frontend FE4 bind 127.0.0.1:8001 accept-proxy default_backend BACK frontend FE6 bind 127.0.0.1:8002 accept-proxy default_backend BACK backend BACK option http-server-close stick-table type ipv6 size 200k expire 15m stick on src6 ... If i set stick table to ipv6, then it doesn't work for ipv4 clients and vice versa... I'm using haproxy 1.5-dev7-snapshot-20110917 behind patched (proxy protocol) stunnel ssl offloader. Is there any better way to achieve source address session stickyness other than defining two backends? Best regards, Brane
Re: HAProxy 1.5-dev7 attempting to connect to real server port of twice virtual server port
On Wednesday 21 of September 2011 17:30:05 Nick Chalk wrote: Afternoon all. We have come across an interesting problem with HAProxy 1.5-dev7: with the config below, the proxy attempts to connect to a real server port of twice the virtual server's port. listen v1 bind 192.168.69.32:80 mode http balance leastconn server backup 127.0.0.1:9081 backup option httpclose option redispatch option abortonclose maxconn 4 log global option httplog server r41 192.168.68.41 weight 1 check port 80 inter 2000 rise 2 fall 3 minconn 0 maxconn 0 Try replacing this line with: server r41 192.168.68.41:80 weight 1 check inter 2000 rise 2 fall 3 minconn 0 maxconn 0 Best regards, Brane
Re: haproxy at amazon
On Tuesday 20 of September 2011 02:02:27 Dean Hiller wrote: We are running haproxy at amazon and running some load tests and seem to be hitting some bottleneck between haproxy and webservers or haproxy itself. How can you tell when haproxy is maxed out? Will cpu hit 100% or is it some other characteristic? our cpu is 4% and I only have 10 webservers and 10 clients, and my 10 clients generate about 1000 requests/second each on a socket and each one is stateless independent of the other, no session is saved at all. If you configure it correctly (haproxy bound to some specific core, network interrupts to some other core sharing L2 cache with haproxy core), you should see 100% on haproxy core (70% system, 30% user if running in L7 with few acls and rewrites) and around 25% on core servicing network interrupts. In full http tunneling mode you should see both cores saturated ad 100%. You should check traffic on your haproxy host both ways using tcpdump. Regards, Brane
Re: PROXY protocol and setting headers X-Forwarded-Protocol=https ou X-Forwarded-Ssl=on
On Monday 19 of September 2011 06:18:45 Willy Tarreau wrote: frontend xxx bind 1.2.3.4:80 bind /var/run/haproxy/sock-xxx accept-proxy But this requires that the ssl termination supports unix sockets and I believe that stud currently does not. Just a quick question, Willy; I read somewhere, that zero-copy is not supported on unix sockets; Is this true? If yes, does that also affect linux tcp splicing? Regards, Brane
Re: [PATCH] Read acl included files relative to the configuration file
On Thursday 08 of September 2011 11:21:34 Finn Arne Gangstad wrote: On Thu, Sep 08, 2011 at 07:43:46AM +0200, Willy Tarreau wrote: Hi again, This morning I had an better idea : pass the config directory parameter on the command line and have haproxy chdir() to it. That way, everything specified after it is relative to this dir, and you don't need a full path for config files. Eg : haproxy -C /etc/haproxy -f haproxy.cfg I think it's easier to explain and to understand than previous proposal, and it can completely solve your multi-machine issue (well doing cd before starting haproxy also does, but I agree it can be less convenient, especially when copy-pasting a command line from ps). What about settings this varible by itself, for example, setting it by dirname(config_file) inside haproxy? Brane
Re: X-Forwarded-For contortions
On Friday 12 of August 2011 20:17:11 Bryan Talbot wrote: What are my other options? There are multiple backends so having one shared front end and duplicating the backend sections and putting the XFF handling there isn't any better. Routing connections through the proxy twice for every hit isn't very nice either since the number of hits isn't low (not high by Willy's standards though) and it really pollutes the logs which we do analyze. Didn't tried this config, but it should work according to docs... frontend some_fe acl trusted_proxies a.b.c.d/24 reqidel ^X-Forwarded-For: unless trusted_proxies option forwardfor except a.b.c.d/24 default_backend some_be backend some_be Best regards, Brane
Re: haproxy API patch
On Sunday 14 of August 2011 22:01:53 Jeff Buchbinder wrote: I've been working on an API patch, where certain functionality is exposed over the stats HTTP service. The fork where I have been working on this is available here: https://github.com/jbuchbinder/haproxy The full patch (which I imported from my old working tree) is here, if you want to see just the changes: https://github.com/jbuchbinder/haproxy/commit/0f924468977fc71f2530837e3e44c f47fc00fd0f Documentation is available here: https://github.com/jbuchbinder/haproxy/blob/master/README.API Don't get me wrong, but i think that it would be much better to implement api on top of unix socket statistics interface. I'm already working on it and it will feature strong encryption, authentication. Just my opinion. But you're right, we need RESTful api for haproxy. Best regards, Brane
Re: https from source to destination
On Thursday 14 of July 2011 05:10:44 James Bardin wrote: Some IT contracts suck. ;) Yes, they do :) I guess your only option is nginx, which supports https upstreams. You can nginx use nginx_http_upstream_fair (http://wiki.nginx.org/HttpUpstreamFairModule) module to achieve fair load distribution and http_healthcheck module (http://wiki.nginx.org/HttpHealthcheckModule) to implement backend health checking. But note, that nginx doesn't support http/1.1 upstreams, nor it doesn't support ipv6 upstreams. If nginx is not an option you're in trouble. Best regards, Brane
Re: Proxy Protocol in 1.4.x ?
On Friday 08 of July 2011 23:17:12 Sébastien Estienne wrote:
http://devblog.bu.mp/introducing-stud ). Today we have the choice between:
- haproxy 1.4 + patched stunnel
- haproxy 1.5 dev + stud
- patched haproxy 1.4 + stud
There is also fourth option:
- patched haproxy 1.4.x + patched stunnel (accept-proxy patch)
I'm using attached patch (found it on internet) with stunnel 4.34.
Best regards, Brane
diff -ru stunnel-4.34/src/client.c stunnel-4.34-exceliance-aloha-sendproxy/src/client.c
--- stunnel-4.34/src/client.c 2010-09-14 17:03:43.0 +0200
+++ stunnel-4.34-exceliance-aloha-sendproxy/src/client.c 2010-12-07 22:46:32.421248698 +0100
@@ -86,6 +86,8 @@
c-opt=opt;
c-local_rfd.fd=rfd;
c-local_wfd.fd=wfd;
+if (c-opt-option.sendproxy)
+c-sendproxy = 1;
return c;
}
@@ -564,6 +566,73 @@
}
}
+ if (c-sendproxy !c-ssl_ptr) {
+ int cfd;
+ struct sockaddr_storage local_addr;
+ struct sockaddr_storage peer_addr;
+ u_char family = AF_UNSPEC;
+
+ cfd = SSL_get_fd(c-ssl);
+ if (cfd != -1) {
+ size_t namelen;
+
+ namelen = sizeof(local_addr);
+ if (!getsockname(cfd, (struct sockaddr *)local_addr, namelen)) {
+namelen = sizeof(peer_addr);
+if (!getpeername(cfd, (struct sockaddr *)peer_addr, namelen))
+ family = peer_addr.ss_family;
+ }
+ }
+
+ if (family == AF_INET) {
+
+ if (BUFFSIZE = 11) {
+memcpy(c-ssl_buff, PROXY TCP4 , 11);
+c-ssl_ptr += 11;
+ }
+
+ if (inet_ntop(peer_addr.ss_family, ((struct sockaddr_in*)peer_addr)-sin_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+ }
+ if (c-ssl_ptr != BUFFSIZE) {
+c-ssl_buff[c-ssl_ptr] = ' ';
+c-ssl_ptr++;
+ }
+ if (inet_ntop(local_addr.ss_family, ((struct sockaddr_in*)local_addr)-sin_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+ }
+ c-ssl_ptr += snprintf(c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr, %u %u\r\n, ntohs(((struct sockaddr_in*)peer_addr)-sin_port), ntohs(((struct sockaddr_in*)local_addr)-sin_port));
+ }
+#if defined(USE_IPv6) !defined(USE_WIN32)
+ else if (family == AF_INET6) {
+
+ if (BUFFSIZE = 11) {
+memcpy(c-ssl_buff, PROXY TCP6 , 11);
+c-ssl_ptr += 11;
+}
+
+if (inet_ntop(peer_addr.ss_family, ((struct sockaddr_in6*)peer_addr)-sin6_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+}
+if (c-ssl_ptr != BUFFSIZE) {
+c-ssl_buff[c-ssl_ptr] = ' ';
+c-ssl_ptr++;
+}
+if (inet_ntop(local_addr.ss_family, ((struct sockaddr_in6*)local_addr)-sin6_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+}
+c-ssl_ptr += snprintf(c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr, %u %u\r\n, ntohs(((struct sockaddr_in6*)peer_addr)-sin6_port), ntohs(((struct sockaddr_in6*)local_addr)-sin6_port));
+ }
+#endif
+ else {
+ if (BUFFSIZE = 15) {
+memcpy(c-ssl_buff, PROXY UNKNOWN\r\n , 15);
+c-ssl_ptr += 15;
+}
+ }
+ c-sendproxy = 0;
+ }
+
/** update *_wants_* based on new *_ptr */
/* this update is also required for SSL_pending() to be used */
read_wants_read=
diff -ru stunnel-4.34/src/options.c stunnel-4.34-exceliance-aloha-sendproxy/src/options.c
--- stunnel-4.34/src/options.c 2010-09-14 17:09:36.0 +0200
+++ stunnel-4.34-exceliance-aloha-sendproxy/src/options.c 2010-12-07 22:46:26.613204761 +0100
@@ -818,6 +818,29 @@
}
#endif
+/* sendproxy */
+switch(cmd) {
+case CMD_INIT:
+section-option.sendproxy=0;
+break;
+case CMD_EXEC:
+if(strcasecmp(opt, sendproxy))
+break;
+if(!strcasecmp(arg, yes))
+section-option.sendproxy=1;
+else if(!strcasecmp(arg, no))
+section-option.sendproxy=0;
+else
+return argument should be either 'yes' or 'no';
+return NULL; /* OK */
+case CMD_DEFAULT:
+break;
+case CMD_HELP:
+s_log(LOG_NOTICE, %-15s = yes|no append proxy prefix,
+sendproxy);
+break;
+}
+
/* exec */
switch(cmd) {
case CMD_INIT:
diff -ru stunnel-4.34/src/prototypes.h stunnel-4.34-exceliance-aloha-sendproxy/src/prototypes.h
--- stunnel-4.34/src/prototypes.h 2010-09-14 17:09:50.0 +0200
+++ stunnel-4.34-exceliance-aloha-sendproxy/src/prototypes.h 2010-12-07 22:47:39.633763055 +0100
@@ -176,6 +176,7 @@
unsigned int retry:1; /* loop remote+program */
Re: Proxy Protocol in 1.4.x ?
On Thursday 07 of July 2011 18:30:10 Sebastien Estienne wrote:
Hello,
I'd like to use stud https://github.com/bumptech/stud with Haproxy for
SSL support.
Stud implement the haproxy proxy protocol, and i'd like to know if
this will be backported to haproxy 1.4 ?
First, thanks for pointing out stud, looks very promising!
I'm using accept-proxy patch with haproxy 1.4.15 in production for two months
without any problems on moderate loaded instance (cca 3k concurrent
connections, 700-800 reqs/sec)...
Patch was written by Cyril Bonte, i'm just providing patch file.
Willy, i've been thinking about extending proxy protocol - it would be very
useful if protocol would allow additional, optional fields like tls_cipher,
tls_client_cert info etc... What is your opinion?
I'm also missing ability in haproxy (some kind of built-in acl) if connection
was accepted from listener with accept-proxy flag set.
Best regards, Brane
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;
+
Re: error with ipv6 backend www server
On Wednesday 15 of June 2011 09:12:00 Willy Tarreau wrote: The server address syntax is : server name ip:port So you should have a colon and not a space before '80' : 3ffe::21da:7:3c06:7c4c:8215:2:80 Note that the syntax is non-ambiguous because the last colon is mandatory before the port, so anything which is before the last colon is the address Willy, i have a suggestion; what if server declaration would be changed to: server [ip_address]:port server [host.example.com]:port That would be new, preferred format, while old one would be supported, but deprecated. I think it would be trivial to implement and configuration would be much more readable. The same with logs. What do you think? Best regards, Brane
Re: url_beg
On Friday 10 of June 2011 16:11:02 Gerd Müller wrote: same effect :( Do you have option http-server-close in your backend specification? Brane
Re: haproxy participates to world IPv6 day
On Wednesday 08 of June 2011 07:42:24 Willy Tarreau wrote: Hi all, The haproxy website was registered among about 300 other ones which participates to the world IPv6 day event : Willy, preparations for IPv6 day would be a really big challenge if HaProxy would not exist. Thanks! Best regards, Brane
Re: Haproxy Reg Exps ...
On Monday 06 of June 2011 11:56:05 Georgi Georgiev wrote: Hi to all , Yesterday I’ve try to match on regexp from client user-agent and redirect it .. The configuration is on frontend is like this: …… acl test_match hdr_reg -i user\-agent:\ test|android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobil e|ip(hone|od)|iris|kindle|lge\ |maemo|midp|mmp|opera\ m(ob|in)i|palm(\ os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)| vodafone|wap|windows\ (ce|phone)|xda|xiino redirect prefix http://xxx?rule1 if test_match ……. It is working fine for most of PCs and mobiles ( redirect only mobile ) but with exactly this user-agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.6; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET4.0C; .NET CLR 3.0.30729) ( IE 8 with Vista SP2 ) it somehow match rule …… So the question is : Where can I find some info about regular expressions library used in haproxy ? I need to find out why it match in this very case ….. $ haproxy -vv | grep -i options OPTIONS = USE_LINUX_SPLICE=1 USE_LIBCRYPT=1 USE_REGPARM=1 USE_PCRE=1 USE_STATIC_PCRE=1 You're using libpcre if USE_PCRE=1. You can check pcre regex with grep -P (it doesn't match on my machine): $ echo Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.6; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET4.0C; .NET CLR 3.0.30729) | grep -P 'test|android|avantgo|blackberry|blazer|compal|elaine| fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge\ |maemo|midp|mmp|opera\ m(ob|in)i|palm(\os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\. (browser|link)|vodafone|wap|windows\ (ce|phone)|xda|xiino' $ echo $? 1 Best regards, Brane
Re: [PATCH] include configuration directive for haproxy 1.5-dev3
On Wednesday 15 of December 2010 15:18:55 L. Alberto Giménez wrote: On 14/12/2010 20:30, Brane F. Gračnar wrote: Hello :) Hi Brane, I haven't had time to test your patch, but after a visual review made some doubts to come up. It also applies to 1.4.10. @@ -5343,6 +5440,40 @@ int readcfgfile(const char *file) err_code |= ERR_ALERT | ERR_FATAL; } [...] + memset(file_dir, '\0', buf_len); + strcpy(file_dir, file); + strcpy(file_dir, dirname(file_dir)); The first strcpy would be useless here? I experienced crashes without first strcpy. dirname(3) may change input buffer. From dirname(3): --- snip --- Both dirname() and basename() may modify the contents of path, so it may be desirable to pass a copy when calling one of these functions. --- snip --- @@ -5193,6 +5195,99 @@ out: return err_code; } [...] + /** we want to support relative to include file glob patterns */ + int buf_len = 3; + if (dir != NULL) + buf_len += strlen(dir); Could you please clarify where does that magic 3 coming from?. As I said, I couldn't test the patch, and I can't figure it out for myself. Initial buffer length should be 2 (To hold at least '/' and '\0' characters). I want to concatenate directory, /, glob pattern into variable real_pattern. Complete buffer length is: strlen(dir) + strlen(pattern) + 1 (slash character) + 1 (string termination byte). I set it to 3 becouse of just in case :) I think that this shouldn't be a problem becouse configuration parsing is done only at haproxy startup and real_pattern is always freed after usage. Best regards, Brane
PROXY protocol and SSL session information
Hello there! I was wondering how to push information about SSL session (cipher, strength, certificate info) to backends. This is usualy done by injecting request headers before sending request to application servers or webserver handlers. I've read proxy protocol specification and i don't see any option how to share this info from stunnel to haproxy. This goal is achievable by putting nginx as SSL ofloader before haproxy. Nginx only supports http 1.0 in proxy mode which has obvious drawbacks (no chunked backend response support). Does anyone use nginx before haproxy instead of stunnel? Best regards, Brane
