企业官网建设流程全解析

上周又有人在群里发截图：Ubuntu 22.04 的终端里敲下yum install vim，回了一句 command not found，接着照着网上搜到的帖子apt install yum装上，再敲同样的命令，屏幕上滚出几十行红字依赖报错。这个场景我见过太多次了。Linux 世界里 apt 和 yum 分属两个不同的发行版家族，Ubuntu 是 Debian 系，原生包管理器是 apt 加 dpkg；yum 是 Red Hat 系的东西，它的下一代叫 dnf。在 Ubuntu 上装 yum、给 yum 配源、做源的更新，这一整套操作本身是成立的，但它的意义和大多数人的预期完全不同，中间还埋着几个很容易踩的坑。这篇就把 Ubuntu 上装 yum 的完整过程、yum 源文件的字段结构、换源与刷缓存的动作顺序、以及几类高频报错的排查链路一次讲透，同时也会把 Ubuntu 自己换 apt 源的正确姿势单独拎出来说清楚，因为搜"Ubuntu 源更新"的人里，一大半真正想要的是后者。

1. 别急着敲 apt install yum：先分清 apt、dpkg、yum、dnf 各自的辖区

1.1 两套体系除了都叫"包管理器"，几乎没有任何共同点

Debian 系的软件包格式是.deb，底层工具是dpkg，负责解包、写数据库、记录文件清单；apt站在 dpkg 上面，负责去远程仓库拉元数据、算依赖关系、按顺序调用 dpkg。整个体系的本地数据库在/var/lib/dpkg/下，用dpkg -l就能看到系统里所有已安装的包。

Red Hat 系的软件包格式是.rpm，底层工具是rpm，数据库默认在/var/lib/rpm/；yum是 rpm 之上的依赖解析和仓库管理工具，配置文件读/etc/yum.conf和/etc/yum.repos.d/*.repo，缓存落在/var/cache/yum/。CentOS 8 之后官方主推 dnf，dnf 用 libsolv 做依赖求解，速度和依赖冲突处理比 yum 3.x 好不少，但配置文件格式和 repo 文件语法基本兼容，所以老教程里的.repo写法在 dnf 上照样能跑。

这两套体系的核心差异在于：它们各自维护一套独立的已安装包数据库，互不感知。你在 Ubuntu 上用 dpkg 装了 vim，rpm 数据库里依然是一片空白；反过来，你在 Ubuntu 上把某个 rpm 包装进去了，dpkg 也完全不知道这些文件的存在。这个"互不感知"是后面一切麻烦的根源，记住这一点，后面很多现象就都能解释了。

1.2 到底什么场景会真的在 Ubuntu 上装 yum

不是所有在 Ubuntu 上找 yum 的人都是走错了门。我实际遇到过这几类需求：

• 交付脚本兼容性测试。甲方给的部署脚本开头就是yum install -y xxx，你想在自己的 Ubuntu 开发机上先跑一遍看看流程，看看到底会卡在哪一步。
• CI 流水线跑在 Ubuntu runner 上，但代码里带了针对 CentOS 的构建逻辑，需要验证语法层面的正确性。
• 给别的机器准备源文件。手上有几台 Rocky 或 CentOS 的服务器要离线配源，想在自己的 Ubuntu 笔记本上把.repo文件写好、把 rpm 包按目录结构整理好，再打包传过去。
• 教学和自学。想直观对比两套包管理器的输出差异，或者单纯想搞清楚yum clean all到底删了什么文件。

这几类需求里，前两类勉强能靠 Ubuntu 上的 yum 跑通一部分，第三类根本不需要装 yum（写个文本文件而已），第四类装完就能看到现象。真正"用 Ubuntu 上的 yum 去给 Ubuntu 装软件"这个需求，是不存在的。

1.3 不同 Ubuntu 版本里 yum 包的可用性差别很大

Debian 和 Ubuntu 的仓库里确实有一个叫yum的包，但它和 RHEL 系自带的 yum 不是同一个东西。Debian 侧对它做过移植和裁剪，去掉了大量和 RHEL 强绑定的逻辑，也未必带着完整的插件生态。

更麻烦的是各版本情况不一致：较老的版本能直接装，依赖链完整；较新的版本里可能因为依赖包被移除而装不上，或者装上之后插件缺失。这里没有一张能覆盖所有版本的对照表，唯一靠谱的做法是在目标机器上现场确认：

apt-cache policy yum apt-cache depends yum

第一条命令看仓库里到底有没有这个包、候选版本是多少、当前是否已装；第二条把依赖树列出来，看看依赖的 python 解释器、rpm 库这些能不能被满足。如果apt-cache policy yum的输出里 Candidate 那一栏是(none)，说明这个源里根本没有，后面就不用费劲了，直接跳到第 4、5 章去研究 repo 文件结构，用不上装 yum 这一步。

顺带说一句，WSL 里的 Ubuntu 也是 Ubuntu，仓库情况同样取决于发行版本号，不是"WSL 特供版"，别指望它有什么不同。

2. 装 yum 前必须核对的三项环境信息与一条回滚预案

2.1 三条命令把底摸清：发行版、架构、Python 现状

动手之前先采集三组信息，后面排查问题时全靠它们。

第一组是发行版和版本号：

lsb_release -a cat /etc/os-release

lsb_release不一定预装，/etc/os-release是标准文件，一定有。搞清楚自己是 20.04、22.04 还是 24.04，这不只是"知道版本"这么简单——24.04 的 apt 源格式换了，后面第 5 章会展开讲。

第二组是架构：

uname -m dpkg --print-architecture

输出x86_64和amd64是同一件事，只是两套命名习惯。如果是 ARM 机器会显示aarch64/arm64，这一点在你后面去镜像站找 rpm 包路径时非常关键，路径里的x86_64换成aarch64之后很多包根本不存在。

第三组是 Python 现状：

which python3 python python3 -V head -1 /usr/bin/yum 2>/dev/null || echo "yum 尚未安装"

最后那条命令是提前看一眼如果 yum 已经存在，它的脚本用哪个解释器启动。这类工具大多是用 Python 写的，脚本第一行的 shebang 决定了它由哪个解释器执行，一旦这个解释器和脚本语法不匹配，就会报 SyntaxError，而报错信息往往看不出是解释器的问题。这是后面第 6 章一条排查链路的伏笔。

2.2 依赖链上最容易被忽略的一环：系统 Python 不要乱动

这里插一段我认为比装 yum 本身更重要的经验。RHEL 系机器上，yum 和系统自带的 Python 版本是强绑定的，很多老版本 yum 脚本头一行写的就是 Python 2。有些人为了跑某个新工具，手动把/usr/bin/python指向了 Python 3，结果 yum 立刻全线崩溃，连卸载重装都做不了，最后只能拿救援模式进系统修。这个坑在服务器运维里属于经典事故。

Ubuntu 上虽然情况不同，但同一个道理：不要把系统默认的 Python 解释器做全局替换。真要装新版本 Python，用update-alternatives管理多版本，或者用虚拟环境隔离，别去动/usr/bin/python3这个符号链接指向的实体。Ubuntu 的系统工具链里有大量脚本依赖它，动了之后 apt 自己都可能出问题。

在 Ubuntu 上装 yum 之所以要提这个，是因为apt install yum会顺带拉入 rpm 相关的库和工具，这些工具里同样有脚本依赖解释器。装之前确认系统 Python 是干净的，能省掉后面一堆玄学问题。

2.3 备份清单和回滚路径

装之前把这几样东西记下来或备份好：

• /etc/apt/sources.list和/etc/apt/sources.list.d/整个目录，打包成 tar 放到家目录。后面折腾源的时候手一抖改错了，直接解回来。
• /etc/yum.conf和/etc/yum.repos.d/，如果已经存在的话。
• 当前已装包清单：dpkg --get-selections > ~/pkg-list-before.txt。这条命令在系统崩了想对比差异时能救命。

回滚路径也要想清楚。卸载就用：

sudo apt remove yum

但这里有个细节：apt remove yum只删 yum 本身，它拉入的 rpm 等依赖会留在系统里。如果你确定不再需要，可以用sudo apt autoremove清理孤立的依赖包，但执行前一定先加--dry-run看一眼要删什么：

sudo apt autoremove --dry-run

我见过有人直接 autoremove，结果把一些看起来"没人依赖"但实际上被手工装的工具一起清掉了。养成先 dry-run 的习惯，代价是几秒钟，收益是避免一次事故。

3. Ubuntu 上把 yum 装起来：从 apt install 到命令能执行

3.1 更新索引并安装

标准流程只有两步：

sudo apt update sudo apt install -y yum

第一条刷新本地索引，第二条真正安装。如果这一步报"无法定位软件包 yum"，说明当前源里没有，或者源本身有问题，先回去看第 2 章的环境确认，再跳到第 5 章检查 apt 源配置。

安装过程中留意终端输出里列出了哪些新增包。典型的会带上rpm、rpm-common以及若干 Python 库。这些名字记一下，出问题的时候知道是哪个组件在捣乱。

3.2 装完之后为什么几乎装不了任何软件

这是所有人装完 yum 之后最想不通的地方：命令能跑，yum --version也正常输出，但yum install任何一个包都会失败。原因在 1.1 节已经埋下了，这里展开说。

yum 装包的工作流大致是：读 repo 文件里的地址，下载 repodata 元数据，在本地算出依赖树，然后调用 rpm 把包写进 rpm 数据库，同时校验文件冲突。问题出在最后一步——Ubuntu 上的 rpm 数据库是刚被创建出来的空库，里面一条记录都没有。于是 yum 会认为系统里连 glibc、bash 这些东西都没装，然后试图从仓库里把整个基础系统重装一遍，而这些 rpm 包安装时会往/usr/bin、/lib这些目录写文件，和 dpkg 已经管理的文件直接冲突。

就算你强行用--nodeps跳过依赖检查塞进去一个包，结果也不会好：dpkg 不知道这些文件存在，下次 apt 升级时可能把它们覆盖掉，或者因为文件冲突直接报错停下。系统会进入一种两套包管理器互相打架的状态，非常难受。

所以结论很明确：Ubuntu 上的 yum 可以当配置解析器和元数据下载器用，不能当真正的包管理器用。想验证这个结论，随便挑一个包试一次就知道了。

如果目标只是"在 Ubuntu 上拿到某个 rpm 文件"，有更直接的路子：按镜像站上的 repodata 索引里的路径直接用wget下载，或者用apt-get download拿 deb 包。没必要绕道 yum。

3.3 验证安装结果与第一轮检查

装完之后跑这几条：

yum --version yum repolist all ls -l /etc/yum.repos.d/ cat /etc/yum.conf

yum --version正常会打印版本号和配置目录位置。如果这里直接抛出一段 Python 的 SyntaxError 或者 ImportError，说明脚本的 shebang 指向的解释器和脚本语法对不上，用head -1 /usr/bin/yum看一眼它调的是哪个解释器，再用apt-cache depends yum核对依赖列表，看是不是某个解释器或库没有正确装上。

yum repolist all会列出识别到的所有仓库，包括启用和禁用的。输出里出现repolist: 0是正常的，因为/etc/yum.repos.d/目录刚开始一般是空的或者只有 Ubuntu 打包时带的占位文件。这一步的目的不是让它列出多少仓库，而是确认 yum 能正常读取配置目录并且没崩。

4. 把 .repo 文件拆成零件看：yum 源的每一个字段在管什么

4.1 一个仓库文件的完整字段说明

yum 读的所有仓库定义都在/etc/yum.repos.d/目录下，而且只认.repo后缀。文件名随便起，但后缀必须是.repo，写成.repo.txt、.conf都不会被读取。这个细节坑过不少人，尤其是从 Windows 传文件上来的时候，系统自动加了后缀。

一个典型的仓库定义长这样：

[base] name=Base Repository baseurl=http://mirrors.aliyun.com/rockylinux/9/BaseOS/x86_64/os/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 metadata_expire=3600 cost=1000

逐字段说清楚：

关于baseurl指向哪一层，这是最容易写错的地方。你打开浏览器访问镜像站，看到的是.../9/BaseOS/x86_64/os/这样的目录，里面有一个repodata子目录和一个Packages子目录。baseurl 就写这个os/这一层，不要写到 repodata 里面去。写成.../os/repodata/是最常见的低级错误，报错信息是下载 repomd.xml 失败。

4.2 mirrorlist 和 baseurl 该选哪个

mirrorlist 指向一个纯文本列表，里面一行一个镜像地址，yum 会从中选一个用。理论上更健壮，某个镜像挂了能自动切下一个。但它有两个现实问题：一是列表文件需要维护方持续更新，很多老发行版停止支持后这个列表就没人管了，指向的地址全部失效；二是排查问题时链路变长，你不确定 yum 最终用的是哪个地址。

baseurl 是硬编码一个地址，简单直接，出问题一眼就能看出来。

我的建议是：在自己维护的机器上，一律用 baseurl 写死一个国内公共镜像站的地址，同时把 mirrorlist 那行注释掉或者删掉。理由是可控性远比"自动切换"重要，镜像站本身可用性都挺高，真挂了手动改一行也很快。而且写死地址之后，第 6 章那类"下载元数据失败"的报错排查会简单很多，直接curl那个地址看返回码就行。

4.3 gpgcheck 关不关：一个需要想清楚的问题

gpgcheck 决定 yum 是否用公钥去校验下载下来的 rpm 包签名。校验能挡住的场景是：镜像站被劫持、下载过程中包被篡改、或者有人故意往仓库里塞了伪造的包。

很多教程为了"一次跑通"，直接教你写gpgcheck=0，省掉配公钥的麻烦。这样做确实能立刻解决报错，但你要清楚代价：你放弃了验证包来源的能力，装进来的东西是什么全凭运气。生产环境上我强烈建议保持gpgcheck=1，公钥从发行版官方的 keyring 包里取，比如 Rocky 系统上可以装rocky-release或rocky-gpg-keys包，公钥会自动落到/etc/pki/rpm-gpg/目录，直接引用就行。

如果确实需要临时关掉校验来先跑通流程，那就只关这一个仓库，别去改全局配置/etc/yum.conf，也别在多个仓库里批量关。问题定位完之后马上改回来。

5. 源更新的动作分解：换地址、清缓存、重建元数据谁先谁后

5.1 换源改的是哪一行，以及 Ubuntu 自己换源的正确姿势

先纠正一个高频混淆：在 Ubuntu 上谈"源的更新"，指的应该是 apt 源，不是 yum 源。这两个是完全不同的文件。

Ubuntu 的 apt 源在较老版本里是/etc/apt/sources.list单文件，一行一条记录。换源就是把里面的archive.ubuntu.com、security.ubuntu.com替换成国内镜像站域名。但 Ubuntu 24.04 换了格式，改用/etc/apt/sources.list.d/ubuntu.sources，是 deb822 风格的结构化文件：

Types: deb URIs: http://archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

拿老教程里的sed命令去替换 24.04 上已经不存在的sources.list，命令会静默成功但什么都没改，然后你会很困惑为什么速度没变。所以第一步永远是确认文件在哪：

grep -rn "archive.ubuntu.com" /etc/apt/

这条命令会告诉你真实的配置落在哪个文件里，两边都查，省得漏掉。

至于用哪个镜像站，选离自己网络近的就行，各家都有完整的 Ubuntu 镜像。换完之后：

sudo apt update sudo apt-cache policy | head -20

第二条命令能看出实际生效的源地址，确认改动落地了。

5.2 yum clean all 和 makecache 到底在删什么、下什么

回到 yum 这边。改完 repo 文件之后，不能马上执行安装，因为本地还存着旧源的元数据。这时候要跑的是一组固定动作：

yum clean all yum makecache

yum clean all清理的是/var/cache/yum/下的内容，具体包括packages（下载下来的 rpm 文件）、metadata（仓库元数据）、dbcache（解析后的数据库缓存）、headers、plugins和expire-cache几个子目录。注意它不会碰/etc/yum.repos.d/里的配置文件，也不会动 rpm 数据库，所以这个命令是安全的，出问题的时候可以放心执行。

yum makecache做的是相反方向的事：把每个启用仓库的 repodata 下载到本地并解析成缓存，下次安装时就不用再跑网络了。

顺序不能颠倒。先 clean 再 makecache，这才是"用新配置重建缓存"。反过来先 makecache 再 clean，等于白干一遍。

如果想更精细一点，可以只清元数据不清包文件：

yum clean metadata yum makecache fast

makecache fast会先尝试复用已有缓存，速度快一些。不过在刚换完源的场景下，我一般还是老老实实跑完整的clean all加makecache，慢几十秒换取确定性。

5.3 用 Ubuntu 当跳板给 RHEL 系机器准备源文件

这是我个人用得最多的场景，也顺便回答"为什么要在 Ubuntu 上折腾 yum 源"。

假设手上有一批 Rocky 9 的机器在内网，不能直连外网，需要在 Ubuntu 笔记本上把 repo 文件和离线包准备好，再整体拷进去。流程大概是：

第一步，在 Ubuntu 上把仓库文件写好，用 Rocky 9 的镜像路径：

[rocky-baseos] name=Rocky Linux 9 BaseOS baseurl=http://mirrors.aliyun.com/rockylinux/9/BaseOS/x86_64/os/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.aliyun.com/rockylinux/RPM-GPG-KEY-Rocky-9

第二步，用wget按 repodata 里的索引把需要的 rpm 拉下来，按Packages/目录结构存在本地。要精确知道某个包在哪个子目录，可以从primary.xml.gz里查，或者更省事地用一个 Rocky 容器临时跑dnf download。

第三步，如果要让内网机器像访问网络仓库一样访问这个本地目录，就在 Ubuntu 上起一个静态文件服务：

python3 -m http.server 8080 --directory /path/to/repo-root

然后内网机器的 repo 文件里 baseurl 就写http://<ubuntu-ip>:8080/。这样完全不需要在那台 Ubuntu 上跑 yum 本身，只需要它当个文件服务器加配置编辑器。

这个方案的好处是分工清晰：Ubuntu 负责文本和网络，RHEL 系机器负责 rpm 和依赖求解，两者各干自己擅长的事，绕开了第 3.2 节说的那堆问题。

6. 报错现场：五类高频问题的定位链路

6.1 下载元数据失败：从 repomd.xml 往回查

报错长这样：

Error: Failed to download metadata for repo 'base': Cannot download repomd.xml

这条链路我按顺序查四件事：

第一，把 baseurl 拼上repodata/repomd.xml，用curl -I请求一次：

curl -I http://mirrors.example.com/rockylinux/9/BaseOS/x86_64/os/repodata/repomd.xml

看到 404 就是路径写错了，看到 200 说明地址没问题，问题在本地。

第二，看是不是 mirrorlist 在作怪。如果 repo 文件里两行都在，yum 会优先用 mirrorlist，而那份列表很可能已经过期。把 mirrorlist 那行注释掉重试。

第三，看发行版是不是已经停止支持。CentOS 8、CentOS 7 这些版本陆续停服之后，原来的镜像路径会被移走，再访问就是 404。这种情况得把 baseurl 改成归档地址。判断方法很简单：访问镜像站的根目录，看看原来那个版本号目录还在不在。

第四，检查代理和时间。有些内网机器要用代理才能出网，/etc/yum.conf里没配proxy=就会一直失败。时间不对会导致 TLS 握手失败，用timedatectl看一眼同步状态。

6.2 GPG 校验失败：分清是缺公钥还是真被改过

两类报错要分清：

GPG key retrieval failed: [Errno 14] ... Public key for xxx.rpm is not installed

第一种是公钥本身没拿到，通常是gpgkey=那行的地址访问不通，或者写成了需要额外配置的格式。先curl一下那个 key 地址能不能下载。

第二种是公钥有了，但包的签名对不上。这可能是仓库被换过、包被重打过，也可能是公钥版本不对——比如你把 Rocky 9 的公钥配到了访问 Rocky 8 仓库的配置上。核对一下公钥和仓库版本是否对应。

处理这类问题，正确顺序是先确认公钥能下、再确认版本匹配、最后才考虑临时关校验。不要一看到 GPG 报错就把 gpgcheck 改成 0，那等于把安全机制整个拆掉。

6.3 命令找不到或 Python 报错：从 shebang 往回查

如果敲yum提示 command not found：

which yum ls -l /usr/bin/yum

看文件是否存在、是否有执行权限。如果路径里有但执行报错，看报错类型。Python 的 SyntaxError 或 ImportError 基本都指向解释器问题，用head -1看 shebang 指向哪个解释器，再确认那个解释器是否装了脚本需要的模块。

有时候现象会伪装成别的问题，比如报No module named yum，看起来像 yum 没装，实际是 Python 的模块搜索路径没包含 yum 的安装目录。这种情况用dpkg -L yum列出这个包装了哪些文件，看看模块落在哪，再对照python3 -c "import sys; print(sys.path)"的输出。

6.4 锁文件残留：Another app is currently holding the yum lock

这个报错说明有个进程占着锁没释放，通常是上次操作被 Ctrl+C 中断留下的：

ls -l /var/run/yum.pid cat /var/run/yum.pid

先看那个 PID 对应的进程是不是还在运行。如果在跑，等它跑完。如果进程早就不在了，锁文件就是残留，删掉即可：

sudo rm -f /var/run/yum.pid

删之前务必确认没有正在运行的 yum 进程，否则会破坏正在进行的安装事务。这个习惯比命令本身重要。

6.5 依赖求解失败：先分清是真缺包还是索引过期

Error: Package: xxx requires: yyy

这类报错的第一反应不该是去找包，而是先确认元数据是新的一版。索引太旧会让 yum 看不到仓库里新增的依赖包。先跑一次yum clean all && yum makecache再看。

如果刷完缓存还是报缺依赖，那就是仓库本身确实没有。这时候看缺的是什么：如果是基础库，说明仓库配置不完整，比如只配了 BaseOS 没配 AppStream；如果是第三方包，那就是需要额外引入对应的仓库。这类问题在 Rocky、Alma 上尤其常见，因为它们的软件包是按仓库拆分的，缺一个仓库就缺一批包。用yum repolist列出所有启用的仓库，对照官方文档确认该有的都配齐了。

7. 几个我实际踩过的坑，以及什么时候该放弃 yum

先说一个最容易被忽略的：.repo文件后缀和编码。从 Windows 传配置文件到 Linux 上，文件名可能被加上了.txt，行尾可能变成 CRLF。这两个问题都会让 yum 完全读不到配置，而且报错信息不会告诉你原因，只会说找不到仓库。拿到配置文件后先跑：

file /etc/yum.repos.d/*.repo

如果输出里有 "CRLF line terminators"，用sed -i 's/\r$//'处理一遍。这个动作应该加进肌肉记忆里。

第二个坑是在 Ubuntu 上装了 yum 之后，忘了它和 apt 是两套东西。有人装完 yum 之后一直在纠结"为什么 yum 装的包 apt 看不到"，然后在两个工具之间反复横跳，最后系统里文件冲突一堆。记住第 1 章的结论，Ubuntu 上就以 apt 为准，yum 只在明确知道自己在干什么的时候用。

第三个坑是镜像站的选择要匹配发行版。把 Ubuntu 的包路径配上 CentOS 的地址，或者反过来，都会得到 404。不同发行版的目录结构差异不小，Rocky 的包在BaseOS和AppStream两个目录下，CentOS 7 是os和updates，写之前去镜像站根目录逛一圈，比照着教程抄快得多。

至于什么时候该放弃：如果你在 Ubuntu 上折腾 yum 超过半小时还是跑不通任何一个实际安装，那就该停下来了。因为 Ubuntu 上本来就不需要 yum 来管理软件，你继续投入时间的地方，是一个它设计上就不打算承担的角色。换成用 apt 管理 Ubuntu 自己，用容器或者虚拟机专门跑 RHEL 系的机器，把两件事彻底隔开，效率会高得多。我在自己机器上就是这么干的：宿主机跑 Ubuntu 日常开发，需要研究 rpm 和 yum 的时候随手起一个 Rocky 的容器，配置文件和命令行全在里面练，练完销毁，宿主机干干净净。这个习惯帮我省掉了大量"把一个工具用在不该用的地方"带来的排查时间。