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)
This commit adds a 'matrix-ntfy' role that runs Ntfy server in Docker with
simple configuration, and plumbing to add the role to the playbook.
TODO: documentation, self-check, database persistence.
`localhost` may resolve to `::1` on some IPv6-enabled systems, which will
not work, because we only potentially expose container ports on
`127.0.0.1` when nginx is disabled (`matrix_nginx_proxy_enabled: false`),
not on `::1`.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1914
* Add matrix-registration-bot
This adds an install and uninstall task plus helpers. The bot is disabled by default.
This commit does not include documentation, yet. In short, the bot can be enabled by adding
matrix_bot_matrix_registration_bot_enabled: true
matrix_bot_matrix_registration_bot_matrix_user_password: "verysecret"
matrix_bot_matrix_registration_bot_matrix_admin_token: "supersecret"
to the host_vars
* Change bot username to bot.matrix-registration-bot following convention
* Address smaller remarks, fix local docker build
* Switch to an env file
* Add environment variables extension for additional config
* Add documentation for the matrix-registration-bot
* Add screenshot on how to obtain admin access token
* Use bot as admin to only have one access token (bot and admin api)
* Use cleaner setting of matrix_synapse_registration_requires_token
* Use config file for cleaner more secure usage
* Delete unneeded env
* Rename vars to make usage clear
* Fix typos/wording and add notice about logging out
* Convert configuration to use |to_json
* Reorder role includes
Nothing should be after `matrix-common-after`.
`matrix-bot-matrix-registration-bot` can probably be anywhere, but it makes sense to put it next to the other `matrix-bot-*` roles.
* Minor group_vars/matrix_servers touchups
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
The `halfshot/matrix-hookshot` container images published to Docker Hub
(as of 2022-04-05, at least) are only available for `amd64`, not for
`arm64`. Self-building on arm64 is necessary.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1728
It should be noted that a `roiarthurb/matrix-hookshot` container image is available,
which is available for the arm64 platform, but that's non-official and doesn't
contain an amd64 build, so it's of limited use.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1682
Previously, when matrix-postgres was disabled, we were setting
`matrix_mautrix_twitter_database_engine` to an invalid empty value.
Now, we always hardcode `matrix_mautrix_twitter_database_engine: postgres`,
but set/unset the database hostname and password values instead.
1.0.2 is the first container image tag that is available as a multi-arch image
with support for linux/amd64, linux/arm64/v8 (arm64) and linux/arm/v7 (arm32),
so self-building is no longer necessary on all these platforms.
4.95-r0-1 is the first container image tag that is available as a multi-arch image
with support for linux/amd64, linux/arm64/v8 (arm64) and linux/arm/v7 (arm32),
so self-building is no longer necessary on all these platforms.
2.2.3 is the first container image tag that is available as a multi-arch image
with support for linux/amd64, linux/arm64/v8 (arm64) and linux/arm/v7 (arm32),
so self-building is no longer necessary on all these platforms.
The goal is to have a single variable which tells us which homeserver
software is in use. Much simpler than having if/elif/elif checks for
variables like (`matrix_synapse_enabled` and `matrix_dendrite_enabled`, etc.)
everywhere.
This change forces ansible to decrypt the variable with ansible-vault if encrypted, to avoid the error '{"msg": "Unexpected templating type error occurred on ({{ matrix_synapse_macaroon_secret_key | password_hash('sha512') }}): secret must be unicode or bytes, not ansible.parsing.yaml.objects.AnsibleVaultEncryptedUnicode"}'
Every other variable in the playbook was found to have no problems with encryption.
The change has no negative impact on non-encrypted matrix_synapse_macaroon_secret_key.
* fix for string concatenation on matrix_synapse_account_threepid_delegates_email and matrix_synapse_account_threepid_delegates_msisdn
* .editorconfig should not be ignored
* Restore .gitignore
Co-authored-by: b <b@b>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This bridge doesn't support SQLite anyway, so it's not necessary
to carry around configuration fields and code for migration from SQLite
to Postgres. There's nothing to migrate.
This commit introduces a new role that downloads and installs the
prometheus community postgres exporter https://github.com/prometheus-community/postgres_exporter.
A new credential is added to matrix_postgres_additional_databases that
allows the exporter access to the database to gather statistics.
A new dashboard was added to the grafana role, with some refactoring
to enable the dashboard only if the new role is enabled.
I've included some basic instructions for how to enable the role in
the Docs section.
In terms of testing, I've tested enabling the role, and disabling
it to make sure it cleans up the container and systemd role.
Expected to have regressed after https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1008
This patch comes with its own downsides (as described in the comments
for matrix_prometheus_node_exporter_container_http_host_bind_port),
but at least there's:
- no security issue
- metrics remain readable from matrix-prometheus (even if the network metrics are inaccurate)
A better patch is certainly welcome.
Not sure why this had been done in the first place.
It doesn't make any sense.
There's no relation between matrix-nginx-proxy and
prometheus-node-exporter.
This variable was previously undefined in the role and was only getting
defined via `group_vars/matrix_servers`.
We now properly initialize it (and its good default value) in the role
itself.
- add matrix_postgres_backup_databases to be build on top of matrix_postgres_additional_databases
- POSTGRES_DB is now directly set from matrix_postgres_backup_databases while building the templates/env-postgres-backup.j2
People who were disabling matrix-nginx-proxy (in favor of their own
nginx webserver) and also overriding `matrix_federation_public_port`,
found that the generated nginx configuration still hardcoded `8448`,
which forced their nginx server to use that, regardless of the fact
that `matrix_federation_public_port` was pointing elsewhere.
We now allow for the in-container federation port to be configurable,
and also automatically wire things properly.