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.

CLAUDE.md

@@ -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` |
+| 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 | **Tenant (SureFire)** — container workload on sfsrv-ana | `servers/sf-ana-container/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 | **Tenant (SureFire)** — physical Dell R630, iDRAC-managed from PFI side | `servers/sf-r630/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

servers/sf-ana-container/README.md

@@ -1,35 +1,46 @@
 # sf-ana-container
 
-**SureFire tenant workload** at the Anaheim colo — a container
+SureFire-client container workload running on `sfsrv-ana` (SureFire's
-host/VM running on the SureFire Proxmox (`sfsrv-ana`, 10.250.250.115).
+Proxmox at 10.250.250.115). **PFI-managed** under the hosting
+agreement.
 
-## Tenancy
+## Client context
 
-- **Owner:** SureFire (tenant)
+- **Client:** SureFire
-- **PFI role:** hosting provider
+- **PFI role:** full-service managed host
-- **Management scope:** coordinate with SureFire before any action
 
 ## 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
+Container/VM workload for SureFire. Specific services TBD — refresh
-documented here (not PFI equipment).
+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 —
+- **VM-image via sfsrv-ana vzdump:** status unknown — depends on what
-  see `servers/sfsrv-ana/README.md` for the three approaches under
+  backup jobs are configured on that Proxmox. Audit via
-  discussion.
+  `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
 

servers/sf-ana-container/ssh-target

@@ -0,0 +1 @@
+lkraven@10.250.150.100

servers/sf-r630/README.md

@@ -1,36 +1,45 @@
 # sf-r630
 
-**SureFire tenant physical server** at the Anaheim colo — Dell
+SureFire-client physical server at the Anaheim colo — Dell PowerEdge
-PowerEdge R630. Owner operates the OS; PFI provides rack + network.
+R630. **PFI-managed** under the hosting agreement (hardware + OS ops).
 
-## Tenancy
+## Client context
 
-- **Owner:** SureFire (tenant)
+- **Client:** SureFire
-- **PFI role:** hosting provider
+- **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.
+  - Web UI: https://10.250.250.110/
-  May be static, on a non-DHCP interface, or assigned to a different
+- **OS-side LAN IP:** **unknown** — not in FortiGate DHCP (static
-  subnet served by SureFire's own gear.
+  config?). Fill this in once identified.
-- **iDRAC Web UI:** https://10.250.250.110/
+- **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
+- **VM-image:** N/A (bare-metal physical)
-  terms require PFI to provide backup, coordinate with SureFire on
+- **File-level restic:** not yet configured
-  in-VM or OS-agent approach.
+  - 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
+`scripts/discover-fortigate.sh 10.250.250.1` on 2026-04-21 — iDRAC's
-lease on the management interface (MAC `74:e6:e2:fe:2c:7c`, VCI
+DHCP lease on the management interface (MAC `74:e6:e2:fe:2c:7c`,
-`iDRAC`).
+VCI `iDRAC`).

servers/sfsrv-ana/README.md

@@ -1,49 +1,52 @@
 # sfsrv-ana
 
-**SureFire tenant Proxmox host** at the Anaheim colo. Third-party
+SureFire-client Proxmox hypervisor at the Anaheim colo. Client-owned
-equipment / workload — tracked here for inventory, backup coverage,
+equipment but **PFI-managed** under the hosting agreement — we have SSH
-and network awareness.
+and are responsible for operations.
 
-## Tenancy
+## Client context
 
-- **Owner:** SureFire (tenant)
+- **Client:** SureFire (SF prefix is SF-client hosts)
-- **PFI role:** hosting provider — provides rack, power, network
+- **PFI role:** full-service managed host (rack, power, network, OS
-- **Management scope:** coordinate with SureFire before any action
+  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).
+- **SSH:** `root@10.250.250.115` (key auth — same pattern as other PVE nodes)
-  If PFI ever gains admin access, add `ssh-target` here.
 
 ## Infrastructure
 
 - **Type:** Proxmox VE hypervisor (bare metal)
 - **Site:** Anaheim (PFI colo)
 
-Hosts SureFire's own VMs, including:
+Hosts SureFire's VMs, including:
-- `sf-ana-container` (10.250.150.100) on the container subnet
+- `sf-ana-container` (10.250.150.100) on the dedicated SF container subnet
 
 ## Backup coverage
 
-- **Not currently backed up by the PFI fleet.**
+- **VM-image:** status unknown — probe with
-- User flagged this as **needing coverage** — open plan item. Options:
+  `scripts/refresh-proxmox-info.sh sfsrv-ana` once SSH is verified.
-  1. Coordinate tenant-side backup of SureFire VMs using their own
+  If no vzdump jobs are configured, set them up the same as pfi-pve
-     target.
+  (daily 01:00 into a network target).
-  2. If PFI is responsible for backups of tenant workloads under the
+- **File-level restic:** not yet configured.
-     hosting agreement, deploy restic clients to SureFire VMs writing
+
-     into a segregated repo on `rest-server-ana` (e.g. a dedicated
+This is on the open work list — once we've validated SSH + refreshed
-     htpasswd user + encryption key scoped to SureFire).
+the Proxmox snapshot, add a `configs/restic/sfsrv-ana/` profile if
-  3. File-level Proxmox vzdump into shared NAS storage, same pattern
+it's running hosted workloads whose state we care about beyond the
-     as pfi-pve.
+VM-image layer.
-- Decision pending.
 
 ## Refresh state
 
-Not wired into `refresh-proxmox-info.sh` — would require SSH access as
+```bash
-root (same flow as pfi-pve / nh3-pve / etc.). Add an `ssh-target` when
+scripts/refresh-proxmox-info.sh sfsrv-ana
-ready.
+```
 
 ## Discovered via
 

servers/sfsrv-ana/ssh-target

@@ -0,0 +1 @@
+root@10.250.250.115