Re: [PATCH] CONTRIB: log: emit warning when -sf/-sd cannot parse argument

[Willy Tarreau]

Hi Chris,

On Wed, Jan 24, 2018 at 10:07:03PM +, Christopher Lane wrote:
> Ping; this is a safe change to wanr about a confusing source of error when
> you don't quote the arguments to haproxy in a "soft reloading new config a
> lot" type of environment.
> 
> On Thu, Dec 7, 2017 at 1:17 PM Chris Lane  wrote:
> 
> >
> > Previously, -sf and -sd command line parsing used atol which cannot
> > detect errors.  I had a problem where I was doing -sf "$pid1 $pid2 $pid"
> > and it was sending the gracefully terminate signal only to the first pid.
> > The change uses strtol and checks endptr and errno to see if the parsing
> > worked.  It doesn't exit so as not to cause failures but will allow
> > trouble-shooting
> > to be faster.

I don't know much what to think about such a change to be honnest. What
valid use case do you have for passing multiple processes as a single
argument after -sf instead of passing a normal list of arguments ?

I suspect you're running a script doing :

 haproxy ... -sf "${pid[*]}"

instead of doing :

 haproxy ... -sf "${pid[@]}"

or :

 haproxy ... -sf ${pid[*]}

Am I wrong ?
Willy

Re: Alpn in debian/ubuntu ppa 1.8

[Willy Tarreau]

On Fri, Jan 26, 2018 at 01:26:35AM +1100, Igor Cicimov wrote:
> Or you meant using the haproxy 16.04 image actually. Ok, another option is
> to compile it myself with the openssl version I have atm.

What mostly matters is the version used to *build* haproxy, because
some features have to be known at build time. If you pick an haproxy
package made for a more recent distro using 1.0.2 or later, it will
enable ALPN. Whether or not it will work on your current distro with
your locally rebuilt openssl is a big question of course.

You should definitely avoid building openssl yourself, it's the best
way to forget about upgrading it when a vulnerability is disclosed.
However if you're already doing it for other reasons it's different
and then maybe you can build your own haproxy with this openssl
version. But as Lukas said, the easiest solution is to upgrade the
distro :-)

Willy

Re: Alpn in debian/ubuntu ppa 1.8

[Igor Cicimov]

Hi Willy,

On Fri, Jan 26, 2018 at 3:47 PM, Willy Tarreau  wrote:

> On Fri, Jan 26, 2018 at 01:26:35AM +1100, Igor Cicimov wrote:
> > Or you meant using the haproxy 16.04 image actually. Ok, another option
> is
> > to compile it myself with the openssl version I have atm.
>
> What mostly matters is the version used to *build* haproxy, because
> some features have to be known at build time. If you pick an haproxy
> package made for a more recent distro using 1.0.2 or later, it will
> enable ALPN. Whether or not it will work on your current distro with
> your locally rebuilt openssl is a big question of course.
>
> You should definitely avoid building openssl yourself, it's the best
> way to forget about upgrading it when a vulnerability is disclosed.
> However if you're already doing it for other reasons it's different
> and then maybe you can build your own haproxy with this openssl
> version. But as Lukas said, the easiest solution is to upgrade the
> distro :-)
>
> Willy
>


​So that's actually what my initial question was aiming at. While building
the deb archive for ubuntu trusty lets say doesn't it make sense to build
it using ​the latest stable openssl 1.0.2 just for the sake of the
features?

Re: Alpn in debian/ubuntu ppa 1.8

[Willy Tarreau]

Hi Igor,

On Fri, Jan 26, 2018 at 05:07:10PM +1100, Igor Cicimov wrote:
> Hi Willy,
> 
> On Fri, Jan 26, 2018 at 3:47 PM, Willy Tarreau  wrote:
> 
> > On Fri, Jan 26, 2018 at 01:26:35AM +1100, Igor Cicimov wrote:
> > > Or you meant using the haproxy 16.04 image actually. Ok, another option
> > is
> > > to compile it myself with the openssl version I have atm.
> >
> > What mostly matters is the version used to *build* haproxy, because
> > some features have to be known at build time. If you pick an haproxy
> > package made for a more recent distro using 1.0.2 or later, it will
> > enable ALPN. Whether or not it will work on your current distro with
> > your locally rebuilt openssl is a big question of course.
> >
> > You should definitely avoid building openssl yourself, it's the best
> > way to forget about upgrading it when a vulnerability is disclosed.
> > However if you're already doing it for other reasons it's different
> > and then maybe you can build your own haproxy with this openssl
> > version. But as Lukas said, the easiest solution is to upgrade the
> > distro :-)
> >
> > Willy
> >
> 
> 
> So that's actually what my initial question was aiming at. While building
> the deb archive for ubuntu trusty lets say doesn't it make sense to build
> it using the latest stable openssl 1.0.2 just for the sake of the
> features?

I don't know what version ships in standard with this distro, but it makes
sense to me that the packages that are built for a distro work with the
distro's default package versions and do not require some hacks by the
user. So if the distro uses 1.0.2 by default it would make sense. If it
uses 1.0.1, it wouldn't make sense to add an extra dependency on an
external, possibly less maintained, package. But that's just my opinion,
I'm not a distro packager. However that's the type of issues we've had to
deal with in our enterprise version since users expect the packages to work
by default and a few advanced users also want the best features which are
unfortunately not compatible with the default distro :-/ And recently we've
seen a progress in the right direction (eg with RHEL 7.4 IIRC) though that
breaks again the compatibility with users of older packages!

I really think that the whole mess around this is caused by the fact that
H2 requires ALPN which was not present in the openssl version shipped with
most distros when it was released, and that the lack of visibility of any
future long term supported openssl version doesn't encourage distro vendors
to provide large scale upgrades.

Willy

Re: Alpn in debian/ubuntu ppa 1.8

[Igor Cicimov]

Hi Willy,

On Fri, Jan 26, 2018 at 6:21 PM, Willy Tarreau  wrote:

> Hi Igor,
>
> On Fri, Jan 26, 2018 at 05:07:10PM +1100, Igor Cicimov wrote:
> > Hi Willy,
> >
> > On Fri, Jan 26, 2018 at 3:47 PM, Willy Tarreau  wrote:
> >
> > > On Fri, Jan 26, 2018 at 01:26:35AM +1100, Igor Cicimov wrote:
> > > > Or you meant using the haproxy 16.04 image actually. Ok, another
> option
> > > is
> > > > to compile it myself with the openssl version I have atm.
> > >
> > > What mostly matters is the version used to *build* haproxy, because
> > > some features have to be known at build time. If you pick an haproxy
> > > package made for a more recent distro using 1.0.2 or later, it will
> > > enable ALPN. Whether or not it will work on your current distro with
> > > your locally rebuilt openssl is a big question of course.
> > >
> > > You should definitely avoid building openssl yourself, it's the best
> > > way to forget about upgrading it when a vulnerability is disclosed.
> > > However if you're already doing it for other reasons it's different
> > > and then maybe you can build your own haproxy with this openssl
> > > version. But as Lukas said, the easiest solution is to upgrade the
> > > distro :-)
> > >
> > > Willy
> > >
> >
> >
> > So that's actually what my initial question was aiming at. While building
> > the deb archive for ubuntu trusty lets say doesn't it make sense to build
> > it using the latest stable openssl 1.0.2 just for the sake of the
> > features?
>
> I don't know what version ships in standard with this distro, but it makes
> sense to me that the packages that are built for a distro work with the
> distro's default package versions and do not require some hacks by the
> user. So if the distro uses 1.0.2 by default it would make sense. If it
> uses 1.0.1, it wouldn't make sense to add an extra dependency on an
> external, possibly less maintained, package. But that's just my opinion,
> I'm not a distro packager. However that's the type of issues we've had to
> deal with in our enterprise version since users expect the packages to work
> by default and a few advanced users also want the best features which are
> unfortunately not compatible with the default distro :-/ And recently we've
> seen a progress in the right direction (eg with RHEL 7.4 IIRC) though that
> breaks again the compatibility with users of older packages!
>
> I really think that the whole mess around this is caused by the fact that
> H2 requires ALPN which was not present in the openssl version shipped with
> most distros when it was released, and that the lack of visibility of any
> future long term supported openssl version doesn't encourage distro vendors
> to provide large scale upgrades.
>
> Willy
>

​Yeah you are absolutely right here please scrap my previous comment which
totally doesn't make any sense :-( I guess it is more showing my
frustration with exactly what you described in the last paragraph.

HAproxy ( + UCARP ) in an Active / Passive setup

[TomK]

Hey All,

We have UCARP and HAproxy configured and setup between two servers. 
HAproxy is bound to the UCARP VIP between the nodes. There are four 
services per hoer: four on SRV1 (primary) and same four apps on SRV2 
(secondary)  We need active / passive behavior, since apps don't support 
an active / active config.   We have one UCARP VIP for each application.


SRV1 primary
SRV2 secondary

We need all four VIP's and HAproxy processes to failover to the standby if:

1) One of the four processes on the primary fails.
2) Primary host fails ( This piece is easier. )

When all fail over to the standby, we need them capable of failover back 
if the secondary (standby) fails in the future.


We can't seem to have all of them stick on the standby (now primary) 
when the primary comes back up or even when the one failed service comes 
back on SRV1 (former primary).


They end up flipping back and we end up in a situation where some of the 
traffic goes to SRV1 and some to SRV2.


We tried the:

stick-table type ip size 1 nopurge peers LB
stick on dst

As well as rise 999

but those eventually fail over.  Wanted to know what is the best 
practice in this case?



Second question we have is how to split up HAproxy processes into 
separate start and stop scripts?  Currently we stop and start using only 
the main restart script /etc/init.d/haproxy but that stops all or starts 
all.  Has anyone split these up into separate start stop scripts to 
control individual HAproxy instances?  In other environments we find 
that they start multiple copies of the same HAproxy definition.  We need 
better fine grained control of each one.


--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.

Re: [PATCH v5 0/8] Add IPv6 support to the ipmask converter

[Willy Tarreau]

Hi Tim,

On Thu, Jan 25, 2018 at 04:24:43PM +0100, Tim Duesterhus wrote:
> Willy,
> 
> okay. I added Jarno to the commit message of the actual changes
> to the ipmask converter. I did not clean up the tags, you know
> best which ones you wanted to change. If Jarno complains about
> his name being in there, before you get the change to apply please
> edit him out, as you need to modify the messages anyway.

Wonderful, now applied, thanks very much.

> Attached comes the complete series (v5). Again: Be extra careful
> with the first patch, because it contains 8bit characters.

Yes, thank you for the reminder. Just checked and it's OK.

Cheers,
Willy

[PATCH v5 4/8] DOC: Fix typo in ARGT_MSK6 comment

[Tim Duesterhus]

The incorrect comment was introduced in commit:
2ac5718dbd4ec722ece228e9f613d2be74eee9da

v1.5-dev9 is the first tag containing this comment, the fix
should be backported to haproxy 1.5 and newer.
---
 include/types/arg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/types/arg.h b/include/types/arg.h
index 651164b2d..c3b09deff 100644
--- a/include/types/arg.h
+++ b/include/types/arg.h
@@ -49,7 +49,7 @@ enum {
ARGT_IPV4, /* an IPv4 address */
ARGT_MSK4, /* an IPv4 address mask (integer or dotted), stored as 
ARGT_IPV4 */
ARGT_IPV6, /* an IPv6 address */
-   ARGT_MSK6, /* an IPv6 address mask (integer or dotted), stored as 
ARGT_IPV4 */
+   ARGT_MSK6, /* an IPv6 address mask (integer or dotted), stored as 
ARGT_IPV6 */
ARGT_TIME, /* a delay in ms by default, stored as ARGT_UINT */
ARGT_SIZE, /* a size in bytes by default, stored as ARGT_UINT */
ARGT_FE,   /* a pointer to a frontend only */
-- 
2.15.1

[PATCH v5 2/8] DOC: sample: Fix outdated comment about sample casts functions

[Tim Duesterhus]

The cast functions modify their output type as of commit:
b805f71d1bb1487f01f78a6ffab26d44919e9944

v1.5-dev20 is the first tag containing this comment, the fix
should be backported to haproxy 1.5 and newer.
---
 src/sample.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/sample.c b/src/sample.c
index d3aa88935..115288539 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -496,8 +496,6 @@ struct sample_conv *find_sample_conv(const char *kw, int 
len)
 
 /**/
 /*  Sample casts functions*/
-/*   Note: these functions do *NOT* set the output type on the*/
-/*   sample, the caller is responsible for doing this on return.  */
 /**/
 
 static int c_ip2int(struct sample *smp)
-- 
2.15.1

Re: How can I map bindings to the correct backend?

[Pieter Vogelaar]

Hi Jonathan,

Thanks for your suggestion. Yes that would also be clean enough, thanks!
Just out of curiosity, would some form of concatenation of samples be possible?

Best regards,
Pieter Vogelaar

Van: Jonathan Matthews 
Datum: donderdag 25 januari 2018 om 16:17
Aan: Pieter Vogelaar , haproxy 
Onderwerp: Re: How can I map bindings to the correct backend?

Unless I'm missing something, wouldn't you be rather better off just having a 
dedicated frontend for each set of ports that forwards to each distinct backend 
server?

Or are you doing this at webscale, or something? :-)

J
--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: How can I map bindings to the correct backend?

[Pieter Vogelaar]

It’s TCP layer 4 load balancing, so the HTTP hdr(host) won’t work.


Best regards,
Pieter Vogelaar

Van: Igor Cicimov 
Datum: donderdag 25 januari 2018 om 16:33
Aan: Pieter Vogelaar 
CC: "haproxy@formilux.org" 
Onderwerp: Re: How can I map bindings to the correct backend?

Hi Pieter,

On Thu, Jan 25, 2018 at 3:15 AM, Pieter Vogelaar 
> wrote:
I have the following configuration:


frontend default-tcp
  bind 192.168.52.12:5044
  bind 192.168.52.12:
  bind 192.168.52.12:5556
  bind 192.168.52.12:5672
  bind 192.168.52.13:5672
  mode tcp
  option tcplog
  use_backend %[dst_port,map(/etc/haproxy/tcp-bindings-to-backends.map,default)]


The map file (/etc/haproxy/tcp-bindings-to-backends.map) looks like:


192.168.52.12:5044 logging-logstashmsg-acc
192.168.52.12: logging-logstashmsg-acc
192.168.52.12:5556 logging-logstashmsg-acc
192.168.52.12:5672 logging-rabbitmq-acc
192.168.52.13:5672 stackstorm-rabbitmq-tst


I would like to route based on the IP address and port to the correct backend. 
At the moment I used the dst_port sample on the use_backend line. But that must 
be a concatenation of dst sample, “:” and dst_port sample.
It seems like a basic thing to do, but I just can’t figure out how to do this.


​How​ do you access the frontend? If via ip:port instead of dns than I guess 
the ip:port combo will already be present in the hdr(host).

Re: How can I map bindings to the correct backend?

[Jonathan Matthews]

Unless I'm missing something, wouldn't you be rather better off just having
a dedicated frontend for each set of ports that forwards to each distinct
backend server?

Or are you doing this at webscale, or something? :-)

J
-- 
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

[PATCH v5 5/8] CLEANUP: standard: Use len2mask4 in str2mask

[Tim Duesterhus]

The len2mask4 function was introduced in commit:
70473a5f8c56d8ec2e837b9b66443dc252b24da9
which is about six years later than the commit that introduced the
str2mask function:
2937c0dd20f2f3c0065b671bbfe3fafcd8862eaf

This is a clean up in preparation for a str2mask6 function which
will use len2mask6.
---
 src/standard.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/standard.c b/src/standard.c
index acd136c27..495bae571 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -1022,10 +1022,8 @@ int str2mask(const char *str, struct in_addr *mask)
 
if (!*str || (err && *err) || (unsigned)len > 32)
return 0;
-   if (len)
-   mask->s_addr = htonl(~0UL << (32 - len));
-   else
-   mask->s_addr = 0;
+
+   len2mask4(len, mask);
}
return 1;
 }
-- 
2.15.1

[PATCH v5 7/8] MINOR: config: Add support for ARGT_MSK6

[Tim Duesterhus]

This commit adds support for ARGT_MSK6 to make_arg_list().
---
 src/arg.c  | 11 +--
 src/hlua.c |  7 +++
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/arg.c b/src/arg.c
index 52977b718..b31858d3b 100644
--- a/src/arg.c
+++ b/src/arg.c
@@ -206,8 +206,15 @@ int make_arg_list(const char *in, int len, uint64_t mask, 
struct arg **argp,
goto parse_err;
break;
 
-   case ARGT_MSK6: /* not yet implemented */
-   goto not_impl;
+   case ARGT_MSK6:
+   if (in == beg)// empty mask
+   goto empty_err;
+
+   if (!str2mask6(word, >data.ipv6))
+   goto parse_err;
+
+   arg->type = ARGT_IPV6;
+   break;
 
case ARGT_TIME:
if (in == beg)// empty time
diff --git a/src/hlua.c b/src/hlua.c
index fa629ba94..ebe8c92b1 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -704,6 +704,13 @@ __LJMP int hlua_lua2arg_check(lua_State *L, int first, 
struct arg *argp,
break;
 
case ARGT_MSK6:
+   memcpy(trash.str, argp[idx].data.str.str, 
argp[idx].data.str.len);
+   trash.str[argp[idx].data.str.len] = 0;
+   if (!str2mask6(trash.str, [idx].data.ipv6))
+   WILL_LJMP(luaL_argerror(L, first + idx, 
"invalid IPv6 mask"));
+   argp[idx].type = ARGT_MSK6;
+   break;
+
case ARGT_MAP:
case ARGT_REG:
case ARGT_USR:
-- 
2.15.1

[PATCH v5 6/8] MINOR: standard: Add str2mask6 function

[Tim Duesterhus]

This new function mirrors the str2mask() function for IPv4 addresses.

This commit is in preparation to support ARGT_MSK6.
---
 include/common/standard.h |  6 ++
 src/standard.c| 22 ++
 2 files changed, 28 insertions(+)

diff --git a/include/common/standard.h b/include/common/standard.h
index dd89203ae..461044787 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -377,6 +377,12 @@ struct sockaddr_storage *str2sa_range(const char *str,
  */
 int str2mask(const char *str, struct in_addr *mask);
 
+/* converts  to a struct in6_addr containing a network mask. It can be
+ * passed in quadruplet form (::::) or in CIDR form (64). It returns 1
+ * if the conversion succeeds otherwise zero.
+ */
+int str2mask6(const char *str, struct in6_addr *mask);
+
 /* convert  to struct in_addr . It returns 1 if the conversion
  * succeeds otherwise non-zero.
  */
diff --git a/src/standard.c b/src/standard.c
index 495bae571..707e2c716 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -1028,6 +1028,28 @@ int str2mask(const char *str, struct in_addr *mask)
return 1;
 }
 
+/* converts  to a struct in6_addr containing a network mask. It can be
+ * passed in quadruplet form (::::) or in CIDR form (64). It returns 1
+ * if the conversion succeeds otherwise zero.
+ */
+int str2mask6(const char *str, struct in6_addr *mask)
+{
+   if (strchr(str, ':') != NULL) { /* quadruplet notation */
+   if (!inet_pton(AF_INET6, str, mask))
+   return 0;
+   }
+   else { /* mask length */
+   char *err;
+   unsigned long len = strtol(str, , 10);
+
+   if (!*str || (err && *err) || (unsigned)len > 128)
+   return 0;
+
+   len2mask6(len, mask);
+   }
+   return 1;
+}
+
 /* convert  to struct in_addr . It returns 1 if the conversion
  * succeeds otherwise zero.
  */
-- 
2.15.1

[PATCH v5 8/8] MEDIUM: sample: Add IPv6 support to the ipmask converter

[Tim Duesterhus]

Add an optional second parameter to the ipmask converter that specifies
the number of bits to mask off IPv6 addresses.

If the second parameter is not given IPv6 addresses fail to mask (resulting
in an empty string), preserving backwards compatibility: Previously
a sample like `src,ipmask(24)` failed to give a result for IPv6 addresses.

This feature can be tested like this:

  defaults
log global
modehttp
option  httplog
option  dontlognull
timeout connect 5000
timeout client  5
timeout server  5

  frontend fe
bind :::8080 v4v6

# Masked IPv4 for IPv4, empty for IPv6 (with and without this commit)
http-response set-header Test %[src,ipmask(24)]
# Correctly masked IP addresses for both IPv4 and IPv6
http-response set-header Test2 %[src,ipmask(24,:::::)]
# Correctly masked IP addresses for both IPv4 and IPv6
http-response set-header Test3 %[src,ipmask(24,64)]

default_backend be

  backend be
server s example.com:80

Tested-By: Jarno Huuskonen 
---
 doc/configuration.txt | 11 +++
 src/sample.c  | 27 ++-
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 827506788..eaaf0f71f 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -12870,11 +12870,14 @@ in_table()
   the presence of a certain key in a table tracking some elements (e.g. whether
   or not a source IP address or an Authorization header was already seen).
 
-ipmask()
-  Apply a mask to an IPv4 address, and use the result for lookups and storage.
+ipmask(, [])
+  Apply a mask to an IP address, and use the result for lookups and storage.
   This can be used to make all hosts within a certain mask to share the same
-  table entries and as such use the same server. The mask can be passed in
-  dotted form (e.g. 255.255.255.0) or in CIDR form (e.g. 24).
+  table entries and as such use the same server. The mask4 can be passed in
+  dotted form (e.g. 255.255.255.0) or in CIDR form (e.g. 24). The mask6 can
+  be passed in quadruplet form (e.g. :::) or in CIDR form (e.g. 64).
+  If no mask6 is given IPv6 addresses will fail to convert for backwards
+  compatibility reasons.
 
 json([])
   Escapes the input string and produces an ASCII output string ready to use as 
a
diff --git a/src/sample.c b/src/sample.c
index 04cec4fc8..0155b3d69 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -1603,11 +1603,28 @@ static int sample_conv_str2upper(const struct arg 
*arg_p, struct sample *smp, vo
return 1;
 }
 
-/* takes the netmask in arg_p */
-static int sample_conv_ipmask(const struct arg *arg_p, struct sample *smp, 
void *private)
+/* takes the IPv4 mask in args[0] and an optional IPv6 mask in args[1] */
+static int sample_conv_ipmask(const struct arg *args, struct sample *smp, void 
*private)
 {
-   smp->data.u.ipv4.s_addr &= arg_p->data.ipv4.s_addr;
-   smp->data.type = SMP_T_IPV4;
+   /* Attempt to convert to IPv4 to apply the correct mask. */
+   c_ipv62ip(smp);
+
+   if (smp->data.type == SMP_T_IPV4) {
+   smp->data.u.ipv4.s_addr &= args[0].data.ipv4.s_addr;
+   smp->data.type = SMP_T_IPV4;
+   }
+   else if (smp->data.type == SMP_T_IPV6) {
+   /* IPv6 cannot be converted without an IPv6 mask. */
+   if (args[1].type != ARGT_IPV6)
+   return 0;
+
+   *(uint32_t*)>data.u.ipv6.s6_addr[0]  &= 
*(uint32_t*)[1].data.ipv6.s6_addr[0];
+   *(uint32_t*)>data.u.ipv6.s6_addr[4]  &= 
*(uint32_t*)[1].data.ipv6.s6_addr[4];
+   *(uint32_t*)>data.u.ipv6.s6_addr[8]  &= 
*(uint32_t*)[1].data.ipv6.s6_addr[8];
+   *(uint32_t*)>data.u.ipv6.s6_addr[12] &= 
*(uint32_t*)[1].data.ipv6.s6_addr[12];
+   smp->data.type = SMP_T_IPV6;
+   }
+
return 1;
 }
 
@@ -2797,7 +2814,7 @@ static struct sample_conv_kw_list sample_conv_kws = {ILH, 
{
{ "length", sample_conv_length,0,NULL, SMP_T_STR,  
SMP_T_SINT },
{ "hex",sample_conv_bin2hex,   0,NULL, SMP_T_BIN,  
SMP_T_STR  },
{ "hex2i",  sample_conv_hex2int,   0,NULL, SMP_T_STR,  
SMP_T_SINT },
-   { "ipmask", sample_conv_ipmask,ARG1(1,MSK4), NULL, SMP_T_IPV4, 
SMP_T_IPV4 },
+   { "ipmask", sample_conv_ipmask,ARG2(1,MSK4,MSK6), NULL, SMP_T_ADDR, 
SMP_T_IPV4 },
{ "ltime",  sample_conv_ltime, ARG2(1,STR,SINT), NULL, SMP_T_SINT, 
SMP_T_STR },
{ "utime",  sample_conv_utime, ARG2(1,STR,SINT), NULL, SMP_T_SINT, 
SMP_T_STR },
{ "crc32",  sample_conv_crc32, ARG1(0,SINT), NULL, SMP_T_BIN,  
SMP_T_SINT  },
-- 
2.15.1

[PATCH v5 1/8] BUG/MINOR: sample: Fix encoding of sample.c

[Tim Duesterhus]

The file contained an 'e' with an gravis accent and thus was
not US-ASCII, but ISO-8859-1.

Also correct the spelling in the incorrect comment.

The incorrect character was introduced in commit:
4d9a1d1a5c4720a169654ee47f9a4364261ffab4

v1.6-dev1 is the first tag containing this comment, the fix
should be backported to haproxy 1.6 and newer.
---
 src/sample.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/sample.c b/src/sample.c
index ed2aee010..d3aa88935 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -389,12 +389,12 @@ struct sample_fetch *find_sample_fetch(const char *kw, 
int len)
return NULL;
 }
 
-/* This fucntion browse the list of available saple fetch.  is
+/* This function browses the list of available sample fetches.  is
  * the last used sample fetch. If it is the first call, it must set to NULL.
- *  is the index of the next sampleèfetch entry. It is used as private
- * value. It is useles to initiate it.
+ *  is the index of the next sample fetch entry. It is used as private
+ * value. It is useless to initiate it.
  *
- * It returns always the newt fetch_sample entry, and NULL when the end of
+ * It returns always the new fetch_sample entry, and NULL when the end of
  * the list is reached.
  */
 struct sample_fetch *sample_fetch_getnext(struct sample_fetch *current, int 
*idx)
-- 
2.15.1

[PATCH v5 3/8] BUG/MINOR: sample: Fix output type of c_ipv62ip

[Tim Duesterhus]

c_ipv62ip failed to set the output type of the cast to SMP_T_IPV4
even for a successful conversion.

This bug exists as of commit cc4d1716a2e72516c2505a6459a9ddbbfb186da2
which is the first commit adding this function.

v1.6-dev4 is the first tag containing this commit, the fix should
be backported to haproxy 1.6 and newer.
---
 src/sample.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sample.c b/src/sample.c
index 115288539..04cec4fc8 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -531,7 +531,7 @@ static int c_ipv62ip(struct sample *smp)
 {
if (!v6tov4(>data.u.ipv4, >data.u.ipv6))
return 0;
-   smp->data.type = SMP_T_IPV6;
+   smp->data.type = SMP_T_IPV4;
return 1;
 }
 
-- 
2.15.1

[PATCH v5 0/8] Add IPv6 support to the ipmask converter

[Tim Duesterhus]

Willy,

okay. I added Jarno to the commit message of the actual changes
to the ipmask converter. I did not clean up the tags, you know
best which ones you wanted to change. If Jarno complains about
his name being in there, before you get the change to apply please
edit him out, as you need to modify the messages anyway.

Attached comes the complete series (v5). Again: Be extra careful
with the first patch, because it contains 8bit characters.

Best regards
Tim Duesterhus

Tim Duesterhus (8):
  BUG/MINOR: sample: Fix encoding of sample.c
  DOC: sample: Fix outdated comment about sample casts functions
  BUG/MINOR: sample: Fix output type of c_ipv62ip
  DOC: Fix typo in ARGT_MSK6 comment
  CLEANUP: standard: Use len2mask4 in str2mask
  MINOR: standard: Add str2mask6 function
  MINOR: config: Add support for ARGT_MSK6
  MEDIUM: sample: Add IPv6 support to the ipmask converter

 doc/configuration.txt | 11 +++
 include/common/standard.h |  6 ++
 include/types/arg.h   |  2 +-
 src/arg.c | 11 +--
 src/hlua.c|  7 +++
 src/sample.c  | 39 +++
 src/standard.c| 28 
 7 files changed, 81 insertions(+), 23 deletions(-)

-- 
2.15.1

Re: How can I map bindings to the correct backend?

[Igor Cicimov]

Hi Pieter,

On Thu, Jan 25, 2018 at 3:15 AM, Pieter Vogelaar 
wrote:

> I have the following configuration:
>
>
>
>
>
> frontend default-tcp
>
>   bind 192.168.52.12:5044
>
>   bind 192.168.52.12:
>
>   bind 192.168.52.12:5556
>
>   bind 192.168.52.12:5672
>
>   bind 192.168.52.13:5672
>
>   mode tcp
>
>   option tcplog
>
>   use_backend %[dst_port,map(/etc/haproxy/tcp-bindings-to-backends.map,
> default)]
>
>
>
>
>
> The map file (/etc/haproxy/tcp-bindings-to-backends.map) looks like:
>
>
>
>
>
> 192.168.52.12:5044 logging-logstashmsg-acc
>
> 192.168.52.12: logging-logstashmsg-acc
>
> 192.168.52.12:5556 logging-logstashmsg-acc
>
> 192.168.52.12:5672 logging-rabbitmq-acc
>
> 192.168.52.13:5672 stackstorm-rabbitmq-tst
>
>
>
>
>
> I would like to route based on the IP address and port to the correct
> backend. At the moment I used the dst_port sample on the use_backend line.
> But that must be a concatenation of dst sample, “:” and dst_port sample.
>
> It seems like a basic thing to do, but I just can’t figure out how to do
> this.
>
>
>

​How​ do you access the frontend? If via ip:port instead of dns than I
guess the ip:port combo will already be present in the hdr(host).

Re: How can I map bindings to the correct backend?

[Igor Cicimov]

On Fri, Jan 26, 2018 at 2:36 AM, Pieter Vogelaar 
wrote:

> It’s TCP layer 4 load balancing, so the HTTP hdr(host) won’t work.
>
>
>
>
>
> Best regards,
>
> Pieter Vogelaar
>
>
>
> *Van: *Igor Cicimov 
> *Datum: *donderdag 25 januari 2018 om 16:33
> *Aan: *Pieter Vogelaar 
> *CC: *"haproxy@formilux.org" 
> *Onderwerp: *Re: How can I map bindings to the correct backend?
>
>
>
> Hi Pieter,
>
>
>
> On Thu, Jan 25, 2018 at 3:15 AM, Pieter Vogelaar 
> wrote:
>
> I have the following configuration:
>
>
>
>
>
> frontend default-tcp
>
>   bind 192.168.52.12:5044
>
>   bind 192.168.52.12:
>
>   bind 192.168.52.12:5556
>
>   bind 192.168.52.12:5672
>
>   bind 192.168.52.13:5672
>
>   mode tcp
>
>   option tcplog
>
>   use_backend %[dst_port,map(/etc/haproxy/tcp-bindings-to-backends.map,
> default)]
>
>
>
>
>
> The map file (/etc/haproxy/tcp-bindings-to-backends.map) looks like:
>
>
>
>
>
> 192.168.52.12:5044 logging-logstashmsg-acc
>
> 192.168.52.12: logging-logstashmsg-acc
>
> 192.168.52.12:5556 logging-logstashmsg-acc
>
> 192.168.52.12:5672 logging-rabbitmq-acc
>
> 192.168.52.13:5672 stackstorm-rabbitmq-tst
>
>
>
>
>
> I would like to route based on the IP address and port to the correct
> backend. At the moment I used the dst_port sample on the use_backend line.
> But that must be a concatenation of dst sample, “:” and dst_port sample.
>
> It seems like a basic thing to do, but I just can’t figure out how to do
> this.
>
>
>
>
>
> ​How​ do you access the frontend? If via ip:port instead of dns than I
> guess the ip:port combo will already be present in the hdr(host).
>
>
>

​Right, tcp didn't notice that.

Re: Alpn in debian/ubuntu ppa 1.8

[Lukas Tribus]

Hello Igor,


On 25 January 2018 at 15:22, Igor Cicimov
 wrote:
>> Upgrade to the *current* LTS release, which is Ubuntu Xenial. It ships
>> OpenSSL 1.0.2.
>
>
> For sure I don't have to update the whole distro to get the newest openssl
> :-)

You mean you expect to replace a system library from one major release
to another, with incompatible ABI and API? No, that's not how it
works. Fortunately OpenSSL 1.1.0 creates .so files with the ".so.1.1"
file ending (as well as a symbolic link to it from ".so" files) , so
the original ".so.1.0.0" files are not overwritten. Otherwise your
system would be broken now.

I suggested to upgrade to the current Ubuntu LTS because its the
fastest and safest way to get OpenSSL 1.0.2, it wont break your
system, you get security updates and you have to do it anyway sooner
or later, as Trusty is EOL'ed next year.


You don't have to; you can always compile OpenSSL statically locally,
and use that to compile Haproxy (see README), or if the 1.1.0 headers
are installed correctly, just compile Haproxy.


But replacing a system library like that is something you need to be
very careful with.



Regards,
Lukas

Alpn in debian/ubuntu ppa 1.8

[Igor Cicimov]

Hi,

I was testing haproxy 1.8 from the ppa repository and noticed it is not
build with alpn support so just wonder why?

Thanks,
Igor

Re: problem in 1.8 with hosts going out of service

[Christopher Faulet]

Le 24/01/2018 à 23:54, Paul Lockaby a écrit :

This patch works for me. Thank you!



On Jan 24, 2018, at 1:02 PM, Christopher Faulet  wrote:

Le 24/01/2018 à 17:21, Paul Lockaby a écrit :

Sorry, I know this list is super busy and that there are a number of other more 
important issues that need to be worked through but I'm hoping one of the 
maintainers has been able to confirm this bug?


Hi,

Sorry Paul. As you said, we are pretty busy. And you're right to ping us. So, I 
can confirm the bug. It is a bug on threads, a deadlock, because of a typo.

Could you check the attached patch to confirm it fixes your problem ?



Hi,

Thanks for tests guys. Willy, you can merge the patch.

--
Christopher Faulet

Re: Bug using no-check in HAProxy 1.8: segfaults

[Christopher Faulet]

Le 25/01/2018 à 11:25, Linus Thiel a écrit :

Hi,

I seem to have hit a bug running the official Docker image for HAProxy.
When specifying no-check for a server, HAProxy segfaults.

I have prepared a test case, which is attached here. To run it:

docker-compose build
docker-compose up

I get:

haproxybug_haproxy-no-check-alpine_1 exited with code 139
haproxybug_haproxy-no-check_1 exited with code 139

Tested using:

Docker version 17.12.0-ce, build c97c6d6
docker-compose version 1.17.1, build 6d101fb
Host machine is running Ubuntu 16.04, kernel 4.4.0-112-generic

Images tested are haproxy:1.8 and haproxy:1.8-alpine

If I should report this to docker-images and/or Debian instead, please
excuse me and let me know.



Hi,

This is a bug in HAProxy. I attached the patch. Willy, you can merge it. 
It must be backported in 1.8.


Thanks
--
Christopher Faulet
>From ecd6e4e171c1420629e97dfe4059fbce4d85722d Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Thu, 25 Jan 2018 11:36:35 +0100
Subject: [PATCH] BUG/MEDIUM: checks: Don't try to release undefined
 conn_stream when a check is freed

When a healt-check is released, the attached conn_stream may be undefined. For
instance, this happens when 'no-check' option is used on a server line. So we
must check it is defined before trying to release it.

This patch must be backported in 1.8.
---
 src/checks.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/checks.c b/src/checks.c
index 56c9d609d..0d4893e69 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -3098,10 +3098,12 @@ void free_check(struct check *check)
 	check->bi = NULL;
 	free(check->bo);
 	check->bo = NULL;
-	free(check->cs->conn);
-	check->cs->conn = NULL;
-	cs_free(check->cs);
-	check->cs = NULL;
+	if (check->cs) {
+		free(check->cs->conn);
+		check->cs->conn = NULL;
+		cs_free(check->cs);
+		check->cs = NULL;
+	}
 }
 
 void email_alert_free(struct email_alert *alert)
-- 
2.14.3

Bug using no-check in HAProxy 1.8: segfaults

[Linus Thiel]

Hi,

I seem to have hit a bug running the official Docker image for HAProxy.
When specifying no-check for a server, HAProxy segfaults.

I have prepared a test case, which is attached here. To run it:

docker-compose build
docker-compose up

I get:

haproxybug_haproxy-no-check-alpine_1 exited with code 139
haproxybug_haproxy-no-check_1 exited with code 139

Tested using:

Docker version 17.12.0-ce, build c97c6d6
docker-compose version 1.17.1, build 6d101fb
Host machine is running Ubuntu 16.04, kernel 4.4.0-112-generic

Images tested are haproxy:1.8 and haproxy:1.8-alpine

If I should report this to docker-images and/or Debian instead, please
excuse me and let me know.

Best regards,
Linus Thiel

-- 
http://yesbabyyes.se/
+46 709 89 03 85


haproxy-bug.tar.bz2
Description: application/bzip

Re: Alpn in debian/ubuntu ppa 1.8

[Lukas Tribus]

Hello,


On 25 January 2018 at 14:53, Igor Cicimov
 wrote:
>
> Hi,
>
> The info below, that openssl version fort he build is little bit oldish isn't 
> it?
>
> # haproxy -vv
> [...]
> Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> [...]


ALPN requires OpenSSL 1.0.2. You are using Ubuntu Trusty, which ships
OpenSSL 1.0.1.



> # openssl version
> OpenSSL 1.1.0g  2 Nov 2017


Don't know where that's from, but not from a vanilla Ubuntu trusty installation.


Upgrade to the *current* LTS release, which is Ubuntu Xenial. It ships
OpenSSL 1.0.2.



Lukas

Re: Alpn in debian/ubuntu ppa 1.8

[Igor Cicimov]

Hi Lukas,

On Fri, Jan 26, 2018 at 1:04 AM, Lukas Tribus  wrote:

> Hello,
>
>
> On 25 January 2018 at 14:53, Igor Cicimov
>  wrote:
> >
> > Hi,
> >
> > The info below, that openssl version fort he build is little bit oldish
> isn't it?
> >
> > # haproxy -vv
> > [...]
> > Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> > Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
> > [...]
>
>
> ALPN requires OpenSSL 1.0.2. You are using Ubuntu Trusty, which ships
> OpenSSL 1.0.1.
>
>
​Ok, so
​

>
>
> > # openssl version
> > OpenSSL 1.1.0g  2 Nov 2017
>
>
​I have even more recent openssl version and this should work.
​

>
> Don't know where that's from, but not from a vanilla Ubuntu trusty
> installation.
>
>
​You mean where that 1.0.1f came from? Obviously the installed one is
1.1.0g and why does it matter where it came from? Where is haproxy looking
for openssl? Maybe I'm missing some library links ...
​

>
> Upgrade to the *current* LTS release, which is Ubuntu Xenial. It ships
> OpenSSL 1.0.2.
>

​For sure I don't have to up​date the whole distro to get the newest
openssl :-)


>
>
> Lukas
>

Re: problem in 1.8 with hosts going out of service

[Willy Tarreau]

On Thu, Jan 25, 2018 at 11:28:38AM +0100, Christopher Faulet wrote:
> Thanks for tests guys. Willy, you can merge the patch.

Applied, thanks!
Willy

Re: [PATCH 0/8] Add IPv6 support to the ipmask converter

[Willy Tarreau]

Hi guys,

On Mon, Jan 22, 2018 at 08:13:59AM +0200, Jarno Huuskonen wrote:
> I did some brief testing on saturday and with this silly config
> frontend test4
> bind ipv4@127.0.0.1:8080
> bind ipv6@::1:8080
> 
> http-request track-sc1 src,ipmask(32,128) table test_be
> 
> http-request track-sc0 req.hdr_ip(X,1),ipmask(24,64) table test_be
> http-request set-var(sess.myx) req.hdr_ip(X,1),ipmask(24,64)
> http-response set-header X-MY %[var(sess.myx)]
> default_backend test_be
> 
> backend test_be
> stick-table type ipv6 size 20 expire 180s store gpc0,conn_cnt
> server wp1 some.ip.addr.ess:80 id 1
> 
> and curl -4|-6 -H "X: ipv4.or.ipv6.address" http://localhost:8080/
> 
> everything I tested seemed to work (I tested Tim's patch with for size_t 
> outside
> of loop).

OK thanks a lot for the tests.

Tim, there were a few versions of some of these patches in the series,
I would appreciate it if you can send me a complete series of what you
want me to apply. It would be nice to add a Tested-By: tag mentionning
Jarno (unless he doesn't want :-)). I noticed that two patches "only"
fix comments and were tagged either BUG or DOC, I'll re-tag them as
CLEANUP since they have no impact on the code nor on the user-facing
doc and will not be eligible for backporting. It's trivial for me to do
this here on the patches themselves, do not waste your time rebasing if
you don't need to change anything else.

Thanks!
Willy

Re: rate-limit sessions not consistent between ssl and non ssl traffic

[Willy Tarreau]

Hi Jérôme,

On Wed, Jan 24, 2018 at 02:38:20PM +0100, Jérôme Magnin wrote:
> Hi,
> 
> I've been toying with haproxy and rate limiting lately, and noticed an odd
> behavior with rate-limit sessions, or maybe I misunderstood how it is supposed
> to be used.
> 
> I'm using the following config:
> 
> global
> maxconn 2
> log 127.0.0.1 local0
> userhaproxy
> chroot  /usr/share/haproxy
> pidfile /run/haproxy.pid
> daemon
>   stats socket /var/run/haproxy.sock
> 
> defaults
>   mode http
> 
> frontend  fe_foo
> bind *:1234
> bind *:1235 ssl crt /etc/haproxy/www.pem
> rate-limit sessions 10
> default_backend be_foo
> 
> backend be_foo
> server s1 127.0.0.1:8001
> 
> I'm using ab to send traffic to the frontend.
> 
> 1/ ab -c 40 -n 100 http://127.0.0.1:1234/
> 
> the output of show info shows maxconnrate 10 and maxsessrate 10.
> This is coherent with the value I set for rate-limit sessions.
> 
> 2/ ab -c 40 -n 100 https://127.0.0.1:1235/
> 
> the output of show info shows maxconnrate, maxsslrate, maxsessrate and
> sslfrontendmaxkeyrate equal 40, 4 times the value for my rate-limit sessions.
> 
> Am I doing something wrong here ?

No but we're on an annoying corner case as I explained to you. I'm putting
all the elements here so that everyone has them as well.

What happens is that the listener_accept() function which performs the
accept() call refrains from accepting a new connection when the frontend's
session rate has reached the configured session rate limit. Sessions are
instanciated at the end of handshakes, and in the case of SSL, it happens
once the SSL handshake with the client is completed. So in practice the
behaviour you're observing is that many clients connect at once. The
frontend's session rate remains zero since none of them has yet completed
a handshake, and once a few handshakes are completed, we stop accepting
new connections for a while, but all already accepted connections still
have to be handshaked.

Thus we see a rush of handshakes during all initial connections, and only
then it falls and is smoothed.

I'm a bit embarrassed with how to address this.

Addressing it with a connection rate limit is the wrong response since it
will not allow you to use tcp-request connection rules to ignore certain
connections, so that creates very trivial DoS vectors (ie just connect 10
times in a row using netcat and nobody connects for one second ; worse,
send 5 connection requests and you'll spend 1.5 hours slowly draining
the pending handshakes).

I thought that one really nice thing to do would be to try to improve the
server side to support per-server connection rate limiting in addition to
the connection concurrency control we already have. Given that most of the
time, "rate-limit session" is used in fact to protect backend servers, it
would allow the limits to be more accurate. But it doesn't solve the root
cause of the problem.

Another idea I was considering would be to place a limit on the number of
concurrent handshakes per frontend (or listener). That would be very
convenient as we'd refrain from accepting new connections if we have
already queued enough of them to keep the handshake code busy. But this
one is tricky and there's a high risk of losing some accounting in certain
error cases.

So I'm still thinking about it, not having many solutions to propose at
the moment :-/

Thanks,
Willy

Re: Alpn in debian/ubuntu ppa 1.8

[Lukas Tribus]

Hello,

On 25 January 2018 at 13:26, Igor Cicimov
 wrote:
> Hi,
>
> I was testing haproxy 1.8 from the ppa repository and noticed it is not
> build with alpn support so just wonder why?

Which OS exactly?


Lukas

Re: Bug using no-check in HAProxy 1.8: segfaults

[Willy Tarreau]

On Thu, Jan 25, 2018 at 11:47:20AM +0100, Christopher Faulet wrote:
> This is a bug in HAProxy. I attached the patch. Willy, you can merge it. It
> must be backported in 1.8.

Applied, thanks!
Willy

Re: Bug using no-check in HAProxy 1.8: segfaults

[Linus Thiel]

On 2018-01-25 13:53, Willy Tarreau wrote:
> On Thu, Jan 25, 2018 at 11:47:20AM +0100, Christopher Faulet wrote:
>> This is a bug in HAProxy. I attached the patch. Willy, you can merge it. It
>> must be backported in 1.8.
> 
> Applied, thanks!

Great, such quickness!

Happy to oblige,
Linus

-- 
http://yesbabyyes.se/
+46 709 89 03 85

Re: Alpn in debian/ubuntu ppa 1.8

[Jerome Magnin]

Hi Igor,

On Thu, Jan 25, 2018 at 11:26:14PM +1100, Igor Cicimov wrote:
> Hi,
> 
> I was testing haproxy 1.8 from the ppa repository and noticed it is not
> build with alpn support so just wonder why?

what's the output of haproxy -vv ?

Jérôme

Re: Alpn in debian/ubuntu ppa 1.8

[Igor Cicimov]

Hi,

The info below, that openssl version fort he build is little bit oldish
isn't it?

# haproxy -vv
HA-Proxy version 1.8.3-1ppa1~trusty 2018/01/02
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_NS=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200


*Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014Running on OpenSSL
version : OpenSSL 1.0.1f 6 Jan 2014*
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.31 2012-07-06
Running on PCRE version : 8.31 2012-07-06
PCRE library supports JIT : no (libpcre build without JIT?)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

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.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

# openssl version
OpenSSL 1.1.0g  2 Nov 2017

# lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 14.04.5 LTS
Release:14.04
Codename:trusty



On Fri, Jan 26, 2018 at 12:39 AM, Lukas Tribus  wrote:

> Hello,
>
> On 25 January 2018 at 13:26, Igor Cicimov
>  wrote:
> > Hi,
> >
> > I was testing haproxy 1.8 from the ppa repository and noticed it is not
> > build with alpn support so just wonder why?
>
> Which OS exactly?
>
>
> Lukas
>



-- 
Igor Cicimov | DevOps


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

Re: Alpn in debian/ubuntu ppa 1.8

[Igor Cicimov]

On Fri, Jan 26, 2018 at 1:22 AM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

> Hi Lukas,
>
> On Fri, Jan 26, 2018 at 1:04 AM, Lukas Tribus  wrote:
>
>> Hello,
>>
>>
>> On 25 January 2018 at 14:53, Igor Cicimov
>>  wrote:
>> >
>> > Hi,
>> >
>> > The info below, that openssl version fort he build is little bit oldish
>> isn't it?
>> >
>> > # haproxy -vv
>> > [...]
>> > Built with OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
>> > Running on OpenSSL version : OpenSSL 1.0.1f 6 Jan 2014
>> > [...]
>>
>>
>> ALPN requires OpenSSL 1.0.2. You are using Ubuntu Trusty, which ships
>> OpenSSL 1.0.1.
>>
>>
> ​Ok, so
> ​
>
>>
>>
>> > # openssl version
>> > OpenSSL 1.1.0g  2 Nov 2017
>>
>>
> ​I have even more recent openssl version and this should work.
> ​
>
>>
>> Don't know where that's from, but not from a vanilla Ubuntu trusty
>> installation.
>>
>>
> ​You mean where that 1.0.1f came from? Obviously the installed one is
> 1.1.0g and why does it matter where it came from? Where is haproxy looking
> for openssl? Maybe I'm missing some library links ...
> ​
>
>>
>> Upgrade to the *current* LTS release, which is Ubuntu Xenial. It ships
>> OpenSSL 1.0.2.
>>
>
> ​For sure I don't have to up​date the whole distro to get the newest
> openssl :-)
>
>
>>
>>
>> Lukas
>>
>
>
​Or you meant using the haproxy 16.04 image actually. Ok, another option is
to compile it myself with the openssl version I have atm.​