Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

We've been seeing CenturyLink and a few other residential providers NATing
their IPv4 traffic, making client persistency on source IP result in really
lopsided load balancing lately.

We'd like to convert to sticking on a custom header we're already using
that IDs the user. There isn't a lot of examples of this, so I was curious
if this is the right approach:

Previous "stick on src" config:
https://gist.github.com/williamsjj/7c3876d32cab627ffe70

New "stick on header" config:
https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906

Thank you in advance for any advice.

-J

Re: LUA

[thierry . fournier]

Hello, its not a dumb question, because all of this  is a little bit
confused.

Lua is a programation language. The basics of the labguage and the main
API are avalaible on the web site:

   http://www.lua.org/

More precisely the manual according with the Lua version in use in
Haproxy is here:

   http://www.lua.org/manual/5.3/

For Lua use wth HAProxy, only the chapters 1, 2, 3 and 6 are useful.

HAProxy provides a lot of class which permit to manipulate stream,
request and all the HAProxy componants. Theses classes are described
here:

   http://www.arpalert.org/src/haproxy-lua-api/1.6dev/index.html

Some complements, like how loading Lua file are in the HAProxy
configuration manual:

   https://cbonte.github.io/haproxy-dconv/configuration-1.6.html

Thierry


On Wed, 30 Sep 2015 10:25:49 +0100
Kobus Bensch  wrote:

> Ignore this, I found what I was looking for.
> 
> On 30/09/2015 10:16, Kobus Bensch wrote:
> > Hi
> >
> > I have been seeing a lot of LUA posts and wanted to read up on it. Is 
> > this the right site: http://www.lua.org/
> >
> > I am aware of the API docs at 
> > http://www.arpalert.org/src/haproxy-lua-api/1.6dev/index.html, but 
> > wanted to read a bit more and Google returned a rather long list of 
> > potential sites.
> >
> > Apologies if this is a bit of a dumb question, but I did not want to 
> > go read something just to find out later that it is completely the 
> > wrong stuff.
> >
> > Thank you
> >
> > Kobus
> > -- 
> > Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
> > Senior Systems Administrator
> > Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
> > DDI:  0207 871 3958
> > Tel:  0207 871 3890
> > Email: kobus.ben...@trustpayglobal.com 
> > 
> 
> -- 
> Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
> Senior Systems Administrator
> Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
> DDI:  0207 871 3958
> Tel:  0207 871 3890
> Email: kobus.ben...@trustpayglobal.com 
> 
> 
> -- 
> 
> 
> Trustpay Global Limited is an authorised Electronic Money Institution 
> regulated by the Financial Conduct Authority registration number 900043. 
> Company No 07427913 Registered in England and Wales with registered address 
> 130 Wood Street, London, EC2V 6DL, United Kingdom.
> 
> For further details please visit our website at www.trustpayglobal.com.
> 
> The information in this email and any attachments are confidential and 
> remain the property of Trustpay Global Ltd unless agreed by contract. It is 
> intended solely for the person to whom or the entity to which it is 
> addressed. If you are not the intended recipient you may not use, disclose, 
> copy, distribute, print or rely on the content of this email or its 
> attachments. If this email has been received by you in error please advise 
> the sender and delete the email from your system. Trustpay Global Ltd does 
> not accept any liability for any personal view expressed in this message.

Re: Linux or FreeBSD ?

[Rainer Duffner]

> Am 30.09.2015 um 16:25 schrieb Jeff Palmer :
> 
> Arnall,
> 
> 
> This advice is less of an haproxy specific response, and more of
> general information.
> 
> As someone who's tried to manage mixed infrastructure, I would push
> back if possible, unles syour organization has decided to move to
> freebsd entirely.
> 


Very few do that.
FreeBSD fulfills its purposes, though.
Even if you try to standardize on one „flavor“ of Linux, you will still end up 
with other flavors - simply because not everything runs on your particular 
flavor.
And you’re not going to run all of your applications on all of your platforms 
anyway. So the QA-effort should be manageable.
But that doesn’t mean it’s wise to introduce a half dozen different platforms, 
either - unless you have enough people to handle all of it.

How many systems (with Debian) are we talking about anyway?
And how many HA-Proxies are supposed to be migrated?

What are the sysadmin’s technical points for moving?
Besides probably not wanting to deal with Debian’s head-ache-inducing idea of 
an OS - that’s a given ;-)

Unless OP is doing some *really fancy stuff*, there’s IMO no pure technical 
show-stopper for a switch.

Re: [PATCH] BUILD: IP_TTL: Fix compilation on almost FreeBSD and OpenBSD.

[joris dedieu]

Already fix by ae459f3

Joris

2015-09-29 8:21 GMT+02:00 Joris Dedieu :
> IP_TTL socket option is defined on some systems that don't have SOL_IP.
> Use IPPROTO_IP in this case.
> ---
>  src/proto_tcp.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/proto_tcp.c b/src/proto_tcp.c
> index f698889..3642398 100644
> --- a/src/proto_tcp.c
> +++ b/src/proto_tcp.c
> @@ -1456,7 +1456,11 @@ static enum act_return 
> tcp_exec_action_silent_drop(struct act_rule *rule, struct
>  * network and has no effect on local net.
>  */
>  #ifdef IP_TTL
> +#ifdef SOL_IP
> setsockopt(conn->t.sock.fd, SOL_IP, IP_TTL, , sizeof(one));
> +#else
> +   setsockopt(conn->t.sock.fd, IPPROTO_IP, IP_TTL, , sizeof(one));
> +#endif
>  #endif
>   out:
> /* kill the stream if any */
> --
> 2.3.6
>

Re: [ANNOUNCE] haproxy-1.6-dev6

[joris dedieu]

Hi Willy,

2015-09-29 18:27 GMT+02:00 Willy Tarreau :
> On Tue, Sep 29, 2015 at 02:58:04PM +0200, joris dedieu wrote:
>> kevent(3,0x0,0,{},5,{1.0 }) = 0 (0x0)
>> kevent(3,0x0,0,{0x4,EVFILT_READ,0x0,0,0x1,0x0},5,{1.0 }) = 1 (0x1)
>> accept(4,{ AF_INET 80.247.233.242:48068 },0x7fffe804) = 5 (0x5)
>> fcntl(5,F_SETFL,O_NONBLOCK) = 0 (0x0)
>> recvfrom(5,0x801407000,16384,0x20080,0x0,0x0) ERR#35 'Resource
>> temporarily unavailable'
>> setsockopt(0x5,0x0,0x4,0x48668c,0x4,0x0) = 0 (0x0)
>> setsockopt(0x5,0x6,0x1,0x48668c,0x4,0x0) = 0 (0x0)
>> accept(4,0x7fffe808,0x7fffe804) ERR#35 'Resource
>> temporarily unavailable'
>> shutdown(5,SHUT_WR) = 0 (0x0)
>> close(5) = 0 (0x0)
>>
>> Has you can see it doesn't looks great.
>
> OK I found the reason, in my case the RST I was seeing was caused by pending
> data otherwise haproxy didn't send it by itself since we're facing the client.
> I've fixed it so that lingering is *really* disabled this time. You can retry

Ok that fix the issue. I get the same tcp sequence on both Linux and FreeBSD.

08:15:25.552414 IP jau31-2-82-236-20-129.fbx.proxad.net.33355 >
ladybug2.rmdir.fr.2: Flags [S], seq 1066137200, win 29200, options
[mss 1460,sackOK,TS val 15996126 ecr 0,nop,wscale 7], length 0
08:15:25.552427 IP ladybug2.rmdir.fr.2 >
jau31-2-82-236-20-129.fbx.proxad.net.33355: Flags [S.], seq
1788015248, ack 1066137201, win 65535, options [mss 1460,nop,wscale
6,sackOK,TS val 524803316 ecr 15996126], length 0
08:15:25.589643 IP jau31-2-82-236-20-129.fbx.proxad.net.33355 >
ladybug2.rmdir.fr.2: Flags [.], ack 1, win 229, options
[nop,nop,TS val 15996135 ecr 524803316], length 0
08:15:25.590207 IP ladybug2.rmdir.fr.2 >
jau31-2-82-236-20-129.fbx.proxad.net.33355: Flags [F.], seq 1, ack 1,
win 1040, options [nop,nop,TS val 524803354 ecr 15996135], length 0
08:15:25.590340 IP ladybug2.rmdir.fr.2 >
jau31-2-82-236-20-129.fbx.proxad.net.33355: Flags [R.], seq 2, ack 1,
win 1040, options [nop,nop,TS val 524803354 ecr 15996135], length 0


> with the attached patch if you want. The second one will get rid of the
> useless recvfrom() call if your system doesn't have TCP_QUICKACK. The third

Yes as far as I know there is no per socket option for this on FreeBSD
(only the system wild net.inet.tcp.delayed_ack variable). The
recvfrom disappears as expected.

Many thanks
Joris

> patch addresses a build issue reported off-list on another FreeBSD machine
> (SOL_IP not defined).
>
> Thanks,
> Willy
>

Re: [ANNOUNCE] haproxy-1.6-dev6

[Willy Tarreau]

Hi Joris,

On Wed, Sep 30, 2015 at 08:50:12AM +0200, joris dedieu wrote:
> > OK I found the reason, in my case the RST I was seeing was caused by pending
> > data otherwise haproxy didn't send it by itself since we're facing the 
> > client.
> > I've fixed it so that lingering is *really* disabled this time. You can 
> > retry
> 
> Ok that fix the issue. I get the same tcp sequence on both Linux and FreeBSD.

Great, thanks for the feedback!

Cheers,
Willy

Re: Implementing HAProxy First Time: Conditional backend issue

[Bryan Talbot]

On Wed, Sep 30, 2015 at 12:37 PM, Susheel Jalali  wrote:

> Dear HAProxy Developers community:
>
> After incorporating inputs from some of you, we tested with an updated
> haproxy.cfg (see below).  Product-1 is still not accessible
>

Without the complete haproxy config and some logs, it was impossible for
anyone to understand what issues you might be having. The question was just
too vague.



> Info.log
> Conditional backend
> Sep 30 09:12:44 localhost haproxy[1691]: 192.168.100.153 - - "GET
> /CoscendPad HTTP/1.1" 404 262 "" "" 53639 804 "webapps-frontend"
> "subdomain_p1-backend" "Product1" 5 0 0 3 8  4 4 0 0 0 0 0 "" ""
>
>
>From the logs shown it looks like your "conditional" backend is returning a
404, but since the log format is not standard; without the haproxy config
we can only guess at what the log contents mean.

-Bryan

Re: Address selection policy in dual-stack environments

[Willy Tarreau]

Hi Dmitry!

On Wed, Sep 30, 2015 at 01:33:56PM +0300, Dmitry Sivachenko wrote:
> 
> > On 29 . 2015 ??., at 23:06, Willy Tarreau  wrote:
> > 
> > On Tue, Sep 29, 2015 at 10:59:15PM +0300, Dmitry Sivachenko wrote:
> >>> I *think* that getaddrinfo() provides this. You can try to build by
> >>> adding USE_GETADDRINFO=1 to your makefile. It's not enabled by default
> >>> because there are numerous bogus implementations on various systems.
> >>> If it works for you it could be the best solution as other programs
> >>> which work are likely using it. I don't know if it's safe to enable
> >>> it by default on FreeBSD.
> >>> 
> >> 
> >> 
> >> I do have this enabled:
> >> 
> >> Build options :
> >>  TARGET  = freebsd
> >>  CPU = generic
> >>  CC  = cc
> >>  CFLAGS  = -O2 -pipe -O2 -fno-strict-aliasing -pipe -fstack-protector 
> >> -DFREEBSD_PORTS
> >>  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_STATIC_PCRE=1 
> >> USE_PCRE_JIT=1
> > 
> > Then I have no idea how other programs retrieve the information allowing
> > them to respect your system-global choices :-(
> 
> 
> The following patch fixes the problem for me:
> 
> --- standard.c.orig 2015-09-30 13:28:52.688425000 +0300
> +++ standard.c  2015-09-30 13:29:00.826968000 +0300
> @@ -599,7 +599,7 @@ static struct sockaddr_storage *str2ip(c
> memset(, 0, sizeof(hints));
> hints.ai_family = sa->ss_family ? sa->ss_family : AF_UNSPEC;
> hints.ai_socktype = SOCK_DGRAM;
> -   hints.ai_flags = AI_PASSIVE;
> +   hints.ai_flags = 0;
> hints.ai_protocol = 0;
>  
> if (getaddrinfo(str, NULL, , ) == 0) {
> 
> 
> 
> FreeBSD manual page for getaddrinfo() is uncertain how to treat AI_PASSIVE 
> when hostname parameter is non-NULL (and this parameter is always non-NULL in 
> standard.c:str2ip()).
> https://www.freebsd.org/cgi/man.cgi?query=getaddrinfo=3
> 
> On  Linux manual page explicitly states that "If node is not NULL, then the 
> AI_PASSIVE flag is ignored."
> 
> So this change should be harmless for Linux.
> 
> What do you think?

I think that you did a good job and that you're perfectly right. I even
checked on one of my older systems and the text was the same in 2008.

Could you please write a commit message describing the initial issue
and copying your analysis above so that we don't lose the elements.
Please tag it as a bug so that we backport it to 1.5 as well.

Cheers,
Willy

Re: Implementing HAProxy First Time: Conditional backend issue

[Susheel Jalali]

Dear Bryan and HAProxy Developers:

As requested, here is the complete haproxy config content.

The relevant error logs are below:

-- --

global
log 127.0.0.1 local2
log-tag haproxy
chroot  /var/haproxy/lib
pidfile  /var/run/haproxy.pid
user haproxy
group   haproxy
nbproc  1
maxconn   256
spread-checks  5
daemon
stats socket  /var/haproxy/stats

defaults
modehttp
log global
option  httplog
option  dontlognull
option  forwardfor
option  abortonclose
option  http-server-close
option  redispatch
retries 3
timeout queue   86400
timeout client  86400
timeout server  86400
timeout connect 86400
timeout http-keep-alive  30
timeout http-request  10
timeout check 20
maxconn 5

frontend webapps-frontend
bind  *:80

acl host_coscendreq.hdr(Host) coscend.com:80
acl path_subdomain_p1 path_beg -i /Product1

use_backend subdomain_p1-backend if host_coscend path_subdomain_p1

default_backend webapps-backend

backend webapps-backend
[ - - -]
option   http-server-close
server Product1.VM0 12.12.12.112:6012 cookie pad-p check

backend subdomain_p1-backend
http-request set-header Host 12.12.12.112:6012
reqirep ^([^\ :]*)\ /Product1/(.*) \1\ /\2
acl hdr_location res.hdr(Location) -m found
rspirep ^Location:\ (http?://12.12.12.112(:[0-9]+)?)?(/.*) 
Location:\ /Product1  if hdr_location

server Product1.VM0 12.12.12.112:6012 cookie pad-p check


admin.log
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-frontend started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-frontend started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-backend started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-backend started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy subdomain_p1-backend started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy HAProxy-stats started.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping frontend 
webapps-frontend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping frontend 
webapps-frontend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend 
webapps-backend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend 
webapps-backend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend 
subdomain_p1-backend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping proxy HAProxy-stats in 
0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-frontend stopped 
(FE: 4 conns, BE: 0 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-frontend stopped 
(FE: 4 conns, BE: 0 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-backend stopped 
(FE: 0 conns, BE: 1 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-backend stopped 
(FE: 0 conns, BE: 1 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy subdomain_p1-backend 
stopped (FE: 0 conns, BE: 1 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy HAProxy-stats stopped 
(FE: 26 conns, BE: 12 conns).


Info.log
Conditional backend
Sep 30 12:47:29 localhost haproxy[1691]: 192.168.100.153 - - "GET 
/CoscendPad HTTP/1.1" 404 262 "" "" 53639 804 "webapps-frontend" 
"subdomain_p1-backend" "Product1" 5 0 0 3 8  4 4 0 0 0 0 0 "" ""

Default backend:
Sep 30 12:47:29 localhost haproxy[1691]: 192.168.100.153 - - "GET 
/favicon.ico HTTP/1.1" 200 4603 "" "" 53639 813 "webapps-frontend" 
"webapps-backend" "Product1" 30 0 0 3 34  1 1 0 0 0 0 0 "" ""



Sincerely,

Susheel Jalali
Coscend Communications Solutions
susheel.jal...@coscend.com

Web site: www.Coscend.com
--
CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail 
Messages from Coscend Communications Solutions' posted at:

http://www.Coscend.com/Terms_and_Conditions.html

On 10/01/15 01:21, Bryan Talbot wrote:
On Wed, Sep 30, 2015 at 12:37 PM, Susheel Jalali 
> wrote:


Dear HAProxy Developers community:

After incorporating inputs from some of you, we tested with an
updated haproxy.cfg (see below).  Product-1 is still not accessible


Without the complete haproxy config and some logs, it was impossible 
for anyone to understand what issues you might be having. The question 
was just too vague.



Info.log
Conditional backend
Sep 30 09:12:44 localhost haproxy[1691]: 192.168.100.153 - - "GET
/CoscendPad HTTP/1.1" 404 262 "" "" 53639 804 "webapps-frontend"
"subdomain_p1-backend" "Product1" 5 0 0 3 8  4 4 0 0 0 0 0 "" ""


From the logs shown it looks like your "conditional" backend is 
returning a 404, but since the log format is not standard; without the 
haproxy config we can only guess at 

crimp BNC connector

[admin]

Contactmeformoreinformationabout BNCconnec=tors andothercompetitiveproducts.  
Whycooperatewithus? 
1Webelongtoastate-unitedpubliccompanywithab=igfactoryandastrongRDteam.Strongcapital,technologyandm=anagementbackgroundaretheguaranteeofreliablequality,fastdeliv=eryandcompetitiveprice.
 
2WeRDandproduceproductsbyourselves.Sowe=cancontrolthewholeprocessofeachproduct.Wecansatisfyyourre=quirementsbyadjustingRD,productionorothersteps.
 
3Wehavefullproductlinesforsurveillance.Nomat=terNVR/HVR/IPC,orAHDDVR/Camera,youalwayscanfindouttheproduc=tsyouwant.
 
4Strongtechnicalteamcanhelpyousolveallofyou=rproblemspre-salesandafter-sales.Aslongasyourequest,Weeven=willarrangesalesandtechniciantoyourcompany,helpyoutosolvea=llofyourtechnicianproblemsanddevelopyourmarket.
 
5Wearedevelopingoversea'smarketnow.Ourpricema=ybelowerthanourcostduringthisyear.Thelossisasforadvertisi=ngcost.Itisverydifficulforyoutocomeaccrosssuchagoodsuppl=ierduringsospecialperiod.
 Actatonce!Donotlosssogoodopportunity! 
BestRegards,CarolSkype:hongmei-technology 

Re: Implementing HAProxy First Time: Conditional backend issue

[Susheel Jalali]

Dear HAProxy Developers community:

After incorporating inputs from some of you, we tested with an updated 
haproxy.cfg (see below).  Product-1 is still not accessible via HAProxy 
(see logs below).  We would appreciate any insights to solve this issue.


___Haproxy.cfg file_

frontend webapps-frontend
bind  *:80

acl host_coscendreq.hdr(Host) coscend.com:80
acl path_subdomain_p1 path_beg -i /Product1

use_backend subdomain_p1-backend if host_coscend path_subdomain_p1

default_backend webapps-backend

backend webapps-backend
[…]

option   http-server-close
server Product1.VM0 12.12.12.112:6012 cookie pad-p check


backend subdomain_p1-backend
http-request set-header Host 12.12.12.112:6012
reqirep ^([^\ :]*)\ /Product1/(.*) \1\ /\2
acl hdr_location res.hdr(Location) -m found
rspirep ^Location:\ (http?://12.12.12.112(:[0-9]+)?)?(/.*) 
Location:\ /Product1  if hdr_location

server Product1.VM0 12.12.12.112:6012 cookie pad-p check


Info.log
Conditional backend
Sep 30 09:12:44 localhost haproxy[1691]: 192.168.100.153 - - "GET 
/CoscendPad HTTP/1.1" 404 262 "" "" 53639 804 "webapps-frontend" 
"subdomain_p1-backend" "Product1" 5 0 0 3 8  4 4 0 0 0 0 0 "" ""


Default backend:
Sep 30 09:12:44 localhost haproxy[1691]: 192.168.100.153 - - "GET 
/favicon.ico HTTP/1.1" 200 4603 "" "" 53639 813 "webapps-frontend" 
"webapps-backend" "Product1" 30 0 0 3 34  1 1 0 0 0 0 0 "" ""



Thank you.
-- --
Sincerely,

Susheel Jalali
Coscend Communications Solutions
susheel.jal...@coscend.com

Web site: www.Coscend.com
--
CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail 
Messages from Coscend Communications Solutions' posted at:

http://www.Coscend.com/Terms_and_Conditions.html


On 09/30/15 00:59, Susheel Jalali wrote:
>
> Dear HAProxy Developers,
>
> We are implementing HAProxy for reverse proxy load balancing for the 
first time in our LAN.  We are seeking your guidance below to optimize 
our HAProxy configuration.  Currently, we are unable to access our fully 
working products via HAProxy on two different servers.  We would 
appreciate any pointers to learn from so that we could solve this 
HAPRoxy conditional backend issue.

>
> Issue:  "Cannot get /Product1"
>
> We have working products (Product-1, 2, 3, …)  instances residing on 
2 servers hosted in internal LAN.  HAProxy is in DMZ. We are using the 
following haproxy.cfg template to configure access to our products 
behind HAProxy:
> · Live Product-1 can be accessed directly: 
http://Server_IP:Port#_of_Product1   or http://Coscend.com:Port#_of_Product1

> · HAProxy stats on Web browser show all working products are UP.
> · But we cannot access them via HAProxy by their names, 
Product1, Product2, ...


> Access URL of Product 1 via HAProxy reverse proxy: 
http://HAProxy_Server_IP:Port#_of_HAProxy/Product1 
orhttp://Coscend.com/Product1

>
> Test scenario created
> · Global and Default sections producing proper logs.
> · Product-1 is accessible via default backend of HAProxy.
> · Bypassing Local DNS issues by using server IP Address and 
product Port #s in haproxy.cfg.
> · Frontend is working and directing us to Product-1, as seen 
in the logs.

> · Product-1 is not accessible via conditional back end.
>
> -- --
>

> frontend webapps-frontend
> bind  *:80
> acl host_coscendreq.hdr(Host) coscend.com:80
> acl path_subdomain_p1 path_beg -i /Product1
> use_backend subdomain_p1-backend if host_coscend path_subdomain_p1
> default_backend webapps-backend
>
> backend webapps-backend
> [. . .]
> option   http-server-close
>
> backend subdomain_p1-backend
> http-request set-header Host 12.12.12.112:6012
> acl hdr_location res.hdr(Location) -m found
> rspirep ^Location:\ (http?://12.12.12.112(:[0-9]+)?)?(/.*) 
Location:\ /Product1  if hdr_location

> server Product1.VM0 12.12.12.112:6012 cookie pad-p check
> Thank you.
>

> Sincerely,
> --
>
> Susheel Jalali
>
>
> Coscend Communications Solutions
> Web site: www.Coscend.com
--
CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail 
Messages from Coscend Communications Solutions' posted at:

http://www.Coscend.com/Terms_and_Conditions.html

Re: Address selection policy in dual-stack environments

[Dmitry Sivachenko]

> On 29 сент. 2015 г., at 23:06, Willy Tarreau  wrote:
> 
> On Tue, Sep 29, 2015 at 10:59:15PM +0300, Dmitry Sivachenko wrote:
>>> I *think* that getaddrinfo() provides this. You can try to build by
>>> adding USE_GETADDRINFO=1 to your makefile. It's not enabled by default
>>> because there are numerous bogus implementations on various systems.
>>> If it works for you it could be the best solution as other programs
>>> which work are likely using it. I don't know if it's safe to enable
>>> it by default on FreeBSD.
>>> 
>> 
>> 
>> I do have this enabled:
>> 
>> Build options :
>>  TARGET  = freebsd
>>  CPU = generic
>>  CC  = cc
>>  CFLAGS  = -O2 -pipe -O2 -fno-strict-aliasing -pipe -fstack-protector 
>> -DFREEBSD_PORTS
>>  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_STATIC_PCRE=1 
>> USE_PCRE_JIT=1
> 
> Then I have no idea how other programs retrieve the information allowing
> them to respect your system-global choices :-(


The following patch fixes the problem for me:

--- standard.c.orig 2015-09-30 13:28:52.688425000 +0300
+++ standard.c  2015-09-30 13:29:00.826968000 +0300
@@ -599,7 +599,7 @@ static struct sockaddr_storage *str2ip(c
memset(, 0, sizeof(hints));
hints.ai_family = sa->ss_family ? sa->ss_family : AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
-   hints.ai_flags = AI_PASSIVE;
+   hints.ai_flags = 0;
hints.ai_protocol = 0;
 
if (getaddrinfo(str, NULL, , ) == 0) {



FreeBSD manual page for getaddrinfo() is uncertain how to treat AI_PASSIVE when 
hostname parameter is non-NULL (and this parameter is always non-NULL in 
standard.c:str2ip()).
https://www.freebsd.org/cgi/man.cgi?query=getaddrinfo=3

On  Linux manual page explicitly states that "If node is not NULL, then the 
AI_PASSIVE flag is ignored."

So this change should be harmless for Linux.

What do you think?

LUA

[Kobus Bensch]

Hi

I have been seeing a lot of LUA posts and wanted to read up on it. Is 
this the right site: http://www.lua.org/


I am aware of the API docs at 
http://www.arpalert.org/src/haproxy-lua-api/1.6dev/index.html, but 
wanted to read a bit more and Google returned a rather long list of 
potential sites.


Apologies if this is a bit of a dumb question, but I did not want to go 
read something just to find out later that it is completely the wrong stuff.


Thank you

Kobus
--
Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
Senior Systems Administrator
Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
DDI:  0207 871 3958
Tel:  0207 871 3890
Email: kobus.ben...@trustpayglobal.com 



--


Trustpay Global Limited is an authorised Electronic Money Institution 
regulated by the Financial Conduct Authority registration number 900043. 
Company No 07427913 Registered in England and Wales with registered address 
130 Wood Street, London, EC2V 6DL, United Kingdom.


For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and 
remain the property of Trustpay Global Ltd unless agreed by contract. It is 
intended solely for the person to whom or the entity to which it is 
addressed. If you are not the intended recipient you may not use, disclose, 
copy, distribute, print or rely on the content of this email or its 
attachments. If this email has been received by you in error please advise 
the sender and delete the email from your system. Trustpay Global Ltd does 
not accept any liability for any personal view expressed in this message.

Re: haproxy 1.5.4 with ssl-bridging

[Janusz Dziemidowicz]

2015-09-29 21:36 GMT+02:00 Douglas Harmon :
> Hello group. I'm new to haproxy. I have read the documentation but
> still require some assistance. I'm trying to configure haproxy to:
>
> 1. accept https connection with client certs required.
> 2. pass the client cert to a backend https server based on https url path
>
> First, can I accomplish this with haproxy? If so, could someone share
> a sample haproxy 1.5 configuration? I have the item 1 above working in
> tcp mode. But I believe I need to be in http mode to get item 2 to
> work.

This is not possible. This is not a haproxy limitation, this is
impossible to do with SSL as you effectively are trying to perform a
man-in-the-middle attack and SSL is designed to prevent exactly that.

You can either:
1. require client SSL cert on haproxy and decrypt traffic to see URL,
but you cannot "forward" client certificate to the backend
2. configure haproxy in TCP mode and forward encrypted traffic to the
backend, but you cannot se the URL

You cannot have both, SSL protocol does not allow such operation.

What you can do, which is usually what people want is to implement 1
and set custom HTTP header with client certificate details (search
haproxy documentation for X-SSL-Client-CN for example). Your backend
will not see client certificate in a SSL handshake, but can access the
header for certificate information.

-- 
Janusz Dziemidowicz

Re: LUA

[Kobus Bensch]

Ignore this, I found what I was looking for.

On 30/09/2015 10:16, Kobus Bensch wrote:

Hi

I have been seeing a lot of LUA posts and wanted to read up on it. Is 
this the right site: http://www.lua.org/


I am aware of the API docs at 
http://www.arpalert.org/src/haproxy-lua-api/1.6dev/index.html, but 
wanted to read a bit more and Google returned a rather long list of 
potential sites.


Apologies if this is a bit of a dumb question, but I did not want to 
go read something just to find out later that it is completely the 
wrong stuff.


Thank you

Kobus
--
Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
Senior Systems Administrator
Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
DDI:  0207 871 3958
Tel:  0207 871 3890
Email: kobus.ben...@trustpayglobal.com 



--
Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
Senior Systems Administrator
Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
DDI:  0207 871 3958
Tel:  0207 871 3890
Email: kobus.ben...@trustpayglobal.com 



--


Trustpay Global Limited is an authorised Electronic Money Institution 
regulated by the Financial Conduct Authority registration number 900043. 
Company No 07427913 Registered in England and Wales with registered address 
130 Wood Street, London, EC2V 6DL, United Kingdom.


For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and 
remain the property of Trustpay Global Ltd unless agreed by contract. It is 
intended solely for the person to whom or the entity to which it is 
addressed. If you are not the intended recipient you may not use, disclose, 
copy, distribute, print or rely on the content of this email or its 
attachments. If this email has been received by you in error please advise 
the sender and delete the email from your system. Trustpay Global Ltd does 
not accept any liability for any personal view expressed in this message.

Re: Linux or FreeBSD ?

[Kobus Bensch]

I dont think it matters really. I would respond with, if it ain't broke...

On 30/09/2015 14:05, Arnall wrote:

Hi Eveyone,

just a simple question, is FreeBSD a good choice for Haproxy ?
Our Haproxy runs under Debian for years, but the new IT want to put it 
under FreeBSD.

Any cons ?

Thanks.



--
Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
Senior Systems Administrator
Address:  22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
DDI:  0207 871 3958
Tel:  0207 871 3890
Email: kobus.ben...@trustpayglobal.com 



--


Trustpay Global Limited is an authorised Electronic Money Institution 
regulated by the Financial Conduct Authority registration number 900043. 
Company No 07427913 Registered in England and Wales with registered address 
130 Wood Street, London, EC2V 6DL, United Kingdom.


For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and 
remain the property of Trustpay Global Ltd unless agreed by contract. It is 
intended solely for the person to whom or the entity to which it is 
addressed. If you are not the intended recipient you may not use, disclose, 
copy, distribute, print or rely on the content of this email or its 
attachments. If this email has been received by you in error please advise 
the sender and delete the email from your system. Trustpay Global Ltd does 
not accept any liability for any personal view expressed in this message.

Linux or FreeBSD ?

[Arnall]

Hi Eveyone,

just a simple question, is FreeBSD a good choice for Haproxy ?
Our Haproxy runs under Debian for years, but the new IT want to put it 
under FreeBSD.

Any cons ?

Thanks.

Re: Linux or FreeBSD ?

[Dmitry Sivachenko]

> On 30 сент. 2015 г., at 16:05, Arnall  wrote:
> 
> Hi Eveyone,
> 
> just a simple question, is FreeBSD a good choice for Haproxy ?
> Our Haproxy runs under Debian for years, but the new IT want to put it under 
> FreeBSD.
> Any cons ?
> 
> Thanks.
> 



Should be roughly the same I think.

Re: Implementing HAProxy First Time: Conditional backend issue

[Bryan Talbot]

On Wed, Sep 30, 2015 at 1:27 PM, Susheel Jalali 
wrote:

> Dear Bryan and HAProxy Developers:
>
> As requested, here is the complete haproxy config content.
>
> The relevant error logs are below:
>
> -- --
> global
> log 127.0.0.1 local2
> log-tag haproxy
> chroot  /var/haproxy/lib
> pidfile  /var/run/haproxy.pid
> user haproxy
> group   haproxy
> nbproc  1
> maxconn   256
> spread-checks  5
> daemon
> stats socket  /var/haproxy/stats
>


The above seems normal but maxconn=256 is pretty low but maybe that's
appropriate for your apps.



>
> defaults
> modehttp
> log global
> option  httplog
>

The logs you show below do not conform to this 'httplog' format and seem to
be a modified CLF, so I don't know for sure what values are in the logs
below.




> option  dontlognull
>

When debugging problems, should probably log as much as you can and then
decide what logs to hide when everything is working.



> option  forwardfor
> option  abortonclose
> option  http-server-close
> option  redispatch
> retries 3
>

All seem normal


> timeout queue   86400
> timeout client  86400
> timeout server  86400
> timeout connect 86400
> timeout http-keep-alive  30
> timeout http-request  10
> timeout check 20
> maxconn 5
>

Default time values are in milliseconds so http-request must be completed
in 10 ms. This might work fine on a LAN but will be an issue on a WAN or
internet. I'm guessing that you assumed that time units default to seconds
instead of milliseconds? If so, then these values are still a problem but
then some will be way too long -- do you really want requests to queue and
to wait to connect to a backend server for a full day (86,400 seconds / 24
hours)?




>
>
> frontend webapps-frontend
> bind  *:80
>
> acl host_coscendreq.hdr(Host) coscend.com:80
>

This will only match if the Host header value includes the port which is
uncommon especially for port :80



>
> acl path_subdomain_p1 path_beg -i /Product1
>
> use_backend subdomain_p1-backend if host_coscend path_subdomain_p1
>
> default_backend webapps-backend
>
> backend webapps-backend
> [ - - -]
> option   http-server-close
> server Product1.VM0 12.12.12.112:6012 cookie pad-p check
>

server is named "Product1.VM0" here but appears in logs below as "Product1"
which leads me to believe that this config is not used to produce the logs.



>
> backend subdomain_p1-backend
> http-request set-header Host 12.12.12.112:6012
> reqirep ^([^\ :]*)\ /Product1/(.*) \1\ /\2
> acl hdr_location res.hdr(Location) -m found
> rspirep ^Location:\ (http?://12.12.12.112(:[0-9]+)?)?(/.*) Location:\
> /Product1  if hdr_location
> server Product1.VM0 12.12.12.112:6012 cookie pad-p check
>
>
server is named "Product1.VM0" here but appears in logs below as "Product1"
which leads me to believe that this config is not used to produce the logs.



>
> admin.log
> Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-frontend started.
> Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-frontend started.
> Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-backend started.
> Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-backend started.
> Sep 30 12:42:29 localhost haproxy[1691]: Proxy subdomain_p1-backend
> started.
> Sep 30 12:42:29 localhost haproxy[1691]: Proxy HAProxy-stats started.
> Sep 30 12:47:29 localhost haproxy[5690]: Stopping frontend
> webapps-frontend in 0 ms.
> Sep 30 12:47:29 localhost haproxy[5690]: Stopping frontend
> webapps-frontend in 0 ms.
> Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend webapps-backend
> in 0 ms.
> Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend webapps-backend
> in 0 ms.
> Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend
> subdomain_p1-backend in 0 ms.
> Sep 30 12:47:29 localhost haproxy[5690]: Stopping proxy HAProxy-stats in 0
> ms.
> Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-frontend stopped
> (FE: 4 conns, BE: 0 conns).
> Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-frontend stopped
> (FE: 4 conns, BE: 0 conns).
> Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-backend stopped
> (FE: 0 conns, BE: 1 conns).
> Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-backend stopped
> (FE: 0 conns, BE: 1 conns).
> Sep 30 12:47:29 localhost haproxy[5690]: Proxy subdomain_p1-backend
> stopped (FE: 0 conns, BE: 1 conns).
> Sep 30 12:47:29 localhost haproxy[5690]: Proxy HAProxy-stats stopped (FE:
> 26 conns, BE: 12 conns).
>
>

Why are proxy frontends repeated twice in the above log but backends (and
other entries) just once? Did you produce this output with a config
different from what you provided above too?

Re: Converting from sticking on src-ip to custom auth header

[Igor Cicimov]

The stick-table type would be string and not ip in that case though
On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
wrote:
>
> We've been seeing CenturyLink and a few other residential providers
NATing their IPv4 traffic, making client persistency on source IP result in
really lopsided load balancing lately.
>
> We'd like to convert to sticking on a custom header we're already using
that IDs the user. There isn't a lot of examples of this, so I was curious
if this is the right approach:
>
> Previous "stick on src" config:
https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>
> New "stick on header" config:
https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>
> Thank you in advance for any advice.
>
> -J

The stick-table type would be string and not ip in that case though

Re: Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

Wondered about that... Do the "tcp-request" rate limiters use the stick
table (I assume they need type ip) or another implied table?

-J

On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

> The stick-table type would be string and not ip in that case though
>
> On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
> wrote:
> >
> > We've been seeing CenturyLink and a few other residential providers
> NATing their IPv4 traffic, making client persistency on source IP result in
> really lopsided load balancing lately.
> >
> > We'd like to convert to sticking on a custom header we're already using
> that IDs the user. There isn't a lot of examples of this, so I was curious
> if this is the right approach:
> >
> > Previous "stick on src" config:
> https://gist.github.com/williamsjj/7c3876d32cab627ffe70
> >
> > New "stick on header" config:
> https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
> >
> > Thank you in advance for any advice.
> >
> > -J
>
> The stick-table type would be string and not ip in that case though
>

Re: Linux or FreeBSD ?

[Willy Tarreau]

On Wed, Sep 30, 2015 at 09:03:48PM +0200, Rainer Duffner wrote:
> 
> > Am 30.09.2015 um 16:25 schrieb Jeff Palmer :
> > 
> > Arnall,
> > 
> > 
> > This advice is less of an haproxy specific response, and more of
> > general information.
> > 
> > As someone who's tried to manage mixed infrastructure, I would push
> > back if possible, unles syour organization has decided to move to
> > freebsd entirely.
> > 
> 
> 
> Very few do that.
> FreeBSD fulfills its purposes, though.
> Even if you try to standardize on one ???flavor??? of Linux, you will still 
> end up with other flavors - simply because not everything runs on your 
> particular flavor.
> And you???re not going to run all of your applications on all of your 
> platforms anyway. So the QA-effort should be manageable.
> But that doesn???t mean it???s wise to introduce a half dozen different 
> platforms, either - unless you have enough people to handle all of it.
> 
> How many systems (with Debian) are we talking about anyway?
> And how many HA-Proxies are supposed to be migrated?
> 
> What are the sysadmin???s technical points for moving?
> Besides probably not wanting to deal with Debian???s head-ache-inducing idea 
> of an OS - that???s a given ;-)
> 
> Unless OP is doing some *really fancy stuff*, there???s IMO no pure technical
> show-stopper for a switch.

I'd be tempted to place my judgement between yours and Jeff's. I'd say
that if the company is already using the target OS on any other place,
the cost of switching is low. If the load balancer is the opportunity
to introduce a new OS, it's a bad idea. By nature a load balancer is
very OS-dependant, and has bugs. Sometimes it's not trivial to tell
if a bug is in haproxy or the underlying OS until you get network
traces and/or strace output (BTW as far as I know, strace still doesn't
support amd64 on FreeBSD). Mixing the two can cast a bad image on the
new OS just because admins will initially not know well how to tune it
for the load and to ensure stability, will not easily troubleshoot
tricky issues, and a lot of frustration will result from this.

You should expect roughly the same performance on both OS so that is
not a consideration for switching or not switching. Really keep in
mind the admin cost, the cost of it being the exception in all your
system and possibly different debugging tools. It's very likely that
it will not be a problem, but better be aware of this.

Willy

Re: Linux or FreeBSD ?

[Rainer Duffner]

> Am 01.10.2015 um 01:22 schrieb Willy Tarreau :
> 
>> 
> 
> I'd be tempted to place my judgement between yours and Jeff's. I'd say
> that if the company is already using the target OS on any other place,
> the cost of switching is low. If the load balancer is the opportunity
> to introduce a new OS, it's a bad idea. By nature a load balancer is
> very OS-dependant, and has bugs. Sometimes it's not trivial to tell
> if a bug is in haproxy or the underlying OS until you get network
> traces and/or strace output (BTW as far as I know, strace still doesn't
> support amd64 on FreeBSD). Mixing the two can cast a bad image on the
> new OS just because admins will initially not know well how to tune it
> for the load and to ensure stability, will not easily troubleshoot
> tricky issues, and a lot of frustration will result from this.
> 



Probably.
But OP’s admin will have his reasons for wanting FreeBSD in the picture.
My guess would be that FreeBSD is the OS he’s more familiar with debugging.
FreeBSD has ktrace - and dtrace (if you know how to use it, that is…)

Here, most of our LBs run HAproxy on FreeBSD.
Sometimes, they’re not. Because…reasons ;-)

Why?
Well, historically, most LBs and reverse-proxies ran FreeBSD (with NGINX).
So it was more or less a „natural“ choice, with some pushing from my side 
(cough).

FreeBSD has CARP.
Linux has keepalived.
etc.

I don’t think we’ll ever get so much traffic that either one will be superior 
to the other. And I seriously doubt OP will.

FreeBSD 10.1 has most of the optimizations that Netflix uses turned-on out of 
the box - but they do file-serving with NGINX.
In their (extreme) case, it works better.
Proxying/load-balancing is a bit different.

I like FreeBSD because I can get a very stable, simple, low overhead, 
no-nonsense OS with a reasonable shelf-live and update-cycle while still being 
able to get up-to-date packages directly from upstream.


> You should expect roughly the same performance on both OS so that is
> not a consideration for switching or not switching. Really keep in
> mind the admin cost, the cost of it being the exception in all your
> system and possibly different debugging tools. It's very likely that
> it will not be a problem, but better be aware of this.
> 


That’s what you get by hiring a FreeBSD guy.
If OP had hired a CentOS guy, I bet he'd want to switch everything to CentOS 
(or even Atomic Server…)
;-)

Re: Converting from sticking on src-ip to custom auth header

[Igor Cicimov]

Well in case of header you would have something like this I guess:

tcp-request content track-sc1 hdr(x-app-authorization)



On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams <
jasonjwwilli...@gmail.com> wrote:

> Wondered about that... Do the "tcp-request" rate limiters use the stick
> table (I assume they need type ip) or another implied table?
>
> -J
>
> On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
> ig...@encompasscorporation.com> wrote:
>
>> The stick-table type would be string and not ip in that case though
>>
>> On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
>> wrote:
>> >
>> > We've been seeing CenturyLink and a few other residential providers
>> NATing their IPv4 traffic, making client persistency on source IP result in
>> really lopsided load balancing lately.
>> >
>> > We'd like to convert to sticking on a custom header we're already using
>> that IDs the user. There isn't a lot of examples of this, so I was curious
>> if this is the right approach:
>> >
>> > Previous "stick on src" config:
>> https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>> >
>> > New "stick on header" config:
>> https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>> >
>> > Thank you in advance for any advice.
>> >
>> > -J
>>
>> The stick-table type would be string and not ip in that case though
>>
>
>


-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000

Re: Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

I still would like to keep the rate limiting based on source ip but the 
persistence based on header. 

My thought was to create a second named stick table but I didn't see a name 
parameter to the stick-table declaration. 

Sent via iPhone

> On Sep 30, 2015, at 18:23, Igor Cicimov  
> wrote:
> 
> Well in case of header you would have something like this I guess:
> 
> tcp-request content track-sc1 hdr(x-app-authorization)
> 
> 
> 
>> On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams 
>>  wrote:
>> Wondered about that... Do the "tcp-request" rate limiters use the stick 
>> table (I assume they need type ip) or another implied table?
>> 
>> -J
>> 
>>> On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov 
>>>  wrote:
>>> The stick-table type would be string and not ip in that case though
>>> 
>>> 
>>> On 01/10/2015 5:07 AM, "Jason J. W. Williams"  
>>> wrote:
>>> >
>>> > We've been seeing CenturyLink and a few other residential providers 
>>> > NATing their IPv4 traffic, making client persistency on source IP result 
>>> > in really lopsided load balancing lately.
>>> >
>>> > We'd like to convert to sticking on a custom header we're already using 
>>> > that IDs the user. There isn't a lot of examples of this, so I was 
>>> > curious if this is the right approach:
>>> >
>>> > Previous "stick on src" config: 
>>> > https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>>> >
>>> > New "stick on header" config: 
>>> > https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>>> >
>>> > Thank you in advance for any advice.
>>> >
>>> > -J
>>> The stick-table type would be string and not ip in that case though
>>> 
> 
> 
> 
> -- 
> Igor Cicimov | DevOps
> 
> 
> 
> p. +61 (0) 433 078 728
> e. ig...@encompasscorporation.com
> w. encompasscorporation.com
> a. Level 4, 65 York Street, Sydney 2000

Re: Linux or FreeBSD ?

[Jeff Palmer]

Arnall,


This advice is less of an haproxy specific response, and more of
general information.

As someone who's tried to manage mixed infrastructure, I would push
back if possible, unles syour organization has decided to move to
freebsd entirely.

Having more than one OS to maintain means writing all of your
management scripts,  configurations, etc at least once per OS flavor
(worse if you have different major versions of OS's too)   subscribing
to double the security mailing lists,  doubling up your lab and QA
environments,  etc.


I would try to stick with whatever OS the bulk of your infrastructure
runs on, unless your team has made the concious effort to move to
another OS en-masse.


(That said,  you may want to look at the dev mailing list the last
month or so, about freebsd specific issues and patches.  there have
been a couple in the last couple of weeks.)




On Wed, Sep 30, 2015 at 9:23 AM, Dmitry Sivachenko  wrote:
>
>> On 30 сент. 2015 г., at 16:05, Arnall  wrote:
>>
>> Hi Eveyone,
>>
>> just a simple question, is FreeBSD a good choice for Haproxy ?
>> Our Haproxy runs under Debian for years, but the new IT want to put it under 
>> FreeBSD.
>> Any cons ?
>>
>> Thanks.
>>
>
>
>
> Should be roughly the same I think.



-- 
Jeff Palmer
https://PalmerIT.net