mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-01 14:57:38 +00:00
pr31 与 main 是**双向分叉**,不是单向落后。`ba281a8` 已把它的多数工作
在 main 上重新实现(dataDir 守卫、gc.go、dataDir 解析),但两边各自又
往前走了,所以 6 个文件 19 处冲突要逐条判。
## 合进来的(main 缺)
- **标记原子写**:main 是 `os.WriteFile` 直接覆写,掉电留半截标记;
改为 `写 .tmp → fsync → close → rename → fsync 目录`
- **H4**:`publishResult` 里 `if errMsg != "" { _ = errMsg }` 把失败原因
丢了,订阅方只看到 ok=false。现在 error 字段恒定存在
- **回读校验补最低可用性**:main 对无 digest 的旧 marker 只比"内容与备份
一致",而**零字节备份内容也一致** ⇒ 判成回滚成功、不清 marker 的时机
也错过了。补"非空 + 带可执行位",刻意**不**要求 `--version`
(老内核没这个 flag,那正是 PR #31 的回归)
- `kernel_apply_test.go`(836 行,含 B2c `TestMarkPendingUpgrade_PreservesOldMarkerOnFailure`)
## 保留 main 的(pr31 在这几处是旧版或更差)
- **回滚校验用 digest**(`verifyRestored`)而不是 `--version`:
pr31 要求回滚后能读版本,而 1.3.x 及以前没有 `--version`,
而它们恰恰是最常见的回滚目标 ⇒ 从旧版升级失败后永久回滚不了
- **`restoreDepGraph` 三态**:原来有+备份有→还原、原来有+备份无→不算成功、
原来无→删掉新装的。pr31 只处理第一种,会导致「旧 homed + 新 depgraph」
的崩溃循环
- **marker 在还原完整后才清**:pr31 在还原前就清,还原失败即失去第二次自愈
- **CLI 不重启服务**:pr31 仍带 `restartUnit`,会杀掉整个 cgroup 连带 guard
- **`resolveDataDir`**:pr31 的 `upgradeDataDir` 是它的子集,多扫几个候选前缀
## 冲突处理中的三处重复声明
两边各加了同名函数,自动合并把它们都留下了:
- `readBinVersionStrict` —— 删 pr31 的(main 在 77 行有)
- `kernelDataDirMu/kernelDataDir/SetKernelDataDir/KernelDataDir` —— 删 kernel.go
里那份(main 在 install.go)
- `newPkgRoot` —— pr31 的重命名 `newPkgRootFromBin`,两套测试各自可用
- rollback.go 里 `verifyRestored` 与 `readBinVersionStrict` 两段校验并存 —— 删后者
顺带修掉删除时误伤的 `ShortSum` 注释,并删掉 pr31 引入但无人调用的
`DataDirEnv`(main 明确不再拿 env 当 dataDir 来源)。
## 验证
go build ./... ✓
go vet ./... ✓
go test ./... -count=1 62 ok / 0 fail
go test -race ./internal/update/ ... ✓
gofmt -l 干净
178 lines
6.7 KiB
Go
178 lines
6.7 KiB
Go
package webui
|
||
|
||
// 内核更新的 HTTP 端点(GET 检查 / POST 升级)。
|
||
//
|
||
// ## 三端共享同一底层(架构约束)
|
||
//
|
||
// agent 的 kernel_update 工具、本端点、CLI(homed-upgrade)三者共享
|
||
// internal/update 的 CheckRelease / Apply —— 三份实现必然漂移,会出现
|
||
// "WebUI 说有新版、agent 说没有"的分裂状态。
|
||
// 本文件只做 HTTP 形状转换,不含业务逻辑。
|
||
//
|
||
// ## 包来源二选一
|
||
//
|
||
// {"release": true} → 从仓库最新 GitHub Release 自动下载
|
||
// {"pkg": "/path/to/pkg.tar.gz"} → 用本机已有的安装包(优先)
|
||
//
|
||
// ## 升级 = 换产物 + 重启,两件事**分开做**
|
||
//
|
||
// Apply(本进程内,同步) :校验 → 备份 → pending → 原子替换
|
||
// 重启(交给内核控制通道) :kernelCtl.RequestKernelRestart → exit 42
|
||
// → guard 用新二进制重拉(不计失败轮次)
|
||
//
|
||
// ★ 为什么 Apply 必须同步返回:替换是**可失败**的动作(空间不足、权限、
|
||
// 包损坏)。异步的话这些错误全被吞掉,用户只看到"已受理"然后毫无变化。
|
||
// 而重启可以异步 —— 它让本进程消失,本来就没法回给它结果。
|
||
//
|
||
// ★ 为什么不用 systemctl restart:见 cmd/homed/kernel_control.go ——
|
||
// worker 是被守护方,只有 guard 知道这次退出该不该重拉。
|
||
|
||
import (
|
||
"encoding/json"
|
||
"log"
|
||
"net/http"
|
||
"os"
|
||
|
||
"github.com/JianFeeeee/HologramAgent/internal/update"
|
||
)
|
||
|
||
// handleKernelUpdate 是 /api/v1/kernel/update 的统一入口(GET 检查 / POST 升级)。
|
||
func (h *Handler) handleKernelUpdate(w http.ResponseWriter, r *http.Request) {
|
||
switch r.Method {
|
||
case http.MethodGet:
|
||
h.handleKernelUpdateCheck(w, r)
|
||
case http.MethodPost:
|
||
h.handleKernelUpdateApply(w, r)
|
||
default:
|
||
writeJSONError(w, http.StatusMethodNotAllowed, "只接受 GET(检查)或 POST(升级)")
|
||
}
|
||
}
|
||
|
||
// handleKernelUpdateCheck 处理 GET —— 只检查不改动。
|
||
func (h *Handler) handleKernelUpdateCheck(w http.ResponseWriter, r *http.Request) {
|
||
writeJSON(w, http.StatusOK, update.CheckRelease(currentKernelVersion()))
|
||
}
|
||
|
||
// handleKernelUpdateApply 处理 POST /api/v1/kernel/update —— 执行升级。
|
||
func (h *Handler) handleKernelUpdateApply(w http.ResponseWriter, r *http.Request) {
|
||
var body struct {
|
||
Pkg string `json:"pkg"`
|
||
Release bool `json:"release"`
|
||
}
|
||
// body 可为空(不合法就在下面报"必须指定来源"),所以解码失败不单独报错。
|
||
_ = json.NewDecoder(r.Body).Decode(&body)
|
||
|
||
src, err := update.ParseSource(body.Pkg, body.Release)
|
||
if err != nil {
|
||
writeJSONError(w, http.StatusBadRequest, err.Error())
|
||
return
|
||
}
|
||
|
||
binPath := update.KernelBinaryPath()
|
||
dataDir := dataDirOf(binPath)
|
||
|
||
// ★ 安装形态闸门:先判断“本机能不能自己升”,再决定要不要下载 880MB。
|
||
//
|
||
// deb/rpm 形态下文件归包管理器所有,直接替换会让 dpkg/rpm 数据库与
|
||
// 实际内容不一致(下次 apt upgrade 覆盖回旧版,或 dpkg 拒绝后续升级)。
|
||
// 此时必须明确告知走包管理器,**而不是**先下载再在 Apply 里失败。
|
||
//
|
||
// 容器同理:文件系统随销毁还原,自替换毫无意义。
|
||
capab := update.Detect(binPath, dataDir)
|
||
plan := update.PlanUpgrade(capab, body.Pkg)
|
||
if !plan.Executable {
|
||
// ★ 用 409(Conflict)而不是 500:这不是“服务器坏了”,
|
||
// 而是“这个请求在本机形态下不适用”,并且带着可执行指引。
|
||
writeJSON(w, http.StatusConflict, map[string]interface{}{
|
||
"applied": false,
|
||
"channel": string(plan.Channel),
|
||
"install_kind": string(capab.Kind),
|
||
"variant": string(capab.Variant),
|
||
"error": plan.Reason,
|
||
"commands": plan.Commands,
|
||
})
|
||
return
|
||
}
|
||
|
||
tmp, err := os.MkdirTemp("", "kernel-upgrade-*")
|
||
if err != nil {
|
||
writeJSONError(w, http.StatusInternalServerError, "建临时目录失败: "+err.Error())
|
||
return
|
||
}
|
||
defer os.RemoveAll(tmp)
|
||
|
||
root, rel, err := src.Resolve(tmp)
|
||
if err != nil {
|
||
writeJSONError(w, http.StatusBadGateway, "取包失败: "+err.Error())
|
||
return
|
||
}
|
||
newDG := update.FindFile(root, "depgraph.bin")
|
||
|
||
// ★ 不再自己取总线:进度事件由 internal/update 以**内核身份**发出
|
||
// (内核在启动时 SetEventBus 注入了总线)。
|
||
//
|
||
// 之前这里从 sdk 拿 *events.Bus 再传给 Apply —— 那既是"安全监控可被
|
||
// 绕过"的根源(插件持有裸总线就能伪造任意事件),也让插件依赖了
|
||
// 一个它本不该有的能力。
|
||
out, err := update.Apply(root, binPath, newDG, dataDir, nil)
|
||
if err != nil {
|
||
writeJSONError(w, http.StatusInternalServerError, err.Error())
|
||
return
|
||
}
|
||
|
||
res := map[string]interface{}{
|
||
"applied": true,
|
||
"from": out.From.Version,
|
||
"to": out.To.Version,
|
||
"backup": out.BackupDir,
|
||
"message": "新内核已就位,正在重启。新版本启动后由第 0 层 update 模块确认;无法启动会自动回滚。",
|
||
}
|
||
if rel != nil {
|
||
res["release"] = rel.Latest
|
||
res["asset"] = rel.Asset
|
||
}
|
||
|
||
// 先把响应写回,再让内核消失(同 kernel/restart 的教训:不 Flush 会
|
||
// 变成 connection reset,用户以为出错了)。
|
||
writeJSON(w, http.StatusOK, res)
|
||
if f, ok := w.(http.Flusher); ok {
|
||
f.Flush()
|
||
}
|
||
|
||
// 重启走**既有**内核控制通道(restartCh → exit 42 → guard 用新二进制重拉)。
|
||
// 不自己 systemctl,也不另开通道。
|
||
if h.kernelCtl == nil {
|
||
log.Printf("[webui] 新内核已就位,但内核控制通道不可用(kernelControlAllowed 未授予 webui),无法请求重启")
|
||
return
|
||
}
|
||
if err := h.kernelCtl.RequestKernelRestart("kernel_update apply"); err != nil {
|
||
log.Printf("[webui] kernel restart request failed (新内核已就位,需手动重启): %v", err)
|
||
}
|
||
}
|
||
|
||
// currentKernelVersion 读本机 homed 的版本(尽力而为)。
|
||
func currentKernelVersion() *update.BinVersion {
|
||
bin := update.KernelBinaryPath()
|
||
if _, err := os.Stat(bin); err != nil {
|
||
return nil
|
||
}
|
||
v, err := update.ReadBinVersion(bin)
|
||
if err != nil {
|
||
return nil
|
||
}
|
||
return v
|
||
}
|
||
|
||
// dataDirOf 返回内核**真实**的数据目录(ks.DataDir,来自 `-data`)。
|
||
//
|
||
// ★ 取注入值,不做任何推导:pending 标记落在哪,第 0 层 update 模块就从
|
||
// 哪读;两边一漂移,升级失败时就**静默不回滚**。而“猜一个看起来合理的
|
||
// 路径”(曾用过 env → exe 同级 data)会让 Apply 的空值守卫变成死代码——
|
||
// 实测生产是 `--data /var/lib/hologram`,而 exe 推导得 /usr/bin/data
|
||
// (只读目录,建备份必 EROFS)。
|
||
//
|
||
// 拿不到就返回空串,由 Apply 拒绝升级并报错。
|
||
func dataDirOf(binPath string) string {
|
||
return update.KernelDataDir()
|
||
}
|