Re: Server timeouts since HAProxy 2.2

2022-08-04 Thread Vincent Bernat

On 2022-08-04 10:35, William Edwards wrote:

However, 
https://haproxy.debian.net/#distribution=Debian=buster=2.2 says:


"The Debian HAProxy packaging team provides various versions of HAProxy 
packages for use on different Debian or Ubuntu systems. The following 
wizard helps you to find the package suitable for your system. [...] You 
will get a stable release of HAProxy 2.2: you may not get the latest 
version but important fixes from later versions are included. Moreover, 
regressions are unlikely."


The bugs page tries to get users to ALWAYS use the latest version. But 
the haproxy.debian.org page says that it's okay not to use the latest 
version.


That's two different point of views, one from Debian, one from upstream. 
They are difficult to reconcile. That's why you (as a user) have to 
choose: an old version with only "important" fixes (security fixes 
mostly) and with known bugs but unlikely regressions on upgrade, or a 
recent version of a stable branch with fixes and sometimes regressions.


Upstream is unlikely to help debug old versions. The Debian solution is 
to report the issue on bugs.debian.org, but this does not scale well and 
I am likely to just ignore the bug because I am too short on time. If 
2.2.9 as in official Debian repository does not work for you, the 
easiest path is to upgrade to 2.2.25 using the second set of instructions.


> I found this bug[1] on the bugs page which looks promising. I'll do
> some more investigation today. Perhaps someone could corroborate that
> that bug's symptoms match what I'm seeing.

Note that if this patch fixes this bug, this is a lot of work to 
integrate it into the current release of Debian. This will have to wait 
for the next point release (not a security issue), I would need to ask 
people to authorize the patch, explain, ask again, prepare, upload, then 
upload the backports until you get the resulting package available as 
2.2.9-2+deb11u4~bpo10+1. Backporting a random patch may trigger 
regressions as it may need other patches to be backported. This is a 
nest of problems. So, if this patch solves your issue, you are on your 
own maintaining a fork of the package.


The commit mentioned in the patch (eddcfbc1911c when backported) is 
introduced in 2.2.23, so it's likely not the patch you need or you need 
other patches as well.




Re: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04

2022-07-09 Thread Vincent Bernat

On 7/9/22 10:55, Willy Tarreau wrote:

On Sat, Jul 09, 2022 at 12:03:02AM +0200, Vincent Bernat wrote:

The error when not running as root is expected. However, the fact it does
not work on boot, then works after is odd. Can you share a minimal
configuration file which exhibits this issue?


That's very strange, it sounds as if the service was not started as
root. Was there any change in ubuntu 22 regarding the definition of
what user a service starts under ?


We did some debugging off-list and the IP addresses were handled by 
keepalived and ip_nonlocal_bind sysctl was not enabled.




Re: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04

2022-07-08 Thread Vincent Bernat
The error when not running as root is expected. However, the fact it 
does not work on boot, then works after is odd. Can you share a minimal 
configuration file which exhibits this issue?


On 7/8/22 23:43, Henning Svane wrote:

Hi Vincent

And found out if I started the service manual with sudo it also worked
sudo service haproxy start
odin@haproxyxmail01:~$ systemctl status haproxy.service
● haproxy.service - HAProxy Load Balancer
  Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor 
preset: enabled)
  Active: active (running) since Fri 2022-07-08 23:39:11 CEST; 5s ago
Docs: man:haproxy(1)
  file:/usr/share/doc/haproxy/configuration.txt.gz
Main PID: 1945 (haproxy)
   Tasks: 17 (limit: 4578)
  Memory: 22.0M
 CPU: 945ms
  CGroup: /system.slice/haproxy.service
  ├─1945 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p 
/run/haproxy.pid -S /run/haproxy-master.sock
  └─1947 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p 
/run/haproxy.pid -S /run/haproxy-master.sock


sudo ls -l /run/haproxy.pid
-rw-r--r-- 1 root root 5 Jul  8 23:39 /run/haproxy.pid

Haproxy.pid will only be created it haproxy/haproxy.service has been started 
with sudo else it is missing

Regards
Henning

-Oprindelig meddelelse-
Fra: Henning Svane 
Sendt: 8. juli 2022 23:32
Til: Vincent Bernat 
Cc: haproxy@formilux.org
Emne: SV: SV: Config will not start on 2.6.1 on Ubuntu 22.04

Hi Vincent

I have now build 2 new Ubuntu 22.04 servers

It looks like when haproxy service is started under boot it do not have 
permission to bind to interfaces.
If I from console start haproxy manual with sudo it works, but not without 
sudo, then it behaves like when the haproxy.services is started under boot.
So my question how to fix this? So the service is started with permission to 
bind to interfaces.

I can see haproxy.service has these permissions
-rw-r--r-- 1 root root 1506 Jun 22 20:49 /lib/systemd/system/haproxy.service

Start of service under boot:
systemctl status haproxy.service
× haproxy.service - HAProxy Load Balancer
  Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor 
preset: enabled)
  Active: failed (Result: exit-code) since Fri 2022-07-08 16:13:25 CEST; 
1min 56s ago
Docs: man:haproxy(1)
  file:/usr/share/doc/haproxy/configuration.txt.gz
 Process: 1069 ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE 
$EXTRAOPTS (code=exited, status=1/FAILURE)
Main PID: 1069 (code=exited, status=1/FAILURE)
 CPU: 209ms

Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Main process 
exited, code=exited, status=1/FAILURE Jul 08 16:13:25 haproxyxmail01 
systemd[1]: haproxy.service: Failed with result 'exit-code'.
Jul 08 16:13:25 haproxyxmail01 systemd[1]: Failed to start HAProxy Load 
Balancer.
Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Scheduled restart 
job, restart counter is at 5.
Jul 08 16:13:25 haproxyxmail01 systemd[1]: Stopped HAProxy Load Balancer.
Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Start request 
repeated too quickly.
Jul 08 16:13:25 haproxyxmail01 systemd[1]: haproxy.service: Failed with result 
'exit-code'.
Jul 08 16:13:25 haproxyxmail01 systemd[1]: Failed to start HAProxy Load 
Balancer.

And if I try to run my configuration from console Without sudo it fails And 
with sudo it works (See below)

haproxy -d -f /etc/haproxy/haproxy.cfg
Available polling systems :
   epoll : pref=300,  test result OK
poll : pref=200,  test result OK
  select : pref=150,  test result FAILED
Total: 3 (2 usable), will use epoll.

Available filters :
 [CACHE] cache
 [COMP] compression
 [FCGI] fcgi-app
 [  OT] opentracing
 [SPOE] spoe
 [TRACE] trace
Using epoll() as the polling mechanism.
[NOTICE]   (1811) : haproxy version is 2.6.1-1ppa1~jammy
[NOTICE]   (1811) : path to executable is /usr/sbin/haproxy
[ALERT](1811) : Binding [/etc/haproxy/haproxy.cfg:85] for frontend 
FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission denied) for 
[xx.xx.58.10:80]
[ALERT](1811) : Binding [/etc/haproxy/haproxy.cfg:86] for frontend 
FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission denied) for 
[xx.xx.58.10:443]
...
[ALERT](1811) : [haproxy.main()] Some protocols failed to start their 
listeners! Exiting.


sudo haproxy -d -f /etc/haproxy/haproxy.cfg Available polling systems :
   epoll : pref=300,  test result OK
poll : pref=200,  test result OK
  select : pref=150,  test result FAILED
Total: 3 (2 usable), will use epoll.

Available filters :
 [CACHE] cache
 [COMP] compression
 [FCGI] fcgi-app
 [  OT] opentracing
 [SPOE] spoe
 [TRACE] trace
Using epoll() as the polling mechanism.
[WARNING]  (1794) : Health check for server HA_DAG_XMail_Autodiscover/XMailDB02 
succeeded, reason: Layer7 check passed, code: 200, check

Re: SV: Config will not start on 2.6.1 on Ubuntu 22.04

2022-07-06 Thread Vincent Bernat
comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.752:6): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="man_filter" pid=790 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.752:7): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="man_groff" pid=790 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.756:8): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/lib/snapd/snap-confine" pid=791 
comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.756:9): apparmor="STATUS" operation="profile_load" 
profile="unconfined" 
name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" 
pid=791 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.760:10): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="lsb_release" pid=792 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.764:11): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/sbin/chronyd" pid=793 comm="apparmor_parser"


Regards

Henning

*Fra:*Vincent Bernat 
*Sendt:* 6. juli 2022 19:06
*Til:* haproxy@formilux.org
*Cc:* Henning Svane 
*Emne:* Re: Config will not start on 2.6.1 on Ubuntu 22.04

On 7/6/22 00:37, Henning Svane wrote:

I get under load of haproxy the following problems for all frontends

What do you mean by "under load"?

Here are two of the errors

for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission
denied) for IPv4 number and port

and

for frontend GLOBAL: cannot bind UNIX socket (Permission denied)
[/run/haproxy/admin.sock]

global

     maxconn 8000

     log /dev/log local0

     log /dev/log local1 notice

     chroot /var/lib/haproxy

     stats socket /run/haproxy/admin.sock mode 660 level admin
expose-fd listeners

     stats timeout 30s

     user haproxy

     group haproxy

     daemon

I have compared folder permission /run/haproxy on Ubuntu 20.04.4
with Ubuntu 22.04 and the permission looks like this for both.

  [/run/haproxy/admin.sock have these permission

drwxrwsr-x  2 haproxy haproxy   40 Jul  5 20:01 haproxy

I have tried your configuration on a freshly installed Ubuntu 22.04 and 
didn't run into any issue. Are you using apparmor? `journalctl -k | grep 
haproxy` may give a hint if you have a profile for it (not shipped by 
the package nor Ubuntu as far as I can see).






Re: Config will not start on 2.6.1 on Ubuntu 22.04

2022-07-06 Thread Vincent Bernat

On 7/6/22 00:37, Henning Svane wrote:

I get under load of haproxy the following problems for all frontends

What do you mean by "under load"?


Here are two of the errors

for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission 
denied) for IPv4 number and port


and

for frontend GLOBAL: cannot bind UNIX socket (Permission denied) 
[/run/haproxy/admin.sock]


global

    maxconn 8000

    log /dev/log local0

    log /dev/log local1 notice

    chroot /var/lib/haproxy

    stats socket /run/haproxy/admin.sock mode 660 level admin 
expose-fd listeners


    stats timeout 30s

    user haproxy

    group haproxy

    daemon

I have compared folder permission /run/haproxy on Ubuntu 20.04.4 with 
Ubuntu 22.04 and the permission looks like this for both.


 [/run/haproxy/admin.sock have these permission

drwxrwsr-x  2 haproxy haproxy   40 Jul  5 20:01 haproxy

I have tried your configuration on a freshly installed Ubuntu 22.04 and 
didn't run into any issue. Are you using apparmor? `journalctl -k | grep 
haproxy` may give a hint if you have a profile for it (not shipped by 
the package nor Ubuntu as far as I can see).


Re: [ANNOUNCE] haproxy-2.6.0

2022-06-14 Thread Vincent Bernat

On 6/14/22 14:22, Artur wrote:


No plan to prepare 2.6 packages for Debian 10 ?

If you can, I'm interested. Thank you.


No particular reason, just nobody asked for it. It will land shortly.



Re: [ANNOUNCE] haproxy-2.6.0

2022-06-03 Thread Vincent Bernat
 ❦ 31 May 2022 17:56 +02, Willy Tarreau:

> HAProxy 2.6.0 was released on 2022/05/31. It added 57 new commits
> after version 2.6-dev12, essentially small bug fixes, QUIC counters
> and doc updates.

It's available on haproxy.debian.net. No QUIC support as neither Debian
nor Ubuntu has the appropriate library.
-- 
The better part of valor is discretion.
-- William Shakespeare, "Henry IV"



Re: [PATCH 1/1: BUILD/MINOR: TCP_KEEPIDLE macos equivalence

2022-05-08 Thread Vincent Bernat
 ❦  8 May 2022 10:57 +02, Willy Tarreau:

> After edition (still minimal and possibly inaccurate but the best I
> could do):
>
> On Linux the interval before starting to send TCP keep-alive packets
> is defined by TCP_KEEPIDLE. MacOS has an equivalent with TCP_KEEPIDLE,
> which also uses seconds as a unit, so it's possible to simply remap the
> definition of TCP_KEEPIDLE to TCP_KEEPALIVE there and get it to seamlessly
> work. The other settings (interval and count) are not present,
> though.

First instance of TCP_KEEPIDLE should be TCP_KEEPALIVE. ;-)
-- 
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-2.5.2

2022-02-16 Thread Vincent Bernat
 ❦ 16 February 2022 22:15 +01, Willy Tarreau:

> That's exactly the sense behind the word "maybe" above, to open the
> discussion :-)  Those with large buffers can definitely see a
> difference. I've seen configs with WAF analysis using 1MB buffers,
> and there the extra CPU usage will be noticeable, maybe 5-10%. My
> impression is that the vast majority of users rely on distro packages
> and are not sensitive to performance (typically sites like haproxy.org
> where enabling everything has no measurable impact, when I'm lucky I
> see 1% CPU). Those who deal with high levels of traffic tend to be
> forced to follow stable updates more often, they'll typically build
> from the Git tree, and are also more at ease with debugging options.
> That was my reasoning, it may be wrong, and I perfectly understand
> your point which is equally valid. And I'm not even asking for a
> change, just saying "maybe it would be even better if".

For Debian, being a binary distribution, we cannot be flexible with the
users. In the past, we were often told we were less performant than a
source distribution because we didn't enable this or this optimization.
Also, 1% CPU increase could also translate to increased latency.

As a comparison, we did not have memory cgroups in our kernels until the
overhead was reduced quite significantly when not using them. On our
side, we believe everyone is using Debian packages. ;-)
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain



Re: [ANNOUNCE] haproxy-2.5.2

2022-02-16 Thread Vincent Bernat
 ❦ 16 February 2022 16:27 +01, Willy Tarreau:

> Maybe that would even be a nice improvement for distros to provide these
> by default starting with 2.6 or maybe even 2.5.

Why not enabling them directly on your side then? Are there some numbers
on the performance impact of these options? I am a bit uncomfortable
providing packages that perform slower than an upstream build.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-2.2.18

2021-11-06 Thread Vincent Bernat
 ❦  5 November 2021 17:05 -06, Jim Freeman:

> Might this (or something 2.4-ish) be heading towards bullseye-backports ?
> https://packages.debian.org/search?keywords=haproxy
> https://packages.debian.org/bullseye-backports/

2.4 will be in bullseye-backports.
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

2021-10-22 Thread Vincent Bernat
 ❦ 22 October 2021 21:08 +02, Willy Tarreau:

>>  ? 19 October 2021 09:22 +02, Vincent Bernat:
>> 
>> > This could be backported to 2.4. Older versions do not display CFLAGS.
>> 
>> Note that if you find this too ugly, I have no problem to maintain this
>> as an OOT patch.
>
> I don't find it ugly. I think it's not the most elegant part of the
> makefile, but a makefile (and ours in particular) is generally not a
> collection of elegant stuff.
>
> I'm just thinking, we have a SILENT_DEFINE macro that should already
> address this. Could you please try to pass your -f... there ? If it
> works it would just be a matter of improving the SILENT_DEFINE
> description to indicate that it works as well for compiler options
> that we don't want to see on the output.

I don't use it directly, it's pushed by Debian build system with some
other flags. I could puts all of them (-g -O2
-ffile-prefix-map=/home/bernat/code/exoscale/haproxy=.
-fstack-protector-strong -Wformat -Werror=format-security) in
SILENT_DEFINE, but if at somepoint, some of them are more invasive, it
would may not be a good idea to hide them out of your view.

Maybe just sit on the patch and see if another distro see a need for it.
I'll keep it as a Debian patch for now and I'll complain in a few years
if I am tired of it.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

2021-10-19 Thread Vincent Bernat
 ❦ 19 October 2021 09:22 +02, Vincent Bernat:

> This could be backported to 2.4. Older versions do not display CFLAGS.

Note that if you find this too ugly, I have no problem to maintain this
as an OOT patch.
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)



[PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

2021-10-19 Thread Vincent Bernat
Some distributions (Debian) adds `-ffile-prefix-map=/current/pwd=` to
CFLAGS in an attempt to make the package more reproducible when source
code is using `__FILE__`. Unfortunately, this makes HAProxy build not
reproducible since CFLAGS is recorded to be displayed in `haproxy
--version`. To solve this, we filter out these arguments as they are
not really important to report to the user.

This could be backported to 2.4. Older versions do not display CFLAGS.
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 50a21b3105cd..6597f0bf855f 100644
--- a/Makefile
+++ b/Makefile
@@ -968,7 +968,7 @@ src/haproxy.o:  src/haproxy.c $(DEP)
  -DBUILD_ARCH='"$(strip $(ARCH))"' \
  -DBUILD_CPU='"$(strip $(CPU))"' \
  -DBUILD_CC='"$(strip $(CC))"' \
- -DBUILD_CFLAGS='"$(strip $(VERBOSE_CFLAGS))"' \
+ -DBUILD_CFLAGS='"$(filter-out -ffile-prefix-map=% 
-fmacro-prefix-map=% -fdebug-prefix-map=%,$(strip $(VERBOSE_CFLAGS)))"' \
  -DBUILD_OPTIONS='"$(strip $(BUILD_OPTIONS))"' \
  -DBUILD_DEBUG='"$(strip $(DEBUG))"' \
  -DBUILD_FEATURES='"$(strip $(BUILD_FEATURES))"' \
-- 
2.33.0




Re: [ANNOUNCE] haproxy-2.4.5

2021-10-03 Thread Vincent Bernat
 ❦  3 October 2021 08:53 +02, Christopher Faulet:

> I will push a fix. As a workaround, you can temporarily disable the HTTP 
> compression filter.

Will you release 2.4.6 or should we push packages for 2.4.5 with the
patch? For Debian/Ubuntu, I didn't push packages for 2.4.5 yet.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev

2021-09-08 Thread Vincent Bernat
 ❦  8 September 2021 09:02 +02, Artur:

> Hello,
>
> Thank you.
>
> Could you please explain the version numbering differences between official 
> haproxy release and the linux distributions
> packages ?
>
> For example : 2.4.4 (official) -> 2.4.3-2~bpo10+1 (Debian 10
> backports)

2.4.3-2~bpo10+1 means this is based on upstream version 2.4.3, second
revision for Debian (-2), backport to Debian 10 (~bpo10), first iteration of
the backport (+1). The changelog (in ~doc/haproxy/changelog.Debian.gz)
gives a hint of the deviation compared to official upstream version:

haproxy (2.4.3-2~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

 -- Vincent Bernat   Sat, 04 Sep 2021 15:19:43 +0200

haproxy (2.4.3-2) experimental; urgency=high

  * d/patches: fix missing header name length check in HTX (CVE-2021-40346).

 -- Vincent Bernat   Sat, 04 Sep 2021 11:56:31 +0200

haproxy (2.4.3-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

 -- Vincent Bernat   Sat, 21 Aug 2021 16:47:45 +0200

haproxy (2.4.3-1) experimental; urgency=medium

  * New upstream release.
  * d/patches: remove patches applied upstream.
  * d/patches: h2: match absolute-path not path-absolute for :path.

 -- Vincent Bernat   Sat, 21 Aug 2021 16:32:25 +0200

Debian packages are not based on 2.4.4 because they were prepared in
advance to be ready when the vulnerability is announced. Packages based
on 2.4.4 will get available later this week.
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev

2021-09-07 Thread Vincent Bernat
 ❦  7 September 2021 17:27 +02, Willy Tarreau:

> I'd like to thank the usual distro maintainers for having accepted to
> produce yet another version of their packages in a short time. Hopefully
> now we can all get back to development!

For Debian/Ubuntu, the fixed versions are:

2.4.3-2
2.4.3-2~bpo10+1
2.4.3-2~bpo11+1
2.4.3-2ppa2~bionic
2.4.3-2ppa1~focal

2.3.13-2
2.3.13-2~bpo10+1
2.3.13-2ppa1~bionic
2.3.13-2ppa1~focal

2.2.16-3
2.2.16-3~bpo9+1
2.2.16-3~bpo10+1
2.2.16-3ppa1~bionic
2.2.16-3ppa1~focal
2.2.9-2+deb11u2 (to be released pretty soon)
2.2.9-2+deb11u2~bpo10+1 (not released yet)
2.2.9-1ubuntu0.2 (not 100% sure as it is not released yet)

2.0.24-1
2.0.24-1~bpo9+1
2.0.24-1~bpo10+1
2.0.24-1ppa1~xenial
2.0.24-1ppa1~bionic
2.0.24-1ppa1~focal
2.0.13-2ubuntu0.3 (not 100% sure as it is not released yet)
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] HTTP/2 vulnerabilities from 2.0 to 2.5-dev

2021-08-17 Thread Vincent Bernat
 ❦ 17 August 2021 17:13 +02, Willy Tarreau:

> HAProxy is affected by 4 vulnerabilities in its HTTP/2 implementation in
> recent versions (starting with 2.0). Three of them are considered as having
> a moderate impact as they only affect the interpretation of the authority
> (Host header field) in H2->H2 communications in versions 2.2 and above.
> One only affects a risk of misinterpretation from lenient HTTP/1 backend
> servers, and affects version 2.0 and above, though at the time of writing
> we're not aware of any such vulnerable server among the mainstream ones
> that are commonly found behind HAProxy (Apache, NGINX, Varnish, etc).

For users of haproxy.debian.net or Launchpad PPA, the vulnerabilities
are fixed by patching the previous versions. Launchpad PPA builders are
still running but it should be available in the next hour. I will upload
the new versions later this week.

Check the changelog (in /usr/share/doc/haproxy/changelog.Debian.gz) if
you want to know if you are running a fixed version. The list of fixed
versions are:

haproxy_2.4.2-2~bpo10+1
haproxy_2.4.2-2~bpo11+1
haproxy_2.4.2-2ppa1~bionic
haproxy_2.4.2-2ppa1~focal
haproxy_2.2.9-2+deb11u1 (should be available from debian-security soon)
haproxy_2.3.12-2~bpo10+1
haproxy_2.3.12-2ppa1~bionic
haproxy_2.3.12-2ppa1~focal
haproxy_2.2.15-3~bpo9+1
haproxy_2.2.15-3~bpo10+1
haproxy_2.2.15-3ppa1~bionic
haproxy_2.2.15-3ppa1~focal
haproxy_2.0.23-3~bpo9+1
haproxy_2.0.23-3~bpo10+1
haproxy_2.0.23-3ppa1~xenial
haproxy_2.0.23-3ppa1~bionic
haproxy_2.0.23-3ppa1~focal

-- 
Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Test, please ignore

2021-07-23 Thread Vincent Bernat
 ❦ 23 July 2021 12:55 +02, Willy Tarreau:

> The list looks uncommonly quiet after having touched some
> anti-spam rules, just testing.

It's the holidays Willy! :)
-- 
Don't over-comment.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-2.3.12

2021-07-08 Thread Vincent Bernat
 ❦  8 July 2021 17:47 +02, Willy Tarreau:

> I'm seeing that at least Vincent was fast enough to package 2.3.11 for
> debian 10, I hope nobody deployed it yet. I'm really sorry for the mess.
> For those who are wondering, 2.4 was not affected.

The new packages are available!
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Official ubuntu 20 repository

2021-06-06 Thread Vincent Bernat
 ❦  6 June 2021 11:54 +01, Ismail Azerty:

> Is there any official ubuntu 20 repository to install the latest
> version of haproxy ?

This is semi-official: 
https://haproxy.debian.net/#?distribution=Ubuntu=focal
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-2.4.0

2021-05-21 Thread Vincent Bernat
 ❦ 17 mai 2021 17:48 +02, Artur:

> When can we expect prebuilt packages for Debian on haproxy.debian.net
> ?

They have been published. Buster, Bionic and Focal are available.
-- 
He jests at scars who never felt a wound.
-- Shakespeare, "Romeo and Juliet, II. 2"



Re: [ANNOUNCE] haproxy-2.4.0

2021-05-17 Thread Vincent Bernat
 ❦ 17 mai 2021 17:48 +02, Artur:

> When can we expect prebuilt packages for Debian on haproxy.debian.net
> ?

Hello,

Sometimes this week.
-- 
The secret source of humor is not joy but sorrow; there is no humor in Heaven.
-- Mark Twain



Re: Proposal about libslz integration into haproxy

2021-04-21 Thread Vincent Bernat
 ❦ 21 avril 2021 08:04 +02, Willy Tarreau:

> William suggested that I was needlessly seeking for trouble and that it
> was pointless to keep compatibility for *both* an external version and
> an internal one. While I initially wanted to demonstrate him he was wrong,
> I realized that I was the one wrong because the lib had considerably
> stabilized (no change over one year), and after all we already embed a
> few other things like xxhash and ebtree without offering the possibility
> to build with an external variant, and in the end it probably was the
> right solution.
>
> So after changing my mind, I would go with the following approach:
>
>   - building with USE_SLZ=1  => always use the embedded one
>   - building with USE_ZLIB=1 => always build using the user-provided zlib
>
> We'd enable USE_SLZ by default and it would be disabled when ZLIB is used
> (or when SLZ is forced off). This way we could have fast and memory-less
> compression available by default without the hassle of cloning an unknown
> repository.
>
> Does anyone have any opinion, objection or suggestion on this (especially
> those in CC who participated to the first discussion or who could have
> packaging concerns) ? Barring any comment I think I'm going to do this
> tomorrow so that we have it in -dev17, leaving a bit of time for distro
> packagers to test and adjust their build process if needed.

>From a distribution point of view, we don't like bundled dependencies.
However, as I see it, libslz is an internal lib (like ebtree), so I
don't think this is really a problem. Moreover, we don't have the
external lib in Debian, so there is no duplicate work. Is there any
practical advantage of keeping using zlib (for a user)?
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-2.3.9

2021-03-31 Thread Vincent Bernat
 ❦ 31 mars 2021 12:46 +02, Willy Tarreau:

> On the kernel Greg solved all this by issuing all versions very
> frequently: as long as you produce updates faster than users are
> willing to deploy them, they can choose what to do. It just requires
> a bandwidth that we don't have :-/ Some weeks several of us work full
> time on backports and tests! Right now we've reached a point where
> backports can prevent us from working on mainline, and where this lack
> of time increases the risk of regressions, and the regressions require
> more backport time.

Wouldn't this mean there are too many versions in parallel?

> I think that the real problem arrives when a version becomes generally
> available in distros. And distro users are often the ones with the least
> autonomy when it comes to rolling back. When you build from sources,
> you're more at ease. Thus probably that a nice solution would be to
> add an idle period between a stable release and its appearance in
> distros so that it really gets some initial deployment before becoming
> generally available. And I know that some users complain when they do
> not immediately see their binary package, but that's something we can
> easily explain and document. We could even indicate a level of confidence
> in the announce messages. It has the merit of respecting the principle
> of least surprise for everyone in the chain, including those like you
> and me involved in the release cycle and who did not necessarily plan
> to stop all activities to work on yet-another-release because the
> long-awaited fix-of-the-month broke something and its own fix broke
> something else.

We can do that. In the future, I may even tackle all the problems at
once: providing easy access to old versions and have two versions of
each repository: one with new versions immediately available and one
with a semi-fixed delay.
-- 
April 1

This is the day upon which we are reminded of what we are on the other three
hundred and sixty-four.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"



Re: [ANNOUNCE] haproxy-2.3.9

2021-03-31 Thread Vincent Bernat
 ❦ 31 mars 2021 10:35 +02, Willy Tarreau:

>> Thanks Willy for the quick update. That's a good example to avoid
>> pushing stable versions at the same time, so we have opportunities to
>> find those regressions.
>
> I know and we're trying to separate them but it considerably increases the
> required effort. In addition there is a nasty effect resulting from shifted
> releases, which is that it ultimately results in older releases possibly
> having more recent fixes than recent ones. And it will happen again with
> 2.2.12 which I hope to issue today. It will contain the small fix for the
> silent-drop issue (which is already in 2.3 of course) but was merged after
> 2.3.9. The reporter of the issue is on 2.2, it would not be fair to him to
> release another 2.2 without it (or we'd fall into a bureaucratic process
> that doesn't serve users anymore). So 2.2.12 will contain this fix. But
> if the person finally decides to upgrade to 2.3.9 a week or two later, she
> may face the bug again. It's not a dramatic one so that's acceptable, but
> that shows the difficulties of the process.

It's a bit annoying that fixes reach a LTS version before the non-LTS
one. The upgrade scenario is one annoyance, but if there is a
regression, you also impact far more users. You could tag releases in
git (with -preX if needed) when preparing the releases and then issue
the release with a few days apart. Users of older versions will have
less frequent releases in case regressions are spotted, but I think
that's the general expectation: if you are running older releases it's
because you don't have time to upgrade and it's good enough for you.

For example:
 - 2.3, monthly release or when there is a big regression
 - 2.2, 3 days after 2.3
 - 2.0, 3 days after 2.2, skip one out of two releases
 - 1.8, 3 days after 2.0, skip one out of four releases

So, you have a 2.3.9. At the same time, you tag 2.2.12-pre1 (to be
released in 3 working days if everything is fine) and you skip skip 2.0
and 1.8 this time because they were releases to match 2.3.8. Next time,
you'll have a 2.0.22-pre1 but no 1.8.30-pre1 yet.

If for some reason, there is an important regression in 2.3.9 you want
to address, you release a 2.3.10 and a 2.2.12-pre2, still no 2.0.22-pre1
nor 1.8.30-pre1. Hopefully, no more regressions spotted, you tag 2.2.12
on top of 2.2.12-pre2 and issue a release.
-- 
He hath eaten me out of house and home.
-- William Shakespeare, "Henry IV"



Re: Table sticky counters decrementation problem

2021-03-30 Thread Vincent Bernat
 ❦ 30 mars 2021 11:21 +02, Thomas SIMON:

> And I confirm you than when rolling back with source compilation and
> 2.3.7 version (can't do this with repository as only last version is 
> available) , counters decrements well.

The old debs are still here, so you can still download them manually if
you need to. I need to switch to aptly at some point since reprepro is
unlikely to ever support several versions for the same source package. I
would also have to host and build packages for Ubuntu as well as it is
common request.
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-1.6.16

2021-03-19 Thread Vincent Bernat
 ❦ 19 mars 2021 17:34 +01, Christopher Faulet:

> HAProxy 1.6.16 was released on 2021/03/19. It added 71 new commits
> after version 1.6.15.

1.6 was EOL last year, I don't understand why there is a last release.
Both 1.6 and 1.7 are marked for critical fixes but many fixes are pushed
in it. The risk is to introduce a late regression in this last version.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Packaging hatop for ubuntu20.04

2021-02-03 Thread Vincent Bernat
 ❦  3 février 2021 10:23 GMT, Louis Charreau:

> we use hatop daily to monitor in real time haproxy.
> This tool is no longer packaged in ubuntu 20.04 (LTS), which is a pity for 
> such a useful tool.
>
> It's true that the initial project doesn't seem to be maintained
> anymore (last commit 5 years ago) and only works in Python2 which is
> itself deprecated: feurix/hatop (https://github.com/feurix/hatop).
>
> We referred to the jhunt/hatop project
> (https://github.com/jhunt/hatop), which is compatible with Python2 and
> 3. And we integrated it into our private repositories.
>
> Do you think it would be possible and useful for others to reintegrate
> hatop into the official Debian / Ubuntu repositories?

It's already the case:

https://tracker.debian.org/news/1226222/accepted-hatop-080-1-source-all-into-unstable-unstable/
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)



Re: haproxy conflict between debian backports and haproxy.debian.net

2021-01-14 Thread Vincent Bernat
 ❦ 14 janvier 2021 19:24 +01, Tim Düsterhus:

> I just checked haproxy.debian.net and noticed that the information
> regarding the backports is not up to date:
>
> For Debian Buster the backport should be moved from 2.0 to 2.2.
>
> I'd also like to note that you have a typo in haproxy.js. It says
> 'backport+' instead of 'backports+' (missing 's').

Oh, thanks! Both issues are fixed!
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)



Re: haproxy conflict between debian backports and haproxy.debian.net

2021-01-13 Thread Vincent Bernat
 ❦ 14 janvier 2021 07:39 +01, ghislain:

>   So, should i use basic debian backports or debian.haproxy.net
> because having both seems to collide with a boom ;p !

It's not really a conflict, but yes, you have an unecessary "downgrade"
to the same version as currently backports has 2.2.x. You can switch to
Debian backports but in the future, it may get 2.4.x while
haproxy.debian.net ensures you stay on 2.2.x.

Alternatively, I will be careful next time to upload the same binary to
haproxy.debian.net and to Debian backports.

Also, you seem to have a custom /etc/apt/preferences that may explain
why you are the first to notice that?
-- 
The human race is a race of cowards; and I am not only marching in that
procession but carrying a banner.
-- Mark Twain



Re: Haproxy 2.2.3 source

2020-09-09 Thread Vincent Bernat
 ❦  9 septembre 2020 19:31 +02, Willy Tarreau:

>> Feel free to pick this patch if that helps for your builds, I'm going
>> to backport it to 2.2 once all platforms are happy.
>
> All builds are OK now, the commit was backported to 2.2 and the patch
> can be retrieved here:
>
>   http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab

All good on Debian:
 https://buildd.debian.org/status/package.php?p=haproxy=experimental
-- 
Small things make base men proud.
-- William Shakespeare, "Henry VI"



Re: Haproxy 2.2.3 source

2020-09-09 Thread Vincent Bernat
It is not cross-built. Debian builds armhf from arm64 builders. It seems
Ubuntu is also using arm64 hardware to build armhf.

An alternative that could work is to use QEMU user emulation. You can
directly use "qemu-debootstrap --arch=armhf" to get a working chroot.
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Илья Шипицин 
 Sent:  9 septembre 2020 20:38 +05
 Subject: Re: Haproxy 2.2.3 source
 To: Willy Tarreau
 Cc: Vincent Bernat; Alex Evonosky; haproxy@formilux.org

> how do you build armh ? can you share details ?
> if that's cross build, we can easily add to github actions, for example.
>
> unfortunately, it is hard to get armh native CI.
>
> ср, 9 сент. 2020 г. в 20:01, Willy Tarreau :
>
>> On Tue, Sep 08, 2020 at 11:47:25PM +0200, Vincent Bernat wrote:
>> >  ?  8 septembre 2020 16:13 -04, Alex Evonosky:
>> >
>> > > Just compiling 2.2.3 and getting this reference:
>> > >
>> > >
>> > > /haproxy-2.2.3/src/thread.c:212: undefined reference to
>> > > `_Unwind_Find_FDE'
>> >
>> > I am getting the same issue on armhf only. Other platforms don't get
>> > this issue. On this platform, we only get:
>> >
>> >   w   DF *UND*    GLIBC_2.4   __gnu_Unwind_Find_exidx
>> > 000165d0 gDF .text  000c  GCC_3.0 _Unwind_DeleteException
>> > d1f6 gDF .text  0002  GCC_3.0 _Unwind_GetTextRelBase
>> > 00016e1c gDF .text  0022  GCC_4.3.0   _Unwind_Backtrace
>> > 00016df8 gDF .text  0022  GCC_3.0 _Unwind_ForcedUnwind
>> > 00016dd4 gDF .text  0022  GCC_3.3 _Unwind_Resume_or_Rethrow
>> > d1f0 gDF .text  0006  GCC_3.0 _Unwind_GetDataRelBase
>> > 0001662c gDF .text  0036  GCC_3.5 _Unwind_VRS_Set
>> > 00016db0 gDF .text  0022  GCC_3.0 _Unwind_Resume
>> > 000169d8 gDF .text  02ba  GCC_3.5 _Unwind_VRS_Pop
>> > 00017178 gDF .text  000a  GCC_3.0 _Unwind_GetRegionStart
>> > 000165cc gDF .text  0002  GCC_3.5 _Unwind_Complete
>> > 00017184 gDF .text  0012  GCC_3.0
>>  _Unwind_GetLanguageSpecificData
>> > 000165dc gDF .text  0036  GCC_3.5 _Unwind_VRS_Get
>> > 000164f0 gDF .text  0004  GCC_3.3 _Unwind_GetCFA
>> > 00016d8c gDF .text  0022  GCC_3.0 _Unwind_RaiseException
>> >
>> > So, older symbols are:
>> >
>> > 000165d0 gDF .text  000c  GCC_3.0 _Unwind_DeleteException
>> > d1f6 gDF .text  0002  GCC_3.0 _Unwind_GetTextRelBase
>> > 00016df8 gDF .text  0022  GCC_3.0 _Unwind_ForcedUnwind
>> > d1f0 gDF .text  0006  GCC_3.0 _Unwind_GetDataRelBase
>> > 00016db0 gDF .text  0022  GCC_3.0 _Unwind_Resume
>> > 00017178 gDF .text  000a  GCC_3.0 _Unwind_GetRegionStart
>> > 00017184 gDF .text  0012  GCC_3.0
>>  _Unwind_GetLanguageSpecificData
>> > 00016d8c gDF .text  0022  GCC_3.0 _Unwind_RaiseException
>> >
>> > Moreover, comment says _Unwind_Find_DFE doesn't take arguments, but the
>> > signature I have in glibc is:
>> >
>> > fde *
>> > _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
>>
>> Ah I'm really angry because I tested on many platforms, *including* armhf,
>> but now I'm not seeing it, so either I failed on one test or it depends
>> on the compiler combination :-(
>>
>> The principle was just to force to load libgcc_s that tends to cause
>> aborts on reload for some users in chroots when threads exit, because
>> pthread_exit() tends to be the first one to require libgcc_s and it's
>> quite too late.
>>
>> In the mean time you can probably get away with this:
>>
>> diff --git a/src/thread.c b/src/thread.c
>> index 5eb68e33a..167e26e9d 100644
>> --- a/src/thread.c
>> +++ b/src/thread.c
>> @@ -201,7 +201,7 @@ static void __thread_init(void)
>> exit(1);
>> }
>>
>> -#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) &&
>> !defined(__clang__)
>> +#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) &&
>> !defined(__clang__) && !defined(__arm__)
>> /* make sure libgcc_s is already loaded, because pthread_exit() may
>>  * may need it on exit after the chroot! _Unwind_Find_FDE() is
>> defined
>>  * there since gcc 3.0, has no side effect, doesn't take any
>> argument
>>
>>
>> But I'd really like to find a *reliable* way to force libgcc_s to be loaded
>> if available and required (i.e. not if statically built). I thought about
>> causing a 64/64 bit divide that usually is done via divsi3 and friend but
>> on x86_64 (where the problem was encountered) it will not do it.
>>
>> I'm thinking about something: maybe I can have a look around
>> pthread_getspecific() and pthread_key_create(). I would be very surprised
>> if they didn't rely on some compiler-specific help from libgcc_s.
>>
>> I'll keep testing and will get back to you guys.
>>
>> Willy
>>
>>



Re: Haproxy 2.2.3 source

2020-09-09 Thread Vincent Bernat
 ❦  9 septembre 2020 16:58 +02, Willy Tarreau:

> Ah I'm really angry because I tested on many platforms, *including* armhf,
> but now I'm not seeing it, so either I failed on one test or it depends
> on the compiler combination :-(

I am getting it on Debian Unstable (gcc 10.2.0, glibc 2.31), Ubuntu
Focal (gcc 9.3.0, glibc 2.31) and Ubuntu Bionic (gcc 7.5.0, glibc 2.27).
-- 
Sometimes I wonder if I'm in my right mind.  Then it passes off and I'm
as intelligent as ever.
-- Samuel Beckett, "Endgame"



Re: Haproxy 2.2.3 source

2020-09-08 Thread Vincent Bernat
 ❦  8 septembre 2020 16:13 -04, Alex Evonosky:

> Just compiling 2.2.3 and getting this reference:
>
>
> /haproxy-2.2.3/src/thread.c:212: undefined reference to
> `_Unwind_Find_FDE'

I am getting the same issue on armhf only. Other platforms don't get
this issue. On this platform, we only get:

  w   DF *UND*    GLIBC_2.4   __gnu_Unwind_Find_exidx
000165d0 gDF .text  000c  GCC_3.0 _Unwind_DeleteException
d1f6 gDF .text  0002  GCC_3.0 _Unwind_GetTextRelBase
00016e1c gDF .text  0022  GCC_4.3.0   _Unwind_Backtrace
00016df8 gDF .text  0022  GCC_3.0 _Unwind_ForcedUnwind
00016dd4 gDF .text  0022  GCC_3.3 _Unwind_Resume_or_Rethrow
d1f0 gDF .text  0006  GCC_3.0 _Unwind_GetDataRelBase
0001662c gDF .text  0036  GCC_3.5 _Unwind_VRS_Set
00016db0 gDF .text  0022  GCC_3.0 _Unwind_Resume
000169d8 gDF .text  02ba  GCC_3.5 _Unwind_VRS_Pop
00017178 gDF .text  000a  GCC_3.0 _Unwind_GetRegionStart
000165cc gDF .text  0002  GCC_3.5 _Unwind_Complete
00017184 gDF .text  0012  GCC_3.0 _Unwind_GetLanguageSpecificData
000165dc gDF .text  0036  GCC_3.5 _Unwind_VRS_Get
000164f0 gDF .text  0004  GCC_3.3 _Unwind_GetCFA
00016d8c gDF .text  0022  GCC_3.0 _Unwind_RaiseException

So, older symbols are:

000165d0 gDF .text  000c  GCC_3.0 _Unwind_DeleteException
d1f6 gDF .text  0002  GCC_3.0 _Unwind_GetTextRelBase
00016df8 gDF .text  0022  GCC_3.0 _Unwind_ForcedUnwind
d1f0 gDF .text  0006  GCC_3.0 _Unwind_GetDataRelBase
00016db0 gDF .text  0022  GCC_3.0 _Unwind_Resume
00017178 gDF .text  000a  GCC_3.0 _Unwind_GetRegionStart
00017184 gDF .text  0012  GCC_3.0 _Unwind_GetLanguageSpecificData
00016d8c gDF .text  0022  GCC_3.0 _Unwind_RaiseException

Moreover, comment says _Unwind_Find_DFE doesn't take arguments, but the
signature I have in glibc is:

fde *
_Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)



Re: HAProxy 2.2.2 CE issue report

2020-08-25 Thread Vincent Bernat
 ❦ 24 août 2020 21:59 +03, Milen Simeonov:

> frontend fe_main
> bind 127.0.0.1:443 ssl crt-list /etc/haproxy/certs/websites.crt_list

I am not able to reproduce. The configuration is missing a path to a
certificate. Does it also crash if you don't provide a crt-list?
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy 1.8.26-1~bpo9+1

2020-08-16 Thread Vincent Bernat
 ❦  4 août 2020 14:10 +02, Bram Gillemon:

> Running debian stretch with 1.8.25-1~bpo9+1, this morning the package
> upgraded to 1.8.26-1~bpo9+1 and i started noticing some strange
> behaviour.

I have uploaded 1.8.26-2 with the upstream fix included (for all
supported distros). If you can check it also works for you...

Thanks.
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy 1.8.26-1~bpo9+1

2020-08-07 Thread Vincent Bernat
 ❦  5 août 2020 22:48 +02, Christopher Faulet:

>> i was just setting up the 2.2 version again and i think i did
>> something wrong this morning because i can't reproduce it anymore.
>>
>> Sorry for the extra work i caused.
>>
> No problem. I always prefer a false bug report than a long fix session :)

Does this bug happens often? Will a new version be released "soon"?
Should I update the packages with this patch?
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy 1.8.26-1~bpo9+1

2020-08-04 Thread Vincent Bernat
 ❦  4 août 2020 14:10 +02, Bram Gillemon:

> Running debian stretch with 1.8.25-1~bpo9+1, this morning the package
> upgraded to 1.8.26-1~bpo9+1 and i started noticing some strange
> behaviour.

For reference:

HA-Proxy version 1.8.26-1~bpo9+1 2020/08/03
Copyright 2000-2020 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -O2 -fdebug-prefix-map=/build/haproxy-1.8.26=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-null-dereference -Wno-unused-label
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 
USE_SYSTEMD=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_NS=1

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

Built with OpenSSL version : OpenSSL 1.1.0l  10 Sep 2019
Running on OpenSSL version : OpenSSL 1.1.0l  10 Sep 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
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 PCRE2 version : 10.22 2016-07-29
PCRE2 library supports JIT : yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy 2.2 LTS package for Debian Stretch oldstable

2020-08-03 Thread Vincent Bernat
 ❦  3 août 2020 22:29 +02, Artur:

> It would be nice to have a Debian Stretch package for the current LTS
> 2.2 branch in backports. It seems it's not available for now.

Well, you are the second person asking this in a short time, so I will
provide one. My rationale is that 2.2 is quite new and Stretch is
already maintained as LTS. When maintained as LTS, we loose the ability
to use backports (there is no LTS for official backports), so it may
make the maintenance more difficult. However, it's unlikely the build
system will change much during the lifecycle of the 2.2 and since it
doesn't require backports, we should be fine.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)



Re: OSX builds in Travis

2020-07-11 Thread Vincent Bernat
 ❦ 11 juillet 2020 12:45 +05, Илья Шипицин:

>> > he-he, brew bundle is deprecated (does not work)
>> >
>> >
>> https://apple.stackexchange.com/questions/148454/brew-bundle-reporting-error-unknown-command-bundle
>>
>> It's very old. It has been added back at some point. Here is upstream
>> recommending its use: https://github.com/Homebrew/brew/issues/2491
>
>
> https://travis-ci.com/github/chipitsine/haproxy/jobs/359964175#L133

It seems brew shipped by Travis is quite old. A `brew update` would fix
this but then it adds 10 minutes to the build... So, back to square one.
-- 
Nothing so needs reforming as other people's habits.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"



Re: OSX builds in Travis

2020-07-10 Thread Vincent Bernat
 ❦ 11 juillet 2020 00:48 +05, Илья Шипицин:

> he-he, brew bundle is deprecated (does not work)
>
> https://apple.stackexchange.com/questions/148454/brew-bundle-reporting-error-unknown-command-bundle

It's very old. It has been added back at some point. Here is upstream
recommending its use: https://github.com/Homebrew/brew/issues/2491

However, as long as socat is not part of the packages already installed,
just `brew install socat` should always work.
-- 
It usually takes more than three weeks to prepare a good impromptu speech.
-- Mark Twain



Re: OSX builds in Travis

2020-07-10 Thread Vincent Bernat
 ❦  9 juillet 2020 13:12 +05, Илья Шипицин:

> do you think does it make sense to use scripted brew instead of travis
> plugin ?
>
> if so, we can try to "brew instal blah-blah-blah || ok, we failed, lets'
> update and install one more time"

I have also hit the problem several time. Brew upstream says to use
"brew bundle" instead:

#v+
-brew install libtool libxml2 check
+brew bundle --file=- <<-EOS
+brew "libtool"
+brew "libxml2"
+brew "check"
+EOS
#v-

This way, brew doesn't complain if a requested package is already
installed but not at the latest version.
-- 
It is a wise father that knows his own child.
-- William Shakespeare, "The Merchant of Venice"



Re: Debian packaging note

2020-05-28 Thread Vincent Bernat
 ❦ 28 mai 2020 12:48 +02, Tim Düsterhus:

>> Okay, I've done what I really wanted to avoid and built my own HAProxy.
>> I'm now running HAProxy 2.1.5-1~~~timwolla+1 and I hope that it will
>> smoothly upgrade to Vincent's build once it is released.
>> 
>
> While researching how to build a 2.1.5 .deb based off your 2.1.4 sources
> I noticed that Debian QA complained that HAProxy's compiler flags were
> hidden [1]. You should be able to fix that by adjusting MAKEARGS in
> debian/rules to include 'V=1':

Thanks. I have added that for the next build on both 2.0 and 2.1.
-- 
Patch griefs with proverbs.
-- William Shakespeare, "Much Ado About Nothing"



Re: [PATCH] enable arm64 builds in travis-ci

2020-05-09 Thread Vincent Bernat
 ❦  8 mai 2020 14:25 +02, Willy Tarreau:

>> > Let's increase the timeout to see if it has a chance to finish, no ?
>> >
>> 
>> yes
>
> OK now pushed. It's really annoying to work blindly like this. The
> build model Travis uses is broken by design. Requiring to commit
> something for testing is utterly wrong. And doing so within the
> project that's supposed to being test is further wrong. We already
> have 44 patches only on .travis.yml! If this continues like this,
> I predict that a "pre-CI" solution will appear to test if your
> change is likely to trigger a travis error before it gets merged...

You can push changes to a (throwable) branch instead.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Segfault on 2.1.3

2020-03-16 Thread Vincent Bernat
 ❦ 16 mars 2020 16:02 -06, Sean Reifschneider:

> I reverted back to haproxy 2.0.13 from the PPA last Wednesday and have
> verified that we get no segfaults on that.  If there's anything else I can
> provide for you, let me know.  Otherwise I'm just gonna close this ticket
> in our bugtracker.  :-)

Sorry, can't help you more. Maybe wait for the next release. It will get
-dbgsym and it should provide more info on why you get the problem.
-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain



Re: Segfault on 2.1.3

2020-03-04 Thread Vincent Bernat
 ❦  4 mars 2020 13:19 -07, Sean Reifschneider :

> I've upgraded back to 2.1, and installed the systemd-coredump, I'll update
> when I have additional information.  I wasn't able to find a -dbgsym
> package, I even looked in the debian pool directory for the PPA.  We're
> talking like a haproxy-dbgsym package, right?  Or am I missing
> something?

Sorry, I forgot to enable this option for 2.1 PPA. You should still be
able to get tracebacks without the dbgsym package (with "coredumpctl
info XXX").
-- 
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Segfault on 2.1.3

2020-03-03 Thread Vincent Bernat
 ❦  3 mars 2020 15:34 -07, Sean Reifschneider :

> We've been running haproxy 1.8 series for quite a while.  We're currently
> in the process of updating to 2.1, and have installed from the vbernat PPA
> on Ubuntu 18.04 using the same old config file.
>
> Now we are seeing segfaults a few times a day:

You can easily collect core information if you install systemd-coredump.
Then, use "coredumpctl list" to locate the collected core, then
"coredumpctl info XXX" to get some stack traces. If you install the
-dbgsym package, you can also use "coredumpctl debug XXX" then use "bt
full" and send the output.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH] MINOR: lua: Add lua-prepend-path configuration option

2020-01-11 Thread Vincent Bernat
 ❦  9 janvier 2020 20:07 +01, Tim Düsterhus :

> If you would package the haproxy-lua-http library for Debian
> (https://github.com/haproxytech/haproxy-lua-http) [1], what would you
> believe would be most "useful" / "in spirit of Debian packaging" / "your
> choice"?
>
> a) Install the library into the regular Lua library path, even if it
> would not be useful / broken outside of HAProxy. Using require within
> HAProxy simply works without doing anything.
> b) Install the library into a HAProxy specific Lua library path (e.g.
> /usr/share/haproxy/lua-path/) and add proper lua-prepend-path to
> HAProxy's default configuration. The user would need to copy that into
> their own configuration, otherwise things break.
> c) Install the library into a HAProxy specific Lua library path and add
> that path to HAProxy at compile time via a dedicated compile option. For
> the user it would work out of the box, similar to option (a), but it
> would not clutter the global Lua library path.
> d) Something entirely different.
>
> Best regards
> Tim Düsterhus
>
> [1] I'd like to see it packaged if something useful comes out of this
> discussion :-)

Sorry for the late answer! b) doesn't seem a good solution as it
prevents sharing configuration files between distributions. I think the
default prepend path should be a compile-time option (eg
`/usr/share/haproxy/lua`) but can be overriden with a specific
directive. Therefore, this is transparent for most users, but if a user
prefer to put additional stuff in another directory, it's still easily
possible.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)



Re: haproxy 2.1 package for Debian 9 Stretch oldstable

2019-12-17 Thread Vincent Bernat
 ❦ 17 décembre 2019 11:49 +01, Tim Düsterhus :

>> I didn't plan to do uploads for Stretch for this version of HAProxy.
>> This is a non-LTS version of HAProxy, so I am only targeting recent
>> distributions. If you find another people interested in this version as
>> well, I'll add it.
>
> I am interested. Due to [#931574] I am currently unable / unwilling to
> upgrade my Stretch servers to Buster. To the best of my knowledge that
> Panic still is not fixed.
>
> However I'd like to run HAProxy 2.1 on these servers.

I have pushed HAProxy 2.1.1 for Stretch. Tell me if everything is OK for
you.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)



Re: haproxy 2.1 package for Debian 9 Stretch oldstable

2019-12-17 Thread Vincent Bernat
 ❦ 16 décembre 2019 22:15 +01, Artur :

> While checking for haproxy 2.1 package for Debian Stretch on
> https://haproxy.debian.net/, I saw it wasn't available (yet ?).
>
> Do you plan to build haproxy deb packages for this version of Debian,
> it's still supported as oldstable for now ?

Hello,

I didn't plan to do uploads for Stretch for this version of HAProxy.
This is a non-LTS version of HAProxy, so I am only targeting recent
distributions. If you find another people interested in this version as
well, I'll add it.
-- 
It is a wise father that knows his own child.
-- William Shakespeare, "The Merchant of Venice"



Re: Status of 1.5 ?

2019-11-26 Thread Vincent Bernat
 ❦ 25 octobre 2019 11:27 +02, Willy Tarreau :

> Now I'm wondering, is anyone interested in this branch to still be
> maintained ? Should I emit a new release with a few pending fixes
> just to flush the pipe and pursue its "critical fixes only" status a
> bit further, or should we simply declare it unmaintained ? I'm fine
> with either option, it's just that I hate working for no reason, and
> this version was released a bit more than 5 years ago now, so I can
> easily expect that it has few to no user by now.
>
> Please just let me know what you think,

What's the conclusion? :)
-- 
Anyone who has had a bull by the tail knows five or six more things
than someone who hasn't.
-- Mark Twain



Re: haproxy 2.0 - stretch - libgcc_s.so.1

2019-06-27 Thread Vincent Bernat
 ❦ 27 juin 2019 09:06 +02, Mildis :

 You can workaround this by not chrooting HAProxy. The problem is that
 once chrooted, it cannot load the library. We should force libpthread to
 preload this lib.
>>> 
>>> This mailing list thread might be relevant / helpful here:
>>> https://www.mail-archive.com/haproxy@formilux.org/msg33189.html
>>> (Message-ID: 8e3aa43f-d6ad-4128-bb10-feeb5f315...@gandi.net).
>> 
>> Thanks. Adding ADDLIB="-Wl,--no-as-needed -lgcc_s -Wl,--as-needed" fixes
>> the issue.
>
> Does 2.0.1 include the fix ?

Yes.
-- 
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)



Re: haproxy 2.0 - stretch - libgcc_s.so.1

2019-06-24 Thread Vincent Bernat
 ❦ 24 juin 2019 19:08 +02, Tim Düsterhus :

>> You can workaround this by not chrooting HAProxy. The problem is that
>> once chrooted, it cannot load the library. We should force libpthread to
>> preload this lib.
>
> This mailing list thread might be relevant / helpful here:
> https://www.mail-archive.com/haproxy@formilux.org/msg33189.html
> (Message-ID: 8e3aa43f-d6ad-4128-bb10-feeb5f315...@gandi.net).

Thanks. Adding ADDLIB="-Wl,--no-as-needed -lgcc_s -Wl,--as-needed" fixes
the issue.

1.9 was already calling pthread_exit() but it doesn't seem to happen
with 1.9.8. Do you know what could have changed?
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"



Re: haproxy 2.0 - stretch - libgcc_s.so.1

2019-06-24 Thread Vincent Bernat
 ❦ 24 juin 2019 18:43 +02, Mildis :

> I'm hitting
> https://www.mail-archive.com/haproxy@formilux.org/msg33189.html 
> with haproxy 2.0 on Stretch, when doing a hot-reload
>
> Jun 24 18:34:05 haproxy[32347]: libgcc_s.so.1 must be installed for 
> pthread_cancel to work
> Jun 24 18:34:05 haproxy[32347]: [WARNING] 174/183405 (32347) : Former worker 
> #1 (32363) exited with code 134 (Aborted)
>
> Is it something to be fixed by Vincent during the build for the
> packaging ?

You can workaround this by not chrooting HAProxy. The problem is that
once chrooted, it cannot load the library. We should force libpthread to
preload this lib.
-- 
The better part of valor is discretion.
-- William Shakespeare, "Henry IV"



Re: [PATCH] BUILD: Silence gcc warning about unused return value

2019-06-12 Thread Vincent Bernat
 ❦ 12 juin 2019 20:47 +02, Tim Duesterhus :

> - write(2, trash.area, trash.data);
> + shut_your_big_mouth_gcc(write(2, trash.area, trash.data));

An alternative not discussed in 89efaed6b67b (which introduced this
function) is to use "(void)!":

 (void)!write(2, trash.area, trash.data);

For an entertaining discussion, see:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425

Of course, like the "if (foo()) /* do nothing */;", this can be broken
in the future.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH v2 1/2] MINOR: systemd: Use the variables from /etc/default/haproxy

2019-05-12 Thread Vincent Bernat
 ❦  8 mai 2019 13:44 +00, Veiko Kukk :

>> It was slightly modified to cleanly apply, because HAProxy's default
>> unit file does not include rsyslog.service as an 'After' dependency.
>> Also the subject line was modified to include the proper subsystem
>> and severity.
>
> I think, instead of After=rsyslog.service, it should be
> After=syslog.service, then any logger daemon could be used that has
> Alias=syslog.service.

After looking a bit more, in Debian, we are using rsyslog.service
explicitely to ensure the presence of a syslog socket inside HAProxy
chroot. As the configuration for this socket is done for rsyslog only,
we depend on rsyslog running for this aspect.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH v2 1/2] MINOR: systemd: Use the variables from /etc/default/haproxy

2019-05-08 Thread Vincent Bernat
 ❦  8 mai 2019 16:23 +02, Tim Düsterhus :

>> I think, instead of After=rsyslog.service, it should be
>> After=syslog.service, then any logger daemon could be used that has
>> Alias=syslog.service.
>> 
>> https://www.freedesktop.org/wiki/Software/systemd/syslog/
>> 
>
> The HAProxy provided unit file does not include a dependency at all.
> That's a Debian specific patch to include the dependency.

I think we didn't know about the alias stuff. We'll fix that on our side
on next upload.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH v2 1/2] MINOR: systemd: Use the variables from /etc/default/haproxy

2019-05-06 Thread Vincent Bernat
 ❦  6 mai 2019 13:46 +02, William Lallemand :

>> /etc/default is a debianism. Other distros use different directories, 
>> such as RedHat which uses /etc/sysconfig
>> 
>> -Patrick
>
> Hi Patrick,
>
> I don't think that's a problem, most distribution use their own unit file
> anyway, people should edit this file before using it.

One of the promise of systemd was to be able to share unit files accross
distribution. For this, systemd wants to discourage the use of
/etc/default and /etc/sysconfig (there was even a discussion about
deprecating EnvironmentFile). You can still use the EXTRAOPTS approach
by using:

ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG $EXTRAOPTS

And let people override EXTRAOPTS with an override:

Environment=EXTRAOPTS=somethingmore

However, many people prefer /etc/default and /etc/sysconfig to systemd
overrides. And for distribution, it enables a smoother transition. For
Debian, we would still add the EnvironmentFile directive. You could
still be compatible with both styles of distribution with:

EnvironmentFile=-/etc/default/haproxy
EnvironmentFile=-/etc/sysconfig/haproxy
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature


Re: [ANNOUNCE] haproxy-1.8.20

2019-05-05 Thread Vincent Bernat
 ❦  5 mai 2019 09:51 +02, Vincent Bernat :

>> So I'd suggest to insist on having the up to date version (even 1.8.21 if
>> we have a reason to have this one released by then). In the worst case,
>> if this is rejected for whatever reason, it's better to leave a well known
>> version there and continue to encourage every user to switch to your up to
>> date PPA than making them believe their version contains the essential
>> fixes, which would be misleading.
>
> OK, I have just asked our release team if they would accept 1.8.20 as
> is. Let's see!

They don't want to make an exception. So, Debian 10 will be with HAProxy
1.8.19.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-1.8.20

2019-05-05 Thread Vincent Bernat
 ❦  5 mai 2019 09:14 +02, Willy Tarreau :

> So I'd suggest to insist on having the up to date version (even 1.8.21 if
> we have a reason to have this one released by then). In the worst case,
> if this is rejected for whatever reason, it's better to leave a well known
> version there and continue to encourage every user to switch to your up to
> date PPA than making them believe their version contains the essential
> fixes, which would be misleading.

OK, I have just asked our release team if they would accept 1.8.20 as
is. Let's see!
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [ANNOUNCE] haproxy-1.8.20

2019-05-04 Thread Vincent Bernat
 ❦ 29 avril 2019 11:04 +02, Christopher Faulet :

> HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits
> after version 1.8.19.

Hey!

Debian Buster will soon be released (nobody knows exactly when, but we
are in full freeze since 2 months). It currently contains HAProxy
1.8.19. I don't think it would be possible to push 1.8.20 as is.

We can either keep 1.8.19 as is or select a few critical patches to
apply on it. For example, we could take the MAJOR patches:

BUG/MAJOR: checks: segfault during tcpcheck_main
BUG/MAJOR: http_fetch: Get the channel depending on the keyword used
BUG/MAJOR: listener: Make sure the listener exist before using it.
BUG/MAJOR: spoe: Fix initialization of thread-dependent fields
BUG/MAJOR: stats: Fix how huge POST data are read from the channel

And maybe:

BUG/MEDIUM: listener: make sure the listener never accepts too many conns

The more changes, the less likely the release team will accept the
change. Assuming we can only make one proposition (which is not true),
what would you (as upstream) try? 1.8.19, one bug, all major bugs, even
more bugs, or 1.8.20?
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)



Re: haproxy segfault

2019-02-12 Thread Vincent Bernat
 ❦ 12 février 2019 21:44 +01, Mildis :

> I'm struggling with Stretch/systemd to generate the coredump on crash.
> Even running haproxy by hand with ulimit -c unlimited does not
> generate a coredump.

Also install haproxy-dbgsym. You need to comment the chroot directive in
your HAProxy configuration if it's enabled. Also, you need to set the
core pattern to a fixed directory where haproxy user can write to, like:

sysctl -w kernel.core_pattern=/tmp/core.%p

Then, on next segfault, you should get your coredump.
-- 
Let me take you a button-hole lower.
-- William Shakespeare, "Love's Labour's Lost"



Re: DNS resolution issue with Docker swarm and HAProxy 1.8.15/1.9.0

2018-12-20 Thread Vincent Bernat
 ❦ 20 décembre 2018 17:14 +01, Willy Tarreau :

>> this is indeed a regression in haproxy.  thanks for reporting it.
>> attached patch should fix it.
>> CC'ing Remi as the original author, and Baptiste, as DNS maintainer.
>
> Good catch, the patch looks obviously good, I've just merged it.
> Thanks for fixing this one, Jérôme.

Is it important enough for an 1.8.16? Is it important enough for
distributors to release a fixed version? Why doesn't it affect most DNS
implementations?
-- 
There is no distinctly native American criminal class except Congress.
-- Mark Twain



Re: [ANNOUNCE] haproxy-1.8.13

2018-07-30 Thread Vincent Bernat
 ❦ 30 juillet 2018 20:55 +0200, Willy Tarreau  :

> What I don't like with PGP on an exposed machine is that it reduces the
> size of your 4096-bit key to the size of your passphrase (which most
> often contains much less than the ~700 characters it would need to be
> as large), and also increases your ability to get fooled into entering
> it. Some would call me paranoid, but I don't think I am, I'm just trying
> to keep a balanced level of security, knowing that the global one is not
> better than the weakest point.

Attacks on asymmetric ciphers do not rely on bruteforce: you don't have
to explore the whole keyspace to guess the private key. You can use
algorithms like the general number field sieve. A 4096-bit RSA keypair
would be roughly equivalent to a symmetric algorithm using a 160-bit key
(unless we find better algorithms to break RSA). A 32-character
passphrase would be enough to protect the private key. Moreover, if you
use a weaker passphrase, you have not lost yet as the string to key
function used to turn the passphrase into an AES key is slow. I don't
know where the limit is, but the idea is that with a shorter passphrase,
the attacker may still have a better time finding the AES key instead of
the passphrase.

But if someone can steal your encrypted key from your machine, they may
also be able to steal the unencrypted one through various means. So, you
may still be right about being paranoid. :)
-- 
The man who sets out to carry a cat by its tail learns something that
will always be useful and which never will grow dim or doubtful.
-- Mark Twain



Re: [PATCH] MINOR: mworker: exit with 0 on successful exit

2018-07-12 Thread Vincent Bernat
 ❦ 12 juillet 2018 16:25 +0200, William Lallemand  :

> Maybe we could take your first patch for the unit file and backport it in 1.8,
> and then make the appropriate changes for 1.9 once the master was
> redesigned.

Yes, no problem. The first patch should apply without any change on 1.8.
I am using it in Debian packages and so far, nobody complained.
-- 
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"



Re: [PATCH] MINOR: mworker: exit with 0 on successful exit

2018-07-12 Thread Vincent Bernat
 ❦ 22 juin 2018 22:03 +0200, Vincent Bernat  :

> Without this patch, when killing the master process, the SIGTERM
> signal is forwarded to all children. Last children will likely exit
> with "killed by signal SIGTERM" status which would be converted by an
> exit with status 143 of the master process.
>
> With this patch, the master process takes note it is requesting its
> children to stop and will convert "killed by signal SIGTERM" to an
> exit status of 0. Therefore, the master process will exit with status
> 0 if everything happens as expected.

I think this patch may have slipped through the cracks!
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain



Re: [PATCH] MINOR: mworker: exit with 0 on successful exit

2018-06-22 Thread Vincent Bernat
 ❦ 22 juin 2018 22:03 +0200, Vincent Bernat  :

>   if (current_child(exitpid)) {
>   ha_alert("Current worker %d exited with code 
> %d\n", exitpid, status);

This is a lie, but I don't think it matters much. We could (mentally)
translate "with code 0" by "with success".
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)



[PATCH] MINOR: mworker: exit with 0 on successful exit

2018-06-22 Thread Vincent Bernat
Without this patch, when killing the master process, the SIGTERM
signal is forwarded to all children. Last children will likely exit
with "killed by signal SIGTERM" status which would be converted by an
exit with status 143 of the master process.

With this patch, the master process takes note it is requesting its
children to stop and will convert "killed by signal SIGTERM" to an
exit status of 0. Therefore, the master process will exit with status
0 if everything happens as expected.

Killing a worker process with SIGTERM will still trigger an exit of
the master process with a status of 143.
---
 src/haproxy.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 11d1d47ceb41..2f11ad124873 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -723,6 +723,7 @@ static void mworker_wait()
 {
int exitpid = -1;
int status = 0;
+   int exiting = 0;
 
 restart_wait:
 
@@ -749,6 +750,7 @@ restart_wait:
}
 #endif
ha_warning("Exiting Master process...\n");
+   exiting = 1;
mworker_kill(sig);
mworker_unregister_signals();
}
@@ -763,8 +765,13 @@ restart_wait:
 
if (WIFEXITED(status))
status = WEXITSTATUS(status);
-   else if (WIFSIGNALED(status))
-   status = 128 + WTERMSIG(status);
+   else if (WIFSIGNALED(status)) {
+   if (exiting && (WTERMSIG(status) == SIGINT ||
+   WTERMSIG(status) == SIGTERM))
+   status = 0;
+   else
+   status = 128 + WTERMSIG(status);
+   }
else if (WIFSTOPPED(status))
status = 128 + WSTOPSIG(status);
else
@@ -776,7 +783,7 @@ restart_wait:
/* check if exited child was in the current children 
list */
if (current_child(exitpid)) {
ha_alert("Current worker %d exited with code 
%d\n", exitpid, status);
-   if (status != 0 && status != 130 && status != 
143
+   if (status != 0
&& !(global.tune.options & 
GTUNE_NOEXIT_ONFAILURE)) {
ha_alert("exit-on-failure: killing 
every workers with SIGTERM\n");
mworker_kill(SIGTERM);
-- 
2.18.0




[PATCH] MINOR: systemd: consider exit status 143 as successful

2018-06-22 Thread Vincent Bernat
The master process will exit with the status of the last worker. When
the worker is killed with SIGTERM, it is expected to get 143 as an
exit status. Therefore, we consider this exit status as normal from a
systemd point of view. If it happens when not stopping, the systemd
unit is configured to always restart, so it has no adverse effect.

This has mostly a cosmetic effect. Without the patch, stopping HAProxy
leads to the following status:

● haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2018-06-22 20:35:42 CEST; 
8min ago
 Docs: man:haproxy(1)
   file:/usr/share/doc/haproxy/configuration.txt.gz
  Process: 32715 ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE 
$EXTRAOPTS (code=exited, status=143)
  Process: 32714 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS 
(code=exited, status=0/SUCCESS)
 Main PID: 32715 (code=exited, status=143)

After the patch:

● haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/lib/systemd/system/haproxy.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: man:haproxy(1)
   file:/usr/share/doc/haproxy/configuration.txt.gz
---
 contrib/systemd/haproxy.service.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/systemd/haproxy.service.in 
b/contrib/systemd/haproxy.service.in
index 7a8b6bead2df..74e66e302065 100644
--- a/contrib/systemd/haproxy.service.in
+++ b/contrib/systemd/haproxy.service.in
@@ -10,6 +10,7 @@ ExecReload=@SBINDIR@/haproxy -f $CONFIG -c -q
 ExecReload=/bin/kill -USR2 $MAINPID
 KillMode=mixed
 Restart=always
+SuccessExitStatus=143
 Type=notify
 
 # The following lines leverage SystemD's sandboxing options to provide
-- 
2.18.0




Re: Haproxy 1.7.10 constantly restarting

2018-03-11 Thread Vincent Bernat
 ❦ 11 mars 2018 07:19 -0400, Aleksey Gordeev  :

> I'm sorry is that question is not suitable. Please give correct channel to 
> contact. 
>
> It's started about a month ago. I have separate instances of same
> version haproxy. One of them restarts every 2 or 3 days.
>
> I have only this in log 
>
> Mar 11 06:43:21  systemd[1]: Stopping HAProxy Load Balancer... 
> Mar 11 06:43:21  haproxy-systemd-wrapper[10939]: haproxy-systemd-wrapper: 
> SIGTERM -> 10942. 
> Mar 11 06:43:21  haproxy-systemd-wrapper[10939]: haproxy-systemd-wrapper: 
> exit, haproxy RC=0 
> Mar 11 06:43:21  systemd[1]: Starting HAProxy Load Balancer... 
> Mar 11 06:43:21  systemd[1]: Started HAProxy Load Balancer. 
> Mar 11 06:43:21  haproxy-systemd-wrapper[19642]: haproxy-systemd-wrapper: 
> executing /usr/sbin/haproxy 

This seems to happen because something is just restarting haproxy. Maybe
logrotate? "rgrep haproxy /etc" may give a clue.
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Syslog with systemd

2018-03-02 Thread Vincent Bernat
 ❦  2 mars 2018 19:24 +1100, Igor Cicimov  :

>> I suppose the permissions of /var/log are incorrect. It should be owned
>> by syslog?
>
> ​The permissions look ok:
> ​
> ​# ls -ld /var/log/
> drwxrwxr-x 16 root syslog 4096 Mar  2 00:00 /var/log/
> # id -a syslog
> uid=104(syslog) gid=108(syslog) groups=108(syslog),4(adm)​

I don't use rsyslog myself, so I can't help you more.
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Syslog with systemd

2018-03-01 Thread Vincent Bernat
 ❦  2 mars 2018 09:49 +1100, Igor Cicimov  :

> $ ls -l /var/log/haproxy.log
> -rw-r- 1 syslog adm 48939 Mar  1 20:17 /var/log/haproxy.log
>
> ​and I'm sure this file was automatically created ​(by rsyslog I guess?).
> I'm sure this has always been the case hence the reason I was confused when
> I had to create it manually (obviously with wrong permissiosn :-/ ).
>
> So the question is now why this file did not get created in the first place
> although I restarted rsyslog and haproxy several times?

I suppose the permissions of /var/log are incorrect. It should be owned
by syslog?
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Syslog with systemd

2018-02-28 Thread Vincent Bernat
 ❦ 28 février 2018 22:14 +1100, Igor Cicimov  :

> ​Same, no logging:​
[...]

Could you strace rsyslogd and check if it is receiving the messages?
-- 
This is the first age that's paid much attention to the future, which is a
little ironic since we may not have one.
-- Arthur Clarke



Re: Syslog with systemd

2018-02-28 Thread Vincent Bernat
 ❦ 28 février 2018 21:00 +1100, Igor Cicimov  :

> ​# ls -l /var/lib/haproxy/dev/log
> srw-rw-rw- 1 root root 0 Feb 28 16:06 /var/lib/haproxy/dev/log
>
> # lsof -n -p $(pidof haproxy) | grep dev/log
> #

In fact, this seems expected because HAProxy is only using
non-connection oriented sockets.

If you run HAProxy outside of systemd, does it work as expected? If yes,
what's the output of (when running through systemd):

cat /proc/$(pidof haproxy)/mounts
-- 
Why is it that we rejoice at a birth and grieve at a funeral?  It is because we
are not the person involved.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"



Re: Syslog with systemd

2018-02-27 Thread Vincent Bernat
 ❦ 28 février 2018 17:51 +1100, Igor Cicimov  :

>> > ​Actually spoke too soon, still have an issue. One of the servers started
>> > logging there but then stopped and on the other the file is still empty.​
>>
>> Is the issue fixed just by restarting HAProxy or does it persist after
>> that?
>
> ​No restart didn't help still same.​

Those commands should help understand the situation better (you may have
to adapt them if pidof returns several PID).

ls -l /var/lib/haproxy/dev/log
lsof -n -p $(pidof haproxy) | grep dev/log
lsof -n -p $(pidof rsyslogd) | grep haproxy/dev/log
-- 
The surest protection against temptation is cowardice.
-- Mark Twain



Re: Syslog with systemd

2018-02-27 Thread Vincent Bernat
 ❦ 28 février 2018 15:50 +1100, Igor Cicimov  :

> ​Actually spoke too soon, still have an issue. One of the servers started
> logging there but then stopped and on the other the file is still empty.​

Is the issue fixed just by restarting HAProxy or does it persist after that?
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)



Re: [PATCH 0/2] Add SystemD's sandboxing options

2018-02-27 Thread Vincent Bernat
 ❦ 27 février 2018 16:00 +0100, Willy Tarreau  :

>> I'm running this exact settings on my Debian Stretch machine using haproxy
>> 1.8.x, without issues so far.
>> 
>> The first patch could cause issues for users that store their configuration
>> in /home or /root, but I consider this unlikely.
>> 
>> Tim Duesterhus (2):
>>   MINOR: systemd: Add SystemD's Protect*= options to the unit file
>>   MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file
>
> I took a look, but my systemd incompetence limited my ability to understand
> what this really does. How does systemd act to do this exactly ? I'm very
> worried that the only way it could proceed would be by running the process
> under ptrace causing a tremendous slowdown, and additionally making the
> process unobservable/undebuggable. Do you know how it proceeds
> internally ?

It uses seccomp.
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)



Re: HTTP/2 Termination vs. Firefox Quantum

2017-12-21 Thread Vincent Bernat
 ❦ 21 décembre 2017 09:00 GMT, Maximilian Böhm  :

> We are using HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04 on Debian 8. On the 
> backend, jetty 9.3.11.v20160721 with http/1.1 answers requests.
>
> Since I've enabled http/2 ("alpn h2,http/1.1"), we are facing issues with 
> Firefox Quantum both, on windows 10 and macOS. I do not have any complaints 
> regarding other browsers (yet?). Requested HTML pages are delivered empty or 
> even cut in the middle. There is no recurring pattern, it's like a lottery, 
> still, very seldom.. The yet simple but not satisfiable solution is to 
> restart the browser.
>
> I know the provided information is quite spare, so my question is
> actually, if there Is there any guideline I can follow to provide you
> more information? I've appended some snippets of the proxy
> configuration.

Also provide "haproxy -vv". I believe in your case, this is:

HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04
Copyright 2000-2017 Willy Tarreau 

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

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

Built with OpenSSL version : OpenSSL 1.0.2l  25 May 2017
Running on OpenSSL version : OpenSSL 1.0.2l  25 May 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
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.35 2014-04-04
Running on PCRE version : 8.35 2014-04-04
PCRE library supports JIT : yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)



[PATCH] MINOR: systemd: remove comment about HAPROXY_STATS_SOCKET

2017-12-08 Thread Vincent Bernat
From: Vincent Bernat <vinc...@bernat.im>

This variable was used by the wrapper which was removed in
a6cfa9098e5a. The correct way to do seamless reload is now to enable
"expose-fd listeners" on the stat socket.
---
 contrib/systemd/haproxy.service.in | 2 --
 1 file changed, 2 deletions(-)

diff --git a/contrib/systemd/haproxy.service.in 
b/contrib/systemd/haproxy.service.in
index edbd4c292dd5..804be3583c1a 100644
--- a/contrib/systemd/haproxy.service.in
+++ b/contrib/systemd/haproxy.service.in
@@ -3,8 +3,6 @@ Description=HAProxy Load Balancer
 After=network.target
 
 [Service]
-# You can point the environment variable HAPROXY_STATS_SOCKET to a stats
-# socket if you want seamless reloads.
 Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
 ExecStartPre=@SBINDIR@/haproxy -f $CONFIG -c -q
 ExecStart=@SBINDIR@/haproxy -Ws -f $CONFIG -p $PIDFILE
-- 
2.15.1




Re: HTTP/2 stream 1 was not closed cleanly

2017-12-04 Thread Vincent Bernat
 ❦  4 décembre 2017 12:34 GMT, Gregory Storme  :

> haproxy -vv
> HA-Proxy version 1.8.0-2~bpo8+1 2017/12/02

If you want to try with 1.8.1, it has just been uploaded.
-- 
Lord, what fools these mortals be!
-- William Shakespeare, "A Midsummer-Night's Dream"



Re: Client cert verification on some paths

2017-12-02 Thread Vincent Bernat
 ❦  2 décembre 2017 10:47 GMT, "Aleksandar Lazic"  :

> You can use the following line to full fill your request, untested.
>
>   bind :443 ssl ca-file "${PATH_TO_CAFILE}" crl-file
> "${PATH_TO_CRLFILE}" verify "${VERIFY_MODE}"

If verify mode is set to optional, on browsers, this will still trigger
the dialog box to get a certificate from the user. AFAIK, there is no
way to achieve what Apache is doing using HAProxy: there is no code to
change SSL parameters after initial bind.
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain



Re: patch: allow to use any compiler

2017-10-08 Thread Vincent Bernat
 ❦  9 octobre 2017 08:49 +0500, Илья Шипицин  :

>> > any particular reason for mixing "CC=gcc" with "CC?=gcc" ?
>>
>> I don't see any use of ?=, except for stuff that are expected to be in
>> environment variables (like HOME, DISPLAY, LANG, PATH).
>>
>
> # find . -name Makefile -exec grep -E '^CC' {} ';' -print
> CC = gcc
> ./Makefile
> CC   = gcc
> ./contrib/debug/Makefile
> CC   = gcc
> ./contrib/halog/Makefile
> CC   = gcc
> ./contrib/ip6range/Makefile
> CC   = gcc
> ./contrib/iprange/Makefile
> CC ?= gcc
> ./contrib/mod_defender/Makefile
> CC ?= gcc
> ./contrib/modsecurity/Makefile
> CC = gcc
> ./contrib/spoa_example/Makefile
> CC   = gcc
> ./contrib/tcploop/Makefile

Oh, I didn't understand. I think ?= should just be =.
-- 
Your manuscript is both good and original, but the part that is good is not
original and the part that is original is not good.
-- Samuel Johnson



Re: patch: allow to use any compiler

2017-10-08 Thread Vincent Bernat
 ❦  8 octobre 2017 15:46 +0500, Илья Шипицин  :

>> > while some Makefiles allow to use CC, other just stick to gcc.
>> > I think we should change to
>> >
>> > CC ?= gcc
>>
>> This doesn't change much. You can already override gcc with "make
>> TARGET=... CC=clang". The only thing "?=" is that you can do "env
>> CC=clang make TARGET=...".
>>
>> Doesn't this work for you?
>>
>
> any particular reason for mixing "CC=gcc" with "CC?=gcc" ?

I don't see any use of ?=, except for stuff that are expected to be in
environment variables (like HOME, DISPLAY, LANG, PATH).
-- 
Consider well the proportions of things.  It is better to be a young June-bug
than an old bird of paradise.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"



Re: patch: allow to use any compiler

2017-10-04 Thread Vincent Bernat
 ❦  4 octobre 2017 23:49 +0500, Илья Шипицин  :

> while some Makefiles allow to use CC, other just stick to gcc.
> I think we should change to
>
> CC ?= gcc

This doesn't change much. You can already override gcc with "make
TARGET=... CC=clang". The only thing "?=" is that you can do "env
CC=clang make TARGET=...".

Doesn't this work for you?
-- 
O, what a tangled web we weave, When first we practice to deceive.
-- Sir Walter Scott, "Marmion"



Re: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
 ❦  3 octobre 2017 17:54 +0200, Marcus Ulbrich  :

> yes... it crashed after 5mins also without this acl.

I was suspecting this ACL as this is the only one with a
case-insensitive match. But maybe the same codepath is used when
matching header names.

> I should test commenting all acl for testing. Is there no way to see
> what acl was active, when haproxy crashes?

While in gdb, you are likely to be able to do, but I can't say exactly
how. Just with the information you provided, I think other people are
more likely to pinpoint the ACL triggering the code path you get and the
cause.

Of course, you can also comment all ACL one by one until crash
disappear. This would also help.
-- 
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
 ❦  3 octobre 2017 16:34 +0200, Marcus Ulbrich  :

>     acl badbots hdr_reg(User-Agent) -i -f /etc/haproxy/badbots.lst
>     http-request deny if badbots !whitelistips_agents

Try removing this one and check if it still crashes (hoping there is
only one crash).
-- 
By trying we can easily learn to endure adversity.  Another man's, I mean.
-- Mark Twain



Re: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
 ❦  3 octobre 2017 11:29 +0200, Marcus Ulbrich  :

> and here is the coredump with libssl and haproxy... I can not get
> clear about this:

Not the same one as previously. But this one is entirely in HAProxy. For
this one, I think an excerpt of your configuration would help. It seems
that one HTTP ACL is not working as expected.
-- 
Kindness is a language which the deaf can hear and the blind can read.
-- Mark Twain



Re: Aw: Re: Haproxy segfault error 4 in libc-2.24

2017-10-03 Thread Vincent Bernat
 ❦  3 octobre 2017 11:15 +0200, lu...@gmx.net :

>> Could you get another one with libssl1.1-dbgsym installed?
>
> Mmmh there is no libssl1.1-dbgsym in stretch, only in sid?
>
> I do think we need those stack traces from libssl.

It should be there. But you need to enable the right repository:

https://wiki.debian.org/AutomaticDebugPackages
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
Could you get another one with libssl1.1-dbgsym installed? But just with
that, maybe other people could infer what's wrong.
-- 
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Marcus Ulbrich <m.ulbr...@tu-braunschweig.de>
 Sent:  2 octobre 2017 19:57 +0200
 Subject: Re: Haproxy segfault error 4 in libc-2.24
 To: Vincent Bernat
 Cc: haproxy@formilux.org

> Okay... I've got a core dump... Thanks a lot!!!
>
> But what this means?
>
>
>
> Program received signal SIGSEGV, Segmentation fault.
>
> __memmove_sse2_unaligned_erms () at
> ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:
>
> ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:
> File or Directory not found.
>
>
> (gdb) bt
>
> #0 0x7ff59a39f760 in __write_nocancel () at
> ../sysdeps/unix/syscall-template.S:84
>
> #1 0x7ff59abc4a45 in ?? () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> #2 0x7ff59abbf58b in BIO_write () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> #3 0x7ff59afbfa4b in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #4 0x7ff59afc0260 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #5 0x7ff59afc8751 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #6 0x7ff59afc6b55 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #7 0x7ff59afd0cd9 in SSL_shutdown () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> #8 0x55bfb883e6b9 in ssl_sock_shutw (conn=0x55bfb9edf9f0,
> clean=)
>
> at src/ssl_sock.c:3923
>
> #9 0x55bfb8801696 in conn_data_shutw (c=) at
> include/proto/connection.h:437
>
> #10 stream_int_shutw_conn (si=0x55bfb9e80798) at src/stream_interface.c:856
>
> #11 0x55bfb8802c8b in si_shutw (si=0x55bfb9e80798) at
> include/proto/stream_interface.h:322
>
> #12 stream_int_notify (si=si@entry=0x55bfb9e80798) at
> src/stream_interface.c:459
>
> #13 0x55bfb8802ecd in si_conn_wake_cb (conn=0x55bfb9edf9f0) at
> src/stream_interface.c:581
>
> #14 0x55bfb87dde3a in conn_fd_handler (fd=) at
> src/connection.c:158
>
> #15 0x55bfb87aae5d in fd_process_cached_events () at src/fd.c:223
>
> #16 0x55bfb8799638 in run_poll_loop () at src/haproxy.c:1751
>
> #17 0x55bfb87958a9 in main (argc=, argv= out>) at src/haproxy.c:2114
>
>
> (gdb) bt full
>
> #0 0x7ff59a39f760 in __write_nocancel () at
> ../sysdeps/unix/syscall-template.S:84
>
> No locals.
>
> #1 0x7ff59abc4a45 in ?? () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> No symbol table info available.
>
> #2 0x7ff59abbf58b in BIO_write () from
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
>
> No symbol table info available.
>
> #3 0x7ff59afbfa4b in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #4 0x7ff59afc0260 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #5 0x7ff59afc8751 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #6 0x7ff59afc6b55 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #7 0x7ff59afd0cd9 in SSL_shutdown () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
>
> No symbol table info available.
>
> #8 0x55bfb883e6b9 in ssl_sock_shutw (conn=0x55bfb9edf9f0,
> clean=) at src/ssl_sock.c:3923
>
> clean = 
>
> conn = 0x55bfb9edf9f0
>
> #9 0x55bfb8801696 in conn_data_shutw (c=) at
> include/proto/connection.h:437
>
> No locals.
>
> #10 stream_int_shutw_conn (si=0x55bfb9e80798) at src/stream_interface.c:856
>
> No locals.
>
> #11 0x55bfb8802c8b in si_shutw (si=0x55bfb9e80798) at
> include/proto/stream_interface.h:322
>
> No locals.
>
> #12 stream_int_notify (si=si@entry=0x55bfb9e80798) at
> src/stream_interface.c:459
>
> No locals.
>
> #13 0x55bfb8802ecd in si_conn_wake_cb (conn=0x55bfb9edf9f0) at
> src/stream_interface.c:581
>
> si = 0x55bfb9e80798
>
> #14 0x55bfb87dde3a in conn_fd_handler (fd=) at
> src/connection.c:158
>
> conn = 0x55bfb9edf9f0
>
> flags = 
>
> #15 0x55bfb87aae5d in fd_process_cached_events () at src/fd.c:223
>
> fd = 22
>
> entry = 0
>
> e = 
>
> #16 0x55bfb8799638 in run_poll_loop () at src/haproxy.c:1751
>
> next = 
>
> #17 0x55bfb87958a9 in main (argc=, argv= out>) at src/haproxy.c:2114
>
> err = 
>
> retry = 
>
> limit = {rlim_cur = 8046, rlim_max = 8046}
>
> errmsg =
> "\000\000\000\000\000\000\000\000\340\230\273\271\277U\000\000
> !\271P\374\177\000\000\350
> \271P\374\177\000\000\006\000\000\000\000\000\000\000\064\357\063\232\365\177\000\000
> !\271P\374\177\000\000 F\273\271\277U\000\000\000\313
> \233\365\177\000\000\256\215ǚ\365\177\000\000>\001\000\024\000\000\000\000\000bca\304h\347Kh\371",
> 
>
> pidfd = 



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
How many haproxy process do you have? Can you reduce nbprocs to 1 if you set it 
to another value? In this case, attach directly to haproxy with gdb -p pid, 
type continue to unblock it and wait for the segfault. Then bt full.

On October 2, 2017 6:59:47 PM GMT+02:00, Marcus Ulbrich 
 wrote:
>no chance... error or killing haproxy there is no core file there... 
>wether in /var/lib, nor in /tmp
>I am frustrated...


Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
 ❦  2 octobre 2017 18:38 +0200, Marcus Ulbrich  :

> yes... core of python script is there than... but i can't get one of
> haproxy segfault :-/

Not even in /var/lib/haproxy then?

If it works with the Python script, try set kernel.core_pattern to just
"/tmp/core". Do you get it? If yes, do you get it too with:

python -c 'import os,time; os.chroot("/var/lib/haproxy"); os.chdir("/"); 
time.sleep(1000)' &
kill -SEGV %1

It should be in /var/lib/haproxy/tmp. If yes, you should get it with
HAProxy too.
-- 
So so is good, very good, very excellent good:
and yet it is not; it is but so so.
-- William Shakespeare, "As You Like It"



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
 ❦  2 octobre 2017 17:06 +0200, Marcus Ulbrich  :

> I even get no core dump with the python oneliner either with chroot
> nor without...

So, kernel.core_pattern seems to be problematic (unrelated, but my
python one-liner wasn't totally correct either). Try again with just
"core", the core file should be in the current directory. If it works,
retry with HAProxy and you should get the core in /var/lib/haproxy.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
Well, I have no idea why you don't get those core files. It's also quite
odd that you get chrooted without the chroot directive. Maybre 'rgrep
chroot /etc' to check if there is anything fishy. Is there anything
special in your environment? Running in a container with memory limits
maybe?

To be sure the core pattern works correctly, could you run:

ulimit -c unlimited
python -c 'import os,time; os.chroot("/var/lib/haproxy"); time.sleep(1000)' &
kill -SEGV %1

You should get a "segmentation fault (core dumped)" and a core file in
/var/lib/haproxy/tmp. If not, check in /tmp directly (on my system, I
didn't get the core file in the chroot, this is new to me). If it
doesn't work, try without os.chroot() and check you get a core file in
/tmp.
-- 
All things that are, are with more spirit chased than enjoyed.
-- Shakespeare, "Merchant of Venice"

 ――― Original Message ―――
 From: Marcus Ulbrich <m.ulbr...@tu-braunschweig.de>
 Sent:  2 octobre 2017 16:39 +0200
 Subject: Re: Haproxy segfault error 4 in libc-2.24
 To: Vincent Bernat
 Cc: haproxy@formilux.org

> okay...
>
> $# sysctl kernel.core_pattern
>
> kernel.core_pattern = /tmp/core.%e.%p.%h.%t
>
> $# ls -ld /var/lib/haproxy/tmp
>
> drwxrwxrwt 2 root root 4096 Okt  2 16:11 /var/lib/haproxy/tmp



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
 ❦  2 octobre 2017 16:29 +0200, Marcus Ulbrich  :

> sorry, but it is commented out... :(

Humm, I don't see how HAProxy would chroot itself without this
directive. Let's try to get the core inside the chroot.

Could you confirm the output of:

 sysctl kernel.core_pattern
 ls -ld /var/lib/haproxy/tmp
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
Then, remove the chroot directive from HAProxy configuration.
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Marcus Ulbrich <m.ulbr...@tu-braunschweig.de>
 Sent:  2 octobre 2017 16:23 +0200
 Subject: Re: Haproxy segfault error 4 in libc-2.24
 To: Vincent Bernat
 Cc: haproxy@formilux.org

> nope...  /var/lib/haproxy/tmp/ directory is left empty after crash...
>
>
> Am 02.10.2017 um 16:09 schrieb Vincent Bernat:
>>   ❦  2 octobre 2017 16:05 +0200, Marcus Ulbrich 
>> <m.ulbr...@tu-braunschweig.de> :
>>
>>> this is linked to /proc/20313/root -> /var/lib/haproxy
>>>
>>> and there is dev/log as empty file..
>> Then, create /var/lib/haproxy/tmp:
>>
>> mkdir /var/lib/haproxy/tmp
>> chmod 1777 /var/lib/haproxy/tmp
>>
>> You should get the core files in this directory (keep core_pattern to 
>> /tmp/...).



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
 ❦  2 octobre 2017 16:05 +0200, Marcus Ulbrich  :

> this is linked to /proc/20313/root -> /var/lib/haproxy
>
> and there is dev/log as empty file..

Then, create /var/lib/haproxy/tmp:

mkdir /var/lib/haproxy/tmp
chmod 1777 /var/lib/haproxy/tmp

You should get the core files in this directory (keep core_pattern to /tmp/...).
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
 ❦  2 octobre 2017 15:58 +0200, Marcus Ulbrich  :

> Yes there is no core dump...
>
> i've ched it and ist was both unlimited...

And "ls -l /proc/xxx/root" is "/" (where xxx is the PID of one of the
HAProxy processes)?
-- 
What good is an obscenity trial except to popularize literature?
-- Nero Wolfe, "The League of Frightened Men"



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
Hello,

Not sure to understand. Is there no core dump or more than one? If none,
did you check in /proc/xxx/status that the limit was correctly applied?
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Marcus Ulbrich <m.ulbr...@tu-braunschweig.de>
 Sent:  2 octobre 2017 12:49 +0200
 Subject: Re: Haproxy segfault error 4 in libc-2.24
 To: Vincent Bernat
 Cc: haproxy@formilux.org

> Hello Vincent,
>
> thanks for your reply. I have done what you said... but there ist nore
> core file dumped in /tmp/.
>
> running gdb console it only says "[Inferior 1 (process 719) exited
> normally]" when the segfault error occours and haproxy restarts. bt
> and bt full results in "No stack."
>
> Can you help about this?
>
> kind regards,
>
> marcus
>
>
> Am 02.10.2017 um 11:35 schrieb Vincent Bernat:
>>   ❦  2 octobre 2017 10:31 +0200, Marcus Ulbrich 
>> <m.ulbr...@tu-braunschweig.de> :
>>
>>> I am running haproxy 1.7.9-1~bpo9+1 on debian 9.1. And after running a
>>> while with production data haproxy stops working wiith segmentation
>>> fault:
>>>
>>> haproxy[26291]: segfault at 5562af80e000 ip 7f5985e48149 sp
>>> 7ffe1d613488 error 4 in libc-2.24
>>>
>>> Can you please help or have any ideas?
>> Try to obtain a core file:
>>
>>   - don't use chroot directive in /etc/haproxy/haproxy.cfg
>>   - sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%h.%t
>>   - systemctl edit haproxy.service and put the following:
>>
>> [Service]
>> LimitCORE=infinity
>>
>>   - systemctl daemon-reload
>>   - systemctl restart haproxy
>>
>> Check with "cat /proc/$(pidof haproxy | head -1)/limits" both limits for
>> "core file size" is unlimited.
>>
>> Once you get a core file in /tmp/core.haproxy.something, use:
>>
>>   - apt-get install haproxy-dbgsym libc6-dbg gdb
>>   - gdb /usr/sbin/haproxy /tmp/core.haproxy.something
>>   - bt full (post the result)
>>
>> To reverse your system:
>>
>>   - apt-get remove haproxy-dbgsym libc6-dbg gdb
>>   - rm /etc/systemd/system/haproxy.service.conf.d/something.conf
>>   - systemctl daemon-reload
>>   - sysctl -w kernel.core_pattern=core



Re: Haproxy segfault error 4 in libc-2.24

2017-10-02 Thread Vincent Bernat
 ❦  2 octobre 2017 10:31 +0200, Marcus Ulbrich  :

> I am running haproxy 1.7.9-1~bpo9+1 on debian 9.1. And after running a
> while with production data haproxy stops working wiith segmentation
> fault:
>
> haproxy[26291]: segfault at 5562af80e000 ip 7f5985e48149 sp
> 7ffe1d613488 error 4 in libc-2.24
>
> Can you please help or have any ideas?

Try to obtain a core file:

 - don't use chroot directive in /etc/haproxy/haproxy.cfg
 - sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%h.%t
 - systemctl edit haproxy.service and put the following:

[Service]
LimitCORE=infinity

 - systemctl daemon-reload
 - systemctl restart haproxy

Check with "cat /proc/$(pidof haproxy | head -1)/limits" both limits for
"core file size" is unlimited.

Once you get a core file in /tmp/core.haproxy.something, use:

 - apt-get install haproxy-dbgsym libc6-dbg gdb
 - gdb /usr/sbin/haproxy /tmp/core.haproxy.something
 - bt full (post the result)

To reverse your system:

 - apt-get remove haproxy-dbgsym libc6-dbg gdb
 - rm /etc/systemd/system/haproxy.service.conf.d/something.conf
 - systemctl daemon-reload
 - sysctl -w kernel.core_pattern=core
-- 
How apt the poor are to be proud.
-- William Shakespeare, "Twelfth-Night"



  1   2   3   >