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 new version supports defining a multiplexed UDP port pool (e.g.
'7882-7892') in livekit_server_config_rtc_udp_port. Previously, the
role's configuration template silently mangled such values into
udp_port: 0. It also gains early validation of the port value.
Related to #5344
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The CDN section of the federation documentation tells users to set
matrix_synapse_federation_port_enabled: false, which only works because
that recipe moves federation traffic to the client port. Followed
partially (keeping federation on the dedicated federation port behind a
fronting reverse proxy), the same line removes the federation route
entirely and breaks federation. Say so explicitly.
Fixes#4475
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>
The new version adds livekit_server_config_rtc_ips_includes and
livekit_server_config_rtc_ips_excludes variables, controlling LiveKit's
rtc.ips.includes/excludes CIDR filters for RTC IP addresses.
Related to #4958
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Matrix Authentication Service supports CAPTCHA protection (ReCaptcha
v2, Cloudflare Turnstile, hCaptcha) for certain operations like
self-service password registration, but configuring it required going
through matrix_authentication_service_configuration_extension_yaml.
Expose it via dedicated variables
(matrix_authentication_service_config_captcha_service, _site_key and
_secret_key), validate the service value and key presence, and document
the setup in the captcha documentation page, which so far only covered
Synapse and Dendrite.
Related to #5344
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Enabling matrix_hookshot_encryption_enabled configures the bridge side
correctly (registration flags, Valkey cache), but hookshot's encryption
also needs the homeserver to support and enable MSC2409 and MSC3202,
which are typically experimental features disabled by default. Nothing
documented that, so the resulting setup silently did not work.
Reference the MSCs in the variable's comment, and show the exact Synapse
settings in the hookshot documentation page. The playbook deliberately
does not auto-enable them: they are experimental homeserver-wide
features, and flipping them from a bridge toggle would be surprising.
Fixes#3861
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>
The autotuning defaults are derived from total system RAM, but every
Synapse process (the main one and each worker) applies the configured
limits independently, so worker setups multiply the theoretical
aggregate cache memory usage.
Fixes#3336
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add the two remaining hints from the official Synapse backup guide:
- never import a dump into a database that already has tables present
(at best it errors, at worst it causes subtle inconsistencies)
- when restoring a backup older than the server's current state,
truncate e2e_one_time_keys_json before starting Synapse, so used
one-time keys are not re-issued (which causes decryption errors);
our pg_dumpall-based backup commands include that table
Fixes#4004
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Slavi Pantaleev
renovate[bot]
Kristoffer
jasonlaguidice
Aine