* Allow the mautrix whatsapp relaybot to be enable with a variable
This allows a user to enable the relaybot by setting a variable in
`vars.yml` in the same way that the mautrix signal relaybot is
configured.
* Correct default values for mautrix whatsapp relaybot variables
* Add documentation for using the relaybot with mautrix whatsapp
* Adjust variable names to better reflect what they do
* Set default variables properly and use to_json in template
This extends the collection with support for seamless authentication at the Jitsi server using Matrix OpenID.
1. New role for installing the [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service)
2. Changes to Jitsi role: Installing Jitsi Prosody Mods and configuring Jitsi Auth
3. Changes to Jitsi and nginx-proxy roles: Serving .well-known/element/jitsi from jitsi.DOMAIN
4. We updated the Jitsi documentation on authentication and added documentation for the user verification service.
Please note that This Mjolnir version bump technnically is missing some extra stuff that mjolnir claims we should do but it didnt work when i tried it and well my mjolnir deployment has been running this since release day almost and its fine. No errors in log that are unexpected. (Mjolnir throws errors in the log for anyone who wonders for various things that are fine. Like if a protection is off that is an error. Its due to how matrix-bot-lib works.)
Without these:
- `--tags=install-synapse` and `--tags=install-all` would be incomplete
and will not contain Synapse worker configuration
- `--tags=install-synapse-reverse-proxy-companion` and
`--tags=setup-synapse-reverse-proxy-companion` would not contain
Synapse worker configuration
* Changes to allow a user to set the max participants on a jitsi
conference
* changed var name from jitsi_max_participants to matrix_prosody_jitsi_max_participants
* add prometheus-nginxlog-exporter role
* Rename matrix_prometheus_nginxlog_exporter_container_url to matrix_prometheus_nginxlog_exporter_container_hostname
* avoid referencing variables from other roles, handover info using group_vars/matrix_servers
* fix: stop service when uninstalling
fix: typo
move available arch's into a var
fix: text
* fix: prometheus enabled condition
Co-authored-by: ikkemaniac <ikkemaniac@localhost>
Running with a user (like `matrix:matrix`) fails if Etherpad is enabled,
because `/matrix/etherpad` is owned by `matrix_etherpad_user_uid`/`matrix_etherpad_user_gid` (`5001:5001`).
The `matrix` user can't acccess the Etherpad directory for this reason
and Borgmatic fails when trying to make a backup.
There may be other things under `/matrix` which similarly use
non-`matrix:matrix` permissions.
Another workaround might have been to add `/matrix/etherpad` (and
potentially other things) to `matrix_backup_borg_location_exclude_patterns`, but:
- that means Etherpad won't be backed up - not great
- only excluding Etherpad may not be enough. There may be other files we
need to exclude as well
---
Running with `root` is still not enough though.
We need at least the `CAP_DAC_OVERRIDE` capability, or we won't be able to read the
`/etc/borgmatic.d/config.yaml` configuration file (owned by
`matrix:matrix` with `0640` permissions).
---
Additionally, it seems like the backup process tries to write to at least a few directories:
- `/root/.borgmatic`
- `/root/.ssh`
- `/root/.config`
> [Errno 30] Read-only file system: '/root/.borgmatic'
> Error while creating a backup.
> /etc/borgmatic.d/config.yaml: Error running configuration file
We either need to stop mounting the container filesystem as readonly
(remove `--read-only`) or to allow writing via a `tmpfs`.
I've gone the `tmpfs` route which seems to work.
In any case, the mounted source directories (`matrix_backup_borg_location_source_directories`)
are read-only regardless, so our actual source files are protected from unintentional changes.
Without this, it's a string and borg says:
> At 'hooks.postgresql_databases[INDEX_HERE].port': '5432' is not of type 'integer'
> /etc/borgmatic/config.yaml /etc/borgmatic.d /tmp/.config/borgmatic/config.yaml /tmp/.config/borgmatic.d: No valid configuration files found
.. and fails to do anything.
This role is usable on its own and it's not tied to Matrix, so
extracting it out into an independent role that we install via
ansible-galaxy makes sense.
This also fixes the confusion from the other day, where
`matrix_postgres_*` had to be renamed to `devture_postgres_*`
(unless it was about `matrix_postgres_backup_*`).
We now can safely say that ALL `matrix_postgres_*` variables need to be
renamed.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2305
More details about the new key type can be found here:
https://eff-certbot.readthedocs.io/en/stable/using.html#rsa-and-ecdsa-keys
Existing RSA-based keys will continue to renew as RSA until manual
action is taken. Example from the documentation above:
> certbot renew --key-type ecdsa --cert-name example.com --force-renewal
In the future, we may add a command which does this automatically for
all domains.
* added dendrite captcha options
* added hcaptcha doc
* proper url
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update main.yml
* renamed captcha vars to new naming scheme
* change vars to new format
* Rename back some incorrect renamed variables
These variables are either not just part of the `client_api` subsection,
or are not even part of that section at all. They shouldn't have been
renamed in baaef2ed616e2645550d9
* Fix up naming inconsistencies
Some of these variables had been renamed in one place,
but not in other places, so it couldn't have worked that way.
* Add validation/deprecation for renamed Dendrite variables
Related to 4097898f885cf4c73, baaef2ed616e2645550, 68f4418092fa8ad
and a0b4a0ae6b2f1f18
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
- forego removing Docker images - it's not effective anyway, because it
only removes the last version.. which is a drop in the bucket, usually
- do not reload systemd - it's none of our business. `--tags=start`,
etc., handle this
- combine all uninstall tasks under a single block, which only runs if
we detect traces (a leftover systemd .service file) of the component.
If no such .service is detected, we skip them all. This may lead to
incorect cleanup in rare cases, but is good enough for the most part.
* Exempt Matrix server from ntfy rate limit
Add the matrix fqdn and localhost to ntfy's exemption list.
Also allow all ntfy rate limits to be configured through Ansible
variables.
* Fix names and formatting
* fixes
* tabs not spaces
* Lint
* Use raw tags instead of bracket soup
We had checks to avoid stopping/deleting systemd services for workers
that used to exist and will continue to exist, but we were deleting
config files for workers each time.. Only to recreate them again later.
This lead to:
- too many misleading "changed" tasks
- too much unnecessary work
- potential failures during playbook execution possibly leaving the
system in a bad state (no worker config files)
