Files
esh-pfi-infrastructure/docs
vh fb91ea759e docs(pfi): lesson 10 -- v6 collapses two exposure controls into one
Operator's framing, and it is a better argument than the terminology
correction that preceded it. Under v4, exposing a host needed two
affirmative acts -- a DNAT and an accept rule -- so missing either left
the host dark. There is no v4 misconfiguration that exposes an internal
host by accident. NAT was load-bearing security whether or not anyone
designed it that way.

v6 removes the first control entirely. The path exists inherently, so
the firewall is the only thing left, and the failure mode inverts from
fail-closed to fail-open. Rule-ordering slips, rulesets that silently
match only one address family, new VLANs added without policy, and
re-delegated prefixes unmatching address-literal rules all become
exposure events rather than no-ops.

Records the practical consequences: key rules on interface/zone rather
than address literals, treat enabling v6 on a segment as requiring
policy to exist first, and verify default-deny from off-net rather than
by reading the ruleset -- which is lesson 3's assert-the-effective-value
discipline applied to firewall policy.

Also corrects my own claim from the previous commit that the pending
firewall pass was 'smaller' than I had implied. It is not smaller, it is
different in kind.
2026-08-18 13:41:23 -07:00
..

docs/

Navigation map for the documentation tree. New session? Read orientation.md first — it's the narrative overview of the fleet, backup architecture, governing principles, and gotchas, and it points at everything else.

Tree

docs/
├── orientation.md            # start here — fleet overview + where-to-look guide
├── runbooks/                 # ops runbooks (recovery, deployment phases)
│   ├── disaster-recovery.md
│   ├── nh3-prune-ritual.md
│   └── pbs-deployment.md
└── pfi/                      # PFI-specific reference (services, models, VMs)
    ├── docker-stack.md
    ├── model-list.md
    ├── proxmox-vms.md
    ├── recommended-model-settings.md
    ├── vm-102-matrix-appservice.md
    └── vm-102-matrix-synapse.md

What goes where

  • runbooks/ — step-by-step ops procedures. Anything you'd reach for during an incident or while standing up new infrastructure. Examples: disaster recovery (blast-radius tiers + restoration steps), PBS deployment (9-phase rollout). New runbook → new file here.
  • pfi/ — PFI-specific reference material that's too narrow for the top-level CLAUDE.md but doesn't change incident response. AI model inventory, recommended inference settings, Matrix bridge config, Proxmox VM map. New stable reference → new file here.
  • Top-level (docs/orientation.md, docs/README.md) — narrative guides about the workspace itself, not about specific infra.

Cross-references

  • Fleet topology + servers table: top-level CLAUDE.md.
  • Open work + recent milestones: top-level STATUS.md.
  • Durable cross-session facts: ~/.claude/projects/-home-lkraven-development-eshpfi-management/memory/.

Conventions

  • Markdown, GitHub-flavored. CommonMark renders fine in most viewers.
  • File names are lowercase-kebab-case, descriptive. No dates in filenames — git history covers that.
  • One topic per file. If a file grows past ~500 lines, look for a natural split before adding more.
  • No checked-in binaries or checksums. Build/release artifacts belong in a build pipeline or tools/, not docs/.