Re: [PATCH] MEDIUM: stats: Add `show events` command.
On Mon, Apr 2, 2012 at 11:21 PM, Willy Tarreau wrote: > Hi Aman, > > On Mon, Apr 02, 2012 at 03:34:08PM -0700, Aman Gupta wrote: >> > OK just to be sure, you should *really* make your changes on 1.5-dev, not >> > 1.4. 1.4 is in deep maintenance mode and I don't intend to merge such >> > changes there, as every time I did I caused some regressions. >> >> I'm in process of porting my patch to 1.5. I don't particularly want >> to run 1.5 in production though, and it occurs to me that my patch is >> quite involved for what I'm trying to accomplish. >> >> My goal is essentially to have the remote ip of the upstream client >> available to my application (sitting behind haproxy). For http >> backends, I can use forwardfor and it works great. However, this >> specific service is raw tcp. I know I can use tproxy, but would prefer >> to avoid upgrading my kernel and setting up additional iptables rules. >> >> The idea with this patch was that the application could connect to >> haproxy to get events and use that data to figure out the upstream >> client's ip. This adds a lot of complexity though, so I'm trying to >> come up with alternatives. The only other obvious solution is to have >> haproxy prepend something to the tcp stream. In my case this will work >> fine, since I can modify my application to extract this from the >> stream before consuming the client data. > > This is the principle of the PROXY protocol. The "send-proxy" server option > was added to 1.5-dev, but it's not in 1.4 though I have the patch to make > this possible. It requires very minor changes to the application and I know > that some people running FTP servers and SSL servers have modified them to > parse this line. The protocol was also already adopted by Stud and Stunnel. > > The protocol is described here : > > http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt > > Please let me know whether you're interested, then I'll check where I left > the patch :-) This is exactly what I am looking for. I am very much interested in a 1.4 backport, and happy to help with the porting and testing process. Aman > > Willy >
Re: [PATCH] MEDIUM: stats: Add `show events` command.
Hi Aman, On Mon, Apr 02, 2012 at 03:34:08PM -0700, Aman Gupta wrote: > > OK just to be sure, you should *really* make your changes on 1.5-dev, not > > 1.4. 1.4 is in deep maintenance mode and I don't intend to merge such > > changes there, as every time I did I caused some regressions. > > I'm in process of porting my patch to 1.5. I don't particularly want > to run 1.5 in production though, and it occurs to me that my patch is > quite involved for what I'm trying to accomplish. > > My goal is essentially to have the remote ip of the upstream client > available to my application (sitting behind haproxy). For http > backends, I can use forwardfor and it works great. However, this > specific service is raw tcp. I know I can use tproxy, but would prefer > to avoid upgrading my kernel and setting up additional iptables rules. > > The idea with this patch was that the application could connect to > haproxy to get events and use that data to figure out the upstream > client's ip. This adds a lot of complexity though, so I'm trying to > come up with alternatives. The only other obvious solution is to have > haproxy prepend something to the tcp stream. In my case this will work > fine, since I can modify my application to extract this from the > stream before consuming the client data. This is the principle of the PROXY protocol. The "send-proxy" server option was added to 1.5-dev, but it's not in 1.4 though I have the patch to make this possible. It requires very minor changes to the application and I know that some people running FTP servers and SSL servers have modified them to parse this line. The protocol was also already adopted by Stud and Stunnel. The protocol is described here : http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt Please let me know whether you're interested, then I'll check where I left the patch :-) Willy
Re: balance uri archaic options
Hi, May I ask you why you want absolutely not hash this part? I clearly don't understand, and I don't see any disadvantage of hashing a full URI. Maybe passing the argument you want to hash in the query string, then use the balance param algorithm may help. cheers On Mon, Apr 2, 2012 at 8:28 PM, Sameh Ghane wrote: > Le (On) Mon, Apr 02, 2012 at 06:32:31PM +0100, Jonathan Matthews ecrivit > (wrote): >> On 2 April 2012 17:25, Sameh Ghane wrote: >> > >> > Is there anything I missed ? Like setting a specific request header which >> > would >> > be the result of a regexp on the URI, and balancing on that header ? >> >> I don't understand what you've written. Could you say it again, but >> differently? >> Some examples would probably help too. > > Sorry for this. > > Imagine I see requests for /x/yy.z and I would like to balance > according to the URI, though I don't want the "y" part to be fed to the > hash > function. As far as I understand, it cannot be done with 'balance uri'. > > That's why I would like to know if it can be circumvented through something > like: > > backend be > .. > reqadd balhdr:\ xxx > balance hdr(balhdr) > .. > > > Cheers, > > -- > Sameh Ghane >
[PATCH 4/4] MAJOR: Add `debug sess` command to unix socket stats interface
---
doc/configuration.txt| 22
include/proto/dumpstats.h|5 +
include/types/stream_interface.h |5 +
src/dumpstats.c | 242 +-
src/session.c|9 ++
5 files changed, 280 insertions(+), 3 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 2ede208..5b1ca85 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -10031,6 +10031,28 @@ shutdown sessions /
maintenance mode, for instance. Such terminated sessions are reported with a
'K' flag in the logs.
+debug sess [proxy:[:]]
+
+ Dump a stream of events about sessions as they are added and removed.
+ The possible event formats are "Forward" and "Close":
+
+"F - | - \n"
+"C \n"
+
+ Streaming will continue until a new command is received or the
+ connection is closed. If or is specified, limit to
+ events concerning only the proxy and server specified.
+
+ This command is restricted and can only be issued on sockets configured
+ for levels "operator" or "admin".
+
+ Example:
+>>> $ echo "set timeout cli 3600; debug sess" | socat stdio,ignoreeof
/tmp/sock1
+F 1 127.0.0.1:50869 - 127.0.0.1:9418 | 127.0.0.1:50870 - 127.0.0.1:6000
+C 1
+F 2 127.0.0.1:50874 - 127.0.0.1:9418 | 127.0.0.1:50875 - 127.0.0.1:6000
+C 2
+
/*
* Local variables:
* fill-column: 79
diff --git a/include/proto/dumpstats.h b/include/proto/dumpstats.h
index eb44a36..d328881 100644
--- a/include/proto/dumpstats.h
+++ b/include/proto/dumpstats.h
@@ -55,6 +55,8 @@
#define STAT_CLI_O_TAB 8 /* dump tables */
#define STAT_CLI_O_CLR 9 /* clear tables */
+#define STAT_CLI_EVENTS 8 /* event stream */
+
/* status codes (strictly 4 chars) used in the URL to display a message */
#define STAT_STATUS_UNKN "UNKN"/* an unknown error occured, shouldn't
happen */
#define STAT_STATUS_DONE "DONE"/* the action is successful */
@@ -63,8 +65,11 @@
#define STAT_STATUS_DENY "DENY"/* action denied */
extern struct si_applet http_stats_applet;
+extern int stats_event_enabled;
void stats_io_handler(struct stream_interface *si);
+void stats_event_new_session(struct session *s);
+void stats_event_end_session(struct session *s);
#endif /* _PROTO_DUMPSTATS_H */
diff --git a/include/types/stream_interface.h b/include/types/stream_interface.h
index 16af806..d730559 100644
--- a/include/types/stream_interface.h
+++ b/include/types/stream_interface.h
@@ -169,6 +169,11 @@ struct stream_interface {
int bol;/* pointer to beginning
of current line */
} errors;
struct {
+ struct list list; /* list of stats
streams in the STAT_CLI_EVENTS state */
+ struct proxy *px; /* if not NULL, only
send events associated with this proxy */
+ struct server *srv; /* if not NULL, only
send events associated with this server */
+ } events;
+ struct {
void *target; /* table we want to
dump, or NULL for all */
struct proxy *proxy;/* table being
currently dumped (first if NULL) */
struct stksess *entry; /* last entry we were
trying to dump (or first if NULL) */
diff --git a/src/dumpstats.c b/src/dumpstats.c
index 74ad966..b3f4423 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -86,6 +86,7 @@ static const char stats_sock_usage_msg[] =
" disable: put a server or frontend in maintenance mode\n"
" enable : re-enable a server or frontend which is in
maintenance mode\n"
" shutdown : kill a session or a frontend (eg:to release
listening ports)\n"
+ " debug sess : stream events about proxied sessions\n"
"";
static const char stats_permission_denied_msg[] =
@@ -114,6 +115,77 @@ enum {
STAT_PX_ST_FIN,
};
+/* Keep track of sessions that want streaming events (STAT_CLI_EVENT).
+ */
+int stats_event_enabled = 0;
+static struct list stats_event_listeners =
LIST_HEAD_INIT(stats_event_listeners);
+
+/* Add a session to the list of event listeners.
+ */
+static inline void stats_event_listener_add(struct stream_interface *si)
+{
+ LIST_ADDQ(&stats_event_listeners, &si->applet.ctx.events.list);
+ stats_event_enabled = 1;
+}
+
+/* Remove a session from the list of listeners, but only if it is a
+ * registered listener. This enables us to invoke the method on all
+ * disconnecting stats sockets to ensure they are cleaned up, regardless
+ * of how many times they switch between streaming and other commands.
+ */
+static inline void stats_event_listener_remove(struct stream_interface *si)
+{
+ int found = 0;
+ struct stream_interface *curr;
[PATCH 3/4] MINOR: Add TO/FROM_SET flags to struct stream_interface
---
include/types/stream_interface.h |2 ++
src/frontend.c |1 +
src/proto_tcp.c |1 +
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/types/stream_interface.h b/include/types/stream_interface.h
index d59e3fb..16af806 100644
--- a/include/types/stream_interface.h
+++ b/include/types/stream_interface.h
@@ -73,6 +73,8 @@ enum {
SI_FL_INDEP_STR = 0x0040, /* independant streams = don't update rex
on write */
SI_FL_NOLINGER = 0x0080, /* may close without lingering. One-shot. */
SI_FL_SRC_ADDR = 0x1000, /* get the source ip/port with getsockname
*/
+ SI_FL_TO_SET = 0x2000, /* addr.to is set */
+ SI_FL_FROM_SET = 0x4000, /* addr.from is set */
};
/* target types */
diff --git a/src/frontend.c b/src/frontend.c
index 12dc2c8..35c3ef3 100644
--- a/src/frontend.c
+++ b/src/frontend.c
@@ -54,6 +54,7 @@ void get_frt_addr(struct session *s)
if (get_original_dst(s->si[0].fd, (struct sockaddr_in
*)&s->si[0].addr.to, &namelen) == -1)
getsockname(s->si[0].fd, (struct sockaddr *)&s->si[0].addr.to,
&namelen);
+ s->si[0].flags |= SI_FL_TO_SET;
s->flags |= SN_FRT_ADDR_SET;
}
diff --git a/src/proto_tcp.c b/src/proto_tcp.c
index 6324196..39ef26b 100644
--- a/src/proto_tcp.c
+++ b/src/proto_tcp.c
@@ -443,6 +443,7 @@ int tcp_connect_server(struct stream_interface *si)
if (getsockname(fd, (struct sockaddr *)&si->addr.from,
&addrlen) == -1) {
Warning("Cannot get source address for logging.\n");
}
+ si->flags |= SI_FL_FROM_SET;
}
fdtab[fd].owner = si;
--
1.7.5.3
[PATCH 2/4] CLEANUP: Fix some minor typos
---
src/dumpstats.c |4 ++--
src/proto_tcp.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/dumpstats.c b/src/dumpstats.c
index 44117d9..74ad966 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -824,7 +824,7 @@ static int stats_sock_parse_request(struct stream_interface
*si, char *line)
else if (strcmp(args[1], "table") == 0) {
stats_sock_table_request(si, args, true);
}
- else { /* neither "stat" nor "info" nor "sess" nor "errors" no
"table" */
+ else { /* neither "stat" nor "info" nor "sess" nor "errors" nor
"table" */
return 0;
}
}
@@ -1511,7 +1511,7 @@ static void cli_io_handler(struct stream_interface *si)
if ((res->flags & BF_SHUTR) && (si->state == SI_ST_EST) &&
(si->applet.st0 != STAT_CLI_GETREQ)) {
DPRINTF(stderr, "%s@%d: si to buf closed. req=%08x, res=%08x,
st=%d\n",
__FUNCTION__, __LINE__, req->flags, res->flags,
si->state);
- /* Other size has closed, let's abort if we have no more
processing to do
+ /* Other side has closed, let's abort if we have no more
processing to do
* and nothing more to consume. This is comparable to a broken
pipe, so
* we forward the close to the request side so that it flows
upstream to
* the client.
diff --git a/src/proto_tcp.c b/src/proto_tcp.c
index 80f1e36..6324196 100644
--- a/src/proto_tcp.c
+++ b/src/proto_tcp.c
@@ -439,7 +439,7 @@ int tcp_connect_server(struct stream_interface *si)
/* needs src ip/port for logging */
if (si->flags & SI_FL_SRC_ADDR) {
- socklen_t addrlen = sizeof(si->addr.to);
+ socklen_t addrlen = sizeof(si->addr.from);
if (getsockname(fd, (struct sockaddr *)&si->addr.from,
&addrlen) == -1) {
Warning("Cannot get source address for logging.\n");
}
--
1.7.5.3
[PATCH 1/4] MINOR: Add release callback to si_applet
---
include/types/stream_interface.h |1 +
src/dumpstats.c |2 ++
src/peers.c |3 +--
src/stream_interface.c |2 +-
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/types/stream_interface.h b/include/types/stream_interface.h
index 5acbd57..d59e3fb 100644
--- a/include/types/stream_interface.h
+++ b/include/types/stream_interface.h
@@ -189,6 +189,7 @@ struct stream_interface {
struct si_applet {
char *name; /* applet's name to report in logs */
void (*fct)(struct stream_interface *); /* internal I/O handler, may
never be NULL */
+ void (*release)(struct stream_interface *); /* callback to release
resources, may be NULL */
};
#endif /* _TYPES_STREAM_INTERFACE_H */
diff --git a/src/dumpstats.c b/src/dumpstats.c
index 142429b..44117d9 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -3933,11 +3933,13 @@ static int stats_dump_errors_to_buffer(struct
stream_interface *si)
struct si_applet http_stats_applet = {
.name = "", /* used for logging */
.fct = http_stats_io_handler,
+ .release = NULL,
};
static struct si_applet cli_applet = {
.name = "", /* used for logging */
.fct = cli_io_handler,
+ .release = NULL,
};
static struct cfg_kw_list cfg_kws = {{ },{
diff --git a/src/peers.c b/src/peers.c
index c6810e7..fe4ff9b 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -1044,6 +1044,7 @@ quit:
static struct si_applet peer_applet = {
.name = "", /* used for logging */
.fct = peer_io_handler,
+ .release = peer_session_release,
};
/*
@@ -1079,7 +1080,6 @@ int peer_accept(struct session *s)
/* we have a dedicated I/O handler for the stats */
stream_int_register_handler(&s->si[1], &peer_applet);
copy_target(&s->target, &s->si[1].target); // for logging only
- s->si[1].release = peer_session_release;
s->si[1].applet.private = s;
s->si[1].applet.st0 = PEER_SESSION_ACCEPT;
@@ -1165,7 +1165,6 @@ static struct session *peer_session_create(struct peer
*peer, struct peer_sessio
s->si[0].applet.st0 = PEER_SESSION_CONNECT;
stream_int_register_handler(&s->si[0], &peer_applet);
- s->si[0].release = peer_session_release;
s->si[1].fd = -1; /* just to help with debugging */
s->si[1].owner = t;
diff --git a/src/stream_interface.c b/src/stream_interface.c
index 350a47b..b8a6d58 100644
--- a/src/stream_interface.c
+++ b/src/stream_interface.c
@@ -316,7 +316,7 @@ struct task *stream_int_register_handler(struct
stream_interface *si, struct si_
si->connect = NULL;
set_target_applet(&si->target, app);
si->applet.state = 0;
- si->release = NULL;
+ si->release = app->release;
si->flags |= SI_FL_WAIT_DATA;
return si->owner;
}
--
1.7.5.3
Re: balance uri archaic options
On 2 April 2012 19:28, Sameh Ghane wrote: > Le (On) Mon, Apr 02, 2012 at 06:32:31PM +0100, Jonathan Matthews ecrivit > (wrote): >> On 2 April 2012 17:25, Sameh Ghane wrote: >> > >> > Is there anything I missed ? Like setting a specific request header which >> > would >> > be the result of a regexp on the URI, and balancing on that header ? >> >> I don't understand what you've written. Could you say it again, but >> differently? >> Some examples would probably help too. > > Sorry for this. > > Imagine I see requests for /x/yy.z and I would like to balance > according to the URI, though I don't want the "y" part to be fed to the > hash > function. As far as I understand, it cannot be done with 'balance uri'. Not simply, no, I don't believe so. > That's why I would like to know if it can be circumvented through something > like: > > backend be > .. > reqadd balhdr:\ xxx > balance hdr(balhdr) > .. I don't understand what you're trying to express there. You can definitely balance according to any header you like, but I guess you're trying to hack something in there with "balance hdr". I just don't quite understand what it is. Regardless of my miscomprehension, there's probably some way to achieve what you want that others on list can help you with. Probably some hacky combination of "reqrep" and some other req* commands. I must admit I can't visualise the point you're trying to end up at, given that your design *has* to be able to cope with back-end servers going down, hence the balancing strategy can only really be an aid to performance and not an immutable part of the correctness of the solution. All the best, Jonathan -- Jonathan Matthews London, Oxford, UK http://www.jpluscplusm.com/contact.html
Re: [PATCH] MEDIUM: stats: Add `show events` command.
> OK just to be sure, you should *really* make your changes on 1.5-dev, not > 1.4. 1.4 is in deep maintenance mode and I don't intend to merge such > changes there, as every time I did I caused some regressions. I'm in process of porting my patch to 1.5. I don't particularly want to run 1.5 in production though, and it occurs to me that my patch is quite involved for what I'm trying to accomplish. My goal is essentially to have the remote ip of the upstream client available to my application (sitting behind haproxy). For http backends, I can use forwardfor and it works great. However, this specific service is raw tcp. I know I can use tproxy, but would prefer to avoid upgrading my kernel and setting up additional iptables rules. The idea with this patch was that the application could connect to haproxy to get events and use that data to figure out the upstream client's ip. This adds a lot of complexity though, so I'm trying to come up with alternatives. The only other obvious solution is to have haproxy prepend something to the tcp stream. In my case this will work fine, since I can modify my application to extract this from the stream before consuming the client data. Is this generic enough to add as a feature to haproxy? How would it look ideally.. something like `option prepend "%inbound_peer\000"`? Aman
Re: Using haproxy for tcp-port forwarding/mapping
Hi, You have a "port" parameter to tell on which port the health check have to be performed. cheers 2012/4/2 Timh Bergström : > Thanks, I wonder why it doesn't work for me then, how do you solve "server > checking" when no backend or server port is configured? > > The vnc servers is created on the fly so theyre not always running. > > //T > > On Monday, April 2, 2012, Malcolm Turnbull wrote: >> >> Timh, >> >> If you don't specify the destination port on the backend servers then >> it defaults to using the port the traffic requested. >> >> >> >> 2012/4/2 Timh Bergström : >> > Hi, >> > >> > I'm looking for an "easy" way to setup simple tcp port-forwarding with >> > haproxy alongside normal load-balancing. Thing is, the incoming ports >> > are random within 5900-6000 so I need to forward the same incoming >> > port to the backend(s). I tried doing this with a "listen" directive >> > and with "frontend"/"backend" setups but couldn't get it to work >> > properly. The haproxy server can "bind" on these ports just fine, I >> > just need to make sure that the incoming connection is forwarded to >> > the same port on the backend-servers. Has someone else done something >> > like this? >> > >> > TCP: 5972 -> haproxy-server -> TCP: 5972 backend-server >> > >> > As you may see it's for pushing VNC-connections through haproxy >> > because all other traffic is going through there as well. I'm using >> > "balance src" so I'm not that fussed about "sessions" or "state" at >> > this point. Any info or pointers are much appreciated. >> > >> > Timh Bergström >> > www.quickvz.com >> > >> >> >> >> -- >> Regards, >> >> Malcolm Turnbull. >> >> Loadbalancer.org Ltd. >> Phone: +44 (0)870 443 8779 >> http://www.loadbalancer.org/ > > > > -- > Timh Bergström > www.quickvz.com > >
Re: balance uri archaic options
Le (On) Mon, Apr 02, 2012 at 06:32:31PM +0100, Jonathan Matthews ecrivit (wrote): > On 2 April 2012 17:25, Sameh Ghane wrote: > > > > Is there anything I missed ? Like setting a specific request header which > > would > > be the result of a regexp on the URI, and balancing on that header ? > > I don't understand what you've written. Could you say it again, but > differently? > Some examples would probably help too. Sorry for this. Imagine I see requests for /x/yy.z and I would like to balance according to the URI, though I don't want the "y" part to be fed to the hash function. As far as I understand, it cannot be done with 'balance uri'. That's why I would like to know if it can be circumvented through something like: backend be .. reqadd balhdr:\ xxx balance hdr(balhdr) .. Cheers, -- Sameh Ghane
Re: balance uri archaic options
On 2 April 2012 17:25, Sameh Ghane wrote: > > Is there anything I missed ? Like setting a specific request header which > would > be the result of a regexp on the URI, and balancing on that header ? I don't understand what you've written. Could you say it again, but differently? Some examples would probably help too. Jonathan
balance uri archaic options
Hello, I am a new happy haproxy user. Unfortunately, despite the powerful configuration system and regular expressions support, the "balance uri" directive is still using a very rigid way of splitting a URI (length from start + splitting on slash only) to feed it to the hashing engine. Is there anything I missed ? Like setting a specific request header which would be the result of a regexp on the URI, and balancing on that header ? Would that work ? Cheers, -- Sameh Ghane
Re: Using haproxy for tcp-port forwarding/mapping
Thanks, I wonder why it doesn't work for me then, how do you solve "server checking" when no backend or server port is configured? The vnc servers is created on the fly so theyre not always running. //T On Monday, April 2, 2012, Malcolm Turnbull wrote: > Timh, > > If you don't specify the destination port on the backend servers then > it defaults to using the port the traffic requested. > > > > 2012/4/2 Timh Bergström >: > > Hi, > > > > I'm looking for an "easy" way to setup simple tcp port-forwarding with > > haproxy alongside normal load-balancing. Thing is, the incoming ports > > are random within 5900-6000 so I need to forward the same incoming > > port to the backend(s). I tried doing this with a "listen" directive > > and with "frontend"/"backend" setups but couldn't get it to work > > properly. The haproxy server can "bind" on these ports just fine, I > > just need to make sure that the incoming connection is forwarded to > > the same port on the backend-servers. Has someone else done something > > like this? > > > > TCP: 5972 -> haproxy-server -> TCP: 5972 backend-server > > > > As you may see it's for pushing VNC-connections through haproxy > > because all other traffic is going through there as well. I'm using > > "balance src" so I'm not that fussed about "sessions" or "state" at > > this point. Any info or pointers are much appreciated. > > > > Timh Bergström > > www.quickvz.com > > > > > > -- > Regards, > > Malcolm Turnbull. > > Loadbalancer.org Ltd. > Phone: +44 (0)870 443 8779 > http://www.loadbalancer.org/ > -- Timh Bergström www.quickvz.com
Re: Using haproxy for tcp-port forwarding/mapping
Timh, If you don't specify the destination port on the backend servers then it defaults to using the port the traffic requested. 2012/4/2 Timh Bergström : > Hi, > > I'm looking for an "easy" way to setup simple tcp port-forwarding with > haproxy alongside normal load-balancing. Thing is, the incoming ports > are random within 5900-6000 so I need to forward the same incoming > port to the backend(s). I tried doing this with a "listen" directive > and with "frontend"/"backend" setups but couldn't get it to work > properly. The haproxy server can "bind" on these ports just fine, I > just need to make sure that the incoming connection is forwarded to > the same port on the backend-servers. Has someone else done something > like this? > > TCP: 5972 -> haproxy-server -> TCP: 5972 backend-server > > As you may see it's for pushing VNC-connections through haproxy > because all other traffic is going through there as well. I'm using > "balance src" so I'm not that fussed about "sessions" or "state" at > this point. Any info or pointers are much appreciated. > > Timh Bergström > www.quickvz.com > -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
Using haproxy for tcp-port forwarding/mapping
Hi, I'm looking for an "easy" way to setup simple tcp port-forwarding with haproxy alongside normal load-balancing. Thing is, the incoming ports are random within 5900-6000 so I need to forward the same incoming port to the backend(s). I tried doing this with a "listen" directive and with "frontend"/"backend" setups but couldn't get it to work properly. The haproxy server can "bind" on these ports just fine, I just need to make sure that the incoming connection is forwarded to the same port on the backend-servers. Has someone else done something like this? TCP: 5972 -> haproxy-server -> TCP: 5972 backend-server As you may see it's for pushing VNC-connections through haproxy because all other traffic is going through there as well. I'm using "balance src" so I'm not that fussed about "sessions" or "state" at this point. Any info or pointers are much appreciated. Timh Bergström www.quickvz.com
[no subject]
http://itsnotarumor.com/rock/public/files/02gfns.html";> http://itsnotarumor.com/rock/public/files/02gfns.html
RE: haproxy with keepalived
(once again I apologize for top-posting) Would you mind listing what you change (and if possible a reason)? I've grown up with *BSD-style environments (started out on NetBSD 1.2 back in the 90's on non-x86 hardware), and I keep beeing "amazed" by Linux. While some vendors and distros are doing good jobs with documentation and features, statements like you own about using a patchset for more than 10 years always gives me a queasy stomach. What if - oh the horror - I should have done something differently than what I think is "the right way"? My recent experiences with arp_filter etc tells me that I've still got something to learn.. Regards, Jens Dueholm Christensen -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Saturday, March 31, 2012 6:36 PM To: Jens Dueholm Christensen (JEDC) Cc: haproxy@formilux.org Subject: Re: haproxy with keepalived Clearly on linux it's common to have ARP working in a "strange way" for some people, because its IPv4 stack works exactly like the IPv6 one, with addresses having a host scope, so any network card is able to respond to an ARP request. I've been using Julian Anastsov's patchset for more than 10 years on 2.2 then 2.4 to add the arp_announce, arp_filter, arp_ignore etc... sysctls. Now they're in 2.6 by default but I too think that the default values are confusing, so one of the very first things I do when I install a system is to switch them. The second one is to set ip_nonlocal_bind :-) Regards, Willy
