CentOS 7停更后yum源配置：联网、离线与内网源实战

上周有位做运维的朋友发来一张截图，一台跑了七八年的 CentOS 7 业务机，执行yum install直接甩出一行Could not resolve host: mirrorlist.centos.org。他的第一反应是 DNS 挂了，查了 resolv.conf、ping 了网关、翻了防火墙规则，折腾半小时，结论是网络一点问题都没有。真正的原因跟网络半毛钱关系都没有：CentOS 7 在 2024 年 6 月 30 日正式走完生命周期，官方那套 mirrorlist 接口已经停止服务，而机器里的/etc/yum.repos.d/CentOS-Base.repo还是出厂默认配置，指向的是一批早就下线的地址。这两年从虚拟机模板、OVA 镜像、几年前的装机脚本里拉起来的 CentOS 7，十台里有八台会撞上这个坑——网络通、SSH 通、yum 死活装不了包。

这篇就把 CentOS7 配置 yum 源这件事从头捋一遍。先把官方源为什么失效、失效后哪些地址还能用讲清楚；再按联网单机、完全断网、内网多机这三种真实场景，给出可以直接抄的配置；最后按排查顺序把我这几年踩过的坑排成一张表。虚拟机、物理服务器、离线机柜都用得上，新手照着敲能跑通，老手可以跳过前两节直接看第三、四节的落地细节和第五节的排查链路。

1. 停更之后，CentOS 7 的 yum 源到底变成了什么样

1.1 mirrorlist 退场：那条报错的真正来路

打开一台默认配置的 CentOS 7，看/etc/yum.repos.d/CentOS-Base.repo里的[base]段，你会发现这样的结构：

[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

关键在于mirrorlist那一行是启用的，而baseurl那一行是被注释掉的。yum 的工作逻辑是：只要 mirrorlist 存在，就先去请求这个接口，拿到一份"可用镜像站列表"，再从列表里挑一个下载元数据。现在这个接口不响应了，yum 拿不到列表，就抛出Cannot find a valid baseurl for repo: base/7/x86_64或者更直白的解析失败提示。

这里有两个变量值得说清楚，很多新手会看懵。$releasever来自centos-release这个包提供的版本信息，在 7.9 机器上执行cat /etc/centos-release会看到CentOS Linux release 7.9.2009 (Core)，那么$releasever就是7；$basearch是基础架构，x86_64 机器上就是x86_64。这两个变量拼出来的路径，决定了你后面写 baseurl 时到底该写/7/还是/7.9.2009/。这一个小细节，是后面所有配置能跑通的前提。

1.2 mirror.centos.org、vault.centos.org 和国内镜像站的分工

停更之后，官方做了两件事：一是把mirror.centos.org上 7 的内容整体下架，不再对外同步；二是把历史版本归档到vault.centos.org，归档路径里带完整版本号，比如/7.9.2009/os/x86_64/。归档站的特点是内容冻结、不再更新，但对绝大多数只需要装基础包、编译依赖、运行时的场景来说完全够用。

问题在于vault.centos.org在国内访问速度很一般，几十台机器同时拉元数据会很难受。所以实际生产里更常用的是国内几家镜像站，它们大多保留了对应的归档目录。下面这张表是我实测下来比较稳的几个来源，路径以你实际访问的结果为准，镜像站的目录结构偶尔会调整：

注意这里的写法是/centos-vault/7.9.2009/，而不是老教程里常见的/centos/7/。直接照搬五年前的博客，多半会 404，因为大部分镜像站已经把 7 的在线同步目录撤掉了。

1.3 先判断你属于哪一类场景，再动手

我见过太多人一上来就复制粘贴一份 repo 文件，结果机器根本不能出网，或者装了 EPEL 之后 base 源反而被顶掉。动手之前先花一分钟对号入座：

最后一行是很多人忽略的：CentOS-Base.repo只管 base、updates、extras、centosplus 这几个官方仓库，EPEL、SCL、以及各种第三方仓库都是独立文件，换 base 源的时候完全不用动它们，也不该顺手删掉。

2. 联网机器换源：从备份到验证的完整动作

2.1 动手之前先备份，这一步别省

/etc/yum.repos.d/这个目录里的文件是系统包管理器管着的，改坏了yum本身可能出现诡异行为。我自己的习惯是先做一次带权限属性的完整备份：

mkdir -p /root/repo-bak cp -a /etc/yum.repos.d/*.repo /root/repo-bak/ ls -l /etc/yum.repos.d/

第二条命令要养成习惯。有些环境里除了CentOS-Base.repo，还躺着CentOS-CR.repo、CentOS-Debuginfo.repo、CentOS-Sources.repo、CentOS-Vault.repo等一堆文件，其中CentOS-CR.repo指向的是持续发布仓库，同样会失效并且拖慢yum makecache。这时候更干净的做法是把整个目录清空再写新文件，而不是一个个去改：

mkdir -p /root/repo-bak mv /etc/yum.repos.d/*.repo /root/repo-bak/

出问题的时候mv /root/repo-bak/*.repo /etc/yum.repos.d/就能一键回滚，比手抖删掉再找原始文件省事得多。

2.2 baseurl 与 mirrorlist 的取舍：直接把 mirrorlist 注释掉

新写一个/etc/yum.repos.d/CentOS-Base.repo，内容如下。这是我目前在生产环境用得最多的一版，四个仓库都指向阿里云的归档目录：

[base] name=CentOS-7.9.2009 - Base baseurl=http://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1 [updates] name=CentOS-7.9.2009 - Updates baseurl=http://mirrors.aliyun.com/centos-vault/7.9.2009/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1 [extras] name=CentOS-7.9.2009 - Extras baseurl=http://mirrors.aliyun.com/centos-vault/7.9.2009/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1 [centosplus] name=CentOS-7.9.2009 - Plus baseurl=http://mirrors.aliyun.com/centos-vault/7.9.2009/centosplus/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=0

三个地方值得解释一下。

第一，$basearch保留变量写法，但版本号写死成 7.9.2009。原因是归档目录的层级里，$releasever展开后只有7，而归档站实际路径是/centos-vault/7.9.2009/，变量对不上。写死版本号虽然不够"通用"，但在停更这个语境下反而是最稳的——反正也不会有 7.10 了。如果你手上的机器是 7.6、7.7 这类小版本，也建议统一指到7.9.2009，包版本只会更新不会冲突。

第二，gpgkey用本地文件而不是网络地址。系统自带的/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7就是官方公钥，直接引用它省掉一次网络请求，也避免了镜像站路径变迁导致校验失败。

第三，centosplus我默认设为enabled=0。这个仓库里放的是会替换基础包的非标准增强版本，普通业务用不到，开着反而容易在升级时把系统包换成 plus 版本，后面排查问题会很难受。需要的时候用yum --enablerepo=centosplus临时开一次就行。

2.3 gpgcheck 到底该不该关

网上大量教程第一句就是"把gpgcheck改成0"，理由是能绕过校验错误。我的建议是：联网换源时保持gpgcheck=1，只在完全隔离且已经核对过镜像 SHA256 的实验环境里才允许关掉。

gpgcheck 做的事情很简单：yum 下载完 rpm 包后，用配置里的公钥去验证包的签名，确认这个包确实由发布方签过、中途没被替换。关掉它等于把最后一道完整性防线拆了。真遇到Public key for xxx.rpm is not installed这类报错，正确做法是手动导入公钥，而不是关校验：

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 rpm -qa gpg-pubkey*

第二条命令能列出当前系统里已经导入的所有公钥指纹，确认导入有没有生效。这一步在离线环境里尤其重要，因为离线机器没法在线拉公钥。

2.4 clean all、makecache、repolist 分别在干什么

改完 repo 文件后，标准的三连动作是：

yum clean all yum makecache yum repolist

很多人是照抄，但不知道这三条各自的作用，出问题了就不知道怎么排查。拆开说：

yum clean all清的是/var/cache/yum/$basearch/$releasever/下的两样东西——已经下载的 rpm 包，以及repodata/里的元数据。元数据本质上是几个压缩的 XML 文件（repomd.xml是索引，primary.xml.gz记录包名、依赖、路径），它们带着有效期。你不清理的话，yum 在有效期内会一直用旧的元数据，即使你换了 baseurl，它也未必立刻去新地址拉取。这就是"我明明改对了源，为什么还是报旧地址的错"的经典原因。

yum makecache是主动触发一次元数据下载并缓存下来，相当于预热。它会挨个请求每个启用仓库的repodata/repomd.xml，所以这一步也是最能暴露网络问题的环节——如果 baseurl 写错，这里会第一时间报错。

yum repolist列出当前启用的仓库名、仓库 ID 和包数量。如果某个仓库的包数量显示为 0，说明元数据没拉到或者路径层数写错了，这时候要看yum repolist -v的详细输出，它会打印每个仓库实际使用的 baseurl。

2.5 EPEL 不是 yum 源的一部分，得单独配

CentOS-Base.repo换完之后，你会发现yum install nginx还是找不到包，因为 nginx、redis、fail2ban、certbot 这些都不在 base 仓库里，它们在 EPEL。EPEL 7 同样已经归档，在线安装的方式是：

yum install -y epel-release

如果这台机器上装的epel-release版本还指向上级失效的地址，就需要手工写一份。EPEL 的归档目录在镜像站上一般叫epel-archive，路径形态是https://mirrors.aliyun.com/epel-archive/7/$basearch/。写法和 base 源一样，单独建一个/etc/yum.repos.d/epel.repo即可。配完之后建议用yum --enablerepo=epel list nginx单独验证一下，确认包能被看到，再批量装东西。

这里有个经验：EPEL 的优先级要低于 base。EPEL 里有一些包名和 base 重名但版本更高的版本，如果不做限制，某些情况下会把系统基础库顶掉。第 5.6 节会讲怎么用 priorities 插件控制。

3. 断网环境：把 ISO 挂成本地 yum 源

3.1 ISO 怎么选：DVD 版和 Minimal 版不是一回事

离线做本地源，第一步是挑对镜像文件。CentOS 7 官方发布的镜像有几种规格：

Minimal 版是给快速装机用的，里面根本没有repodata目录，挂上去做源一定失败。做本地源请用 DVD 版。下载完成后建议核对一下校验值，官方会同时发布sha256sum.txt，执行sha256sum CentOS-7-x86_64-DVD-2009.iso对一下，避免因为镜像下载不完整导致后面出现莫名其妙的元数据错误——这种问题排查起来极其耗时，前置校验五分钟就能省掉。

3.2 loop 挂载 ISO 与开机自动挂载

假设 ISO 已经上传到/opt/CentOS-7-x86_64-DVD-2009.iso：

mkdir -p /mnt/cdrom mount -o loop,ro /opt/CentOS-7-x86_64-DVD-2009.iso /mnt/cdrom ls /mnt/cdrom

正常的话ls会看到Packages、repodata、GPL、CentOS_BuildTag这些目录和文件，说明镜像结构是完整的。如果是物理机直接用光驱放光盘，那就换成mount /dev/sr0 /mnt/cdrom。

临时挂载重启就没了，所以要么写进/etc/fstab，要么写进开机脚本。fstab 的写法有个容易踩的坑：ISO 文件路径必须是绝对路径，而且loop选项不能少：

/opt/CentOS-7-x86_64-DVD-2009.iso /mnt/cdrom iso9660 loop,ro 0 0

写完用mount -a验证一次，没有报错才算数。物理光驱的写法是/dev/sr0 /mnt/cdrom iso9660 defaults,ro 0 0。

这里有个我踩过的坑：如果 ISO 文件放在一块后挂载的独立数据盘上，fstab 里两行的先后顺序会影响开机挂载结果。数据盘的挂载条目必须排在 ISO 之前，否则系统启动时 ISO 那行会因为找不到文件而失败。稳妥点的话，可以在 fstab 里给数据盘加上_netdev之外的依赖处理，或者干脆把 ISO 放到根分区。

3.3 本地仓库文件的最小可用配置

挂载好了，写一份最简的 repo 文件。先把其他仓库全部停掉，避免它们干扰：

mkdir -p /root/repo-bak mv /etc/yum.repos.d/*.repo /root/repo-bak/

然后新建/etc/yum.repos.d/local.repo：

[local-dvd] name=CentOS-7.9.2009 - Local DVD baseurl=file:///mnt/cdrom gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1

baseurl用的是file://协议，后面跟挂载点绝对路径，两个斜杠不能少——写成file:/mnt/cdrom有的版本会报协议不识别。gpgcheck=1在这里是可以保留的，因为 ISO 自带签名元数据，本地公钥也在系统里，校验能正常通过。只有在你下载的 ISO 来源不明、或者自己做了一个手工打包的目录时，才考虑关掉。

验证方式和联网环境一样：yum clean all、yum makecache、yum repolist。如果repolist里local-dvd的包数量在几千这个量级，就是正常的。

3.4 本地源三个最常见的报错

第一个是Cannot find a valid baseurl for repo: local-dvd。九成情况是 ISO 没挂上。执行mount | grep cdrom看看有没有挂载记录，ls /mnt/cdrom看看目录是不是空的。如果重启后报这个错，那就是 fstab 没生效。

第二个是Error: Cannot retrieve metalink for repository: epel/x86_64。这说明你的机器上 EPEL 的 repo 文件还在，而且它还开着。本地源不需要 EPEL，把/etc/yum.repos.d/里的非本地 repo 全部搬走就行。

第三个是用了yum remove或者系统自动卸载 ISO 之后，所有 yum 操作都报错。这种情况在容器和某些自动化脚本里比较常见。手动umount /mnt/cdrom再重新mount -o loop一次就能恢复。如果你在写自动化脚本，建议在脚本开头固定加一句挂载检查。

还有一点必须提醒：DVD 镜像里没有 updates 仓库。也就是说，用本地源装出来的包，全都是发布时的基线版本，安全补丁一个都没有。如果业务对补丁有要求，得走第 4 节的 HTTP 源方案，把 updates 目录也补齐。

4. 内网几十台机器：搭一个 HTTP yum 源

4.1 为什么不用 FTP，也不用 NFS 直接共享

yum 支持的协议其实挺多：http、https、ftp、file。很多人第一反应是用 FTP，因为"文件共享"这个词天然联想到 FTP。但实际做下来，HTTP 是内网 yum 源最省事的选择，原因有三个。

FTP 需要额外跑一个 ftpd 服务，还得处理被动模式端口范围，防火墙规则一多就容易出错；而且 yum 在 FTP 上的元数据读取并发性能一般，几十台机器同时makecache的时候很慢。NFS 表面上看是最简单的，目录一导出就完事，但 yum 会在仓库目录里大量随机读小文件，NFS 的元数据操作开销被放大，机器一多就明显卡顿，权限映射和 root squash 也容易出问题。HTTP 就不一样了，nginx 装一个包就有，静态文件读取性能好，还能顺手把内网其他静态资源挂一起用，防火墙只开一个 80 端口。

4.2 目录规划与 nginx 配置要点

假设有一台内网机器10.0.0.10，规划目录如下：

mkdir -p /data/yum/centos7 mount -o loop,ro /opt/CentOS-7-x86_64-DVD-2009.iso /mnt/cdrom cp -a /mnt/cdrom/. /data/yum/centos7/

用cp -a而不是mv，是为了保留原目录结构和软链接。如果磁盘空间紧张，也可以直接把 ISO 挂到/data/yum/centos7，但那样就没法再往里添加 updates 目录了，属于一次性方案。

nginx 配置重点在autoindex，因为维护的时候经常需要直接看目录里有哪些包：

server { listen 80; server_name _; root /data/yum; autoindex on; autoindex_exact_size off; autoindex_localtime on; location / { try_files $uri $uri/ =404; } }

autoindex_exact_size off会把文件大小显示成 MB、GB 而不是字节数，看目录的时候舒服很多。

这里有两个最容易卡住的系统层配置。SELinux：如果机器上 SELinux 是 enforcing 状态，nginx 默认没有权限读/data下的文件，访问会返回 403。处理方式是给目录打上 httpd 相关的标签：

semanage fcontext -a -t httpd_sys_content_t "/data/yum(/.*)?" restorecon -Rv /data/yum

如果semanage命令不存在，先yum install -y policycoreutils-python。另一个是防火墙：

firewall-cmd --permanent --add-service=http firewall-cmd --reload

配置完成后，在服务器本机先用curl -I http://127.0.0.1/centos7/repodata/repomd.xml探一下，能返回 200 再往下走。

4.3 客户端怎么指过来

内网其他机器上的 repo 文件写成这样：

[internal-base] name=CentOS-7.9.2009 - Internal HTTP baseurl=http://10.0.0.10/centos7/ gpgcheck=0 enabled=1

gpgcheck=0在这里是无奈但合理的选择：我们把 DVD 内容复制过来之后，如果后续往里加了自己打包的 rpm，签名就对不上了，元数据校验会失败。内网环境信任边界相对清晰，关掉校验换取灵活性是常见做法。如果你们环境有更严格的合规要求，可以保留gpgcheck=1并对自建包做签名。

有个提高可用性的小技巧：baseurl支持写多行，yum 会按顺序尝试。内网源可以再挂一个备用机器：

baseurl=http://10.0.0.10/centos7/ http://10.0.0.11/centos7/

4.4 补齐 updates 和 extras：createrepo 的用法

DVD 只有os的内容，缺 updates。如果内网有一台能出网的机器，可以把它当"跳板"，把包同步下来再传进去。常用两个工具：reposync负责把远程仓库的包全量拉到本地，createrepo负责在本地目录生成repodata元数据。

yum install -y createrepo mkdir -p /data/yum/centos7-updates # 把下载好的 rpm 全部放进 centos7-updates createrepo -v /data/yum/centos7-updates

createrepo跑完后目录里会多出一个repodata/文件夹，这才是一个能被 yum 识别的仓库。客户端那边再补一个段：

[internal-updates] name=CentOS-7.9.2009 - Internal Updates baseurl=http://10.0.0.10/centos7-updates/ gpgcheck=0 enabled=1

每次往目录里新增或删除 rpm 包之后，都必须重新执行一次createrepo，否则元数据和实际文件对不上，客户端会报repomd.xml找不到某个包的错误。这是自建源最高频的翻车点，建议直接写进发布脚本里。

5. 六类高频故障，按这个顺序排查

5.1 Cannot find a valid baseurl 与域名解析失败

这两类报错看着像，根因完全不同。域名解析失败的典型提示是Could not resolve host: mirrorlist.centos.org，说明 yum 在尝试连接一个域名但解析不了。这时候先cat /etc/resolv.conf看 DNS 配置，再nslookup mirrors.aliyun.com测解析。内网隔离机器上 DNS 往往只指向内网服务器，解析不了外网域名是正常的，说明你该走本地源方案了。

Cannot find a valid baseurl指的是"YAML 文件里给的地址都不对"，跟 DNS 没关系。用yum repolist -v把每个仓库实际用的 baseurl 打出来，逐条curl -I一下，哪条返回 404 就改哪条。这个动作比盲目重装 yum 有效一百倍。

5.2 repodata 校验失败与 GPG key 缺失

repomd.xml相关的报错通常长这样：[Errno 14] HTTP Error 404 - Not Found，或者repomd.xml signature could not be verified。前者说明 baseurl 的路径层级不对，最常见的是把/centos-vault/7.9.2009/os/x86_64/写成了/centos/7/os/x86_64/。后者说明公钥没导入或者不匹配，执行：

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 rpm -qa gpg-pubkey* --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'

如果之前误导入过错误的公钥，可以用rpm -e gpg-pubkey-xxxx删掉再重新导入。

5.3 缓存污染导致的"新源不生效"

这个问题的表现形式非常迷惑：yum repolist显示的是新仓库，包数量也对，但yum install依然从旧地址下载，或者报旧地址连不上。根因是/var/cache/yum/里残留了上一次的元数据。彻底清一遍：

yum clean all rm -rf /var/cache/yum yum makecache

注意yum clean all有时候清不干净，直接rm -rf目录是最彻底的。清完之后第一次makecache会慢一点，属于正常现象。

5.4 时间不同步引发的元数据异常

用https协议的镜像站时，如果服务器时间偏差太大（比如虚拟机从快照恢复后时间停在几个月前），TLS 握手会因为证书有效期判断失败而报错，提示通常是certificate is not yet valid或者SSL certificate problem。先看时间：

date timedatectl status

CentOS 7 上校准时间用 chrony：

yum install -y chrony systemctl enable --now chronyd chronyc sources -v

时间同步是很多人排查 yum 问题时会忽略的一环，但只要用 https 源，它就必须是正常的。

5.5 磁盘空间被 /var/cache/yum 吃掉

yum 会缓存下载过的 rpm 包，长期运行的机器上这个目录能涨到几个 G。如果yum install报No space left on device，先看：

df -h du -sh /var/cache/yum

确认是缓存占满的话，两个处理方向：一是yum clean packages只清包不清元数据；二是修改/etc/yum.conf，把keepcache从默认的0保持住（默认本来就不保留），并定期检查。反过来，如果内网机器网络很差、经常重复装包，可以把keepcache=1打开，让 yum 保留已下载的包，重装时能直接用本地副本。

5.6 多源冲突与优先级控制

同时启用了 base、EPEL、以及自己加的第三方源之后，同一个包可能会出现在多个仓库里，yum 的行为就变得不可预测。控制手段是用 priorities 插件：

yum install -y yum-plugin-priorities

然后在 repo 文件里加一行，数字越小优先级越高：

[base] ... priority=1 [epel] ... priority=10

一般把 base 设为 1，EPEL 设为 10，自建源根据情况放中间。另外，排查单个包到底来自哪个仓库，用：

yum --showduplicates list nginx yum list available --disablerepo=* --enablerepo=epel

前一条列出所有版本和来源仓库，后一条只在指定仓库里搜，定位问题时非常有用。

6. 长期维护上的一些个人经验

配置能跑通只是第一步，真正麻烦的是几个月后系统还稳不稳。我自己的做法是：把 repo 文件纳入版本管理，不管是 Git 还是公司内部的配置管理平台，别让它散落在几十台机器上各写各的。同时用/etc/yum/vars/releasever统一固定版本号，文件里只写一行7.9.2009，这样所有 repo 文件都可以用$releasever变量，将来要调整版本只需要改一个地方。

还有一个习惯我强烈建议保持：每台机器上都留一份能兜底的离线源配置。哪怕平时不用，把 ISO 放在固定目录、repo 文件写好但enabled=0，等哪天公网镜像站出问题或者网络策略收紧，一条yum --enablerepo=local-dvd install xxx就能救急。我遇到过两次外部镜像站长时间不可用的情况，都是靠这份备胎配置把当天的工作撑过去的。

最后提一句做内网源时的验证习惯。每次改完配置，别只看yum repolist，一定跑一次真实安装：yum install -y telnet或者yum install -y lrzsz这种体积小、依赖少的包，能装上再清理掉。元数据能拉到不代表包能下来，包能下来也不代表依赖能解出来，这三层都通过，才算这份 yum 源真的可用。