企业官网建设流程全解析

简介：openEuler 22.03 LTS SP1 用户在离线或内网环境下完成到 SP3 的升级，往往受制于依赖包缺失与联网限制。这套离线升级包正是为此封装，面向系统管理员和运维工程师，已由作者在新装 SP1 系统上验证通过，依赖关系提前处理完毕，可直接作为本地软件仓库使用，免去手动解析 rpm 依赖的环节。压缩包共 508 个文件，其中 501 个 rpm 覆盖内核、linux-firmware、libicu 等关键组件，另有 gz/bz2 格式的仓库元数据与 xml 文件，用于搭建 yum/dnf 本地源，整体大小 389.15MB，目录结构清晰，便于核对和批量部署。目前已有 906 人学习下载，常被内网运维和系统升级人群用作参考。拿到这份包后，可按提示在 SP1 环境中执行升级，完整替换内核与系统组件，并借助内置元数据核实包完整性，避免下载遗漏或依赖冲突。对需要离线批量升级 openEuler 的团队而言，是一份可直接落地的升级素材。 做离线升级包这件事，说到底就是给隔离网络里的 openEuler 系统准备一份“找齐了所有依赖的软件包集合”。之前我在一个不能连外网的生产环境里维护过一批 openEuler 22.03 LTS 的机器，系统版本停留在 SP1，安全漏洞公告发了一堆却装不上补丁，那叫一个难受。后来专门搭了一套离线升级方案，把 SP3 的升级包整体制作、分发、应用跑通之后，整个运维节奏才顺过来。

这篇东西不聊虚的，直接讲清楚 openEuler-22.03-LTS-SP3 离线升级包怎么做、怎么用、踩过哪些坑。不管你是给华为服务器批量升级，还是在 VMware 虚拟机里测试，这套思路都能直接复刻。

1. 离线升级的整体方案：为什么不能直接拷贝 RPM

很多新手第一次做离线升级，想法都很简单：找一台能联网的机器，把 RPM 包下载下来，拷贝到内网机器上一个个 rpm -ivh 装。实际一操作就翻车，最典型的问题是依赖缺失——你要升级的包依赖另外五个包，那五个包又依赖别的包，手拉手能拉出一长串，光靠肉眼根本找不全。

所以离线升级包的核心不是“下载 RPM”，而是“把所有依赖关系一起打包”。完整方案分三步：先在联网机器上把目标版本的全量依赖拉下来，再用 createrepo 生成仓库元数据，最后拷贝到内网机器配置成本地 yum 源，让系统自己处理依赖关系。这样一来，内网机器上的 yum/dnf 会像访问在线源一样工作，只是数据源从网络换成了本地目录。

这个方案有个前提条件需要注意：制作离线升级包的机器，其系统版本、架构必须和目标机保持一致。比如目标机是 x86_64 架构的 openEuler 22.03 LTS SP3，那包也要在 x86_64 的 22.03 环境里下载，不能拿 aarch64 的包直接混用，不然装的时候会报架构不匹配，白折腾一趟。

1.1 离线升级包的适用场景

离线升级包主要面向三类场景：

第一类是严格的内网隔离环境。研发网、生产网这些区域通常只有少数跳板机有外网权限，其余服务器全部物理隔离或者逻辑隔离，系统补丁、安全更新只能靠人工导入。

第二类是等保合规要求高的项目。客户现场不允许服务器直连公网，但安全扫描又催着修复漏洞，这时离线升级包是标准交付物。

第三类是批量部署场景。比如一次性给 30 台机器升级，与其每台都联网下载，不如做一份离线包，拷到内网后每台机器本地安装，速度反而更快，还不占用外网带宽。

1.2 制作与使用的整体流程图

借用一张内心的流程图（纯文字版，动手的时候按这个顺序来）：

联网中转机：配置 yum 源 → 下载全部依赖 RPM → createrepo 生成元数据 → tar 打包 目标内网机：解压 tar → 配置本地 repo → yum makecache → yum update

整个链条里最关键的一步是“下载全部依赖 RPM”，这一步做扎实了，后面所有环节都顺。

2. 动手前的准备：版本核对与中转机搭建

在开始制作离线升级包之前，有两件事必须提前确认，不然很容易白忙一场。

先看目标机的版本和架构。登录目标机执行：

cat /etc/openEuler-release uname -m

第一行会输出系统版本，比如 openEuler release 22.03 (LTS-SP3)；第二行输出硬件架构，x86_64 就是 64 位 Intel/AMD，aarch64 就是 ARM 平台。这两个信息决定了中转机上要用哪套仓库和哪套包。

接着准备中转机。中转机可以是 VMware 里的一台虚拟机，也可以是实体服务器。系统必须装 openEuler 22.03 LTS，版本建议跟目标机一致，架构必须一致。中转机需要能访问公网，至少能访问 openEuler 官方软件源。

2.1 中转机的系统与网络要求

中转机的系统建议直接安装 openEuler 22.03 LTS SP3，装好之后先确认源可用：

yum repolist

能看到 openEuler 官方源、EPOL 源等输出就说明网络和仓库都正常。如果一条记录都没有，检查 /etc/yum.repos.d/openEuler.repo 里的 baseurl 是否指向正确镜像，或者清理一下 yum 缓存：

yum clean all yum makecache

中转机磁盘空间要留够。openEuler 的基础升级包可能不大，但如果你打算做全量升级，把所有需要更新的包都拉下来，可能需要 5~10GB 甚至更多空间。建议中转机数据盘留 20GB 空间比较稳妥。

2.2 确认目标机的实际升级需求

不是所有机器都需要把系统升到最新，做离线升级包前先明确这次要升什么：

• 只修复某个安全漏洞：下载对应的补丁包及其依赖即可
• 从 SP2 升到 SP3：需要完整的升级包集合
• 内核安全更新：下载新内核相关 RPM

我建议在中转机上先把要升级的包列表列出来，方法很简单——直接对比当前版本和仓库里的最新版本：

yum list updates

执行后系统会把中转机上所有可升级的包列出来，这就是离线包的基本范围。如果目标机和中转机装的软件不完全一样，你还需要根据目标机的 rpm -qa 输出手工补充升级项。不过一般情况下的做法是：中转机装的东西比目标机更全，这样拉下来的包覆盖范围更广，到目标机上基本都能命中。

3. 核心实操：离线升级包的三个制作方法

制作离线升级包有几种常见方法，我分别说一下各自的适用场景和操作步骤。

3.1 方法一：yum install --downloadonly 下载指定包

如果你只需要升级某一个或几个确定的包，用 yum 自带的 downloadonly 参数最方便：

yum install --downloadonly --downloaddir=/data/upgrade-packages <包名>

比如要升级内核：

yum install --downloadonly --downloaddir=/data/upgrade-packages kernel

这个命令会把包和它依赖的所有包都下载到指定目录，但不会安装。注意 openEuler 22.03 默认的包管理器是 dnf，但保留了 yum 命令兼容，所以 yum 和 dnf 都可以用。如果执行后提示未知参数，用 dnf 命令代替：

dnf install --downloadonly --downloaddir=/data/upgrade-packages kernel

这个方法的局限是：一次只能处理你指定的包。要做全量升级，需要把所有可升级的包名都带上，命令行会变得很冗长。

3.2 方法二：repotrack 全量依赖下载

做全量升级包更推荐用 repotrack 命令，它来自 yum-utils 工具包。先安装：

yum install -y yum-utils

然后下载所有可升级的包：

repotrack -p /data/upgrade-packages $(yum list updates | awk 'NR>3 {print $1}')

这条命令的意思是：把 yum list updates 列出来所有可升级的包名，逐个用 repotrack 下载，每个包都会把它的全部依赖一起拉下来。-p 参数指定输出目录。

repotrack 比 downloadonly 强的地方在于：它会把指定包的所有依赖（包括运行时依赖、库依赖）全部递归下载，不会漏。对于做系统级升级，这是最可靠的方法。

如果你只想升级内核和驱动相关的包，也可以这样：

repotrack -p /data/upgrade-packages kernel kernel-core kernel-modules

注意：repotrack 下载的包数量可能非常庞大，而且包含大量重复依赖。下载完成后检查一下目录大小，心里有个数。

3.3 方法三：利用 ISO 镜像自带的升级包

openEuler 官方发布了完整的光盘镜像，SP3 的 everything ISO 里包含所有官方 RPM 包。如果内网机器可以直接挂载 ISO，这个方案更省事——不用下载，直接拷贝。

把 ISO 上传到内网，挂载：

mount -o loop openEuler-22.03-LTS-SP3-everything-x86_64.iso /mnt/openEuler-iso

ISO 里的 Packages 目录就是所有 RPM 的集合，直接把它作为本地源使用即可。这个方法适合做全新安装或者基础系统的离线升级，但如果你的软件是从 EPOL 或者第三方源装的，ISO 里可能没有对应包，还是要走前面的 repotrack 方法。

3.4 用 createrepo 生成本地仓库元数据

无论用哪种方法下载完 RPM，下一步都是把它变成可以被 yum 识别的仓库。这一步靠 createrepo 命令完成：

yum install -y createrepo cd /data/upgrade-packages createrepo .

执行成功后，目录下会生成一个 repodata 子目录，里面有仓库的元数据文件。这一步非常关键——有了 repodata，目标机才能用 yum 自动解析依赖；没有 repodata，yum 找不到本地源。

createrepo 完成后还可以验证一下仓库是否有效：

yum repolist

如果能看到以 /data/upgrade-packages 为 baseurl 的仓库出现在列表里，说明仓库制作成功。

3.5 打包分发与传输方式

仓库制作完成后，进行打包：

cd /data tar czvf openEuler-22.03-SP3-upgrade.tar.gz upgrade-packages/

然后通过 scp、移动硬盘或者受控通道把这个 tar 包传到内网目标机。需要注意：

• 包较大时建议用 tar 而不是直接拷目录，因为 tar 能减少文件数量、保持软链接关系
• 内网批量分发时可以把 tar 包放到一台内网服务器上，目标机用 wget 或 scp 下载
• 拷到目标机后先解压，解压目录需要有可执行权限

4. 目标机的离线升级执行步骤

离线包做好只是第一步，真正的考验在内网机器上执行升级。目标机上操作请按照以下流程，每一步都有它的理由。

4.1 升级前备份

别嫌麻烦，这一步坚决不能省。执行升级之前，建议对系统关键数据进行备份：

• /etc 配置目录：升级过程中配置文件可能会被覆盖或迁移
• 数据库和应用数据：如果要升级内核，可能需要重启，确保数据落盘安全
• 系统引导配置：把 /boot 下的内核文件列表记录下来

没有外接备份设备的话，至少也要用 tar 备份一份：

tar czvf /root/etc-backup-$(date +%F).tar.gz /etc

另一个推荐操作是使用 yum history 记录当前状态。升级前执行：

yum history list

可以看到当前事务列表。后面如果升级出问题，可以通过 yum history undo <事务ID> 回滚，这是 yum 自带的最强保险。

4.2 上传解压并配置本地 repo

在目标机上执行：

mkdir -p /data/upgrade-packages tar xzvf openEuler-22.03-SP3-upgrade.tar.gz -C /data/

然后新建一个本地仓库配置文件：

vi /etc/yum.repos.d/local.repo

写入以下内容：

[local-upgrade] name=Local Upgrade Repository baseurl=file:///data/upgrade-packages enabled=1 gpgcheck=0

这里 gpgcheck 设置为 0 是因为从官网镜像下载的 RPM 包已经是可信来源，且离线环境也没法在线拉取公钥。如果目标机上有 GPG 公钥，也可以改为 gpgcheck=1 并配置 gpgkey 路径，会更严谨，但增加了配置复杂度。安全要求严格的场景，建议把公钥文件一并打包导入。

配置完成后清理缓存并生成新缓存：

yum clean all yum makecache

4.3 执行升级与内核更新

缓存生成好后，先看一下有哪些包可以升级：

yum list updates

如果列出的包和你在中转机上下载的一致，说明仓库配置无误。接下来准备升级，推荐先做软件包升级，再单独处理内核升级。要注意 openEuler 22.03 的内核包更新默认会有多个内核版本共存，不会自动删旧内核，这是设计上的安全策略。

执行普通软件包升级：

yum update -y

注意：这条命令会把所有可升级的包都更新到仓库里的最新版本。如果你的离线包里只包含了部分包，而其它包在本地源里没有对应更新，yum 只会处理源里能匹配到的部分，不会报错。后面的正常流程是更新内核：

yum update kernel -y

升级完成后，确认新内核是否已经写入引导配置。openEuler 使用 GRUB2 作为引导程序，新内核安装后会自动修改 grub.cfg，但为了保险起见可以执行：

grub2-mkconfig -o /boot/grub2/grub.cfg

在部分 UEFI 环境，路径可能是 /boot/efi/EFI/openEuler/grub.cfg，用 ls 确认即可。

4.4 升级后验证

重启前先检查当前系统版本与内核版本：

cat /etc/openEuler-release uname -r

然后重启系统：

reboot

重启后再次执行 uname -r，看内核版本是否为升级后的版本。如果启动后系统启动异常，GRUB 引导菜单里有 previous 选项可以选择旧内核进入，这就是前面说的多内核共存策略的价值。

再检查关键服务是否正常：

systemctl status sshd

如果 sshd 状态正常，说明系统核心服务没有受到升级影响，离线升级基本成功。

5. 离线升级中踩过的坑与排查技巧

离线升级看着流程简单，实际操作中踩坑概率相当高。我把这几年遇到的高频问题整理成一份速查表，方便后面真遇到了直接对照排查。

5.1 高频问题对照表

5.2 几个容易忽略的细节

内核升级时的 RPM 版本匹配问题值得单独提一下。如果我们下载的 kernel 包和当前系统上的 kernel-devel 版本不匹配，编译第三方驱动（比如网卡驱动、GPU 驱动）时会报错。解决方法是把 kernel-devel、kernel-headers 和 kernel 一起打包下载，保持版本一致。

另一个容易踩的坑是 dnf 和 yum 的混用。openEuler 22.03 虽然提供 yum 命令，但底层调用的是 dnf。在制作离线包时，如果你用了 yum 命令的某些自定义插件，可能在中转机上正常，但目标机上由于没有装对应插件导致仓库解析失败。建议所有操作统一用 yum 或统一用 dnf，不要混着来。

5.3 不同架构包混用的问题

前面反复强调 x86_64 和 aarch64 的包不能混用。实际遇到过的情况是：客户给了台 aarch64 的 TAISHAN 服务器，我没注意，直接把 x86_64 中转机上做的包拷过去了，结果 yum 安装时大量报错。虽然 rpm 安装时会提示架构不匹配，但 yum 在解析依赖阶段就已经开始混乱了。

判断方法很简单：

rpm -qp --qf '%{ARCH}\n' 包名.rpm

如果目标机是 aarch64，这个包输出必须包含 aarch64 或 noarch，出现 x86_64 的包就是搞错了。

6. 把离线升级包推广到更多场景

做完一次 openEuler 22.03 LTS SP3 的离线升级包，你会发现这套方案不只是“升级一次”这么简单，它还可以延伸出很多用途。

批量同版本机器的部署可以用这个思路：把 ISO 镜像 + 离线升级包组合起来，先装基础系统，再统一更新到目标版本，整个过程全内网操作，不依赖任何外部网络。

升级之后还可以把 yum history 里的变更记录导出成报告，作为等保整改的材料提交。离线升级带来一个额外好处——因为每次升级都经过中转机中转，所有变更历史都有据可查，这块在审计的时候很有价值。

另外，如果你需要在离线环境里安装 Docker、Miniconda 或者 VSFTPD 这类常见软件，操作手法完全一样：在中转机上用 repotrack 下载软件包，然后做成本地源，内网机器通过 yum install 安装。这个思路一旦打通，离线环境下的软件安装和维护就都不是问题了。

# 以离线安装 Docker 为例，中转机上执行 repotrack -p /data/docker-packages docker-ce docker-ce-cli containerd.io

反正记住一个核心逻辑：在线机器负责解决依赖，离线机器只是搬运工。这个模式适用于所有基于 RPM 的 Linux 发行版，不只是 openEuler。

最后分享一个我自己的习惯：每次制作完成离线升级包，我都会在 /data/upgrade-packages 目录下放一个 README，写清楚这个包的制作时间、源系统版本、包含的更新内容、校验值。隔了半年后再看到这个目录，你依然能快速知道这份离线包是干什么的、能不能复用到新场景。细节做扎实了，运维工作才会真正轻松起来。

本文还有配套的精品资源，点击获取