The `matrix_redis_` -> `redis_` check and the `redis_` -> `valkey_`
check both stored their matches in
`matrix_playbook_migration_redis_migration_vars`.
Facts persist for the whole play, so the second check was silently
overwriting the first one's value. Nothing reads these facts outside the
block that sets them, so this was harmless in practice, but it breaks as
soon as anyone reorders the checks, reads a fact later on, or disables
one of the two checks and expects the other's value to still be around.
Name the second one after its own check, like every other check here
does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four checks carried the task name of the check they were copy-pasted
from, so the redis -> valkey and keydb -> valkey checks both announced
themselves as matrix_redis ones, and both synapse OIDC label checks
announced themselves as matrix_ssl ones.
The matrix_nginx_proxy and matrix_ssl leftover messages also asked
people to rename variables, while the sentence right above them
(correctly) asks for these to be removed. The roles are gone, so there
is nothing to rename them to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The variables holding matched deprecated variable names used to be
dictionaries (built via `vars | dict2items | ... | items2dict`), so
calling `.keys()` on them was correct.
Since a1f6ee4dc9b92fdb520627ec22265b800f73a6f8, they are lists produced
by the `ansible.builtin.varnames` lookup, but 15 of the messages
consuming them were left calling `.keys()`.
The failing tasks are gated behind a `| length > 0` condition, so only
people who actually still carry one of these deprecated variables would
hit this. Such people were greeted by a cryptic templating error instead
of the message telling them what to rename or remove.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5491
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A single prefix-level catch in matrix_playbook_migration covers all
renamed bridge variable prefixes at once. It always runs (unlike the
per-role validate_config tasks, which only run when a role is enabled),
so a stale old-style _enabled variable cannot silently disable a bridge.
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>
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>
LiveKit v1.12.0 tightens TURN security: credentials now carry a TTL,
and TURN no longer relays to restricted peer CIDRs by default. The
role defaults match upstream's secure defaults and are appropriate
for typical playbook deployments.
Bumps the migration-validation gate accordingly so users are pointed
at the CHANGELOG entry on next run.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.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>
* Fetch ansible-role-ddclient from MASH project
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Replace `matrix_dynamic_dns` with `ddclient`
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Set `matrix-dynamic-dns` to `ddclient_identifier`
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Remove `ddclient_container_network` in favor of the role's configuration
On the role the value of `ddclient_container_network` is set to `ddclient_identifier`, which is set to `matrix-dynamic-dns` on the playbook.
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Replace `matrix-dynamic-dns` with `ddclient` on matrix_servers
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Replace `ddclient_docker_image_*` with `ddclient_container_image_*`
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Update `ddclient_container_image_*`
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Move `ddclient_base_path` to matrix_servers
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Move `ddclient_web_*` to matrix_servers
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Remove `matrix-dynamic-dns` directory
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Update configuring-playbook-dynamic-dns.md
Reuse 75e264f538/docs/services/ddclient.md
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
* Fix a typo
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
---------
Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
Co-authored-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>
Slavi Pantaleev
Suguru Hirahara
Suguru Hirahara
Aine
Catalan Lover
Suguru Hirahara