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

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

The bridge lost its metrics endpoint when it was rewritten on top of
bridgev2, so the playbook was publishing a Traefik route which could
only ever yield an HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

The bridge does not expose a metrics endpoint, so the playbook was
publishing a Traefik route which could only ever yield an HTTP 502.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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. 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>

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>