The make-shared task previously ran on every play with changed_when: false,
which always reported "ok" even when it had just mutated mount propagation.
Check /proc/self/mountinfo for the shared tag first and run mount --make-shared
only when the volume is not already shared, reporting changed accurately.
Detection is fail-safe: grep exits non-zero on no-match or any error, so the
mount is skipped only when shared propagation is positively confirmed. Every
other case falls through to running the (idempotent) command, so behavior
cannot regress relative to running it unconditionally.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace the hardcoded /volume1 path with a matrix_base_synology_volume_path
variable (defaulting to /volume1), used both by the setup-time prerequisites
task and by the boot-fix recovery script. This keeps the path consistent with
the rest of the configuration and lets users on a non-default Docker storage
volume override it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ansible.builtin.mount does not support changing mount propagation,
so command is suppressed with noqa rather than replaced with the module.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add detect_platform.yml with a single `matrix_base_host_is_synology`
boolean (null = autodetect, true/false = force); all Synology gates now
use this variable instead of reaching into the raw stat result
- Make recursive chown conditional: stat the data path before any changes
and only run `chown -R` (native binary, not Ansible file recurse) when
uid/gid actually differs from expected
- Expose `matrix_base_synology_requests_version_constraint` so the
requests<2.32 pin can be bumped without a code change
- Replace Python GID lookup with `synogroup --get` + regex_search,
dropping the python3 dependency for that step
- Require `matrix_synology_user_password` (non-empty) and create the
service account with expired=1 so it cannot be used to log in to DSM
- Apply `mount --make-shared /volume1` during setup so the first run
no longer requires a manual step before starting services
- Use `devture_systemd_docker_base_host_command_docker` and
`devture_systemd_docker_base_host_command_systemctl` in the boot-fix
script instead of hardcoded paths
- Boot-fix now also restarts matrix-*.service units in `failed` state,
not only `inactive`
- Update docs to reflect all of the above
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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>
Prevents Renovate from proposing "major" updates to the registry-only
calver tags (vYY.MM[.PATCH]), which break further updates and
self-building. See the previous commit for details.
Co-Authored-By: Claude Fable 5 <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>
matrix_livekit_jwt_service_container_repo_version interpolated
livekit_server_version (the LiveKit Server role's version) instead of
this role's own matrix_livekit_jwt_service_version, so self-builds
checked out the wrong git tag.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>