prek bakes the full path of the currently installed version into the hooks it
generates (var/mise/installs/prek/<version>/...). That path stops existing as
soon as the pinned version changes or old versions are pruned, and the hook's
PATH fallback finds no prek either, so every commit fails until the hook is
regenerated by hand. It also means a hook keeps running the version it was
generated with, long after mise.toml has moved on.
Rewriting PREK to mise's shim makes the hook resolve whatever mise.toml pins at
the time it runs. The accompanying MISE_DATA_DIR / MISE_TRUSTED_CONFIG_PATHS
exports keep that resolution inside this project - without them mise falls back
to the global data directory and silently installs a second copy of the tool.
The patch loop now covers every hook file prek generated rather than just
pre-commit, since default_install_hook_types decides which ones exist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every dependency bump in the housekeeping list was already automerging,
but as a pull request - which meant an email and an open PR for every
bump even when it merged itself. Branch-push automerge makes green bumps
invisible; a failing one still surfaces as a pull request. The new
Matrix i18n workflow gates the i18n/requirements.txt ones with a real
exercise of the translation toolchain.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhJbmhyUpt4qSrKD9cbJ5A
Nothing used to test an i18n/requirements.txt bump - the first real
exercise of a bumped Sphinx/Babel stack was the next scheduled
translations run, well after merging. Template extraction runs the same
toolchain the scheduled workflow uses, in a minute or two, so a broken
bump now fails on its branch instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhJbmhyUpt4qSrKD9cbJ5A
The seven pinned com.devture.ansible.role.* roles are maintained by the
same people who review these PRs; their releases are already the review.
Same branch-push automerge (and the same lint gate) as MASH role bumps.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhJbmhyUpt4qSrKD9cbJ5A
Same rule mash-playbook has been running in production: role bumps from
mother-of-all-self-hosting merge via branch push (no PR) once the branch's
CI checks pass. The trust basis is the role repositories' own gates - each
release is cut by Molecule-verified, autotagged merges over there.
Bumps of devture roles and everything else keep their PRs. Extending the
same treatment to devture roles (here and in mash-playbook) is a discussed
follow-up.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhJbmhyUpt4qSrKD9cbJ5A
The previous image versions set ANSIBLE_WORKER_SESSION_ISOLATION=False in an
attempt to restore SSH prompts on Ansible 2.21. That setting does not bring
the prompts back — it makes Ansible hang silently at the first SSH connection
whenever a prompt would have been needed. See
https://github.com/devture/docker-ansible/issues/6
The new image auto-accepts the SSH host keys of previously unknown hosts
instead. The docs stop recommending ANSIBLE_WORKER_SESSION_ISOLATION=False
for direct (non-Docker) runs for the same reason, and now explain how to use
an ssh-agent for passphrase-protected SSH keys.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Protected rooms, watched policy lists, protection settings and the set of
users allowed to command a bot all belong to a management room rather than
to the bot, and a room can be protected from only one of them. That is what
makes it possible to delegate a single room to another moderator without
handing over power in every other protected room, so it is worth spelling
out, along with what such a split does not cover: the variables naming one
management room, and policy lists shared through subscriptions.
Adding a second management room also means declaring the rooms of a bot
which had been auto-creating its own, which is a step with a sharp edge:
once the bot is no longer auto-creating, any of its rooms missing from the
declaration is unregistered. Document that path and warn about it.
Also drop a note describing "!lists subscribe --insert-before" as a future
release. The role has shipped a version carrying it since v0.2608.0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This reverts commit 421b592690.
The org.matrix.msc4143.rtc_foci property is indeed gone from MSC4143 and
Element Call v0.24.0 no longer reads it, but Element Web does not ship that
version of Element Call yet. v1.12.26 embeds Element Call v0.22.0, which
discovers transports through the well-known property.
That embedded copy cannot consult the homeserver's RTC transports API
instead: it runs as a widget, a widget holds no access token and the API
requires authentication, so its own discovery code skips the API branch
outright. Newer Element Call versions ask their host client over the widget
API (MSC4515) and Element Web already implements that side of it, but the
widget has to speak it too.
Dropping the property therefore left Element Web and Element Desktop users
with MISSING_MATRIX_RTC_TRANSPORT when starting a call.
The restored variables carry a comment about why the property stays, and the
changelog entry is rewritten to announce the revert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
lk-jwt-service v0.6.0 ships a healthcheck which builds its URL as
http://localhost:$LIVEKIT_JWT_BIND/healthz, interpolating the bind
address into the port slot. We set LIVEKIT_JWT_BIND to ":8080", so the
check requests http://localhost::8080/healthz, which does not parse and
can never succeed. The container therefore sits permanently unhealthy,
Traefik skips unhealthy containers, and the service stops being routed,
so Element Call fails to obtain an SFU token.
No value satisfies both sides: the service passes LIVEKIT_JWT_BIND to
ListenAndServe, which needs a full bind address, while the healthcheck
needs a bare port. The check only works when the variable is unset and
its own "8080" fallback applies, which would mean ignoring a configured
port. Correcting the check from here is not possible either, as the
image is built FROM scratch and has no shell for a --health-cmd
override to use.
Turn the healthcheck off, behind a variable so it can be turned back on
once upstream fixes it. This restores the pre-v0.6.0 behavior, where the
image carried no healthcheck at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Failing to update the apt cache now reports why, instead of reporting that
the result of the apt module has no cache_updated attribute.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Tuwunel v1.9.0 adds the default `.im.nheko.msc3664.reply` push rule to every
account, but only evaluates its condition when this option is on. Without it,
replies do not affect notification counts or reach pushers.
Kept off, as upstream has it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tuwunel v1.9.0 removes `[global.ldap] name_attribute` and no longer checks
a secondary attribute for the localpart, so a directory entry must carry it
in `uid_attribute` to allow login.
A leftover key produces no boot warning, so the playbook reports it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This document and docs/configuring-playbook-livekit-jwt-service.md were both
added in 9970603f1 (Add Element Call support), which squashed a branch that
renamed the role along the way (matrix-jwt-service ->
matrix-livekit-jwt-service). The document belonging to the old name survived
the squash, was never linked to from anywhere and was never touched again,
while the other one is the one referenced by the documentation index, the
README and the Matrix RTC and Element Call documents.
Its remaining content is covered elsewhere, and it was the only place telling
people to enable matrix_livekit_jwt_service_enabled by hand.
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>
Unlike the other bots, Meowlnir's ensure-matrix-users-created tasks
may need to restart the homeserver so that it picks up Meowlnir's
appservice registration. That only helps once the homeserver's
configuration has been brought up to date by its own role, so the
meowlnir role must come after it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Asks the homeserver who Meowlnir's appservice token belongs to.
A 401 (M_UNKNOWN_TOKEN) response means the homeserver is running
without Meowlnir's appservice registration, which is the usual cause
of Meowlnir's "Failed to connect to homeserver" log messages.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Without a timeout, a request against an API which accepts connections
but never answers (e.g. Meowlnir stuck retrying against a homeserver
that rejects its appservice token) hangs the playbook forever instead
of failing with a usable error.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Since mautrix-meta v26.07, Instagram is a separate bridge upstream (its own binary, container image and configuration schema). As of v0.2608.0, the bridge no longer has a `mode` configuration option at all, so the premise of auto-generating the Instagram role from the Messenger one (one binary, one schema, a mode switch) is gone.
- Drop the role generator (`bin/rebuild-mautrix-meta-instagram.sh` and the `just rebuild-mautrix-meta-instagram` recipe). The two roles are now maintained independently.
- Drop `matrix_bridge_mautrix_meta_instagram_meta_mode` and all mode-derived lookups from the Instagram role. Computed values are unchanged.
- Sync both config templates with the v0.2608.0 example configs: the Instagram template loses `mode` and gains the Instagram-only options; the Messenger template replaces `mode` with the new `tor` option (still derived from `matrix_bridge_mautrix_meta_messenger_meta_mode: facebook-tor`) and loses the Instagram-only `disable_xma_*` options.
- Fix self-building for the Instagram role: build via `Dockerfile.ig` (producing the actual Instagram binary at `/usr/bin/mautrix-instagram`) instead of the Messenger `Dockerfile`. A new `matrix_bridge_mautrix_meta_instagram_container_binary_path` variable points the systemd service at the right binary for self-built and prebuilt images.
- Rename the systemd service templates to role-specific file names.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5510
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Since mise 2026.6.4 (advisory GHSA-436v-8fw5-4mj8), trust-control settings
(`yes`, `ci`, `trusted_config_paths`, `paranoid`) in non-global configs are
ignored, and every mise invocation prints a warning about this one.
Removing it changes nothing on current mise - the setting was already dead.
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>
The role-constructed foci list now lives in the _default variable, freeing _auto for playbook-level injection, consistent with how other default/auto/custom variable triads work.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Draupnir stores each protection's settings as custom state events in the
management room, which requires a power level of 50 by default. A bot left
at the default power level of 0 cannot save any protection settings.
The failure is silent and has an expensive symptom: the
PolicyChangeNotification protection cannot remember its notifications room,
so it creates a brand new one on every restart of the bot. With the
playbook restarting the bot on every installation run, this litters the
server with abandoned rooms (90 of them observed on one deployment over
6 months).
Zero Touch Deployment is unaffected, since the bot creates and owns the
management room itself.
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>
The `matrix_synapse_experimental_features_msc3202_device_masquerading_enabled`
entry was missing its closing angle bracket, so anyone still setting
that variable was told to rename it to `<removed - this feature is
enabled by default now`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Since v26.07, Instagram is a separate bridge upstream, with its own
binary and its own container image. Both bridges are published to the
same image repository, Instagram's under `ig-`-prefixed tags.
Both roles kept pointing at the unprefixed image, which now carries
only the legacy Instagram code path. That path no longer works against
Instagram's current DM protocol, so mautrix-meta-instagram authenticates
and does its initial sync, then loops on failed MQTT sync tasks and
bridges nothing.
The prefix is derived from `meta_mode`, so it also covers a
mautrix-meta-messenger role run with `meta_mode: instagram`. Renovate
keeps tracking the unprefixed tag for both roles, which is correct:
the two images are built from one git tag.
The self-build checkout took its git ref by parsing the tag out of the
container image reference. That would now ask for a non-existent `ig-`
git tag (upstream has none), and it was already wrong for a commit-hash
pin, where it asked for `HASH-amd64`. It uses `_version` directly now,
like every other role in the playbook does.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5510
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Upstream no longer has an `ig_e2ee` option in either connector. It is
already absent at v0.2607.0, the version both roles are pinned to, so
we have been rendering a dead key into config.yaml for a while.
Anyone who set the variable is told it is gone, via the usual
deprecated-variable check.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The committed role had drifted from what
bin/rebuild-mautrix-meta-instagram.sh produces, by one reordered
`_homeserver_domain` line. No behaviour change; this just makes the
next diff against the role show only intentional changes.
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 `matrix_redis_` -> `redis_` check and the `redis_` -> `valkey_`
check both stored their matches in
`matrix_playbook_migration_redis_migration_vars`.
Facts persist for the whole play, so the second check was silently
overwriting the first one's value. Nothing reads these facts outside the
block that sets them, so this was harmless in practice, but it breaks as
soon as anyone reorders the checks, reads a fact later on, or disables
one of the two checks and expects the other's value to still be around.
Name the second one after its own check, like every other check here
does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four checks carried the task name of the check they were copy-pasted
from, so the redis -> valkey and keydb -> valkey checks both announced
themselves as matrix_redis ones, and both synapse OIDC label checks
announced themselves as matrix_ssl ones.
The matrix_nginx_proxy and matrix_ssl leftover messages also asked
people to rename variables, while the sentence right above them
(correctly) asks for these to be removed. The roles are gone, so there
is nothing to rename them to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The variables holding matched deprecated variable names used to be
dictionaries (built via `vars | dict2items | ... | items2dict`), so
calling `.keys()` on them was correct.
Since a1f6ee4dc9, they are lists produced
by the `ansible.builtin.varnames` lookup, but 15 of the messages
consuming them were left calling `.keys()`.
The failing tasks are gated behind a `| length > 0` condition, so only
people who actually still carry one of these deprecated variables would
hit this. Such people were greeted by a cryptic templating error instead
of the message telling them what to rename or remove.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5491
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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 example only covered `matrix.example.com` and the federation stream,
so people who make the playbook serve the base domain were left without a
proxy host for it. Requests for the `/.well-known/matrix/*` files on the
base domain then never reach Traefik and Nginx Proxy Manager answers with
a 404 error of its own, breaking federation and client discovery.
The nginx example already covers this by listing `example.com` in its
`server_name` directive. Serving the base domain from the Matrix server
is optional though, so the new section says so and points people whose
base domain lives elsewhere to the server delegation documentation.
Also note that a `*.example.com` wildcard certificate does not cover the
base domain itself, which is easy to get wrong when setting this up.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5465
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Logging in does not involve approving a session from the LINE mobile app.
The bridge shows a PIN code, which needs to be entered into the LINE
mobile app instead.
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>
Its upstream repository has been archived and has not seen a change
since March 2025. mautrix-linkedin now covers the same use case.
The bridge remains installable, but as with other deprecated and
unmaintained components, it is no longer listed in the README and has
been moved to the deprecated services section of the documentation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Replaces the question-and-answer troubleshooting format (which no other
documentation page uses) with regular subsections, and clarifies why the
request needs to come from a Chrome-based browser.
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>
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>
The new image restores the ability of SSH to ask about unknown host keys
and to prompt for the passphrase of an SSH key, which Ansible 2.21 broke
by having forked workers run session-isolated.
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>
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>
LiveKit Server configuration validation now requires an explicit choice
between an RTC port range and a multiplexed UDP port, instead of
silently rendering the default udp_port alongside a user-defined port
range (which LiveKit ignores). See the CHANGELOG entry for details.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5344
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Points AI coding agents at the new style guide and summarizes the
repository layout and the conventions that are easy to get wrong
(roles/galaxy being auto-managed, group_vars wiring boundaries,
variable deprecation).
Related to #3631
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codifies the conventions the playbook and its documentation already follow:
language and Markdown style, placeholder values for examples, the structure
of component documentation pages, and the checklist for adding a new
component (including where a component should live: this playbook, an
external MASH role, or mash-playbook).
Fixes#3631
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The exporter's configuration used to ship a leftover "myprefix" placeholder
as the metric name prefix, so the bundled Grafana dashboard (which queries
unprefixed metric names) could never show any data.
Metric names are now unprefixed and the namespace label value changed from
matrix to nginx. See the CHANGELOG entry for details.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3380
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
