Secrets are injected from the environment into the rendered
configuration before each startup using envsubst.
The test now makes use of this feature for the db password.
In version 2.0.15 `gotify` switched to `packr` at 2.x which is why the
UI can't be served properly via HTTP and causes an empty 500 response and
the following errors in `journald`:
```
2020/09/12 19:18:33 [Recovery] 2020/09/12 - 19:18:33 panic recovered:
GET / HTTP/1.1
Host: localhost:8080
Accept: */*
User-Agent: curl/7.72.0
stat /home/ma27/Projects/ui/build/index.html: no such file or directory
```
This wasn't caught by the VM-test as it only tested the REST and push
APIs. Using their internal `packr.go` script in our build as it's the
case in the upstream build-system[1] fixes the issue.
[1] https://github.com/gotify/server/pull/277/files#diff-b67911656ef5d18c4ae36cb6741b7965R48
This commit fixes the ejabberd tests for hydra:
mod_http_upload and mod_disco need to be explicitly enabled, and a
handler needs to be setup to make it work. Also, the client needs to be
able to contact the server.
The commit also fixes the situation where http upload failed: in that
case the client would wait forever because nothing catched the error.
Finally, there remains a non-reproducible error where ejabberd server
fails to start with an error like:
format: "Failed to create cookie file '/var/lib/ejabberd/.erlang.cookie': eacces"
(happens ~15%) I tried to check existence of /var/lib/ejabberd/ in
pre-start script and saw nothing that would explain this error, so I
gave up about this error in particular.
We apparently didn't fit anymore. I don't think this test is meant
to (also) check closure size.
Note: as of this commit, the test is blocked by a fontconfig problem,
so I tested with that merge temporarily reverted.
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
The cyclic dependency of systemd → cryptsetup → lvm2 → udev=systemd
needs to be broken somewhere. The previous strategy of building
cryptsetup with an lvm2 built without udev (#66856) caused the
installer.luksroot test to fail. Instead, build lvm2 with a udev built
without cryptsetup.
Fixes #96479.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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
The original idea for this test was, on top of providing a networkd
test, to provide newcomers with a sample configuration they could use
to get started with networkd.
That's precisely why we were doing this systemd tmpfile dance in the
first place. It was a convenient way to create a runtime file with a
specific mode and owner.
Sadly, this tmpfile rule made the test flaky. There's a race condition
between the wireguard interface configured by systemd-networkd and
systemd-tmpfiles-setup.
Sometimes, networkd is going to try loading the wireguard private key
file *before* the said file gets created by systemd-tmpfiles.
A perfect solution here would be to create a "After" dependency
between wg0.netdev and systemd-tmpfiles-setup.service. Sadly, it is
currently impossible to create such a dependency between a
networkd-specific unit and a service.
We're removing this tmp file in favor of pointing networkd directly to
the Nix store. This is clearly something that shouldn't be done in the
real world for a private file: the store is world-readable. However,
this is the only way I found to fix this test flakiness for now.
In `systemd-243` the option `FwMark` in the `[WireGuard]` section of
a `.netdev`-unit has been renamed to `FirewallMark`[1]. Due to the
removal of deprecated options in our `networkd` module[2] the evaluation
of this test doesn't work.
Renaming the option to its new name fixes the issue.
[1] 1c30b174ed
[2] e9d13d3751
