Re: USE_QUIC in haproxy debian packages?

On 2023-11-22 09:13, William Lallemand wrote: Hello Vincent, [HAProxy list in cc] We backported the USE_QUIC_OPENSSL_COMPAT build option in HAProxy 2.8.4, so we can build with USE_QUIC using OpenSSL without a patched version of OpenSSL. Unfortunately we can't activate this option in the

Re: process of release to debian, backports ?

For Debian stable, usually only a critical vulnerability. In theory, this could also be major bugs, but maintaining an hybrid patched version is something we prefer not to do, to not have people running in the wild an additional unsupported (by upstream) branch. For Debian backports, they

Re: [*EXT*] RE: [ANNOUNCE] haproxy-2.4.22

On 2023-02-14 18:08, Ionel GARDAIS wrote: Hi Marc, I guess Vincent choose to use a -2 tag so that users who hold their package on minor version will still get the update. That's because the uploads were prepared in advance, before the 2.4.22 release. Willy sent us the patch in advance to be

Re: [*EXT*] Important HAProxy releases to come next week

On 2023-02-13 19:34, Vincent Bernat wrote: That's a pretty sneaky way to ruin one's Valentine dinner. :-D Sure, but we have to compose between disclosing too early, ruining the west coast's morning and too late, ruining eastern dinners :-) Maybe this one will be remembered as the Valentine's

Re: [*EXT*] Important HAProxy releases to come next week

bug. I think we're mostly good as it is now, but I'm still having some backports to finish for now. Do you know if Vincent Bernat will be publishing his PPA quickly afterwards ? Yes, I'll be ready.

Re: add-apt-repository ppa:vbernat/haproxy-2.7 fails

On 2023-01-05 18:23, Henning Svane wrote: TimeoutError: [Errno 110] Connection timed out Either your system does not have a connection to Internet or there was a transient error with Launchpad. Not much to do except retry a bit later.

Re: Followup on openssl 3.0 note seen in another thread

On 2022-12-16 05:49, Willy Tarreau wrote: There's currently a great momentum around WolfSSL that was already adopted by Apache, Curl, and Ngtcp2 (which is the QUIC stack that powers most HTTP/3-compatible agents). Its support on haproxy is making fast progress thanks to the efforts on the two

Re: Followup on openssl 3.0 note seen in another thread

On 2022-12-14 15:15, Willy Tarreau wrote: Possibly, yes. It's more efficient in every way from what we can see. For users who build themselves (and with QUIC right now you don't have a better choice), it should not change anything and will keep robustness. For those relying on the distro's

Re: SSL Certificate

On 2022-09-01 18:53, Илья Шипицин wrote: that website provides some non confidential documentation. neither it asks you for login/password or payment details. there's nothing wrong with http on such websites. There are download links without an obvious way to check for their integrity.

Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3

On 2022-08-20 22:35, Bren wrote: EnvironmentFile=-/etc/default/haproxy Do you have something here too? Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" This does not match the file shipped by HAProxy, but this may explain why you also run into this bug.

Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3

On 2022-08-20 21:36, Ionel GARDAIS wrote: That was it : - remove the EXTRAOPTS from /etc/default/haproxy - stop the running process referencing -x /run/haproxy/admin.sock on the CLI - upgrade All is OK. First processes do not list -x on the CLI and a reload spawn a process with -x sockpair@

Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3

On 2022-08-20 19:15, Ionel GARDAIS wrote: Below is the systemctl cat haproxy output. Yes, not responding backends was expected, sorry for not specified it. "expose-fd listeners" was present in the configuration file. Update fails even after I removed the two keywords. I have EXTRAOPTS="-x

Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3

On 2022-08-19 23:09, Ionel GARDAIS wrote: Aug 19 22:09:09 haproxy-2 haproxy[1280]: [WARNING] (1280) : Failed to connect to the old process socket '/run/haproxy/admin.sock' Aug 19 22:09:09 haproxy-2 haproxy[1280]: [ALERT](1280) : Failed to get the sockets from the old process! There was

Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3

On 2022-08-19 22:16, Ionel GARDAIS wrote: I had to rollback to 2.6.2 after having upgrade to 2.6.3 because systemd was restarting the haproxy process every 1m30s (on an up-to-date Debian 11) apt upgrade itself hung while doing the upgrade. With Debian packages from haproxy.debian.net? Logs

Re: Server timeouts since HAProxy 2.2

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

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

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

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

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

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

le_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="/u

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

Re: [ANNOUNCE] haproxy-2.6.0

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

❦ 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

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

❦ 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

Re: [ANNOUNCE] haproxy-2.5.2

❦ 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

Re: [ANNOUNCE] haproxy-2.5.2

❦ 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

Re: [ANNOUNCE] haproxy-2.2.18

❦ 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

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

❦ 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

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

❦ 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 St

[PATCH] BUILD: improve reproducibility by filtering BUILD_CFLAGS

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

Re: [ANNOUNCE] haproxy-2.4.5

❦ 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

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

ersion: 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

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

❦ 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

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

❦ 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

Re: Test, please ignore

❦ 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

❦ 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

Re: Official ubuntu 20 repository

❦ 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

Re: [ANNOUNCE] haproxy-2.4.0

❦ 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

❦ 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

❦ 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

Re: [ANNOUNCE] haproxy-2.3.9

❦ 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

Re: [ANNOUNCE] haproxy-2.3.9

❦ 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 >

Re: Table sticky counters decrementation problem

❦ 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

Re: [ANNOUNCE] haproxy-1.6.16

❦ 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

Re: Packaging hatop for ubuntu20.04

❦ 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

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

❦ 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

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

❦ 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

Re: Haproxy 2.2.3 source

❦ 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: > >

Re: Haproxy 2.2.3 source

am 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; haprox

Re: Haproxy 2.2.3 source

❦ 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),

Re: Haproxy 2.2.3 source

❦ 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:

Re: HAProxy 2.2.2 CE issue report

❦ 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

Re: Haproxy 1.8.26-1~bpo9+1

❦ 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

Re: Haproxy 1.8.26-1~bpo9+1

❦ 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

Re: Haproxy 1.8.26-1~bpo9+1

❦ 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

Re: Haproxy 2.2 LTS package for Debian Stretch oldstable

❦ 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

Re: OSX builds in Travis

❦ 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 >>

Re: OSX builds in Travis

❦ 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:

Re: OSX builds in Travis

❦ 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

Re: Debian packaging note

❦ 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

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

❦ 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

Re: Segfault on 2.1.3

❦ 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.

Re: Segfault on 2.1.3

❦ 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

Re: Segfault on 2.1.3

❦ 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

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

❦ 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

Re: haproxy 2.1 package for Debian 9 Stretch oldstable

❦ 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

Re: haproxy 2.1 package for Debian 9 Stretch oldstable

❦ 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,

Re: Status of 1.5 ?

❦ 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

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

❦ 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: >>>

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

❦ 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: >

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

❦ 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

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

❦ 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);

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

❦ 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

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

❦ 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

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

❦ 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

Re: [ANNOUNCE] haproxy-1.8.20

❦ 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 wel

Re: [ANNOUNCE] haproxy-1.8.20

❦ 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

Re: [ANNOUNCE] haproxy-1.8.20

❦ 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

Re: haproxy segfault

❦ 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

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

❦ 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. >

Re: [ANNOUNCE] haproxy-1.8.13

❦ 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

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

❦ 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

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

❦ 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 st

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

❦ 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) t

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

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

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

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

Re: Haproxy 1.7.10 constantly restarting

❦ 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

Re: Syslog with systemd

❦ 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 >

Re: Syslog with systemd

❦ 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

Re: Syslog with systemd

❦ 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.

Re: Syslog with systemd

❦ 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

Re: Syslog with systemd

❦ 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

Re: Syslog with systemd

❦ 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

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

❦ 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

Re: HTTP/2 Termination vs. Firefox Quantum

❦ 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

[PATCH] MINOR: systemd: remove comment about HAPROXY_STATS_SOCKET

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 de

Re: HTTP/2 stream 1 was not closed cleanly

❦ 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

Re: Client cert verification on some paths

❦ 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,

Re: patch: allow to use any compiler

❦ 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

Re: patch: allow to use any compiler

❦ 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

Re: patch: allow to use any compiler

❦ 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

Re: Haproxy segfault error 4 in libc-2.24

❦ 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

  1   2   3   >