Unverified Commit faa508e8 authored by Lemon-miaow's avatar Lemon-miaow
Browse files

docs(audit): operator self-healing postmortem — ledger #26/#27 with live drills 

RCON-secret deletion lockup and the stale start anchor (with its permanent
Provisioned=False) get their full live evidence trail, plus the sts
accidental-deletion drill. Deployed image note bumped to auditfix24.
parent 82b5a606

AUDIT-2026-09-22.md

+10 −1
Changes for AUDIT-2026-09-22.md: 10 added lines, 1 removed line.
Original line number Diff line number Diff line
@@ -27,6 +27,8 @@ IPv6-only 接入（`ssh -6 -i ~/.ssh/id_ed25519 root@fdb2:2c26:f4e4:0:21c:42ff:f 
| 23 | **配额门非原子 + storage 缓存被清零**：(a) audit #4：`QuotaCheck` 与 `ClaimServer` 两条语句，同一用户并发认领两台无主服可双双通过 `max_servers`（deferred-seams 曾把这条挂为“只能在真 PG 上关闭”）；(b) 更隐蔽：PATCH 资源时 `UpdateServerResources(..., 0)` 把本不能改的 storage 缓存写 0，而缓存列是配额聚合的**唯一**输入 → 此后该服的 storage 维度在配额里凭空消失 | (a) 新增 pgint 并发测试：修复前两台全赢；修复后恰 1 赢 + 1 `ErrQuotaExceeded`，DB 只 1 行 owned；(b) hermetic 测试 `TestPatchServerPreservesStorageCache`（修复前 `resourceUpdates` 里 storage=0） | (a) 门槛进 `ClaimServer`：同一事务内 `pg_advisory_xact_lock(hashtext(user_id))` + 四维重查（与 `QuotaCheck` 共用 `quotaAllows` 防漂移）+ 行 `FOR UPDATE`，两个 claim handler 把 `ErrQuotaExceeded` 映射为与串行一致的 403；(b) resize 前读取现值并透传 storage。提交 `bb68fef`；deferred-seams 对应条目核销 |

| 24 | **reaper 警告信从不真正投递**：`felis reaper` 从不装配任何 Warner（`r.Warner` 恒 nil），而 `maybeWarn` 对 nil warner / 投递失败一律照样 `MarkWarned` + `warned++` → 每位有主的服都在**无人收到提醒**的情况下 15 天后被静默回收，跑批日志还谎报"已警告 N 台"。红线⑤的"best-effort 不阻塞回收"被误读成了"失败也要记成已通知" | hermetic 单测 3 例（坏 notifier / nil warner → 不盖章、成功才盖章）。真机 drill（auditfix20）：13d idle 实收 1 封（收件人=owner 的验证邮箱、subject 含 3d）；重跑不重发；14.5d 补发 1d（elif 档位）；SMTP 端口打坏 → 日志 `warn delivery failed; will retry next run` 且**不盖章**，恢复后补发；邮箱未验证 → `has no verified email` 不盖章；owner NULL → 静默跳过；边界 11d23h 不发 / 12d1m 发；全程 `world_backups` 保持 4 条不动（纯警告零备份副作用） | `mail.SendNotice` + `mailWarner`：查 owner 的 verified email → `SendNotice`；nil/失败不盖章、下次重试；reaper pod 模板加 optional `FELIS_SMTP_PASSWORD` env；`felis setup` 复制 felis-smtp 镜像并在「configure email」刷新 minecraft ns 的 felis-smtp+felis-config 镜像；docs/troubleshooting §10 更新。提交 `8e7c7bb` |

| 25 | **idle auto-stop 从未触发（三层复合缺陷）**：条件齐备的空载服永远不停。① CRD status schema 未声明 `emptySince`，apiserver **pruning** 掉计时戳（`unknown field "status.emptySince"`），计时器每次读回都是 nil；② 即使戳幸存，Running 空载稳态**没有任何 watch 事件**（玩家进出不碰 CRD、RCON 只在 Reconcile 内探），盖章一次后 reconcile 链停摆，无人叫醒；③ auto-stop 用整对象 `Update` 写 spec 且 OperatorRole 从未有 `minecraftservers:patch/update` → 403 `cannot update resource`。三层任一都让功能永久失效，而单测（fake client 不剪 schema、手动驱动、无 RBAC）全部覆盖不到 | 真机逐层实锤：schema 修复后 `empty=2026-09-22T20:02:13Z` 首次成功持久化；静置 88s+ 无动作、operator 日志 90s 零行（②实锤）；修复前日志 5 条 403（③实锤）；全修后场景 1：超时戳触发即 Stopped；场景 2：起服 → 20:11:43 盖章 → **全程无干预** → 20:12:17 自动 Stopped；翻转 Running→Stopped→Running 收敛 Running；`idle=null` 后不再自停 | ① schema 补 `emptySince`（`c04a3f0`）；② `reconcileRunning` 尾部返回 RequeueAfter——空载=到点精确唤醒、有人=30s 探针周期，+3 个单测（`1c89a5e`）；③ auto-stop 改 merge-patch（防 status clobber，与 reaper 的 Stop 同型）+ OperatorRole 补 `patch` + rbac 测试锚点（`f650bf8`）。真机 auditfix22 全通；troubleshooting §11 增自检三连 |

| 26 | **RCON Secret 被删 → 服务器永久锁死**：删掉 per-server RCON 密码 Secret 后，(a) operator 没有任何 watch 能看到删除（Running 稳态零事件），secret 一直不重建；(b) 一旦被任意事件带到 reconcile：新密码铸造成功，但运行中的 pod 仍持有旧密码、sts 模板无变化 → pod 永不重启 → 探针用新密码连旧密码 pod，**永久 `RconNotReachable`** 直至 300s `ReadinessTimeout`；恢复只有人工删 pod。`ensureRconSecret` 的注释却声称"heals on the next pass" | 真机：删 secret 后静置 60s 无重建、无日志；annotate 触发后 96s+ 持续 RconNotReachable（新密码 `91dd62…` vs pod 旧密码）；删 pod 后 17s 恢复 Running——根因=密码漂移实锤 | ① `SetupWithManager` 增 `Owns(&corev1.Secret{})`（controller-owned，删除事件映射回 CR）——真机日志见 `source="kind source: *v1.Secret"`；② pod template 新增 `RconSecretAnnotation` = 当前密码 SHA-256 指纹（64-bit）：secret 重建指纹变 → sts 自动 rollout 用上新密码，未重建则恒定不抖动；测试 2 例（跨 reconcile 稳定 / 重建必变）。提交 `56f3abd`。真机复测：删 secret 后**同秒**察觉+重建+换戳，31s 全自动恢复 Running |

| 27 | **陈旧启动锚点 → 已恢复的服务器被误判 StartupTimeout + Provisioned 永久 False**：`status.startRequestedAt` 只在 Stop 时清，成功（markRunningReady）不清——一旦服务器曾经历一次长 Starting，其 300s 预算就悬在健康运行中；此后任意一次 pod 波动（rollout/崩溃）都会立即套用旧戳判 `Failed(StartupTimeout)`。且 `markFailed` 写入的 `ConditionProvisioned=False` 无人复位，恢复后仍永久挂着失败标记 | 真机：20:19 已恢复 Running 的 test-one，20:21 因一次 stamp 注入引发的 pod rollout 被标记 `Failed StartupTimeout`（锚点残留自 20:16）；恢复后 status.conditions 里 `Provisioned=False … StartupTimeout` 持续存在 | `markRunningReady`：清 `StartRequestedAt`（每次启动/恢复尝试各有独立预算）+ 复位 `ConditionProvisioned=True`；测试 2 例（Ready 清锚点、Failed→Running 后 Provisioned 恢复）。提交 `82b5a60`。真机复测：清戳生效（`startRequestedAt: None`）、pod blip 删→33s 恢复全程无 Failed、锚点重新盖章后成功清除 |



## 待决策台账（未修）
@@ -97,6 +99,13 @@ IPv6-only 接入（`ssh -6 -i ~/.ssh/id_ed25519 root@fdb2:2c26:f4e4:0:21c:42ff:f 
- **翻转混沌**：3 秒内 Running→Stopped→Running，最终收敛 Running ready（期间 409 竞争为控制器正常噪音，controller-runtime 重试自愈）。

- **收尾**：`spec.idle` 删除后再无自停；test-one 回 Stopped、空 sts、无 EmptySince；VM 镜像 auditfix22 = `f650bf8`。



### 本轮新增真机证据（第八批：operator 自愈深挖，auditfix23/24）



- **RCON Secret 删除自愈（`56f3abd`）**：修复前——删 secret 静置 60s 零察觉、触发后 96s+ 永久 `RconNotReachable`、仅人工删 pod 可恢复；修复后——删 secret **同秒**（20:22:16）察觉（Secret watch 日志）→ 新密码 + stamp 换值（`3b24164f…`→`c465b627…`）→ rollout → **20:22:47 全自动恢复 Running**（31s）。

- **陈旧锚点（`82b5a60`）**：修复前——已恢复服务器因锚点残留被 `Failed(StartupTimeout)`、`Provisioned=False` 永挂；修复后——Ready 即清锚（`startRequestedAt: None`）、`Provisioned: True`；pod blip 演练：删除→20:24:48 重锚→20:25:19 恢复→锚清空，**全程无 Failed**。

- **StatefulSet 误删自愈**：删除 sts → **秒级**重建（PVC `world-test-one-0` 保持 Bound，Retain 策略）、29s 后 Running、stamp 保持 `c465b627…`（未触发多余 rollout）。

- **收尾**：期间 7 条 operator ERROR 全为 CR/sts 409 竞争噪音（自愈）；test-one 回 Stopped。



## 结论：离"生产可用"还差什么（按优先级）



1. ~~构建链路的上下文通道~~ ✅ **已修**（`f79e5eb`/`02fd2de`，真机全链路含拉回校验；Trivy DB 需按 §8e 镜像一次）。
@@ -117,6 +126,6 @@ IPv6-only 接入（`ssh -6 -i ~/.ssh/id_ed25519 root@fdb2:2c26:f4e4:0:21c:42ff:f 
- 面板会话 cookie：`/tmp/felis-cookies.json`；API 助手：`/tmp/fcurl.sh`

- 测试服：`test-one`（minecraft ns，stopped）；合法备份 `bk-47ee2e7e96e5a4ca9d0e51b805518bac`

- CDP 调试口：Mac `127.0.0.1:9333`（独立 Chrome，profile `/tmp/felis-chrome2`）；WebAuthn 虚拟认证器需在**同一 CDP 会话**内完成仪式，且先 `Page.bringToFront`（否则 NotAllowedError: page does not have focus）

- 已部署到 VM：`felis-api`/`felis-operator`/`felis-reaper`(CronJob) 镜像 = `felis:auditfix22`（含 #20–#25 全部修复；迁移 0020 已应用，`schema_migrations` max=20；CronJob 仍 `suspend=true`，SMTP 密码 env 待 `felis setup`「configure email」刷新时落地；operator Role 已手动补 `minecraftservers:patch`，`felis install/setup` 重渲染时收敛）

- 已部署到 VM：`felis-api`/`felis-operator`/`felis-reaper`(CronJob) 镜像 = `felis:auditfix24`（含 #20–#27 全部修复；迁移 0020 已应用，`schema_migrations` max=20；CronJob 仍 `suspend=true`，SMTP 密码 env 待 `felis setup`「configure email」刷新时落地；operator Role 已手动补 `minecraftservers:patch`，`felis install/setup` 重渲染时收敛）

- 构建链路 drill 现成条件：`felis-build` 里有 `felis-service-token`（Secret 复制）；`felis-config` 里 `kaniko_image/trivy_image` 指向 k3s containerd 已导入的 pin tag、`trivy_db_repository = registry.felis.svc:5000/mirror/trivy-db:2`（镜像配方 §8e；VM 上 docker daemon 的 `insecure-registries` 已含 registry ClusterIP）

- VM 内部面：`k3s kubectl -n felis port-forward svc/felis-api-internal 18081:8081`（Pod 重建后转发会悬死，需重启）；reaper CronJob（minecraft ns）已应用但 `suspend=true`