lighttpd: trigger reload on ACME cert renewal

[stokito]

Maintainer: @gstrauss Compile tested: main branch OpenWrt Run tested: VirtualBox

Description: When the acme service issued a new cert it will call a hotplug and send UBUS event acme.renew. All services that may use the certs issued by acme should re-read the certs if they were changed. The triggers was already added for uhttpd, nginx and haproxy. But not for the Lighttpd and Apache. For the Apache it would be more difficult because it doesn't use procd but for the Lighty it's simple.

Fixes #15610

[gstrauss]

Seems reasonable. I will consider this PR for the future.

However, please note that if a long upload/download is in progress from/to a slow client, then the download might be interrupted by the (configurable) default 8 second graceful restart timeout in lighttpd.

[stokito]

Thank you @gstrauss! This will help to users to get rid of custom scripts to reload.

For the typical OpenWrt usage it should be fine to lose current connection. Long downloads aren't expected. Still, the similar problem may affect the Lighttd on other setups.

I think that we may have a better solutions:

0. Check if cert file was changed and only then try to reload it. Use it for new connections while keeping old connections.
1. The Lighttpd can reload certs itself by schedule (e.g. once a day) when there are no active connections or for only new connections. The certs are renewed long before the expiration of previous certs.
2. Add some kind of the Lighttd's own Management API so that the acme can send a precise command reload certs. The Tomcat has such api and also EmailRelay has admin interface on a unix socket that can be extended for such reload certs command.

I don't know what would be a proper solution. But it needs to be also solved for other servers.

[stokito]

@gstrauss friendly remind on this

[systemcrash]

If some download is ongoing, and aborts, the user will retry. LGTM.

[gstrauss]

If some download is ongoing, and aborts, the user will retry. LGTM.

While that might be true for some users for some downloads, you have no data to prove this, and therefore your opinion is not well substantiated. Please withhold such opinions.

I have seen sufficient poorly written javascript to be able to say to that not all websocket connections will be retried to recover from disconnects.

Again, I will consider this PR for the future. However, I will not pretend to minimize the potential impact because it does not affect the specific use case that you (or anyone else) have in your head.

The next scheduled lighttpd release is targeting Jan 2025 and I may consider this PR when I push that release to openwrt.

[gstrauss]

FYI: lighttpd 1.4.78 (#26202) includes a new feature (option disabled by default) to check and reload certificates and CRLs about once a minute, without needing to restart lighttpd. https://www.lighttpd.net/2025/3/22/1.4.78/ https://wiki.lighttpd.net/Docs_SSL#Configuration