Something seems to have happened as of Ansible 2.4.0.0 where this no
longer works. I suspect it is related to the major changes to static
and dynamic imports that landed around this same time.
We make sure that this tasks always runs by using the special tag of
the same name.
[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.
I can't remember right now why I needed to use Debian's MariaDB build
but now I just want to use upstream's latest stable. Debian's version
is 10.1 and upstream has moved on to 10.2.
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.
Sync with latest packaged version from Debian 9. Effectively this
only updates comments and disabled options, but having less changes
to look at during an apt upgrade is nice and reduces the chance of
adding errors.
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).
Debian 9 is still in beta and doesn't have nginx.org builds yet, so
we need to use the nginx package in Debian's repositories, and that
required a bit of a different configuration.
After official nginx.org builds are released we can revert this.
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'
Only vhosts running WordPress, etc need PHP. Make sure to set the
appopriate variables for each vhost in the host's vars, ie:
nginx_vhosts:
- domain_name: example.com
has_wordpress: True
- domain_name: example.net
needs_php: True
You can set either of them, but not both—needing WordPress implies
needing PHP.
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`.
When I originally deployed Ubuntu 16.04 there were no public xenial
MariaDB builds yet, so I used wily (15.10). Now there are official
xenial builds so we can use them instead.
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
I had removed them from Debian 8 and Ubuntu 14.04 configs last year
when the NSA's Suite B crypto guidelines dropped 128-bit algorithms
but those changes didn't make it to my new Ubuntu 16.04 config.
It is probably overkill and paranoid, but this server is mine, so I
can make those decisions (and I only connect from modern clients).
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).
