This is not worthy of production, but I found it useful for monitoring
certain things while I developed this project.

I found this to be most useful when I was trying to find things in the
LOCKSS codebase.

Docker forbids updating configurations and secrets: to replace one, one
must either create the replacement with a new name or delete and
recreate the configuration or secret, which requires stopping any
containers that use it.

This change modifies the Docker Stack deployment to give each
configuration a name derived from a hash of its contents. This allows
running stacks to be updated while preserving idempotency.

This also changes some tasks to prevent them from unnecessarily
reporting changed status, making this role idempotent.

This moves most of the code into a standalone (at least in principle)
"http_frontend" role and invokes it from the main LOCKSS role.

This creates a service that listens on (by default) port 80 and maps
LOCKSS's many Web interfaces, each listening on a different port, to
paths under a single base. For example:

    http://lockss.test/crawler -> http://lockss.test:24631

This is not ready for production. The remaining tasks are as follows:

- Turn the front-end into a proper Docker image and service. (It should
  include a health check.)

- Merge the lockss-config-frontend into the main lockss role.

- Remove from the firewall rules access to the other administrative
  ports that are now accessed through this.

- Document the front-end paths. Or, better yet, write a landing page
  that lists them all.

Among other things, this version uses Docker's host-based networking
rather than the ingress network. This simplifies the networking setup,
but I'm leaving ferm in place because it is easier to configure than ufw
or firewalld, and we may need to switch back again.

This caused a problem with the LOCKSS 2.0-alpha2 configuration, where
LOCKSS_ACCESS_SUBNET used semicolons to separate values, but it should
be done generally.

See IEEE, POSIX.1-2017—Base Definitions § 3.206.

It's too slow to be worthwhile.

This skips several tasks that fail, at least in some conditions, when
run in check mode but not when run in normal mode.

As I noted in an earlier commit, restricting Docker's ingress traffic is
more complicated than adding a few rules to the filter table's INPUT
chain. I had thought that relying on LOCKSS's "LOCKSS_ACCESS_SUBNET"
variable would be sufficient; unfortunately, that is not the case:
LOCKSS sees all of its traffic as coming from the Docker overlay network
(by default, 10.0.0.0/8), regardless of its true origin.

Fortunately for us, Docker provides us with a chain, DOCKER-USER, called
by Docker's rules from the FORWARD chain in the filter table, that is
suitable for filtering Docker's ingress traffic.

Accordingly, this commit:

- Removes the misleadingly ineffective 'lockss_trusted_ips' variable and
  provides new variables 'lockss_network_ips' and 'lockss_admin_ips'.

- Replaces ufw or firewalld with ferm. Neither ufw nor firewalld is
  capable of satisfying this use case without employing significant
  violence; ferm is elegant and has beautiful configuration files.
  Beauty over bloodshed.

- Adds tasks to configure a local firewall that denies inbound and
  forwarded traffic by default, permits ssh from anywhere, and permits
  access to LOCKSS's data and configuration ports from
  'lockss_network_ips' and 'lockss_admin_ips' respectively.

  Said firewall cooperates with Docker: Docker and the firewall can be
  started in any order, and restarting either preserves rules created by
  the other.

                                *  *  *

I got the suggestion of using ferm for this, as well as the bulk of the
Docker-related rules, from a blog post: Ben Chavet, Convincing Docker
and Iptables to Play Nicely, Aug. 8, 2019,
<https://www.lullabot.com/articles/convincing-docker-and-iptables-play-nicely>.

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.