I downloaded the key and checked the fingerprint with gpg:
$ gpg --dry-run --import mariadb_release_signing_key.asc
gpg: key F1656F24C74CD1D8: 6 signatures not checked due to missing keys
gpg: Total number processed: 1
We can register changes when adding repositories and keys and then
update the apt package index conditionally. This should make it be
more consistent between initial host setup and subsequent re-runs.
Ansible 2.4 and 2.5 are moving away from specialized loop functions
and the old syntax will eventually be deprecated and removed. I did
not change the with_fileglob loops because I'm not sure about their
syntax yet.
See: https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html
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.
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 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
For idempotence we need to run all apt-related tasks, like editing
source files, adding keys, installing packages, etc, when running
the 'packages' tag.
When you use the apt_repository module it adds a sources.list with
an annoying filename, and also it's just easier to use a template
when we have different distros/versions to support.
Ansible's mysql module can get this password and connect fine, but
`mysql` on the command line chokes if the password is slightly
complicated and is not quoted.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Relies on the host having a dict with appropriate values defined,
for example:
wordpress_blogs:
- site_name: blah.com
wordpress_version: 3.9.2
wordpress_db_user: db_user
wordpress_db_name: db_name
wordpress_db_pass: V9&XvvKu1hYl
Signed-off-by: Alan Orth <alan.orth@gmail.com>
