msa-agent

3 Commits

Author SHA1 Message Date

Author	SHA1	Message	Date
chick	b31b7fe25a	fix(release): 发布前确认工作树干净且提交已推送，并显式指定 tag 指向的提交实测的缺陷：v1.0.2 的二进制是对的（校验和与 `b060f86` 干净树上的本地构建逐字节一致），但 tag 落在 1.0.1 那个提交上——因为脚本不自己建 tag，而是让 Gitea 建，而 Gitea 把 release 的 tag 建在"创建那一刻远端默认分支的 HEAD"上。当时 `b060f86` 还没 push，origin/main 还是 f499d02，于是 v1.0.1 和 v1.0.2 指向同一个树，去读该 release 源码的人拿到的是修复前的版本。两处修正： 1. 创建 release 时显式给 `target_commitish`，不再让服务器决定。 2. 发布前要求工作树干净、且 HEAD 已在某个远端分支上。前者不只是洁癖：Go 默认把 VCS 信息打进二进制，工作树脏时构建产物带 "modified" 标记——实测同一个提交，干净树是 9c9c09dd…，脏树是 1d9bf3a1…，所以"tag 必须指向二进制所来自的那个提交"这句话在有未提交改动时根本不成立。	2026-09-18 14:05:40 +08:00
chick	b060f8664c	chore: 1.0.2（enroll/install 的接缝修复）	2026-09-18 12:39:58 +08:00
chick	20070b90f7	fix: enroll 写出守护进程会拒绝的配置，install 写出与自身路径不符的单元四处"校验在错误的层"的缺陷，都属于同一类：每个组件单独看都对，接缝错了。 1. `msa-agent enroll --relay http://relay.example` / `relay.example` / `https://relay.example/v1` 都会写出配置文件，install 报成功，守护进程在下一次启动才拒绝，日志里只有一行 "msa-agent exiting"。规则原本散在三处（config 只查非空、transport 查真实规则、enroll 的注册客户端另有一份），现在收进 `internal/relayurl` 一份，三处都调它。 `config.File.Validate` 因此也补上了 https/host/无路径/无 query 的检查。 2. `enroll` 不再自己手写字段检查，改为构造真正的 `config.File` 并调用真正的 `Validate`—— 一份"什么是可用配置"的定义，结构上无法再漂移。`config.Marshal` 让 enroll 与 Save 用同一个编码器。 3. `install --config /srv/msa/config.json` 会给该文件改属主、交给服务用户，然后写一个 ExecStart 指向 `/etc/msa-agent/config.json` 的单元——服务起来找不到配置就退出，而它需要的文件就在别处、属主正确、从未被读。`enroll --audit /srv/audit/audit.log` 同理：单元的 `ReadWritePaths` 只覆盖 `/var/log/msa-agent`，在 `ProtectSystem=strict` 下 agent 的 `MkdirAll` 报 EROFS，进程启动即退出，报错既不提那个 flag 也不提那条指令。现在单元是模板， `RenderedUnit` 按实际布局渲染，`--print-unit` 打印的就是会被写入的那一份；默认布局渲染结果与仓库里被 review 过的文件逐字节相同，所以 vendored 副本的漂移检查仍然有意义。测试：新增 `internal/relayurl`，`config`/`enroll`/`install` 各补回归测试。每条都做了变异验证（把修复回退，对应测试必须失败）。	2026-09-18 12:38:56 +08:00

b31b7fe25a

fix(release): 发布前确认工作树干净且提交已推送，并显式指定 tag 指向的提交

实测的缺陷：v1.0.2 的二进制是对的（校验和与 b060f86 干净树上的本地构建逐字节一致），但
**tag 落在 1.0.1 那个提交上**——因为脚本不自己建 tag，而是让 Gitea 建，而 Gitea 把 release 的
tag 建在"创建那一刻远端默认分支的 HEAD"上。当时 b060f86 还没 push，origin/main 还是 f499d02，
于是 v1.0.1 和 v1.0.2 指向同一个树，去读该 release 源码的人拿到的是修复前的版本。

两处修正：

1. 创建 release 时显式给 `target_commitish`，不再让服务器决定。
2. 发布前要求工作树干净、且 HEAD 已在某个远端分支上。前者不只是洁癖：Go 默认把 VCS 信息打进
   二进制，工作树脏时构建产物带 "modified" 标记——实测同一个提交，干净树是 9c9c09dd…，脏树是
   1d9bf3a1…，所以"tag 必须指向二进制所来自的那个提交"这句话在有未提交改动时根本不成立。

2026-09-18 14:05:40 +08:00

chick b060f8664c chore: 1.0.2（enroll/install 的接缝修复） 2026-09-18 12:39:58 +08:00

chick

20070b90f7

fix: enroll 写出守护进程会拒绝的配置，install 写出与自身路径不符的单元

四处"校验在错误的层"的缺陷，都属于同一类：每个组件单独看都对，接缝错了。

1. `msa-agent enroll --relay http://relay.example` / `relay.example` /
   `https://relay.example/v1` 都会写出配置文件，install 报成功，守护进程在**下一次启动**才
   拒绝，日志里只有一行 "msa-agent exiting"。规则原本散在三处（config 只查非空、transport
   查真实规则、enroll 的注册客户端另有一份），现在收进 `internal/relayurl` 一份，三处都调它。
   `config.File.Validate` 因此也补上了 https/host/无路径/无 query 的检查。

2. `enroll` 不再自己手写字段检查，改为构造真正的 `config.File` 并调用真正的 `Validate`——
   一份"什么是可用配置"的定义，结构上无法再漂移。`config.Marshal` 让 enroll 与 Save 用同一个
   编码器。

3. `install --config /srv/msa/config.json` 会给该文件改属主、交给服务用户，然后写一个
   ExecStart 指向 `/etc/msa-agent/config.json` 的单元——服务起来找不到配置就退出，而它需要的
   文件就在别处、属主正确、从未被读。`enroll --audit /srv/audit/audit.log` 同理：单元的
   `ReadWritePaths` 只覆盖 `/var/log/msa-agent`，在 `ProtectSystem=strict` 下 agent 的
   `MkdirAll` 报 EROFS，进程启动即退出，报错既不提那个 flag 也不提那条指令。现在单元是模板，
   `RenderedUnit` 按实际布局渲染，`--print-unit` 打印的就是会被写入的那一份；默认布局渲染结果
   与仓库里被 review 过的文件逐字节相同，所以 vendored 副本的漂移检查仍然有意义。

测试：新增 `internal/relayurl`，`config`/`enroll`/`install` 各补回归测试。每条都做了变异验证
（把修复回退，对应测试必须失败）。

2026-09-18 12:38:56 +08:00