Tests were carried out like this:
- `virtualenv3 env`
- `./env/bin/pip install ansible==4.10.0 ansible-core==2.11.7`
- `./env/bin/ansible-playbook .....`
The lowest version of `ansible-core` available on PyPI right now is
2.11.0. That version has trouble with `ansible==4.0.0` though.
The errors we were hitting seemed to be resolved by others online by
using `ansible==4.10.0` instead, which has a minimum `ansible-core`
requirement of `2.11.7`, so that's what we went with.
Older versions of Ansible may work, but.. I'm having trouble
installing them and don't want to spend too much time on digging through
ancient versions and testing them out. People should just learn to run
up-to-date software.
- 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.
Ansible recently started showing warnings about `crypt` being
deprecated. If one installs `passlib`, the `password_hash` values that
are generated would be different by default. With this patch, we ensure
consistency regardless of which one is used.
After this patch, password hashes (and UUIDs derived from them) will
change once, but they should be stable after that.
These hashes changing is not a problem, because the playbook
changes all references to the new values. Changes are only a problem if
they're done partially and with different tools.
For example:
- `--tags=setup-COMPONENT` with `passlib`
- `--tags=setup-postgres` with `crypt` (no `passlib`)
If so, the Postgres database password's value will differ for the
configuration generated for `COMPONENT`.
The `rounds=` value is arbitrary. It doesn't matter what it is,
as long as it's different than the default for `crypt` (5000)
and the default for `passlib` for `sha512` (656000).
Source (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_filters.html):
> To ensure idempotency, specify rounds to be neither crypt’s nor passlib’s default, which is 5000 for crypt and a variable value (535000 for sha256, 656000 for sha512) for passlib
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.
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
With this change, trying to run the playbook should report an error that
looks like this:
> The offending line appears to be:
>
> # Most of the roles below are not distributed with the playbook, but downloaded separately using `ansible-galaxy` via the `make roles` command (see `Makefile`).
> - role: galaxy/com.devture.ansible.role.playbook_help
> ^ here
.. with that comment included, which might help some people who missed
the `make roles` part.
Improves https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2232
Slavi Pantaleev
