Re: [PATCH 4/4] CLEANUP: Re-apply xalloc_size.cocci

[Willy Tarreau]

On Sat, Nov 06, 2021 at 03:14:45PM +0100, Tim Duesterhus wrote:
> Use a consistent size as the parameter for the *alloc family.

Series applied, thanks Tim!
Willy

Re: How to compile with packaged openssl when custom openssl installed?

[Илья Шипицин]

чт, 4 нояб. 2021 г. в 22:31, Shawn Heisey :

> On 11/4/21 7:55 AM, Willy Tarreau wrote:
> > Normally you just have to specify SSL_INC and SSL_LIB at build time to
> > specify the one you want to build with. I'm doing exactly this when I
> > want to build with older versions:
>
>
> I tried this.  My make command (building 2.4.8) had these env additions:
>
>SSL_INC=/usr/include/openssl \
>SSL_LIB=/usr/lib/x86_64-linux-gnu \
>
> Which should have told it to use the openssl provided by Ubuntu
> packages.  But that didn't work, it still found the 3.x version in
> /usr/local (installed with openssl default locations for ./Configure),
> and failed to compile.
>
> I thought I found an error in the Makefile where setting USE_OPENSSL
> clears SSL_INC and SSL_LIB, but even with that problem handled (I think
> ... my Makefile experience is slim), it STILL finds the 3.x version and
> tries to use it.
>

it does not clear.

at least gnu make and bsd make.
SSL_INC=
means "if SSL_INC is defined as environment variable, clear it", but if you
specify SSL_INC from make command line, it has priority over Makefile


>
> Changing the prefix on the openssl compile to something nonstandard
> (/usr/local/ssl3 in my case) is the only way I have found to keep the
> haproxy build from finding it.  This is less than ideal, but sufficient
> for my needs.
>
> Thanks,
> Shawn
>
>
>
>

Re: How to compile with packaged openssl when custom openssl installed?

[Shawn Heisey]

On 11/6/2021 3:22 AM, Erwan Le Pape wrote:
Try building with SSL_INC=/usr/include and you should be good to build. 
When running HAProxy you'll have to make sure that the library 
resolution order is consistent with the library you linked against (ie. 
/usr/local/lib is searched after /usr/lib) or you'll face some weird 
issues and crashes.


I thought you might be on to something here.   But it didn't help.  Even 
with SSL_INC=/usr/include it still failed just as before, trying to 
compile against openssl 3.x.


I guess I'll just have to use the nonstandard prefix when building 
openssl 3.x.  That is an acceptable workaround for me.  I had hoped I 
could install it in the standard location, but I don't actually NEED it 
to be in that location.


Thanks,
Shawn

Re: [ANNOUNCE] haproxy-2.5-dev13

[Илья Шипицин]

as we are close to 2.5, can the following remaining Coverity issues be
addressed ? at least I'm aware of possible null pointer deref

src/stream_interface.c: insecure data handling suspected by coverity ·
Issue #1405 · haproxy/haproxy (github.com)


src/stick_table.c: unchecked return value suspected by coverity · Issue
#1163 · haproxy/haproxy (github.com)


Null pointer dereference suspected by coverity · Issue #1434 ·
haproxy/haproxy (github.com)


сб, 6 нояб. 2021 г. в 14:11, Willy Tarreau :

> Hi,
>
> HAProxy 2.5-dev13 was released on 2021/11/06. It added 35 new commits
> after version 2.5-dev12.
>
> These are the last-mile fixes and cleanups for this release.
>
>   - the backend support for WebSocket over HTTP/2 was adjusted to allow
> WebSocket to use HTTP/1 even if HTTP traffic uses HTTP/2. There were
> indeed some users complaining about broken WebSocket when H2 is
> enabled on the backend side because their servers did not yet support
> WebSocket over HTTP/2. With this, haproxy will offer WS over HTTP/2
> even if the server runs HTTP/2 without it, and haproxy will use HTTP/1
> connections to the server for WS. The new server keyword to tune this
> is "ws". This part will be backported to 2.4 to fix the issues that
> these users are facing. More improvements are planned (autodetection)
> but they do present certain shortcomings in case servers would restart
> and change their status, so they were kept on hold for now.
>
>   - the fc_conn_err and bc_conn_err sample fetch functions which return the
> frontend connection and backend connection error codes were renamed to
> "fc_err" and "bc_err" to be consistent with the other ones, as "fc" and
> "bc" already stand for "frontend connection" and "backend connection".
> No need for the confusing redundancy. This may possibly break some
> configs if you were using them on a development version, but better fix
> that before they're part of a final release.
>
>   - as discussed a few days ago, the frontend connection's SNI was added to
> the HTTPS log format. It was placed just before the SSL version and
> ciphers, delimited with a '/' so that even if an empty one is sent,
> there is no ambiguity on the field parsing.
>
>   - some of the DNS stats counters were split into their own resolvers
> stats, because they were really resolver events rather than DNS
> protocol level events. This could make a difference when we later
> implement support for DNS load balancing.
>
>   - a warning is now sent when "compression offload" is used in a defaults
> section, because that does nothing. While the doc was already clear
> about it, it used to be accepted by the config parser, so we cannot
> really error on it now at the risk of breaking some harmless configs.
> However a warning does seem appropriate at least.
>
>   - small fixes and updates on JWT, resolvers, and QUIC
>
>   - build instructions for QUIC and quictls were added to the INSTALL file
>
>   - an example error-log-format was added to the doc, as it wasn't exactly
> trivial. We think it covers most use cases, so with a bit of luck it
> will often be copy-pasted and generalized.
>
>   - more code cleanups, doc updates, and regtest cleanups
>
> Yesterday while reviewing optimal logging options for HTTPS with William,
> we noticed that some sample-fetch functions are missing to retrieve the
> certificate check status on the backend, or extract the backend's TLS
> version or SNI. The code already exists (we even did most of it on the
> fly just to test) but I didn't want to rush a last-minute set of new
> sample-fetch functions, whose tests and documentation would needlessly
> delay this release. I will probably add them later next week or after the
> release, and they're low-importance details that can trivially be
> backported if we want.
>
> I've told Björn not to rush his patches on Multi-path TCP. While they're
> trivial and certainly harmless, there's no reason to hurry on this at the
> last minute and risk to make mistakes, we'll have plenty of time to
> complete
> this work later. MPTCP is still young, and if there's some demand, once
> merged the backport should even be trivial to perform.
>
> I expect a few more doc updates, makefile reorderings/cleanups, regtests,
> bug fixes, maybe a few more sample-fetch functions and converters, some
> more tests on various machine sizes, and if everything's good we could
> release by the end of next week.
>
> So, please test it. If you can't take any risk on your production, at the
> very least please check that it properly loads your configuration and/or
> that any warning or error is expected, that could save you some precious
> time later ;-)
>
> Please find the usual URLs below :
>Site index   : 

[PATCH] MINOR: promex: backend aggregated server check status

[William Dauchy]

- add new metric: `haproxy_backend_agg_server_check_status`
  it counts the number of servers matching a specific check status
  this permits to exclude per server check status as the usage is often
  to rely on the total. Indeed in large setup having thousands of
  servers per backend the memory impact is not neglible to store the per
  server metric.
- realign promex_str_metrics array

quite simple implementation - we could improve it later by adding an
internal state to the prometheus exporter, thus to avoid counting at
every dump.

this patch is an attempt to close github issue #1312

Signed-off-by: William Dauchy 
---
 addons/promex/service-prometheus.c | 229 -
 include/haproxy/stats-t.h  |   1 +
 src/stats.c|   4 +
 3 files changed, 131 insertions(+), 103 deletions(-)

diff --git a/addons/promex/service-prometheus.c 
b/addons/promex/service-prometheus.c
index 221e40705..ef217007d 100644
--- a/addons/promex/service-prometheus.c
+++ b/addons/promex/service-prometheus.c
@@ -189,106 +189,107 @@ const struct promex_metric 
promex_global_metrics[INF_TOTAL_FIELDS] = {
 
 /* frontend/backend/server fields */
 const struct promex_metric promex_st_metrics[ST_F_TOTAL_FIELDS] = {
-   //[ST_F_PXNAME] ignored
-   //[ST_F_SVNAME] ignored
-   [ST_F_QCUR]   = { .n = IST("current_queue"),
.type = PROMEX_MT_GAUGE,.flags = (  
 PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_QMAX]   = { .n = IST("max_queue"),
.type = PROMEX_MT_GAUGE,.flags = (  
 PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_SCUR]   = { .n = IST("current_sessions"), 
.type = PROMEX_MT_GAUGE,.flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_SMAX]   = { .n = IST("max_sessions"), 
.type = PROMEX_MT_GAUGE,.flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_SLIM]   = { .n = IST("limit_sessions"),   
.type = PROMEX_MT_GAUGE,.flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_STOT]   = { .n = IST("sessions_total"),   
.type = PROMEX_MT_COUNTER,  .flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_BIN]= { .n = IST("bytes_in_total"),   
.type = PROMEX_MT_COUNTER,  .flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_BOUT]   = { .n = IST("bytes_out_total"),  
.type = PROMEX_MT_COUNTER,  .flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_DREQ]   = { .n = IST("requests_denied_total"),
.type = PROMEX_MT_COUNTER,  .flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC   ) },
-   [ST_F_DRESP]  = { .n = IST("responses_denied_total"),   
.type = PROMEX_MT_COUNTER,  .flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_EREQ]   = { .n = IST("request_errors_total"), 
.type = PROMEX_MT_COUNTER,  .flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC   ) },
-   [ST_F_ECON]   = { .n = IST("connection_errors_total"),  
.type = PROMEX_MT_COUNTER,  .flags = (  
 PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_ERESP]  = { .n = IST("response_errors_total"),
.type = PROMEX_MT_COUNTER,  .flags = (  
 PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_WRETR]  = { .n = IST("retry_warnings_total"), 
.type = PROMEX_MT_COUNTER,  .flags = (  
 PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_WREDIS] = { .n = IST("redispatch_warnings_total"),
.type = PROMEX_MT_COUNTER,  .flags = (  
 PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_STATUS] = { .n = IST("status"),   
.type = PROMEX_MT_GAUGE,.flags = (PROMEX_FL_FRONT_METRIC | 
PROMEX_FL_LI_METRIC | PROMEX_FL_BACK_METRIC | PROMEX_FL_SRV_METRIC) },
-   [ST_F_WEIGHT] = { .n = IST("weight"),   
.type = PROMEX_MT_GAUGE,.flags = (  
 PROMEX_FL_BACK_METRIC |