It is reported ok and described as expected, under a heading saying
"unclaimed". A heading that disagrees with the line beneath it is read first,
and the reader who acts on it is acting on the wrong one - which is how the
last two problems on this host started.
Following the previous advice left a config with an empty bridge, which is
worse than the leftover rules it was meant to tidy and for a reason the advice
did not consider.
Every rule in DEJIMA-CI-FWD names an interface. A bridge with no rules matches
nothing, falls off the end of the chain, returns to DOCKER-USER and gets
Docker's default, which accepts. So clearing 'bridge' did not stop that network
being used; it stopped it being filtered. Anything landing there - a runner made
without --pool, a container left behind - has unrestricted egress, on a host
whose whole subject is not having that.
That is the second reason the shared network is not retirable. The first was the
resolver address. Both are easy to meet and neither names itself: one shows up
as jobs failing in apt, the other as nothing at all.
So verify reports the shared bridge as expected rather than as something to
tidy, and no longer offers either half of removing it. And it checks the
dangerous direction, which it had not been looking at: a network that exists
whose bridge has no rules. Rules without a network are harmless and were already
reported; a network without rules is the one that fails open, and it is
invisible because the network works and the jobs pass.
Reported from following the advice. dnsmasq listens on the gateway address of
the SHARED network, and every pool's runners are given that address as --dns. So
`docker network rm` on it, which verify suggested for a bridge with nothing on
it, took DNS away from every pool at once. The symptom is jobs failing in apt,
which names nothing that would lead anybody back here.
The shared network carries no jobs once every pool has its own, and that is what
made it look retirable. What it still carries is the address the resolver
answers on, which is the one thing about it that has nothing to do with pools.
Verify recognises a bridge holding the gateway address and says to keep the
network, offering only the half that is safe: clearing 'bridge' so no rules are
written for it. It also checks that address exists at all, first, because losing
it breaks every pool and nothing else in the report would show why. That check
prints the command that puts the network back.
The upgrade note says the same, since an operator reasoning from "no jobs are on
it" would reach the same wrong conclusion the tool did.
The retire advice from the previous commit told an operator to remove the bridge
from the config's bridge line, which leaves an empty value, and the firewall
refused to start on one. So following the advice took a host from "leftover
rules on an unused interface" to "no egress rules at all until you put the value
back", which is a worse place to be than the note was about.
`bridge` names the shared network from before pools existed. On a host whose
pools all have networks of their own there is nothing left on it, and requiring
it meant the only way to keep the firewall running was to leave a value naming
an interface nothing uses. It may be empty now, and what is refused is having no
bridge from EITHER source: the config's, or a pool's.
The advice says to clear the value rather than to remove it from the line, and
says an empty one is fine once every pool has a network, since that is the part
an operator has no way to know.
Found while moving the existence check: it ran before the pools file was read,
so it only ever covered the configured bridge. A pool whose network had never
been created got rules naming an interface that is not there, which iptables
accepts without complaint - leaving that pool's jobs on a bridge with no rules
at all. It runs over every bridge from both sources now, and says which of the
two to fix.
TWO THINGS, BOTH FROM RUNNING IT. Verify reported the pre-pools bridge as a
problem when it is not one, and getting the new verify onto the host meant a
full installer run for a change that only replaced binaries.
--tools deploys the programs, the templates and the upgrade notes, records the
guest version, and stops. Most upgrades change only what is in bin/, and running
the whole installer to put them there means answering prompts about a network, a
resolver and a token that are already correct: tedious, and a chance to change
one of them by accident, which is how a re-run for one reason becomes a
re-registration of something else. On a host with no config it refuses, since
programs with nothing to read are worse installed than not.
Verify now tells an unclaimed bridge with jobs on it from one with none. The
first is a finding: containers on a bridge no pool describes are jobs running
under an allowlist nothing here decided. The second is untidy rather than
unsafe, so it prints as a note and does not fail the run - a verifier that cries
about leftovers is one whose real findings get skimmed past. Both say what to do,
and the pre-pools shared bridge is named as what it is rather than as a pool
somebody deleted.
The deployment blocks became a function so both paths use one copy, which also
means --tools cannot drift from what a full run installs.
branderson