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.
Ansible errors on adding the tarsnap signing key because it is not
valid (expired a month ago). I contacted Colin Percival about this
on Twitter but he did not seem worried for some reason.
I had previously been removing some packages for security reasons,
then removing others because they were annoying, and yet *others*
because they were annoying on newer Ubuntus only. It is easier to
just unify these tasks and remove them all in one go.
On older Ubuntus where some packages don't exist the task will just
succeed because the package is absent anyways.
The default systemd journal configuration on CentOS 7 and Ubuntu
16.04 does not keep journal logs for multiple boots. This limits
the usefulness of the journal entirely (for example, try to see
sshd logs from even two or three months ago!).
Changing the storage to "persistent" makes systemd keep the logs
on disk in /var/log/journal for up to 2% of the partition size.
The default in later OpenSSH is 6, which seems too high. If you can't
get your password correct after 3 tries then I think you need help.
Eventually I'd like an easy way to enable blocking of repeated login
attempts at the firewall level. I think it's possible in firewalld.
Avoids the following error in apt:
Skipping acquire of configured file 'nginx/binary-i386/Packages' as repository 'https://nginx.org/packages/ubuntu bionic InRelease' doesn't support architecture 'i386'
No need to give Google even more data or free advertising by using
this as the default! In practice I always use the DNS servers from
the VPS provider anyways.
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.
This tag is no longer reachable after switching to the new dynamic
includes in Ansible 2.4 and 2.5. Anyways, I've been questioning my
decision to add the "packages" tag to any task that uses the apt
module.
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.
