Attempting to reuse keys on a basis different to the cert (AKA,
storing the key in a directory with a hashed name different to
the cert it is associated with) was ineffective since when
"lego run" is used it will ALWAYS generate a new key. This causes
issues when you revert changes since your "reused" key will not
be the one associated with the old cert. As such, I tore out the
whole keyDir implementation.
As for the race condition, checking the mtime of the cert file
was not sufficient to detect changes. In testing, selfsigned
and full certs could be generated/installed within 1 second of
each other. cmp is now used instead.
Also, I removed the nginx/httpd reload waiters in favour of
simple retry logic for the curl-based tests
Testing of certs failed randomly when the web server was still
returning old certs even after the reload was "complete". This was
because the reload commands send process signals and do not wait
for the worker processes to restart. This commit adds log watchers
which wait for the worker processes to be restarted.
- Use an acme user and group, allow group override only
- Use hashes to determine when certs actually need to regenerate
- Avoid running lego more than necessary
- Harden permissions
- Support "systemctl clean" for cert regeneration
- Support reuse of keys between some configuration changes
- Permissions fix services solves for previously root owned certs
- Add a note about multiple account creation and emails
- Migrate extraDomains to a list
- Deprecate user option
- Use minica for self-signed certs
- Rewrite all tests
I thought of a few more cases where things may go wrong,
and added tests to cover them. In particular, the web server
reload services were depending on the target - which stays alive,
meaning that the renewal timer wouldn't be triggering a reload
and old certs would stay on the web servers.
I encountered some problems ensuring that the reload took place
without accidently triggering it as part of the test. The sync
commands I added ended up being essential and I'm not sure why,
it seems like either node.succeed ends too early or there's an
oddity of the vm's filesystem I'm not aware of.
- Fix duplicate systemd rules on reload services
Since useACMEHost is not unique to every vhost, if one cert
was reused many times it would create duplicate entries in
${server}-config-reload.service for wants, before and
ConditionPathExists
This allows the user to configure systemd tmpfiles.d via
`environment.etc."tmpfiles.d/X.conf".text = "..."`, which after #93073
causes permission denied (with new X.conf):
```
ln: failed to create symbolic link '/nix/store/...-etc/etc/tmpfiles.d/X.conf': Permission denied
builder for '/nix/store/...-etc.drv' failed with exit code 1
```
or collision between environment.etc and systemd-default-tmpfiles
packages (with existing X.conf, such as tmp.conf):
```
duplicate entry tmpfiles.d/tmp.conf -> /nix/store/...-etc-tmp.conf
mismatched duplicate entry /nix/store/...-systemd-246/example/tmpfiles.d/tmp.conf <-> /nix/store/...-etc-tmp.conf
builder for '/nix/store/...-etc.drv' failed with exit code 1
```
Fixes#96755
GPaste ships keybindings for gnome-control-center. Those depend on GSettings schemas
but there is currently no mechanism for loading schemas other than using global ones
from $XDG_DATA_DIRS. Eventually, I want to add such mechanism but until then,
let's return the impure sessionPath option that was removed in
f63d94eba3
