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 —— 反过来会导致同步失败或客户端找不到包。
-
repositoryURL 必须可被 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 列表就认为万事大吉。
