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.
An attack on Triple DES was recently published[0]. It's not a very
high severity attack but the fact is that Triple DES is very old
and there are much better ciphers to use, like AES and ChaCha20.
I logged the ciphers that were negotiated on all of my vhosts over
a period of 72 hours and there were zero occurences of Triple DES,
so I am removing it, as suggested by the authors of the attack as
well as OpenSSL[1].
[0] https://sweet32.info
[1] https://www.openssl.org/blog/blog/2016/08/24/sweet32/
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
Pipelining makes ansible run tasks much faster, and as of Ansible
2.0 or 2.1 or so, it now works on older hosts that have requiretty
in their sudo config[0]. Also, disable the creation of those stupid
retry files.
[0] https://github.com/ansible/ansible/pull/13200
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.
