fleet: re-frame SureFire hosts from tenant-only to PFI-managed

Initial framing was wrong. PFI runs these under a managed-hosting
agreement: SSH, OS ops, backups are all PFI's responsibility. Hardware
and data belong to the client.

Changes:
- ssh-target files added for sfsrv-ana (root@10.250.250.115 — same
  pattern as other PVE nodes) and sf-ana-container
  (lkraven@10.250.150.100 guess, adjust if different user).
- sf-r630 still lacks an ssh-target — the OS-side LAN IP isn't in
  FortiGate DHCP (static config somewhere). Will fill in once
  identified; README flags that gap.
- READMEs rewritten: dropped "tenant-scoped" / "not SSH-managed"
  language, added "client context" section that explains the
  managed-hosting relationship. Backup coverage now listed as
  planned rather than blocked on tenant coordination.
- CLAUDE.md fleet table: SF rows re-labeled "SureFire client
  (PFI-managed)". Placement-rules section updated to note that
  SF hosts are first-class PFI-ops targets, just client-owned.
- Memory (project_surefire_tenant.md) rewritten to reflect
  managed-services reality + hosts-file entries needed for name
  resolution since these aren't in PFI DNS.
This commit is contained in:
2026-04-21 16:51:50 -07:00
parent 2cda9fd8a6
commit 017f8f9b76
6 changed files with 84 additions and 59 deletions
+4 -4
View File
@@ -62,9 +62,9 @@ Observed and standardized across servers:
| pfi-postgres | 10.250.50.80 | Anaheim | VM on pfi-pve (VMID 105) — shared Postgres (vaultwarden/gitea/paperless) | `servers/pfi-postgres/README.md` |
| ana-wg | 10.250.50.252 | Anaheim | LXC on pfi-pve (CT 113) — WireGuard | `servers/ana-wg/README.md` |
| pfi-pve | 10.250.250.31 | Anaheim | Proxmox VE hypervisor | `servers/pfi-pve/README.md` |
| sfsrv-ana | 10.250.250.115 | Anaheim | **Tenant (SureFire)** — Proxmox VE hypervisor | `servers/sfsrv-ana/README.md` |
| sf-ana-container | 10.250.150.100 | Anaheim | **Tenant (SureFire)** — container workload on sfsrv-ana | `servers/sf-ana-container/README.md` |
| sf-r630 | iDRAC 10.250.250.110 | Anaheim | **Tenant (SureFire)** — physical Dell R630, iDRAC-managed from PFI side | `servers/sf-r630/README.md` |
| sfsrv-ana | 10.250.250.115 | Anaheim | **SureFire client (PFI-managed)** — Proxmox VE hypervisor | `servers/sfsrv-ana/README.md` |
| sf-ana-container | 10.250.150.100 | Anaheim | **SureFire client (PFI-managed)** — container workload on sfsrv-ana | `servers/sf-ana-container/README.md` |
| sf-r630 | iDRAC 10.250.250.110 | Anaheim | **SureFire client (PFI-managed)** — physical Dell R630, iDRAC-managed from PFI side | `servers/sf-r630/README.md` |
| nh3-docker | 10.100.50.40 | NH3 (`10.100.0.0/16`) | General-purpose Docker host (non-GPU VM on nh3-pve) | `servers/nh3-docker/README.md` |
| nh3-pve | 10.100.250.60 | NH3 | Proxmox VE hypervisor | `servers/nh3-pve/README.md` |
| esh-docker-vm | 10.0.50.45 | ESH home lab (`esteban.net`, `10.0.50.0/24`) | Home-lab Docker host (VM on esh-pve) | `servers/esh-docker-vm/README.md` |
@@ -78,7 +78,7 @@ Observed and standardized across servers:
- NH-site non-GPU services → `nh3-docker`.
- ESH home-lab workloads (`esteban.net`) → `esh-docker-vm` (general) or `vm-esh-nas` (needs direct NFS mounts from 10.0.50.50). Not part of the PFI colo topology, but shares monitoring/backup tooling.
- Cross-site services (e.g. Beszel hub, Dozzle hub) live on `ana-docker` and pull from agents on the other hosts.
- **SureFire (SF) tenant hosts** (`sf-*`, `sfsrv-ana`) are at the Anaheim colo but PFI doesn't control the OS. Inventory only — coordinate any management with the tenant.
- **SureFire (SF) client hosts** (`sf-*`, `sfsrv-ana`) are PFI-managed under the hosting agreement — SSH, OS ops, backups are PFI's responsibility. Hardware and data belong to the client; coordinate anything that affects data with them.
- **Hypervisors** (`pfi-pve`, `nh3-pve`, `esh-pve`, `esh-pve-nas`) are tracked for inventory / capacity planning. Don't deploy Docker stacks directly on them; new workloads land as VMs. `server_inspect.sh` captures host-level detail only — VM/LXC/ZFS enumeration needs Proxmox-native tooling (`qm list`, `pvesh get …`, `zpool list`).
## How to refresh a server's state
+24 -13
View File
@@ -1,35 +1,46 @@
# sf-ana-container
**SureFire tenant workload** at the Anaheim colo — a container
host/VM running on the SureFire Proxmox (`sfsrv-ana`, 10.250.250.115).
SureFire-client container workload running on `sfsrv-ana` (SureFire's
Proxmox at 10.250.250.115). **PFI-managed** under the hosting
agreement.
## Tenancy
## Client context
- **Owner:** SureFire (tenant)
- **PFI role:** hosting provider
- **Management scope:** coordinate with SureFire before any action
- **Client:** SureFire
- **PFI role:** full-service managed host
## Network
- **LAN IP:** 10.250.150.100
- **SSH:** not wired — tenant equipment.
- **FQDN:** not in DNS yet — add to workstation `/etc/hosts`:
```
10.250.150.100 sf-ana-container
```
- **SSH:** `lkraven@10.250.150.100` (guess — adjust if a different
user owns the container's ssh config)
## Infrastructure
- **Hypervisor:** `sfsrv-ana` (SureFire Proxmox, 10.250.250.115)
- **Site:** Anaheim (PFI colo)
- **Subnet:** `10.250.150.0/24` — dedicated SureFire container subnet
- **Subnet:** `10.250.150.0/24` — dedicated SF container subnet
## Role
Container/workload host for SureFire. Specific services aren't
documented here (not PFI equipment).
Container/VM workload for SureFire. Specific services TBD — refresh
the server-info snapshot once SSH is verified:
```bash
scripts/refresh-server-info.sh sf-ana-container
```
## Backup coverage
- **Not currently backed up by the PFI fleet.** Needs coverage plan —
see `servers/sfsrv-ana/README.md` for the three approaches under
discussion.
- **VM-image via sfsrv-ana vzdump:** status unknown — depends on what
backup jobs are configured on that Proxmox. Audit via
`scripts/refresh-proxmox-info.sh sfsrv-ana`.
- **File-level restic:** not yet configured — worth adding once we
know what state the container runs (DBs, configs, app data).
## Discovered via
+1
View File
@@ -0,0 +1 @@
lkraven@10.250.150.100
+26 -17
View File
@@ -1,36 +1,45 @@
# sf-r630
**SureFire tenant physical server** at the Anaheim colo — Dell
PowerEdge R630. Owner operates the OS; PFI provides rack + network.
SureFire-client physical server at the Anaheim colo — Dell PowerEdge
R630. **PFI-managed** under the hosting agreement (hardware + OS ops).
## Tenancy
## Client context
- **Owner:** SureFire (tenant)
- **PFI role:** hosting provider
- **Client:** SureFire
- **PFI role:** full-service managed host
## Network
- **iDRAC BMC IP:** 10.250.250.110 (on the management subnet)
- **OS-side LAN IP:** unknown — not surfaced via our DHCP discovery.
May be static, on a non-DHCP interface, or assigned to a different
subnet served by SureFire's own gear.
- **iDRAC Web UI:** https://10.250.250.110/
- Web UI: https://10.250.250.110/
- **OS-side LAN IP:** **unknown** — not in FortiGate DHCP (static
config?). Fill this in once identified.
- **SSH:** no `ssh-target` set yet because the OS IP isn't known. Add
one (e.g. `root@<ip>` or `lkraven@<ip>`) once identified.
## Infrastructure
- **Type:** Physical Dell PowerEdge R630
- **Site:** Anaheim (PFI colo)
- **Management:** iDRAC only from the PFI side (power, console, hardware
health). OS-level access is tenant-scoped.
## Backup coverage
- Not applicable from the PFI side — tenant equipment. If hosting
terms require PFI to provide backup, coordinate with SureFire on
in-VM or OS-agent approach.
- **VM-image:** N/A (bare-metal physical)
- **File-level restic:** not yet configured
- Pending OS identification + SSH access
- Follow the `configs/restic/ana-ml2/` template when setting up
(both are bare-metal hosts; similar source list + no DB hooks by
default unless SF apps run databases)
## Refresh state
Once the OS IP is known and an `ssh-target` is in place:
```bash
scripts/refresh-server-info.sh sf-r630
```
## Discovered via
`scripts/discover-fortigate.sh 10.250.250.1` on 2026-04-21 — DHCP
lease on the management interface (MAC `74:e6:e2:fe:2c:7c`, VCI
`iDRAC`).
`scripts/discover-fortigate.sh 10.250.250.1` on 2026-04-21 — iDRAC's
DHCP lease on the management interface (MAC `74:e6:e2:fe:2c:7c`,
VCI `iDRAC`).
+28 -25
View File
@@ -1,49 +1,52 @@
# sfsrv-ana
**SureFire tenant Proxmox host** at the Anaheim colo. Third-party
equipment / workload — tracked here for inventory, backup coverage,
and network awareness.
SureFire-client Proxmox hypervisor at the Anaheim colo. Client-owned
equipment but **PFI-managed** under the hosting agreement — we have SSH
and are responsible for operations.
## Tenancy
## Client context
- **Owner:** SureFire (tenant)
- **PFI role:** hosting provider — provides rack, power, network
- **Management scope:** coordinate with SureFire before any action
- **Client:** SureFire (SF prefix is SF-client hosts)
- **PFI role:** full-service managed host (rack, power, network, OS
ops, backups)
## Network
- **LAN IP:** 10.250.250.115
- **FQDN:** not yet in DNS / `/etc/hosts` — add a line to the
workstation's hosts file to make short-name resolution work:
```
10.250.250.115 sfsrv-ana
```
- **Web UI:** https://10.250.250.115:8006 (Proxmox VE)
- **SSH:** not currently wired into this workspace (tenant equipment).
If PFI ever gains admin access, add `ssh-target` here.
- **SSH:** `root@10.250.250.115` (key auth — same pattern as other PVE nodes)
## Infrastructure
- **Type:** Proxmox VE hypervisor (bare metal)
- **Site:** Anaheim (PFI colo)
Hosts SureFire's own VMs, including:
- `sf-ana-container` (10.250.150.100) on the container subnet
Hosts SureFire's VMs, including:
- `sf-ana-container` (10.250.150.100) on the dedicated SF container subnet
## Backup coverage
- **Not currently backed up by the PFI fleet.**
- User flagged this as **needing coverage** — open plan item. Options:
1. Coordinate tenant-side backup of SureFire VMs using their own
target.
2. If PFI is responsible for backups of tenant workloads under the
hosting agreement, deploy restic clients to SureFire VMs writing
into a segregated repo on `rest-server-ana` (e.g. a dedicated
htpasswd user + encryption key scoped to SureFire).
3. File-level Proxmox vzdump into shared NAS storage, same pattern
as pfi-pve.
- Decision pending.
- **VM-image:** status unknown — probe with
`scripts/refresh-proxmox-info.sh sfsrv-ana` once SSH is verified.
If no vzdump jobs are configured, set them up the same as pfi-pve
(daily 01:00 into a network target).
- **File-level restic:** not yet configured.
This is on the open work list — once we've validated SSH + refreshed
the Proxmox snapshot, add a `configs/restic/sfsrv-ana/` profile if
it's running hosted workloads whose state we care about beyond the
VM-image layer.
## Refresh state
Not wired into `refresh-proxmox-info.sh` — would require SSH access as
root (same flow as pfi-pve / nh3-pve / etc.). Add an `ssh-target` when
ready.
```bash
scripts/refresh-proxmox-info.sh sfsrv-ana
```
## Discovered via
+1
View File
@@ -0,0 +1 @@
root@10.250.250.115