This reduces the time and space required to spin up a new VM.

I see little risk in using known passwords here, but it's such a bad
practice that I'd rather avoid it entirely.

(The worst case I can imagine is that a malicious process running on the
developer's workstation would be able to manipulate the configuration.)

Docker secrets cannot be changed (at least through the Ansible module)
while their are in use.

This breaks idempotency.

Ordinary firewall filtering rules, placed in iptables's "INPUT" chain in
the "filter" table, aren't applied to Docker's ingress traffic, which is
redirected ("NATted") to Docker's interface by the "PREROUTING" chain in
the "nat" table. Hence, the rules pretending to allow LOCKSS management
traffic from trusted hosts are superfluous and misleading: traffic to
those ports is instead restricted by LOCKSS according to its
"LOCKSS_ACCESS_SUBNET" variable.

I could write rules to filter Docker's ingress traffic, but I would
rather not take the time--I would need to take care that they were
always given priority over Docker's rules, even when Docker were
restarted--and LOCKSS's own handling of matters ought to be sufficient
for now.

With that, the base firewall rules (enabling a default-deny ingress
policy with an exception for ssh) seem out of scope for this role.

- Vagrantfile: Correct the path to the parsed YAML file. (This caused
  'vagrant global-status' to fail when called from outside the project's
  directory.)

- Vagrantfile: As we do not use it, disable the default sharing of the
  project's directory with the VMs.

- lockss: Use /tmp as temporary directory.

- Other trivialities.

When it already exists, the swap file managed by the role must be
excluded from the sum of memory and swap used to calculate the size of
said file.

The size of the swap file's header ought to be included in the
calculation; otherwise, the file will be slightly undersized, and the
role will re-create it at every invocation.