* Enable Internal Admin API Access separately from Public access.
* Add Config variable for Draupnir Hijack command
And also make the internal admin API be automatically activated when this capability is used.
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Further Refine Internal Admin API
* Add Non Worker Labels for Internal Admin API
* Variable Rename
* Add validation rules for Internal Synapse admin API
* Add Draupnir Admin API required config validation.
* Override `matrix_synapse_reverse_proxy_companion_container_labels_internal_client_synapse_admin_api_traefik_entrypoints` via group vars
* Wire `matrix_bot_draupnir_admin_api_enabled` to `matrix_bot_draupnir_config_admin_enableMakeRoomAdminCommand` in Draupnir's `defaults/main.yml`
* Remove unnecessary `matrix_bot_draupnir_admin_api_enabled` override from `group_vars/matrix_servers`
The same value is now (more appropriately) defined in Draupnir's `defaults/main.yml` file anyway.
* Add additional condition (`matrix_bot_draupnir_enabled`) for enabling `matrix_synapse_container_labels_internal_client_synapse_admin_api_enabled`
* Use a separate task for validating `matrix_bot_draupnir_admin_api_enabled` when `matrix_bot_draupnir_config_admin_enableMakeRoomAdminCommand`
The other task deals with checking for null and not-blank and can't handle booleans properly.
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This:
- brings consistency - no more mixing `_name_prefix` and `_registry_prefix`
- adds extensibility - a future patch will allow reconfiguring all registry prefixes for all roles in the playbook
We still have `_docker_` vs `_container_` inconsistencies.
These may be worked on later.
This is done for a few reasons:
- less globals and more indepdendence for each role is better. We rely
on various externally-hosted roles and they don't rely on this global
either.
- `matrix_container_global_registry_prefix` could make people think they
could just override this variable and have all their images pull from
elsewhere. This is rarely the case, unless you've taken special care
to mirror all the various components (from their respective
registries) to your own. In such a case, you probably know what you're
mirroring and can adjust individual variables.
- nowadays, various components live on different registries.
With Docker Inc tightening rate limits for Docker Hub, it's even more
likely that we'll see increased diversity in where images are hosted
Note that there is no other "when" on this file. It is not sensible to keep these exceptions here.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This change clarifies that it is the upstream project, not this project owner, that discourages enabling Pantalaimon for Draupnir. This distinction should make it clear who is responsible for the matter.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Multiple use of the phrase "you know what you are doing" does not increase its effect but rather makes it noisy instead. Since it is warned with capitalized "DO NOT", it is enough.
Also replace the order to check in at the upstream with the recommendation, as it is inconsistent for this project overall to ask users to do so. It is not sensible to make an exception for Draupnir.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Draupnir 2.0.0
The config getting changes all over the place is because of 2.0 having removed a lot of config options due to the code being removed.
* Update Draupnir Documentation to reflect state as of 2.0.0
* Apply Review Feedback
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Change Room IDs found in code review to not conform to playbook standard.
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Further Integrate Code Review Feedback
* Apply remaining suggestions from code review.
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Apply Configuration Review Feedback
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Add Self Registration and Native Login to Draupnir
* Rework Draupnir Documentation to Remove Pantalaimon
* Set bot.draupnir as default username for the bot in config
* Draupnir 2.0.1
* Integrate Review Feedback on Structure of Docs
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Further Restructure Docs and tweak variables in response.
* Only auto-create draupnir user if a password has been set
The Draupnir role supports configuring it with either an access token or with a password.
When a password is not assigned (which means the access token mode is used), the user is to be created manually.
* Add ensure-matrix-users-created tag
Now that the Draupnir user may be auto-created in certain configurations (if a password is assigned), it's useful to have the tag there.
---------
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Related to 0241c71a4c
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3270#issuecomment-2143782962
With this change, it should be possible for people to adjust the Docker
dependency from `docker.service` to something else (e.g. `pkg-ContainerManager-dockerd.service`),
or to completely eliminate it by setting `devture_systemd_docker_base_docker_service_name` to an empty string.
This makes it easier for people to use the playbook against a Synology DSM server.
Appservice Draupnir for All required Develop before the release of 1.87.0 to work at all in the playbook. Now that we have a release to pin to we will return to being pinned to a release. Especially as Draupnir 2.0.0 push is happening now in main. This will mean that Draupnir develop is expected to be much more unstable than usual for a bit so its important that we pin to a stable release. These releases are validated due to having been dogfooded ever since D4A was merged into the playbook.
commit cf8637efaca0a0be3609fd6add0dff893a0a9194
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:14:57 2024 +0200
Make devture_systemd_docker_base_ipv6_enabled automatically reconfigure geerlingguy/ansible-role-docker
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit dc7af3bc7d25f321bf409477d823e43ea8a05803
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:10:31 2024 +0200
Replace matrix_ipv6_enabled with devture_systemd_docker_base_ipv6_enabled
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit 07e900d6a2926233a4fce34d9d8be292ff115260
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:01:51 2024 +0200
Improve matrix_ipv6_enabled comments
commit 3f03ca7f6983cb06b64607efef7a96b30c7def5b
Author: Tilo Spannagel <development@tilosp.de>
Date: Sat Mar 9 19:27:50 2024 +0000
Add setting to enable ipv6
This is an attempt at optimizing service startup.
The effect is most pronounced when many services are restarted one by one.
The systemd service manager role sometimes does this - for example when `just install-service synapse` runs.
In such cases, a 5-second delay for each Synapse worker service
(or other bridge/bot service that waits on the homeserver) quickly adds up to a lot.
When services are all stopped fully and then started, the effect is not so pronounced, because
`matrix-synapse.service` starts first and pulls all worker services (defined as `Wants=` for it).
Later on, when the systemd service manager role "starts" these worker services, they're started already.
Even if they had a 5-second wait each, it would have happened in parallel.
Draupnir moved its repo on github from the namespace of its maintainer Gnuxie to a newly created Github Organisation the-draupnir-project and this commit reflects this.
