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).
The creation of the fastcgi cache dir is part of the nginx role and
should be labled as such. In situations where you only run nginx
tasks with `-t nginx` nginx will fail to start due to the missing
cache dir.
Google's preload check application pointed out that there was an
extra semi colon in the HTTP header:
$ hstspreload checkdomain alaninkenya.org
Warning:
1. Syntax warning: Header includes an empty directive or extra semicolon.
The tool can be downloaded here: https://github.com/chromium/hstspreload
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Google's PageSpeed Insights tool pointed out that the Genericons
in WordPress' Jetpack module could be compressed.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Everything is HTTPS now, whether self-signed or otherwise, so it
doesn't make sense to have a config switch for this.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
It's just deduplication, since it's already obvious that the dict
is for nginx-related vars:
- nginx_domain_name→domain_name
- nginx_domain_aliases→domain_aliases
- nginx_enable_https→enable_https
- nginx_enable_hsts→enable_hsts
Signed-off-by: Alan Orth <alan.orth@gmail.com>
It would be bettwe to set these defaults in the role's defaults, but
we can't because they exist in dicts for each of the host's sites.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
The `enable_https` option in host_vars becomes `nginx_enable_https`
to be more consistent with other nginx options used in host_vars.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Set `use_snakeoil_cert: 'yes'` in host_vars. This is good for dev
hosts where we don't have real domains or real certs. But everything
should have TLS.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
For now I generated the certs manually, but in the future the play-
book should run the letsencrypt-auto client for us!
Signed-off-by: Alan Orth <alan.orth@gmail.com>
We need to actually check if HSTS was requested before setting the
header in the block handing PHP requests. We check in the main vhost
block, but nginx headers are only inherited if you don't set ANY
headers in child blocks (ie, headers set in parent blocks are cleared
if you set any new ones in the child).
Signed-off-by: Alan Orth <alan.orth@gmail.com>
This is really a per-site setting, so it doesn't make sense to have
a role default. Anyways, HSTS is kinda tricky and potentially dang-
erous, so unless a vhost explicitly sets it to "yes" we shouldn't
enable it.
Note: also switch from using a boolean to using a string; it is st-
ill declarative, but at least now I don't have to guess whether it
is being treated as a bool or not.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
