Adding more presets in the future would be nice.

We're talking about a webserver running on the same machine, which
imports the configuration files generated by the `matrix-nginx-proxy`
in the `/matrix/nginx-proxy/conf.d` directory.

Users who run an nginx webserver on some other machine will need to do
something different.

Related to: https://matrix.org/blog/2021/02/18/synapse-1-27-0-released#dropping-armv7-docker-images

The official Etherpad Docker image has no support for sqlite3 databases.

This give us the possibility to run multiple instances of
workers that that don't expose a port.

Right now, we don't support that, but in the future we could
run multiple `federation_sender` or `pusher` workers, without
them fighting over naming (previously, they'd all be named
something like `matrix-synapse-worker-pusher-0`, because
they'd all define `port` as `0`).

Related to:
- https://github.com/matrix-org/synapse/pull/9407
- https://github.com/matrix-org/synapse/pull/7855

don't bind to any host port if nginx_proxy is used
only bind to localhost if it's not used

This leads to much easier management and potential safety
features (validation). In the future, we could try to avoid port
conflicts as well, but it didn't seem worth the effort to do it now.
Our port ranges seem large enough.

This can also pave the way for a "presets" feature
(similar to `matrix_nginx_proxy_ssl_presets`) which makes it even easier
for people to configure worker counts.

`::` leads to errors like:

> socket.gaierror: [Errno -9] Address family for hostname not supported

These validation tasks should only run when Prometheus is enabled.

It seems like it doesn't cause any issues for any of these services.

The quotes around "host" for both `--pid` and `--net` were
causing trouble for me:

> docker: --pid: invalid PID mode.

and:

> docker: Error response from daemon: network "host" not found.

I've also changed the `-v` call to `--mount` for consistency with the
rest of the playbook.

Changed `matrix_mautrix_signal_docker_image_force_pull` to `matrix_mautrix_signal_daemon_docker_image_force_pull` when force pulling the daemon

Using the hardcoded IP did break while I was
messing with IPv6 stuff on the other branch

By running it in a more privileged container with access to the host network stack and such

Also includes the dashboards for Synapse and for Node Exporter.

Again has only been tested on debian amd64 so far, but the grafana docker image is available for arm64 and arm32. Nice.

Basic system stats, to show stuff the synapse metrics
can't show such as resource usage by bridges, etc

Seems to work fine as well.

This too has only been tested on debian amd64 so far

Initial attempt. Seems to work fine.

Only tested on debian amd64 so far

This will make data migration easier.

I felt that adding another variable was probably going to be the easiest way to do this. I may end up adding another variable to enable this feature, for consistency with some of the other things.

https://github.com/vector-im/element-web/releases/tag/v1.7.20
https://hub.docker.com/layers/vectorim/element-web/v1.7.20/images/sha256-44cae3a532d86c16940deb70866b522ba6acc8c5d7adf3c661cfc8b06f1de681?context=explore

This passes any arguments given to 'matrix-postgres-cli' to the 'psql' command.

Examples:
  $ # start an interactive shell connected to a given db
  $ sudo matrix-postgres-cli -d synapse
  $ # run a query, non-interactively
  $ sudo matrix-postgres-cli -d synapse -c 'SELECT group_id FROM groups;'

If they do, our next playbook runs would simply revert it
and report "changed" for that task.

There's no benefit to letting the bridge spew a new config file.

This does not apply to the mautrix whatsapp bridge, because that one
is written in Go (not Python) and takes different flags. There's no
equivalent flag there.