docs(audit): tenth-batch ledger — configure-email mirror fix (#29) and auditfix25 deployment

2026-09-23 04:44:12 +08:00
1 parent ed722d55f8
commit d4bb8d344b
@@ -30,6 +30,7 @@ IPv6-only 接入（`ssh -6 -i ~/.ssh/id_ed25519 root@fdb2:2c26:f4e4:0:21c:42ff:f
 | 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、锚点重新盖章后成功清除 |
 | 28 | **cfsetup 把 "policy already exists" 当成功吞掉 → fail-closed 保证可被旧策略顶替**：Cloudflare Access 的 `CreateAccessPolicy` 在收到 already-exists 时直接返回 nil；若该 app 上已有一条更宽松的旧策略（改 identity 后重跑、或此前手工配置），守卫 op.console 的仍是旧策略，而 Setup 报告成功——`validateFailClosed` 只校验过"我们构建的策略"，从未校验证留在线上的那条 | 代码审查（集成侧无真实 CF 账号，无法真机）：httptest 3 例复刻——已存在同名策略、缺席、POST 竞态。修复前第 1 例吞错返回 nil 且不发 PUT | 改为按名 upsert：lookup → PUT 覆盖守卫体 → 缺席才 POST（POST 撞 already-exists → 重查后 PUT，绝不吞）。`apiPost/apiPut` 共用一个 `apiWrite`。提交 `30857df` |
 | 29 | **"configure email" 的工作负载镜像复制从不生效**：`replicateSMTPToWorkloadNamespace` 把硬编码 `namespace: felis` 的 felis-smtp manifest 用 `-n minecraft apply` 发出——kubectl 拒绝 namespace 冲突（`the namespace from the provided object ... does not match`）→ 第一段直接 return err，**第二段 felis-config 的镜像复制根本不会执行**。于是任何"装好后再改 SMTP"的部署，reaper 的 pre-reap 警告永远拿不到新配置（这正是 8e7c7bb 添加该刷新要解决的事），且失败仅 warning 不中止 | 真机 kubectl 行为实验：`-n minecraft apply` 带 `namespace: felis` 的 manifest → `error: … does not match …`；修复后（manifest namespace=minecraft）→ `accepted-namespace=minecraft`（server dry-run）；felis-config 渲染+apply 序列同为 accepted | `smtpSecretManifest(password, namespace)` 显式参数（控制面调用传 "felis"，镜像传工作负载 ns）；回归测试 `TestSMTPSecretManifestCarriesTargetNamespace`。提交 `ed722d5` |
 ## 待决策台账（未修）
@@ -116,6 +117,13 @@ IPv6-only 接入（`ssh -6 -i ~/.ssh/id_ed25519 root@fdb2:2c26:f4e4:0:21c:42ff:f
 - **/fleet**：4 服全量（含运行中 lobby/login 的 endpoint 地址）一次读全。
 - **bootstrap-assets crd**：嵌入式资产含 `emptySince`（auditfix24 二进制核对）。
 ### 本轮新增真机证据（第十批：configure email 复制链修复，auditfix25）
 - **发现路径**：复核 `8e7c7bb` 新增的 replicate 逻辑时怀疑 manifest/-n namespace 冲突 → kubectl 真机实验裁决（hardcoded `namespace: felis` 版直接 `error: … does not match …`，证实第一段必错、第二段被跳过）。
 - **修复后行为验证**：两条命令序列（felis-smtp manifest 携带目标 ns + `felis-config` create--dry-run|apply）均被 server 接受且落点 `minecraft`。
 - **live 收敛项（随下次 `felis install/setup` 重跑）**：live CronJob 仍是旧模板（无 `FELIS_SMTP_PASSWORD` env）；`felis-smtp`/镜像两 ns 均未创建（SMTP 未配置，属正常）；与 operator Role 手动补 patch 同批处理。
 - **部署**：`felis:auditfix25` = `ed722d5`（api/operator/reaper 三处 set；api/operator rollout 完成，panel 200）。
 ## 结论：离"生产可用"还差什么（按优先级）
 1. ~~构建链路的上下文通道~~ ✅ **已修**（`f79e5eb`/`02fd2de`，真机全链路含拉回校验；Trivy DB 需按 §8e 镜像一次）。
@@ -136,6 +144,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:auditfix24`（含 #20–#27 全部修复；迁移 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:auditfix25`（含 #20–#29 全部修复；迁移 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`