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.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1894
Because the configuration file is now mounted as readonly and maubot tries to update it on start,
we get this warning:
> Failed to create tempfile to write updated config to disk: [Errno 30] Read-only file system: '/config/tmpfa8vcb3y.yaml'
It doesn't seem to cause issues though.
Because the configuration is no longer overwritten on every bot start, each
next Ansible run should no longer overwrite it again and report a
"changed" task.
* Make interface hidden behind proxy by default
* Remove expose option and replace with http_bind_port
Reasoning: This is a similar binary trigger but allows to bin not on all interfaces
* Clarify maubot admin purpose
* Remove unnecessary edif
* Extend docs to prevent common misconceptions
* Make http_bind_port singular, do not allow multiple values
* Make optional again
Reasoning: setup_install.yml only runs on --tags=setup-all or on --tags=setup-bot-maubot.
If --tags=setup-nginx-proxy or similar commands are run, setup_install.yml will not run and the nginx configuration will be incomplete.
Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#var-naming
We don't really fix these, but just suppress them,
because they're like that intentionally.
We try to name variables in a way that is consistent with the
configuration key they control. If the upstream component uses
camelCase, we also need to include camelCase in the variable name.
Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#git-latest
Our variable naming is not necessarily consistent across roles.
I've tried to follow the naming conventions of each individual role.
All new variables are suffixed with `_version`, but the prefix may be
somewhat different.
