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>
Slavi Pantaleev
renovate[bot]
github-actions[bot]