* Update configuring-playbook.md: move a link for docs/configuring-playbook-bot-postmoogle.md to Bots section
The document (on 9c2a8addee93910cb9079f856bc3fb3932592c91; initial commit to add Postmoogle) says:
> Postmoogle is a bot/bridge you can use to forward emails to Matrix rooms
Therefore it is not really incorrect to categorize Postmoogle as bridge document-wise, but since the list on README.md categorizes it as a bot, and based on the file name of the documentation, this commit moves the link for Postmoogle to the Bots section.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Revert "Update configuring-playbook.md: move a link for docs/configuring-playbook-bot-postmoogle.md to Bots section"
This reverts commit 1e2e903cb9.
* Change the file name of Postmoogle documentation to make it clear that Postmoogle is a bridge
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update documentation for Postmoogle related to a bridge/bot status
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add a global config option for Docker network MTU
* Upgrade systemd_docker_base (v1.2.0-0 -> v1.3.0-0)
The new version includes `devture_systemd_docker_base_container_networks_driver_options`
due to 3cc7d12396
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3502
* Switch from passing matrix_playbook_docker_network_mtu to respecting devture_systemd_docker_base_container_networks_driver_options
Related to:
- 3cc7d12396
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3502
* Update all roles to versions that respect `devture_systemd_docker_base_container_networks_driver_options`
---------
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.
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 07e900d6a2
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:01:51 2024 +0200
Improve matrix_ipv6_enabled comments
commit 3f03ca7f69
Author: Tilo Spannagel <development@tilosp.de>
Date: Sat Mar 9 19:27:50 2024 +0000
Add setting to enable ipv6
This is still very far from usable.
Various bridges and bots are still talking to
`matrix-nginx-proxy` instead of the new `matrix-homeserver-proxy` role.
These services need to be reworked. While reworking them,
various cleanups are being done as well as adding Traefik-labels to
those that need them.
This is backward-compatible with what we had before. We're not changing
the SSL mode - just making it configurable.
Most components are defaulting to `sslmode=disable`, while some
(`matrix-bot-matrix-reminder-bot` and others) do not specify an `sslmode` at all.
We're making sslmode configurable, because certain external Postgres
servers may be configured to require SSL encryption.
In such cases `sslmode=disable` does not work and needs to be changed to
`sslmode=require` or something else (`verify-ca`, `verify-full`, etc).
- 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.
