手头有台还在跑 CentOS 7.6 的服务器最近发现 yum install 开始一直转圈最后直接给我抛一串Failed to download metadata的报错。看到这个提示我心里的第一反应是该来的还是来了CentOS 7.6 的 yum 源不换已经没法用了。今天把这次 yum 源更换的完整过程记录下来包括踩过的坑、翻过的车以及最终稳定的仓库配置希望能帮到同样还困在 7.6 上的运维朋友。如果你也遇到过 Could not retrieve mirrorlist 或者 404 之类的提示这篇尤其适合你哪怕你只是刚接触 Linux按着步骤做也能把源换过来。1. 为什么突然要换 yum 源CentOS 7.6 已经进入维护终点1.1 先理解 yum 源到底是个什么东西很多人把 yum 源简称为“软件下载地址”但如果只把它理解成一个网址换源时非常容易踩坑。yum 源对应的是一系列仓库配置文件默认存放在/etc/yum.repos.d/目录下文件后缀是.repo。每个.repo文件里至少要定义仓库 ID、仓库名称、下载地址以及 GPG 签名校验开关。yum 在安装、更新软件包时会先读取这些文件去 baseurl 指向的路径下载repodata/repomd.xml再根据这份元数据去拉具体的 RPM 包。所以你会发现很多时候软件包下载失败根本问题其实出在元数据拉不到而不是 RPM 包本身的问题。用个生活化的类比仓库的repomd.xml就像图书馆的检索卡片目录yum 先查目录再按编号去书架取书。换源之后必须执行yum clean all原因也在于本地缓存里还留着旧仓库的目录索引如果不清理yum 大概率会拿着旧索引去新地址找包然后报出一堆莫名其妙的错。1.2 7.6.1810 这个版本号为什么这么特殊CentOS 7 的常见子版本有 7.2、7.4、7.6、7.9其中 7.6.1810 里的 1810 表示该版本构建于 2018 年 10 月。不同子版本之间并不是简单的“新版覆盖旧版”它们的仓库路径在官方仓库体系里也是独立分开的。典型路径是:http://mirror.centos.org/centos/7.6.1810/os/x86_64/CentOS 7 整体生命周期结束后官方把所有历史版本统一挪到了vault.centos.org。原来的mirrorlist.centos.org基本失去维护很多国内镜像节点也不再同步旧版本的内容。更关键的是如果你图省事直接把 7.6 的 yum 源指向通用的 CentOS 7 仓库yum 在解析包依赖时很可能会把大量核心包升级到 7.9 的版本这在生产环境是一个不太容易预料的坑。所以我的建议非常明确换源时一定要把7.6.1810这个子版本号写死不要用通用的$releasever变量。1.3 系统停服之后现场到底长什么样根据我实际遇到的情况CentOS 7 停服之后yum 源失效的表现大概有这几类执行yum makecache时长时间卡住最后报Cannot retrieve repository metadata (repomd.xml)。直接提示Could not retrieve mirrorlist ... connection timed out。用 curl 访问默认源地址得到 404或跳转到 vault 但路径不对。启用了第三方源之后报错信息更乱甚至安装一个vim都会被依赖关系卡住。遇到这些报错别急着重装系统。CentOS 7.6 本身不会因为源失效就立刻崩溃只是无法安装新软件包、无法打补丁而已。把源切换到一个仍然存在的镜像副本大部分功能就能恢复。2. 换源前的准备工作备份、评估与镜像源选型2.1 先备份 /etc/yum.repos.d别等出了事再后悔换源的第一步不是删文件而是备份。我最开始接手一台服务器时看到别人处理这类问题第一动作就是rm -rf /etc/yum.repos.d/这种操作我从来不敢用。原因很简单yum 配置涉及面比想象中广除了 CentOS-Base.repo还可能有epel.repo、mariadb.repo、docker-ce.repo等第三方源直接删除会把这些关联配置也一起端掉后面再想找回非常麻烦。安全操作是新建一个备份目录把全部.repo文件移进去mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/这样就算新配置写坏了我们随时可以恢复现场。注意文件移走之后目录里是空的此时任何 yum 操作都会提示There are no enabled repos这个现象是正常的因为我们已经把所有旧源禁用了。2.2 选哪个镜像源阿里云 Vault、清华 TUNA 还是官方 Vault选源主要考虑三件事可用性、速度、可靠性。CentOS 7 停服之后官方把历史版本放在vault.centos.org直连速度在部分网络环境下并不理想。国内常用的替代方案是阿里云镜像站的centos-vault目录、清华 TUNA 的centos-vault目录以及中科大的镜像目录。阿里云的地址格式是http://mirrors.aliyun.com/centos-vault/7.6.1810/os/$basearch/清华的地址格式是https://mirrors.tuna.tsinghua.edu.cn/centos-vault/7.6.1810/os/$basearch/官方 Vault 的地址格式是http://vault.centos.org/7.6.1810/os/$basearch/我个人的经验是如果服务器在国内且需要稳定下载软件包优先选阿里云或清华如果服务器在海外或者内网有更复杂的防火墙策略官方 Vault 也不差。这里有一个细节$basearch是 yum 的变量会自动替换成x86_64或aarch64不用手动改成具体架构。但7.6.1810尽量写死不要用$releasever因为在 CentOS 7 的仓库变量里$releasever会被替换成7指向通用 7.x 仓库而不是你想要的 7.6.1810。2.3 第三方源也要一并盘点只换 CentOS 官方源往往不够。很多生产服务器上还开着 EPEL、docker-ce、mysql 等第三方源。EPEL 7 在 CentOS 7 停服之后同样进入了归档状态继续沿用老的download.fedoraproject.org/pub/epel/7/$basearch地址可能也会遇到元数据拉取的问题。所以在备份完旧配置之后建议把ls /etc/yum.repos.d/backup/的输出好好看一眼搞清楚自己之前到底启用了哪些源。更换官方源的同时第三方源要么同步换成 archive 地址要么先全部停用、等主源恢复稳定后再按需开。先切主源再处理第三方源这个顺序能让故障面小很多。3. 核心实操把 yum 源完整切到 CentOS 7.6 Vault3.1 确认系统版本和 CPU 架构动手前我习惯先确认三样东西系统版本、release 包版本、CPU 架构。命令行如下cat /etc/redhat-release rpm -q centos-release uname -m正常输出类似CentOS Linux release 7.6.1810 (Core) centos-release-7-6.1810.2.el7.centos.x86_64 x86_64这里确认uname -m的值很重要因为后面配置文件里的$basearch会被自动替换成这个值。如果服务器是 ARM 架构那 URL 对应路径会是aarch64很多从网上复制的 x86_64 配置就会失效。另外rpm -q centos-release能看出系统是不是被改动过如果这个包的信息都查不到说明系统基线本身有问题换源解决不了根本问题。3.2 编写这两个核心配置文件备份完成后我们在/etc/yum.repos.d/下新建一个CentOS-Base.repo。这里以阿里云 Vault 为例配置如下cat /etc/yum.repos.d/CentOS-Base.repo EOF [base] nameCentOS-7.6.1810 - Base - mirrors.aliyun.com baseurlhttp://mirrors.aliyun.com/centos-vault/7.6.1810/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1 [updates] nameCentOS-7.6.1810 - Updates - mirrors.aliyun.com baseurlhttp://mirrors.aliyun.com/centos-vault/7.6.1810/updates/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1 [extras] nameCentOS-7.6.1810 - Extras - mirrors.aliyun.com baseurlhttp://mirrors.aliyun.com/centos-vault/7.6.1810/extras/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1 EOF这里简单解释下每个参数的意义[base]: 仓库 ID全局唯一后面yum repolist显示的就是它。name: 仓库的描述名主要给人看写清晰一点方便排障。baseurl: 核心地址。阿里云 Vault 的路径就是刚才讲过的固定地址格式。gpgcheck1: 开启 RPM 签名校验。不要为了省事关掉签名校验能在一定程度上防止软件包被篡改。gpgkey: 指向本机 GPG 公钥文件。CentOS 7 安装系统后这个 key 默认存在于/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7。如果你使用的是清华 TUNA 或者官方 Vault只需要把baseurl整段替换成对应地址就行其余内容保持不变。3.3 清理缓存、重建元数据并验证配置文件写完之后先做清理再重建缓存yum clean all yum makecacheyum clean all会清空/var/cache/yum下的旧元数据和事务记录。如果不执行这一步yum 可能拿着旧缓存去新 baseurl 拉包多绕很多弯路。yum makecache会重新下载所有已启用仓库的元数据这一步能直观确认新源到底通不通。然后执行yum repolist输出应该能看到类似Loaded plugins: fastestmirror repo id repo name status base CentOS-7.6.1810 - Base - mirrors.aliyun.com 10,072 extras CentOS-7.6.1810 - Extras - mirrors.aliyun.com 422 updates CentOS-7.6.1810 - Updates - mirrors.aliyun.com 1,234status 列的数字表示该仓库当前可用的软件包数量。如果这里都是 0 或直接报错说明配置文件还有问题先不要往下走。3.4 实际安装一个软件包验证元数据能拉下来不代表一切正常最好实际安装一个小体积软件包验证。我习惯装tree或lrzsz体积小、依赖少能快速验证整个链路yum install -y tree如果提示Complete!说明源已经正常工作。此时再用yum update -y前要慎重尤其是在生产环境。换源操作本身只解决“软件源不可用”的问题它不强制你立刻升级系统确认源可用后安装需要的软件包或按计划打补丁都可以。4. 换源常见问题与排查实录4.1 换源后依然报 404 怎么办404 是换源时最常遇到的问题。绝大多数原因是 baseurl 路径不对。用阿里云 Vault 时常见写错的地方有两个一是把7.6.1810写成了7.6二是把centos-vault写成了centos。之前有台机器就是这种情况我怎么看都觉得配置没问题结果 curl 一试立刻露馅。排查步骤很简单把 baseurl 里的$basearch手动替换成x86_64然后用 curl 直接访问curl -I http://mirrors.aliyun.com/centos-vault/7.6.1810/os/x86_64/repodata/repomd.xml正常应该返回200 OK。如果返回404 Not Found说明路径有问题逐个对照配置里的 URL 段必要时到镜像站的网页目录里手动翻一下真实路径。这个方法比反复猜配置高效得多。4.2 GPG 签名校验失败的两种处理方式换源后偶尔会看到这样的报错GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7这个报错的含义是 yum 找不到签名公钥文件。可能原因有两种一是系统被精简过公钥文件确实缺失二是gpgkey路径写错。处理方法也分两种如果/etc/pki/rpm-gpg/下没有任何 CentOS 相关 key可以手动导入官方公钥rpm --import https://www.centos.org/keys/RPM-GPG-KEY-CentOS-7如果公钥文件存在但名字不匹配则把.repo里的gpgkey路径改成实际存在的文件名。这里再次强调不要直接改gpgcheck0关闭校验那相当于把仓库的大门敞开失去了一道重要的安全防线。4.3 元数据下载失败的 SSL/HTTPS 问题使用清华 TUNA 或官方 Vault 的 HTTPS 地址时可能会因为证书问题导致下载失败。最常见的报错是ERROR: cannot verify mirrors.tuna.tsinghua.edu.cns certificate这种问题往往不是源不可用而是服务器时间错误、证书链缺失或系统 CA 证书包太旧。先检查时间date如果时间偏差过大先同步时间再试。如果确认时间没问题可以临时改用该镜像的 HTTP 地址。在内网环境或非关键业务中HTTP 也能接受但在公网环境里我仍然建议优先修复 HTTPS 证书链路而不是长期用明文 HTTP。4.4 EPEL、docker、mysql 等第三方仓库失效怎么办换完主源后最常见的后续问题就是第三方源。以 EPEL 为例如果你继续使用老的epel.repo可能会看到Cannot retrieve metalink for repository: epel. Please verify its path原因是 EPEL 7 在 CentOS 7 停服后也进入了归档状态。建议把 epel 源换成 archive 地址例如阿里云的epel-archive路径http://mirrors.aliyun.com/epel-archive/7/$basearchdocker-ce 和 mysql 源的处理思路类似确认镜像站是否提供对应版本的归档目录如果提供直接替换 baseurl如果不提供建议先禁用该源不要让它阻塞整个 yum 流程。毕竟 yum 在解析仓库时任何一个启用但不可用的 repo 都可能拖慢或中断操作。常见现象可能原因快速处理404 Not Foundbaseurl 路径写错用 curl 验证真实路径GPG key 报错公钥文件缺失或路径错误导入公钥或修正路径元数据下载超时DNS/网络/镜像站问题切换镜像源或改用 HTTP第三方源报错源已归档失效换 archive 地址或暂时禁用5. 换源之后的长期维护与个人体会5.1 Vault 源不再更新安全维护怎么做这里必须说一个可能不太好听的事实CentOS 7 的 Vault 源本质上是“快照仓库”它保留了历史版本但不会再像以前那样持续推送安全更新。所以把源换好只等于让系统能继续装包、能安装缺失的软件不等于让系统重新获得了长期安全维护。对于仍必须运行 CentOS 7.6 的机器我会建议做好三件事严格控制出网策略减少不必要的对外服务暴露。对关键应用尽量容器化把业务和底层操作系统解耦这样底层补丁停更的影响范围更小。在计划内逐步推进操作系统升级或迁移不要等到依赖包彻底无法安装时再被动处理。5.2 批量维护的自动化思路如果手里不止一台 CentOS 7.6而是几十台、上百台建议别一台台手工改。先把新的.repo配置放到配置管理工具里再写一个简单脚本批量执行。最基本的脚本逻辑可以这样备份/etc/yum.repos.d/到backup/。用新模板覆盖CentOS-Base.repo。执行yum clean all yum makecache。检查yum repolist是否正常。这样做的收益很直接所有机器用同一套仓库配置排障时不会被“这台机器改过源、那台没改过”这种差异浪费大量时间。脚本里还应该加一个简单的失败检测比如yum repolist返回非零就直接退出避免坏配置被同步到所有机器。5.3 一些边界情况和个人体会最后再分享几个实际运维中的边角场景。第一种情况服务器不能访问外网。那就要在企业内网搭建本地仓库镜像。方法是找一台可以访问外网的机器用 rsync 同步阿里云或清华的centos-vault/7.6.1810目录再通过内网 Nginx 或 HTTP 服务暴露。这样客户端只需把 baseurl 指向内网地址速度和安全性都更好。第二种情况已经有人把源乱改过yum 配置里塞了一大堆.repo文件。我的做法是先把所有.repo移入backup只添加一个自己确认可用的CentOS-Base.repo等验证通过后再按需逐个恢复第三方源。这能有效隔离“哪个源导致问题”的排查变量。第三种情况服务器上已经积累了大量旧缓存。换源后如果yum clean all执行不彻底偶尔还会看到一些过期的元数据警告。必要时可以手动清空/var/cache/yum目录然后再yum makecache。这是少数可以“手动删缓存”的场景比反复纠结报错信息更直接。就我个人来说换 CentOS 7.6 的 yum 源并不难难的是换完源之后心态也要跟着转换这个系统的确有它自己的生命周期终点。仓库配置改得再顺手也只是延缓了系统老化的速度。趁着源还能访问尽早把业务迁移或重新规划到更合适的运行环境才是这批 CentOS 7 服务器最稳妥的出路。