From 0174f319a2dfaf54b03edcfc751aa4820991a8e0 Mon Sep 17 00:00:00 2001 From: willy tarreau Date: Sun, 18 Dec 2005 01:02:42 +0100 Subject: [PATCH] * released 1.2.3 (1.1.30) * add an architecture guide to the documentation * released without any changes * increased default BUFSIZE to 16 kB to accept max headers of 8 kB which is compatible with Apache. This limit can be configured in the makefile now. Thanks to Eric Fehr for the checks. * added a per-server "source" option which now makes it possible to bind to a different source for each (potentially identical) server. * changed cookie-based server selection slightly to allow several servers to share a same cookie, thus making it possible to associate backup servers to live servers and ease soft-stop for maintenance periods. (Alexander Lazic) * added the cookie 'prefix' mode which makes it possible to use persistence with thin clients which support only one cookie. The server name is prefixed before the application cookie, and restore back. * fixed the order of servers within an instance to match documentation. Now the servers are *really* used in the order of their declaration. This is particularly important when multiple backup servers are in use. --- CHANGELOG | 20 + Makefile | 9 +- doc/architecture.txt | 979 +++++++++++++++++++++++++++++++++++++++++++ doc/haproxy-en.txt | 117 +++++- doc/haproxy-fr.txt | 116 ++++- haproxy.c | 301 +++++++++---- 6 files changed, 1444 insertions(+), 98 deletions(-) create mode 100644 doc/architecture.txt diff --git a/CHANGELOG b/CHANGELOG index 84e022862..8057f87c0 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,6 +1,26 @@ ChangeLog : =========== +2005/01/22 : 1.2.3 (1.1.30) + - add an architecture guide to the documentation + - released without any changes + +2004/12/26 : 1.2.3-pre1 (1.1.30-pre1) + - increased default BUFSIZE to 16 kB to accept max headers of 8 kB which is + compatible with Apache. This limit can be configured in the makefile now. + Thanks to Eric Fehr for the checks. + - added a per-server "source" option which now makes it possible to bind to + a different source for each (potentially identical) server. + - changed cookie-based server selection slightly to allow several servers to + share a same cookie, thus making it possible to associate backup servers to + live servers and ease soft-stop for maintenance periods. (Alexander Lazic) + - added the cookie 'prefix' mode which makes it possible to use persistence + with thin clients which support only one cookie. The server name is prefixed + before the application cookie, and restore back. + - fixed the order of servers within an instance to match documentation. Now + the servers are *really* used in the order of their declaration. This is + particularly important when multiple backup servers are in use. + 2004/10/18 : 1.2.2 (1.1.29) - fixed a bug where a TCP connection would be logged twice if the 'logasap' option was enabled without the 'tcplog' option. diff --git a/Makefile b/Makefile index f9fb9f9a8..7caf492c4 100644 --- a/Makefile +++ b/Makefile @@ -61,12 +61,19 @@ LIBS.pcre=-L$(PCREDIR)/lib -lpcreposix -lpcre #DEBUG = DEBUG = -g +# if small memory footprint is required, you can reduce the buffer size. There +# are 2 buffers per concurrent session, so 16 kB buffers will eat 32 MB memory +# with 1000 concurrent sessions. +#SMALL_OPTS = -DBUFSIZE=8192 -DMAXREWRITE=1024 +SMALL_OPTS = + + # global options TARGET_OPTS=$(COPTS.$(TARGET)) REGEX_OPTS=$(COPTS.$(REGEX)) CPU_OPTS=$(COPTS.$(CPU)) -COPTS=$(CPU_OPTS) $(TARGET_OPTS) $(REGEX_OPTS) +COPTS=$(CPU_OPTS) $(TARGET_OPTS) $(REGEX_OPTS) $(SMALL_OPTS) LIBS=$(LIBS.$(TARGET)) $(LIBS.$(REGEX)) # - use -DSTATTIME=0 to disable statistics, else specify an interval in diff --git a/doc/architecture.txt b/doc/architecture.txt new file mode 100644 index 000000000..06a044622 --- /dev/null +++ b/doc/architecture.txt @@ -0,0 +1,979 @@ + ------------------- + H A - P r o x y + Architecture Guide + ------------------- + version 1.1.30 + willy tarreau + 2004/11/28 + + +This document provides real world examples with working configurations. +Please note that except stated otherwise, global configuration parameters +such as logging, chrooting, limits and time-outs are not described here. + +=================================================== +1. Simple HTTP load-balancing with cookie insertion +=================================================== + +A web application often saturates the front-end server with high CPU loads, +due to the scripting language involved. It also relies on a back-end database +which is not much loaded. User contexts are stored on the server itself, and +not in the database, so that simply adding another server with simple IP/TCP +load-balancing would not work. + + +-------+ + |clients| clients and/or reverse-proxy + +---+---+ + | + -+-----+--------+---- + | _|_db + +--+--+ (___) + | web | (___) + +-----+ (___) + 192.168.1.1 192.168.1.2 + + +Replacing the web server with a bigger SMP system would cost much more than +adding low-cost pizza boxes. The solution is to buy N cheap boxes and install +the application on them. Install haproxy on the old one which will spread the +load across the new boxes. + + 192.168.1.1 192.168.1.11-192.168.1.14 192.168.1.2 + -------+-----------+-----+-----+-----+--------+---- + | | | | | _|_db + +--+--+ +-+-+ +-+-+ +-+-+ +-+-+ (___) + | LB1 | | A | | B | | C | | D | (___) + +-----+ +---+ +---+ +---+ +---+ (___) + haproxy 4 cheap web servers + + +Config on haproxy (LB1) : +------------------------- + + listen 192.168.1.1:80 + mode http + balance roundrobin + cookie SERVERID insert indirect + option httpchk HEAD /index.html HTTP/1.0 + server webA 192.168.1.11:80 cookie A check + server webB 192.168.1.12:80 cookie B check + server webC 192.168.1.13:80 cookie C check + server webD 192.168.1.14:80 cookie D check + + +Description : +------------- + - LB1 will receive clients requests. + - if a request does not contain a cookie, it will be forwarded to a valid + server + - in return, a cookie "SERVERID" will be inserted in the response holding the + server name (eg: "A"). + - when the client comes again with the cookie "SERVERID=A", LB1 will know that + it must be forwarded to server A. The cookie will be removed so that the + server does not see it. + - if server "webA" dies, the requests will be sent to another valid server + and a cookie will be reassigned. + + +Flows : +------- + +(client) (haproxy) (server A) + >-- GET /URI1 HTTP/1.0 ------------> | + ( no cookie, haproxy forwards in load-balancing mode. ) + | >-- GET /URI1 HTTP/1.0 ----------> + | <-- HTTP/1.0 200 OK -------------< + ( the proxy now adds the server cookie in return ) + <-- HTTP/1.0 200 OK ---------------< | + Set-Cookie: SERVERID=A | + >-- GET /URI2 HTTP/1.0 ------------> | + Cookie: SERVERID=A | + ( the proxy sees the cookie. it forwards to server A and deletes it ) + | >-- GET /URI2 HTTP/1.0 ----------> + | <-- HTTP/1.0 200 OK -------------< + ( the proxy does not add the cookie in return because the client knows it ) + <-- HTTP/1.0 200 OK ---------------< | + >-- GET /URI3 HTTP/1.0 ------------> | + Cookie: SERVERID=A | + ( ... ) + + +Limits : +-------- + - if clients use keep-alive (HTTP/1.1), only the first response will have + a cookie inserted, and only the first request of each session will be + analyzed. This does not cause trouble in insertion mode because the cookie + is put immediately in the first response, and the session is maintained to + the same server for all subsequent requests in the same session. However, + the cookie will not be removed from the requests forwarded to the servers, + so the server must not be sensitive to unknown cookies. If this causes + trouble, you can disable keep-alive by adding the following option : + + option httpclose + + - if for some reason the clients cannot learn more than one cookie (eg: the + clients are indeed some home-made applications or gateways), and the + application already produces a cookie, you can use the "prefix" mode (see + below). + + - LB1 becomes a very sensible server. If LB1 dies, nothing works anymore. + => you can back it up using keepalived. + + - if the application needs to log the original client's IP, use the + "forwardfor" option which will add an "X-Forwarded-For" header with the + original client's IP address. You must also use "httpclose" to ensure + that you will rewrite every requests and not only the first one of each + session : + + option httpclose + option forwardfor + + The web server will have to be configured to use this header instead. + For example, on apache, you can use LogFormat for this : + + LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b " combined + CustomLog /var/log/httpd/access_log combined + + +================================================================== +2. HTTP load-balancing with cookie prefixing and high availability +================================================================== + +Now you don't want to add more cookies, but rather use existing ones. The +application already generates a "JSESSIONID" cookie which is enough to track +sessions, so we'll prefix this cookie with the server name when we see it. +Since the load-balancer becomes critical, it will be backed up with a second +one in VRRP mode using keepalived. + +Download the latest version of keepalived from this site and install it +on each load-balancer LB1 and LB2 : + + http://www.keepalived.org/ + +You then have a shared IP between the two load-balancers (we will still use the +original IP). It is active only on one of them at any moment. To allow the +proxy to bind to the shared IP, you must enable it in /proc : + +# echo 1 >/proc/sys/net/ipv4/ip_nonlocal_bind + + + shared IP=192.168.1.1 + 192.168.1.3 192.168.1.4 192.168.1.11-192.168.1.14 192.168.1.2 + -------+------------+-----------+-----+-----+-----+--------+---- + | | | | | | _|_db + +--+--+ +--+--+ +-+-+ +-+-+ +-+-+ +-+-+ (___) + | LB1 | | LB2 | | A | | B | | C | | D | (___) + +-----+ +-----+ +---+ +---+ +---+ +---+ (___) + haproxy haproxy 4 cheap web servers + keepalived keepalived + + +Config on both proxies (LB1 and LB2) : +-------------------------------------- + + listen 192.168.1.1:80 + mode http + balance roundrobin + cookie JSESSIONID prefix + option httpclose + option forwardfor + option httpchk HEAD /index.html HTTP/1.0 + server webA 192.168.1.11:80 cookie A check + server webB 192.168.1.12:80 cookie B check + server webC 192.168.1.13:80 cookie C check + server webD 192.168.1.14:80 cookie D check + + +Notes: the proxy will modify EVERY cookie sent by the client and the server, +so it is important that it can access to ALL cookies in ALL requests for +each session. This implies that there is no keep-alive (HTTP/1.1), thus the +"httpclose" option. Only if you know for sure that the client(s) will never +use keep-alive, you can remove this option. + + +Description : +------------- + - LB1 is VRRP master (keepalived), LB2 is backup. + - LB1 will receive clients requests on IP 192.168.1.1. + - both load-balancers send their checks from their native IP. + - if a request does not contain a cookie, it will be forwarded to a valid + server + - in return, if a JESSIONID cookie is seen, the server name will be prefixed + into it, followed by a delimitor ('~') + - when the client comes again with the cookie "JSESSIONID=A~xxx", LB1 will + know that it must be forwarded to server A. The server name will then be + extracted from cookie before it is sent to the server. + - if server "webA" dies, the requests will be sent to another valid server + and a cookie will be reassigned. + + +Flows : +------- + +(client) (haproxy) (server A) + >-- GET /URI1 HTTP/1.0 ------------> | + ( no cookie, haproxy forwards in load-balancing mode. ) + | >-- GET /URI1 HTTP/1.0 ----------> + | X-Forwarded-For: 10.1.2.3 + | <-- HTTP/1.0 200 OK -------------< + ( no cookie, nothing changed ) + <-- HTTP/1.0 200 OK ---------------< | + >-- GET /URI2 HTTP/1.0 ------------> | + ( no cookie, haproxy forwards in lb mode, possibly to another server. ) + | >-- GET /URI2 HTTP/1.0 ----------> + | X-Forwarded-For: 10.1.2.3 + | <-- HTTP/1.0 200 OK -------------< + | Set-Cookie: JSESSIONID=123 + ( the cookie is identified, it will be prefixed with the server name ) + <-- HTTP/1.0 200 OK ---------------< | + Set-Cookie: JSESSIONID=A~123 | + >-- GET /URI3 HTTP/1.0 ------------> | + Cookie: JSESSIONID=A~123 | + ( the proxy sees the cookie, removes the server name and forwards + to server A which sees the same cookie as it previously sent ) + | >-- GET /URI3 HTTP/1.0 ----------> + | Cookie: JSESSIONID=123 + | X-Forwarded-For: 10.1.2.3 + | <-- HTTP/1.0 200 OK -------------< + ( no cookie, nothing changed ) + <-- HTTP/1.0 200 OK ---------------< | + ( ... ) + + + +======================================================== +2.1 Variations involving external layer 4 load-balancers +======================================================== + +Instead of using a VRRP-based active/backup solution for the proxies, +they can also be load-balanced by a layer4 load-balancer (eg: Alteon) +which will also check that the services run fine on both proxies : + + | VIP=192.168.1.1 + +----+----+ + | Alteon | + +----+----+ + | + 192.168.1.3 | 192.168.1.4 192.168.1.11-192.168.1.14 192.168.1.2 + -------+-----+------+-----------+-----+-----+-----+--------+---- + | | | | | | _|_db + +--+--+ +--+--+ +-+-+ +-+-+ +-+-+ +-+-+ (___) + | LB1 | | LB2 | | A | | B | | C | | D | (___) + +-----+ +-----+ +---+ +---+ +---+ +---+ (___) + haproxy haproxy 4 cheap web servers + + +Config on both proxies (LB1 and LB2) : +-------------------------------------- + + listen 0.0.0.0:80 + mode http + balance roundrobin + cookie JSESSIONID prefix + option httpclose + option forwardfor + option httplog + option dontlognull + option httpchk HEAD /index.html HTTP/1.0 + server webA 192.168.1.11:80 cookie A check + server webB 192.168.1.12:80 cookie B check + server webC 192.168.1.13:80 cookie C check + server webD 192.168.1.14:80 cookie D check + +The "dontlognull" option is used to prevent the proxy from logging the health +checks from the Alteon. If a session exchanges no data, then it will not be +logged. + +Config on the Alteon : +---------------------- + +/c/slb/real 11 + ena + name "LB1" + rip 192.168.1.3 +/c/slb/real 12 + ena + name "LB2" + rip 192.168.1.4 +/c/slb/group 10 + name "LB1-2" + metric roundrobin + health tcp + add 11 + add 12 +/c/slb/virt 10 + ena + vip 192.168.1.1 +/c/slb/virt 10/service http + group 10 + + +========================================================= +3. Simple HTTP/HTTPS load-balancing with cookie insertion +========================================================= + +This is the same context as in example 1 above, but the web +server uses HTTPS. + + +-------+ + |clients| clients + +---+---+ + | + -+-----+--------+---- + | _|_db + +--+--+ (___) + | SSL | (___) + | web | (___) + +-----+ + 192.168.1.1 192.168.1.2 + + +Since haproxy does not handle SSL, this part will have to be extracted from the +servers (freeing even more ressources) and installed on the load-balancer +itself. Install haproxy and apache+mod_ssl on the old box which will spread the +load between the new boxes. Apache will work in SSL reverse-proxy-cache. If the +application is correctly developped, it might even lower its load. However, +since there now is a cache between the clients and haproxy, some security +measures must be taken to ensure that inserted cookies will not be cached. + + + 192.168.1.1 192.168.1.11-192.168.1.14 192.168.1.2 + -------+-----------+-----+-----+-----+--------+---- + | | | | | _|_db + +--+--+ +-+-+ +-+-+ +-+-+ +-+-+ (___) + | LB1 | | A | | B | | C | | D | (___) + +-----+ +---+ +---+ +---+ +---+ (___) + apache 4 cheap web servers + mod_ssl + haproxy + + +Config on haproxy (LB1) : +------------------------- + + listen 127.0.0.1:8000 + mode http + balance roundrobin + cookie SERVERID insert indirect nocache + option httpchk HEAD /index.html HTTP/1.0 + server webA 192.168.1.11:80 cookie A check + server webB 192.168.1.12:80 cookie B check + server webC 192.168.1.13:80 cookie C check + server webD 192.168.1.14:80 cookie D check + + +Description : +------------- + - apache on LB1 will receive clients requests on port 443 + - it forwards it to haproxy bound to 127.0.0.1:8000 + - if a request does not contain a cookie, it will be forwarded to a valid + server + - in return, a cookie "SERVERID" will be inserted in the response holding the + server name (eg: "A"), and a "Cache-control: private" header will be added + so that the apache does not cache any page containing such cookie. + - when the client comes again with the cookie "SERVERID=A", LB1 will know that + it must be forwarded to server A. The cookie will be removed so that the + server does not see it. + - if server "webA" dies, the requests will be sent to another valid server + and a cookie will be reassigned. + +Notes : +------- + - if the cookie works in "prefix" mode, there is no need to add the "nocache" + option because it is an application cookie which will be modified, and the + application flags will be preserved. + - if apache 1.3 is used as a front-end before haproxy, it always disables + HTTP keep-alive on the back-end, so there is no need for the "httpclose" + option on haproxy. + - configure apache to set the X-Forwarded-For header itself, and do not do + it on haproxy if you need the application to know about the client's IP. + + +Flows : +------- + +(apache) (haproxy) (server A) + >-- GET /URI1 HTTP/1.0 ------------> | + ( no cookie, haproxy forwards in load-balancing mode. ) + | >-- GET /URI1 HTTP/1.0 ----------> + | <-- HTTP/1.0 200 OK -------------< + ( the proxy now adds the server cookie in return ) + <-- HTTP/1.0 200 OK ---------------< | + Set-Cookie: SERVERID=A | + Cache-Control: private | + >-- GET /URI2 HTTP/1.0 ------------> | + Cookie: SERVERID=A | + ( the proxy sees the cookie. it forwards to server A and deletes it ) + | >-- GET /URI2 HTTP/1.0 ----------> + | <-- HTTP/1.0 200 OK -------------< + ( the proxy does not add the cookie in return because the client knows it ) + <-- HTTP/1.0 200 OK ---------------< | + >-- GET /URI3 HTTP/1.0 ------------> | + Cookie: SERVERID=A | + ( ... ) + + + +======================================== +4. Soft-stop for application maintenance +======================================== + +When an application is spread across several severs, the time to update all +instances increases, so the application seems jerky for a longer period. + +HAproxy offers several solutions for this. Although it cannot be reconfigured +without being stopped, not does it offer any external command, there are other +working solutions. + + +========================================= +4.1 Soft-stop using a file on the servers +========================================= + +This trick is quite common and very simple: put a file on the server which will +be checked by the proxy. When you want to stop the server, first remove this +file. The proxy will see the server as failed, and will not send it any new +session, only the old ones if the "persist" option is used. Wait a bit then +stop the server when it does not receive anymore connections. + + + listen 192.168.1.1:80 + mode http + balance roundrobin + cookie SERVERID insert indirect + option httpchk HEAD /running HTTP/1.0 + server webA 192.168.1.11:80 cookie A check inter 2000 rise 2 fall 2 + server webB 192.168.1.12:80 cookie B check inter 2000 rise 2 fall 2 + server webC 192.168.1.13:80 cookie C check inter 2000 rise 2 fall 2 + server webD 192.168.1.14:80 cookie D check inter 2000 rise 2 fall 2 + option persist + redispatch + contimeout 5000 + + +Description : +------------- + - every 2 seconds, haproxy will try to access the file "/running" on the + servers, and declare the server as down after 2 attempts (4 seconds). + - only the servers which respond with a 200 or 3XX response will be used. + - if a request does not contain a cookie, it will be forwarded to a valid + server + - if a request contains a cookie for a failed server, haproxy will insist + on trying to reach the server anyway, to let the user finish what he was + doing. ("persist" option) + - if the server is totally stopped, the connection will fail and the proxy + will rebalance the client to another server ("redispatch") + +Usage on the web servers : +-------------------------- +- to start the server : + # /etc/init.d/httpd start + # touch /home/httpd/www/running + +- to soft-stop the server + # rm -f /home/httpd/www/running + +- to completely stop the server : + # /etc/init.d/httpd stop + +Limits +------ +If the server is totally powered down, the proxy will still try to reach it +for those clients who still have a cookie referencing it, and the connection +attempt will expire after 5 seconds ("contimeout"), and only after that, the +client will be redispatched to another server. So this mode is only useful +for software updates where the server will suddenly refuse the connection +because the process is stopped. The problem is the same if the server suddenly +crashes. All of its users will be fairly perturbated. + + +================================== +4.2 Soft-stop using backup servers +================================== + +A better solution which covers every situation is to use backup servers. +Version 1.1.30 fixed a bug which prevented a backup server from sharing +the same cookie as a standard server. + + + listen 192.168.1.1:80 + mode http + balance roundrobin + redispatch + cookie SERVERID insert indirect + option httpchk HEAD / HTTP/1.0 + server webA 192.168.1.11:80 cookie A check port 81 inter 2000 + server webB 192.168.1.12:80 cookie B check port 81 inter 2000 + server webC 192.168.1.13:80 cookie C check port 81 inter 2000 + server webD 192.168.1.14:80 cookie D check port 81 inter 2000 + + server bkpA 192.168.1.11:80 cookie A check port 80 inter 2000 backup + server bkpB 192.168.1.12:80 cookie B check port 80 inter 2000 backup + server bkpC 192.168.1.13:80 cookie C check port 80 inter 2000 backup + server bkpD 192.168.1.14:80 cookie D check port 80 inter 2000 backup + +Description +----------- +Four servers webA..D are checked on their port 81 every 2 seconds. The same +servers named bkpA..D are checked on the port 80, and share the exact same +cookies. Those servers will only be used when no other server is available +for the same cookie. + +When the web servers are started, only the backup servers are seen as +available. On the web servers, you need to redirect port 81 to local +port 80, either with a local proxy (eg: a simple haproxy tcp instance), +or with iptables (linux) or pf (openbsd). This is because we want the +real web server to reply on this port, and not a fake one. Eg, with +iptables : + + # /etc/init.d/httpd start + # iptables -t nat -A PREROUTING -p tcp --dport 81 -j REDIRECT --to-port 80 + +A few seconds later, the standard server is seen up and haproxy starts to send +it new requests on its real port 80 (only new users with no cookie, of course). + +If a server completely crashes (even if it does not respond at the IP level), +both the standard and backup servers will fail, so clients associated to this +server will be redispatched to other live servers and will lose their sessions. + +Now if you want to enter a server into maintenance, simply stop it from +responding on port 81 so that its standard instance will be seen as failed, +but the backup will still work. Users will not notice anything since the +service is still operational : + + # iptables -t nat -D PREROUTING -p tcp --dport 81 -j REDIRECT --to-port 80 + +The health checks on port 81 for this server will quickly fail, and the +standard server will be seen as failed. No new session will be sent to this +server, and existing clients with a valid cookie will still reach it because +the backup server will still be up. + +Now wait as long as you want for the old users to stop using the service, and +once you see that the server does not receive any traffic, simply stop it : + + # /etc/init.d/httpd stop + +The associated backup server will in turn fail, and if any client still tries +to access this particular server, he will be redispatched to any other valid +server because of the "redispatch" option. + +This method has an advantage : you never touch the proxy when doing server +maintenance. The people managing the servers can make them disappear smoothly. + + +4.2.1 Variations for operating systems without any firewall software +-------------------------------------------------------------------- + +The downside is that you need a redirection solution on the server just for +the health-checks. If the server OS does not support any firewall software, +this redirection can also be handled by a simple haproxy in tcp mode : + + global + daemon + quiet + pidfile /var/run/haproxy-checks.pid + listen 0.0.0.0:81 + mode tcp + dispatch 127.0.0.1:80 + contimeout 1000 + clitimeout 10000 + srvtimeout 10000 + +To start the web service : + + # /etc/init.d/httpd start + # haproxy -f /etc/haproxy/haproxy-checks.cfg + +To soft-stop the service : + + # kill $( if not closed. For this reason, it's always a good idea to have one local log server at the 'notice' level. Since version 1.1.28 and 1.2.1, if an instance loses all its servers, an -emergency mesasge will be sent in the logs to inform the administator that an +emergency message will be sent in the logs to inform the administator that an immediate action must be taken. +Since version 1.1.30 and 1.2.3, several servers can share the same cookie +value. This is particularly useful in backup mode, to select alternate paths +for a given server for example, to provide soft-stop, or to direct the clients +to a temporary page during an application restart. The principle is that when +a server is dead, the proxy will first look for another server which shares the +same cookie value for every client which presents the cookie. If there is no +standard server for this cookie, it will then look for a backup server which +shares the same name. Please consult the architecture guide for more information. Examples : ---------- @@ -781,6 +804,18 @@ Examples : server web1 192.168.1.1:80 cookie server01 check server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2 +# Load-balancing with 'prefixed cookie' persistence, and soft-stop using an +# alternate port 81 on the server for health-checks. + listen http_proxy 0.0.0.0:80 + mode http + cookie JSESSIONID prefix + balance roundrobin + option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www + server web1-norm 192.168.1.1:80 cookie s1 check port 81 + server web2-norm 192.168.1.2:80 cookie s2 check port 81 + server web1-stop 192.168.1.1:80 cookie s1 check port 80 backup + server web2-stop 192.168.1.2:80 cookie s2 check port 80 backup + # automatic insertion of a cookie in the server's response, and automatic # deletion of the cookie in the client request, while asking upstream caches # not to cache replies. @@ -851,8 +886,10 @@ option : Other features are available. They are transparent mode, event logging and header rewriting/filtering. -4.1) Transparent mode +4.1) Network features --------------------- +4.1.1) Transparent mode +----------------------- In HTTP mode, the 'transparent' keyword allows to intercept sessions which are routed through the system hosting the proxy. This mode was implemented as a replacement for the 'dispatch' mode, since connections without cookie will be @@ -890,6 +927,50 @@ Example : # iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \ -j REDIRECT --to-ports 65000 +4.1.2) Per-server source address binding +---------------------------------------- +As of versions 1.1.30 and 1.2.3, it is possible to specify a particular source +to reach each server. This is useful when reaching backup servers from a +different LAN, or to use an alternate path to reach the same server. It is also +usable to provide source load-balancing for outgoing connections. Obviously, +the same source address is used to send health-checks. + +Example : +--------- + # use a particular source to reach both servers + listen http_proxy 0.0.0.0:65000 + mode http + balance roundrobin + server server01 192.168.1.1:80 source 192.168.2.13 + server server02 192.168.1.2:80 source 192.168.2.13 + +Example : +--------- + # use a particular source to reach each servers + listen http_proxy 0.0.0.0:65000 + mode http + balance roundrobin + server server01 192.168.1.1:80 source 192.168.1.1 + server server02 192.168.2.1:80 source 192.168.2.1 + +Example : +--------- + # provide source load-balancing to reach the same proxy through 2 WAN links + listen http_proxy 0.0.0.0:65000 + mode http + balance roundrobin + server remote-proxy-way1 192.168.1.1:3128 source 192.168.2.1 + server remote-proxy-way2 192.168.1.1:3128 source 192.168.3.1 + +Example : +--------- + # force a TCP connection to bind to a specific port + listen http_proxy 0.0.0.0:2000 + mode tcp + balance roundrobin + server srv1 192.168.1.1:80 source 192.168.2.1:20 + server srv2 192.168.1.2:80 source 192.168.2.1:20 + 4.2) Event logging ------------------ @@ -1370,6 +1451,20 @@ Example : server 192.168.1.1:80 cookie server01 check server 192.168.1.2:80 cookie server02 check +The other solution brought by versions 1.1.30 and 1.2.3 is to reuse a cookie +from the server, and prefix the server's name to it. In this case, don't forget +to force "httpclose" mode so that you can be assured that every subsequent +request will have its cookie fixed. + + listen application 0.0.0.0:80 + mode http + cookie JSESSIONID prefix + balance roundrobin + server 192.168.1.1:80 cookie srv1 check + server 192.168.1.2:80 cookie srv2 check + option httpclose + + 4.5) Protection against information leak from the servers --------------------------------------------------------- In versions 1.1.28/1.2.1, a new option 'checkcache' was created. It carefully diff --git a/doc/haproxy-fr.txt b/doc/haproxy-fr.txt index c5f6eb606..28687bb71 100644 --- a/doc/haproxy-fr.txt +++ b/doc/haproxy-fr.txt @@ -1,9 +1,10 @@ - - H A - P r o x y - --------------- - version 1.2.2 + ------------------- + H A - P r o x y + Manuel de référence + ------------------- + version 1.2.3 willy tarreau - 2004/10/18 + 2005/01/22 ================ | Introduction | @@ -571,6 +572,14 @@ retournera un cookie vide (cookie de suppression) : cookie SERVERID insert +Pour réutiliser un cookie applicatif et lui préfixer l'identifiant du serveur, +puis le supprimer dans les requêtes suivantes, utiliser l'option 'prefix'. Elle +permet d'insérer une instance de haproxy devant une application sans risquer +d'incompatibilités dûes à des clients qui ne supporteraient pas d'apprendre +plus d'un cookie : + + cookie JSESSIONID prefix + Pour insérer un cookie, en s'assurant qu'un cache en amont ne le stockera pas, ajouter le mot clé 'nocache' après 'insert' : @@ -598,6 +607,14 @@ Remarques : cookie de persistence inséré, donc provoquer des changements de serveurs pour des clients partageant le même cache. +- le mode 'prefix' ne nécessite pas d'utiliser 'indirect', 'nocache', ni + 'postonly', car tout comme le mode 'rewrite', il s'appuie sur un cookie + présenté par l'application qui est censée savoir à quel moment il peut + être émis sans risque. Toutefois, comme il nécessite de rectifier le cookie + présenté par le client dans chaque requête ultérieure, il est indispensable + de s'assurer que le client et le serveur communiqueront sans "keep-alive + HTTP". Dans le doute, il est recommandé d'utiliser l'option "httpclose". + - lorsque l'application est bien connue, et que les parties nécessitant de la persistence sont systématiquement accédées par un formulaire en mode POST, il est plus efficace encore de combiner le mot clé "postonly" avec "insert" @@ -766,6 +783,17 @@ Depuis la version 1.1.18 (et 1.2.1), un message d'urgence est envoy logs en niveau 'emerg' si tous les serveurs d'une même instance sont tombés, afin de notifier l'administrateur qu'il faut prendre une action immédiate. +Depuis les versions 1.1.30 et 1.2.3, plusieurs serveurs peuvent partager la +même valeur de cookie. C'est particulièrement utile en mode backup, pour +sélectionner des chemins alternatifs pour un serveur donné, pour mettre en +oeuvre l'arrêt en douceur d'un serveur, ou pour diriger les clients +temporairement vers une page d'erreur en attendant le redémarrage d'une +application. Le principe est que lorsqu'un serveur est détecté comme inopérant, +le proxy cherchera le prochain serveur possédant la même valeur de cookie pour +chaque client qui le demandera. S'il ne trouve pas de serveur normal, alors il +le cherchera parmi les serveurs de backup. Consulter le guide d'architecture +pour plus d'informations. + Exemples : ---------- # conf du paragraphe 3) avec surveillance TCP @@ -803,6 +831,18 @@ Exemples : server web1 192.168.1.1:80 cookie server01 check server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2 +# répartition avec persistence basée sur le préfixe de cookie, et arrêt en +# douceur utilisant un second port (81) juste pour les health-checks. + listen http_proxy 0.0.0.0:80 + mode http + cookie JSESSIONID prefix + balance roundrobin + option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www + server web1-norm 192.168.1.1:80 cookie s1 check port 81 + server web2-norm 192.168.1.2:80 cookie s2 check port 81 + server web1-stop 192.168.1.1:80 cookie s1 check port 80 backup + server web2-stop 192.168.1.2:80 cookie s2 check port 80 backup + # Insertion automatique de cookie dans la réponse du serveur, et suppression # automatique dans la requête, tout en indiquant aux caches de ne pas garder # ce cookie. @@ -874,7 +914,9 @@ D'autres fonctionnalit principalement du mode transparent, de la journalisation des connexions, et de la réécriture des entêtes. -4.1) Fonctionnement en mode transparent +4.1) Fonctionnalités réseau +--------------------------- +4.1.1) Fonctionnement en mode transparent --------------------------------------- En mode HTTP, le mot clé 'transparent' permet d'intercepter des sessions routées à travers la machine hébergeant le proxy. Dans ce mode, on ne précise pas @@ -911,6 +953,53 @@ Exemple : -j REDIRECT --to-ports 65000 +4.1.2) Choix d'une adresse source par serveur +--------------------------------------------------- +Avec les versions 1.1.30 et 1.2.3, il devient possible de spécifier une adresse +IP source pour joindre chaque serveur. C'est utile pour joindre des serveurs de +backup à partir d'un LAN différent, ou pour utiliser des chemins alternatifs +pour joindre le même serveur. C'est également utilisable pour faciliter une +répartition de charge selon l'adresse IP source pour des connexions sortantes. +Bien entendu, la même adresse est utilisée pour les health-checks. + +Exemple : +--------- + # utiliser une adresse particulière pour joindre les 2 serveur + listen http_proxy 0.0.0.0:65000 + mode http + balance roundrobin + server server01 192.168.1.1:80 source 192.168.2.13 + server server02 192.168.1.2:80 source 192.168.2.13 + +Exemple : +--------- + # utiliser une adresse particulière pour joindre chaque serveur + listen http_proxy 0.0.0.0:65000 + mode http + balance roundrobin + server server01 192.168.1.1:80 source 192.168.1.1 + server server02 192.168.2.1:80 source 192.168.2.1 + +Exemple : +--------- + # faire une répartition d'adresse sources pour joindre le même proxy à + # travers deux liens WAN + listen http_proxy 0.0.0.0:65000 + mode http + balance roundrobin + server remote-proxy-way1 192.168.1.1:3128 source 192.168.2.1 + server remote-proxy-way2 192.168.1.1:3128 source 192.168.3.1 + +Exemple : +--------- + # forcer une connexion TCP à s'attacher à un port particulier + listen http_proxy 0.0.0.0:2000 + mode tcp + balance roundrobin + server srv1 192.168.1.1:80 source 192.168.2.1:20 + server srv2 192.168.1.2:80 source 192.168.2.1:20 + + 4.2) Journalisation des connexions ---------------------------------- 4.2.1) Niveaux de log @@ -1411,6 +1500,21 @@ Exemple : server 192.168.1.1:80 cookie server01 check server 192.168.1.2:80 cookie server02 check +L'autre solution apportée par les versions 1.1.30 et 1.2.3 est de réutiliser un +cookie en provenance du serveur et de lui préfixer l'identifiant du serveur. +Dans ce cas, ne pas oublier de forcer le mode "httpclose" pour empêcher le +client et le serveur de travailler en mode "keep-alive" afin que le proxy +puisse corriger le nom du cookie dans toutes les futures requêtes. + + listen application 0.0.0.0:80 + mode http + cookie JSESSIONID prefix + balance roundrobin + server 192.168.1.1:80 cookie srv1 check + server 192.168.1.2:80 cookie srv2 check + option httpclose + + 4.5) Protection contre les fuites d'informations du serveur ----------------------------------------------------------- Dans les versions 1.1.28 et 1.2.1, une nouvelle option 'checkcache' a été créée. diff --git a/haproxy.c b/haproxy.c index 426786e33..b6682b43b 100644 --- a/haproxy.c +++ b/haproxy.c @@ -1,6 +1,6 @@ /* * HA-Proxy : High Availability-enabled HTTP/TCP proxy - * 2000-2004 - Willy Tarreau - willy AT meta-x DOT org. + * 2000-2005 - Willy Tarreau - willy AT meta-x DOT org. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -57,8 +57,8 @@ #include #endif -#define HAPROXY_VERSION "1.2.2" -#define HAPROXY_DATE "2004/10/18" +#define HAPROXY_VERSION "1.2.3" +#define HAPROXY_DATE "2005/01/22" /* this is for libc5 for example */ #ifndef TCP_NODELAY @@ -73,10 +73,24 @@ #define SHUT_WR 1 #endif -#define BUFSIZE 8192 +/* + * BUFSIZE defines the size of a read and write buffer. It is the maximum + * amount of bytes which can be stored by the proxy for each session. However, + * when reading HTTP headers, the proxy needs some spare space to add or rewrite + * headers if needed. The size of this spare is defined with MAXREWRITE. So it + * is not possible to process headers longer than BUFSIZE-MAXREWRITE bytes. By + * default, BUFSIZE=16384 bytes and MAXREWRITE=BUFSIZE/2, so the maximum length + * of headers accepted is 8192 bytes, which is in line with Apache's limits. + */ +#ifndef BUFSIZE +#define BUFSIZE 16384 +#endif // reserved buffer space for header rewriting -#define MAXREWRITE 4096 +#ifndef MAXREWRITE +#define MAXREWRITE (BUFSIZE / 2) +#endif + #define REQURI_LEN 1024 #define CAPTURE_LEN 64 @@ -89,9 +103,13 @@ // max # of matches per regexp #define MAX_MATCH 10 -/* FIXME: serverid_len and cookiename_len are no longer checked in configuration file */ -#define COOKIENAME_LEN 16 -#define SERVERID_LEN 16 +// cookie delimitor in "prefix" mode. This character is inserted between the +// persistence cookie and the original value. The '~' is allowed by RFC2965, +// and should not be too common in server names. +#ifndef COOKIE_DELIM +#define COOKIE_DELIM '~' +#endif + #define CONN_RETRIES 3 #define CHK_CONNTIME 2000 @@ -128,6 +146,9 @@ /* if a < min, then bound to . The macro returns the new */ #define LBOUND(a, min) ({ typeof(a) b = (min); if ((a) < b) (a) = b; (a); }) +/* returns 1 only if only zero or one bit is set in X, which means that X is a + * power of 2, and 0 otherwise */ +#define POWEROF2(x) (((x) & ((x)-1)) == 0) /* * copies at most chars from to . Last char is always * set to 0, unless is 0. The number of chars copied is returned @@ -241,25 +262,26 @@ int strlcpy2(char *dst, const char *src, int size) { #define PR_MODE_HEALTH 2 /* bits for proxy->options */ -#define PR_O_REDISP 1 /* allow reconnection to dispatch in case of errors */ -#define PR_O_TRANSP 2 /* transparent mode : use original DEST as dispatch */ -#define PR_O_COOK_RW 4 /* rewrite all direct cookies with the right serverid */ -#define PR_O_COOK_IND 8 /* keep only indirect cookies */ -#define PR_O_COOK_INS 16 /* insert cookies when not accessing a server directly */ -#define PR_O_COOK_ANY (PR_O_COOK_RW | PR_O_COOK_IND | PR_O_COOK_INS) -#define PR_O_BALANCE_RR 32 /* balance in round-robin mode */ +#define PR_O_REDISP 0x00000001 /* allow reconnection to dispatch in case of errors */ +#define PR_O_TRANSP 0x00000002 /* transparent mode : use original DEST as dispatch */ +#define PR_O_COOK_RW 0x00000004 /* rewrite all direct cookies with the right serverid */ +#define PR_O_COOK_IND 0x00000008 /* keep only indirect cookies */ +#define PR_O_COOK_INS 0x00000010 /* insert cookies when not accessing a server directly */ +#define PR_O_COOK_PFX 0x00000020 /* rewrite all cookies by prefixing the right serverid */ +#define PR_O_COOK_ANY (PR_O_COOK_RW | PR_O_COOK_IND | PR_O_COOK_INS | PR_O_COOK_PFX) +#define PR_O_BALANCE_RR 0x00000040 /* balance in round-robin mode */ #define PR_O_BALANCE (PR_O_BALANCE_RR) -#define PR_O_KEEPALIVE 64 /* follow keep-alive sessions */ -#define PR_O_FWDFOR 128 /* insert x-forwarded-for with client address */ -#define PR_O_BIND_SRC 256 /* bind to a specific source address when connect()ing */ -#define PR_O_NULLNOLOG 512 /* a connect without request will not be logged */ -#define PR_O_COOK_NOC 1024 /* add a 'Cache-control' header with the cookie */ -#define PR_O_COOK_POST 2048 /* don't insert cookies for requests other than a POST */ -#define PR_O_HTTP_CHK 4096 /* use HTTP 'OPTIONS' method to check server health */ -#define PR_O_PERSIST 8192 /* server persistence stays effective even when server is down */ -#define PR_O_LOGASAP 16384 /* log as soon as possible, without waiting for the session to complete */ -#define PR_O_HTTP_CLOSE 32768 /* force 'connection: close' in both directions */ -#define PR_O_CHK_CACHE 65536 /* require examination of cacheability of the 'set-cookie' field */ +#define PR_O_KEEPALIVE 0x00000080 /* follow keep-alive sessions */ +#define PR_O_FWDFOR 0x00000100 /* insert x-forwarded-for with client address */ +#define PR_O_BIND_SRC 0x00000200 /* bind to a specific source address when connect()ing */ +#define PR_O_NULLNOLOG 0x00000400 /* a connect without request will not be logged */ +#define PR_O_COOK_NOC 0x00000800 /* add a 'Cache-control' header with the cookie */ +#define PR_O_COOK_POST 0x00001000 /* don't insert cookies for requests other than a POST */ +#define PR_O_HTTP_CHK 0x00002000 /* use HTTP 'OPTIONS' method to check server health */ +#define PR_O_PERSIST 0x00004000 /* server persistence stays effective even when server is down */ +#define PR_O_LOGASAP 0x00008000 /* log as soon as possible, without waiting for the session to complete */ +#define PR_O_HTTP_CLOSE 0x00010000 /* force 'connection: close' in both directions */ +#define PR_O_CHK_CACHE 0x00020000 /* require examination of cacheability of the 'set-cookie' field */ /* various session flags */ #define SN_DIRECT 0x00000001 /* connection made on the server matching the client cookie */ @@ -339,6 +361,7 @@ int strlcpy2(char *dst, const char *src, int size) { #define SRV_RUNNING 1 /* the server is UP */ #define SRV_BACKUP 2 /* this server is a backup server */ #define SRV_MAPPORTS 4 /* this server uses mapped ports */ +#define SRV_BIND_SRC 8 /* this server uses a specific source address */ /* what to do when a header matches a regex */ #define ACT_ALLOW 0 /* allow the request */ @@ -403,6 +426,7 @@ struct server { char *cookie; /* the id set in the cookie */ char *id; /* just for identification */ struct sockaddr_in addr; /* the address to connect to */ + struct sockaddr_in source_addr; /* the address to which we want to bind for connect() */ short check_port; /* the port to use for the health checks */ int health; /* 0->rise-1 = bad; rise->rise+fall-1 = good */ int rise, fall; /* time in iterations */ @@ -727,7 +751,7 @@ int process_session(struct task *t); void display_version() { printf("HA-Proxy version " HAPROXY_VERSION " " HAPROXY_DATE"\n"); - printf("Copyright 2000-2004 Willy Tarreau \n\n"); + printf("Copyright 2000-2005 Willy Tarreau \n\n"); } /* @@ -1645,12 +1669,26 @@ int connect_server(struct session *s) { return -1; } - /* allow specific binding */ - if (s->proxy->options & PR_O_BIND_SRC && - bind(fd, (struct sockaddr *)&s->proxy->source_addr, sizeof(s->proxy->source_addr)) == -1) { - Alert("Cannot bind to source address before connect() for proxy %s. Aborting.\n", s->proxy->id); - close(fd); - return -1; + /* allow specific binding : + * - server-specific at first + * - proxy-specific next + */ + if (s->srv != NULL && s->srv->state & SRV_BIND_SRC) { + setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &one, sizeof(one)); + if (bind(fd, (struct sockaddr *)&s->srv->source_addr, sizeof(s->srv->source_addr)) == -1) { + Alert("Cannot bind to source address before connect() for server %s/%s. Aborting.\n", + s->proxy->id, s->srv->id); + close(fd); + return -1; + } + } + else if (s->proxy->options & PR_O_BIND_SRC) { + setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &one, sizeof(one)); + if (bind(fd, (struct sockaddr *)&s->proxy->source_addr, sizeof(s->proxy->source_addr)) == -1) { + Alert("Cannot bind to source address before connect() for proxy %s. Aborting.\n", s->proxy->id); + close(fd); + return -1; + } } if ((connect(fd, (struct sockaddr *)&s->srv_addr, sizeof(s->srv_addr)) == -1) && (errno != EINPROGRESS)) { @@ -2938,7 +2976,16 @@ int process_cli(struct session *t) { /* here, we have the cookie name between p1 and p2, * and its value between p3 and p4. - * we can process it. + * we can process it : + * + * Cookie: NAME=VALUE; + * | || || | + * | || || +--> p4 + * | || |+-------> p3 + * | || +--------> p2 + * | |+------------> p1 + * | +-------------> colon + * +--------------------> req->h */ if (*p1 == '$') { @@ -2966,31 +3013,75 @@ int process_cli(struct session *t) { (memcmp(p1, t->proxy->cookie_name, p2 - p1) == 0)) { /* Cool... it's the right one */ struct server *srv = t->proxy->srv; + char *delim; - while (srv && - ((srv->cklen != p4 - p3) || memcmp(p3, srv->cookie, p4 - p3))) { + /* if we're in cookie prefix mode, we'll search the delimitor so that we + * have the server ID betweek p3 and delim, and the original cookie between + * delim+1 and p4. Otherwise, delim==p4 : + * + * Cookie: NAME=SRV~VALUE; + * | || || | | + * | || || | +--> p4 + * | || || +--------> delim + * | || |+-----------> p3 + * | || +------------> p2 + * | |+----------------> p1 + * | +-----------------> colon + * +------------------------> req->h + */ + + if (t->proxy->options & PR_O_COOK_PFX) { + for (delim = p3; delim < p4; delim++) + if (*delim == COOKIE_DELIM) + break; + } + else + delim = p4; + + + /* Here, we'll look for the first running server which supports the cookie. + * This allows to share a same cookie between several servers, for example + * to dedicate backup servers to specific servers only. + */ + while (srv) { + if ((srv->cklen == delim - p3) && !memcmp(p3, srv->cookie, delim - p3)) { + if (srv->state & SRV_RUNNING || t->proxy->options & PR_O_PERSIST) { + /* we found the server and it's usable */ + t->flags &= ~SN_CK_MASK; + t->flags |= SN_CK_VALID | SN_DIRECT; + t->srv = srv; + break; + } + else { + /* we found a server, but it's down */ + t->flags &= ~SN_CK_MASK; + t->flags |= SN_CK_DOWN; + } + } srv = srv->next; } - if (!srv) { + if (!srv && !(t->flags & SN_CK_DOWN)) { + /* no server matched this cookie */ t->flags &= ~SN_CK_MASK; t->flags |= SN_CK_INVALID; } - else if (srv->state & SRV_RUNNING || t->proxy->options & PR_O_PERSIST) { - /* we found the server and it's usable */ - t->flags &= ~SN_CK_MASK; - t->flags |= SN_CK_VALID | SN_DIRECT; - t->srv = srv; - } - else { - t->flags &= ~SN_CK_MASK; - t->flags |= SN_CK_DOWN; - } - /* if this cookie was set in insert+indirect mode, then it's better that the - * server never sees it. + /* depending on the cookie mode, we may have to either : + * - delete the complete cookie if we're in insert+indirect mode, so that + * the server never sees it ; + * - remove the server id from the cookie value, and tag the cookie as an + * application cookie so that it does not get accidentely removed later, + * if we're in cookie prefix mode */ - if (del_cookie == NULL && + if ((t->proxy->options & PR_O_COOK_PFX) && (delim != p4)) { + buffer_replace2(req, p3, delim + 1, NULL, 0); + p4 -= (delim + 1 - p3); + ptr -= (delim + 1 - p3); + del_cookie = del_colon = NULL; + app_cookies++; /* protect the header from deletion */ + } + else if (del_cookie == NULL && (t->proxy->options & (PR_O_COOK_INS | PR_O_COOK_IND)) == (PR_O_COOK_INS | PR_O_COOK_IND)) { del_cookie = p1; del_colon = colon; @@ -3814,6 +3905,14 @@ int process_srv(struct session *t) { buffer_replace2(rep, p3, p4, t->srv->cookie, t->srv->cklen); t->flags |= SN_SCK_INSERTED | SN_SCK_DELETED; } + else if ((t->srv) && (t->proxy->options & PR_O_COOK_PFX)) { + /* insert the cookie name associated with this server + * before existing cookie, and insert a delimitor between them.. + */ + buffer_replace2(rep, p3, p3, t->srv->cookie, t->srv->cklen + 1); + p3[t->srv->cklen] = COOKIE_DELIM; + t->flags |= SN_SCK_INSERTED | SN_SCK_DELETED; + } break; } else { @@ -4252,32 +4351,48 @@ int process_chk(struct task *t) { sa = s->addr; sa.sin_port = htons(s->check_port); - /* allow specific binding */ - if (s->proxy->options & PR_O_BIND_SRC && - bind(fd, (struct sockaddr *)&s->proxy->source_addr, sizeof(s->proxy->source_addr)) == -1) { - Alert("Cannot bind to source address before connect() for proxy %s. Aborting.\n", s->proxy->id); - close(fd); - s->result = -1; + /* allow specific binding : + * - server-specific at first + * - proxy-specific next + */ + if (s->state & SRV_BIND_SRC) { + setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &one, sizeof(one)); + if (bind(fd, (struct sockaddr *)&s->source_addr, sizeof(s->source_addr)) == -1) { + Alert("Cannot bind to source address before connect() for server %s/%s. Aborting.\n", + s->proxy->id, s->id); + s->result = -1; + } } - else if ((connect(fd, (struct sockaddr *)&sa, sizeof(sa)) != -1) || (errno == EINPROGRESS)) { - /* OK, connection in progress or established */ - - //fprintf(stderr, "process_chk: 4\n"); - - s->curfd = fd; /* that's how we know a test is in progress ;-) */ - fdtab[fd].owner = t; - fdtab[fd].read = &event_srv_chk_r; - fdtab[fd].write = &event_srv_chk_w; - fdtab[fd].state = FD_STCONN; /* connection in progress */ - FD_SET(fd, StaticWriteEvent); /* for connect status */ - fd_insert(fd); - /* FIXME: we allow up to for a connection to establish, but we should use another parameter */ - tv_delayfrom(&t->expire, &now, s->inter); - task_queue(t); /* restore t to its place in the task list */ - return tv_remain(&now, &t->expire); + else if (s->proxy->options & PR_O_BIND_SRC) { + setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &one, sizeof(one)); + if (bind(fd, (struct sockaddr *)&s->proxy->source_addr, sizeof(s->proxy->source_addr)) == -1) { + Alert("Cannot bind to source address before connect() for proxy %s. Aborting.\n", + s->proxy->id); + s->result = -1; + } } - else if (errno != EALREADY && errno != EISCONN && errno != EAGAIN) { - s->result = -1; /* a real error */ + + if (!s->result) { + if ((connect(fd, (struct sockaddr *)&sa, sizeof(sa)) != -1) || (errno == EINPROGRESS)) { + /* OK, connection in progress or established */ + + //fprintf(stderr, "process_chk: 4\n"); + + s->curfd = fd; /* that's how we know a test is in progress ;-) */ + fdtab[fd].owner = t; + fdtab[fd].read = &event_srv_chk_r; + fdtab[fd].write = &event_srv_chk_w; + fdtab[fd].state = FD_STCONN; /* connection in progress */ + FD_SET(fd, StaticWriteEvent); /* for connect status */ + fd_insert(fd); + /* FIXME: we allow up to for a connection to establish, but we should use another parameter */ + tv_delayfrom(&t->expire, &now, s->inter); + task_queue(t); /* restore t to its place in the task list */ + return tv_remain(&now, &t->expire); + } + else if (errno != EALREADY && errno != EISCONN && errno != EAGAIN) { + s->result = -1; /* a real error */ + } } } //fprintf(stderr, "process_chk: 5\n"); @@ -5059,15 +5174,24 @@ int cfg_parse_listen(char *file, int linenum, char **args) { else if (!strcmp(args[cur_arg], "postonly")) { curproxy->options |= PR_O_COOK_POST; } + else if (!strcmp(args[cur_arg], "prefix")) { + curproxy->options |= PR_O_COOK_PFX; + } else { - Alert("parsing [%s:%d] : '%s' supports 'rewrite', 'insert', 'indirect', 'nocache' and 'postonly' options.\n", + Alert("parsing [%s:%d] : '%s' supports 'rewrite', 'insert', 'prefix', 'indirect', 'nocache' and 'postonly' options.\n", file, linenum, args[0]); return -1; } cur_arg++; } - if ((curproxy->options & (PR_O_COOK_RW|PR_O_COOK_IND)) == (PR_O_COOK_RW|PR_O_COOK_IND)) { - Alert("parsing [%s:%d] : cookie 'rewrite' and 'indirect' mode are incompatible.\n", + if (!POWEROF2(curproxy->options & (PR_O_COOK_RW|PR_O_COOK_IND))) { + Alert("parsing [%s:%d] : cookie 'rewrite' and 'indirect' modes are incompatible.\n", + file, linenum); + return -1; + } + + if (!POWEROF2(curproxy->options & (PR_O_COOK_RW|PR_O_COOK_INS|PR_O_COOK_PFX))) { + Alert("parsing [%s:%d] : cookie 'rewrite', 'insert' and 'prefix' modes are incompatible.\n", file, linenum); return -1; } @@ -5340,8 +5464,14 @@ int cfg_parse_listen(char *file, int linenum, char **args) { Alert("parsing [%s:%d] : out of memory.\n", file, linenum); return -1; } - newsrv->next = curproxy->srv; - curproxy->srv = newsrv; + + if (curproxy->srv == NULL) + curproxy->srv = newsrv; + else + curproxy->cursrv->next = newsrv; + curproxy->cursrv = newsrv; + + newsrv->next = NULL; newsrv->proxy = curproxy; do_check = 0; @@ -5408,8 +5538,18 @@ int cfg_parse_listen(char *file, int linenum, char **args) { do_check = 1; cur_arg += 1; } + else if (!strcmp(args[cur_arg], "source")) { /* address to which we bind when connecting */ + if (!*args[cur_arg + 1]) { + Alert("parsing [%s:%d] : '%s' expects [:] as argument.\n", + file, linenum, "source"); + return -1; + } + newsrv->state |= SRV_BIND_SRC; + newsrv->source_addr = *str2sa(args[cur_arg + 1]); + cur_arg += 2; + } else { - Alert("parsing [%s:%d] : server %s only supports options 'backup', 'cookie', 'check', 'inter', 'rise' and 'fall'.\n", + Alert("parsing [%s:%d] : server %s only supports options 'backup', 'cookie', 'check', 'inter', 'rise', 'fall', 'port' and 'source'.\n", file, linenum, newsrv->id); return -1; } @@ -6090,6 +6230,7 @@ int readcfgfile(char *file) { } while (curproxy != NULL) { + curproxy->cursrv = NULL; if (curproxy->state == PR_STDISABLED) { curproxy = curproxy->next; continue;