Put the ISO store on smaug, and add the fifth inbound rule ADR-0016 did not write down

[Gerrrt]

#413 buys and builds smaug.
ADR-0016
decides its direction of travel and writes down three inbound rules, all
host- and port-scoped.

Note

Updated 2026-09-17. As filed this issue called its rule the fourth, and
said ADR-0016's three were "deliberately not yet created". Both have moved.
The rules were created on 2026-09-16 as four — ADR-0016's three, with the
Hicks pass split into 443 and 8096 instead of carrying a port list, and
with 443 in place of the 22 that table names, because that port was an
operating-system decision and smaug runs TrueNAS
(ADR-0040).
The host is also smaug and not zion
(ADR-0038).
So the rule this issue adds is the fifth, and the count is the only thing
about it that changed.

It arrives with #440.

Why the ISO store matters more here than it looks

Packer builds consume installer ISOs, and Windows builds consume three each. On
local storage those reads land on Saruman's 7.2K mirror — the binding
constraint in every sizing decision ADR-0029 makes, and the reason the lab
domain's endpoints run per session rather than continuously.

Moving ISOs to smaug takes that load off the pool entirely, and it is a
one-time sequential read per build, so network latency costs nothing. It also
makes templates buildable from any host, which starts mattering once there are
two.

What it is not

Live VM disks stay on local storage. Network latency on random I/O would
undo everything #418's SSDs are
being fitted for. ISOs and backups only.

The rule, and why it goes in ADR-0016's list

This is Saruman on VLAN 30 reaching in to 10.0.40.30 — a fifth inbound,
host- and port-scoped rule of exactly the shape the four live ones already have.
It does not change CasaBonita's Reaches column: nothing on 40 initiates.

ADR-0013 retired rule counts
because a number cannot say where in the order a rule goes, and the four that
exist all sit above an existing Block access to CasaBonita. This one does
too, and there is now a worked example of getting that right:
build-the-nas.md §0.5 and §0.6 create four
passes in position and verify them from morpheus rather than from the UI,
because an appended rule matches nothing while looking present.

It belongs in that ADR's list rather than appended to the firewall later — which
is the failure mode #229 and
#344 both recorded, from
opposite directions.

What this now waits on

Not the host — it is built and addressed. The pool. An ISO store is a share,
and there is nothing to share from until the two Exos drives land and erebor
exists. Concretely this needs build-the-nas.md §3–§5 done, and then a decision
this issue owns: whether the ISOs sit on a dataset of their own or under
erebor/apps, and whether the share is the SMB one §5 creates or a second one
scoped to Saruman.

Purchases this needs

None beyond #413's two drives.

---

Corrected 2026-09-19

"What this now waits on: the pool" — stale; erebor and erebor/apps exist (#522). What it actually waits on is #440: an ISO store with no Packer to consume it buys nothing, so this moved to automation today.

The ordinal. This issue's "fifth inbound rule" and #523's "fifth Hicks pass" cannot both be fifth. The count is four everywhere (build-the-nas.md, security.md, network.md, stacks/media/README.md) and neither rule is written. Read this as "another inbound pass, Saruman → smaug on the share's port", and create it in the same sitting as #523's, as #523 asks.