Re: HAProxy and musl (was: Re: HAproxy Error)

2023-09-14 Thread Aleksandar Lazic

Hi.

Resuscitate this old thread with a musl lib update.

https://musl.libc.org/releases.html

```
musl-1.2.4.tar.gz (sig) - May 1, 2023

This release adds TCP fallback to the DNS stub resolver, fixing the 
longstanding inability to query large DNS records and incompatibility 
with recursive nameservers that don't give partial results in truncated 
UDP responses. It also makes a number of other bug fixes and 
improvements in DNS and related functionality, including making both the 
modern and legacy API results differentiate between NODATA and NxDomain 
conditions so that the caller can handle them differently.




```

Regards
Alex


On 2020-04-16 (Do.) 13:26, Willy Tarreau wrote:

On Thu, Apr 16, 2020 at 12:29:42PM +0200, Tim Düsterhus wrote:

FWIW musl seems to work OK here when building for linux-glibc-legacy.


Yes. HAProxy linked against Musl is smoke tested as part of the Docker
Official Images program, because the Alpine-based Docker images use Musl
as their libc. In fact you can even use TARGET=linux-glibc + USE_BACKTRACE=.


By the way, I initially thought I was the only one building with musl
for my EdgeRouter-x that I'm using as a distcc load balancer for the
build farm at work. But if there are other users, we'd rather add
a linux-musl target, as the split between OS and library was precisely
made for this purpose!

Anyone objects against something like this (+ the appropriate entries
in other places and doc) ?


diff --git a/Makefile b/Makefile
index d5841a5..a3dad36 100644
--- a/Makefile
+++ b/Makefile
@@ -341,6 +341,18 @@ ifeq ($(TARGET),linux-glibc-legacy)
  USE_ACCEPT4 USE_LINUX_SPLICE USE_PRCTL USE_THREAD_DUMP USE_GETADDRINFO)
  endif
  
+# For linux >= 2.6.28 and musl

+ifeq ($(TARGET),linux-musl)
+  set_target_defaults = $(call default_opts, \
+USE_POLL USE_TPROXY USE_LIBCRYPT USE_DL USE_RT USE_CRYPT_H USE_NETFILTER  \
+USE_CPU_AFFINITY USE_THREAD USE_EPOLL USE_FUTEX USE_LINUX_TPROXY  \
+USE_ACCEPT4 USE_LINUX_SPLICE USE_PRCTL USE_THREAD_DUMP USE_NS USE_TFO \
+USE_GETADDRINFO)
+ifneq ($(shell echo __arm__/__aarch64__ | $(CC) -E -xc - | grep 
'^[^\#]'),__arm__/__aarch64__)
+  TARGET_LDFLAGS=-latomic
+endif
+endif
+
  # Solaris 8 and above
  ifeq ($(TARGET),solaris)
# We also enable getaddrinfo() which works since solaris 8.

Willy




Re: HAproxy Error

2020-04-17 Thread Lukas Tribus
On Fri, 17 Apr 2020 at 13:57,  wrote:
>  Even clean installation isn’t working because the default package available 
> in RHEL from you is without openssl.

You are wrong.

1) we don't provide any packages. RHEL does.
2) a fresh RHEL 8.1 AMI on AWS works just fine and uses the provided
1.8.15 image with SSL support, as opposed to 2.1.2 which clearly you
manually compiled from source.


Here is the evidence from a freshly installed RHEL 8.1 AMI image on AWS:

[root@ip-172-31-42-121 ~]# uname -a
Linux ip-172-31-42-121.eu-central-1.compute.internal
4.18.0-147.el8.x86_64 #1 SMP Thu Sep 26 15:52:44 UTC 2019 x86_64
x86_64 x86_64 GNU/Linux
[root@ip-172-31-42-121 ~]# date
Fri Apr 17 12:22:38 UTC 2020
[ec2-user@ip-172-31-42-121 ~]$ haproxy -vv
-bash: haproxy: command not found
[root@ip-172-31-42-121 ~]# yum update
Red Hat Update Infrastructure 3 Client Configuration Server 8



 7.6 kB/s | 2.1 kB 00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)



  11 kB/s | 2.8 kB 00:00
Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)



  10 kB/s | 2.4 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!
[root@ip-172-31-42-121 ~]# yum install haproxy
Last metadata expiration check: 0:00:07 ago on Fri 17 Apr 2020 12:22:43 PM UTC.
Dependencies resolved.
=
 Package
Architecture
Version
   Repository
  Size
=
Installing:
 haproxy
x86_64
1.8.15-6.el8_1.1
   rhel-8-appstream-rhui-rpms
 1.3 M

Transaction Summary
=
Install  1 Package

Total download size: 1.3 M
Installed size: 4.4 M
Is this ok [y/N]: y
Downloading Packages:
haproxy-1.8.15-6.el8_1.1.x86_64.rpm



 4.9 MB/s | 1.3 MB 00:00
-
Total



 3.5 MB/s | 1.3 MB 00:00
Running transaction check
Waiting for process with pid 1068 to finish.
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing:



 1/1
  Running scriptlet: haproxy-1.8.15-6.el8_1.1.x86_64



 1/1
  Installing   : haproxy-1.8.15-6.el8_1.1.x86_64



 1/1
  Running scriptlet: haproxy-1.8.15-6.el8_1.1.x86_64



 1/1
  Verifying: haproxy-1.8.15-6.el8_1.1.x86_64



 1/1

Installed:
  haproxy-1.8.15-6.el8_1.1.x86_64

Complete!
[root@ip-172-31-42-121 ~]# haproxy -vv
HA-Proxy version 1.8.15 2018/12/13
Copyright 2000-2018 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -Wno-format-truncation -Wno-null-dereference -Wno-unused-label
  OPTIONS = USE_LINUX_TPROXY=1 USE_CRYPT_H=1 USE_GETADDRINFO=1
USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_SYSTEMD=1
USE_PCRE=1

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

Built with OpenSSL version : OpenSSL 1.1.1c FIPS  28 May 2019
Running on OpenSSL version : OpenSSL 1.1.1c FIPS  28 May 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.4
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.42 2018-03-20
Running on PCRE version : 8.42 2018-03-20
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), 

Re: HAproxy Error

2020-04-17 Thread Willy Tarreau
On Fri, Apr 17, 2020 at 11:57:40AM +, bindushree...@cognizant.com wrote:
> We are asking about the issue using your application. If you don't
> have enough information to provide its okay thank you.

Are you serious ? Did you even read *any* single response ? Several
people told you that you were running a locally built haproxy package
which has nothing to do with the one provided by RHEL, and you insist
on not taking that very basic diagnostic into account.

> Also we have come to you after checking everything from our end. Even clean
> installation isn't working because the default package available in RHEL from
> you is without openssl.

No, either you didn't check, or you're not doing the very basic things
any admin would do. You're starting haproxy from /usr/local/sbin and
you won't find such a path in a mainstream distro, it definitely is for
your locally installed packages.

Some someone on your end *has* built and installed this bogus version
and you're not using the one from the distro. A quick googling seems
to indicate that RHEL8 ships with haproxy 1.8. Yours is 2.1 so it does
not come from RHEL.

> If you can help us with rpm which is having openssl in it.

I'm sorry but you're on your own here. Your system is obviously broken,
everyone sees it without having access to it, and you refuse to admit it.
There's hardly anything anyone can do remotely to help you if you continue
to report wrong diagnostics.

Now what else to do ? I don't know. Maybe use rpm to figure what package
provides /usr/local/sbin/haproxy and remove that package, then install
the valid one provided by your distro instead. Maybe your distro isn't
genuine and was badly modified by someone in your team. Maybe someone
installed a backdoored executable there before leaving your company, I
don't know, everything is possible, but I can't guess for you I'm afraid.

Hoping this helps,
Willy



RE: HAproxy Error

2020-04-17 Thread BINDUSHREE.DB
Hi Willy,

For your kind information not asking you how to manage server or how to google.
We are asking about the issue using your application. If you don't have enough 
information to provide its okay thank you.
Also we have come to you after checking everything from our end. Even clean 
installation isn’t working because the default package available in RHEL from 
you is without openssl.
If you can help us with rpm which is having openssl in it.

Thank you.

Thanks,
Bindushree D B


-Original Message-
From: Willy Tarreau 
Sent: Friday, April 17, 2020 1:07 PM
To: D B, Bindushree (Cognizant) 
Cc: li...@ltri.eu; haproxy@formilux.org
Subject: Re: HAproxy Error

[External]


On Fri, Apr 17, 2020 at 04:02:41AM +, bindushree...@cognizant.com wrote:
> HI Lukas,
>
> Package was installed in RHEL machines using yum. Let me know how to install 
> Redhat openssl version.

Well, I'm sorry but at this point you're mainly asking how to manage
*your* server. Participants here are not in a position to help you fix what's 
on your server if you performed wrong operations. Either you trash it and 
reinstall it from scratch to have a clean install, or you contract with someone 
to do the job for you. But your requests for help are absolutely not related to 
haproxy at this point, only to help you figure how to use google to find how to 
install packages on your system.

There's no point continuing this thread, everyone is wasting his time, 
including you apparently since you've remained stuck at point zero before the 
elementary google search.

Willy
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient(s), please reply to the sender and 
destroy all copies of the original message. Any unauthorized review, use, 
disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored.
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient(s), please reply to the sender and 
destroy all copies of the original message. Any unauthorized review, use, 
disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored.


Re: HAproxy Error

2020-04-17 Thread Willy Tarreau
On Fri, Apr 17, 2020 at 04:02:41AM +, bindushree...@cognizant.com wrote:
> HI Lukas,
> 
> Package was installed in RHEL machines using yum. Let me know how to install 
> Redhat openssl version.

Well, I'm sorry but at this point you're mainly asking how to manage
*your* server. Participants here are not in a position to help you
fix what's on your server if you performed wrong operations. Either
you trash it and reinstall it from scratch to have a clean install,
or you contract with someone to do the job for you. But your requests
for help are absolutely not related to haproxy at this point, only to
help you figure how to use google to find how to install packages on
your system.

There's no point continuing this thread, everyone is wasting his time,
including you apparently since you've remained stuck at point zero
before the elementary google search.

Willy



RE: HAproxy Error

2020-04-16 Thread BINDUSHREE.DB
HI Lukas,

Package was installed in RHEL machines using yum. Let me know how to install 
Redhat openssl version.


Yum install haproxy.


Thanks,
Bindushree D B


-Original Message-
From: Lukas Tribus 
Sent: Friday, April 17, 2020 3:09 AM
To: D B, Bindushree (Cognizant) 
Cc: haproxy 
Subject: Re: HAproxy Error

[External]


Hello,


On Thu, 16 Apr 2020 at 13:51,  wrote:
> # which haproxy
> /usr/ local/sbin/haproxy
>
>
>
> Attached output for command “haproxy –vv”
>
>
>
> Also I’m using a AWS RHEL 8.1 version AMI.
>
> Let us know what else is required. Also let me know how to enable Openssl. 
> Provide me the rpm link which has openssl enabled by default.

As I expected, you are not using the RedHat provided package, but a local build 
of 2.1.2, without SSL support.

I suggest you uninstall/remove your local build, and go back using the RedHat 
provided package.


Lukas




Lukas
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient(s), please reply to the sender and 
destroy all copies of the original message. Any unauthorized review, use, 
disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored.
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient(s), please reply to the sender and 
destroy all copies of the original message. Any unauthorized review, use, 
disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored.


Re: HAproxy Error

2020-04-16 Thread Lukas Tribus
Hello,


On Thu, 16 Apr 2020 at 13:51,  wrote:
> # which haproxy
> /usr/ local/sbin/haproxy
>
>
>
> Attached output for command “haproxy –vv”
>
>
>
> Also I’m using a AWS RHEL 8.1 version AMI.
>
> Let us know what else is required. Also let me know how to enable Openssl. 
> Provide me the rpm link which has openssl enabled by default.

As I expected, you are not using the RedHat provided package, but a
local build of 2.1.2, without SSL support.

I suggest you uninstall/remove your local build, and go back using the
RedHat provided package.


Lukas




Lukas



Re: HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Willy Tarreau
On Thu, Apr 16, 2020 at 05:38:59PM +0500,  ??? wrote:
> ??, 16 ???. 2020 ?. ? 16:26, Willy Tarreau :
> 
> > On Thu, Apr 16, 2020 at 12:29:42PM +0200, Tim Düsterhus wrote:
> > > > FWIW musl seems to work OK here when building for linux-glibc-legacy.
> > >
> > > Yes. HAProxy linked against Musl is smoke tested as part of the Docker
> > > Official Images program, because the Alpine-based Docker images use Musl
> > > as their libc. In fact you can even use TARGET=linux-glibc +
> > USE_BACKTRACE=.
> >
> > By the way, I initially thought I was the only one building with musl
> > for my EdgeRouter-x that I'm using as a distcc load balancer for the
> > build farm at work. But if there are other users, we'd rather add
> >
> 
> private buildfarm ? what do you use ? just curious

Oh it's made of distccd running on 10 MIQI boards (ARM RK3288 quad-A17
at 1.8-2.0 GHz) and it's also squatting 7 of our traffic generators
running on SolidRun MacchiatoBin (quad A72 at 2 GHZ) when they're not
used for benchmarks. That's a lot of CPUs to deal with, so it requires a
huge amount of parallelism to keep them busy. But sending too many jobs
to a slow CPU or to the same machine results in uneven distribution and
highly varying build times. So instead of sending everything from the
PC directly to the nodes, there's a small server in the middle that runs
haproxy which parses the distcc requests to figure the file sizes, and
uses that value with Patrick's priority-based queuing so that largest
files are distributed first to largest and most idle nodes, and small
files are distributed last. This is also one of the reasons why I reorder
the makefile before each release. I build with "make -j 120" and depending
on the build options it takes from 3 to 5 seconds at -O0 or about 7-9 at
-O2. Pretty appreciable savings when you build 50 to 200 times a day :-)

There are more info there if you're interested in the design and want
some photos:
   https://wtarreau.blogspot.com/2019/01/build-farm-version-3-2018.html
   https://wtarreau.blogspot.com/2019/01/build-farm-version-2-2016-2017.html

I presented it twice at kernel recipes (initial one and updates) if you
want to go deeper and laugh hearing me speak english with a french accent:
   
https://kernel-recipes.org/en/2016/talks/speeding-up-development-by-setting-up-a-kernel-build-farm/
   
https://www.slideshare.net/ennael/kernel-recipes-2017-build-farm-again-willy-tarreau
   https://www.youtube.com/watch?v=sJwMRA34_SI

> > a linux-musl target, as the split between OS and library was precisely
> > made for this purpose!
> >
> > Anyone objects against something like this (+ the appropriate entries
> > in other places and doc) ?
> >
> 
> looks good

OK, then I'll merge it before emitting a new dev now.

Thanks,
Willy



Re: HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Илья Шипицин
чт, 16 апр. 2020 г. в 16:26, Willy Tarreau :

> On Thu, Apr 16, 2020 at 12:29:42PM +0200, Tim Düsterhus wrote:
> > > FWIW musl seems to work OK here when building for linux-glibc-legacy.
> >
> > Yes. HAProxy linked against Musl is smoke tested as part of the Docker
> > Official Images program, because the Alpine-based Docker images use Musl
> > as their libc. In fact you can even use TARGET=linux-glibc +
> USE_BACKTRACE=.
>
> By the way, I initially thought I was the only one building with musl
> for my EdgeRouter-x that I'm using as a distcc load balancer for the
> build farm at work. But if there are other users, we'd rather add
>

private buildfarm ? what do you use ? just curious

a linux-musl target, as the split between OS and library was precisely
> made for this purpose!
>
> Anyone objects against something like this (+ the appropriate entries
> in other places and doc) ?
>

looks good


>
>
> diff --git a/Makefile b/Makefile
> index d5841a5..a3dad36 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -341,6 +341,18 @@ ifeq ($(TARGET),linux-glibc-legacy)
>  USE_ACCEPT4 USE_LINUX_SPLICE USE_PRCTL USE_THREAD_DUMP
> USE_GETADDRINFO)
>  endif
>
> +# For linux >= 2.6.28 and musl
> +ifeq ($(TARGET),linux-musl)
> +  set_target_defaults = $(call default_opts, \
> +USE_POLL USE_TPROXY USE_LIBCRYPT USE_DL USE_RT USE_CRYPT_H
> USE_NETFILTER  \
> +USE_CPU_AFFINITY USE_THREAD USE_EPOLL USE_FUTEX USE_LINUX_TPROXY
> \
> +USE_ACCEPT4 USE_LINUX_SPLICE USE_PRCTL USE_THREAD_DUMP USE_NS
> USE_TFO \
> +USE_GETADDRINFO)
> +ifneq ($(shell echo __arm__/__aarch64__ | $(CC) -E -xc - | grep
> '^[^\#]'),__arm__/__aarch64__)
> +  TARGET_LDFLAGS=-latomic
> +endif
> +endif
> +
>  # Solaris 8 and above
>  ifeq ($(TARGET),solaris)
># We also enable getaddrinfo() which works since solaris 8.
>
> Willy
>


RE: HAproxy Error

2020-04-16 Thread BINDUSHREE.DB
Hi Team,

Here is the output of the required commands.

# which haproxy
/usr/ local/sbin/haproxy

Attached output for command “haproxy –vv”

Also I’m using a AWS RHEL 8.1 version AMI.
Let us know what else is required. Also let me know how to enable Openssl. 
Provide me the rpm link which has openssl enabled by default.

Thanks,
Bindushree D B

From: Илья Шипицин 
Sent: Thursday, April 16, 2020 1:56 PM
To: Lukas Tribus 
Cc: D B, Bindushree (Cognizant) ; Aleksandar Lazic 
; haproxy 
Subject: Re: HAproxy Error

[External]


чт, 16 апр. 2020 г. в 12:48, Lukas Tribus mailto:li...@ltri.eu>>:
Hello,

On Thu, 16 Apr 2020 at 06:04, 
mailto:bindushree...@cognizant.com>> wrote:
>
> Hi Team
>
> Let us know your availability to work on this.

As Aleks already said:

This haproxy executable has been build without OpenSSL support, which
is required for your configuration.

Provide the output of "which haproxy" and "haproxy -vv", I doubt you

also, it would be nice to see

rpm -qf `which haproxy`


are actually running the Redhat package you indicated, more likely you
built Haproxy manually from source on top of it.


Lukas
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient(s), please reply to the sender and 
destroy all copies of the original message. Any unauthorized review, use, 
disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored. This e-mail and any files transmitted with it are for the sole 
use of the intended recipient(s) and may contain confidential and privileged 
information. If you are not the intended recipient(s), please reply to the 
sender and destroy all copies of the original message. Any unauthorized review, 
use, disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored.
[root@RHEL8TestHA ~]# haproxy -vv
HA-Proxy version 2.1.2 2019/12/21 - https://haproxy.org/
Status: stable branch - will stop receiving fixes around Q1 2021.
Known bugs: http://www.haproxy.org/bugs/bugs-2.1.2.html
Build options :
  TARGET  = linux-glibc
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter 
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered 
-Wno-missing-field-initializers -Wno-implicit-fallthrough 
-Wno-stringop-overflow -Wno-cast-function-type -Wtype-limits 
-Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
  OPTIONS =

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT 
-PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM 
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT 
+CRYPT_H -VSYSCALL +GETADDRINFO -OPENSSL -LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 -ZLIB 
-SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD 
-OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

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

Built with multi-threading support (MAX_THREADS=64, default=2).
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Built without PCRE or PCRE2 support (using libc's regex instead)
Encrypted password support via crypt(3): yes
Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
Compression algorithms supported : identity("identity")

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 multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTTP   side=FE|BE mux=H2
fcgi : mode=HTTP   side=BEmux=FCGI
: mode=HTTP   side=FE|BE mux=H1
: mode=TCPside=FE|BE mux=PASS

Available services : none

Available filters :
[SPOE] spoe
[CACHE] cache
[FCGI] fcgi-app
[TRACE] trace
[COMP] compression


Re: HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Willy Tarreau
On Thu, Apr 16, 2020 at 12:29:42PM +0200, Tim Düsterhus wrote:
> > FWIW musl seems to work OK here when building for linux-glibc-legacy.
> 
> Yes. HAProxy linked against Musl is smoke tested as part of the Docker
> Official Images program, because the Alpine-based Docker images use Musl
> as their libc. In fact you can even use TARGET=linux-glibc + USE_BACKTRACE=.

By the way, I initially thought I was the only one building with musl
for my EdgeRouter-x that I'm using as a distcc load balancer for the
build farm at work. But if there are other users, we'd rather add
a linux-musl target, as the split between OS and library was precisely
made for this purpose!

Anyone objects against something like this (+ the appropriate entries
in other places and doc) ?


diff --git a/Makefile b/Makefile
index d5841a5..a3dad36 100644
--- a/Makefile
+++ b/Makefile
@@ -341,6 +341,18 @@ ifeq ($(TARGET),linux-glibc-legacy)
 USE_ACCEPT4 USE_LINUX_SPLICE USE_PRCTL USE_THREAD_DUMP USE_GETADDRINFO)
 endif
 
+# For linux >= 2.6.28 and musl
+ifeq ($(TARGET),linux-musl)
+  set_target_defaults = $(call default_opts, \
+USE_POLL USE_TPROXY USE_LIBCRYPT USE_DL USE_RT USE_CRYPT_H USE_NETFILTER  \
+USE_CPU_AFFINITY USE_THREAD USE_EPOLL USE_FUTEX USE_LINUX_TPROXY  \
+USE_ACCEPT4 USE_LINUX_SPLICE USE_PRCTL USE_THREAD_DUMP USE_NS USE_TFO \
+USE_GETADDRINFO)
+ifneq ($(shell echo __arm__/__aarch64__ | $(CC) -E -xc - | grep 
'^[^\#]'),__arm__/__aarch64__)
+  TARGET_LDFLAGS=-latomic
+endif
+endif
+
 # Solaris 8 and above
 ifeq ($(TARGET),solaris)
   # We also enable getaddrinfo() which works since solaris 8.

Willy



Re: HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Willy Tarreau
On Thu, Apr 16, 2020 at 12:37:44PM +0200, Tim Düsterhus wrote:
> Ilya,
> 
> Am 16.04.20 um 12:34 schrieb  ???:
> > yep, I thought about alpine as well.
> > 
> > I'm not sure how often official docker validation runs. If it runs often
> > enough, maybe we do not need CI.
> > 
> 
> The tests are run for every update of the Dockerfile, thus either for
> new HAProxy releases or for Alpine updates. I usually add a `-rc`
> version of the Dockerfile for upcoming HAProxy versions once the
> development cycle gets close to the end and the versions are expected to
> be somewhat stable.

Great, I think it's already quite sufficient. Of course we can always
do more and better, but we have to stay reasonable and focus on the
sweet spot between the benefits expected from extra test coverage and
the infrastructure costs (because at the end of the day someone *has*
to pay for all the builds and tests we provoke).

I think the CI has brought a lot since it was set up, and our usage is
well balanced. Maybe some would consider that it's underexploited, or
others woud consider that we're already abusing. My view is that it's
OK this way and already helps a lot. I'm more interested by the nasty
bugs it allows us to detect (such as non-portable openssl functions or
incorrect integer operations on some archs) than just "it fails to build
there, we need to add an ifdef", because ultimately even if we break an
OS that way, it's instantly detected and trivial to fix. It's always
pleasant to detect those in advance, but if they're missed it really
does not harm. Detecting the issues around abns seamless on ppc64le was
way more useful :-)

Cheers,
Willy



Re: HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Tim Düsterhus
Ilya,

Am 16.04.20 um 12:34 schrieb Илья Шипицин:
> yep, I thought about alpine as well.
> 
> I'm not sure how often official docker validation runs. If it runs often
> enough, maybe we do not need CI.
> 

The tests are run for every update of the Dockerfile, thus either for
new HAProxy releases or for Alpine updates. I usually add a `-rc`
version of the Dockerfile for upcoming HAProxy versions once the
development cycle gets close to the end and the versions are expected to
be somewhat stable.

See here for the PRs updating the Dockerfile:
https://github.com/docker-library/official-images/pulls?q=is%3Apr+label%3Alibrary%2Fhaproxy+is%3Aclosed.
Within the PRs there's always a comment with the results of the tests
for all the versions.

Best regards
Tim Düsterhus



Re: HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Илья Шипицин
yep, I thought about alpine as well.

I'm not sure how often official docker validation runs. If it runs often
enough, maybe we do not need CI.

чт, 16 апр. 2020 г. в 15:29, Tim Düsterhus :

> Willy,
>
> [removed Bindushree from Cc as we disgress from the main topic]
>
> Am 16.04.20 um 11:44 schrieb Willy Tarreau:
> >> seems, we need some musl or picolibc in CI.
> >> beeing glibc dependent is dangerous
> >
> > It's not really glibc-dependent in that it's properly enclosed in ifdefs.
> > But you'd be welcome to add musl if you find an easy way to do it. Please
> > just avoid building a toolchain and musl on the fly for this, as this
> would
> > eat a huge amount of resources on the CI infrastructure :-/
> >
> > FWIW musl seems to work OK here when building for linux-glibc-legacy.
>
> Yes. HAProxy linked against Musl is smoke tested as part of the Docker
> Official Images program, because the Alpine-based Docker images use Musl
> as their libc. In fact you can even use TARGET=linux-glibc +
> USE_BACKTRACE=.
>
> Make options are here:
>
> https://github.com/docker-library/haproxy/blob/3dd3917d3a70c230d8b192541ee08764e1da16af/2.2-rc/alpine/Dockerfile#L31-L45
>
> Basic smoke test (Reverse Proxy to example.com) is here:
>
> https://github.com/docker-library/official-images/tree/master/test/tests/haproxy-basics
>
> Best regards
> Tim Düsterhus
>


HAProxy and musl (was: Re: HAproxy Error)

2020-04-16 Thread Tim Düsterhus
Willy,

[removed Bindushree from Cc as we disgress from the main topic]

Am 16.04.20 um 11:44 schrieb Willy Tarreau:
>> seems, we need some musl or picolibc in CI.
>> beeing glibc dependent is dangerous
> 
> It's not really glibc-dependent in that it's properly enclosed in ifdefs.
> But you'd be welcome to add musl if you find an easy way to do it. Please
> just avoid building a toolchain and musl on the fly for this, as this would
> eat a huge amount of resources on the CI infrastructure :-/
> 
> FWIW musl seems to work OK here when building for linux-glibc-legacy.

Yes. HAProxy linked against Musl is smoke tested as part of the Docker
Official Images program, because the Alpine-based Docker images use Musl
as their libc. In fact you can even use TARGET=linux-glibc + USE_BACKTRACE=.

Make options are here:
https://github.com/docker-library/haproxy/blob/3dd3917d3a70c230d8b192541ee08764e1da16af/2.2-rc/alpine/Dockerfile#L31-L45

Basic smoke test (Reverse Proxy to example.com) is here:
https://github.com/docker-library/official-images/tree/master/test/tests/haproxy-basics

Best regards
Tim Düsterhus



Re: HAproxy Error

2020-04-16 Thread Willy Tarreau
On Thu, Apr 16, 2020 at 02:38:28PM +0500,  ??? wrote:
> hmm.
> 
> seems, we need some musl or picolibc in CI.
> beeing glibc dependent is dangerous

It's not really glibc-dependent in that it's properly enclosed in ifdefs.
But you'd be welcome to add musl if you find an easy way to do it. Please
just avoid building a toolchain and musl on the fly for this, as this would
eat a huge amount of resources on the CI infrastructure :-/

FWIW musl seems to work OK here when building for linux-glibc-legacy.

Cheers,
Willy



Re: HAproxy Error

2020-04-16 Thread Илья Шипицин
hmm.

seems, we need some musl or picolibc in CI.
beeing glibc dependent is dangerous

чт, 16 апр. 2020 г. в 13:29, Willy Tarreau :

> Hi Lukas,
>
> On Thu, Apr 16, 2020 at 09:44:39AM +0200, Lukas Tribus wrote:
> > Provide the output of "which haproxy" and "haproxy -vv", I doubt you
> > are actually running the Redhat package you indicated, more likely you
> > built Haproxy manually from source on top of it.
>
> This just makes me think that on glibc-based systems we could use
> getauxval() to report the full path name to the executable in case
> of error. I'll see if I can come up with something usable.
>
> Willy
>
>


Re: HAproxy Error

2020-04-16 Thread Aleksandar Lazic

On 16.04.20 10:57, Willy Tarreau wrote:

On Thu, Apr 16, 2020 at 10:26:54AM +0200, Willy Tarreau wrote:

Hi Lukas,

On Thu, Apr 16, 2020 at 09:44:39AM +0200, Lukas Tribus wrote:

Provide the output of "which haproxy" and "haproxy -vv", I doubt you
are actually running the Redhat package you indicated, more likely you
built Haproxy manually from source on top of it.


This just makes me think that on glibc-based systems we could use
getauxval() to report the full path name to the executable in case
of error. I'll see if I can come up with something usable.


OK I did this:

   $ env PATH=$PWD:$PATH haproxy -c -f mini4.cfg
   [WARNING] 106/105513 (30832) : Setting tune.ssl.default-dh-param to 1024 by 
default, if your workload permits it you should set it to at least 2048. Please 
set a value >= 1024 to make this warning disappear.
   [NOTICE] 106/105513 (30832) : haproxy version is 2.2-dev5-bb8698-83
   [NOTICE] 106/105513 (30832) : path to executable is /g/public/haproxy/haproxy
   [ALERT] 106/105513 (30832) : Some warnings were found and 'zero-warning' is 
set. Aborting.

It also reports the version string, which can sometimes help when
dealing with multiple installations. The path to the executable is
only available on glibc for now (we're using the kernel's AUX vector).
This could possibly be improved to at least report argv[0] when not
available. But let's see how this works. If it helps we could even
backport it.


Hey that's really cool ;-)


Willy






Re: HAproxy Error

2020-04-16 Thread Willy Tarreau
On Thu, Apr 16, 2020 at 10:26:54AM +0200, Willy Tarreau wrote:
> Hi Lukas,
> 
> On Thu, Apr 16, 2020 at 09:44:39AM +0200, Lukas Tribus wrote:
> > Provide the output of "which haproxy" and "haproxy -vv", I doubt you
> > are actually running the Redhat package you indicated, more likely you
> > built Haproxy manually from source on top of it.
> 
> This just makes me think that on glibc-based systems we could use
> getauxval() to report the full path name to the executable in case
> of error. I'll see if I can come up with something usable.

OK I did this:

  $ env PATH=$PWD:$PATH haproxy -c -f mini4.cfg 
  [WARNING] 106/105513 (30832) : Setting tune.ssl.default-dh-param to 1024 by 
default, if your workload permits it you should set it to at least 2048. Please 
set a value >= 1024 to make this warning disappear.
  [NOTICE] 106/105513 (30832) : haproxy version is 2.2-dev5-bb8698-83
  [NOTICE] 106/105513 (30832) : path to executable is /g/public/haproxy/haproxy
  [ALERT] 106/105513 (30832) : Some warnings were found and 'zero-warning' is 
set. Aborting.

It also reports the version string, which can sometimes help when
dealing with multiple installations. The path to the executable is
only available on glibc for now (we're using the kernel's AUX vector).
This could possibly be improved to at least report argv[0] when not
available. But let's see how this works. If it helps we could even
backport it.

Willy



Re: HAproxy Error

2020-04-16 Thread Willy Tarreau
Hi Lukas,

On Thu, Apr 16, 2020 at 09:44:39AM +0200, Lukas Tribus wrote:
> Provide the output of "which haproxy" and "haproxy -vv", I doubt you
> are actually running the Redhat package you indicated, more likely you
> built Haproxy manually from source on top of it.

This just makes me think that on glibc-based systems we could use
getauxval() to report the full path name to the executable in case
of error. I'll see if I can come up with something usable.

Willy



Re: HAproxy Error

2020-04-16 Thread Илья Шипицин
чт, 16 апр. 2020 г. в 12:48, Lukas Tribus :

> Hello,
>
> On Thu, 16 Apr 2020 at 06:04,  wrote:
> >
> > Hi Team
> >
> > Let us know your availability to work on this.
>
> As Aleks already said:
>
> This haproxy executable has been build without OpenSSL support, which
> is required for your configuration.
>
> Provide the output of "which haproxy" and "haproxy -vv", I doubt you
>

also, it would be nice to see

rpm -qf `which haproxy`



> are actually running the Redhat package you indicated, more likely you
> built Haproxy manually from source on top of it.
>
>
> Lukas
>
>


Re: HAproxy Error

2020-04-16 Thread Lukas Tribus
Hello,

On Thu, 16 Apr 2020 at 06:04,  wrote:
>
> Hi Team
>
> Let us know your availability to work on this.

As Aleks already said:

This haproxy executable has been build without OpenSSL support, which
is required for your configuration.

Provide the output of "which haproxy" and "haproxy -vv", I doubt you
are actually running the Redhat package you indicated, more likely you
built Haproxy manually from source on top of it.


Lukas



RE: HAproxy Error

2020-04-15 Thread BINDUSHREE.DB
Hi Team

Let us know your availability to work on this.

Thanks,
Bindushree D B

-Original Message-
From: Aleksandar Lazic 
Sent: Wednesday, April 15, 2020 6:06 PM
To: D B, Bindushree (Cognizant) ; 
haproxy@formilux.org
Subject: Re: HAproxy Error

[External]


Hi.

On 15.04.20 13:39, bindushree...@cognizant.com wrote:
> ++Adding attachement
>
> Thank you in advance.
>
> Thanks,
>
> Bindushree D B
>
> *From:* D B, Bindushree (Cognizant)
> *Sent:* Wednesday, April 15, 2020 5:08 PM
> *To:* haproxy@formilux.org
> *Subject:* HAproxy Error
> *Importance:* High
>
> Hi Team,
>
> We are in the process of using newer HAproxy version.
>
> Below is the scenario explained where we are stuck.
>
> ·In RHEL 8.1 version, installed the latest version of the application.
>
>  haproxy-1.8.15-6.el8_1.1.x86_64
>
> # yum info haproxy

haproxy -vv is much better then the rpm info.

> Red Hat Update Infrastructure 3 Client Configuration Server 8 
>12 kB/s | 2.1 kB   
>   00:00
> Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)
>24 kB/s | 2.8 kB   
>   00:00
> Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)   
>21 kB/s | 2.4 kB   
>   00:00

Have you asked Red Hat about this issue, maybe there is a nother rpm which have 
ssl build in?

> Installed Packages
>
> Name : haproxy
> Version  : 1.8.15
> Release  : 6.el8_1.1
> Architecture : x86_64
> Size : 4.4 M
> Source   : haproxy-1.8.15-6.el8_1.1.src.rpm
> Repository   : @System
>
>  From repo: rhel-8-appstream-rhui-rpms

[snipp]

> ·So after this configuration file is updated with our configurations. We need 
> to use multiple certificates (SNI) hence used bind option to verify the 
> certificates under the folder. But receiving below error please help us on 
> priority.
>
> Attached configuration file for reference.
>
> Below is the error we are receiving.
>
> # haproxy -f /etc/haproxy/haproxy.cfg -c
>
> [ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:33] : 'bind 
> *:443' unknown keyword 'ssl'. Registered keywords :

Well it looks like the haproxy isn't build with openssl that's the reason why 
the haproxy -vv output is required.

https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcbonte.github.io%2Fhaproxy-dconv%2F1.8%2Fconfiguration.html%235.2-ssldata=02%7C01%7CBINDUSHREE.DB%40cognizant.com%7Cd681f50bb1f54321f8fd08d7e1398d01%7Cde08c40719b9427d9fe8edf254300ca7%7C0%7C0%7C637225509619839030sdata=KreqEBl7WcybZapA5f2nQdjO7p5y8O%2BvE5qWcq4%2B7OA%3Dreserved=0

[snipp]

> [ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:36] : error 
> detected while parsing an 'http-request set-header' condition : unknown fetch 
> method 'ssl_fc' in ACL expression 'ssl_fc'.
>
> [ALERT] 105/113215 (5684) : Error(s) found in configuration file :
> /etc/haproxy/haproxy.cfg
>
> Please check the error and configuration and let me know what needs to done 
> to fix the issue.
>
> Thanks,
>
> Bindushree D B
>
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged 
> information. If you are not the intended recipient(s), please reply to the 
> sender and destroy all copies of the original message. Any unauthorized 
> review, use, disclosure, dissemination, forwarding, printing or copying of 
> this email, and/or any action taken in reliance on the contents of this 
> e-mail is strictly prohibited and may be unlawful. Where permitted by 
> applicable law, this e-mail and other e-mail communications sent to and from 
> Cognizant e-mail addresses may be monitored. This e-mail and any files 
> transmitted with it are for the sole use of the intended recipient(s) and may 
> contain confidential and privileged information. If you are not the intended 
> recipient(s), please reply to the sender and destroy all copies of the 
> original message. Any unauthorized review, use, disclosure, dissemination, 
> forwarding, printing or copying of this email, and/or any action taken in 
> reliance on the contents of this e-mail is strictly prohibited and may be 
> unlawful. Where permitted by applicable law, this e-mail and other e-mail 
> communications sent to and from Cognizant e-mail addresses may be monitored.

Useless disclaimer for a public mailing list!

Regards
Aleks
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged inform

Re: Disclaimer in emails (was: Re: HAproxy Error)

2020-04-15 Thread Lukas Tribus
Hello Tim, Aleks,

I fully agree with everything Tim just said.

Let's keep the list about haproxy.

Lukas



Disclaimer in emails (was: Re: HAproxy Error)

2020-04-15 Thread Tim Düsterhus
Aleks,

Am 15.04.20 um 15:35 schrieb Aleksandar Lazic:
>> Can we please stop complaining about these disclaimers? It adds more
>> noise to the list than the disclaimers itself which are neatly tucked
>> away at the end of the email.
> 
> Nope, because I only add my complaining when I answer a question or try
> to answer a question.
> 
> I agree with you that just to talk about the disclaimer increases the
> noise, but sometimes is a discussion necessary, IMHO.

Even then I scroll through the email to read it in full, only to find a
"get rid of the disclaimer" at the very end. The last quote block + your
comment about the disclaimer takes up 23 lines. That's almost height of
a standard 80x24 terminal (and incidentally also the height of the
message pane within my MUA).

All that for a reply that could be reduced to the following 3 sentences:

The error message indicates that your HAProxy was not compiled with SSL
support enabled. You can check by running `haproxy -vv`. Please always
provide that output when seeking help on the list to allow for effective
support.

>> I'm fully aware that they are of dubious value, but your complaints are
>> not going to change anything about them. The HAProxy users seeking help
>> on the list are not going to be able to get rid of them, because that's
>> usually a decision made by their non-technical management.
> 
> That's a assumption which is not always true, as far as I know. There are
> some persons which can decide by them self which e-mail address they use.

Yes, that's why I said "usually".

>> Maybe they
>> are even legally necessary in some legislation on this world. I don't
>> know, because I'm not a lawyer proficient in law of all 195 countries.
> 
> Me neither but the most reason to ad this disclaimer is legal certainty
> which is useless, from my point of view.

Yes exactly, *your* PoV. The sender's PoV and laws can differ.

>> The users came here to receive help with HAProxy and not to be berated.
> 
> I don't see the notice about useless disclaimer as berate. From my point
> of view is the information that the e-mail disclaimer to a public mailing
> list a clarification not a berate.

A short note *might* be appropriate for a mailing list about email
operations, because the entire purpose of such a list would be "how to
send email properly". The purpose of this list is "how to use HAProxy"
which has nothing to do with email (unless you use HAProxy to load
balance your SMTP servers of course).

>> FWIW: If I was sending mail to this list from $COMPANY email you would
>> need to live with a 14 line signature that is not a disclaimer, but
>> similarly is snail mail information of $COMPANY that I'm required to add
>> by law.
> 
> A snail mail disclaimer is not the same as e-mail disclaimer.

I am aware. That's why I said "[...] is not a disclaimer, but similarly
[...]". Similarly in that it is legal (or pseudo legal) boilerplate.

> https://en.wikipedia.org/wiki/Disclaimer
> https://en.wikipedia.org/wiki/Email_disclaimer#Effectiveness_of_disclaimers

You do not need to educate me with Wikipedia articles. And in fact the
second link uses a very non-committal language by saying that these
disclaimers "[...] may not be legally enforceable". Any statement with a
"may" in it is absolutely useless.

Best regards
Tim Düsterhus



Re: HAproxy Error

2020-04-15 Thread Aleksandar Lazic

On 15.04.20 14:57, Tim Düsterhus wrote:

Aleks,
Ilya,

Am 15.04.20 um 14:35 schrieb Aleksandar Lazic:

Useless disclaimer for a public mailing list!



Am 15.04.20 um 14:25 schrieb Илья Шипицин:> hello.

should we destroy this message ?


Can we please stop complaining about these disclaimers? It adds more
noise to the list than the disclaimers itself which are neatly tucked
away at the end of the email.


Nope, because I only add my complaining when I answer a question or try
to answer a question.

I agree with you that just to talk about the disclaimer increases the
noise, but sometimes is a discussion necessary, IMHO.


I'm fully aware that they are of dubious value, but your complaints are
not going to change anything about them. The HAProxy users seeking help
on the list are not going to be able to get rid of them, because that's
usually a decision made by their non-technical management.


That's a assumption which is not always true, as far as I know. There are
some persons which can decide by them self which e-mail address they use.


Maybe they
are even legally necessary in some legislation on this world. I don't
know, because I'm not a lawyer proficient in law of all 195 countries.


Me neither but the most reason to ad this disclaimer is legal certainty
which is useless, from my point of view.


The users came here to receive help with HAProxy and not to be berated.


I don't see the notice about useless disclaimer as berate. From my point
of view is the information that the e-mail disclaimer to a public mailing
list a clarification not a berate.


FWIW: If I was sending mail to this list from $COMPANY email you would
need to live with a 14 line signature that is not a disclaimer, but
similarly is snail mail information of $COMPANY that I'm required to add
by law.


A snail mail disclaimer is not the same as e-mail disclaimer.

https://en.wikipedia.org/wiki/Disclaimer
https://en.wikipedia.org/wiki/Email_disclaimer#Effectiveness_of_disclaimers


Best regards
Tim Düsterhus


Best regards
Aleks



Re: HAproxy Error

2020-04-15 Thread Tim Düsterhus
Aleks,
Ilya,

Am 15.04.20 um 14:35 schrieb Aleksandar Lazic:
> Useless disclaimer for a public mailing list!
> 

Am 15.04.20 um 14:25 schrieb Илья Шипицин:> hello.
> should we destroy this message ?

Can we please stop complaining about these disclaimers? It adds more
noise to the list than the disclaimers itself which are neatly tucked
away at the end of the email.

I'm fully aware that they are of dubious value, but your complaints are
not going to change anything about them. The HAProxy users seeking help
on the list are not going to be able to get rid of them, because that's
usually a decision made by their non-technical management. Maybe they
are even legally necessary in some legislation on this world. I don't
know, because I'm not a lawyer proficient in law of all 195 countries.

The users came here to receive help with HAProxy and not to be berated.

FWIW: If I was sending mail to this list from $COMPANY email you would
need to live with a 14 line signature that is not a disclaimer, but
similarly is snail mail information of $COMPANY that I'm required to add
by law.

Best regards
Tim Düsterhus



Re: HAproxy Error

2020-04-15 Thread Aleksandar Lazic

Hi.

On 15.04.20 13:39, bindushree...@cognizant.com wrote:

++Adding attachement

Thank you in advance.

Thanks,

Bindushree D B

*From:* D B, Bindushree (Cognizant)
*Sent:* Wednesday, April 15, 2020 5:08 PM
*To:* haproxy@formilux.org
*Subject:* HAproxy Error
*Importance:* High

Hi Team,

We are in the process of using newer HAproxy version.

Below is the scenario explained where we are stuck.

·In RHEL 8.1 version, installed the latest version of the application.

         haproxy-1.8.15-6.el8_1.1.x86_64

# yum info haproxy


haproxy -vv is much better then the rpm info.


Red Hat Update Infrastructure 3 Client Configuration Server 8   
 12 kB/s | 2.1 kB 
00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)  
     24 kB/s | 2.8 kB 
00:00
Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs) 
 21 kB/s | 2.4 kB 
00:00


Have you asked Red Hat about this issue, maybe there is a nother rpm which have 
ssl build in?


Installed Packages

Name     : haproxy
Version  : 1.8.15
Release  : 6.el8_1.1
Architecture : x86_64
Size : 4.4 M
Source   : haproxy-1.8.15-6.el8_1.1.src.rpm
Repository   : @System

 From repo    : rhel-8-appstream-rhui-rpms


[snipp]


·So after this configuration file is updated with our configurations. We need 
to use multiple certificates (SNI) hence used bind option to verify the 
certificates under the folder. But receiving below error please help us on 
priority.

Attached configuration file for reference.

Below is the error we are receiving.

# haproxy -f /etc/haproxy/haproxy.cfg -c

[ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:33] : 'bind 
*:443' unknown keyword 'ssl'. Registered keywords :


Well it looks like the haproxy isn't build with openssl that's the reason why 
the haproxy -vv output is required.

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.2-ssl

[snipp]


[ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:36] : error 
detected while parsing an 'http-request set-header' condition : unknown fetch 
method 'ssl_fc' in ACL expression 'ssl_fc'.

[ALERT] 105/113215 (5684) : Error(s) found in configuration file : 
/etc/haproxy/haproxy.cfg

Please check the error and configuration and let me know what needs to done to 
fix the issue.

Thanks,

Bindushree D B

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of 
this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.


Useless disclaimer for a public mailing list!

Regards
Aleks



Re: HAproxy Error

2020-04-15 Thread Илья Шипицин
ср, 15 апр. 2020 г. в 16:41, :

> Hi Team,
>
>
>
> We are in the process of using newer HAproxy version.
>
> Below is the scenario explained where we are stuck.
>
>
>
> · In RHEL 8.1 version, installed the latest version of the
> application.
>
> haproxy-1.8.15-6.el8_1.1.x86_64
>
> # yum info haproxy
>
> Red Hat Update Infrastructure 3 Client Configuration Server
> 8
> 12 kB/s | 2.1 kB 00:00
>
> Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI
> (RPMs)
>   24 kB/s | 2.8 kB 00:00
>
> Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI
> (RPMs)
> 21 kB/s | 2.4 kB 00:00
>
> Installed Packages
>
> Name : haproxy
>
> Version  : 1.8.15
>
> Release  : 6.el8_1.1
>
> Architecture : x86_64
>
> Size : 4.4 M
>
> Source   : haproxy-1.8.15-6.el8_1.1.src.rpm
>
> Repository   : @System
>
> From repo: rhel-8-appstream-rhui-rpms
>
> Summary  : HAProxy reverse proxy for high availability environments
>
> URL  : http://www.haproxy.org/
>
> License  : GPLv2+
>
> Description  : HAProxy is a TCP/HTTP reverse proxy which is particularly
> suited for high
>
>  : availability environments. Indeed, it can:
>
>  :  - route HTTP requests depending on statically assigned
> cookies
>
>  :  - spread load among several servers while assuring server
> persistence
>
>  :through the use of HTTP cookies
>
>  :  - switch to backup servers in the event a main one fails
>
>  :  - accept connections to special ports dedicated to service
> monitoring
>
>  :  - stop accepting connections without breaking existing ones
>
>  :  - add, modify, and delete HTTP headers in both directions
>
>  :  - block requests matching particular patterns
>
>  :  - report detailed status to authenticated users from a URI
>
>  :intercepted from the application
>
>
>
> · So after this configuration file is updated with our
> configurations. We need to use multiple certificates (SNI) hence used bind
> option to verify the certificates under the folder. But receiving below
> error please help us on priority.
>
> Attached configuration file for reference.
>
> Below is the error we are receiving.
>
>
>
> # haproxy -f /etc/haproxy/haproxy.cfg -c
>
> [ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:33] : 'bind
> *:443' unknown keyword 'ssl'. Registered keywords :
>
> [STAT] level 
>
> [STAT] expose-fd 
>
> [STAT] severity-output 
>
> [ TCP] defer-accept
>
> [ TCP] interface 
>
> [ TCP] mss 
>
> [ TCP] tcp-ut 
>
> [ TCP] tfo
>
> [ TCP] transparent
>
> [ TCP] v4v6
>
> [ TCP] v6only
>
> [ TCP] namespace 
>
> [ ALL] accept-netscaler-cip 
>
> [ ALL] accept-proxy
>
> [ ALL] backlog 
>
> [ ALL] id 
>
> [ ALL] maxconn 
>
> [ ALL] name 
>
> [ ALL] nice 
>
> [ ALL] process 
>
> [ ALL] proto 
>
> [UNIX] gid 
>
> [UNIX] group 
>
> [UNIX] mode 
>
> [UNIX] uid 
>
> [UNIX] user 
>
> [ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:36] : error
> detected while parsing an 'http-request set-header' condition : unknown
> fetch method 'ssl_fc' in ACL expression 'ssl_fc'.
>
> [ALERT] 105/113215 (5684) : Error(s) found in configuration file :
> /etc/haproxy/haproxy.cfg
>
> Please check the error and configuration and let me know what needs to
> done to fix the issue.
>
>
>
>
>
>
>
> Thanks,
>
> Bindushree D B
>
>
> This e-mail and any files transmitted with it are for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. If you are not the intended recipient(s), please reply to the
> sender and destroy all copies of the original message. Any unauthorized
> review, use, disclosure, dissemination, forwarding, printing or copying of
>

hello.
should we destroy this message ?



> this email, and/or any action taken in reliance on the contents of this
> e-mail is strictly prohibited and may be unlawful. Where permitted by
> applicable law, this e-mail and other e-mail communications sent to and
> from Cognizant e-mail addresses may be monitored. This e-mail and any files
> transmitted with it are for the sole use of the intended recipient(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient(s), please reply to the sender and destroy all copies of
> the original message. Any unauthorized review, use, disclosure,
> dissemination, forwarding, printing or copying of this email, and/or any
> action taken in reliance on the contents of this e-mail is strictly
> prohibited and may be unlawful. Where permitted by applicable law, this
> e-mail and other e-mail communications sent to and from Cognizant e-mail
> addresses may be monitored.
>


RE: HAproxy Error

2020-04-15 Thread BINDUSHREE.DB
++Adding attachement

Thank you in advance.

Thanks,
Bindushree D B

From: D B, Bindushree (Cognizant)
Sent: Wednesday, April 15, 2020 5:08 PM
To: haproxy@formilux.org
Subject: HAproxy Error
Importance: High

Hi Team,

We are in the process of using newer HAproxy version.
Below is the scenario explained where we are stuck.


* In RHEL 8.1 version, installed the latest version of the application.
haproxy-1.8.15-6.el8_1.1.x86_64
# yum info haproxy
Red Hat Update Infrastructure 3 Client Configuration Server 8   
 12 kB/s | 2.1 kB 
00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)  
 24 kB/s | 2.8 kB 
00:00
Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs) 
 21 kB/s | 2.4 kB 
00:00
Installed Packages
Name : haproxy
Version  : 1.8.15
Release  : 6.el8_1.1
Architecture : x86_64
Size : 4.4 M
Source   : haproxy-1.8.15-6.el8_1.1.src.rpm
Repository   : @System
>From repo: rhel-8-appstream-rhui-rpms
Summary  : HAProxy reverse proxy for high availability environments
URL  : http://www.haproxy.org/
License  : GPLv2+
Description  : HAProxy is a TCP/HTTP reverse proxy which is particularly suited 
for high
 : availability environments. Indeed, it can:
 :  - route HTTP requests depending on statically assigned cookies
 :  - spread load among several servers while assuring server 
persistence
 :through the use of HTTP cookies
 :  - switch to backup servers in the event a main one fails
 :  - accept connections to special ports dedicated to service 
monitoring
 :  - stop accepting connections without breaking existing ones
 :  - add, modify, and delete HTTP headers in both directions
 :  - block requests matching particular patterns
 :  - report detailed status to authenticated users from a URI
 :intercepted from the application


* So after this configuration file is updated with our configurations. 
We need to use multiple certificates (SNI) hence used bind option to verify the 
certificates under the folder. But receiving below error please help us on 
priority.

Attached configuration file for reference.

Below is the error we are receiving.



# haproxy -f /etc/haproxy/haproxy.cfg -c

[ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:33] : 'bind 
*:443' unknown keyword 'ssl'. Registered keywords :

[STAT] level 

[STAT] expose-fd 

[STAT] severity-output 

[ TCP] defer-accept

[ TCP] interface 

[ TCP] mss 

[ TCP] tcp-ut 

[ TCP] tfo

[ TCP] transparent

[ TCP] v4v6

[ TCP] v6only

[ TCP] namespace 

[ ALL] accept-netscaler-cip 

[ ALL] accept-proxy

[ ALL] backlog 

[ ALL] id 

[ ALL] maxconn 

[ ALL] name 

[ ALL] nice 

[ ALL] process 

[ ALL] proto 

[UNIX] gid 

[UNIX] group 

[UNIX] mode 

[UNIX] uid 

[UNIX] user 

[ALERT] 105/113215 (5684) : parsing [/etc/haproxy/haproxy.cfg:36] : error 
detected while parsing an 'http-request set-header' condition : unknown fetch 
method 'ssl_fc' in ACL expression 'ssl_fc'.

[ALERT] 105/113215 (5684) : Error(s) found in configuration file : 
/etc/haproxy/haproxy.cfg
Please check the error and configuration and let me know what needs to done to 
fix the issue.



Thanks,
Bindushree D B

This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient(s), please reply to the sender and 
destroy all copies of the original message. Any unauthorized review, use, 
disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored. This e-mail and any files transmitted with it are for the sole 
use of the intended recipient(s) and may contain confidential and privileged 
information. If you are not the intended recipient(s), please reply to the 
sender and destroy all copies of the original message. Any unauthorized review, 
use, disclosure, dissemination, forwarding, printing or copying of this email, 
and/or any action taken in reliance on the contents of this e-mail is strictly 
prohibited and may be unlawful. Where permitted by applicable law, this e-mail 
and other e-mail communications sent to and from Cognizant e-mail addresses may 
be monitored.
global
log 127.0.0.1 local0 debug
user 

Re: HAProxy error log

2016-07-15 Thread CJ Ess
>From global section:

  log 127.0.0.1 local0
  log 127.0.0.1 local1 err

>From defaults section:

  log global
  option httplog
  option log-separate-errors

>From rsyslog confg:

$Umask 
$FileCreateMode 0644
local1.* -/var/log/haproxy/haproxy_errors.log

No network capture available.


On Fri, Jul 15, 2016 at 3:45 PM, Cyril Bonté  wrote:

> Le 15/07/2016 à 19:35, CJ Ess a écrit :
>
>> I think I gave the relevant details but here is a sample (with hostname,
>> frontend name, backend name, server name, user agent, x-forwarded-for
>> chain, and url path changed). I have thousands of these, identical
>> frontends, backends, method, and url) to a pool of identical servers.
>> Each of these appears in the error log, however they all have in common
>> a 200 result code and -'s for state flags. I don't know why these would
>> appear in the error log.
>>
>> 2016-07-15T13:00:19-04:00 hostname haproxy[116593]: 127.0.0.1:62401
>>  [15/Jul/2016:13:00:16.191] frontend_name
>> backend_name/server_name 790/0/953/1155/2898 200 135 - - 
>> 17847/17845/5414/677/0 0/0 {user_agent|x-forwarded-for} "POST
>> /services/x HTTP/1.1"
>>
>
> Well this log line is a beginning, but details are  :
> - the haproxy configuration
> - the syslog server configuration/rules
> - a network capture showing that logs are sent at an error level
>
>
>
>> On Fri, Jul 15, 2016 at 1:24 PM, Cyril Bonté > > wrote:
>>
>> Le 15/07/2016 à 17:46, CJ Ess a écrit :
>>
>> I've got thousands of errors showing up in my haproxy error.log
>> but I'm
>> not sure why, the requests being logged there have a 200 result
>> code and
>> the session state flags are all -'s. However its primarily
>> requests to a
>> particular backend being logged there. What can I do to diagnose?
>>
>>
>> At least, provide some details.
>>
>>
>>
>> My HAProxy version is 1.5.18
>>
>>
>>
>> --
>> Cyril Bonté
>>
>>
>>
>
> --
> Cyril Bonté
>


Re: HAProxy error log

2016-07-15 Thread Cyril Bonté

Le 15/07/2016 à 19:35, CJ Ess a écrit :

I think I gave the relevant details but here is a sample (with hostname,
frontend name, backend name, server name, user agent, x-forwarded-for
chain, and url path changed). I have thousands of these, identical
frontends, backends, method, and url) to a pool of identical servers.
Each of these appears in the error log, however they all have in common
a 200 result code and -'s for state flags. I don't know why these would
appear in the error log.

2016-07-15T13:00:19-04:00 hostname haproxy[116593]: 127.0.0.1:62401
 [15/Jul/2016:13:00:16.191] frontend_name
backend_name/server_name 790/0/953/1155/2898 200 135 - - 
17847/17845/5414/677/0 0/0 {user_agent|x-forwarded-for} "POST
/services/x HTTP/1.1"


Well this log line is a beginning, but details are  :
- the haproxy configuration
- the syslog server configuration/rules
- a network capture showing that logs are sent at an error level




On Fri, Jul 15, 2016 at 1:24 PM, Cyril Bonté > wrote:

Le 15/07/2016 à 17:46, CJ Ess a écrit :

I've got thousands of errors showing up in my haproxy error.log
but I'm
not sure why, the requests being logged there have a 200 result
code and
the session state flags are all -'s. However its primarily
requests to a
particular backend being logged there. What can I do to diagnose?


At least, provide some details.



My HAProxy version is 1.5.18



--
Cyril Bonté





--
Cyril Bonté



Re: HAProxy error log

2016-07-15 Thread CJ Ess
I think I gave the relevant details but here is a sample (with hostname,
frontend name, backend name, server name, user agent, x-forwarded-for
chain, and url path changed). I have thousands of these, identical
frontends, backends, method, and url) to a pool of identical servers. Each
of these appears in the error log, however they all have in common a 200
result code and -'s for state flags. I don't know why these would appear in
the error log.

2016-07-15T13:00:19-04:00 hostname haproxy[116593]: 127.0.0.1:62401
[15/Jul/2016:13:00:16.191] frontend_name backend_name/server_name
790/0/953/1155/2898 200 135 - -  17847/17845/5414/677/0 0/0
{user_agent|x-forwarded-for} "POST /services/x HTTP/1.1"

On Fri, Jul 15, 2016 at 1:24 PM, Cyril Bonté  wrote:

> Le 15/07/2016 à 17:46, CJ Ess a écrit :
>
>> I've got thousands of errors showing up in my haproxy error.log but I'm
>> not sure why, the requests being logged there have a 200 result code and
>> the session state flags are all -'s. However its primarily requests to a
>> particular backend being logged there. What can I do to diagnose?
>>
>
> At least, provide some details.
>
>
>
> My HAProxy version is 1.5.18
>>
>>
>
> --
> Cyril Bonté
>


Re: HAProxy error log

2016-07-15 Thread Cyril Bonté

Le 15/07/2016 à 17:46, CJ Ess a écrit :

I've got thousands of errors showing up in my haproxy error.log but I'm
not sure why, the requests being logged there have a 200 result code and
the session state flags are all -'s. However its primarily requests to a
particular backend being logged there. What can I do to diagnose?


At least, provide some details.



My HAProxy version is 1.5.18




--
Cyril Bonté