Re: Show outgoing headers when full debug enabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/04/2015 12:56 ??, CJ Ess wrote: When you run HAProxy in full debugging mode there is a debug_hdrs() call that displays all of the http headers read from the frontend, I'd also like to be able to see the headers being sent to the backend. So far I haven't pinpointed where the headers are being sent from so that I can add another debug_hdrs() call. Anyone point me to the right place? tcpdump may be easier... Cheers, Pavlos -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVQetrAAoJEIP8ktofcXa54WYP/jiEj2NT9bK/pQyqC6gk2jXH JJh3vhZkXe+yQ65zIiaY0G+7QfWQOgQpoNFpfc710xOyQIhQDrYI74rh6oG6O5Zc frvv4ChsrNh7tupVgr/81QLBQa2ZZVgsvja2BwXUcXbop1ZGIQqbC/QgQ5ku58g+ aDJgnTqaLzXSc56x0SVRxThiHdZnczb1mHsQ8mrWNzXArk2s/3iiX7ae3W5Nv4Wl cTznzehyJChY1JeHnUBbh1lrKq0JuugCe9NzZOK/SVqP56YwGNQ75rZxh9f5EBB3 QTZlvTlBy5YNW4vtfq2L6QgkA6+ayXmi/AnTGPCoT4mrE7fe8ksqF88oNdV0Asuf iEe6DFQVcsNUaFLxrpC9MRAi2rYA3OVwZieMxCyC4arnFQ9qbtSG0KBfaElCuGn5 vBTVd83R88UX0WNSQL1Fr1o6zN6thz04KnM6aDdZcXgcLTZQd/Y5t0HVdETH8hlX oIc+/kshBwwoUhZ5MoRtj4ALQ2y7z6Uchi1j1jW/UkjLvYceXiPu04pwUEm4DooS dktqr69Wf45I+FO5Cq6sdcaPCAjCnrSS46eiibGnSg6SKyLQk7fI4+uQfepUkSFY yNuwsqiRdNOg7ZS0BOp/NmLVQi4n44/0ju2iccY4HsI8SYiEBEfgS06Fs95A8pjM BSydnkhlmB8g6cT1P1D1 =M0ir -END PGP SIGNATURE-
Choosing backend based on constant
Hi everybody I'd like to simplify my haproxy configuration management by using almost identical configurations for different groups of haproxy installations that use different backends based on string comparision. The only difference in haproxy configuration files of different groups would be that string. The configuration logic would be something like this (not syntactically correct for haproxy, I know, but should show what I wish to accomplish): constant = foo # first hostgroup configuration constant = bar # second hostgroup configuration # common configuration for all hostgroups use_backend ha_backend_foo if constant == foo use_backend ha_backend_bar if constant == bar ... I wonder how to specify that string and form acl to use in 'use_backend' statement? Thanks in advance, Veiko
Re: Choosing backend based on constant
On Thu, Apr 30, 2015 at 11:49 AM, Veiko Kukk vk...@xvidservices.com wrote: Hi everybody I'd like to simplify my haproxy configuration management by using almost identical configurations for different groups of haproxy installations that use different backends based on string comparision. The only difference in haproxy configuration files of different groups would be that string. The configuration logic would be something like this (not syntactically correct for haproxy, I know, but should show what I wish to accomplish): constant = foo # first hostgroup configuration constant = bar # second hostgroup configuration # common configuration for all hostgroups use_backend ha_backend_foo if constant == foo use_backend ha_backend_bar if constant == bar ... I wonder how to specify that string and form acl to use in 'use_backend' statement? Thanks in advance, Veiko Hi Veiko, The question is how do you set your constant, what piece of information do you use from the traffic or whatever? Then we may help you. Baptiste
Re: Choosing backend based on constant
Perhaps this is more what you are looking for? https://github.com/smarterclayton/haproxy-map-route-example On Thu, Apr 30, 2015 at 11:43 AM, Veiko Kukk vk...@xvidservices.com wrote: I'd like to manually add that constant string into configuration, not to get it from the traffic. It would help to reduce differences in haproxy configuration file between server groups and easier migration between groups. Best regards, Veiko On 30/04/15 18:06, Baptiste wrote: On Thu, Apr 30, 2015 at 11:49 AM, Veiko Kukk vk...@xvidservices.com wrote: Hi everybody I'd like to simplify my haproxy configuration management by using almost identical configurations for different groups of haproxy installations that use different backends based on string comparision. The only difference in haproxy configuration files of different groups would be that string. The configuration logic would be something like this (not syntactically correct for haproxy, I know, but should show what I wish to accomplish): constant = foo # first hostgroup configuration constant = bar # second hostgroup configuration # common configuration for all hostgroups use_backend ha_backend_foo if constant == foo use_backend ha_backend_bar if constant == bar ... I wonder how to specify that string and form acl to use in 'use_backend' statement? Thanks in advance, Veiko Hi Veiko, The question is how do you set your constant, what piece of information do you use from the traffic or whatever? Then we may help you. Baptiste
[PATCH] HAProxy 1.6 Compile clean with -DDEBUG_FULL -DDEBUG_AUTH
diff --git a/src/auth.c b/src/auth.c
index 42c0808..6973136 100644
--- a/src/auth.c
+++ b/src/auth.c
@@ -218,11 +218,12 @@ check_user(struct userlist *ul, const char *user,
const char *pass)
{
struct auth_users *u;
+ struct auth_groups_list *agl;
const char *ep;
#ifdef DEBUG_AUTH
- fprintf(stderr, req: userlist=%s, user=%s, pass=%s, group=%s\n,
- ul-name, user, pass, group);
+ fprintf(stderr, req: userlist=%s, user=%s, pass=%s\n,
+ ul-name, user, pass);
#endif
for (u = ul-users; u; u = u-next)
diff --git a/src/stream.c b/src/stream.c
index 12b6f9d..72cbb08 100644
--- a/src/stream.c
+++ b/src/stream.c
@@ -737,10 +737,10 @@ static void sess_update_stream_int(struct stream *s)
DPRINTF(stderr,[%u] %s: sess=%p rq=%p, rp=%p, exp(r,w)=%u,%u
rqf=%08x rpf=%08x rqh=%d rqt=%d rph=%d rpt=%d cs=%d ss=%d\n,
now_ms, __FUNCTION__,
s,
- req, s-rep,
+ req, s-res,
req-rex, s-res.wex,
req-flags, s-res.flags,
- req-buf-i, req-buf-o, s-res.buf-i, s-res.buf-o,
s-si[0].state, req-cons-state);
+ req-buf-i, req-buf-o, s-res.buf-i, s-res.buf-o,
s-si[0].state, s-si[1].state);
if (si-state == SI_ST_ASS) {
/* Server assigned to connection request, we have to try to
connect now */
@@ -931,10 +931,10 @@ static void sess_prepare_conn_req(struct stream *s)
DPRINTF(stderr,[%u] %s: sess=%p rq=%p, rp=%p, exp(r,w)=%u,%u
rqf=%08x rpf=%08x rqh=%d rqt=%d rph=%d rpt=%d cs=%d ss=%d\n,
now_ms, __FUNCTION__,
s,
- s-req, s-rep,
+ s-req, s-res,
s-req.rex, s-res.wex,
s-req.flags, s-res.flags,
- s-req.buf-i, s-req.buf-o, s-res.buf-i, s-res.buf-o,
s-si[0].state, s-req.cons-state);
+ s-req.buf-i, s-req.buf-o, s-res.buf-i, s-res.buf-o,
s-si[0].state, s-si[1].state);
if (si-state != SI_ST_REQ)
return;
Config option for staging/dev backends?
I have a number of backend configs that handle requests to dev and staging webservers. These backend configs only have one server. If that server goes down briefly because the server process is restarted, which happens frequently precisely because they are for dev/staging, I get a console notification from syslog. I definitely DO want this kind of console notification if one of the production backends has no server available, but I don't want the interruption for staging or dev. If a config option to reduce the severity of the no server available notification on an individual backend isn't available currently, can one be added? Thanks, Shawn
Re: Config option for staging/dev backends?
Hi Shawn, Le 30/04/2015 21:57, Shawn Heisey a écrit : One thing that I can do is increase the fall parameter for checks on the dedicated dev/staging servers, but there's a downside: haproxy won't notice that a server is down very quickly. I don't mind that haproxy *logs* the server going down and the entire backend being unavailable ... in fact, that's a good thing ... I just don't want to see it on the console or in ssh sessions. A message that's logged to the console implies that there's a problem requiring immediate attention. A dev server rebooting does NOT require immediate attention. Simply adjust your the log levels in your haproxy configuration for those backends, by setting the minimum syslog level to error for example, this will prevent still log the events but won't send them as emerg/alert/crit (which I assume one of them is configured to send logs to the console). Or use a different facility for them, and configure your syslog server to not send logs to the console for this facility when it's sent by haproxy. See http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-log for more details, specifically the last argument. -- Cyril Bonté
Re: Config option for staging/dev backends?
On 4/30/2015 1:03 PM, Pavlos Parissis wrote: On 30/04/2015 08:31 μμ, Shawn Heisey wrote: I definitely DO want this kind of console notification if one of the production backends has no server available, but I don't want the interruption for staging or dev. If a config option to reduce the severity of the no server available notification on an individual backend isn't available currently, can one be added? Just disable health checking for those backends. There are a couple of reasons that I include dev/staging sites in the haproxy config. 1) It ensures that haproxy is *always* part of the equation, since it will be part of the equation when the code is in production. Site behavior might change in subtle ways if we don't connect in exactly the same way for dev, staging, and production. 2) I need to verify that health checks actually work. If health checks are disabled on my dev/staging back ends, then I can't verify that those health checks actually work unless we deploy the new website code to a production server, which defeats part of the purpose of having a staging server in the first place. One thing that I can do is increase the fall parameter for checks on the dedicated dev/staging servers, but there's a downside: haproxy won't notice that a server is down very quickly. I don't mind that haproxy *logs* the server going down and the entire backend being unavailable ... in fact, that's a good thing ... I just don't want to see it on the console or in ssh sessions. A message that's logged to the console implies that there's a problem requiring immediate attention. A dev server rebooting does NOT require immediate attention. Thanks, Shawn
Re: Config option for staging/dev backends?
On 30/04/2015 08:31 μμ, Shawn Heisey wrote: I have a number of backend configs that handle requests to dev and staging webservers. These backend configs only have one server. If that server goes down briefly because the server process is restarted, which happens frequently precisely because they are for dev/staging, I get a console notification from syslog. I definitely DO want this kind of console notification if one of the production backends has no server available, but I don't want the interruption for staging or dev. If a config option to reduce the severity of the no server available notification on an individual backend isn't available currently, can one be added? Thanks, Shawn Just disable health checking for those backends. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: Config option for staging/dev backends?
On 30/04/2015 09:57 μμ, Shawn Heisey wrote: On 4/30/2015 1:03 PM, Pavlos Parissis wrote: On 30/04/2015 08:31 μμ, Shawn Heisey wrote: I definitely DO want this kind of console notification if one of the production backends has no server available, but I don't want the interruption for staging or dev. If a config option to reduce the severity of the no server available notification on an individual backend isn't available currently, can one be added? Just disable health checking for those backends. There are a couple of reasons that I include dev/staging sites in the haproxy config. 1) It ensures that haproxy is *always* part of the equation, since it will be part of the equation when the code is in production. Site behavior might change in subtle ways if we don't connect in exactly the same way for dev, staging, and production. 2) I need to verify that health checks actually work. If health checks are disabled on my dev/staging back ends, then I can't verify that those health checks actually work unless we deploy the new website code to a production server, which defeats part of the purpose of having a staging server in the first place. One thing that I can do is increase the fall parameter for checks on the dedicated dev/staging servers, but there's a downside: haproxy won't notice that a server is down very quickly. I don't mind that haproxy *logs* the server going down and the entire backend being unavailable ... in fact, that's a good thing ... I just don't want to see it on the console or in ssh sessions. A message that's logged to the console implies that there's a problem requiring immediate attention. A dev server rebooting does NOT require immediate attention. ah ok, so you do want health checking, I misunderstood your initial question. Then it is matter to configure your log daemon to emit haproxy logs to console but that will emit all messages and not just the ones from staging backend and I guess you want to get messages on the console for failures on other backends. I guess if you use syslog-ng you can set a filter to skip log messages matching a specific pattern(backend names in your case) Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: Choosing backend based on constant
On Thu, Apr 30, 2015 at 06:43:30PM +0300, Veiko Kukk wrote: I'd like to manually add that constant string into configuration, not to get it from the traffic. It would help to reduce differences in haproxy configuration file between server groups and easier migration between groups. Once in a while I'm saying that we need to implement a few sample fetch functions returning a constant that's passed as argument exactly for this purpose. I think we should create : bin() str() int() uint() bool() ipv4() ipv6() But since there's little demand for this, it's still very low on the priority list. If you want to work on this, your patch will be very welcome! Otherwise you could use env() and rely on an environment variable, that's convenient as well. Regards, Willy
Re: Recommendations for a new haproxy installation
Hi, On Wed, Apr 29, 2015 at 10:58:36PM -0600, Shawn Heisey wrote: On 4/29/2015 3:00 PM, Shawn Heisey wrote: How can I be sure that openssl is compiled with support for TLS acceleration in the CPU? I am compiling haproxy from source. Would you recommend that I install a separate and newer openssl from source for explicit use with haproxy, and tweak its config for the specific hardware it's on? Followup on the openssl part of my email. I built and installed openssl 1.0.2a from source, with this config line: ./config no-shared enable-ec_nistp_64_gcc_128 threads This looks correct to me. Then I built haproxy using this command: make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 CPU=native SSL_INC=/usr/local/ssl/include SSL_LIB=/usr/local/ssl/lib ADDLIB=-ldl Here's the 'haproxy -vv' and 'uname -a' output: --- HA-Proxy version 1.5.11 2015/01/31 Copyright 2000-2015 Willy Tarreau w...@1wt.eu Build options : TARGET = linux2628 CPU = native CC = gcc CFLAGS = -O2 -march=native -g -fno-strict-aliasing OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.8 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.2a 19 Mar 2015 Running on OpenSSL version : OpenSSL 1.0.2a 19 Mar 2015 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.31 2012-07-06 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. Looks good as well. --- Linux lb1 3.13.0-49-generic #83-Ubuntu SMP Fri Apr 10 20:11:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux --- OK. Can anyone who's knowledgeable about this look over what I've done and tell me if they'd do something different? That's fine for me. I also still need some assistance with the rest of my original email. I do not have much advice to add beyond this. Side issue, mentioning in case it's important, though I suspect it isn't: When I built openssl with the indicated config, 'make test' failed, but it passed on an earlier build with 'shared' instead of 'no-shared'. I rebuilt with no-shared because haproxy was dynamically linking the older openssl library installed from ubuntu packages, instead of the newer library used for compile. You'd still better run with the shared mode in my opinion, because openssl provides frequent updates and 1.0.2 is fairly new, so you'll certainly have to rebuild often. On the other hand, it might be an opportunity to think about upgrading haproxy as well. But you need to be reactive since openssl updates are generally for security issues (eg heartbleed and such), so you don't want to wait. Regards, Willy
Re: Recommendations for a new haproxy installation
On Wed, Apr 29, 2015 at 03:00:58PM -0600, Shawn Heisey wrote: I have an existing load balancer installation that I have been slowly migrating from IPVS to haproxy. It's CentOS 6, so many components are out of date, such as TLS support. Once that migration is done, I would like to entirely replace the hardware and load an ideal software environment for haproxy. The new machines have Ubuntu 14, so the openssl version is fairly new, but not the newest available. The CPU is an Intel Xeon E5-2430, which has built-in TLS acceleration. It has 16GB of memory. The machine is dedicated for load balancing. How can I be sure that openssl is compiled with support for TLS acceleration in the CPU? I don't understand what type of acceleration your talking about. There are multiple features improving TLS performance such as AES-NI, MULX, AVX2, etc. Anyway you can use openssl speed to compare between the original lib and your newly built one. You can force some algorithms to verify specific improvements, such as openssl speed rsa2048 or openssl speed ecdhp256 etc. I am compiling haproxy from source. Would you recommend that I install a separate and newer openssl from source for explicit use with haproxy, and tweak its config for the specific hardware it's on? As I mentionned in the other mail, I still prefer a dynamic build to make it easier to update it, but I know it's not necessarily easy because the soname doesn't change between versions... The CPU has 6 hyperthreaded CPU cores. I know that haproxy can be run in multiprocess mode to take advantage of multiple CPU cores, but is that a recommended and stable config? Yes, but there are a few things that are not shared such as stick-tables and stats. Also you won't be able to use peers to replicate stick-tables between nodes. And health-checks will be done for each process. If it is, then I will do it just so I'm taking full advantage of the hardware. If it's just for SSL performance, you can also have one TLS-only instance running in multi-process to decipher the traffic and a single process one for the rest. You just use abstract sockets between the processes, they're cheaper than TCP and that's all. Example : global nbproc 6 listen ssl-offload bind :443 process 1 crt ... bind :443 process 2 crt ... bind :443 process 3 crt ... bind :443 process 4 crt ... bind :443 process 5 crt ... bind :443 process 6 crt ... server clear abns@haproxy-clear-listener send-proxy-v2 And the other one : global nbproc 1 frontend clear-text bind :80 ... bind abns@haproxy-clear-listener accept-proxy ... You can put the two in the same config if you want, but then don't forget to specify bind-process 1 in all instances except the first one. Peers will fail as well (though I have an idea how to fix that). I know from the list history that stats don't aggregate across processes, but as long as I can figure out how to look at all the stats, that shouldn't be a problem. To access all the stats, simply have different ports bound to different processes and visit all of them. For the CLI, you can define as many as you want and specify process on the stats line as well to limit the scope of the socket. Is there anything else I should be aware of or think about as I work on the OS and software for this replacement hardware? If you're working on preparing the OS, please *do* verify that conntrack is properly tuned (large hash table with at least 1/4 of the total number of sessions). Otherwise under load it will become extremely slow. Regards, Willy
Re: [PATCH] HAProxy 1.6 Compile clean with -DDEBUG_FULL -DDEBUG_AUTH
Hi,
On Thu, Apr 30, 2015 at 01:47:30PM -0400, CJ Ess wrote:
diff --git a/src/auth.c b/src/auth.c
index 42c0808..6973136 100644
--- a/src/auth.c
+++ b/src/auth.c
@@ -218,11 +218,12 @@ check_user(struct userlist *ul, const char *user,
const char *pass)
{
struct auth_users *u;
+ struct auth_groups_list *agl;
const char *ep;
#ifdef DEBUG_AUTH
Above, could you please move the variable declaration after the #ifdef
so that we don't get a build warning in the non-debug case ?
Otherwise it looks fine to me.
Thanks,
Willy
Re: Show outgoing headers when full debug enabled
On Thu, Apr 30, 2015 at 10:44:28AM +0200, Pavlos Parissis wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/04/2015 12:56 ??, CJ Ess wrote: When you run HAProxy in full debugging mode there is a debug_hdrs() call that displays all of the http headers read from the frontend, I'd also like to be able to see the headers being sent to the backend. So far I haven't pinpointed where the headers are being sent from so that I can add another debug_hdrs() call. Anyone point me to the right place? tcpdump may be easier... Yes that's very true. When root access is not possible, strace is a nice alternative as well : strace -tts200 -e trace=sendto -p $pid Cheers, Willy
Re: Config option for staging/dev backends?
Le 30/04/2015 23:32, Shawn Heisey a écrit : On 4/30/2015 2:11 PM, Cyril Bonté wrote: Simply adjust your the log levels in your haproxy configuration for those backends, by setting the minimum syslog level to error for example, this will prevent still log the events but won't send them as emerg/alert/crit (which I assume one of them is configured to send logs to the console). Or use a different facility for them, and configure your syslog server to not send logs to the console for this facility when it's sent by haproxy. Assuming I understood what you were telling me, this didn't work. I tried adding a log line to the backend: backend be-services-dev-8443 description Back end for dev services requests. log 127.0.0.1 local0 err No, you didn't provide err as the minlevel argument. It should be something like : log 127.0.0.1 local0 notice err Also, ensure you don't have a log global somewhere in those backends or in the previously declared defaults section. Btw, I'm realizing that the minlevel argument is not documented at all. This is something we'll have to fix in the documentation. server circus 10.100.2.99:8443 ssl track chk-mule-8443/circus The global logging config looks like this: global log 127.0.0.1 local0 log 127.0.0.1 local1 notice I also tried with warning in place of err with no change. In both cases, this was logged into my ssh session when the web server on circus was restarted: Message from syslogd@ at Thu Apr 30 15:20:58 2015 ... localhost.localdomain haproxy[13259]: backend be-services-dev-8443 has no server available! I do think it would be good to have a dedicated backend option that changes the severity of that one kind of log and doesn't require repeating the log destination that has already been declared in global. I can look into making a patch, but that will require learning parts of the code first. Thanks, Shawn -- Cyril Bonté
Re: Config option for staging/dev backends?
On 4/30/2015 2:11 PM, Cyril Bonté wrote: Simply adjust your the log levels in your haproxy configuration for those backends, by setting the minimum syslog level to error for example, this will prevent still log the events but won't send them as emerg/alert/crit (which I assume one of them is configured to send logs to the console). Or use a different facility for them, and configure your syslog server to not send logs to the console for this facility when it's sent by haproxy. Assuming I understood what you were telling me, this didn't work. I tried adding a log line to the backend: backend be-services-dev-8443 description Back end for dev services requests. log 127.0.0.1 local0 err server circus 10.100.2.99:8443 ssl track chk-mule-8443/circus The global logging config looks like this: global log 127.0.0.1 local0 log 127.0.0.1 local1 notice I also tried with warning in place of err with no change. In both cases, this was logged into my ssh session when the web server on circus was restarted: Message from syslogd@ at Thu Apr 30 15:20:58 2015 ... localhost.localdomain haproxy[13259]: backend be-services-dev-8443 has no server available! I do think it would be good to have a dedicated backend option that changes the severity of that one kind of log and doesn't require repeating the log destination that has already been declared in global. I can look into making a patch, but that will require learning parts of the code first. Thanks, Shawn
Re: Choosing backend based on constant
You can use stick tables to create sticky sessions based on origin IP, cookies, and things like that, you'll need HAProxy 1.5 of better t do it. If you google for haproxy sticky sessions you'll find an number of examples. Here are a couple stand-outs: http://blog.haproxy.com/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/ http://stackoverflow.com/questions/27094501/haproxy-1-5-8-how-do-i-configure-cookie-based-stickiness http://serverfault.com/questions/652911/implementing-tcp-sticky-sessions-with-haproxy-to-handle-ssl-pass-through-traffic
Re: Choosing backend based on constant
I'd like to manually add that constant string into configuration, not to get it from the traffic. It would help to reduce differences in haproxy configuration file between server groups and easier migration between groups. Best regards, Veiko On 30/04/15 18:06, Baptiste wrote: On Thu, Apr 30, 2015 at 11:49 AM, Veiko Kukk vk...@xvidservices.com wrote: Hi everybody I'd like to simplify my haproxy configuration management by using almost identical configurations for different groups of haproxy installations that use different backends based on string comparision. The only difference in haproxy configuration files of different groups would be that string. The configuration logic would be something like this (not syntactically correct for haproxy, I know, but should show what I wish to accomplish): constant = foo # first hostgroup configuration constant = bar # second hostgroup configuration # common configuration for all hostgroups use_backend ha_backend_foo if constant == foo use_backend ha_backend_bar if constant == bar ... I wonder how to specify that string and form acl to use in 'use_backend' statement? Thanks in advance, Veiko Hi Veiko, The question is how do you set your constant, what piece of information do you use from the traffic or whatever? Then we may help you. Baptiste
