self-hosted/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-24 10:27:04 +02:00
Code Issues Releases Activity
5e00f0135e
matrix-docker-ansible-deploy/roles/matrix-synapse/vars/main.yml

35 lines
2.6 KiB
YAML
Raw Normal View History

Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-16 18:05:48 +02:00
---
Rename some variables
2019-02-28 11:51:09 +02:00
matrix_synapse_client_api_url_endpoint_public: "https://{{ matrix_server_fqn_matrix }}/_matrix/client/versions"
Make Matrix federation port configurable Fixes #523 (Github Issue).
2020-06-09 07:29:03 +02:00
matrix_synapse_federation_api_url_endpoint_public: "https://{{ matrix_server_fqn_matrix }}:{{ matrix_federation_public_port }}/_matrix/federation/v1/version"
Move mautrix telegram and whatsapp into separate roles The goal is to move each bridge into its own separate role. This commit starts off the work on this with 2 bridges: - mautrix-telegram - mautrix-whatsapp Each bridge's role (including these 2) is meant to: - depend only on the matrix-base role - integrate nicely with the matrix-synapse role (if available) - integrate nicely with the matrix-nginx-proxy role (if available and if required). mautrix-telegram bridge benefits from integrating with it. - not break if matrix-synapse or matrix-nginx-proxy are not used at all This has been provoked by #174 (Github Issue).
2019-05-14 16:47:22 +02:00
# Tells whether this role had executed or not. Toggled to `true` during runtime.
matrix_synapse_role_executed: false
Remove some fact definitions during runtime
2019-08-22 07:00:02 +02:00
matrix_synapse_media_store_directory_name: "{{ matrix_synapse_media_store_path|basename }}"
Do not handle /_matrix/federation on client-server port, nor /_matrix/client stuff on federation port I guess it didn't hurt to do it until now, but it's not great serving federation APIs on the client-server API port, etc. matrix-corporal doesn't work yet (still something to be solved in the future), but its firewalling operations will also be sabotaged by Client-Server APIs being served on the federation port (it's a way to get around its firewalling).
2021-01-24 22:18:31 +02:00
# A Synapse generic worker can handle both federation and client-server API endpoints.
# We wish to split these, as we normally serve federation separately and don't want them mixed up.
#
# This is some ugly Ansible/Jinja2 hack (seen here: https://stackoverflow.com/a/47831492),
# which takes a list of various strings and removes the ones NOT containing `/_matrix/client` anywhere in them.
#
# We intentionally don't do a diff between everything possible (`matrix_synapse_workers_generic_worker_endpoints`) and `matrix_synapse_workers_generic_worker_federation_endpoints`,
# because `matrix_synapse_workers_generic_worker_endpoints` also contains things like `/_synapse/client/`, etc.
# While /_synapse/client/ endpoints are somewhat client-server API-related, they're:
# - neither part of the client-server API spec (and are thus, different)
# - nor always OK to forward to a worker (we're supposed to obey `matrix_nginx_proxy_proxy_matrix_client_api_forwarded_location_synapse_client_api_enabled`)
#
# It's also not too many of these APIs (only `^/_synapse/client/password_reset/email/submit_token$` at the time of this writing / 2021-01-24),
# so it's not that important whether we forward them or not.
#
# Basically, we aim to cover most things. Skipping `/_synapse/client` or a few other minor things doesn't matter too much.
matrix_synapse_workers_generic_worker_client_server_endpoints: "{{ matrix_synapse_workers_generic_worker_endpoints|default([]) | map('regex_search', '.*/_matrix/client.*')| list | difference([none]) }}"
# A Synapse generic worker can handle both federation and client-server API endpoints.
# We wish to split these, as we normally serve federation separately and don't want them mixed up.
#
# This is some ugly Ansible/Jinja2 hack (seen here: https://stackoverflow.com/a/47831492),
Whitelist /_matrix/key requests for going to generic workers on the federation port
2021-01-25 09:31:52 +02:00
# which takes a list of various strings and removes the ones NOT containing `/_matrix/federation` or `/_matrix/key` anywhere in them.
matrix_synapse_workers_generic_worker_federation_endpoints: "{{ matrix_synapse_workers_generic_worker_endpoints|default([]) | map('regex_search', '.*(/_matrix/federation|/_matrix/key).*')| list | difference([none]) }}"
Reference in New Issue Copy Permalink