The internal DNS server for the *pyrocufflink.blue* et al. domains runs
on the firewall now, and is thus no longer managed by Ansible. Dropping
the group variables so the file encrypted with Ansible Vault can go
away.
The `hassdb.yml` playbook is no longer used; the new Home Assistant
deployment uses the built-in database again, since it is stored on NVMe
instead of an SD card.
Further, the current deployment is hosted by a machine with a single
filesystem, which thus cannot be remounted read-only after applying
policy.
It is important that only one configuration management job run at a
time. Currently, this is enforced by having only one agent with the
*ansible* label, and that agent has only one executor. This is not an
ideal solution, because it requires maintaining a separate machine for
this purpose.
The *Lockable Resources Plugin* provides an alternate solution to this
problem. Using this plugin, jobs can acquire an exclusive lock on a
"resource" that prevents other jobs that require the same resource from
running. Any job that starts while the lock is held will wait until it
is released before executing. This will enforce the same serial
execution policy, but does not require a separate, dedicated machine.
Jobs will be able to run on any executor with the appropriate label.
Using this option, it is now possible to run configuration management
jobs on the normal agents, defining the execution environment in a
Docker image, so the *cm0.pyrocufflink.blue* agent can be
decommissioned.
Since the host *gw0* is not a member of the *pyrocufflink.blue* domain,
GSSAPI authentication does not work. As such, the SSH private key has to
be made available to the `ansible-playbook` process for authentication
to that host.
The `zabbix.yml` playbook applies to hosts that are not members of the
*pyrocufflink.blue* domain, and thus have different passwords for
`sudo`. Using the `-e` argument to `ansible-playbook` and specifying a
single Vault-encrypted file that defines the `ansible_become_password`
variable effectively forces Ansible to try to use that password on every
host. This is because variables defined on the command line, or read
from a file specified on the command line, have the highest precedence.
To use different passwords on different hosts, the normal variable
scoping rules have to be used. To that end, one `sudo-pass` file is
created in the `group_vars/pyrocufflink` directory, so it will apply to
all machines that are members of the *pyrocufflink.blue* domain.
Additionally, another `sudo-pass` file is created in the `host_vars/gw0`
directory; it will only apply to the gateway device.
Dustin