Source: https://github.com/matrix-org/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types
As an alternative, we should probably find a way to run one or a few
more generic workers (which will handle appservice and user_dir stuff) and
update `homeserver.yaml` so that it would point to the name of these workers using
`notify_appservices_from_worker` and `update_user_directory_from_worker` options.
For now, this solves the deprecation, so we can have a peace of mind
going forward.
We're force-setting these worker counts to 0, so that we can clean up
existing homeservers which use these worker types. In the future, these
options will either be removed or repurposed (so that they transparently
create more generic workers that handle user_dir/appservice loads).
Details here: https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_6.html#id36
Basically:
```yaml
- name: Prior to 2.13
debug:
msg: '[1] + {{ [2] }}'
- name: 2.13 and forward
debug:
msg: '{{ [1] + [2] }}'
```
Interestingly, we had been using the new/safe syntax in lofs of places.
We were using the broken one in many others though. Hopefully all
instances were fixed by this patch.
Related to https://gitlab.com/mx-puppet/discord/mx-puppet-discord/-/issues/117
Looks like the bridge is too quick to start and fails to initialize
itself by connecting to Synapse. It's mostly observed after a system
reboot, because Synapse (and everything else) is slower to start.
Once mx-puppet-discord fails to initialize itself, a "No relay found"
error will be observed any time you try to relay a Matrix message to
Discord. Relaying messages in the other direction (Discord to Matrix)
also fails.
With this workaround (longer delay on mx-puppet-discord startup), I
observe mx-puppet-discord working well, even after a full reboot.
Of course, a proper fix is preferable, instead of delaying by a magic
number of seconds.
These endpoints should not be proxied to a generic Synapse worker
without other preparation (setting up stream writers, sending traffic
to a specific stream writer, etc.).
Disabling them for now. In the future, we'd like to fix up our awk
script to disable them automatically.
This is a fix up for 058fedff91
This prevented us from keeping our workers reverse-proxying definitions
updated since Synapse v1.54.0.
The last `workers.md` file we could parse is at commit
02632b3504ad4512c5f5a4f859b3fe326b19c788.
Parsing regressed at commit c56bfb08bc071368db23f3b1c593724eb4f205f0,
because the introduction message for `synapse.app.generic_worker` said
"If":
> If a worker is set up to handle a..
.. which made the AWK script think that definitions below were
conditional (which they're not in this case).
This patch fixes up the regex for determining if a line is conditional
or not, so that it doesn't trip up. Hopefully, it doesn't miss something
important.
When setting `matrix_nginx_proxy_enabled: false` and enabling authentication on the metrics endpoint, the htpasswd file is hardcoded to the nginx-proxy container dir, this changes the hardcoded value to a variable so the path can be updated
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1775
Related to https://signald.org/articles/install/docker/#migrating-from-versions-before-0180
> Prior to 0.18.0 the signald container image used the root user, which is not recommended for security reasons. This was fixed in the 0.18.0 release which will start as root, fix permissions on the volume, then drop to the non-root user and start signald. Future images will start as the non-root user, so if you’re upgrading make sure to run 0.18.0 at least once.
> A special tag, 0.18.0-non-root, will be published. it starts as the non-root user and does not fix permissions on the volume.
* Add matrix-registration-bot
This adds an install and uninstall task plus helpers. The bot is disabled by default.
This commit does not include documentation, yet. In short, the bot can be enabled by adding
matrix_bot_matrix_registration_bot_enabled: true
matrix_bot_matrix_registration_bot_matrix_user_password: "verysecret"
matrix_bot_matrix_registration_bot_matrix_admin_token: "supersecret"
to the host_vars
* Change bot username to bot.matrix-registration-bot following convention
* Address smaller remarks, fix local docker build
* Switch to an env file
* Add environment variables extension for additional config
* Add documentation for the matrix-registration-bot
* Add screenshot on how to obtain admin access token
* Use bot as admin to only have one access token (bot and admin api)
* Use cleaner setting of matrix_synapse_registration_requires_token
* Use config file for cleaner more secure usage
* Delete unneeded env
* Rename vars to make usage clear
* Fix typos/wording and add notice about logging out
* Convert configuration to use |to_json
* Reorder role includes
Nothing should be after `matrix-common-after`.
`matrix-bot-matrix-registration-bot` can probably be anywhere, but it makes sense to put it next to the other `matrix-bot-*` roles.
* Minor group_vars/matrix_servers touchups
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
It is very confusing to debug why messages only go from Matrix to Slack
but not from Slack to Matrix. RTM should be enabled by default, as
that's the recommended way to make this work.
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
