企业官网建设流程全解析

yum 这套包管理机制，只要你用的是 RedHat 系发行版，基本躲不开。新机器装完系统第一件事往往不是配服务，而是先把源换掉——因为默认源要么慢得让人怀疑人生，要么干脆连不上。这篇文章就聊怎么给 Linux 换上阿里云的网络 yum 源，从"为什么要换"到"换完怎么验证"，再到"换完之后报错怎么办"，一条线走完。内容以 CentOS 7 为主轴，同时把 CentOS 8、Rocky Linux、AlmaLinux 的写法一并带上，最后再补一段内网离线环境搭本地源的思路。不管你是刚接触 Linux 的新手，还是常年跟服务器打交道的运维，配 yum 源这个动作都算基本功，而基本功最容易在细节上翻车。我会把自己踩过的坑、验证过的方法、以及那些官方文档里不写的经验都摊开说，让你照着做就能通，出了问题也知道去哪儿找原因。

1. yum 源这件事，为什么值得单独拿出来讲

1.1 默认源慢与失效的真实原因

很多人第一次装完 CentOS，敲一句yum install vim就开始等，等三五分钟没动静，以为是网络坏了，其实是默认源在拖后腿。RedHat 系系统的默认 yum 源指向的是境外服务器，物理链路要绕一大圈，延迟高、丢包多，高峰期下载几十 MB 的包能磨掉十几分钟。更麻烦的是从 2024 年下半年开始，CentOS 7 正式走完生命周期，官方镜像站的目录结构做了调整，原来mirror.centos.org/centos/7/这个路径下的内容被迁到了 vault 归档目录，直接照抄老教程里的地址，刷新缓存时会甩给你一串HTTP Error 404或者Cannot find a valid baseurl for repo。这不是网络问题，是源地址本身已经作废了。

yum 的工作原理其实不复杂，它先去 repodata 里拉一份元数据，也就是记录着"这个仓库里有哪些包、每个包什么版本、依赖谁"的清单，然后根据你的安装请求算出需要下哪些包。元数据拉不下来，后面的一切都免谈。所以换源本质上换的是两样东西：一是 repodata 的获取地址，二是 rpm 包的实际下载地址。这两样都指向同一个镜像站，速度才起得来。

1.2 换成阿里云镜像后到底快多少

阿里云开源镜像站是国内做得比较扎实的一个，覆盖了 CentOS、Rocky、AlmaLinux、Ubuntu、Debian 等主流发行版，同步频率高，带宽也足。我在同一台 ECS 上做过对比测试，用默认源装gcc加上一堆依赖，前后折腾了将近八分钟；换成阿里云源之后同样一套包，一分半左右搞定。这个差距在批量初始化机器的时候会被放得特别大——你同时开十台机器装环境，省下来的就是实打实的工时。

除了快，还有稳定性。国内镜像站不用绕国际出口，晚上高峰期的抖动明显小，脚本里跑yum install -y不容易因为超时中断。对于自动化部署来说，这一点比单纯的"快"更重要，因为超时重试的逻辑写起来很烦，能不重试就不重试。

1.3 换源前必须搞清楚的三个前提

第一，你得知道自己的机器能上外网。有些内网环境是隔离的，压根连不到镜像站，这种场景不是换源能解决的，得走本地源或者内网自建源，后面第 4 章会讲。

第二，你得知道系统版本和架构。CentOS 7 和 CentOS 8 的 repo 文件内容完全不同，x86_64 和 aarch64 的包路径也不一样，写错了就是 404。

第三，你得留后路。换源之前先备份原有的 repo 文件，万一改崩了还能退回去。这个动作只要十秒钟，但能救命。

注意：不要在不清楚系统版本的情况下直接复制粘贴网上的换源命令。很多老教程是针对 CentOS 7 写的，你拿到 CentOS 8 或者 Rocky 9 上用，轻则报错，重则把原有配置搞得一团糟。

2. 动手前的情报收集与安全备份

2.1 先确认发行版、版本号和架构

动手之前先把这三条命令敲一遍，结果记下来：

cat /etc/redhat-release cat /etc/os-release uname -m

第一条给出的是发行版名称和版本号，比如CentOS Linux release 7.9.2009 (Core)。第二条信息更全，会带上VERSION_ID和ID字段，脚本里解析版本号一般用这个文件。第三条给出 CPU 架构，x86_64是最常见的，国产化环境里aarch64也很普遍，个别场景还会遇到loongarch64。

为什么要这么较真？因为 yum 仓库的路径是按$releasever和$basearch两个变量拼出来的，前者对应大版本号（CentOS 7 就是 7），后者对应架构。如果这两个变量解析出来的值和你预期的镜像路径对不上，刷新缓存必然失败。特别是从 CentOS 7 升到 7.9 这种小版本变化，$releasever仍然是 7，不会变成 7.9，这一点新手容易搞混，写 vault 路径的时候要写全7.9.2009才行。

2.2 摸清 /etc/yum.repos.d 目录的家底

所有 yum 仓库的定义文件都放在/etc/yum.repos.d/下面，扩展名是.repo。先看看里面有什么：

ls -l /etc/yum.repos.d/

CentOS 7 标准安装完之后，这个目录里通常躺着这么几个文件：CentOS-Base.repo是主仓库，也是我们最需要改的；CentOS-CR.repo是持续交付仓库，一般用不上；CentOS-Debuginfo.repo是调试符号包，普通用户不需要；CentOS-fasttrack.repo是快速通道；CentOS-Media.repo是光盘源，默认禁用；CentOS-Sources.repo是源码包。还有CentOS-Vault.repo，这个在 EOL 之后反而变得有用了。

真正要动的主要是CentOS-Base.repo。其他文件保持默认禁用状态就行，除非你有明确需求。有些人图省事把整个目录清空再塞一个新文件进去，这种做法我不推荐——万一新文件有问题，你连回退的余地都没有了。留着原来的，改掉一个，是最稳的路子。

2.3 备份：一步不能省的操作

备份这件事，说一百遍都不算多。我见过太多次因为没备份，改崩了只能重装系统的例子。

cd /etc/yum.repos.d/ mkdir -p backup cp -a *.repo backup/

用cp -a而不是普通cp，是为了保留文件的权限、属主和时间戳，万一需要恢复，cp -a backup/*.repo /etc/yum.repos.d/就能原样还原。或者更直接一点，给单个文件加个后缀：

mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak

这样原文件还在，只是扩展名变了，yum 不会去读它。等新的配好验证通过，再决定是删还是留。

提示：备份目录不要放在/etc/yum.repos.d/里面还用.repo结尾，否则 yum 会把它也当成仓库定义文件去解析，平白多出一堆报错。用backup这种不带.repo的目录名是最省心的做法。

3. 阿里云 yum 源的三种配置方式与完整实操

3.1 方式一：直接下载官方 repo 文件（最省事）

阿里云镜像站专门放了一个 repo 文件的下载目录，地址是https://mirrors.aliyun.com/repo/。里面按发行版和版本准备了现成的配置文件，CentOS 7 对应的是Centos-7.repo。操作就三步：

cd /etc/yum.repos.d/ curl -o CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo yum clean all && yum makecache

第一条是确保你在正确的目录下操作，第二条用curl把文件拉下来并直接命名为CentOS-Base.repo，覆盖掉原来的。如果你习惯用wget，把curl -o换成wget -O也是一样的效果。如果系统里这两个工具都没有——这种情况在最小化安装的机器上很常见——那就用yum install -y curl wget先装上，或者干脆用python -c之类的办法，不过最省事的还是先用CentOS-Media.repo挂光盘装一个。

下载完成之后，强烈建议先cat一眼看看内容：

cat /etc/yum.repos.d/CentOS-Base.repo

重点看baseurl是不是指向mirrors.aliyun.com，gpgcheck是不是 1，gpgkey路径对不对。正常情况下阿里云提供的这份文件已经把 mirrorlist 去掉，直接写死了 baseurl，省去了 yum 再去逐个探测镜像的环节，速度会更快一些。

这个方式的好处是快、准、不用理解 repo 文件语法。缺点也明显——万一你遇到的是 CentOS 7 EOL 之后的情况，这份文件里写的路径可能已经 404 了，这时候就得用下面的方式二做二次修改。

3.2 方式二：sed 批量改写现有 repo 文件

如果你不想下载外部文件，或者下载的 repo 文件路径已经失效，那就直接改本地的。核心思路是把mirrorlist行注释掉，把baseurl行启用并指向阿里云。

先看一眼原来的写法：

grep -E '^(mirrorlist|#baseurl|baseurl)' /etc/yum.repos.d/CentOS-Base.repo

CentOS 7 默认文件里，mirrorlist是启用的，#baseurl是注释掉的，而且baseurl指向的是http://mirror.centos.org。我们要做的就是反转这个状态：

sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-Base.repo sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=https://mirrors.aliyun.com|g' /etc/yum.repos.d/CentOS-Base.repo

用的是|作为分隔符而不是/，因为待替换的字符串里本身就含有斜杠，用|可以省去大量转义，写错的风险小很多。替换完再grep一次确认。

这里有个关键点：CentOS 7 EOL 之后，mirrors.aliyun.com/centos/7/这个路径下的内容已经被移到mirrors.aliyun.com/centos-vault/7.9.2009/了，替换出来的 baseurl 拼上$releasever之后大概率会 404。解决办法是把版本号写死：

sed -i 's|mirrors.aliyun.com/centos/\$releasever|mirrors.aliyun.com/centos-vault/7.9.2009|g' /etc/yum.repos.d/CentOS-Base.repo

注意$releasever里的$在 sed 表达式里要转义成\$，否则 shell 会先把它展开成空字符串，替换结果就错了。这条命令执行完之后，再把$basearch保留原样，它会由 yum 在运行时解析成实际架构。

3.3 方式三：手写一份最小可用 repo 文件

有时候机器上的 repo 文件被前人改得乱七八糟，不如推倒重来。新建一个文件，写这么一段：

[base] name=CentOS-7 - Base - mirrors.aliyun.com failovermethod=priority baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/RPM-GPG-KEY-CentOS-7 enabled=1 [updates] name=CentOS-7 - Updates - mirrors.aliyun.com failovermethod=priority baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/updates/$basearch/ gpgcheck=1 gpgkey=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/RPM-GPG-KEY-CentOS-7 enabled=1

[base]和[updates]是仓库 ID，方括号里的名字随便起，但要保证唯一。baseurl是这个仓库的根地址，指向包含repodata目录的那一层。gpgcheck=1表示下载的包要做签名校验，gpgkey就是公钥的地址。enabled=1表示默认启用，写成 0 就是默认禁用。

注意：baseurl的末尾那个斜杠不能少。看起来是小事，但少一个斜杠，yum 拼出来的 repodata 路径就会变成.../x86_64repodata/repomd.xml，报到你怀疑人生。

这种手写方式的优势是完全可控，你知道每一行在干什么。代价是扩展仓库（比如 extras、centosplus）得自己一条条补，比较费时间。生产环境里我一般还是用方式一加方式二的组合，手写只在排查问题时临时用。

3.4 刷新缓存并验证配置是否真的生效

不管用哪种方式配好，接下来这四步是固定动作：

yum clean all yum makecache yum repolist all yum install -y vim

yum clean all把本地缓存的元数据和包清掉，避免旧缓存干扰；yum makecache重新从各个仓库拉取元数据并缓存到本地，这一步的输出会明确告诉你哪个仓库拉了多少个包；yum repolist all列出所有仓库及其状态，你能一眼看到哪些是 enabled、哪些是 disabled；最后装个小包验证一下实际下载速度。

yum repolist all的输出里，如果某个仓库显示0个包，或者状态是enabled但仓库名后面带着奇怪的报错，那就说明这个仓库有问题。正常情况 base 加 updates 加起来应该有上万条记录。

还有个细节值得观察：yum makecache跑完之后会提示Metadata Cache Created，耗时通常在几秒到十几秒。如果这个时间特别长，说明镜像站虽然通了但带宽一般，可以考虑换成其他国内镜像作为备选，多个源互为补充也是一种策略。

4. 不同发行版与特殊场景的处理

4.1 CentOS 7 与 8 走向 EOL 后的路径变化

CentOS 7 在 2024 年 6 月底结束了维护周期，CentOS 8 更早，2021 年底就停了。停维带来的直接影响是官方镜像站上的非归档目录不再更新，很多内容被搬到了 vault。这就解释了为什么那么多人在换源的时候撞上 404——教程还是老教程，路径已经不是老路径了。

针对 CentOS 8，vault 的路径是https://mirrors.aliyun.com/centos-vault/8.5.2111/，注意 CentOS 8 最后一个小版本是 8.5.2111。同样要把$releasever替换成写死的版本号。CentOS 8 用的是 dnf 而不是 yum，不过 dnf 完全兼容 yum 的命令行，dnf makecache和yum makecache效果一样。

需要提醒的是，CentOS 8 后来演变成了 CentOS Stream，仓库结构和 CentOS 8 不太一样。如果你在跑 Stream，直接按 Stream 的路径来配，别混用。

现实一点说，还在用 CentOS 7 的机器现在应该考虑迁到 Rocky 或者 AlmaLinux 了，这两个是社区接棒的产物，仓库结构和 CentOS 8 基本一致，迁移成本不算高。

4.2 Rocky Linux 与 AlmaLinux 的换源写法

Rocky Linux 9 的换源命令大致是这样：

sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.aliyun.com/rockylinux|g' \ -i.bak /etc/yum.repos.d/Rocky-*.repo dnf makecache

注意这里用的是$contentdir而不是$releasever拼路径，contentdir会在运行时解析成rocky，所以最终地址是mirrors.aliyun.com/rockylinux/9/...。-i.bak的作用是就地修改的同时自动生成一个.bak备份，省得自己再手动备份一遍。

AlmaLinux 9 的写法类似，但原文件里baseurl前面通常带一个空格：

sed -i.bak -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^# baseurl=https://repo.almalinux.org|baseurl=https://mirrors.aliyun.com/almalinux|g' \ /etc/yum.repos.d/almalinux*.repo dnf makecache

不同小版本的 repo 文件原始地址可能略有差异，动手之前先cat一下看看，或者用grep -n baseurl把相关行都列出来，确认清楚了再批量替换。盲目替换的结果往往是有的仓库改了有的没改，报错信息还特别难懂。

4.3 内网离线环境：本地 yum 源搭建思路

内网机器连不上外网，这时候网络 yum 源再好也白搭，只能搭本地源。主流做法有两种：挂 ISO 镜像，或者用内网的 HTTP 服务器做仓库。

单机挂 ISO 的操作是这样：

mkdir -p /mnt/cdrom mount -o loop /path/to/CentOS-7-x86_64-DVD-2009.iso /mnt/cdrom cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=Local CentOS 7 DVD baseurl=file:///mnt/cdrom gpgcheck=0 enabled=1 EOF yum clean all && yum makecache

gpgcheck=0是因为本地 ISO 的包一般没必要再校验，省得导入公钥的麻烦。挂载命令如果机器有光驱，也可以直接mount /dev/sr0 /mnt/cdrom。

如果内网机器多，每台都挂 ISO 太笨，可以在内网找一台机器把 ISO 内容解压到 Web 根目录，然后用http://内网IP/centos7/这种地址作为 baseurl。再进一步，用reposync把外网仓库同步到本地，配合定时任务每天增量更新，这就是自建镜像站的路子了。

4.4 顺手把 EPEL 源一起配了

EPEL 是 Extra Packages for Enterprise Linux 的缩写，里面有很多官方仓库不提供的常用工具，比如htop、nginx、certbot。配完主源之后顺手把它加上，能省不少事：

yum install -y epel-release sed -i 's|^metalink=|#metalink=|g' /etc/yum.repos.d/epel.repo sed -i 's|^#baseurl=http://download.fedoraproject.org/pub/epel|baseurl=https://mirrors.aliyun.com/epel|g' /etc/yum.repos.d/epel.repo yum makecache

或者更直接：

curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo

顺带说一句，EPEL 在 CentOS 7 上是 7 版本，CentOS 8、Rocky 9 上对应 8 和 9，装的时候版本要对上，不然又是 404。

5. 报错现场：常见问题与排查思路

5.1 缓存刷新失败：从报错信息倒推原因

yum makecache报错是最常见的场景，报错内容大致能分成几类。

一类是Cannot find a valid baseurl for repo: base/7/x86_64。这句话的意思是 yum 找不到可用的仓库地址。常见原因有三个：repo 文件里mirrorlist和baseurl两个都被注释掉了；baseurl拼出来的地址确实访问不到；或者网络本身不通。排查顺序是先cat看配置文件，再curl -I手动访问一下 baseurl，最后再检查网络。

另一类是repomd.xml: [Errno 14] HTTP Error 404 - Not Found。这个基本可以断定是路径错了，多半是没把$releasever替换成实际的 vault 路径，或者版本号和实际系统对不上。把 baseurl 复制出来，去掉末尾的$basearch，用浏览器或者curl访问一下，看目录结构对不对，一目了然。

还有一类是Failed to synchronize cache for repo 'xxx'，后面跟着一串具体的网络错误。这种要看错误类型，Couldn't resolve host是 DNS 问题，Connection timed out是网络不通或者被防火墙拦了，SSL certificate problem是证书问题。对症下药就行。

5.2 GPG 校验与密钥导入的那些坑

Public key for xxx.rpm is not installed这个报错，说明包下下来了但签名校验过不去。解决办法是导入对应的公钥：

rpm --import https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/RPM-GPG-KEY-CentOS-7 rpm --import https://mirrors.aliyun.com/epel/RPM-GPG-KEY-EPEL-7

或者从本地文件导入：rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7。

如果你实在不想折腾签名校验，可以在 repo 文件里把gpgcheck改成 0。但我不建议这么做，尤其是在生产环境。签名校验是防止包被篡改的一道防线，关掉它等于把这道门拆了。真遇到了问题，优先去解决密钥导入，而不是绕过校验。

还有一种情况是GPG key retrieval failed，意思是公钥文件本身下载不到。这时候检查一下gpgkey这一行写的路径，是不是也用了已经失效的旧地址。跟 baseurl 一样，EOL 之后密钥文件的路径也可能变。

5.3 网络、DNS 与代理的连锁反应

有些机器 yum 报错，根源根本不在 yum，而在网络配置。排查这类问题，我的习惯是从底层往上层走。

先看 DNS：

cat /etc/resolv.conf ping -c 3 mirrors.aliyun.com

resolv.conf里如果nameserver是空的或者指向一个不通的地址，域名解析必然失败，报错就是Couldn't resolve host。改一个可用的 DNS 上去，问题立刻消失。ping通不通也能说明不少问题，通说明网络层没问题，不通就要看路由和网关。

再看是不是走了代理。有些企业环境强制走代理出网，yum 不配代理就出不去。这种情况下要在/etc/yum.conf里加上：

proxy=http://proxy.example.com:8080

或者在环境变量里配http_proxy和https_proxy。这里要注意，yum 读的是配置文件里的 proxy 设置，不完全依赖环境变量，两个地方都检查一遍比较稳妥。

最后还得看一眼防火墙。本机的 iptables 或者 firewalld 如果规则过严，出站的 443 端口被挡了，也会表现为连接超时。这种问题在内网服务器上其实挺常见的，尤其是那些从别处接手过来的机器。

5.4 一张速查表覆盖八成故障

这张表里的最后一条挺有意思，yum lock在自动化脚本并发执行时经常撞上。做法要么是加锁等待，要么在脚本里判断一下pgrep yum再决定是否继续。

6. 实操心得与长期维护

6.1 几个我踩过的坑

第一个坑是"只看不验"。改完 repo 文件直接跑yum install，报错了才开始回头查，其实每次改完先跑一遍yum repolist all，几十秒就能确认配置对不对，省下的时间远比这几十秒多。

第二个坑是"sed 漏掉了某一行"。CentOS-Base.repo 里[base]、[updates]、[extras]这几个 section 都有 mirrorlist 和 baseurl，每条都要处理。用通配替换的时候要确认模式匹配上了，可以先用不带-i的 sed 跑一遍看看输出，确认无误再就地修改。

第三个坑是"误删了 Media 源"。有些教程教你把/etc/yum.repos.d/清空，结果最小化安装、网络又不通的环境下，连装个 curl 都做不到，彻底陷入死循环。留着 Media 源当兜底，关键时候能救场。

第四个坑是"在企业内网直接照抄外网配置"。内网通常有自建的镜像源或者代理，外网地址不一定通。进来先问清楚网络环境，比上来就改配置高效得多。

6.2 把换源动作写进初始化脚本

机器一多，手动换源就是折磨。我的做法是写一个初始化脚本，把版本判断、备份、替换、验证这几步全包进去。核心思路是用ID和VERSION_ID两个变量来分支：

#!/bin/bash set -e source /etc/os-release REPO_DIR=/etc/yum.repos.d BACKUP_DIR=${REPO_DIR}/backup_$(date +%Y%m%d) mkdir -p ${BACKUP_DIR} cp -a ${REPO_DIR}/*.repo ${BACKUP_DIR}/ 2>/dev/null || true case "${ID}-${VERSION_ID}" in centos-7) curl -fsSL -o ${REPO_DIR}/CentOS-Base.repo \ https://mirrors.aliyun.com/repo/Centos-7.repo ;; centos-8|centos-8.*) curl -fsSL -o ${REPO_DIR}/CentOS-Base.repo \ https://mirrors.aliyun.com/repo/Centos-8.repo ;; rocky-9*|almalinux-9*) sed -i.bak -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.aliyun.com/rockylinux|g' \ ${REPO_DIR}/*.repo ;; *) echo "unsupported distro: ${ID} ${VERSION_ID}" exit 1 ;; esac yum clean all yum makecache

set -e保证任何一步失败就退出，避免半吊子状态。curl用-fsSL这几个参数，静默模式下失败也会返回非零状态码，方便脚本判断。备份目录带上日期，回头要回滚也知道找哪一天的。

这个脚本我在几批机器上跑过，基本能用。真实的自动化场景里还会加上失败重试、日志落盘、并发控制这些，但骨架就是这么个骨架。

6.3 还能怎么往下扩展

换源只是起步，沿着这条路还能往下走几步。

一是把常用镜像都配齐。pip 用https://mirrors.aliyun.com/pypi/simple/，npm 用https://registry.npmmirror.com，Maven 的settings.xml里把中央仓库换成阿里云地址，Docker 的daemon.json里配registry-mirrors。整套配下来，装依赖的速度会有质的变化，尤其是 Maven 拉 jar 包那种动辄几百 MB 的场景。

二是把源配置纳入配置管理。Ansible 里写个 task，或者用 cloud-init 的write_files模块把 repo 文件直接在机器开机时写进去，新机器起来就是配好的状态，比人工登录改强太多。

三是自建内网镜像。用reposync加createrepo的组合，定期从上游同步需要的仓库到内网，既能保证速度又能控制安全边界。这套东西搭一次，后面几年都省心。

四是把 vault 这件事记在心里。任何依赖官方源路径的配置，遇上发行版 EOL 都可能失效。定期检查一下yum makecache的输出，看看有没有仓库悄悄地报 404 但被其他仓库的正常输出盖住了，这种事发生得比想象中频繁。