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>
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>
Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.
The companion appservice variables defined by this role are folded
under the role prefix as well: matrix_mautrix_androidsms_* becomes
matrix_bridge_mautrix_wsproxy_androidsms_* and matrix_mautrix_imessage_*
becomes matrix_bridge_mautrix_wsproxy_imessage_*.
matrix_mautrix_signal_wsproxy_syncproxy_connection_string becomes
matrix_bridge_mautrix_wsproxy_syncproxy_connection_string, aligning it
with the sibling matrix_bridge_mautrix_wsproxy_syncproxy_* variables.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The new role version splits backup_borg_location_exclude_patterns into
auto/custom components, following the existing split for
backup_borg_location_source_directories. The playbook now wires its
computed values into the _auto variables for both, so users can append
their own entries via the _custom variables instead of redefining the
whole lists and accidentally dropping playbook-provided values.
Previously, redefining backup_borg_location_exclude_patterns dropped
the postgres_data_path exclusion (making borg walk live Postgres data
and fail with warning exit codes), and the playbook's own
source_directories wiring made the role's _custom variable a no-op.
Related to #5092
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
With workers enabled, every Synapse process (the main one and each
worker) maintains its own database connection pool of up to
matrix_synapse_database_cp_max (default: 10) connections. The previous
fixed limit of 500 left little headroom on setups running many workers,
where exhausting it manifests as degraded performance and, reportedly,
E2EE misbehavior.
Size the limit as a 200-connection baseline (for everything else that
talks to Postgres) plus cp_max connections per Synapse process, never
going below the previous value of 500. The stock worker presets stay at
500; setups that raise worker counts (or cp_max) get a limit that grows
accordingly. The new matrix_synapse_workers_total_count variable
reflects what the matrix_synapse_workers_*_count variables ask for; it
does not reflect a manually populated
matrix_synapse_workers_enabled_list, and such setups should override
postgres_max_connections themselves.
Fixes#4442
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The bridge could only be installed by self-building its source code,
and its upstream repository (on src.miscworks.net) has become
unreachable (the Internet Archive last saw it alive in May 2026),
making installation impossible. The bridge was also based on the
long-unmaintained node-kakao library and carried a warning that using
it may get KakaoTalk accounts banned.
The playbook catches leftover matrix_appservice_kakaotalk_* variables
and points users to the manual uninstallation instructions.
Related to #5068
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
etherpad_base_url always ends with a trailing slash, and the playbook
passed it verbatim to jitsi_etherpad_base, which the Jitsi role appends
path segments to (e.g. /p/). The generated Jitsi configuration therefore
contained URLs like https://etherpad.example.com//p/, which can 404
depending on the web server. Strip trailing slashes when wiring.
Fixes#3471
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The new role release splits grafana_dashboard_download_urls into
default/auto/custom components. Wire the playbook's automatic dashboard
list via the auto component, so users can add their own dashboards
through grafana_dashboard_download_urls_custom without clobbering it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Synapse only generates thumbnails of local media at upload time (unless
dynamic_thumbnails is enabled, which the playbook does not do) and no
tooling exists to regenerate them, so restoring a backup left all
previously uploaded local images without thumbnails permanently. The
official Synapse backup guide recommends backing this directory up.
Related to #4004.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The exporter's wal collector (enabled by default) calls pg_ls_waldir(),
which Postgres restricts to superusers and members of the pg_monitor
role. The exporter user is created as a plain managed-database user, so
scraping logged "permission denied for function pg_ls_waldir" on every
run.
Grant pg_monitor via the managed database's additional_sql_queries,
which the Postgres role applies both on initial creation and on
subsequent runs, covering existing installations too.
Fixes#3039
Co-Authored-By: Claude Fable 5 <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>
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.
v0.5.0 makes LIVEKIT_FULL_ACCESS_HOMESERVERS a required setting and
drops the implicit `*` wildcard default upstream.
Split the full-access-homeservers list into _default/_auto/_custom
parts (following the convention used for other variables in this role),
with a sane _default of the homeserver's own domain. This also lets
group_vars/matrix_servers drop its now-redundant override.
Add a validate_config.yml check requiring the setting to be defined.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
These variables were being assigned in group_vars/matrix_servers to
values byte-identical (or functionally identical) to what the
respective role's defaults/main.yml already provides.
Beyond just being noise, such redundant overrides cause drift over
time. When a role's default is later updated to something saner or
better (for example, switched from a hardcoded value to a derivation
from another variable), the matching line in group_vars/matrix_servers
stays frozen at the old value and silently defeats the improvement,
because group_vars beats role defaults in Ansible's precedence order.
The maubot management hostname fix in
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/5248
is an example of this: the role default had been improved to derive
from matrix_bot_maubot_hostname, but the stale group_vars override
held it back to matrix_server_fqn_matrix.
Removing these overrides lets the role defaults do their job.
Closes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/5248
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Slavi Pantaleev
Aine
Suguru Hirahara
Jason LaGuidice
Suguru Hirahara