Somewhat related to #213 (Github Pull Request).

We've been moving in the opposite direction for quite a long time.
All services should just leave logging to systemd's journald.

This is a new feature of Synapse v1.1.0.

Discussed in #145 (Github Pull Request).

Well, `config.yaml` has been playbook-managed for a long time.
It's now extended to match the default sample config of the Discord
bridge.

With this patch, we also make `registration.yaml` playbook-managed,
which leads us to consistency with all other bridges.

Along with that, we introduce `./config` and `./data` separation,
like we do for the other bridges.

With most people on Synapse v0.99+ and Synapse v1.0 now available,
we should no longer try to be backward compatible with Synapse 0.34,
because this just complicates the instructions for no good reason.

Changes to the original are:
- it tells people to stop and disable services, so that:
   - services won't be running while you are copying files
   - services won't accidentally start again later
- it does the file-copying in 1 step
- it does copying before running `--tags=setup-all`, so that existing files (SSL certificates, etc.) can be reused. Otherwise, the playbook starts from a blank slate, retrieves them anew, generates new signing keys anew, etc. Only to have those replaced by your own old backup later.
- it mentions DNS changes
- combines `--tags=setup-all,start` into a single step, thanks to the files being already copied

This doesn't replace all usage of `-v`, but it's a start.

People sometimes troubleshoot by deleting files (especially bridge
config files). Restarting Synapse with a missing registration.yaml file
for a given bridge, causes the `-v
/something/registration.yaml:/something/registration.yaml:ro` option
to force-create `/something/registration.yaml` as a directory.

When a path that's provided to the `-v` option is missing, Docker
auto-creates that path as a directory.
This causes more breakage and confusion later on.

We'd rather fail, instead of magically creating directories.
Using `--mount`, instead of `-v` is the solution to this.

From Docker's documentation:

> When you use --mount with type=bind, the host-path must refer to an existing path on the host.
> The path will not be created for you and the service will fail with an error if the path does not exist.

Refers to #89 (Github Issue)

and provide an example for using the admin API

The bit about the matrix-make-user-admin script was messed up (it wasn't actually a code block so the "<username>" was hidden). For me at least it seems like the ``` syntax is much harder to accidentally mess up.

Docs for #161 (Github issue) and #168 (Github Pull Request).

The previous URL returns a 404.

Hopefully, we no longer lead people to believe that DNS SRV
records are going away forever and for all use-cases.

Fixes #156 (Github Issue)

It's too many configuration options to keep them in a single list.
Trying to put some order.

Fixes #129 (Github Issue).

Unfortunately, we rely on `service_facts`, which is only available
in Ansible >= 2.5.

There's little reason to stick to an old version such as Ansible 2.4:
- some time has passed since we've raised version requirements - it's
time to move into the future (a little bit)
- we've recently (in 82b4640072) improved the way one can run
Ansible in a Docker container

From now on, Ansible >= 2.5 is required.

Inspired by #128 (Github Issue), we've created a new Docker image
to replace https://hub.docker.com/r/qmxme/ansible

Adding dnspython or dig to `qmxme/ansible` doesn't seem like a good
idea (that might be accepted by them), given that it's specific to our
use case. That's why we'll be maintaining our own image from now on.

When using Let's Encrypt SSL certificates, a cronjob is set up to
automatically renew them. Though it does require a `cron`-compatible
program on the server.

This fixes the error that is caused by the `/etc/cron.d` directory
not existing and the `ansible-cron` module trying to write out a
file there -- without checking if the directory exists first.

Related to #108 (Github Pull Request).

It didn't mention `matrix_appservice_discord_client_id` and
`matrix_appservice_discord_bot_token`, which makes it hard for
beginners.

Related to #105 (Github Pull Request).

Bridge is setup to work on the matrix side with this, but the discord invite link is not automatically generated.