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.
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.
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
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
[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
Using www-data was a temporary measure while I was waiting for the
official nginx.org packages to be released for Debian 9 and we had
to use Debian's own nginx package.
There are currently no nginx.org builds for Debian 9, so we need to
use the package from Debian's repository. This package provides a
www-data user and group instead of an nginx one.
We can revert some of this after Debian 9 is released and official
builds come from nginx.org (though it might be useful to keep the
main nginx.conf as a template).
I'm surprised this worked all these years actually. Since Ansible
version 1.6 it has been possible to use the version_compare filter
instead of doing math logic on strings.
See: https://docs.ansible.com/ansible/playbooks_tests.html
I realized the other day that due to complex logic in the location
blocks, various WordPress static files like images and stylesheets
didn't get the HTTP Strict Transport Security header set. We need
to include it on each level where we are setting headers, because
nginx overwrites headers if you set them again in a child block.
There was some knowledge floating around that 860 bytes was the
optimal size, I think it was from an Akamai engineer or something,
but the HTML 5 Boilerplate server configs use 256 bytes, and I
actually have HTML content that is less than 860 bytes, so I guess
I could benefit from compressing it. gzip compression is costly
for the compression side, but very quick for the client, so this
is a good thing.
See: https://github.com/h5bp/server-configs-nginx/blob/master/nginx.conf
The variable name is misleading as this really does is install the
certbot client and its dependencies, and we generally want this to
always happen. If a host doesn't want it, they can override it in
their host vars.
Perhaps I should rename this variable to "bootstrap_letsencrypt" or
something so it is more accurate.
The `ConditionFileIsExecutable` goes in the [Unit] section! This
fixes the error:
systemd[1]: [/etc/systemd/system/renew-letsencrypt.service:6] Unknown lvalue 'ConditionFileIsExecutable' in section 'Service'
Used to indicate if a vhost needs PHP configuration or not, like
for a static site. Set in the hosts's nginx_vhosts block. Defaults
to "False" if unset.
This reverts commit 201165cff6.
Turns out this actually breaks initial deployments, because the
cache gets updated in the first task, then you add sources for
nginx and mariadb, but it doesn't update the indexes because the
cache is < 3600 seconds old, so you end up getting the distro's
versions of nginx and mariadb.
When you give Ansible the key id it will check if the key exists
before trying to download and add it. I got the long fingerprint
from `sudo apt-key finger`.
I have added cache_valid_time=3600 for the first task in each
tag that could be possibly running apt-related commands. For ex,
the "nginx" tag is also in the "packages" tag, but sometimes you
run the nginx tag by itself (perhaps repeatadely), so you'd want
to limit the update unless the cache was 1 hour old
I never modify file in the git repo, but the WordPress updater does
updates from the web (for example TwentySixteen theme), and this
always causes the task to fail when I switch WordPress versions.
This reverts commit a38d822fad.
The docs definitely recommend twice a day. From a note on certbot's
installation page:
> if you're setting up a cron or systemd job, we recommend running
> it twice per day (it won't do anything until your certificates
> are due for renewal or revoked, but running it regularly would
> give your site a chance of staying online in case a Let's
> Encrypt-initiated revocation happened for some reason). Please
> select a random minute within the hour for your renewal tasks.
See: https://certbot.eff.org/#ubuntuxenial-nginx
For idempotence we need to run all apt-related tasks, like editing
source files, adding keys, installing packages, etc, when running
the 'packages' tag.
Take an opinionated stance on HTTPS and assume that hosts are using
HTTPS for all vhosts. This can either be via custom TLS cert/key
pairs defined in the host's variables (could even be self-signed
certificates on dev boxes) or via Let's Encrypt.
Hosts can specify use_letsencrypt: 'yes' in their host_vars. For
now this assumes that the certificates already exist (ie, you have
to manually run Let's Encrypt first to register/create the certs).
Alan Orth