Until now, ntfy metrics could only be collected by an external Prometheus
server. Enabling the integrated Prometheus (`prometheus_enabled: true`)
now also has it scrape ntfy, like it does for the other services.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Since the introduction of the synapse-usage-exporter role (55f869254, #3442), group_vars/matrix_servers was overriding matrix_synapse_report_stats_endpoint with an empty string whenever synapse-usage-exporter was disabled, clobbering the role's matrix.org default.
For deployments that enable matrix_synapse_report_stats, Synapse would then try reporting statistics to an empty URL, failing with:
> synapse.app.homeserver - 210 - WARNING - phone_stats_home-0 - Error reporting stats: Invalid URI b''
The default endpoint URL now lives in a dedicated matrix_synapse_report_stats_endpoint_default variable, which group_vars/matrix_servers falls back to when synapse-usage-exporter is not enabled.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
None of these flags exist in current Synapse:
- msc3266_enabled: MSC3266 support was stabilized in Synapse v1.153.0 and the room summary API is now always enabled
- msc4140_enabled: this was never a Synapse configuration setting in any released version. Delayed events have always been controlled by the `max_event_delay_duration` setting, which the playbook was emitting alongside the flag. The toggle is now named `matrix_synapse_delayed_events_enabled`.
- msc4429_enabled: MSC4429 support has not landed in any released Synapse version, so this flag never had any effect
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
When no experimental features were enabled (e.g. Matrix RTC and Matrix Authentication Service both disabled), the generated homeserver.yaml contained `experimental_features: null`, which Synapse v1.157.0+ does not tolerate and crashes on startup.
The `experimental_features` configuration is now constructed via a dedicated `matrix_synapse_experimental_features` variable (split into `_default`, `_auto` and `_custom`, as is customary), which always yields a mapping (potentially an empty one).
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5455
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The /_tuwunel namespace carries Tuwunel's ad-hoc routes (server_version,
local_user_count) and its native OpenID Connect provider endpoints
(/_tuwunel/oidc/...), which a reverse proxy must route for OIDC login
to work. Add public (enabled by default, like the client API) and
internal Traefik label groups.
Tuwunel serves the Synapse administration API under /_synapse/admin,
but the role only routed /_matrix, so admin dashboards and moderation
bots could not reach it. Add public and internal Traefik label groups
mirroring the matrix-synapse role, and enable them automatically when
Ketesa, Element Admin, or Draupnir is installed.
A single prefix-level catch in matrix_playbook_migration covers all
renamed bridge variable prefixes at once. It always runs (unlike the
per-role validate_config tasks, which only run when a role is enabled),
so a stale old-style _enabled variable cannot silently disable a bridge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Renames the matrix_mautrix_SERVICENAME_* placeholders in the common
mautrix bridges guide to matrix_bridge_mautrix_SERVICENAME_*, and fixes
prose in the matrix-bridge-steam role that referred to the old variable
prefix and to a misspelled (underscore-styled) systemd service name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
