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