This changes the default behavior which opened by default the firewall rules.
The users now need to declare explicitely they want to open the firewall.
This exposes 2 scenario running the mediatomb service:
- one running with the unmaintained mediatomb package
- one running with the new maintained gerbera package
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 server password.
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
