When DB credentials change (derived from matrix_synapse_macaroon_secret_key),
a running Synapse container may fail to connect to its database and stop
serving requests. This causes register_new_matrix_user to fail with
"Connection refused" when the matrix-user-creator role tries to register users.
This extends the retry logic from 44b43a51b (which handled HMAC failures)
to also handle Connection refused errors: restart Synapse (picking up the
new config with updated credentials), wait for it to start, and retry.
Caused by c21a80d232
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When the registration_shared_secret changes (derived from
matrix_synapse_macaroon_secret_key), a running Synapse container still
has the old secret in its config. This causes register_new_matrix_user
to fail with "HMAC incorrect" when the matrix-user-creator role tries
to register users.
This mirrors the approach from 2a581cce (which added similar retry
logic for the Matrix Authentication Service on database auth failure):
if the initial registration attempt fails with an HMAC error, restart
Synapse (picking up the new config with the updated secret), wait for
it to start, and retry.
Caused by c21a80d232
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When the Postgres role updates database passwords (e.g., due to a
change in the secret derivation method), the Matrix Authentication
Service container may still be running with old configuration that
references the previous password. This causes mas-cli to fail with
"password authentication failed" when the matrix-user-creator role
tries to register users.
Rather than adding config-change detection or eager restarts to the
MAS role, this adds targeted retry logic: if the initial registration
attempt fails with a database authentication error, restart the MAS
service (which picks up the new config with the updated password),
wait for it to start, and retry. The restart usually only triggers
once per run since subsequent user registrations succeed after the restart.
Related to c21a80d232
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* continuwuity support
* continuwuity support
* use main instead of commit tag
* fix docker image link
* migration from conduwuit
* fix yaml lint
* backup directories and linter fixes
* linter fixes
This change intends to explain how ensure-matrix-users-created and ensure-users-created are expected to work by default.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This reverts commit 752de4406e.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3393
When running the playbook against an existing server, it invokes `register_new_matrix_user`
as part of the `matrix-user-creator` role, which runs before the
`systemd_service_manager`. At that time, `matrix-user-creator` detects
that Synapse is up (from before), but it's the old version. Services have not yet been
restarted, so it's actually the older Synapse version that is up, not
the new one. The old version does not support the `--exists-ok` flag yet.
Basically, this `--exists-ok` patch landed too early and has affected existing playbook
users that have an older version of Synapse in operation.
It will be safer to bring back this patch some time in the future.
However, users upgrading from Synapse <= v1.109.0 even long into the
future will bump into the same issue. As such, it would be better to
either add special handling or to delay bringing back this patch enough
so as to ensure everyone using the playbook is on Synapse >= 1.110.0.
