n1/f1 Agent 密码对齐
SolarFlow 走 4 VPS 独立架构 → 此问题直接消失。 仅 n+f 合并架构需要手动对齐密码。
n1 和 f1 共享同一台 VPS，但 Ansible 为它们各自生成随机 agent_password。密码不一致导致 Press 推送 n1 Job 时认证失败（401）。
1. 归属
| 问题 | 答案 |
|---|---|
| 属于哪个仓库？ | 不是源码问题。Ansible playbook 的行为 + Press DB tabServer 和 tabProxy Server 的 agent_password 字段 |
| 在容器内路径？ | 无。Agent config.json（宿主机 /home/frappe/agent/config.json）+ Press DB |
| 在构建链的哪一步？ | Ansible playbook Setup Server 时自动生成密码 |
2. 功能解释
agent_password 怎么用的？
Press 给 Agent 发 Job 时，用这个密码做 HMAC 签名认证。Agent 收到请求后，用自己的 agent_password 验证签名。两边密码必须一致。
为什么 n+f 合并时会有两个密码？
n1 和 f1 在 Press DB 中是两条独立记录（一条 Proxy Server，一条 Server）。Ansible playbook 对每条记录各自生成随机密码 openssl rand -hex 16。它们碰巧是同一台机器，但 Ansible 不知道。
3. 为什么会出现这个问题
n+f 合并架构是我们的特例。Press 官方架构中 n 和 f 是两台独立物理机，各自有自己的 Agent 和密码。我们合并到一台机器后，机器上实际只有一个 Agent 进程、一份 config.json、一个 agent_password。但 Press 期望两个密码（一个给 n1 Job，一个给 f1 Job）。
设备器的 Agent 用的是 f1 的密码（Ansible 后生成的那个），n1 Job 签名用的是 n1 的密码 → 不匹配 → 401。
4. 补丁/修改做了什么
n1.agent_password = f1.agent_password # 手动对齐
从 f1 的 Server 记录读取 agent_password，直接覆盖到 n1 的 Proxy Server 记录。
5. 性质判断
workaround。n+f 合并架构的专属问题。不是改源码，是改 DB 配置值。但重建 f1 后会重现（Ansible 又生成新密码）。
6. 正确做法
SolarFlow 如果也走 n+f 合并：建记录时手动设同一个 agent_password。如果是独立 n-B 和 f-B（推荐），根本不存在这个问题——每台机器有自己独立的 Agent。
7. 影响范围
- n1 Job Add Site to Upstream 的认证
- 重建 f1 后重现，需固化到 playbook 或部署脚本