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.
Continuwuity has no native enable-captcha toggle; it enables the ReCAPTCHA
registration flow based on the presence of a private site key. The playbook
previously always rendered empty `recaptcha_site_key`/`recaptcha_private_site_key`
values, which made Continuwuity enable a broken captcha flow and break
registration in some clients.
The keys are now only rendered when both are configured, gated by a derived
`matrix_continuwuity_recaptcha_enabled` flag in the role's `vars/main.yml`. A
consistency check fails the play when exactly one of the two keys is set.
Fixes#5329
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mautrix publishes each release under two tag schemes: v0.YYMM.PATCH
(also used for git tags, due to Go's module path requirements for
major versions >= 2) and a calver vYY.MM[.PATCH] scheme that exists
only on the Docker registry.
We switched mautrix-signal to the calver scheme in 3564155a7, which
left it silently stuck at v26.02.2: the calver tags have an
inconsistent number of components (v26.02.2 vs v26.05), and Renovate's
docker versioning only offers updates between tags with the same
number of dot-separated parts. It also broke self-building, which uses
the version as a git ref, and calver tags do not exist in git.
Going back to the v0 scheme (used by all other mautrix bridges) fixes
both problems and upgrades signal from the February release to the
current May one.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The additional-networks connect loop in the kakaotalk systemd unit
template iterated over matrix_appservice_discord_container_additional_networks,
a copy-paste leftover from the discord bridge role. The host-network
guard added in #5310 mirrored the same wrong variable.
This means the kakaotalk container was being connected to the networks
computed for the discord bridge instead of its own, potentially leaving
it without access to its homeserver/database networks depending on the
discord bridge's configuration.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat: support container_network=host across all roles + systemd templates
Mirror the pattern Slavi introduced for matrix-coturn (aafa8f0) across the
fork: every 'Ensure X container network is created' task gets a
'when: <var> not in ["", "host"]' guard so MDAD does not try to
docker_network create a network literally named 'host' (returns 403,
since host is a pre-defined Docker network).
Mirror the same guard in every systemd unit template that does
'ExecStartPre=docker network connect <addnet> <container>' loops over
matrix_<role>_container_additional_networks: skip the connects when the
container is on host networking (where additional --network attaches
are invalid).
Unblocks DiD setups where MDAD-managed containers share their host's
network namespace (matrix-mdad outer compose service joined to central
postgres/openldap networks) to reach external services on the outer
Docker daemon.
* Simplify container network guards (!= 'host') and fix duplicate when
Guarding on the empty string ('') as well was misleading: systemd unit
templates still render an unconditional --network= flag, so an empty
network value produces a broken docker create command. Only 'host' is
actually supported, so only guard on that. This also matches the
existing convention in the Traefik role
(when: traefik_container_network != 'host').
Also fix a duplicate when key in the meshtastic-relay role, where the
network-creation task already had a when condition - the two are now
combined into a list.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
renovate[bot]
Slavi Pantaleev
Aine
Jason LaGuidice
Hollie Hutchinson
Catalan Lover
Bart van der Braak
Kevin Veen-Birkenbach