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>
Tuwunel is a Matrix homeserver maintained by the matrix-construct
organisation. See https://matrix-construct.github.io/tuwunel/.
The rendered TOML emits only keys exposed as Ansible variables; the
rest fall back to tuwunel's upstream defaults. Anything not surfaced
can be set via the TUWUNEL_* env extension or by overriding the
template path.
Popular features Tuwunel adds variables for:
- OAuth2/OIDC identity providers (a list of `[[global.identity_provider]]`
blocks; brand-aware defaults for Google, GitHub, Keycloak, MAS, etc)
- LDAP and JWT authentication
- Media storage providers (native local and S3 with multipart upload)
- RocksDB tuning (compression, direct_io, parallelism, online backups)
- Native TLS dual-protocol mode
- Blurhashing, Sentry crash reporting
Auto-wired from existing playbook globals: well-known client URL,
TURN/coturn, MatrixRTC LiveKit URL, federation.
The `tuwunel-migrate-from-conduwuit` tag performs a binary-swap
migration. Migration from any other Conduit derivative is unsupported
and would corrupt the database.
Signed-off-by: Jason Volk <jason@zemos.net>
Ketesa needs the MAS admin API exposed to perform MAS-specific
operations (registration tokens, sessions, emails, etc.) when MAS
is in use.
The admin still needs to provision an admin token for Ketesa
manually, but at least the listener resource is now ready by default.
Mirrors the existing Synapse admin API auto-enable pattern.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5164
* Add Matrix <-> Meshtastic bridge (meshtastic-matrix-relay)
Vendors the meshtastic-matrix-relay (mmrelay) role into roles/custom/
following the conventions used by other bridge roles.
Co-authored-by: luschmar <90399580+luschmar@users.noreply.github.com>
* Add docs and CHANGELOG entry for Matrix <-> Meshtastic bridge
Co-authored-by: luschmar <90399580+luschmar@users.noreply.github.com>
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Matches the earlier Python -> Go rewrites of the other mautrix-* bridges.
Related to:
- https://github.com/mautrix/telegram/releases/tag/v0.2604.0
- https://mau.fi/blog/2026-04-mautrix-release/
The bridge is now a Go binary with upstream-handled automatic database and
config migration on first start, so in-place upgrades on Postgres should
Just Work for users on the defaults. The lottieconverter sidecar container
is gone (bundled upstream), and the public web-based login endpoint is
gone (login happens inside Matrix now).
Upstream v0.2604.0 has a known bug in the legacy SQLite migration that
can corrupt data. The role detects legacy Python-bridge SQLite databases
(via the `telethon_sessions` table signature) and refuses to upgrade,
pointing users to switch to Postgres (playbook-managed pgloader migration)
or wait for the next upstream release. The guard is isolated in its own
`validate_config_sqlite_legacy_migration_bug.yml` so it can be deleted
cleanly once upstream fixes the bug.
Removed variables (all caught by the deprecation check in
`validate_config.yml` with actionable rename/removal hints): the entire
`_hostname` / `_path_prefix` / `_scheme` / `_public_endpoint` /
`_appservice_public_*` / `_container_labels_public_endpoint_*` /
`_container_http_host_bind_port` family (web login endpoint is gone);
`_bot_token` (old-style relaybot is gone, use the common bridgev2 relay
mode); `_filter_mode` (dropped upstream); `_bridge_login_shared_secret_map*`
(use Appservice Double Puppet); `_username_template`, `_alias_template`,
`_displayname_template` (templates moved under `network:`, new Go-template
syntax, exposed via `_network_displayname_template`); all
`_lottieconverter_*` variables; `_appservice_database` (renamed to
`_appservice_database_uri`).
Added playbook-time validation that catches legacy permission values
(`relaybot`, `puppeting`, `full`) in the fully-merged config (so overrides
via `matrix_mautrix_telegram_configuration_extension_yaml` are caught too),
with a mapping hint in the error message.
Other notes:
- The legacy sqlite->postgres relocation of `{base_path}/mautrix-telegram.db`
to `{data_path}/mautrix-telegram.db` now happens BEFORE the pgloader
migration step, so users who flip to Postgres as part of this upgrade
get their data imported correctly.
- The Ketesa managed-user regex for the telegram namespace is updated to
match both regular IDs and the new `channel-<id>` form used by bridgev2.
- `matrix_playbook_migration_expected_version` bumped to v2026.04.24.0,
with a new breaking-change entry pointing at the CHANGELOG section.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Register env, database config, scripts, and systemd service/timer results,
compute matrix_synapse_s3_storage_provider_restart_necessary, and wire it
into group_vars/matrix_servers instead of hardcoding restart_necessary: true.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Register image pull, env, and systemd service results, compute
matrix_goofys_restart_necessary, and wire it into group_vars/matrix_servers
instead of hardcoding restart_necessary: true.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace hardcoded restart_necessary: true with the computed
backup_borg_restart_necessary variable that the role already exposes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace hardcoded restart_necessary: true with the computed variables
(jitsi_web_restart_necessary, jitsi_prosody_restart_necessary,
jitsi_jicofo_restart_necessary, jitsi_jvb_restart_necessary) that the
jitsi role already exposes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace hardcoded restart_necessary: true with computed values for:
conduit, continuwuity, dendrite, element-call, media-repo,
appservice-kakaotalk, and wechat.
Each role now registers results from config, support files, systemd service,
and docker image pull tasks, then computes a restart_necessary variable
from their combined .changed state. group_vars/matrix_servers is updated
to reference these variables instead of hardcoding true.
For dendrite, the systemd service template was also separated out of the
combined support-files with_items loop so it can be independently tracked.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MAS now connects to the playbook-managed Postgres via a UNIX socket by
default (when available), matching the approach already used by Synapse.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
syn2mas reads Synapse's homeserver.yaml and reuses the database
connection details from there.
When Synapse is configured to reach the integrated Postgres over a UNIX socket,
the temporary syn2mas container was given the config file but not the socket mount,
so migrations could fail even though Synapse itself was configured correctly.
Wire the Synapse socket settings into MAS via playbook vars and mount
the same socket path into the syn2mas container, so migrations work in
socket-based deployments without coupling the MAS role directly to
Synapse role variables.
Slavi Pantaleev
Suguru Hirahara
Jason LaGuidice
Suguru Hirahara
Jason Volk
luschmar
Aine
DrKnees
Jakob S.
Aine