I changed these yesterday when editing the truthy values, but acco-
rding to ansible-link we can just rely on them being true or false
without comparing.
According to Ansible we can use yes, true, True, "or any quoted st-
ring" for a boolean true, but ansible-lint wants us to use either
true or false.
See: https://chronicler.tech/red-hat-ansible-yes-no-and/
After the inital acme.sh script is downloaded and bootstrapped we
can remove it. If a host already has been bootstrapped then there
is no need to download it and do it over again.
Instead of manually creating our own self-signed certificate we can
use the one created automatically by the ssl-cert package on Debian.
This is only used by the dummy default HTTPS vhost.
The certbot-auto client that I've been using for a long time is now
only supported if you install it using snap. I don't use snap on my
systems so I decided to switch to the acme.sh client, which is imp-
lemented in POSIX shell with no dependencies. One bonus of this is
that I can start using ECC certificates.
This also configures the .well-known directory so we can use webroot
when installing and renewing certificates. I have yet to understand
how the renewal works with regards to webroot, though. I may have to
update the systemd timers to point to /var/lib/letsencrypt/.well-known.
It seems that it is no longer recommended/supported to install the
standalone certbot-auto client on Ubuntu 20.04. We apparently need
to use the one provided by Ubuntu, which luckily includes a service
and timer to renew the certs.
ansible-lint told me not to test equality with booleans using literal
"True" and "False", but it Ansible complains if I use "is True" also.
It seems that I need to adjust the syntax slightly.
We can register changes when adding repositories and keys and then
update the apt package index conditionally. This should make it be
more consistent between initial host setup and subsequent re-runs.
Instead of looping over a list of items to install, we can actually
just give a list directly to the apt module. This allows the module
to install all packages in one transaction, which is faster as well
as slightly safer for some dependency resolution scenarios.
Because of the shift from static imports to dynamic includes these
tags will never be reached unless they have their own task that is
tagged at the top-level (dynamic includes don't pass their tags to
their children).
After reörganizing for dynamic includes these tags will never be reached
because the children of dynamic includes do not inherit tags from their
parents as they did with static imports.
As of Ansible 2.4 and 2.5 the behavior for importing tasks has changed
to introduce the notion of static imports and dynamic includes. If the
tasks doing the import is using variable interpolation or conditionals
then the task should be dynamic. This results in quicker playbook runs
due to less importing of unneccessary tasks.
One side effect of this is that child tasks of dynamic includes do not
inherit their parents' tags so you must tag them explicitly or a block.
Also, I had to move the letsencrypt tasks to the main task file so the
tags were available (due to dynamic tasks not inheriting tags).
As of Ansible 2.4 and 2.5 the behavior for importing tasks has changed
to introduce the notion of static imports and dynamic includes. If the
tasks doing the import is using variable interpolation or conditionals
then the task should be dynamic. This results in quicker playbook runs
due to less importing of unneccessary tasks.
One side effect of this is that child tasks of dynamic includes do not
inherit their parents' tags so you must tag them explicitly or a block.
Use dynamic includes instead of static imports when you are running
tasks conditionally or using variable interpolation. The down side
is that you need to then tag the parent task as well as all child
tasks, as tags only apply to children of statically imported tasks.
Instead of iterating over fifteen packages with a loop that does fifteen
separate apt transactions, it is better to give the apt module a list so
it can install them all in one transaction. This is both quicker and te-
chnically more safe for dependency resolution.
Instead of iterating over fifteen packages with a loop that does fifteen
separate apt transactions, it is better to give the apt module a list so
it can install them all in one transaction. This is both quicker and te-
chnically more safe for dependency resolution.
Ansible 2.4 and 2.5 are moving away from specialized loop functions
and the old syntax will eventually be deprecated and removed. I did
not change the with_fileglob loops because I'm not sure about their
syntax yet.
See: https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html
[ANSIBLE0006] systemctl used in place of systemd module
Also, move the functionality of the changed check to the systemd task,
because it has the ability to simply daemon-reload itself now.
Ansible 2.4 changes the way includes work. Now you have to use "import"
for playbooks and tasks that are static, and "include" for those that
are dynamic (ie, those that use variables, loops, etc).
See: http://docs.ansible.com/ansible/devel/playbooks_reuse_includes.html
