spacewalk通过软件通道、客户端订阅和yum自动化实现集中更新控制，不替代yum update但管控包可用性、目标系统和生效时间。

Spacewalk 本身不直接“推送”更新，而是通过软件通道（Software Channel）+ 客户端订阅 + yum 自动化机制实现集中更新控制。它不替代 yum update，但能决定「哪些包可用」「哪些系统能装」「何时生效」。

为什么不能直接用 yum update --assumeyes 在所有机器上跑

裸跑 yum update 缺乏策略控制：无法按环境（如 dev/staging/prod）分批更新，无法拦截高危包（比如内核升级需重启），也无法审计谁在什么时候更新了什么。Spacewalk 把更新变成可审批、可回溯、可关联 errata 的操作。

• 所有客户端必须安装并注册 spacewalk-client 包，否则无法接收通道元数据
• 客户端默认仍走本地 yum 命令，但源指向 Spacewalk 镜像的 repo（如 http://spacewalk.example.com/pub/centos6/），而非官方镜像
• Spacewalk 后台同步的是 RPM 包 + 元数据（包括 errata 记录），不是执行远程命令

创建 channel 和 repository 的关键顺序不能错

先有 repository（物理包位置），再建 channel（逻辑分组），最后把 repo 关联到 channel —— 反过来会导致同步失败或客户端找不到包。

CMIC Skill Scanner (Linux ARM64)

使用 auto、native 或 external 引擎审计待安装的 skill 包或归档，并可选启用 LLM 语义分析。

下载

• repository URL 必须可被 Spacewalk 服务端访问：本地路径用 file:///var/ftp/pub/centos7，HTTP 路径需确保 Web 服务已导出该目录
• 创建 channel 时 Architecture 必须与目标系统一致（如 x86_64），否则客户端订阅后 yum repolist 不显示该 channel
• 同步前确认 SELinux 或防火墙没拦住 spacewalk-sync 进程对 repo 目录的读取，常见报错：IOError: [Errno 13] Permission denied

让客户端真正应用更新的三种方式

Spacewalk 不自动执行 yum update，你得选一种触发方式：

• 手动触发：登录客户端，运行 yum update --disablerepo="*" --enablerepo="centos7_channel"（注意指定 channel 名对应的 repo ID）
• 定时任务：在客户端加 crontab，例如 0 2 * * 0 root yum -y update --enablerepo=centos7_channel
• 通过 Spacewalk Web UI 批量调度：Hosts → Select systems → Schedule Errata Installation → 选 errata → 设定时间。这会调用 taskomatic 在后台下发 yum update 命令，但依赖客户端 rhn-check 服务正常运行

errata 同步和过滤是安全更新的核心

单纯同步 RPM 包不够，errata（补丁公告）才是识别“这个更新是否修复 CVE-2025-1234”的依据。Spacewalk 从 ULN（Upstream Linux Network）或本地镜像拉取 errata 元数据，并绑定到对应 RPM。

• 同步 errata 前，先确认 channel 已启用 “Sync Errata” 选项（Web UI 中 Channels → Edit → Enable Errata Sync）
• 同步后，在 Errata → List All 中可筛选类型：Security Advisory、Bug Fix Advisory；点击某条 errata 可看到影响哪些 channel 和系统
• 误删 errata 元数据会导致 Web UI 显示“0 affected systems”，即使 RPM 已同步成功——此时需重新运行 spacewalk-repo-sync --channel centos7_channel --errata

最易被忽略的一点：Spacewalk 管理的是「软件源状态」，不是「运行时状态」。系统是否真正打上了补丁，仍要靠客户端执行 yum update 并重启相关服务。别只盯着 Web UI 上的 errata 列表就认为万事大吉。