[ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi all!

Give some food, drink, disk space, a quiet place, a keyboard and Git to
a developer and he will code forever... All good things must come to an
end, and I decided that it had to be right now. After all, we initially
announced the end of developments around end of September and a release
around October or November. We've missed the September deadline, but I
know by experience that nobody notices missed deadlines as long as they
are not missed by more than one month. And one month ends today.

So what do we have here ? A *preview* of what the final 1.8 will be like.
As a reminder, our -rc don't mean they're totally ready, but that we're
really done with development and only performing the last adjustments,
fixes, cleanups, documentation updates etc and that NEW FEATURES ARE NOT
WELCOME ANYMORE FOR THIS VERSION. There are still some issues (I found
a few after the release) but overall there's enough in various areas to
satisfy the curious. And we needed to merge our various branches to take
the time to fix conflicts and adapt our respective code (mainly to
threads, which were merged first).

In practice, since 1.8-dev3, the following main features were merged :
  - multi-thread support : for certain workloads like massive SSL rekeying
it provides comparable performance to multi-process, but with all the
load handled in a single process, hence single health checks and server
states, single stats, single CLI etc. There are some known scalability
limitations coming from arbitrations we had to do for 1.8 and which we
will address during 1.9 (and maybe some before 1.8-final). The feature
is enabled by default on linux2628 and freebsd, and disabled by default
on other targets, though it can be forced enabled using USE_THREAD=1 or
forced disabled using USE_THREAD= (empty string). Once enabled, it's
possible to start several threads in the configuration using the
"nbthread" directive in the global section. It's possible to force to
map threads to CPUs but we're not completely satisfied with the current
configuration options and will be working on them (any feedback is
welcome). Another point is that we tried to start to take a look at
the device detection extensions and it didn't appear trivial enough
to fit in the tight schedule so this was postponed. Their maintainers
are welcome to take a look as they know this much better than anyone
else, and the thread developers will be happy to give some help on the
subject.

Important note: I just found that health-checks are totally broken
(recursive locks and missed unlocks), so please disable checks when
testing threads for now. We'll see how to address this.

  - small object cache : this is what I've been calling the "favicon cache"
for several years now. The idea is always the same, when haproxy is
deployed in front of a slow application server having to deliver a few
small static objects, it costs a lot to this server to deliver them. A
small cache of a few megabytes caching small objects for a short time
with zero administration definitely helps here. As we don't want this
cache to cause trouble, it's pessimistic : if any risk is suspected,
an object is not cached ; and by default it caches for a short time
(1 minute I believe) so that even after a failed deployment, it takes
less time to wait than to wake up the LB admin to clear the cache. To
be very clear, this is not meant to replace any real cache you might
already be using. Maybe it could offload it from some dumb files at
best. It's only meant to improve the situation for those not having
a cache. The cache is enabled using "http-request cache-use" and
"http-response cache-store" directives like below (the doc will
come soon) :

listen frt
mode http
http-response cache-store foobar
http-request cache-use foobar

cache foobar
total-max-size 4   # size in megabytes

  - client-facing HTTP/2 : that's HTTP/2 support on the frontend. It's
much better after the completely new rewrite than the first attempt a
few months ago, and in the end I'm really happy with the outcome
despite the pain it was. It's now almost complete, it supports POST,
1xx responses, chunked responses. In fact it's easier to enumerate
what it does not support : CONTINUATION frames are not yet implemented
(I may have found how to do it), PRIORITY frames are ignored (that's
allowed by the spec), there's no equivalent of chunked encoding in
requests, and trailers from the response are discarded. What it needs
most is real world exposure now to spot corner cases. I wanted to
place it on haproxy.org until I failed on the thread problem described
above and had to revert. In order to enable it, simply add
"alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,
and if the

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Cyril Bonté]

Hi all,

Le 01/11/2017 à 00:20, Willy Tarreau a écrit :

[...]
So what do we have here ? A *preview* of what the final 1.8 will be like.
[...]
Please find the usual URLs below :
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/


This announcement was exciting enough to take some time to regenerate an 
up to date HTML documentation ! 1.8-rc1 is now available : 
http://cbonte.github.io/haproxy-dconv/1.8/configuration.html



Have fun,
Willy -- feeling exhausted like a marathoner :-)


Great job ! Now it's time to test and track nasty bugs before the final 
1.8 release ;-)



--
Cyril Bonté

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi Cyril,

On Wed, Nov 01, 2017 at 01:03:42AM +0100, Cyril Bonté wrote:
> This announcement was exciting enough to take some time to regenerate an up
> to date HTML documentation ! 1.8-rc1 is now available :
> http://cbonte.github.io/haproxy-dconv/1.8/configuration.html

Cool, thank you!

> > Have fun,
> > Willy -- feeling exhausted like a marathoner :-)
> 
> Great job ! Now it's time to test and track nasty bugs before the final 1.8
> release ;-)

Yep. And we know certain points already have to be fixed. The real great
thing is to be allowed to sleep a full night for the first time in a few
months ;-)

Cheers,
Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi Aleks,

On Wed, Nov 01, 2017 at 10:28:55AM +, Aleksandar Lazic wrote:
> Have a good and refreshing sleep ;-)

done :-)

> Thanks for the hard work ;-)
> 
> There is now a shiny new docker image with the rc1.
> 
> docker run --rm --entrypoint /usr/local/sbin/haproxy me2digital/haproxy18
> -vv

Cool, thanks for doing this. Just FYI, we currently have two issues to
be careful about :
  - checks don't work with threads (spinning loop at the first error if
an HTTP check is enabled for example)
  - rate counters stored as extra data in stick tables for tracking using
update_freq_ctr_period() enter a spinning loop if threads are *disabled*.

While annoying, it's not huge considering the amount of code merged and the
parallel development that happened. We'll address this ASAP.

BTW I noted last evening that we still didn't add the build options to the
-vv output, we'll do it as well.

Cheers,
Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Lukas Tribus]

Hello,



outstanding work everyone!
I hope to play with those features soon.


Just upgrading the binary from -dev3 to -rc1 however broke my setup:
Turns out that the new object caching code breaks when another filter
(compression) is already enabled (at config parsing stage) - even when
object caching is not enabled itself:

lukas@dev:~/haproxy$ cat ../haproxy.cfg
defaults
 timeout connect 5000
 timeout client  5
 timeout server  5
 compression algo gzip

frontend http_in
 bind :80
 default_backend bk_testbk

backend bk_testbk
 mode http
 server server1 10.0.0.1:80

lukas@dev:~/haproxy$ ./haproxy -f ../haproxy.cfg
[ALERT] 304/203750 (6995) : Proxy 'http_in': unable to find the cache
'(null)' referenced by the filter 'cache'.
[ALERT] 304/203750 (6995) : Proxy 'bk_testbk': unable to find the
cache '(null)' referenced by the filter 'cache'.
[ALERT] 304/203750 (6995) : Fatal errors found in configuration.
lukas@dev:~/haproxy$



Now I'm going to disable compression and try the fun stuff :)


cheers,
lukas

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi Lukas,

On Wed, Nov 01, 2017 at 08:43:19PM +0100, Lukas Tribus wrote:
> Just upgrading the binary from -dev3 to -rc1 however broke my setup:
> Turns out that the new object caching code breaks when another filter
> (compression) is already enabled (at config parsing stage) - even when
> object caching is not enabled itself:
> 
(...)
> 
> lukas@dev:~/haproxy$ ./haproxy -f ../haproxy.cfg
> [ALERT] 304/203750 (6995) : Proxy 'http_in': unable to find the cache
> '(null)' referenced by the filter 'cache'.
> [ALERT] 304/203750 (6995) : Proxy 'bk_testbk': unable to find the
> cache '(null)' referenced by the filter 'cache'.
> [ALERT] 304/203750 (6995) : Fatal errors found in configuration.
> lukas@dev:~/haproxy$
> 
> Now I'm going to disable compression and try the fun stuff :)

Thanks for reporting, such type of early breakage is indeed expected
after I stressed everyone to merge. We know that the inned parts work
pretty well overall but some integration work is now needed.

You may have to explicitly use the compression filter by the way,
though I have no idea how to do that but I think it's mentionned
somewhere in the config manual. William was about to write some doc
when I interrupted him to get his code, but he'll certainly get back
to this soon.

Cheers,
Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Bryan Talbot]

> On Nov 1, 2017, at Nov 1, 3:28 AM, Aleksandar Lazic  wrote:
> 
> 
> There is now a shiny new docker image with the rc1.
> 
> docker run --rm --entrypoint /usr/local/sbin/haproxy me2digital/haproxy18 -vv
> 


For the past couple of years, I’ve also been maintaining a base docker image 
for haproxy. It is interesting to see how other’s structure the build and 
configuration. 

I see that you include a base / default configuration file while I’ve left that 
completely up to the user to provide one. Given how many different ways people 
use haproxy, it didn’t seem that there was any one “basic” config that would 
work beyond a trivial example. I’m curious how useful the configuration you’ve 
packaged is. I use my image as a base which I then repackage use-case specific 
configuration files into for deployments and I assume anyone else using the 
image does the same thing, but I do not have any feedback about that.


https://hub.docker.com/r/fingershock/haproxy-base/ 


-Bryan

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Lukas Tribus]

Hello Willy,


>   - client-facing HTTP/2 : that's HTTP/2 support on the frontend. It's
> much better after the completely new rewrite than the first attempt a
> few months ago, and in the end I'm really happy with the outcome
> despite the pain it was. It's now almost complete, it supports POST,
> 1xx responses, chunked responses. In fact it's easier to enumerate
> what it does not support : CONTINUATION frames are not yet implemented
> (I may have found how to do it), PRIORITY frames are ignored (that's
> allowed by the spec), there's no equivalent of chunked encoding in
> requests, and trailers from the response are discarded. What it needs
> most is real world exposure now to spot corner cases. I wanted to
> place it on haproxy.org until I failed on the thread problem described
> above and had to revert. In order to enable it, simply add
> "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,
> and if the client advertises ALPN "h2" it will be used, otherwise it
> will fall back to HTTP/1.1.

Actually that is not what I'm seeing.

In ALPN, the client announces the supported protocols, currently for example
http1/1 and h2, and then the server picks a protocol out of that
selection, based
on its own preference.

However, with clients supporting both http/1.1 and h2 the configuration:
alpn http/1.1,h2

always leads to HTTP/1.1 (on both curl and Chrome) here.


I had to turn it around, for HTTP/2 to be actually negotiated:
alpn h2,http/1.1

With the latter configuration, HTTP/2 is actually used.



> "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,

And "alpn h2,http/1.1" does work via HTTP2 in a HTTP mode frontend.


But when the frontend is in TCP mode, and the backend is in HTTP mode,
its looks like the H2 parser is not started even when ALPN negotiates h2, and
the HTTP/1.1 only backend server receives the "PRI" connection request verbatim:

000a:https_in.accept(0005)=0008 from [10.0.0.4:54737] ALPN=h2
000a:bk_testbk.clireq[0008:]: PRI * HTTP/2.0
000a:bk_testbk.srvrep[0008:adfd]: HTTP/1.1 400 Bad Request
000a:bk_testbk.srvhdr[0008:adfd]: Server: nginx/1.10.3 (Ubuntu)
000a:bk_testbk.srvhdr[0008:adfd]: Date: Wed, 01 Nov 2017 21:15:41 GMT
000a:bk_testbk.srvhdr[0008:adfd]: Content-Type: text/html
000a:bk_testbk.srvhdr[0008:adfd]: Content-Length: 182
000a:bk_testbk.srvhdr[0008:adfd]: Connection: close
000a:bk_testbk.srvcls[0008:adfd]
000b:bk_testbk.clireq[0008:]: SM
000b:bk_testbk.clicls[adfd:]
000b:bk_testbk.closed[adfd:]


In the HTTP/1.1 world I used to think that even if the frontend is in TCP mode,
when haproxy selects a backend in HTTP mode, it understands that this is gonna
be a HTTP session and it turned on the HTTP hut for all intends and purposes.

Of course, when both front and backend are in TCP mode and we negotiate h2
via NPN or ALPN, we have to leave it alone (just terminate TLS).

But in the "frontend->tcp mode; backend->http mode" case, should we be able to
start the H2 parsing and actually handle this case? Or is this something we are
unable to cover?

I'm certainly able to fix this issue here via configuration, I'm just
not sure if that
is the case for all the use-cases out there?



Now, comment number 3, pretty sure this is actually a bug :)

In my configuration, files transferred via HTTP2 are corrupted with
random content
from memory. I could spot my certificate, some HTTP headers and the content of
/etc/resolv.conf in the HTTP payload. Using HTTP/1.1 (even by a client
side change)
fixes this. Just H2 is affected.

How to reproduce? In my case I'm transferring a 150KB .svg file
through haproxy and
it gets corrupted every time.


The configuration is *VERY* basic (also, no filters are enabled :) ):

lukas@dev:~/haproxy$ cat ../haproxy.cfg
defaults
 timeout connect 5000
 timeout client  5
 timeout server  5
 #compression algo gzip
frontend http_in
 bind :80
 default_backend bk_testbk
frontend https_in
 mode http
 bind :443 ssl crt /home/lukas/cert/certdir/cert.pem alpn h2,http/1.1
 default_backend bk_testbk
backend bk_testbk
 mode http
 server www www.lan.ltri.eu:80

lukas@dev:~/haproxy$

Not sure what I can do to pinpoint this issue?



BTW: tomorrow is OpenSSL release day, they will publish new releases fixing a
already disclosed low severity and a undisclosed moderate level security issue:

https://mta.openssl.org/pipermail/openssl-announce/2017-October/000104.html




cheers,
lukas

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi Lukas,

On Wed, Nov 01, 2017 at 11:35:30PM +0100, Lukas Tribus wrote:
> In ALPN, the client announces the supported protocols, currently for example
> http1/1 and h2, and then the server picks a protocol out of that
> selection, based on its own preference.

Yep.

> However, with clients supporting both http/1.1 and h2 the configuration:
> alpn http/1.1,h2
> 
> always leads to HTTP/1.1 (on both curl and Chrome) here.
> 
> I had to turn it around, for HTTP/2 to be actually negotiated:
> alpn h2,http/1.1

Hmmm I think you're right, I've been doing most of my tests with "h2"
only and figured it would be good to propose h1 as well in the mail
announce so that testers don't see connections rejected!

> With the latter configuration, HTTP/2 is actually used.

OK.

> > "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,
> 
> And "alpn h2,http/1.1" does work via HTTP2 in a HTTP mode frontend.
> 
> 
> But when the frontend is in TCP mode, and the backend is in HTTP mode,

I didn't think about this use case.

> its looks like the H2 parser is not started even when ALPN negotiates h2, and
> the HTTP/1.1 only backend server receives the "PRI" connection request 
> verbatim:

That's totally true. H2 is only used if negociated by ALPN *and* the
frontend is in HTTP mode, as I couldn't find any case where we would
not want to use H2 there, so I preferred not to introduce another
option in the frontend.

> 000a:https_in.accept(0005)=0008 from [10.0.0.4:54737] ALPN=h2
> 000a:bk_testbk.clireq[0008:]: PRI * HTTP/2.0
> 000a:bk_testbk.srvrep[0008:adfd]: HTTP/1.1 400 Bad Request
> 000a:bk_testbk.srvhdr[0008:adfd]: Server: nginx/1.10.3 (Ubuntu)
> 000a:bk_testbk.srvhdr[0008:adfd]: Date: Wed, 01 Nov 2017 21:15:41 GMT
> 000a:bk_testbk.srvhdr[0008:adfd]: Content-Type: text/html
> 000a:bk_testbk.srvhdr[0008:adfd]: Content-Length: 182
> 000a:bk_testbk.srvhdr[0008:adfd]: Connection: close
> 000a:bk_testbk.srvcls[0008:adfd]
> 000b:bk_testbk.clireq[0008:]: SM
> 000b:bk_testbk.clicls[adfd:]
> 000b:bk_testbk.closed[adfd:]
> 
> 
> In the HTTP/1.1 world I used to think that even if the frontend is in TCP 
> mode,
> when haproxy selects a backend in HTTP mode, it understands that this is gonna
> be a HTTP session and it turned on the HTTP hut for all intends and purposes.

Yes but here we have to make the choice while installing the mux, it's
important to understand that we *cannot* apply the frontend's switching
rules to the preface which purposely looks like a broken request, then
decide to route it to an HTTP backend. So we have to decide of the protocol
in the frontend.

> Of course, when both front and backend are in TCP mode and we negotiate h2
> via NPN or ALPN, we have to leave it alone (just terminate TLS).

Exactly.

> But in the "frontend->tcp mode; backend->http mode" case, should we be able to
> start the H2 parsing and actually handle this case? Or is this something we 
> are
> unable to cover?

I don't see a way to cover it unfortunately. However I think the HTTP parser
needs to detect the H2 preface and immediately reject it so that we don't
end up with hung requests like this.

> I'm certainly able to fix this issue here via configuration, I'm just
> not sure if that is the case for all the use-cases out there?

We at least need to address it in the configuration. We *may* be able to
address it in the config validity checking : since we're able to detect
http frontends switching to tcp backends and report an error, we might
be able to check for the opposite when one of the frontend's "bind" lines
is configured to support H2, and then emit a warning (since some people
might very well switch to a TCP backend only when ALPN says H2 to offload
the processing somewhere else). However that would leave them with an
unfixable warning and I don't want this either, as TCP->HTTP setups are
used when you want to support multiple protocols on the same port and
ALPN is a perfect example of this. So I think the best would be to just
reject the preface in the backend and report the reason in the logs.

> Now, comment number 3, pretty sure this is actually a bug :)
> 
> In my configuration, files transferred via HTTP2 are corrupted with
> random content
> from memory. I could spot my certificate, some HTTP headers and the content of
> /etc/resolv.conf in the HTTP payload. Using HTTP/1.1 (even by a client
> side change)
> fixes this. Just H2 is affected.

Ouch, not good.

> How to reproduce? In my case I'm transferring a 150KB .svg file
> through haproxy and
> it gets corrupted every time.
> 
> 
> The configuration is *VERY* basic (also, no filters are enabled :) ):
> 
> lukas@dev:~/haproxy$ cat ../haproxy.cfg
> defaults
>  timeout connect 5000
>  timeout client  5
>  timeout server  5
>  #compression algo gzip
> frontend http_in
>  bind :80
>  default_backend bk_testbk
> frontend https_in
>  mode http
>  bind :443 ssl crt /home/luka

re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Robert Samuel Newson]

Hi,

I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact 
config works with 1.7 but says this for 1.8-rc1;

unable to stat SSL certificate from file '/path/to/foo.pem': No such file or 
directory.

That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa like 
1.7 does.

I also tried asking the mailing list daemon for help by emailing 
haproxy+h...@formilux.org as the signup confirmation specifies, the full body 
of that help is just "Hello,". I was hoping to ask the daemon to send me the 
initial message in this thread so I could reply into the thread properly. Sadly 
the mailing list archive doesn't show any of the headers I might have injected 
to get threading working that way, so sorry for breaking the thread but I 
really tried not to.

I am very excited about many of the new features in 1.8 and am itching to try 
them.

B.

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[William Lallemand]

Hi Lukas,

On Wed, Nov 01, 2017 at 09:02:53PM +0100, Willy Tarreau wrote:
> Hi Lukas,
> 
> On Wed, Nov 01, 2017 at 08:43:19PM +0100, Lukas Tribus wrote:
> > Just upgrading the binary from -dev3 to -rc1 however broke my setup:
> > Turns out that the new object caching code breaks when another filter
> > (compression) is already enabled (at config parsing stage) - even when
> > object caching is not enabled itself:
> > 
> (...)
> > 
> > lukas@dev:~/haproxy$ ./haproxy -f ../haproxy.cfg
> > [ALERT] 304/203750 (6995) : Proxy 'http_in': unable to find the cache
> > '(null)' referenced by the filter 'cache'.
> > [ALERT] 304/203750 (6995) : Proxy 'bk_testbk': unable to find the
> > cache '(null)' referenced by the filter 'cache'.
> > [ALERT] 304/203750 (6995) : Fatal errors found in configuration.
> > lukas@dev:~/haproxy$
> > 
> > Now I'm going to disable compression and try the fun stuff :)
> 

That's a bug of the post parsing callback, it tries to use the cache with a
filter which is not a cache. I just fix it in the master. 


> Thanks for reporting, such type of early breakage is indeed expected
> after I stressed everyone to merge. We know that the inned parts work
> pretty well overall but some integration work is now needed.
> 
> You may have to explicitly use the compression filter by the way,
> though I have no idea how to do that but I think it's mentionned
> somewhere in the config manual. William was about to write some doc
> when I interrupted him to get his code, but he'll certainly get back
> to this soon.

It will need a configuration filter keyword for the cache, to define the
explicit order of the filters. 

The cache might not work after the compression in the current state of the
filter API.

-- 
William Lallemand

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Dmitry Sivachenko]

> On 01 Nov 2017, at 02:20, Willy Tarreau  wrote:
> 
> Hi all!
> 


Hello,

several new warnings from clang, some look meaningful:

cc -Iinclude -Iebtree -Wall  -O2 -pipe  -fstack-protector -fno-strict-aliasing  
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv  
-Wno-address-of-packed-member -Wno-null-dereference -Wno-unused-label   
-DFREEBSD_PORTS-DTPROXY -DCONFIG_HAP_CRYPT -DUSE_GETADDRINFO -DUSE_ZLIB  
-DENABLE_POLL -DENABLE_KQUEUE -DUSE_CPU_AFFINITY -DUSE_ACCEPT4 
-DCONFIG_REGPARM=3 -DUSE_THREAD -DUSE_OPENSSL  -DUSE_PCRE -I/usr/local/include 
-DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.8-rc1-901f75c\" 
-DCONFIG_HAPROXY_DATE=\"2017/10/31\" -c -o src/standard.o src/standard.c
src/server.c:875:14: warning: address of array 'check->desc' will always
  evaluate to 'true' [-Wpointer-bool-conversion]
if (check->desc)
~~  ~~~^~~~
src/server.c:914:14: warning: address of array 'check->desc' will always
  evaluate to 'true' [-Wpointer-bool-conversion]
if (check->desc)
~~  ~~~^~~~
src/server.c:958:14: warning: address of array 'check->desc' will always
  evaluate to 'true' [-Wpointer-bool-conversion]
if (check->desc)
~~  ~~~^~~~
src/cfgparse.c:5044:34: warning: implicit conversion from 'int' to 'char'
  changes value from 130 to -126 [-Wconstant-conversion]
  ...curproxy->check_req[5] = 130;
~ ^~~
src/cfgparse.c:5070:33: warning: implicit conversion from 'int' to 'char'
  changes value from 128 to -128 [-Wconstant-conversion]
  ...curproxy->check_req[5] = 128;
~ ^~~



cc -Iinclude -Iebtree -Wall  -O2 -pipe  -fstack-protector -fno-strict-aliasing  
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv  
-Wno-address-of-packed-member -Wno-null-dereference -Wno-unused-label   
-DFREEBSD_PORTS-DTPROXY -DCONFIG_HAP_CRYPT -DUSE_GETADDRINFO -DUSE_ZLIB  
-DENABLE_POLL -DENABLE_KQUEUE -DUSE_CPU_AFFINITY -DUSE_ACCEPT4 
-DCONFIG_REGPARM=3 -DUSE_THREAD -DUSE_OPENSSL  -DUSE_PCRE -I/usr/local/include 
-DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.8-rc1-901f75c\" 
-DCONFIG_HAPROXY_DATE=\"2017/10/31\" -c -o src/sample.o src/sample.c
src/peers.c:255:16: warning: implicit conversion from 'int' to 'char' changes
  value from 133 to -123 [-Wconstant-conversion]
*msg_type = PEER_MSG_STKT_UPDATE_TIMED;
  ~ ^~
src/peers.c:257:16: warning: implicit conversion from 'int' to 'char' changes
  value from 134 to -122 [-Wconstant-conversion]
*msg_type = PEER_MSG_STKT_INCUPDATE_TIMED;
  ~ ^
src/peers.c:261:16: warning: implicit conversion from 'int' to 'char' changes
  value from 128 to -128 [-Wconstant-conversion]
*msg_type = PEER_MSG_STKT_UPDATE;
  ~ ^~~~
src/peers.c:263:16: warning: implicit conversion from 'int' to 'char' changes
  value from 129 to -127 [-Wconstant-conversion]
*msg_type = PEER_MSG_STKT_INCUPDATE;
  ~ ^~~
src/peers.c:450:11: warning: implicit conversion from 'int' to 'char' changes
  value from 130 to -126 [-Wconstant-conversion]
msg[1] = PEER_MSG_STKT_DEFINE;
   ~ ^~~~
src/peers.c:486:11: warning: implicit conversion from 'int' to 'char' changes
  value from 132 to -124 [-Wconstant-conversion]
msg[1] = PEER_MSG_STKT_ACK;
   ~ ^



cc -Iinclude -Iebtree -Wall  -O2 -pipe  -fstack-protector -fno-strict-aliasing  
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv  
-Wno-address-of-packed-member -Wno-null-dereference -Wno-unused-label   
-DFREEBSD_PORTS-DTPROXY -DCONFIG_HAP_CRYPT -DUSE_GETADDRINFO -DUSE_ZLIB  
-DENABLE_POLL -DENABLE_KQUEUE -DUSE_CPU_AFFINITY -DUSE_ACCEPT4 
-DCONFIG_REGPARM=3 -DUSE_THREAD -DUSE_OPENSSL  -DUSE_PCRE -I/usr/local/include 
-DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.8-rc1-901f75c\" 
-DCONFIG_HAPROXY_DATE=\"2017/10/31\" -c -o src/freq_ctr.o src/freq_ctr.c
src/mux_h2.c:1734:15: warning: implicit conversion from enumeration type
  'enum h2_ss' to different enumeration type 'enum h2_cs'
  [-Wenum-conversion]
h2c->st0 = H2_SS_ERROR;
 ~ ^~~
src/mux_h2.c:2321:15: warning: implicit conversion from enumeration type
  'enum h2_ss' to different enumeration type 'enum h2_cs'
  [-Wenum-conversion]
h2c->st0 = H2_SS_ERROR;
 ~ ^~~
src/mux_h2.c:2435:15: warning: implicit conversion from enumeration type
  'enum h2_ss' to different enumeration type 'enum h2_cs'
  [-Wenum-conversion]
h2c->st0 = H2_SS_ERROR;

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi Dmitry,

On Fri, Nov 03, 2017 at 03:11:21PM +0300, Dmitry Sivachenko wrote:
> Hello,
> 
> several new warnings from clang, some look meaningful:

Thanks, Olivier also reported some of them. Some are valid or easy
to address, others might need some -Wno-something I guess.

> src/server.c:875:14: warning: address of array 'check->desc' will always
>   evaluate to 'true' [-Wpointer-bool-conversion]
> if (check->desc)
> ~~  ~~~^~~~

This one needs to be fixed, I think we moved from a pointer to a char[]
and the test is not needed anymore.

> src/cfgparse.c:5044:34: warning: implicit conversion from 'int' to 'char'
>   changes value from 130 to -126 [-Wconstant-conversion]
>   ...curproxy->check_req[5] = 130;
> ~ ^~~
> src/cfgparse.c:5070:33: warning: implicit conversion from 'int' to 'char'
>   changes value from 128 to -128 [-Wconstant-conversion]
>   ...curproxy->check_req[5] = 128;
> ~ ^~~

We've seen this one the other way around in the past, you assing a negative
number to shut it up and it complains on arm where chars are unsigned. I
*seem* to remember that it doesn't complain when entered in hexadecimal
form though, we'll have to try (if you want to, feel free to send a patch
if it works using 0x82 and 0x80).

> cc -Iinclude -Iebtree -Wall  -O2 -pipe  -fstack-protector 
> -fno-strict-aliasing  -fno-strict-aliasing -Wdeclaration-after-statement 
> -fwrapv  -Wno-address-of-packed-member -Wno-null-dereference 
> -Wno-unused-label   -DFREEBSD_PORTS-DTPROXY -DCONFIG_HAP_CRYPT 
> -DUSE_GETADDRINFO -DUSE_ZLIB  -DENABLE_POLL -DENABLE_KQUEUE 
> -DUSE_CPU_AFFINITY -DUSE_ACCEPT4 -DCONFIG_REGPARM=3 -DUSE_THREAD 
> -DUSE_OPENSSL  -DUSE_PCRE -I/usr/local/include -DUSE_PCRE_JIT  
> -DCONFIG_HAPROXY_VERSION=\"1.8-rc1-901f75c\" 
> -DCONFIG_HAPROXY_DATE=\"2017/10/31\" -c -o src/sample.o src/sample.c
> src/peers.c:255:16: warning: implicit conversion from 'int' to 'char' changes
>   value from 133 to -123 [-Wconstant-conversion]
> *msg_type = PEER_MSG_STKT_UPDATE_TIMED;
>   ~ ^~

Same here, though this one is an enum and I would hate to have to start
to use casts for this, casts are only made to secretly hide bugs :-(
I think the pointer could be an unsigned char though. We'll have to
check if it yells somewhere else.

> cc -Iinclude -Iebtree -Wall  -O2 -pipe  -fstack-protector 
> -fno-strict-aliasing  -fno-strict-aliasing -Wdeclaration-after-statement 
> -fwrapv  -Wno-address-of-packed-member -Wno-null-dereference 
> -Wno-unused-label   -DFREEBSD_PORTS-DTPROXY -DCONFIG_HAP_CRYPT 
> -DUSE_GETADDRINFO -DUSE_ZLIB  -DENABLE_POLL -DENABLE_KQUEUE 
> -DUSE_CPU_AFFINITY -DUSE_ACCEPT4 -DCONFIG_REGPARM=3 -DUSE_THREAD 
> -DUSE_OPENSSL  -DUSE_PCRE -I/usr/local/include -DUSE_PCRE_JIT  
> -DCONFIG_HAPROXY_VERSION=\"1.8-rc1-901f75c\" 
> -DCONFIG_HAPROXY_DATE=\"2017/10/31\" -c -o src/freq_ctr.o src/freq_ctr.c
> src/mux_h2.c:1734:15: warning: implicit conversion from enumeration type
>   'enum h2_ss' to different enumeration type 'enum h2_cs'
>   [-Wenum-conversion]
> h2c->st0 = H2_SS_ERROR;
>  ~ ^~~

I'm aware (and ashamed) of these ones already, I need to understand what I
wanted to set to know how to fix it (currently dealing with a much uglier
one).

> src/mux_h2.c:526:24: warning: unused function 'h2_get_n64' [-Wunused-function]

Ah now it starts to report this also for inlines ? It'll get pretty annoying
then as it prevents one from creating all the useful tools at once for later
use :-/  No idea how to shut up this one, maybe in the long term we'll also
need -Wno-unused-function.

> src/cache.c:176:7: warning: variable 'ret' is used uninitialized whenever 'if'
>   condition is false [-Wsometimes-uninitialized]
> if (len) {
> ^~~
> src/cache.c:202:7: note: uninitialized use occurs here
> if ((ret != len) ||
>  ^~~
> src/cache.c:176:3: note: remove the 'if' if its condition is always true
> if (len) {
> ^
> src/cache.c:151:9: note: initialize the variable 'ret' to silence this warning
> int ret;
>^
> = 0

Thanks, these ones may indeed be useful.

> src/cache.c:566:9: warning: implicit conversion from enumeration type
>   'enum act_return' to different enumeration type 'enum act_parse_ret'
>   [-Wenum-conversion]
> return ACT_RET_ERR;
> ~~ ^~~

I noted these ones as well.

> In file included from ../../ebtree/ebtree.c:21:
> ../../ebtree/ebtree.h:469:35: warning: taking address of packed member
>   'branches' of class or structure 'eb_node' may result in an unaligned
>   pointer value [-Waddress-of-packed-member]
> eb_troot_t *new_left = eb_dotag(&new->branches, EB_LEFT);
>   

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

Hi Robert,

On Thu, Nov 02, 2017 at 03:58:47PM +, Robert Samuel Newson wrote:
> Hi,
> 
> I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact 
> config works with 1.7 but says this for 1.8-rc1;
> 
> unable to stat SSL certificate from file '/path/to/foo.pem': No such file or 
> directory.
> 
> That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa 
> like 1.7 does.

Oh bad, that's totally unexpected. I'm CCing Emeric and Manu, the former
being the SSL maintainer (in case he has a quick idea about it) and the
latter having upgraded a large part of the cert management code, possibly
having an idea about anything that could have gone wrong.

> I also tried asking the mailing list daemon for help by emailing
> haproxy+h...@formilux.org as the signup confirmation specifies, the full body
> of that help is just "Hello,". I was hoping to ask the daemon to send me the
> initial message in this thread so I could reply into the thread properly.
> Sadly the mailing list archive doesn't show any of the headers I might have
> injected to get threading working that way, so sorry for breaking the thread
> but I really tried not to.

I was not even aware of the feature :-)

> I am very excited about many of the new features in 1.8 and am itching to try
> them.

As long as you're very careful that's useful. I'm going to issue an rc2 with
the most painful bugs fixed.

Thanks for the report,
Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Robert Newson]

It seems to only be some versions of OpenSSL. I’ll go over this again more 
carefully and keep notes. I was trying out tls 1.3 support as well, so it might 
be specific to OpenSSL 1.1.1-dev. 

Sent from my iPhone

> On 3 Nov 2017, at 22:33, Willy Tarreau  wrote:
> 
> Hi Robert,
> 
>> On Thu, Nov 02, 2017 at 03:58:47PM +, Robert Samuel Newson wrote:
>> Hi,
>> 
>> I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact 
>> config works with 1.7 but says this for 1.8-rc1;
>> 
>> unable to stat SSL certificate from file '/path/to/foo.pem': No such file or 
>> directory.
>> 
>> That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa 
>> like 1.7 does.
> 
> Oh bad, that's totally unexpected. I'm CCing Emeric and Manu, the former
> being the SSL maintainer (in case he has a quick idea about it) and the
> latter having upgraded a large part of the cert management code, possibly
> having an idea about anything that could have gone wrong.
> 
>> I also tried asking the mailing list daemon for help by emailing
>> haproxy+h...@formilux.org as the signup confirmation specifies, the full body
>> of that help is just "Hello,". I was hoping to ask the daemon to send me the
>> initial message in this thread so I could reply into the thread properly.
>> Sadly the mailing list archive doesn't show any of the headers I might have
>> injected to get threading working that way, so sorry for breaking the thread
>> but I really tried not to.
> 
> I was not even aware of the feature :-)
> 
>> I am very excited about many of the new features in 1.8 and am itching to try
>> them.
> 
> As long as you're very careful that's useful. I'm going to issue an rc2 with
> the most painful bugs fixed.
> 
> Thanks for the report,
> Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

On Sat, Nov 04, 2017 at 09:17:23AM +, Robert Newson wrote:
> It seems to only be some versions of OpenSSL. I'll go over this again more 
> carefully and keep notes. I was trying out tls 1.3 support as well, so it 
> might be specific to OpenSSL 1.1.1-dev. 

Thanks, this is helpful.

Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Robert Newson]

It’s only 1.0.1 that’s affected, so I’m inferring that predates support for 
serving multiple certificate types; it’s not an haproxy regression. 

I’ve failed in all attempts to try tls 1.3 though. Haproxy segfaults very soon 
after startup. I tried several OpenSSL versions.

Sent from my iPhone

> On 4 Nov 2017, at 09:17, Robert Newson  wrote:
> 
> It seems to only be some versions of OpenSSL. I’ll go over this again more 
> carefully and keep notes. I was trying out tls 1.3 support as well, so it 
> might be specific to OpenSSL 1.1.1-dev. 
> 
> Sent from my iPhone
> 
>> On 3 Nov 2017, at 22:33, Willy Tarreau  wrote:
>> 
>> Hi Robert,
>> 
>>> On Thu, Nov 02, 2017 at 03:58:47PM +, Robert Samuel Newson wrote:
>>> Hi,
>>> 
>>> I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact 
>>> config works with 1.7 but says this for 1.8-rc1;
>>> 
>>> unable to stat SSL certificate from file '/path/to/foo.pem': No such file 
>>> or directory.
>>> 
>>> That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa 
>>> like 1.7 does.
>> 
>> Oh bad, that's totally unexpected. I'm CCing Emeric and Manu, the former
>> being the SSL maintainer (in case he has a quick idea about it) and the
>> latter having upgraded a large part of the cert management code, possibly
>> having an idea about anything that could have gone wrong.
>> 
>>> I also tried asking the mailing list daemon for help by emailing
>>> haproxy+h...@formilux.org as the signup confirmation specifies, the full 
>>> body
>>> of that help is just "Hello,". I was hoping to ask the daemon to send me the
>>> initial message in this thread so I could reply into the thread properly.
>>> Sadly the mailing list archive doesn't show any of the headers I might have
>>> injected to get threading working that way, so sorry for breaking the thread
>>> but I really tried not to.
>> 
>> I was not even aware of the feature :-)
>> 
>>> I am very excited about many of the new features in 1.8 and am itching to 
>>> try
>>> them.
>> 
>> As long as you're very careful that's useful. I'm going to issue an rc2 with
>> the most painful bugs fixed.
>> 
>> Thanks for the report,
>> Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

On Sat, Nov 04, 2017 at 01:33:30PM +, Robert Newson wrote:
> It's only 1.0.1 that's affected, so I'm inferring that predates support for
> serving multiple certificate types; it's not an haproxy regression. 
> 
> I've failed in all attempts to try tls 1.3 though. Haproxy segfaults very
> soon after startup. I tried several OpenSSL versions.

I've emitted -rc2 last night, though if you were relying on the latest -git
it's probably about the same. So I would be *very* interested in knowing if
you still see the segfault and if so, how to reproduce it!

Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Robert Samuel Newson]

-rc2 went cpu bound on all threads (nbthread 8 fwiw) where the only thing I 
changed was haproxy.

B.

> On 4 Nov 2017, at 16:17, Willy Tarreau  wrote:
> 
> On Sat, Nov 04, 2017 at 01:33:30PM +, Robert Newson wrote:
>> It's only 1.0.1 that's affected, so I'm inferring that predates support for
>> serving multiple certificate types; it's not an haproxy regression. 
>> 
>> I've failed in all attempts to try tls 1.3 though. Haproxy segfaults very
>> soon after startup. I tried several OpenSSL versions.
> 
> I've emitted -rc2 last night, though if you were relying on the latest -git
> it's probably about the same. So I would be *very* interested in knowing if
> you still see the segfault and if so, how to reproduce it!
> 
> Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Willy Tarreau]

On Sat, Nov 04, 2017 at 04:46:28PM +, Robert Samuel Newson wrote:
> -rc2 went cpu bound on all threads (nbthread 8 fwiw) where the only thing I 
> changed was haproxy.

OK. I think we'll have to exchange off-list with your config and
anything that can help figure what it happening.

Thanks,
Willy

Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Emmanuel Hocdet]

Hi Robert,

> Le 4 nov. 2017 à 14:33, Robert Newson  a écrit :
> 
> It’s only 1.0.1 that’s affected, so I’m inferring that predates support for 
> serving multiple certificate types; it’s not an haproxy regression. 
> 

yes, multiple certificate bundle only work with openssl >= 1.0.2

> I’ve failed in all attempts to try tls 1.3 though. Haproxy segfaults very 
> soon after startup. I tried several OpenSSL versions.
> 
> Sent from my iPhone

++
Manu

Re[2]: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Aleksandar Lazic]

Hi.

-- Originalnachricht --
Von: "Willy Tarreau" 
An: "Cyril Bonté" 
Cc: haproxy@formilux.org
Gesendet: 01.11.2017 07:44:23
Betreff: Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile


Hi Cyril,

On Wed, Nov 01, 2017 at 01:03:42AM +0100, Cyril Bonté wrote:
This announcement was exciting enough to take some time to regenerate 
an up

to date HTML documentation ! 1.8-rc1 is now available :
http://cbonte.github.io/haproxy-dconv/1.8/configuration.html


Cool, thank you!


> Have fun,
> Willy -- feeling exhausted like a marathoner :-)

Great job ! Now it's time to test and track nasty bugs before the 
final 1.8

release ;-)


Yep. And we know certain points already have to be fixed. The real 
great
thing is to be allowed to sleep a full night for the first time in a 
few

months ;-)

Have a good and refreshing sleep ;-)

Thanks for the hard work ;-)

There is now a shiny new docker image with the rc1.

docker run --rm --entrypoint /usr/local/sbin/haproxy 
me2digital/haproxy18 -vv



HA-Proxy version 1.8-rc1-901f75c 2017/10/31
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET = linux2628
  CPU = generic
  CC = gcc
  CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement 
-fwrapv -Wno-unused-label
  OPTIONS = USE_LINUX_SPLICE=1 USE_GETADDRINFO=1 USE_ZLIB=1 
USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 
USE_TFO=1


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


Built with OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017
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.4
Built with transparent proxy support using: IP_TRANSPARENT 
IPV6_TRANSPARENT IP_FREEBIND

Built with network namespace support.
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

Encrypted password support via crypt(3): yes
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes

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




Cheers,
Willy


Regards
Aleks

Re[2]: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

[Aleksandar Lazic]

-- Originalnachricht --
Von: "Bryan Talbot" 
An: "Aleksandar Lazic" 
Cc: "HAproxy Mailing Lists" 
Gesendet: 01.11.2017 21:25:34
Betreff: Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile

On Nov 1, 2017, at Nov 1, 3:28 AM, Aleksandar Lazic  
wrote:



There is now a shiny new docker image with the rc1.

docker run --rm --entrypoint /usr/local/sbin/haproxy 
me2digital/haproxy18 -vv


For the past couple of years, I’ve also been maintaining a base docker 
image for haproxy. It is interesting to see how other’s structure the 
build and configuration.


I see that you include a base / default configuration file while I’ve 
left that completely up to the user to provide one. Given how many 
different ways people use haproxy, it didn’t seem that there was any 
one “basic” config that would work beyond a trivial example. I’m 
curious how useful the configuration you’ve packaged is. I use my image 
as a base which I then repackage use-case specific configuration files 
into for deployments and I assume anyone else using the image does the 
same thing, but I do not have any feedback about that.


https://hub.docker.com/r/fingershock/haproxy-base/

-Bryan


Well the reason why I use a default config file is that most enterprise 
customer mainly don't know how to configure the haproxy.
They know the destination ip:port and on which port the service should 
listen.


This makes the usage of that image much easier, from my point of view.
That's the reason why the openshift template exist.

https://gitlab.com/aleks001/haproxy17-centos/blob/master/haproxy-osev3.yaml

You can use this image easily as ingress or egress proxy with 0 
knowledge of haproxy.


I have described the setup a little bit in this blog post.

https://www.me2digital.com/blog/2017/08/openshift-egress-options/#haproxy-generic-proxy

With the environment variable CONFIG_FILE is it possible to use a 
complete custom haproxy config file.
This can be provided as you described with -v in docker mode or with 
config maps in kubernetes and openshift.


Another point is the logging.

I have added socklog into the image to get haproxy logs to stdout.

Sometimes you have now syslog server where you can send the haproxy logs 
therefore the default setup in the image uses the socklog which is 
designed to write to stdout and listen to a ip or unix socket.


http://smarden.org/socklog/

This could be easily overwritten by env vars

https://gitlab.com/aleks001/haproxy17-centos/blob/master/containerfiles/container-entrypoint.sh#L5

One of the reason why I have added all this into the image is that the 
security level in openshift is quite high, which is good from my point 
of view, but due to this fact you can's just use rsyslog image or 
something else which requires root privileges.


Another feature is that the prometheus scrapper is there and is used as 
sidecar container, at least in my openshift template.


I know there are some options to improve the image, I'm open for 
suggestions, issues, pull requests ;-)


I hope I have bring some light to the question why I have build this 
image.


Regards
Aleks