6b4b7647e fixed this for synapse-usage-exporter only. A checkout owned by
a different user makes the git task fail from then on, either with a
permission error or with git's dubious-ownership protection, until
someone removes the directory on the host by hand. It gets into that
state when the matrix user's uid changes (a server migration or a restore
onto a differently numbered user), when an earlier clone ran as another
user, or when someone runs git as root inside the checkout.

Every other role cloning a repository onto the server was open to the
same failure, so ensure the checkout's ownership recursively before
updating it at the remaining 54 sites.

The three matrix-synapse ext clones also gain force=yes. They were the
only on-server clones without it, which left a checkout that an
interrupted run had half-written wedged, instead of repaired on the next
run.

matrix-matrixto used to clone as root into a directory that nothing ever
chowned, unlike every other role. It now becomes the matrix user too.

The Element Web and SchildiChat Web theme checkouts live on the Ansible
controller, where correcting ownership is not ours to do, so they merely
mark the checkout as a safe directory for git.

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

The recursive chown in front of the git task already guarantees that git
operates on a checkout owned by the user it becomes, so marking the path
as a safe.directory on top of that protects against nothing. Drop the
environment variables and condense the comment to a single line.

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

The template was missing the public_media and direct_media sections, as
well as the bridge.phone_numbers_in_profile, bridge.relay.displayname_format
and backfill.threads.max_initial_messages settings.

Their absence made the bridge fall back to zero values instead of the
defaults that upstream ships (most notably disabling thread backfilling).
The template now matches the configuration that the bridge generates
itself, key for key.

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

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

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

The variable was defined, but the configuration template hardcoded the
command prefix, so changing the variable had no effect.

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

The variable was defined, but the configuration template hardcoded the
command prefix, so changing the variable had no effect.

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

The variable was defined, but the configuration template hardcoded the
command prefix, so changing the variable had no effect.

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

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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>

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>