Looks like we've skipped a bunch of 0.8.x versions (up to 0.8.9)
and are jumping straight to 0.9.0.
This is untested. Judging by Dendrite's changelog, it shouldn't cause
any breakage though: https://github.com/matrix-org/dendrite/blob/v0.9.0/CHANGES.md
* Auto trust new signal identities
from signald doku: when a remote key changes, set trust level to TRUSTED_UNVERIFIED instead of UNTRUSTED
I find it much more convenient when new identities are automatically recognized as trusted, as the process to do that manually is cumbersome.
Should this the default behavior, or should i add an option to configure this behavior?
* Added option to trust new signal identities
* Using env file
* Renamed variable
* Corrected typo
* Use fully-qualified Ansible module name
* removed option trust_new_keys
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* if variable to bind an exporter container to a host port is set, have matrix-domain.conf (nginx) support this
* manipulate some variables to account for just port numbers or 0.0.0.0 IPs
* Make sure to use the right variable in the init.yml files
* Update roles/matrix-prometheus-node-exporter/tasks/init.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update roles/matrix-prometheus-postgres-exporter/tasks/init.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* remove extraneous variables and whitespace
Co-authored-by: Luca Bilke <luca@gmail.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This is what upstream uses and also what
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1977
used.
Initially, I wanted to make the prefix more unique, in case another
Kakaotalk bridge comes along, but.. it's probably on the new bridge to
come up with a unique puppet prefix, not on us now to override upstream
decisions.
Adds support for: https://src.miscworks.net/fair/matrix-appservice-kakaotalk
This is pretty similar to
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1977
which just appeared, but has mostly been done independently.
I've taken some inspiration and did some fixups based on that PR.
Thanks to https://github.com/hnarjis for taking the time to contribute!
Notable differences between this branch compared to that PR:
- better naming and documentation around the "configuration" variables
- no unnecessary (5 sec.) intentional delay when starting `matrix-appservice-kakaotalk-node.service`
- stores configuration in `config/`, not in `data/`
- passes configuration as read-only and starts the bridge with (`--no-update`) to ensure no changes are made to it
- starts containers more securely - with `matrix:matrix` user:group (not `root`) and
reduced capabilities (`--cap-drop=ALL`)
- uses `tcp` for communication between the "node" and the appservice (simpler than sharing unix sockets)
- `registration.yaml` which is closer to the one generated by `matrix-appservice-kakaotalk` (no `de.sorunome.msc2409.push_ephemeral` stuff, etc.)
- `registration.yaml` which is more customizable (customizable bot username and prefix for puppets - see `matrix_appservice_kakaotalk_appservice_bot_username` and `matrix_appservice_kakaotalk_user_prefix`)
- less fragile and more extensible bridge permissions configuration via `matrix_appservice_kakaotalk_bridge_permissions`. Doing `{% if matrix_admin %}` in the bridge configuration sometimes causes syntax problems (I hit some myself) and is not ideal. Other bridges should be redone as well.
- configurable command prefix for the bridge, instead of hardcoding `!kt` (see `matrix_appservice_kakaotalk_command_prefix`)
- logging that is more consistent with the rest of the playbook (console / journald only, no logging to files), as well as configurable log level (via `matrix_appservice_kakaotalk_logging_level`)
- somewhat more detailed documentation (`docs/configuring-playbook-bridge-appservice-kakaotalk.md`)
- removed some dead code (data relocation tasks from `tasks/setup_install.yml`, as well as likely unnecessary SQLite -> Postgres migration)
Not doing {% if matrix_admin %} checks in the YAML also fixes some issues
with indentation being incorrect sometimes.
This should be backward compatible, except for mautrix-signal's case
where `matrix_mautrix_signal_bridge_permissions` previously existed
as a string, not a dictionary. `tasks/validate_config.yml` will catch
the problem an even provide a quick fix.
Slavi Pantaleev
Aine
Stuart Mumford
Charles Wright
Aine
Arthur Brugière
IUCCA
MdotAmaan
snailed
MdotAmaan
Maxdeso
Aaron Raimist
Simone