# SGPT REVIEW REQUEST — WO-NYC-SSD-01-PRODUCTION-001
# Filed: AT 2026-05-07 | CC | For SGPT GO/NO-GO verdict
# Canonical inbox copy. Legacy pointer at /ops/mcp/SGPT_INBOX.md.
# ══════════════════════════════════════════════════════════════════════

## ASK

Review WO-NYC-SSD-01-PRODUCTION-001 (production onboarding of
nyc-ssd-01.verity.one) and return a GO / NO-GO verdict with
redlines on any concerns. CC will not dispatch SC until SGPT
GO is received per PTF-200 (SGPT→CC→SC).

## CONTEXT

AR directive 2026-05-07: build tunnel from 19a (a02) to
nyc-ssd-01, land backups of pot-01, wk_veritize, and wk_miusa
on nyc-ssd-01, install Fail2ban, harden for production. AR
described nyc-ssd-01 as a "substantional server" being
prepared for production, signaling P0 priority.

WO covers four buckets: tunnel (WireGuard), backups
(rsync + pg_dump), Fail2ban, production hardening (UFW,
SSH key-only, Webmin rotation, unattended-upgrades, time
sync, monitoring).

## PRIMARY REVIEW AREAS

SGPT focus areas — please explicitly verdict each:

### R1. WireGuard topology

Proposed:
- Tunnel subnet `10.200.0.0/24`
- a02 side: `10.200.0.1/24`
- nyc-ssd-01 side: `10.200.0.2/24`
- Listen port: TBD, populated to vault `WG_TUNNEL_PORT`

**SGPT verdict:**
- Subnet conflict check vs. existing VPCs? DO VPC for Verity
  fleet is `10.116.0.0/24` (per vault). Anchor-01 is
  `10.10.0.0/24` (per vault). `10.200.0.0/24` should not
  overlap. Confirm no other VPC or tunnel is using
  `10.200.0.0/24` already.
- AllowedIPs scoping — proposed `/32` on each side restricts
  the tunnel to peer-only routing. Confirm this is correct
  for the backup-only use case (no need to route arbitrary
  internal traffic through the tunnel).
- Persistence — `wg-quick@wg0` systemd unit on both sides.
  Confirm acceptable.

### R2. Backup transport scope

Proposed sources:
- pot-01 → `/opt/`, `/etc/`, application state
- wksvr → `/opt/production/{veritize,miusa}/addons/`,
  Odoo filestore for wk_veritize and wk_miusa,
  `/etc/odoo*`, nginx site configs
- DO Managed PG → `pg_dump` of `wk_veritize` and `wk_miusa`
  from `$DO_PG_HOST`

**SGPT verdict:**
- Source-server impact: rsync from wksvr during backup
  windows — confirm 02:00 UTC (22:00 ET) is outside peak
  Odoo activity. Acceptable bandwidth impact.
- pot-01 wallet/key materials: confirm the rsync includes
  these encrypted at rest, and that they are NOT exposed
  to nyc-ssd-01 in plaintext during transport. Tunnel
  encryption + at-rest encryption acceptable, or do we
  need a separate signed-archive flow?
- DO Managed PG egress: `pg_dump` from outside DO incurs
  egress on DO's side. Quantify expected daily dump size
  for wk_veritize and wk_miusa.
- pg_dump format: proposed `-Fc` (custom format,
  compressed). Confirm or recommend `-Fd` (directory) for
  parallelism.

### R3. Fail2ban posture

Proposed jails:
- `[sshd]` — 5 retries / 10 min / 1 hour ban
- `[webmin-auth]` — custom jail on
  `/var/webmin/miniserv.log`
- a02 WireGuard side `10.200.0.1/32` whitelisted

**SGPT verdict:**
- Path of `/var/webmin/miniserv.log` — confirm correct path
  for Webmin 2.640. Some installs use
  `/var/log/webmin/miniserv.log`.
- Whitelist scope: a02 reaches nyc-ssd-01 via public IP for
  the Phase 3a SSH bootstrap (before WG is up). Confirm
  whether to whitelist a02's public IP `104.248.63.137`
  during bootstrap and remove after WG verified, or
  whitelist permanently.
- Recidive jail: should we add `[recidive]` to escalate
  repeat offenders? Default for production posture.

### R4. UFW firewall posture

Proposed:
- Default deny incoming
- Allow 22/tcp, 10000/tcp restricted to a02 IP + AR IPs (if
  in vault)
- Allow WireGuard listen port UDP from a02 only

**SGPT verdict:**
- AR IP whitelist source — vault doesn't currently contain
  AR's home/office static IPs. Recommend prompting AR to
  add `AR_ADMIN_IP_HOME` and `AR_ADMIN_IP_OFFICE` (if
  static) to vault before locking down 22/tcp and 10000/tcp,
  to avoid AR lockout.
- Webmin port 10000 — confirm whether to keep on 10000 or
  move to a non-standard port behind the firewall. Default
  port is widely scanned.

### R5. SSH hardening sequencing

Proposed sequence:
1. Phase 3a: SSH key bootstrap (a02 → nyc-ssd-01 via root
   password)
2. Phase 3i: SSH config to PasswordAuthentication no
3. Verify key auth still works
4. Optional: AR rotates / removes `NYC_SSD_01_PASS` from
   vault

**SGPT verdict:**
- Confirm the order. Specifically: do NOT disable password
  auth before key auth is verified working from a02. SC
  should keep an active root SSH session open during the
  config change as a safety net.
- Webmin: does disabling SSH password auth affect Webmin
  login? Webmin has independent auth, so no — but confirm.

### R6. Restore verification

Proposed:
- Spin up temp PostgreSQL on nyc-ssd-01
- Load wk_veritize + wk_miusa dumps
- Confirm row counts match production
- Tear down test PG

**SGPT verdict:**
- Row-count comparison — which tables to compare? Suggest
  `res_users`, `res_company`, `product_product`,
  `sale_order`, `account_move` as canonical tables, plus
  Veritize-specific tables (`verity_affiliate_*`).
- Restore PG instance: which port, which user, isolated
  from production?
- Frequency: one-time on initial backup, or recurring weekly
  restore-test?

### R7. Monitoring hookup

Proposed: add nyc-ssd-01 to existing ops-center on a02; read
backup-run logs over the tunnel.

**SGPT verdict:**
- Confirm ops-center is the canonical monitoring surface
  (it is per memory). Identify the integration point: file
  read over WG, or nyc-ssd-01 pushes a heartbeat?
- Alert routing: where do failures go? AR via VIRA? Email?
  Slack?

### R8. Vault standardization

Proposed Phase 2: add standardized variable names
(`NYC_SSD_01_*`, `WG_TUNNEL_PORT`, etc.) to vault.env without
changing values, per vault rule 6.

**SGPT verdict:**
- CC adds variable names; SC may also per rule 6. Confirm
  the canonical owner.
- Loose-format current entry stays in place (do not delete)
  to avoid disrupting any existing ad-hoc reference.

## ROLLBACK POSTURE

Already documented in WO. SGPT to confirm rollback is
trivial up to Phase 5 (cutover), and that any phase can be
aborted without production data risk on source servers
(rsync is read-only against sources; pg_dump is read-only
against DO Managed PG).

## VERDICT REQUESTED

Please return one of:
- **GO** — ready for CC to proceed to Phase 2 (vault
  standardization) and then dispatch SC for Phase 3a.
- **GO WITH REDLINES** — list redlines; CC addresses and
  re-submits.
- **NO-GO** — list blocking concerns; CC re-plans.

Filed at canonical SGPT inbox per dual-write protocol.
Legacy pointer updated at `/ops/mcp/SGPT_INBOX.md`.

TRUTH MATTERS®