Re: soft-stop stops runtime API, should that be optional?
Hi,
I'll appreciate a response on this, I was unable to get any guidance from
docs.
Thanks
On Tue, Nov 7, 2023 at 3:37 PM Abhijeet Rastogi
wrote:
> Hi HAproxy community,
>
> In our HAproxy deployment, access to runtime API is extremely critical, it
> is used for:-
> - collecting metrics
> - managing servers in a backend (SoT is not DNS, so we have to use runtime
> API), etc
>
> I observed that, when soft-stop is in progress, we get the following error
> while performing a connect.
>
> connect(5, {sa_family=AF_UNIX, sun_path="path/to/haproxy.sock"}, 60) = -1
> ECONNREFUSED (Connection refused)
> recvfrom(3, 0x7ffcc675fe10, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN
> (Resource temporarily unavailable)
>
> Due to this, we're unable to perform any operations or collect metrics
> while haproxy is in soft stop, for us, that's a long time as we use the
> current settings.
>
> close-spread-time 10m
> hard-stop-after 11m
>
> "stats socket" (unix socket) is configured on one of the production
> frontends, we're using version "version 2.8.0-01b97d-15 2023/09/26".
>
> Will it make sense if HAproxy had an option to not disable runtime API
> during soft-stop, perhaps an argument
> While exploring the code, I noticed that the soft-stop code stops all
> "stoppable
> listeners"
> ,
> I wonder if there's a way to make a listener non-stoppable?
>
> Are there any workarounds to getting around this limitation, while also
> retaining the soft-stop behavior?
> Our reason to use soft-stop is to do best-effort into gracefully draining
> client connections (send Connection: close). We also don't have a way to
> drain H2 connections proactively, but that's a discussion for another day.
>
> Cheers,
> Abhijeet (https://abhi.host)
>
--
Cheers,
Abhijeet (https://abhi.host)
Re: Can't display the certificate: Not found or the certificate is a bundle!
On Tue, Nov 14, 2023 at 02:21:44PM +0100, Christoph Kukulies wrote: > Thanks. > > I did a fresh > > acme.sh --issue -d domain ... --keylength 2048 > with prior revoking the certificates since I was a bit unsure what the > partially exposing of my provate key was concerned - thanks, Shawn. > > I went back to the Wiki and found the necessary steps there: > > DEPLOY_HAPROXY_HOT_UPDATE=yes > DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock > DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d > www.mydomain.org --deploy-hook haproxy > [Tue Nov 14 02:07:26 PM CET 2023] Deploying PEM file > [Tue Nov 14 02:07:26 PM CET 2023] Moving new certificate into place > [Tue Nov 14 02:07:26 PM CET 2023] Reload successful > [Tue Nov 14 02:07:26 PM CET 2023] Success > acme@mail:~/.acme.sh$ ls -l /etc/haproxy/certs > total 12 > -rw-rw-r-- 1 acme acme 8489 Nov 14 14:07 www.mydomain.org.pem > > Christoph Kukulies > k...@kukulies.org > > > > This file seems to be assembled by the deploy script. (since it contains the > private key). > > So far so good for the first. Got to implement the renewal mechanism now. I don't think you followed correctly the instruction of the wiki, the DEPLOY_HAPROXY_HOT_UPDATE=yes option is supposed to prevent the reload by using the CLI. It does not look like this is working here. You must have skipped the installation of the deploy script. https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh#acmesh-installation -- William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
Thanks. I did a fresh acme.sh --issue -d domain ... --keylength 2048 with prior revoking the certificates since I was a bit unsure what the partially exposing of my provate key was concerned - thanks, Shawn. I went back to the Wiki and found the necessary steps there: DEPLOY_HAPROXY_HOT_UPDATE=yes DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d www.mydomain.org --deploy-hook haproxy [Tue Nov 14 02:07:26 PM CET 2023] Deploying PEM file [Tue Nov 14 02:07:26 PM CET 2023] Moving new certificate into place [Tue Nov 14 02:07:26 PM CET 2023] Reload successful [Tue Nov 14 02:07:26 PM CET 2023] Success acme@mail:~/.acme.sh$ ls -l /etc/haproxy/certs total 12 -rw-rw-r-- 1 acme acme 8489 Nov 14 14:07 www.mydomain.org.pem Christoph Kukulies k...@kukulies.org This file seems to be assembled by the deploy script. (since it contains the private key). So far so good for the first. Got to implement the renewal mechanism now. > Am 13.11.2023 um 17:20 schrieb William Lallemand : > > On Mon, Nov 13, 2023 at 10:46:08AM +0100, Christoph Kukulies wrote: >>> Am 13.11.2023 um 10:09 schrieb William Lallemand : acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | socat /var/run/haproxy/admin.sock - Can't display the certificate: Not found or the certificate is a bundle! >> >> acme@mail:~/.acme.sh/www.mydomain.org_ecc$ echo "show ssl cert " | socat >> /var/run/haproxy/admin.sock - >> # filename >> /etc/haproxy/certs/fullchain.pem >> /etc/haproxy/certs/fullchain_ec.pem >>> >> > > Well, you can't display /etc/haproxy/certs/mydomain.org.pem because it's > not in haproxy. > > Can you share the output of your deploy acme.sh command as well as your > haproxy configuration? > > -- > William Lallemand -- Christoph smime.p7s Description: S/MIME cryptographic signature
Re: Should we change the -c output?
On Tue, Nov 14, 2023 at 02:32:40AM -0500, John Lauro wrote: > I like the default message. If you want to suppress it, then you can use -q. > Having some standard output that can be suppressed with -q is also > fairly standard for UNIX commands. > In haproxy we have these two flags: -q is meant to suppress all the messages, even when the configuration is wrong, that's not the same thing as displaying only the errors. -V is meant to add more output than the default. Till 2.8, the systemd unit was not displaying the errors upon a reload because it was checking the configuration with -q, I'm surprised nobody reported it, because that's really a pain to have a process which reloads incorrectly without showing any error. Problem is, when removing the -q, the script adds "Configuration is valid" to the logs for every reloads, which are already a bit heavy for just a reload. Using -q for this was a problem, so I'd better not do it. I'm not talking about suppressing the message, just hiding the "valid" message by default, without -V. All other warnings and alerts are still outputed, so it's easy to see if you broke something. -- William Lallemand
