Files
HomeAgent/internal/plugins/webui/kernel_update.go
JianFeeeee ba281a855a feat(update): 差分 OTA + 安装形态分派 + 事件总线统一受安全监控
三条主线,由 e2e 实测驱动。

## 一、差分 OTA(internal/update/delta.go)

实测:改一行逻辑,88MB 的二进制逐字节只差 80 字节,而 OTA 一直下整包。

用 rsync 族的滚动哈希块匹配(4KB 粒度),不是 bsdiff —— 后者需 17×N
峰值内存(88MB → 1.5GB),而升级恰可能发生在内存紧张时。

真实二进制实测:88,036,728 字节 → 补丁 77,316 字节(0.088%)。

三道闸:应用前验旧文件 sha256(错基线会静默产出垃圾)、应用后验结果
sha256、COPY/LITERAL 越界防护。任何失败**退回整包**,不向上抛 ——
差分是优化,不是可用性前提。

接入:Source.Resolve 优先试 delta;CheckRelease 按 -from-<commit8>.delta
匹配(不猜基线);CLI 新增 -make-delta;打包脚本 build_delta(需
PREVIOUS_HOMED),delta 进 SHA256SUMS。

## 二、安装形态分派(internal/update/install.go + channel.go)

内核对「能不能自己升级」此前只有一个答案:直接替换二进制。而 deb/rpm
形态下那样做会让 dpkg/rpm 数据库与实际内容不一致(下次 apt upgrade
覆盖回旧版,或 dpkg 拒绝后续升级)。

新增探测:deb/rpm/tar/container/source 五类形态 + 变体(full/server/
client/toolchain)+ 目录写权限。判据全部来自可观测系统事实(dpkg 的
info 目录、容器标记文件),不做路径推断。

三端统一走 PlanUpgrade 分派;形态闸门放在**下载 880MB 之前**。

## 三、事件总线统一受安全监控(internal/events + security)

用户指正:「eventbus 上所有事件都要接受安全模块的监控」。

此前 EventPolicy 只被 internal/sdk/events.go 调用,而那是四条路径中的
一条。s.Publish / s.Subscribe / s.EventBus() 拿的是裸 *events.Bus,
任何插件都能绕过策略发任意事件(含伪造内核事件)。

现在闸门在 Bus.Publish/Subscribe 本体上(Guard 接口注入,避免 events
↔ security 成环),四条路径全部覆盖。sdk.EventBus() 改返回带身份的
BusHandle。内核身份免授权,但载荷照样过凭据闸门。

白名单按主体收窄:agent_output/stage/terminal_output 只允许承载者
(webui/cli/agentcli)发布 —— 它们是内核向外的输出面,谁都能发就等于
能伪造 agent 说的话。

## e2e 暴露并修掉的三个真实回归

	[bus] subscribe denied: pluginmgr type=update_request
	[bus] subscribe denied: skillmgr type=skill_detected

前两个让升级请求静默丢失、职责链交接断掉。内部协作事件必须可订阅
(安全边界在发布侧,订阅只是「听得到」)。

## 顺带的止血修复

- 回滚判据从 `--version` 改为 digest:旧内核(1.3.x 及以前)没有该
  flag,而它恰是最常见的回滚目标 —— 原逻辑让「从旧版升级失败」永久
  无法回滚。
- CopyFile 补 fsync(替换 homed 本体时掉电会留半截文件)。
- restore 完整还原才清 marker(原先先清再还原,还原失败就失去第二次
  自愈机会)。
- 回滚时移除升级中新增的 depgraph(否则「旧 homed + 新 depgraph」
  会因 digest 不匹配崩溃循环)。
- homed-upgrade 不再硬编码 systemctl restart(丢 guard 状态、unit 名
  漂移);改用内核已有的 restartCh → exit 42 语义。
- homed-upgrade 不再用 CGO_ENABLED=0 编却依赖 go-sqlite3(stub 下
  静默失效,该路径从未工作过);改用 internal/config。
- 服务单元补 User=hologramagent + 三条安装路径补建用户(此前发行物里
  完全没有落实降权)。
- rpm 的 fpm 调用补 --after-install(此前 rpm 装完根本不建用户)。

## 判据

新增 30 条:差分 8(往返/压缩比/错基线/截断/篡改/边界)、通道 8、
执行器 6、事件闸门 8、按主体授权 8。全仓 go test ./... 0 失败。
2026-10-29 09:54:55 +08:00

179 lines
6.7 KiB
Go
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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),不做任何推导:pending 标记落在哪,
// 第 0 层 update 模块就从哪读;两边一漂移,升级失败时就**静默不回滚**。
// 而“猜一个看起来合理的路径”会让 Apply 的空值守卫变成死代码。
//
// 拿不到就返回空串,由 Apply 拒绝升级并报错。
//
// ⚠️ 不要再加 HOMEAGENT_DATA_DIR 回退:部署方可能不设,而设了也未必
// 与内核实际的 -data 一致 —— 那正是“看起来在工作”的一类错误。
func dataDirOf(binPath string) string {
return update.KernelDataDir()
}