We no longer validate that there's an IP address defined.
Seems like Coturn can start without one as well, so there's no need to
require it.
If people populate `matrix_coturn_turn_external_ip_addresses` directly
to specify multiple addresses, they can leave
`matrix_coturn_turn_external_ip_address` empty.
We use the "select not equal to empty string" thing in the for loop
to avoid `matrix_coturn_turn_external_ip_address` leading to
`matrix_coturn_turn_external_ip_addresses: ['']` leading to
`external-ip=` in the Coturn configuration.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1741
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".
This switches the playbook from devture/rust-synapse-compress-state (a
container image which wraps the upstream-prebuilt amd64 binary of
rust-synapse-compress-state) to registry.gitlab.com/mb-saces/rust-synapse-compress-state
(https://gitlab.com/mb-saces/rust-synapse-compress-state), which builds
rust-synapse-compress-state from source and provides a multi-arch image
that currently works on amd64 and arm64.
Ideally, we'll stop using `:latest` and arm32 support will be made
available upstream as well at some point.
Discussed here: https://gitlab.com/mb-saces/rust-synapse-compress-state/-/issues/1
Changed the commit hash in matrix_synapse_ext_spam_checker_mjolnir_antispam_git_version to latest. Fixes a Synapse ImportError with mjolnir v1.4.1 leading to a Synapse crash-loop.
`roles/matrix-synapse/vars/workers.yml` has not been updated here,
because running `roles/matrix-synapse/files/workers-doc-to-yaml.awk`
seems to cause some trouble with the current `workers.md` file
available at https://github.com/matrix-org/synapse/raw/master/docs/workers.md,
namely lots of:
> FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually
lines and commented out regex lines.
This is something that remains to be investigated/fixed.
For an unknown reason prometheus ignored the given "numeric" index and replaced it by 1. This made it not work properly, plus multiple workers of same types were not differentiable. With a "string" index, it works as intended.
The `to_nice_yaml` helper will by default wrap any string YAML values on
the first space after column 80. This can in worst case yield invalid
YAML syntax. More details in Ansible's documentation here:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#formatting-data-yaml-and-json
In short, you need to explicitly provide a custom width argument of a
high number of some kind to avoid the line wrapping.
matrix_synapse_federation_port_enabled can be disabled by users, for
example, when one wants to use the same port for client and federation
requests (docs/configuring-playbook-federation.md).
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1682
Previously, when matrix-postgres was disabled, we were setting
`matrix_mautrix_twitter_database_engine` to an invalid empty value.
Now, we always hardcode `matrix_mautrix_twitter_database_engine: postgres`,
but set/unset the database hostname and password values instead.
This allows disabling the automatic portal bridging, meaning bridges
must be manually setup via self-servicing, by setting:
matrix_appservice_discord_bridge_enableSelfServiceBridging: true
"Community" support
- has been removed from mautrix/facebook in v0.3.3:
31cac6fb5e
- has been removed from mautrix/signal in v0.2.2:
1f27a608a6
- will be removed in the next mautrix/instagram release:
e2ae1ca503
- will be removed in the next mautrix/twitter release:
3893075265
For now, we disable the new `com.devture.shared_secret_auth` login type
by default, because it causes problems with Element:
https://github.com/vector-im/element-web/issues/19605
This also becomes the first module to use the new Synapse module system
that got introduced in Synapse v1.46.0.
Despite these upgrades, things should remain functionally identical
as far as bridges, matrix-corporal or other consumers are concerned.
Fedora 35 is:
- `ansible_os_family = 'RedHat'`
- `ansible_distribution_major_version = '35'`
Our RedHat checks against v7/v8 are really for RHEL derivatives (CentOS, Rockylinux,
AlmaLinux), but the same checks (by coincidence) apply for Fedora 35.
The problem is that `'35' > '7'` (comparing these as strings) is
`false`.
This patch makes sure that we always cast
`ansible_distribution_major_version` to an integer.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1610
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.
Not hardcoding 'CentOS' and using the OS family ('RedHat') instead,
we now behave better on Rockylinux and AlmaLinux, etc.
With that said, we may or may not fully support CentOS/Rockylinux/AlmaLinux v8 yet.
Certain things were improved in
https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300.
v8 support is discussed here: https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300
Certain things (firewalld?) may still be problematic. This patch does not try to address those.
If the remaining issues are confirmed to be fixed in the future, we can mark v8 as supported.
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.
1.0.2 is the first container image tag that is available as a multi-arch image
with support for linux/amd64, linux/arm64/v8 (arm64) and linux/arm/v7 (arm32),
so self-building is no longer necessary on all these platforms.
4.95-r0-1 was problematic, because `/etc/exim/exim.conf` in the
container had the wrong permissions (writable by the `exim` user).
Fixed in 697f3cff7e
which is built as 4.95-r0-2
4.95-r0-1 is the first container image tag that is available as a multi-arch image
with support for linux/amd64, linux/arm64/v8 (arm64) and linux/arm/v7 (arm32),
so self-building is no longer necessary on all these platforms.