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.
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.
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.
Basically, when using conditionals or variables in your tasks you should
use include_tasks instead of import_tasks. The down side is that you now
need to tag all included tasks individually or with a block, unlike when
using static imports (tags are applied to all imported child tasks).
I would actually like to reduce this task to a single one that uses the
host's ansible_distribution variable, but Ansible 2.5.1 currently gives
the following error: ansible_distribution is undefined.
Vanilla Ubuntu (and Debian actually) defaults to using the official
mirror for security updates rather than country or regional mirrors.
Also, for what it's worth, Ubuntu mirrors didn't always sync these
security archives. I'd prefer to stay closer to vanilla Ubuntu but
also it kinda makes sense to get security updates from the official
source than a mirror (in case of delay or errors).
We stopped being able to do dynamic includes from the playbooks around
Ansible 2.4.0.0 if I recall correctly. Instead we can create a task to
include the variables and make it always run by using the special tag.
For now the Debian and Ubuntu vars files are the same, but I will keep
them separate so that it is more flexible in the future.
These tasks are conditional and mutually exclusive due to the "when"
clause. Using import_tasks means that these are imported before the
playbook execution and then skipped during evaluation of the test.
It makes sense in this case to use include_tasks so that the tasks
are only imported during playbook execution if the condition is met.
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
I have zero idea if we have IE6 clients any more, but according to the
H5BP community IE6 actually did support gzip and only represents 0.1%
of Internet traffic in 2015 (!) anyways.
See: https://github.com/h5bp/server-configs-nginx/issues/125
You should only use the "shell" module when you need shell functions
like flow control and redirects. Also, the "command" module is safer
because it is not affected by the user's environment.
