Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1775
Related to https://signald.org/articles/install/docker/#migrating-from-versions-before-0180
> Prior to 0.18.0 the signald container image used the root user, which is not recommended for security reasons. This was fixed in the 0.18.0 release which will start as root, fix permissions on the volume, then drop to the non-root user and start signald. Future images will start as the non-root user, so if you’re upgrading make sure to run 0.18.0 at least once.
> A special tag, 0.18.0-non-root, will be published. it starts as the non-root user and does not fix permissions on the volume.
People often report and ask about these "failures".
More-so previously, when the `docker kill/rm` output was collected,
but it still happens now when people do `systemctl status
matrix-something` and notice that it says "FAILURE".
Suppressing to avoid further time being wasted on saying "this is
expected".
The `to_nice_yaml` helper will by default wrap any string YAML values on
the first space after column 80. This can in worst case yield invalid
YAML syntax. More details in Ansible's documentation here:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#formatting-data-yaml-and-json
In short, you need to explicitly provide a custom width argument of a
high number of some kind to avoid the line wrapping.
"Community" support
- has been removed from mautrix/facebook in v0.3.3:
31cac6fb5e
- has been removed from mautrix/signal in v0.2.2:
1f27a608a6
- will be removed in the next mautrix/instagram release:
e2ae1ca503
- will be removed in the next mautrix/twitter release:
3893075265
Reverts b1b4ba501f, 90c9801c56, a3c84f78ca, ..
I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.
`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.
Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).
We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.
Updated settings in template file:
* relay for any user
* user permissions only for HS domain users
Co-authored-by: Jan <31133207+Jaffex@users.noreply.github.com>
Permissions, when set in the template, will be augmented rahter than replaced when using matrix_mautrix_signal_configuration_extension_yaml. Therefore, permissions shall only be set in the defaults/vars.yml or in the HS specific vars.yml file
Per default relay bot functionality is disabled; the bridge user permissions depends on the relay bot, if enabled the base domain users are on level relay, else remain on user;
See these last commits:
tulir/mautrix-signal@4fc34330c1f6947aece67863b0d04da34c776f80
tulir/mautrix-signal@64bc5c36a509ba435a0b01cf44afb1b5d2642efd
tulir/mautrix-signal@ddda1666d41d28750cc59d070e4388b24add6ad9
If they do, our next playbook runs would simply revert it
and report "changed" for that task.
There's no benefit to letting the bridge spew a new config file.
This does not apply to the mautrix whatsapp bridge, because that one
is written in Go (not Python) and takes different flags. There's no
equivalent flag there.
Matthew Cengia
Slavi Pantaleev
GoliathLabs
Aine
Jim Myhrberg
László Várady
GoMatrixHosting
Kim Brose
Marko Weltzer
Marko Weltzer
IUCCA
rakshazi
laszabine
Jan
AtomHare
Wolfgang Winter
WobbelTheBear
Toorero
teutat3s
transcaffeine
efraimbart