openEuler离线升级包：构建内网等保环境专属软件源与事务回滚实践

简介openEuler-22.03-LTS-SP3离线升级包是一套专为openEuler 22.03 SP1升级至SP3场景准备的完整软件包集合主要面向中高级系统运维人员、实施工程师以及内网隔离环境中的服务器升级需求。资源共包含508个文件其中501个RPM格式的软件包覆盖内核、硬件固件、基础库与系统组件等关键升级内容另有少量XML和SQLite压缩包格式的仓库元数据文件可作为离线yum仓库的元数据来源。所有软件包的依赖关系已经预先处理完成并在全新安装的SP1系统上实际验证通过升级时无需再逐一下载和反复排查依赖缺失。整个zip压缩包体积约389.15MB目前已有915人学习下载适合提前下载后分发至其他内网机器。对于需要快速完成SP1到SP3离线升级的用户这套资源提供了经过验证的软件包集合和清晰的目录结构显著简化升级准备过程降低内网运维的操作门槛。1. 离线升级包当内网等保环境遇到 openEuler-22.03-LTS-SP3先准备好这张“后悔药”我拿到的这个标题是“openEuler-22.03-LTS-SP3离线升级包”不少同行第一反应是“这不就是把 rpm 拷进去吗”结果依赖关系理不清、repo 源配错、升级中途被打断系统直接处于半升级状态。这活儿看着简单真正稳的落地方式是把“离线升级包”当成一整套仓库工程来管理而不是一份文件拷贝清单。本文面向机房没有外网、有等保合规要求的场景给的是从零构建离线源、配置本地 repo、执行事务升级、以及事后回滚的完整路径。新手能照着操作熟手重点看避坑部分。2. 为什么离线升级包是刚需先理解远程源在隔离网络里为什么必然翻车2.1 在线升级在受限网络里的五个不可控点一说升级很多人的第一反应是“配个公网源dnf updata 不就完事了吗”。这个做法在生产环境尤其是机房做分区隔离、只有少量业务节点能出外网的网络里基本走不通。问题出在几个点上策略层面节点不出外网是安全基线的硬性要求开墙要过审批周期以周计而漏洞修复的窗口往往以天计连接层面即使有跳板机dnf 在传输大元数据的时候容易断流SP3 的 repo 元数据反复拉不全最后就是依赖解析失败升级中断在“正在下载”这一阶段。一致性层面在线源的 updateinfo 文件是滚动更新的内网节点和公网源看到的包版本集合天然不同时间一长环境之间就产生了版本漂移基线无法对齐。审计层面等保和行业合规普遍要求“软件来源可审计”公网源下载的包没有内部准入记录攻防演练复盘时根本说不清楚哪个包是谁、何时、从哪里进来的。窗口层面几百个节点的批量升级在线方式等于把每个节点都暴露在同一批外网连接上占了带宽也给外部监控留下了模糊的攻击面。离线升级包对这类环境的第一个价值是把“出网拉包”这件事从业务节点身上挪走。由一台允许出网的管理机把全部依赖包拉下来形成离线升级包再通过内网分发节点本身全程不接触公网。第二个价值是可复现性同一份离线包今天升级和三个月后升级看到的 repo 元数据、rpm 版本、依赖关系完全一致这对做变更审批和环境基线对齐特别重要。第三个价值是可控性升级哪一批、先升哪个依赖组后升哪个应用完全由 repo 配置里的 exclude 和 installonly 策略决定而不是被公网源牵着走。2.2 离线升级包的正确认知它不是文件拷贝而是一个自洽的软件仓库很多第一次接触的朋友会把离线包当成一个装满了 rpm 的目录拷过去以后 dnf install 某个包时说“没有可用软件包”或者“依赖缺失”就开始怀疑是不是包没拷全。真相是dnf 的仓库识别靠的是 repodata 目录里的元数据primary.xml.gz、filelists.xml.gz、other.xml.gz、repomd.xml而不是单纯扫描目录里的 rpm 文件。没有元数据哪怕 rpm 文件排满一排dnf 也认为这个仓库是空的。所以要构建一个合格的 openEuler-22.03-LTS-SP3 离线升级包至少需要三个部分RPM 软件包集负责提供升级实际要用到的二进制包repodata 元数据负责让 dnf 能索引并解析依赖签名与校验信息负责让 gpgcheck 和 checksum 校验通过。三者缺一升级动作就会在某个环节被卡死。组成部分作用缺失时的表现RPM 软件包集升级实际要用到的二进制包dnf 提示 missing dependencyrepodata 元数据让 dnf 能索引、解析依赖dnf 提示仓库是空仓库签名与校验信息让 gpgcheck 和 checksum 校验通过安装被 gpg 检查拦下这里有一个容易忽略的细节元数据和 rpm 集合必须来自同一次同步否则就会出现“元数据里声明了 libfoo.so.1但包目录里没有这个文件或者文件已更新”的错位。官方做法是把同步和生成元数据做成一条流水线任何一步失败都不生成新的 repodata宁可让旧版本继续服务也不要把截断的数据推上线。我一般会在内网准备两台机器一台“同步机”负责拉取、校验、裁剪、生成元数据一台“分发机”或者直接用主节点承载 repo 服务。同步机可以出网也可以不出网——不出网时用移动介质导入包出网时直接用工具同步这两种方式后面都会给到命令。搞清这一点后面的实操才不会反复翻车。2.3 选型理由为什么用 createrepo_c 而不是手工维护依赖有人会问能不能直接拷贝镜像站上的 repodata 来用理论上可以但实际不可行。镜像站的 repodata 是基于完整仓库生成的包含的模块列表、源码包索引、以及大量你根本用不到的架构包元数据体积大且解析慢。更重要的是repodata 里的文件清单与镜像站文件时刻保持关联一旦你裁剪掉部分 rpm原版 repodata 就成了“过期索引”dnf 会拿它去找不存在的文件。createrepo_c 的作用就是让元数据与本地文件集合重新对齐生成一个自洽的、可独立分发的仓库。createrepo_c 比老旧的 createrepo 快很多对 zstd 压缩的支持也更好适合几千个包的仓库索引重建。另一个常见工具是 dnf reposync它负责同步 rpm 文件本身两者配合就构成了离线升级包构建的完整工具链。接下来的章节就是从同步到生成、再到节点使用的完整落地路径。3. 构建离线升级包三步完成仓库初始化把散落 rpm 变成可用离线源3.1 第一步用 reposync 从镜像站同步 SP3 仓库构建离线升级包最常见的做法是找一台能连接官方镜像站的同步机直接用 dnf reposync 把仓库整体拉下来。命令如下# 安装必需工具链注意 createrepo_c 是生成元数据的关键 dnf install -y dnf-plugins-core createrepo_c # 创建离线包目录按 releasever 归档避免以后多版本混在一起 mkdir -p /data/offline-repo/openEuler-22.03-LTS-SP3 cd /data/offline-repo/openEuler-22.03-LTS-SP3 # 同步 baseos 仓库只拉 x86_64 架构同时下载元数据 dnf reposync \ --repoidbaseos \ --archx86_64 \ --download-metadata \ --downloaddirbaseos \ --destdir. \ --newest-only这里的关键参数说明--repoid指定要同步的仓库 IDbaseos 对应 openEuler 22.03 LTS SP3 的基础仓库--archx86_64只拉当前架构省掉不需要的源码包和其他架构包--download-metadata会把官方仓库的 repomd.xml 一并下载后续可以用它做校验基准--newest-only只保留每个软件包的最新版本避免仓库里堆积历史版本导致依赖解析变慢。注意--destdir是目标根目录配合--downloaddir使用时目录层级要提前规划否则很可能把包拉到一个奇怪的嵌套路径。逻辑说明reposync 本质上是逐包调用下载逻辑它会把 rpm 文件放入指定目录但不会帮你生成新的元数据——生成元数据是下一步 createrepo_c 的工作。补充一点如果同步机也不允许出网可行的替代方案是在能出网的临时环境同步成目录再把整个目录用移动介质转入内网。rpm 文件本身是二进制格式同一架构下直接拷贝可用的概率很高但强烈建议拷贝完成后重新执行一次 createrepo_c 并核对签名不要信任“拷过来的 repodata 一定能用”这种直觉这一步就是另一处血泪经验的来源。3.2 第二步用 createrepo_c 生成干净的 repodata同步完成后要重新生成元数据。这一步不能省原因是官方镜像站的 repodata 是基于完整仓库生成的里面包含了大量你用不到的模块和源包索引内网源只应该包含你已经同步回来的这批文件元数据必须与本地文件一一对应。# 对 baseos 目录重新生成元数据zstd 压缩减小占用 createrepo_c \ --compress-typezstd \ --revision2025-01-15-sp3-baseos \ --workers4 \ --outputdir/data/offline-repo/openEuler-22.03-LTS-SP3/baseos/repodata \ /data/offline-repo/openEuler-22.03-LTS-SP3/baseos参数说明--compress-typezstd指定元数据压缩格式openEuler 22.03 系列的 dnf 版本都支持 zstd比 gzip 压缩率更高、解压更快--revision会给 repomd.xml 写入一个自定义修订标识后续排查“这个源到底是什么时候生成的”时特别有用建议按日期加版本号命名--workers4控制并行压缩线程内网机器核数不多时改成 2 即可--outputdir显式指定 repodata 输出路径不指定时会在源码目录下自动生成指定后更可控。生成完成后马上做一次完整性校验# 进入目录确认元数据和文件数对得上 cd /data/offline-repo/openEuler-22.03-LTS-SP3 ls -lh baseos/repodata/ # 用 dnf 本地仓库验证能正确解析 dnf --repofrompathlocal,./baseos --repolocal list available | head -5逻辑说明--repofrompath可以临时把本地目录挂载为一个仓库来测试不修改任何配置文件是上线前最安全的预检手段。如果这里能列出软件包列表说明元数据生成是成功的如果报“Empty repo”或者“Cannot open repodata”优先检查目录路径是否有嵌套、repomd.xml 是否存在、createrepo_c 命令是否真的在当前目录生成了输出。3.3 第三步构建最小依赖集只带业务需要的包全量仓库往往有几千个包如果只是给几台业务服务器升级没必要全量搬运。更精细的做法有一个常见实践先在临时环境里模拟“安装目标软件包”的依赖解析把解析结果导出来再用 dnf download 只下载依赖列表里的 rpm。核心命令# 在临时环境里执行事务解析把需要的包名列表导出 dnf install --assumeno --downloadonly openssl python3 openssh-server 21 \ | tee /tmp/dep-resolve.log # 用 dnf download 批量拉取--resolve 会自动带上依赖 dnf download \ --resolve \ --archx86_64 \ --alldeps \ --destdir/data/offline-repo/openEuler-22.03-LTS-SP3/min-set \ openssl python3 openssh-server参数说明--resolve是核心它会自动把依赖链条上的所有包拉下来--alldeps连弱依赖一起拉离线环境里宁可多一点也不要少一个--destdir指定输出目录。逻辑说明这个方式生成的目录结构和全量方式不同使用前同样需要 createrepo_c 生成元数据步骤与上一节完全一致。什么场景选什么方式可以参考下面这张表构建方式适用场景体积依赖风险全量 repo 同步大规模集群统一基线大低最小依赖集少量应用服务器小中需要验证依赖闭环全量裁剪有存储但想控制分发量中低需维护裁剪清单4. 把离线包部署成可用源repo 配置、事务管理与三条升级路径4.1 配置本地 repo 文件一个参数错误会让整批节点全部掉源离线源放到内网分发机后下一步是让业务节点认识它。这里最常见的翻车是配置文件里的 baseurl 写成了镜像站路径或者 gpgcheck1 但本地没有导入对应的公钥。先看一份可用的 repo 配置# /etc/yum.repos.d/openEuler-SP3-offline.repo [openEuler-SP3-baseos] nameopenEuler 22.03 LTS SP3 BaseOS (offline) baseurlhttp://repo.internal.example.org/offline/openEuler-22.03-LTS-SP3/baseos enabled1 gpgcheck1 repo_gpgcheck0逻辑说明baseurl指向内网分发机的 HTTP 服务路径需要保证该路径下有 repodata 目录gpgcheck1要求校验 rpm 签名因此必须在节点上导入构建离线包时所用的 GPG 公钥repo_gpgcheck0表示不对 repo 元数据本身做 GPG 签名校验——如果离线包是从官方源同步的元数据没有额外签名这里设 1 会直接导致仓库不可用。常见做法是公钥放在离线包目录里一起分发节点上执行# 导入公钥key 文件名以实际包内文件为准 rpm --import /etc/pki/rpm-gpg/openEuler-SP3.asc注意临时测试环境想快速验证可以把 gpgcheck 临时改成 0但生产环境千万不要省掉公钥导入这一步。gpgcheck1 在离线场景下的意义是防止内网分发过程中包被替换属于内部供应链安全的底线。配置完成后先做一次仓库刷新不要让旧缓存干扰判断dnf clean all dnf makecache dnf repolist4.2 升级前的事务保护history 与 rollback 是你唯一的后悔药离线升级和在线升级最大的不同是一旦升级过半断电或者被其他操作打断你不能再指望“重新拉一次包”来修复因为节点根本出不了网。所以事务保护要从三个层面做升级前的系统快照、rpm 数据库备份、以及依赖 dnf history 做事务级回滚。下面是一组推荐做法# 备份 rpm 数据库和关键配置目录出问题可以直接还原元数据 mkdir -p /var/backup/pre-upgrade-sp3 cp -a /var/lib/rpm /var/backup/pre-upgrade-sp3/ cp -a /etc /var/backup/pre-upgrade-sp3/ # 升级前先记录当前的事务历史确认干净 dnf history list --reverse | head -10 # 执行真正的事务升级前先做假设事务检查依赖冲突 dnf upgrade --assumeno baseos 21 | tee /tmp/sp3-dryrun.log--assumeno会执行完整的依赖解析但回答“否”因此不会真正安装任何包它带来的价值是如果这条命令报出依赖错误、包冲突、或者需要额外安装某个模块早于真实升级被看到。我在生产环境里反复强调这个步骤因为它能拦截掉 90% 的依赖类翻车而成本几乎为零。真正的升级命令分为三种路径按场景选择# 路径一最小化升级只把同仓库内现有已安装包升级到 SP3 版本 dnf upgrade openEuler-SP3-baseos # 路径二过滤内核和关键包业务先上内核后升 dnf upgrade --excludekernel* --excludekmod* openEuler-SP3-baseos # 路径三全库升级包括内核和所有依赖适合维护窗口充足的批次 dnf upgrade --refresh openEuler-SP3-baseos逻辑说明路径一适合应用层升级改动面小路径二是把内核单独挪到下一个窗口再升规避内核与老模块的兼容风险路径三是整批基线对齐最适合用来把 SP2 环境一次性拉到 SP3。内核升级后需要重启才会生效这一条要写进变更单。4.3 升级后的验证集不再依赖“看着没报错”这种主观判断升级完成不等于现场验收完成。我习惯用一个固定命令组做后置验证覆盖包版本、仓库数、事务状态、内核版本四个面# 检查关键包是否已到 SP3 基线版本 rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n | grep -E ^(openssl|python3|systemd|kernel) | sort # 确认当前事务历史最后一条是 Success dnf history info | head -12 # 确认仓库里没有残留的 SP2 源或重复配置 dnf repolist --all | grep -v disabled # 确认内核版本重启后应看到新内核 uname -r升级中最容易被忽略的坑是“两个仓库同时供应同一个包”。假设节点上还保留着老版本的内网源新配置的 SP3 源也包含同名 rpmdnf 的版本比较会选中较高的那个。如果老源的版本号反而更高例如打了私有补丁就会出现升级后“版本没变”的假象。因此升级前务必将旧 repo 文件移出目录或者设置 enabled0保证只有 SP3 源在服务这也是后文避坑章节会再次强调的点。节点多了以后建议写成循环脚本统一执行验收# 批量节点验证脚本将结果汇总到 master 端 for host in node01 node02 node03; do ssh root$host rpm -q openssl systemd | paste -d - -; dnf history list --reverse | head -1; uname -r; /tmp/sp3-verify-$(date %F).log done说明这个循环适合几十台以内的批量验证几百台的规模建议用资产管理平台下发命令并回传结果脚本思路可以复用但不建议在多线程调度上重复造轮子。5. 离线升级避坑指南依赖、元数据、缓存与回滚的五个真实案例5.1 仓库能列出来但一安装就报“No available packages”现象dnf repolist能看到 offline 仓库软件包数量也正常但执行dnf install xxx时提示没有可用软件包。原因元数据和 rpm 集不是同一批产物。常见于把别人拷贝来的 rpm 目录直接拷入内网却没重新生成元数据。更隐蔽的一种是 reposync 时从官网同步了元数据但同步中断repodata 里记录了后续的文件列表而目录里根本没有对应文件。解决强制重新生成元数据。把 createrepo_c 的输出目录清掉重新执行然后在节点上dnf clean all dnf makecache。不要用“源里的文件看起来挺全”这种直觉一切以 repodata 解析结果为准。5.2 gpgcheck1 时升级中断报 GPG key retrieval failed现象升级执行到一半事务被 GPG 检查卡住日志反复出现 Failed to import GPG key。原因节点上没有导入离线包对应的公钥或者 repo 文件里的 keyurl 指向了公网地址节点出不了网导致拉取 key 失败。离线包从官方源同步时rpm 文件带的是官方签名公钥本身不会随仓库自动下发。解决把公钥文件放到离线包根目录随包分发。节点第一次使用前执行rpm --import /path/to/公钥然后dnf clean all dnf makecache再重试。最好的做法是把导入公钥的动作写进自动化初始化脚本而不是每次都手工补。5.3 SP2 和 SP3 的包混装升级完出现版本倒退现象某个包显示版本还是老版本甚至比升级前还低应用依赖的动态库版本不匹配服务起不来。原因节点上残留了老 SP2 的内网源且 SP2 源里有打了私有补丁的高版本 rpm。dnf 默认比较版本号和 release私有补丁通常把 release 改得很高导致新源提供的 SP3 官方版本在比较中落败选了 SP2 包。解决升级前把旧 repo 文件全部移出/etc/yum.repos.d/或改为 enabled0只保留 SP3 源。升级完成后用dnf repoquery --installed --qf核对关键包版本并在资产管理平台登记机器最后的版本基线。这个坑在所有离线升级里都值得排第一。5.4 升级过程中断电rpm 数据库前后不一致现象重启后 dnf 命令报错需要重建 rpm 数据库部分包出现“installed but not installed”状态。原因dnf 升级是在 rpm 事务内完成的事务被硬打断后可能出现 rpmdb 损坏或处于半提交状态。解决立刻用升级前备份出来的/var/lib/rpm做恢复再执行dnf history undo last回滚事务。用备份恢复 rpmdb 后要重新执行dnf clean all。这个场景的核心教训是升级前的那两行备份命令是不能省的。断电在机房并不罕见UPS 掉电、存储切换、运维误操作都可能打断升级。5.5 元数据更新后节点上永远拿的是旧缓存现象内网分发机已经更新了 repodata节点也执行了dnf makecache但解析出来的包列表还是老版本。原因节点本地的 dnf 缓存没有失效或者节点的/var/cache/dnf被只读挂载导致缓存刷新失败。另一种常见原因是节点上的时间与仓库元数据时间为准的时间差太大dnf 对缓存过期时间做了保守判断。解决先检查缓存目录挂载状态再执行dnf clean all并删除对应仓库的缓存子目录同步检查节点时间用时间同步命令校正。最后重新 makecache 验证。养成升级前先执行dnf clean all的习惯可以避开这个坑的一大半场景。6. 把离线源变成日常增量同步、版本基线与补丁管理离线升级包只有做成日常机制才真正值钱。我现在的习惯是做一台固定同步机每两周做一次增量同步用dnf reposync --download-metadata全量重扫仓库但只下载新增或变化的 rpm再用 createrepo_c 重生成元数据生成后将仓库目录打上带日期的标签保留最近三个版本作为回退选项。# 增量同步与元数据重生成的定时任务示例 dnf reposync --repoidbaseos --archx86_64 --download-metadata --newest-only -p /data/offline-repo/openEuler-22.03-LTS-SP3/baseos createrepo_c --update --compress-typezstd /data/offline-repo/openEuler-22.03-LTS-SP3/baseos--update是增量生成元数据的关键参数它只重新扫描有变化的文件速度比全量快得多。注意增量同步后务必对比分发机与节点上的 repodata 时间戳确认节点重新 makecache 完毕再释放维护窗口。另外两个我一直在用的习惯一是离线包目录里维护一个 VERSION 文件记录构建日期、同步范围、关键包版本二是把升级后的基线做台账哪台机器是 SP3 的哪一批、升级时间、操作人和回滚标记都留下来。这样审计时不需要翻聊天记录直接看台账就能说清楚。每次升级窗口结束后我都会把当次的 dnf history 导出一份存档跟离线包版本号放在一起。这个习惯救过我好几次——半年后某个节点出现诡异问题翻出当初的升级事务记录一眼就能定位是哪一批包引入的回归。离线升级包这种东西最怕的是“一次性思维”用完就扔下次重新拉包重新踩坑。把它变成一套带版本、带台账、带回退策略的仓库工程后内网的升级工作就从一个高危操作变成常规维护了。希望帮到你。本文还有配套的精品资源点击获取