Dendrite uses a lot of databases, but a single (`dendrite`) role, which
leads to `matrix_postgres_import_roles_to_ignore` being something like
`['dendrite', 'dendrite', 'dendrite', ...]` needlessly.
This leads to weird regexes being generated for
`matrix_postgres_import_roles_ignore_regex`.
It's not that it hurts, but it just looks odd.
We were only reporting failures for when the async task didn't finish.
We also need to report a failure for when the task finished, but
returned a non-zero exit code.
This allows people to augment the Synapse image with custom tools and
addons without having to rebuild it from scratch.
If customizations are enabled, the playbook will build a new
`localhost/matrixdotorg/synapse:VERSION-customized` image
on top of the default one (`FROM matrixdotorg/synapse:VERSION`)
and with custom Dockerfile build steps.
For servers that self-build the Synapse image, the Synapse image will be
built first, before proceding to extend it the same way.
In the future, we'll also have easy to enable Dockerfile build steps
for modules that the playbook supports.
People often report and ask about these "failures".
More-so previously, when the `docker kill/rm` output was collected,
but it still happens now when people do `systemctl status
matrix-something` and notice that it says "FAILURE".
Suppressing to avoid further time being wasted on saying "this is
expected".
Reverts b1b4ba501f, 90c9801c56, a3c84f78ca, ..
I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.
`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.
Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).
We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.
In short, the problem is that older Postgres versions store passwords
hashed as md5. When you dump such a database, the dump naturally also
contains md5-hashed passwords.
Restoring from that dump used to create users and updates their passwords
with these md5 hashes.
However, Postgres v14 prefers does not like md5-hashed passwords now (by default),
which breaks connectivity. Postgres v14 prefers `scram-sha-256` for
authentication.
Our solution is to just ignore setting passwords (`ALTER ROLE ..`
statements) when restoring dumps. We don't need to set passwords as
defined in the dump anyway, because the playbook creates users
and manages their passwords by itself.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1340
