The configuration template only rendered a datastore when its for_kinds
list was non-empty, even though the inline documentation (matching
upstream's) describes forKinds: [] as the way to make a datastore
readonly. That made the documented migration scenario impossible: moving
media between the file and s3 datastores while keeping the old one
readable.
Introduce matrix_media_repo_datastore_file_enabled and
matrix_media_repo_datastore_s3_enabled, which default to the previous
kinds-based behavior. A readonly datastore is now expressed by enabling
the datastore explicitly while assigning it no kinds.
Fixes#4303
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
synapse-usage-exporter is self-built by default (no upstream image is
published), so every user enabling it runs the git clone/update task. A
docker-src checkout whose files are owned by a different user (e.g. left
behind by an earlier clone) made that task fail: either with a
permission error, or with git's dubious-ownership protection, which
ignores the repository's own configuration and surfaces as a confusing
"'origin' does not appear to be a git repository" error.
Ensure the checkout's ownership recursively before updating it, and mark
the path as a safe.directory for the git invocation itself (via
GIT_CONFIG_* environment variables), so the ownership check cannot
misfire regardless of which user git effectively runs as.
Fixes#5065
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The user-namespace regexes in the mautrix-meta-messenger and
mautrix-meta-instagram registration templates interpolated
the bridge username prefix without regex-escaping it, unlike the
neighboring homeserver domain and appservice username values. The
default prefixes are regex-safe, but a customized prefix containing
regex metacharacters would produce a wrong (too broad or invalid)
appservice user namespace.
Related to the registration regex discussion in #5096.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The playbook-shipped welcome.html hardcoded #2e2f32 for the headline and
welcome text, which is nearly invisible on the dark background Element
renders when the dark theme is active. Element Web's default
use_system_theme behavior keys the theme off the system color scheme, so
switch the text to Element's dark-theme text color (#ebeef2) under a
prefers-color-scheme: dark media query.
Fixes#4838
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
matrix_appservice_discord_container_image_self_build only switched the
image registry prefix to localhost/, but the role never had any build
tasks, so enabling it always ended in an image pull failure. Remove the
variable and reject it in validate_config.yml with a hint that the
prebuilt image is amd64-only and that mautrix-discord is the better
option on other architectures.
Fixes#2379
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The upstream Synapse Grafana dashboard uses `{{job}}-{{index}}` in its
legends to tell workers apart, but the worker scrape configs only set
instance, worker_id, job and app labels. Without an index label, the
dashboard legends collapsed and workers could not be distinguished.
Derive the index label from the worker id (its per-type index is the
first number in the id, e.g. federation-sender-1, stream-writer-2-events),
matching the index label already set on the main process target.
Fixes#2158Fixes#2159
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Element Desktop (Electron) loads the location-sharing map style from a
`vector://vector` origin, so fetching map_style.json from the Element
domain is a cross-origin request. Without an Access-Control-Allow-Origin
header, the request is blocked and maps fail to load with "This homeserver
is not configured correctly to display maps".
Add a dedicated Traefik router for map_style.json that attaches an
Access-Control-Allow-Origin header (configurable via
matrix_client_element_location_sharing_map_style_access_control_allow_origin,
defaulting to `*`). It is only defined when location sharing is enabled.
Fixes#2291
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Attaches a com.centurylinklabs.watchtower.enable=false label to the
matrix-matrixto container by default, telling Watchtower (if in use)
to skip it. The image is built locally from source, so Watchtower
cannot update it and merely produces 'digest retrieval failed' errors
on every run.
A dedicated variable is used (instead of pre-filling
matrix_matrixto_container_labels_additional_labels) so that people
overriding the additional-labels variable do not lose the label.
Fixes#4820
Based on the report and initial patch in
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/4821 by @der-domi
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The sygnal container images (since v0.16.0) hardcode a HEALTHCHECK which
relies on curl, but the image does not include curl, so the healthcheck
can never pass. See https://github.com/element-hq/sygnal/issues/326
This unblocks upgrading sygnal past v0.15.1.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This is a major upgrade which performs a one-way database migration
and removes LDAP support upstream.
The continuwuity.toml.j2 template is re-synced with the v26.6.1 example
config. Notably, registration_token is now only rendered when non-empty,
because v26+ refuses to start when it is set to an empty string.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds optional support for running the playbook on Synology DSM 7+, detected
automatically via /etc/synoinfo.conf so that non-Synology hosts are unaffected.
Includes DSM-native user/group management (synouser/synogroup), a requests
version constraint for Docker SDK compatibility, and a boot-fix service that
re-shares the volume mount and starts matrix services skipped by DSM's boot
ordering. The shared-mount volume path is configurable via
matrix_base_synology_volume_path, and the make-shared step only runs when the
volume is not already shared.
Co-authored-by: CKSit <sitchiuki@gmail.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The bridgev2 (Go) rewrite removed matrix_mautrix_telegram_scheme (the old
Python bridge's public web-login endpoint scheme) and added a deprecation
check for it. We later reintroduced a variable of the same name to configure
the bridge's HTTP API exposure address, but the deprecation entry remained.
Because the check matches any defined variable (via ansible.builtin.varnames),
not just user-set ones, it tripped for every install with the Telegram bridge
enabled, even when the user never set it.
Drop the deprecation entry, since the variable is a current one again. The
related (still removed) matrix_mautrix_telegram_hostname and
matrix_mautrix_telegram_path_prefix entries are kept.
Closes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5368
Regression since d2252db4fe
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Emit a /.well-known/matrix/mautrix file listing the base URLs of all
enabled and exposed mautrix bridges under the `fi.mau.bridges` property,
so tools like Mautrix Manager (https://github.com/mautrix/manager) can
auto-discover them.
The list is built in group_vars from each bridge's public address and is
gated on the bridge being enabled, the playbook attaching its Traefik
labels, and the exposure router being emitted, so we only advertise URLs
that are actually reachable. The file follows the same auto/custom and
configuration-extension pattern as the other well-known files and is only
written when the list is non-empty.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Unlike the other mautrix bridges, the mautrix-slack role had no Traefik
label infrastructure at all, so this builds the scaffold first (a new
labels.j2, the container_labels_traefik_* vars, the label-file wiring in
the systemd service and setup_install.yml, and the group_vars wiring),
then exposes the bridge's appservice HTTP API under
https://matrix.<domain>/bridges/slack like the other bridges.
The provisioning shared secret was already auto-generated.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Auto-generate the provisioning shared secret (to enable the provisioning
API), route the whole bridge HTTP port via Traefik under
`<matrix-fqn>/bridges/meta-messenger`, and populate
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The labels template gate is widened so the exposure router is
emitted even when metrics are disabled (the exposure router reuses the
existing appservice Traefik service on port 29319).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Auto-generate the provisioning shared secret (to enable the provisioning
API), route the whole bridge HTTP port via Traefik under
`<matrix-fqn>/bridges/meta-instagram`, and populate
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The labels template gate is widened so the exposure router is
emitted even when metrics are disabled (the exposure router reuses the
existing appservice Traefik service on port 29319).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Auto-generate the provisioning shared secret (to enable the provisioning
API), route the whole mautrix-whatsapp HTTP port via Traefik under
`<matrix-fqn>/bridges/whatsapp`, and populate appservice.public_address,
reusing the matrix_bridges_exposure_* mechanism.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-bluesky HTTP port via Traefik under
`<matrix-fqn>/bridges/bluesky` and populate the existing
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The provisioning shared secret is already auto-generated in
group_vars, so the provisioning API is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-twitter HTTP port via Traefik under
`<matrix-fqn>/bridges/twitter` and populate the existing
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The provisioning shared secret is already auto-generated in
group_vars, so the provisioning API is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-signal HTTP port via Traefik under
`<matrix-fqn>/bridges/signal` and populate appservice.public_address,
reusing the matrix_bridges_exposure_* mechanism. The provisioning shared
secret is already auto-generated in group_vars, so the provisioning API
is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-telegram HTTP port via Traefik under
`<matrix-fqn>/bridges/telegram` and populate appservice.public_address,
reusing the matrix_bridges_exposure_* mechanism. The provisioning shared
secret is already auto-generated in group_vars, so the provisioning API
is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a generic mechanism for exposing bridges' HTTP API (the provisioning
API, etc.) publicly on the Matrix domain, so tools like mautrix-manager
(https://github.com/mautrix/manager) can drive bridge login.
- Introduce global matrix_bridges_exposure_* vars (on by default),
exposing each supported bridge under `<matrix-fqn>/bridges/<bridge>`.
- mautrix-gmessages: make the provisioning shared secret configurable
(auto-generated in group_vars) so the provisioning API is enabled,
route the whole bridge HTTP port via Traefik, and populate
appservice.public_address.
Requests are authenticated by the bridge itself (per-user Matrix access
token for the provisioning API, homeserver token for the appservice
endpoints), not by the reverse proxy.
This is the first bridge converted; the other mautrix bridges will follow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
As of tuwunel v1.8.0, the ip_range_denylist applies to push gateway
delivery as well, so surface it as an Ansible variable using the
default/auto/custom merge pattern. The default mirrors tuwunel's own
upstream denylist (RFC1918, loopback, multicast, and other unroutable
ranges), matching the identical list already used for Synapse's
matrix_synapse_url_preview_ip_range_blacklist.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The role shipped its own copy of the bridge's Dockerfile and templated it
over the cloned source before building. That copy had already drifted from
upstream (e.g. missing libheif-plugin-libde265) and required separate
maintenance (Renovate bumping the base image here instead of upstream).
Build from the cloned repo's own Dockerfile instead, matching every other
self-build role (e.g. matrix-bridge-steam). The Dockerfile now tracks the
pinned bridge version automatically.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add the matrix-rustpush-bridge role, a Matrix <-> iMessage bridge built
on the mautrix-go bridgev2 framework using RustPush (OpenBubbles backend).
Unlike the existing mautrix-imessage/wsproxy bridge, it talks directly to
Apple's push notification service, so it needs neither a running Mac nor a
wsproxy on the homeserver. Each user supplies a hardware key extracted from a
Mac through the bridge bot's login flow.
The bridge uses its own bot username and puppet namespace (rustpushbot,
rustpush_*) so it does not collide with the wsproxy iMessage bridge.
This bridge is in early development and may have stability issues.
Slavi Pantaleev
renovate[bot]
Suguru Hirahara
krassle
cksit
Aine
Jason LaGuidice
Hollie Hutchinson