* 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)
We need this to control whether `('matrix-' + matrix_homeserver_implementation + '.service')`
would get injected into `devture_systemd_service_manager_services_list_auto`
This was useful when the order of these roles in relation to Synapse
mattered (when we were injecting stuff into Synapse variables during
runtime). This is no longer the case since 0ea7cb5d18, so all of
this can be removed.
These `init.yml` (now `inject_into_nginx_proxy.yml`) tasks do not need
to `always` run. They only need to run for `setup-all` and
`setup-nginx-proxy`. Unless we're dealing with these 2 tags, we can
spare ourselves a lot of work.
This patch also moves the `when` statement from `init.yml` into
`main.yml` in an effort to further optimize things by potentially
avoiding the extra file include.
These are not even caused by Archlinux, but by running buggy Ansible on old Ubuntu
while targeting modern servers (like Archlinux, but also others, ..).
We shouldn't employ ugly workarounds like this. We should tell people to
avoid running buggy Ansible or bad distros like Ubuntu, even.
* Enable location sharing in Element
* Update roles/custom/matrix-client-element/tasks/validate_config.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update roles/custom/matrix-client-element/tasks/setup_install.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Rename location sharing vars to be consistent with other vars
* Rename style.json to map_style.json
* Add m.tile_server section to /.well-known/matrix/client
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Add task to configure a standalone JVB on a different server
* add missing file
* set nginx config
* update prosody file and expose port 5222
* change variable name to server id
* formatting change
* use server id of jvb-1 for the main server
* adding documentation
* adding more jvbs
* rename variable
* revert file
* fix yaml error
* minor doc fixes
* renaming tags and introducing a common tag
* remove duplicates
* add mapping for jvb to hostname/ip
* missed a jvb_server
* Update roles/matrix-nginx-proxy/templates/nginx/conf.d/matrix-jitsi.conf.j2
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* PR review comments and additional documentation
* iterate on dict items
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* adding documentation around the xmpp setting
* add common after
* reduce the number of services during init of the additional jvb
* remove rogue i
* revert change to jitsi init as it's needed
* only run the jvb service on the additional jvb host
* updating docs
* reset default and add documentation about the websocket port
* fix issue rather merge with master
* add missing role introduced in master
* this role is required too
* Adding new jitsi jvb playbook, moving setup.yml to matrix.yml and creating soft link
* updating documentation
* revert accidental change to file
* add symlink back to roles to aid running of the jitsi playbook
* Remove extra space
* Delete useless playbooks/roles symlink
* Remove blank lines
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Jitsi control sentry dns using vars
* renaming variables
* Revert "renaming variables"
This reverts commit 4146c48f6a2e71d1b0d3f58c767aea1b2f4f789c.
* set to connection string or 0 to disable
* Update comments
* Use empty string for default Sentry DSN variables
Both should work identically, but an empty string seems better
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This fixes a regression since the change done in c1c152f7ac.
When another role (say `matrix-jitsi`) included `roles/custom/matrix-base/tasks/util/ensure_openssl_installed.yml`,
which then included `{{ role_path }}/tasks/util/ensure_openssl_installed_DISTRO.yml`,
that `role_path` variable would end up being the parent role
(`matrix-jitsi`) and not the `matrix-base` role, so we'd get a failure.
An alternative solution may have been to avoid using `role_path`, but
importing roles properly (like we've done in this patch) sounds like a better way.
Unfortunately, `import_role` fails if `tasks_from` is something like
`util/ensure_openssl_installed` (containing a `/`), so I had to move
these utils out of `util/`.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228
We no longer ask users to create Matrix user accounts for these bots:
- Postmoogle
- Honoroit
- Reminder Bot
Other bots and services (matrix-registration-bot, maubot, mjolnir,
Dimension, etc.) require an Access Token to run (not a password),
so this new role doesn't help for them.
It does help for the above bots though, and for defining your own
"initial user accounts" in the `matrix_user_creator_users_additional`
variable.
Dendrite uses a lot of databases, but a single (`dendrite`) role, which
leads to `matrix_postgres_import_roles_to_ignore` being something like
`['dendrite', 'dendrite', 'dendrite', ...]` needlessly.
This leads to weird regexes being generated for
`matrix_postgres_import_roles_ignore_regex`.
It's not that it hurts, but it just looks odd.
We were only reporting failures for when the async task didn't finish.
We also need to report a failure for when the task finished, but
returned a non-zero exit code.
This is more consistent with how we name variables. It's also less
confusing, especially given that we have `matrix_hookshot_feeds_pollTimeoutSeconds` as well.
This allows people to augment the Synapse image with custom tools and
addons without having to rebuild it from scratch.
If customizations are enabled, the playbook will build a new
`localhost/matrixdotorg/synapse:VERSION-customized` image
on top of the default one (`FROM matrixdotorg/synapse:VERSION`)
and with custom Dockerfile build steps.
For servers that self-build the Synapse image, the Synapse image will be
built first, before proceding to extend it the same way.
In the future, we'll also have easy to enable Dockerfile build steps
for modules that the playbook supports.
We don't like updating to untagged releases, but..
0.2.1 has some regression and upstream is not releasing 0.2.2 or 0.3.0
just yet, so we either need to downgrade to 0.2.0 or go `latest`.
We can hopefully switch back to a tagged release soon.
Related to https://github.com/mautrix/instagram/issues/56
* Make registration proxy independent of other roles, document
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Fix yml issues
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Remove undefined variable (as service HAS to be exposed
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Add registration endpint
Defines the registration endpoint that should be intercepted/forwarded to the proxy
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Add image name
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
This is consistent with what all other roles do. If someone includes a
role, the assumption is that they want its functionality enabled.
The playbook distribution then disables components via
`group_vars/matrix_servers`. We've always had `matrix_grafana_enabled: false`
there, so flipping the in-role `_enabled` flag to `true` does not change
anything for playbook users. Users who import the roles individually in
their own other playbooks (and who don't use `group_vars/matrix_servers`)
may observe a change in the defaults with this.
Using `matrix_synapse_*` variables within the `matrix-grafana` role
is not a good practice.
We now have a `matrix_grafana_default_home_dashboard_path` variable
with a good universal default value and we override it via
`group_vars/matrix_servers` based on enabled components, etc.
This is a better fix for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2133
We shouldn't be using it in the role (`tasks/setup.yml`) without
defining at least some default value in the role itself.
We've always had the override in `group_vars/matrix_servers`,
so the variable was essentially defined (at the playbook level), but
that's not the right way to do things.
* send emails in UTF-8 👋
* fix options descriptions
* add SMTP auth
* allow sending emails from your apps and scripts using postmoogle as email provider