lk-jwt-service v0.6.0 stopped honoring the delay_cs_api_url request parameter
and now locates a user's Client-Server API by fetching the
/.well-known/matrix/client file of that user's base domain itself.
For our own homeserver, this makes the service leave the server over the
public network only to come back to it, which is wasteful at best and does
not work at all where the base domain is not reachable from the host.
Since we know where our homeserver is, we tell the service directly via the
new LIVEKIT_CS_API_URL_OVERRIDES environment variable. Federated homeservers
keep being resolved through discovery.
The service now also joins the container network that the homeserver's
Client-Server API is reachable on, like our other add-on services do.
It used to only be connected to it by coincidence, via the reverse-proxy
network, which left it unable to reach the homeserver when the playbook is
not managing Traefik.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The org.matrix.msc4143.rtc_foci property has been dropped from MSC4143 and
Element Call v0.24.0 no longer reads it, so the homeserver's own RTC
transports API is left as the single source of truth. Synapse, continuwuity
and tuwunel all serve it at the unstable path which clients request.
Keeping both around also made Element Web list the same LiveKit transport
twice, as it merges the two sources without deduplicating them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The RTC transports API was enabled based on matrix_rtc_enabled, while the
transports it serves were populated based on matrix_livekit_jwt_service_enabled.
Enabling the LiveKit JWT service on its own (say, when pointing it at an
externally hosted LiveKit server) therefore configured a transport but left
the API which announces it switched off.
Gating the feature on matrix_synapse_matrix_rtc_transports instead keeps the
API and its payload in sync, and makes the empty-transports case that the
variable's own documentation warns about unreachable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The homeserver only reads appservice registrations on startup, and the
playbook only restarts it at the very end of a run. On the run which
first enables Meowlnir, bot provisioning therefore talked to a
homeserver still running without Meowlnir's registration, hitting
M_UNKNOWN_TOKEN and hanging indefinitely.
Provisioning now verifies the token upfront and restarts the homeserver
itself when needed, so a single run completes even when Meowlnir was
just enabled.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Enabling the MSC4143 experimental feature without configuring any transports makes Synapse serve an empty response on the RTC transports API. Clients treat that response as authoritative and do not fall back to the org.matrix.msc4143.rtc_foci property in the client well-known, breaking Element Call with a MISSING_MATRIX_RTC_TRANSPORT error.
This makes the playbook wire the LiveKit JWT service URL into the new matrix_rtc.transports Synapse setting, matching what continuwuity, tuwunel and the client well-known already advertise.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5522
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hookshot's end-to-bridge encryption needs MSC2409 and MSC3202 enabled
on the homeserver, but the playbook only turned them on for Meowlnir.
Hookshot's encryption defaults to the playbook-wide
`matrix_bridges_encryption_enabled` toggle, so turning that on gave
Hookshot encryption against a Synapse which was not set up for it, and
Hookshot then struggled in encrypted rooms.
The playbook already wires up Hookshot's other encryption prerequisite
(Valkey) and fails the run when the Redis settings are missing, so
being only half-automatic here was the odd one out.
Synapse sends the extra data only to appservices which ask for it in
their registration file, so turning these on affects no other
component.
The documentation told Hookshot users to set the two Synapse variables
by hand, and argued they should be enabled deliberately. That
contradicted what we already do for Meowlnir, so it is gone; the note
now matches the Meowlnir one and points out that other homeserver
implementations still need arranging by hand.
Closes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5506
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Visiting the homeserver's root path used to redirect to Element Web,
but only when Element Web was the client the playbook installed. People
running Cinny, Commet, FluffyChat, Hydrogen, SchildiChat or Sable landed
on a bare homeserver page instead.
The wiring now builds matrix_playbook_public_client_urls — the public
URLs of every playbook-managed web client which is enabled, ordered by
preference — and redirects to the first of them. Element Web stays
first, so existing setups redirect exactly where they did before.
The URL is computed once and shared by all five homeserver
implementations, which each carried their own copy of the old
Element-Web-only expression. It honours each client's own scheme,
hostname and path prefix, so a client served under a subpath now gets
linked correctly.
Supersedes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/5513
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Commet role was the only playbook-installed web client without a
`_scheme` variable to go with its `_hostname` and `_path_prefix`, so
anything wishing to build Commet's public URL had to reach for
`matrix_playbook_ssl_enabled` itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Meowlnir (https://github.com/maunium/meowlnir) is a Matrix moderation
bot which speaks the same policy-list protocol as Mjolnir and Draupnir,
but runs as an appservice and can override individual policies coming
from ban lists you do not control.
Bots and their management rooms live only in Meowlnir's own database —
nothing in its configuration file can declare one — so the role
provisions them through the management API from a declarative roster
(matrix_bot_meowlnir_bots_custom), applied under the
ensure-matrix-users-created tag. Management rooms may be declared or
created for you; bots and rooms no longer declared get pruned.
Wrapper scripts for driving the management API by hand are installed
to /matrix/meowlnir/bin.
Meowlnir re-runs its configuration upgrader in memory on every start,
so a literal `generate` value yields a new secret per restart. All
secrets are therefore rendered explicitly, validation rejects
`generate`, and the configuration directory is mounted read-only.
Draupnir and Meowlnir both want synapse-http-antispam, which the
playbook wires up to a single consumer. The wiring prefers Draupnir,
and both roles fail the run when each claims it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Jitsi migrated image publishing from Docker Hub to the GitHub Container
Registry, and the new registry carries no tag history, so this also moves
Jitsi to stable-11146-1. That release makes the containers rootless and runs
them with a read-only root filesystem.
`jitsi_jvb_container_colibri_ws_host_bind_port` goes away with it. Colibri
WebSocket support was removed upstream in favour of SCTP data channels, so
the Jitsi Video Bridge no longer serves HTTP at all and needs no
reverse-proxy routing.
The metrics endpoint was the only thing this bridge ever routed through
Traefik. With it gone, the container was still labeled `traefik.enable=true`
without defining any router, which makes Traefik fall back to its default
rule and produce a router pointing at nothing. It was also joining the
reverse-proxy network for no reason.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487
The playbook exposes service metrics under a single endpoint
(`https://matrix.example.com/metrics/*`), controlled by
`matrix_metrics_exposure_enabled` and friends. synapse-usage-exporter was
not wired into this at all, so its metrics could only be scraped by the
integrated Prometheus and were unreachable for an external one.
The role had no metrics router whatsoever. Its only Traefik router (for
the `/report-usage-stats/push` ingestion endpoint) was gated on
`matrix_synapse_usage_exporter_container_labels_traefik_enabled`, which
defaulted to `matrix_synapse_usage_exporter_proxying_enabled`. Adding a
metrics router under that same switch would have meant that exposing
metrics also publishes the ingestion endpoint, so the master switch now
defaults to `true` and each router carries its own conditional.
Despite its generic name, `matrix_synapse_usage_exporter_proxying_enabled`
only ever concerned the endpoint that Synapse pushes usage statistics
**to**, never the metrics endpoint that Prometheus reads **from**. The
documentation now says so explicitly.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5467
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
The playbook exposes service metrics under a single endpoint
(`https://matrix.example.com/metrics/*`), controlled by
`matrix_metrics_exposure_enabled` and friends. ntfy was not wired into
this at all, so enabling metrics exposure did not expose ntfy's metrics
and enabling Basic Authentication did not protect them.
We have ntfy serve its metrics on a dedicated port, instead of on its
regular HTTP port. Serving them on the regular HTTP port also makes them
reachable at `https://ntfy.example.com/metrics`, where nothing protects
them, as ntfy does not apply its own access-control rules to the metrics
endpoint.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5468
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>
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.
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>
Slavi Pantaleev
jasonlaguidice
Aine
Co van Leeuwen
Benjamin Blacher
Jason Volk