This also removes the `matrix_synapse_version_arm64` variable we've
been dragging around for a long time.
Since https://github.com/matrix-org/synapse/pull/11810, a multiarch Synapse
container image (for AMD64 and ARM64) is released at the same time.
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.
v1.50.0 was found to be buggy for people using a `webclient` listener.
This is fixed in v1.50.1.
We don't use such a listener, so we weren't affected anyway.
Also get rid of `--tags=update-user-password` in the
`matrix-dendrite` role, as what we had doesn't work.
We may be able to do it with some Ansible helper or something else.
For now, we'll omit this feature.
This upgrade is technically not needed due to 1.49.1 and 1.49.2 being identical with a lone fix to Debian packaging being the only change.
Still some might want us to be on the absolutely latest version even tho these 2 are practically identical.
ARM64 has yet to be built so this has to wait for that before merge.
Related to https://github.com/matrix-org/synapse/issues/11604
Getting an upstream fix is preferable. In any case, it's probably nice
to have this defined explicitly in our configuration. This way, people
can more easily discover that they can override the URL preview
language.
We had to remove UID/GID environment variables that we used to pass
to the Synapse container, because it was causing a problem after
https://github.com/matrix-org/synapse/pull/11209
We were using both `--user` and UID/GID environment variables until now.
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.
