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
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.
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.
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).
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>
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>
