Welcome! Log In Create A New Profile

Advanced

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

Posted by Willy Tarreau 
Willy Tarreau
[ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 12:30AM
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 client advertises ALPN "h2" it will be used, otherwise it
will fall back to HTTP/1.1. You'll need to have 16kB or larger buffers
(that's the default value and may be adjusted using tune.bufsize).
It's only supported over TLS for now. Note, on openssl versions before
1.0.2, you need to use "npn" instead of "alpn", but I don't know how
long browsers will support it.

- TLS1.3 0-RTT done right : while there is a lot of demand for 0-RTT
support everywhere (which people often just call TLS1.3 by the way),
it's important to remember that by default 0-RTT makes TLS vulnerable
to replay attacks and that the upper protocol must take care of this.
The IETF HTTP working group has been working on a draft to define how
to safely map HTTP on top of 0-RTT to provide both performance and
security (https://tools.ietf.org/html/draft-ietf-httpbis-replay-00).
HAProxy 1.8-rc1 is the first server-side component to implement this
draft, and we'll soon run some interoperability tests with a well
known browser which just implemented it as well on the client side.
This can be enabled using openssl-1.1.1 (still in development as well)
and the "allow-0rtt" directive on the bind line.

That's more or less all for the user-visible changes, the rest are important
infrastructure changes supporting this work. That's why it was important to
merge right now, so that we all have a common base to start sorting out the
various issues that will inevitably emerge, and finish the documentation and
the configuration mechanisms. I'm not listing all the things that were
already merged in earlier versions (JSON stats, server-templates, SRV records
etc), I'll try to recap everything for the release.

If you have suggestions (especially on the configuration perspective), feel
free to suggest ideas here on the list so that everyone can participate (and
please use a different thread to address different topics so that participants
are not forced to receive the parts they're not interested in).

Ah last thing. Yes I know it's fun to deploy a fresh new load balancer in
production, and I was about to do it on haproxy.org. I was lucky it took only
2 seconds to enter an endless loop, it's less fun if it happens when you're
driving on your way back home. So use with care, on dedicated servers only,
with non-critical traffic only, and keep an eye on it. Do not hesitate to
report strange things here, we all know it encourages the "me too" behaviour.

I hope we'll be able to quickly sort out the thread+check problem and emit an
rc2, in the worst case in a week or two. Given that the code merge was *much*
faster than anticipated, I wouldn't be surprized if we can release 1.8 by end
of November with everything working (=nobody knows how to break it yet).

Please find the usual URLs below :
Site index : http://www.haproxy.org/
Discourse : http://discourse.haproxy.org/
Sources : http://www.haproxy.org/download/1.8/src/
Git repository : http://git.haproxy.org/git/haproxy-1.8.git/
Git Web browsing : http://git.haproxy.org/?p=haproxy-1.8.git
Changelog : http://www.haproxy.org/download/1.8/src/CHANGELOG
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

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

Complete changelog :
Baptiste Assmann (1):
MINOR: lua: add uuid to the Class Proxy

Christopher Faulet (69):
BUG/MINOR: spoe: Don't compare engine name and SPOE scope when both are NULL
BUG/MINOR: spoa: Update pointer on the end of the frame when a reply is encoded
MINOR: action: Add trk_idx inline function
MINOR: action: Use trk_idx instead of tcp/http_trk_idx
MINOR: action: Add a function pointer in act_rule struct to check its validity
MINOR: action: Add function to check rules using an action ACT_ACTION_TRK_*
MINOR: action: Add a functions to check http capture rules
MINOR: action: Factorize checks on rules calling check_ptr if defined
MINOR: acl: Pass the ACLs as an explicit parameter of build_acl_cond
MEDIUM: spoe: Add support of ACLS to enable or disable sending of SPOE messages
MINOR: spoe: Check uniqness of SPOE engine names during config parsing
MEDIUM: spoe: Parse new "spoe-group" section in SPOE config file
MEDIUM: spoe/rules: Add "send-spoe-group" action for tcp/http rules
MINOR: spoe: Move message encoding in its own function
MINOR: spoe: Add a type to qualify the message list during encoding
MINOR: spoe: Add a generic function to encode a list of SPOE message
MEDIUM: spoe/rules: Process "send-spoe-group" action
BUG/MINOR: dns: Fix CLI keyword declaration
MAJOR: dns: Refactor the DNS code
BUG/MINOR: mailers: Fix a memory leak when email alerts are released
MEDIUM: mailers: Init alerts during conf parsing and refactor their processing
MINOR: mailers: Use pools to allocate email alerts and its tcpcheck_rules
MINOR: standard: Add memvprintf function
MINOR: log: Save alerts and warnings emitted during HAProxy startup
MINOR: cli: Add "show startup-logs" command
MINOR: startup: Extend the scope the MODE_STARTING flag
MINOR: threads: Add THREAD_LOCAL macro
MEDIUM: threads: Add hathreads header file
MINOR: threads: Add mechanism to register per-thread init/deinit functions
MINOR: threads: Add nbthread parameter
MEDIUM: threads: Adds a set of functions to handle sync-point
MAJOR: threads: Start threads to experiment multithreading
MINOR: threads: Define the sync-point inside run_poll_loop
MEDIUM: threads/buffers: Define and register per-thread init/deinit functions
MEDIUM: threads/chunks: Transform trash chunks in thread-local variables
MEDIUM: threads/time: Many global variables from time.h are now thread-local
MEDIUM: threads/logs: Make logs thread-safe
MEDIUM: threads/pool: Make pool thread-safe by locking all access to a pool
MAJOR: threads/fd: Make fd stuffs thread-safe
MINOR: threads/fd: Add a mask of threads allowed to process on each fd in fdtab array
MEDIUM: threads/fd: Initialize the process mask during the call to fd_insert
MINOR: threads/fd: Process cached events of FDs depending on the process mask
MINOR: threads/polling: pollers now handle FDs depending on the process mask
WIP: SQUASH WITH SYNC POINT
MEDIUM: threads/signal: Add a lock to make signals thread-safe
MEDIUM: threads/listeners: Make listeners thread-safe
MEDIUM: threads/proxy: Add a lock per proxy and atomically update proxy vars
MEDIUM: threads/server: Make connection list (priv/idle/safe) thread-safe
MEDIUM: threads/server: Add a lock per server and atomically update server vars
MINOR: threads/server: Add a lock to deal with insert in updates_servers list
MEDIUM: threads/lb: Make LB algorithms (lb_*.c) thread-safe
MEDIUM: threads/queue: Make queues thread-safe
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe
MEDIUM: thread/vars: Make vars thread-safe
MEDIUM: threads/filters: Add init/deinit callback per thread
MINOR: threads/filters: Update trace filter to add _per_thread callbacks
MEDIUM: threads/compression: Make HTTP compression thread-safe
MEDIUM: thread/spoe: Make the SPOE thread-safe
MEDIUM: thread/dns: Make DNS thread-safe
MINOR: threads: Add thread-map config parameter in the global section
MINOR: threads/checks: Add a lock to protect the pid list used by external checks
MINOR: threads/checks: Set the task process_mask when a check is executed
MINOR: threads/mailers: Add a lock to protect queues of email alerts
MINOR: threads: Don't start when device a detection module is used
BUG/MEDIUM: threads: Run the poll loop on the main thread too
BUG/MINOR: threads: Add missing THREAD_LOCAL on static here and there
MAJOR: threads: Offically enable the threads support in HAProxy
BUG/MAJOR: threads/time: Store the time deviation in an 64-bits integer
BUG/MEDIUM: threads: Initialize the sync-point

Dragan Dosen (4):
IMPORT: sha1: import SHA1 functions
MINOR: sample: add the sha1 converter
MINOR: sample: add the hex2i converter
BUG/MEDIUM: prevent buffers being overwritten during build_logline() execution

Emeric Brun (15):
MINOR: threads: Prepare makefile to link with pthread
MINOR: threads: Add atomic-ops and plock includes in import dir
MAJOR: threads/task: handle multithread on task scheduler
MEDIUM: threads/stick-tables: handle multithreads on stick tables
MINOR: threads/sample: Change temp_smp into a thread local variable
MEDIUM: threads/http: Make http_capture_bad_message thread-safe
MINOR: threads/regex: Change Regex trash buffer into a thread local variable
MAJOR: threads/applet: Handle multithreading for applets
MAJOR: threads/peers: Make peers thread safe
MAJOR: threads/buffer: Make buffer wait queue thread safe
MEDIUM: threads/stream: Make streams list thread safe
MAJOR: threads/ssl: Make SSL part thread-safe
MAJOR: threads/map: Make acls/maps thread safe
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters.

Emmanuel Hocdet (9):
BUILD: ssl: support OPENSSL_NO_ASYNC #define
MINOR: ssl: build with recent BoringSSL library
BUG/MINOR: ssl: OCSP_single_get0_status can return -1
MEDIUM: ssl: convert CBS (BoringSSL api) usage to neutral code
MINOR: ssl: support Openssl 1.1.1 early callback for switchctx
MINOR: ssl: generated certificate is missing in switchctx early callback
MINOR: update proxy-protocol-v2 #define
MINOR: merge ssl_sock_get calls for log and ppv2
MINOR: add ALPN information to send-proxy-v2

Lukas Tribus (2):
BUG/MINOR: cli: restore "set ssl tls-key" command
CLEANUP: cli: remove undocumented "set ssl tls-keys" command

Olivier Houchard (12):
BUG/MEDIUM: server: Allocate tmptrash before using it.
BUG/MINOR: checks: Don't forget to release the connection on error case.
MINOR: http: Mark the 425 code as "Too Early".
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1
MINOR: ssl/proto_http: Add keywords to take care of early data.
MINOR: ssl: Don't abuse ssl_options.
BUG/MINOR: dns: Fix SRV records with the new thread code.
MINOR: ssl: Remove the global allow-0rtt option.
MINOR: connection: introduce conn_stream
MINOR: mux: add more methods to mux_ops
MINOR: mux_pt: implement remaining mux_ops methods
MAJOR: connection : Split struct connection into struct connection and struct conn_stream.

Thierry FOURNIER (8):
MINOR: hlua: Add regex class
BUG/MINOR: lua: const attribute of a string is overridden
MEDIUM: threads/lua: Makes the jmpbuf and some other buffers local to the current thread.
MEDIUM: threads/lua: Add locks around the Lua execution parts.
MEDIUM: threads/lua: Ensure that the launched tasks runs on the same threads than me
MEDIUM: threads/lua: Cannot acces to the socket if we try to access from another thread.
MEDIUM: threads/xref: Convert xref function to a thread safe model
MEDIUM: threads/tasks: Add lock around notifications

William Lallemand (13):
MEDIUM: cfgparse: post section callback
MEDIUM: cfgparse: post parsing registration
CLEANUP: shctx: get ride of the shsess_packet{_hdr} structures
MEDIUM: lists: list_for_each_entry{_safe}_from functions
REORG: shctx: move lock functions and struct
MEDIUM: shctx: allow the use of multiple shctx
REORG: shctx: move ssl functions to ssl_sock.c
MEDIUM: shctx: separate ssl and shctx
MINOR: shctx: rename lock functions
MEDIUM: shctx: forbid shctx to read more than expected
MEDIUM: cache: configuration parsing and initialization
MEDIUM: cache: store objects in cache
MEDIUM: cache: deliver objects from cache

Willy Tarreau (110):
CONTRIB: trace: add the possibility to place trace calls in the code
CONTRIB: trace: try to display the function's return value on exit
CONTRIB: trace: report the base name only for file names
MINOR: stream-int: stop checking for useless connection flags in chk_snd_conn
MINOR: ssl: don't abort after sending 16kB
MINOR: connection: move the cleanup of flag CO_FL_WAIT_ROOM
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted
MEDIUM: connection: make use of CO_FL_WILL_UPDATE in conn_sock_shutw()
MINOR: raw_sock: make use of CO_FL_WILL_UPDATE
MINOR: ssl_sock: make use of CO_FL_WILL_UPDATE
MINOR: buffer: add the buffer input manipulation functions
BUILD: Makefile: disable -Wunused-label
MEDIUM: h1: ensure that 1xx, 204 and 304 don't have a payload body
MINOR: h1: store the status code in the H1 message
BUILD: stick-tables: silence an uninitialized variable warning
CLEANUP: threads: replace the last few 1UL<<tid with tid_bit
CLEANUP: threads: rename process_mask to thread_mask
MINOR: h1: add a function to measure the trailers length
MINOR: threads: add a portable barrier for threads and non-threads
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes
MEDIUM: connection: start to introduce a mux layer between xprt and data
MINOR: connection: implement alpn registration of muxes
MINOR: mux: register the pass-through mux for any ALPN string
MEDIUM: session: use the ALPN token and proxy mode to select the mux
MINOR: connection: report the major HTTP version from the MUX for logging (fc_http_major)
MINOR: connection: introduce the conn_stream manipulation functions
MINOR: connection: make conn_stream users also check for per-stream error flag
MINOR: conn_stream: new shutr/w status flags
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode
MEDIUM: connection: make conn_sock_shutw() aware of lingering
MINOR: connection: add cs_close() to close a conn_stream
MEDIUM: mux_pt: make cs_shutr() / cs_shutw() properly close the connection
MEDIUM: connection: replace conn_full_close() with cs_close()
MEDIUM: connection: make mux->detach() release the connection
MEDIUM: stream: do not forcefully close the client connection anymore
MEDIUM: checks: exclusively use cs_destroy() to release a connection
MEDIUM: connection: add a destroy callback
MINOR: session: release the listener with the session, not the stream
MEDIUM: session: make use of the connection's destroy callback
CONTRIB: hpack: implement a reverse huffman table generator for hpack
MINOR: hpack: implement the HPACK Huffman table decoder
MINOR: hpack: implement the header tables management
MINOR: hpack: implement the decoder
MEDIUM: hpack: implement basic hpack encoding
MINOR: h2: centralize all HTTP/2 protocol elements and constants
MINOR: h2: create a very minimalistic h2 mux
MINOR: h2: expose tune.h2.header-table-size to configure the table size
MINOR: h2: expose tune.h2.initial-window-size to configure the window size
MINOR: h2: expose tune.h2.max-concurrent-streams to limit the number of streams
MINOR: h2: create the h2c struct and allocate its pool
MINOR: h2: create the h2s struct and the associated pool
MINOR: h2: handle two extra stream states for errors
MINOR: h2: add a frame header descriptor for incoming frames
MEDIUM: h2: allocate and release the h2c context on connection init/end
MEDIUM: h2: implement basic recv/send/wake functions
MEDIUM: h2: dynamically allocate the demux buffer on Rx
MEDIUM: h2: implement the mux buffer allocator
MINOR: h2: add the connection and stream flags listing the causes for blocking
MINOR: h2: add function h2s_id() to report a stream's ID
MINOR: h2: small function to know when the mux is busy
MINOR: h2: new function h2c_error to mark an error on the connection
MINOR: h2: new function h2s_error() to mark an error on a stream
MINOR: h2: add h2_set_frame_size() to update the size in a binary frame
MINOR: h2: new function h2_peek_frame_hdr() to retrieve a new frame header
MINOR: h2: add a few functions to retrieve contents from a wrapping buffer
MINOR: h2: add stream lookup function based on the stream ID
MINOR: h2: create dummy idle and closed streams
MINOR: h2: add the function to create a new stream
MINOR: h2: update the {MUX,DEM}_{M,D}ALLOC flags on buffer availability
MEDIUM: h2: start to consider the H2_CF_{MUX,DEM}_* flags for polling
MINOR: h2: also terminate the connection on shutr
MEDIUM: h2: properly consider all conditions for end of connection
MEDIUM: h2: wake the connection up for send on pending streams
MEDIUM: h2: start to implement the frames processing loop
MINOR: h2: add a function to send a GOAWAY error frame
MINOR: h2: match the H2 connection preface on init
MEDIUM: h2: enable connection polling for send when a cs wants to emit
MEDIUM: h2: enable reading again on the connection if it was blocked on stream buffer full
MEDIUM: h2: process streams pending for sending
MINOR: h2: send a real SETTINGS frame based on the configuration
MEDIUM: h2: detect the presence of the first settings frame
MINOR: h2: create a stream parser for the demuxer
MINOR: h2: implement PING frames
MEDIUM: h2: decode SETTINGS frames and extract relevant settings
MINOR: h2: lookup the stream during demuxing
MEDIUM: h2: honor WINDOW_UPDATE frames
MINOR: h2: implement h2_send_rst_stream() to send RST_STREAM frames
MINOR: h2: handle CONTINUATION frames
MEDIUM: h2: partial implementation of h2_detach()
MEDIUM: h2: unblock a connection when its current stream detaches
MEDIUM: h2: basic processing of HEADERS frame
MEDIUM: h2: don't use trash to decode headers!
MEDIUM: h2: implement the response HEADERS frame to encode the H1 response
MEDIUM: h2: send the H1 response body as DATA frames
MEDIUM: h2: skip the response trailers if any
MEDIUM: h2: properly continue to parse header block when facing a 1xx response
MEDIUM: h2: send WINDOW_UPDATE frames for connection
MEDIUM: h2: handle request body in DATA frames
MINOR: h2: handle RST_STREAM frames
MEDIUM: h2: send DATA+ES or RST_STREAM on shutw/shutr
MINOR: h2: use a common function to signal some and all streams.
MEDIUM: h2: handle GOAWAY frames
MINOR: h2: centralize the check for the idle streams
MINOR: h2: centralize the check for the half-closed(remote) streams
MEDIUM: h2: silently ignore frames higher than last_id after GOAWAY
MINOR: h2: properly reject PUSH_PROMISE frames coming from the client
MEDIUM: h2: perform a graceful shutdown on "Connection: close"
MEDIUM: h2: send a GOAWAY frame when dealing with an empty response
MEDIUM: h2: apply a timeout to h2 connections
BUG/MEDIUM: h2: fix incorrect timeout handling on the connection

---
Cyril Bonté
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 01:10AM
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é
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 07:50AM
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
Aleksandar Lazic
Re[2]: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 11:40AM
Hi.

------ Originalnachricht ------
Von: "Willy Tarreau" <w@1wt.eu>
An: "Cyril Bonté" <cyril.bonte@free.fr>
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 <willy@haproxy.org>

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
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 12:00PM
Hi Aleks,

On Wed, Nov 01, 2017 at 10:28:55AM +0000, 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
Lukas Tribus
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 08:50PM
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 50000
timeout server 50000
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
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 09:10PM
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
Bryan Talbot
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 09:30PM
> On Nov 1, 2017, at Nov 1, 3:28 AM, Aleksandar Lazic <al@none.at> 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/ https://hub.docker.com/r/fingershock/haproxy-base/

-Bryan
Lukas Tribus
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 01, 2017 11:40PM
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:

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


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 50000
timeout server 50000
#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
Aleksandar Lazic
Re[2]: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 02, 2017 12:50AM
------ Originalnachricht ------
Von: "Bryan Talbot" <bryan.talbot@playnext.com>
An: "Aleksandar Lazic" <al@none.at>
Cc: "HAproxy Mailing Lists" <haproxy@formilux.org>
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 <al@none.at>
>>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
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 02, 2017 07:40AM
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.

> 0000000a:https_in.accept(0005)=0008 from [10.0.0.4:54737] ALPN=h2
> 0000000a:bk_testbk.clireq[0008:ffffffff]: PRI * HTTP/2.0
> 0000000a:bk_testbk.srvrep[0008:adfd]: HTTP/1.1 400 Bad Request
> 0000000a:bk_testbk.srvhdr[0008:adfd]: Server: nginx/1.10.3 (Ubuntu)
> 0000000a:bk_testbk.srvhdr[0008:adfd]: Date: Wed, 01 Nov 2017 21:15:41 GMT
> 0000000a:bk_testbk.srvhdr[0008:adfd]: Content-Type: text/html
> 0000000a:bk_testbk.srvhdr[0008:adfd]: Content-Length: 182
> 0000000a:bk_testbk.srvhdr[0008:adfd]: Connection: close
> 0000000a:bk_testbk.srvcls[0008:adfd]
> 0000000b:bk_testbk.clireq[0008:ffffffff]: SM
> 0000000b:bk_testbk.clicls[adfd:ffffffff]
> 0000000b:bk_testbk.closed[adfd:ffffffff]
>
>
> 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 50000
> timeout server 50000
> #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?

I don't know for now, I'll have to try to reproduce. Olivier already
sent me some fixes for mistakes I did in the H2 code (wrong states in
error cases) but that should not affect this. I suspect we're reading
past a buffer in some cases (possibly the measurement of the contiguous
payload in the buffer which occasionally fails).

> 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

Yep, but thanks for recalling it, especially since some of the list members
here probably are not subscribed.

Cheers,
Willy
Robert Samuel Newson
re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 02, 2017 05:10PM
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+help@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.
William Lallemand
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 02, 2017 05:10PM
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
Dmitry Sivachenko
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 03, 2017 01:20PM
> On 01 Nov 2017, at 02:20, Willy Tarreau <w@1wt.eu> 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;
~ ^~~~~~~~~~~
src/mux_h2.c:526:24: warning: unused function 'h2_get_n64' [-Wunused-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
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;
~~~~~~ ^~~~~~~~~~~
src/cache.c:589:11: warning: implicit conversion from enumeration type
'enum act_parse_ret' to different enumeration type 'enum act_return'
[-Wenum-conversion]
return ACT_RET_PRS_OK;
~~~~~~ ^~~~~~~~~~~~~~
src/cache.c:591:11: warning: implicit conversion from enumeration type
'enum act_parse_ret' to different enumeration type 'enum act_return'
[-Wenum-conversion]
return ACT_RET_PRS_ERR;
~~~~~~ ^~~~~~~~~~~~~~~
src/cache.c:594:9: warning: implicit conversion from enumeration type
'enum act_parse_ret' to different enumeration type 'enum act_return'
[-Wenum-conversion]
return ACT_RET_PRS_OK;
~~~~~~ ^~~~~~~~~~~~~~
src/cache.c:622:9: warning: implicit conversion from enumeration type
'enum act_return' to different enumeration type 'enum act_parse_ret'
[-Wenum-conversion]
return ACT_RET_ERR;
~~~~~~ ^~~~~~~~~~~


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);
^~~~~~~~~~~~~
(a lot of similar)
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 03, 2017 03:50PM
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);
> ^~~~~~~~~~~~~
> (a lot of similar)

Olivier reported them. It's a real pain because it's made like this
on purpose and as usual C language developers are trying to kill C
usage around them by making the language unusable for what it was made
for : manipulating data in a portable way :-( This warning is so much
ridiculous as the so called unaligned pointer is the first member of
the structure! I guess we'll have to hide this one as well but it's
annoying for anyone using ebtree :-/

Thanks very much!
Willy
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 03, 2017 11:40PM
Hi Robert,

On Thu, Nov 02, 2017 at 03:58:47PM +0000, 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+help@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
Robert Newson
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 04, 2017 10:30AM
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 <w@1wt.eu> wrote:
>
> Hi Robert,
>
>> On Thu, Nov 02, 2017 at 03:58:47PM +0000, 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+help@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
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 04, 2017 10:40AM
On Sat, Nov 04, 2017 at 09:17:23AM +0000, 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
Robert Newson
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 04, 2017 02:40PM
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 <bob@rsn.io> 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 <w@1wt.eu> wrote:
>>
>> Hi Robert,
>>
>>> On Thu, Nov 02, 2017 at 03:58:47PM +0000, 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+help@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
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 04, 2017 05:30PM
On Sat, Nov 04, 2017 at 01:33:30PM +0000, 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
Robert Samuel Newson
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 04, 2017 05:50PM
-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 <w@1wt.eu> wrote:
>
> On Sat, Nov 04, 2017 at 01:33:30PM +0000, 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
Willy Tarreau
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 04, 2017 06:20PM
On Sat, Nov 04, 2017 at 04:46:28PM +0000, 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
Emmanuel Hocdet
Re: [ANNOUNCE] haproxy-1.8-rc1 : the last mile
November 06, 2017 11:00AM
Hi Robert,

> Le 4 nov. 2017 à 14:33, Robert Newson <bob@rsn.io> 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
Sorry, only registered users may post in this forum.

Click here to login