Re: [PATCH] include configuration directive for haproxy 1.5-dev3
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. And, please, post your patches inline, they are easier to review :) @@ -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? @@ -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. Thanks a lot! -- L. Alberto Giménez
[RFC] Thinking about RDP-cookie
Hi list, At my company we are using HAProxy as our main load balancer, and we have situations where we would like to have TCP load balancing plus some sort of stickyness (for example, to use SSL-enabled web servers that need session persistence). The immediate answer would be source IP has, but that would... well... somehow imbalance backend load. I have tried to google if it has been already discussed in the list, but found nothing, but I find weird that such a topic had not raised in the past. The RDP-cookie feature got me thinking if that wouldn't be valid as a new balance algorithm (TCP roundrobin upon the first TCP session and some kind of stickyness for further connections), as it results effectively as a balancing method for TCP with backend session support. I'm thinking about something like having a connection table where each new connection gets inserted upon first session, and somehow assigned an internal persistent association with a roundrobin-elected backend. Upon further connections, the proxy would recognize that there was a session in the past and that it would reuse the same backend. This way we would have the load more balanced (roundrobin) and TCP-level stickyness. That would be good for balancing PHP applications that store sessions in local files (as it's the vast majority of that kind of applications). I'm not familiar with HAProxy code (yet), and I don't know what would represent implementing it (I'm willing to if Willy and the HAProxy community welcome the feature), or if it's a good idea in the first place (after all, RDP-cookie does exactly that, so it seems that it's useful...), but I think that that new algorithm would be a cleaner implementation for the RDP-cookie behaviour. What do you think? Regards, L. Alberto Giménez
Re: [RFC] Thinking about RDP-cookie
On 15/12/2010 15:57, Malcolm Turnbull wrote: On 15 December 2010 14:33, L. Alberto Giménez agimenez-hapr...@sysvalve.homelinux.net wrote: RDP and HTTP have cookies in the application protocol, therefore you can insert or modify a marker/cookie to keep track... How would you insert the marker in standard TCP traffic? The only method I'm aware of is source IP for TCP persistence. Sorry if I didn't explain clearly, but the very-high-level-algorithm would be: -8-- empty tcp-persistence hash table (at initialization time) accept a connection if (remote IP has persistence entry in the has table) get persistent backend (already assigned) else choose a new backend via roundrobin (care about load?) Register IP - backend as a persistent connection end if redirect connection to the chosen backend -8-- Everything would be done at tcp/ip level, so no application knowledge would be needed. I hope that things are clearer now :) Regards, L. Alberto Giménez
Re: [RFC] Thinking about RDP-cookie
On Wed, Dec 15, 2010 at 05:40:24PM +0100, Hervé COMMOWICK wrote: If i understood carefully, this is what stick-table are able to handle : balance roundrobin stick-table type ip size 200k expire 30m stick on src Sure, that's what I was talking about :) I'm a little bit outdated regarding newer features of HAProxy! Thanks, -- L. Alberto Giménez JabberID agime...@jabber.sysvalve.es GnuPG key ID 0x3BAABDE1
Re: HAproxy tproxy problem when try to make transparent proxy
On 03/20/2010 08:27 PM, Daniele Genetti wrote: So, there is something that don't permit to communicate in transparent mode.. Where is the barrier? mmm.. Hi, Sorry for insist on that, but are you *completely* sure that your routing is properly set up so transparent mode can work? This kind of errors are almost always related to routing issues. Please check that: * You have the tproxy enabled in your kernel * You have haproxy compiled with tproxy support Your backend servers *can't* see the clients directly (i.e., they have the haproxy box as default gateway and *no other* gateways). The same for the clients (not mandatory, but if they can see the servers, it may cause trouble). Best regards, L. Alberto Giménez
Re: Transparent proxy
Carlo Granisso wrote: Hello everybody, I have a problem with haproxy (1.3.17) and kernel 2.6.29 I have successfully recompiled my kernel with TPROXY modules and installed haproxy (compiled from source with tproxy option enabled) and installed iptables 1.4.3 (that have tproxy patch). Now I can't use transparent proxy function: if I leave in haproxy.cfg this line source 0.0.0.0 usesrc clientip haproxy say 503 - Service unavailable. If I comment out the line, everything work fine (without transparent proxy). My situation: haproxy with two ethernet device: first one for public IP, sceond one for private IP (192.168.XX.XX) two web server with one ethernet for each one connected to my private network. Have you got ideas or you can provide me examples Hi, I've just set up a transparent proxy with kernel 2.6.28 (the first one with official tproxy support) and haproxy 1.3.15 (the version Debian comes with, but rebuilding the package with the tproxy linux option enabled). Just make sure your backends route their outgoing traffic through the load balancer, since the response packets with the fake address MUST be seen by the load blancer box to undo the transparent-proxy magic. Regards, L. Alberto Giménez
