凌晨一点值班手机响了。业务那边反馈所有新环境初始化失败我登录一台故障机执行yum update日志干净利落地甩出一行红字Could not resolve host: mirrorlist.centos.org。看到这行报错我心里基本有数了这多半不是网络抽风而是 CentOS 7 的 yum 源进了生命周期终止后的“失联区”。CentOS 7 在 2024 年 6 月 30 日停止维护官方维护计划早就公布过。但 CentOS 7 至今仍是存量最大的 Linux 发行版之一大量线上业务、离线机房、老构建机都还在用它。官方源退役后默认请求的mirrorlist.centos.org和mirror.centos.org/centos/7/路径会逐步不可用表现就是 yum install 报错、yum update 失败、依赖解析直接崩溃。更麻烦的是这类报错不只有一种长相有时是 DNS 解析失败有时是 404有时干脆卡在 mirrorlist 测速上。排查不仔细很容易绕弯子。这篇文章把我实际处理这个问题的完整过程写出来包含报错类型辨别、排查顺序、Base 源和 EPEL 源的配置修改、缓存清理以及几个特别容易踩的坑。如果你正被 CentOS 7 的 yum 源问题折磨或者想提前储备这个运维操作场景的处理方案直接照做即可。1. 报错现场CentOS 7 源失效的几种典型长相1.1 最容易遇到的几类报错先说结论CentOS 7 源失效不会只有一种表现形式。我实际处理过的服务器里最常见的是下面这三种。第一种DNS 解析类型Could not retrieve mirrorlist http://mirrorlist.centos.org/?release7archx86_64repoosinfracontainer error was 14: curl#6 - Could not resolve host: mirrorlist.centos.org第二种仓库校验失败类型One of the configured repositories failed (CentOS-7 - Base), and yum will now exit第三种元数据 404 类型http://mirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found这三种表面症状差异很大。第一种看起来像 DNS 没配好第二种像是仓库配置损坏第三种像文件路径写错。但它们的根因是同一件事CentOS 7 进入生命周期终止EOL状态后官方仓库维护重点已经转移到归档目录老仓库不再生成新的repomd.xml部分 URL 直接返回 404部分mirrorlist接口干脆不再对版本 7 返回可用镜像列表。也就是说不是你的网络坏了而是远端真的“没有这个东西了”。1.2 为什么 CentOS 7 的源会集体消失CentOS 7 的完整版本是 7.9.2009这也是该系列最后一个正式版本。任何软件发行版只要停止维护官方通常会把历史仓库从“主下载目录”挪到“归档目录”避免占用主目录的空间也避免用户继续收到已不维护的包。CentOS 项目的归档位置就是vault.centos.org。对 yum 源来说默认情况下 CentOS 7 的 Base、Updates、Extras 三个仓库会去请求mirrorlist.centos.org/?release7archx86_64repoosmirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml一旦官方把主目录里的centos/7/内容移走这两个地址就变成无效状态。镜像列表返回不了可用镜像主目录返回 404yum 自然拉不到任何仓库元数据。需要注意EPEL 源Extra Packages for Enterprise Linux也存在类似问题。EPEL 7 同样停止维护默认的download.fedoraproject.org/pub/epel/7/路径也会失效需要切到归档路径archives.fedoraproject.org/pub/archive/epel/7/。2. 动手前的排查先分清楚是真的源失效还是本地网络故障2.1 三步定位问题改配置之前我建议先花几分钟做一遍快速定位避免把网络问题错怪到源头上。第一步用yum repolist看具体是哪个仓库报错。报错信息里通常写了仓库名比如 CentOS-7 - Base、CentOS-7 - Updates或者 EPEL。记住这个名字后面要定向处理。第二步手动用 curl 测试关键 URL。如果报错里带着 mirrorlist 地址就测 mirrorlist如果带着具体 repodata 路径就测 repodata。curl -I --connect-timeout 5 http://mirrorlist.centos.org/?release7archx86_64repoos curl -I --connect-timeout 5 http://mirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml如果 curl 返回 200 或 302说明网络和域名解析都没问题问题在别的仓库或配置细节。如果 curl 返回 404可以基本确认是远端归档问题。如果 curl 报Could not resolve host先查 DNScat /etc/resolv.conf再用ping或者dig试几个常见域名。如果 curl 超时检查出网防火墙和代理配置。公司内网环境经常有代理限制yum 默认不走代理需要在/etc/yum.conf里显式配置proxy。第三步把/etc/yum.repos.d/目录里的.repo文件全部列出来确认系统里除了默认源之外还有没有第三方源。很多服务器会残留各种第三方软件源它们如果也指向 CentOS 7 时代的老地址一样会报错。2.2 备份配置文件修改任何系统配置文件前备份是底线操作。yum 源配置文件虽然改动量不大但一旦替换出错连恢复现场都很麻烦。mkdir -p /root/yum-repo-backup/$(date %F) cp -r /etc/yum.repos.d/* /root/yum-repo-backup/$(date %F)/如果后续改动出问题直接把这个目录里的文件拷回去就能恢复。另外我习惯顺手记录一下当前系统版本和架构cat /etc/redhat-release uname -mCentOS 7 的最终版本号是 7.9.2009架构一般是x86_64这两个信息在下一步配置里会用到。若服务器是aarch64等 ARM 架构路径中的架构参数要对应替换。3. 核心修复把 yum 源切换到归档源3.1 修改 CentOS-Base.repoCentOS 7 的默认源配置位于/etc/yum.repos.d/CentOS-Base.repo。修复原则其实很简单把失效的mirrorlist和mirror.centos.org地址全部替换成vault.centos.org/7.9.2009/下的对应路径。最稳妥的方式是手工编辑逐段替换。下面是我实际用过的配置片段[base] nameCentOS-$releasever - Base baseurlhttp://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [updates] nameCentOS-$releasever - Updates baseurlhttp://vault.centos.org/7.9.2009/updates/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [extras] nameCentOS-$releasever - Extras baseurlhttp://vault.centos.org/7.9.2009/extras/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7注意这里有三个关键点。第一mirrorlist行必须注释掉或者删除。否则即使你写了正确的baseurlyum 有时仍会去请求 mirrorlist 接口轻则多绕一段请求重则直接报错。第二路径里的7.9.2009是 CentOS 7 的最终版本号。不要写成7。vault.centos.org/7/不一定稳定官方归档目录按完整版本号组织7.9.2009才是准确的归档目录名。第三$basearch变量可以保留yum 会自动替换成x86_64或aarch64。$releasever在 CentOS 7 上通常等于7但我建议直接写死完整版本号减少变量解析带来的不确定性。如果你不想手工编辑也可以用 sed 快速替换。默认的 CentOS-Base.repo 里baseurl是注释状态mirrorlist是启用状态处理方式就是取反再换地址sed -i s|^mirrorlist|#mirrorlist|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|^#baseurl|baseurl|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|http://mirror.centos.org/centos/$releasever|http://vault.centos.org/7.9.2009|g /etc/yum.repos.d/CentOS-Base.repo这套命令在绝大多数默认配置的 CentOS 7 系统上可以直接复用。第三行的目的是把文件里的变量形式地址替换成固定的归档地址注意单引号防止 shell 展开。3.2 处理 EPEL 源EPEL 是 CentOS 7 里最常用的第三方软件源很多额外包都依赖它。如果系统里装了epel-release/etc/yum.repos.d/epel.repo同样需要改。先确认一下rpm -qa | grep epel-release有输出就说明 EPEL 源存在。编辑/etc/yum.repos.d/epel.repo把mirrorlist注释掉baseurl改成归档地址[epel] nameExtra Packages for Enterprise Linux $releasever - $basearch baseurlhttps://archives.fedoraproject.org/pub/archive/epel/7/$basearch enabled1 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7如果你用了 epel-testing同样处理[epel-testing] nameExtra Packages for Enterprise Linux $releasever - Testing - $basearch baseurlhttps://archives.fedoraproject.org/pub/archive/epel/7/testing/$basearch enabled0 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7这里有个特殊情况。如果系统里根本没有安装epel-release却需要使用 EPEL 中的软件包那就先别急着装包。因为老版本的epel-releaserpm 文件自带的仓库配置也会指向失效地址。正确做法是先到 EPEL 归档目录下载与 CentOS 7 匹配的epel-releaserpm然后用rpm -ivh安装装完再按上面的方式修改仓库文件。3.3 清理缓存并验证修复结果源配置改完后第一件事不是直接 yum install而是清理缓存和重建元数据。原因很简单本地/var/cache/yum里可能还残留着旧的仓库元数据它会把 yum 引导到老地址上导致改了半天仍然报错。yum clean all yum makecacheyum clean all会清掉所有仓库的元数据缓存和临时文件。yum makecache会按当前配置文件重新拉取所有启用仓库的repomd.xml这一步如果顺利执行说明源配置已经生效。接下来跑一遍yum repolist确认仓库数量正常yum repolist输出里应该能看到base、updates、extras和epel等仓库状态正常。最后做个实际测试yum -y update这里注意CentOS 7 已经 EOL别指望还能拉到大量更新但命令执行过程不报 404、不报Could not resolve host就说明 yum 源本身已经恢复可用。如果只想装某个软件也可以直接yum -y install package验证。4. 实操中的坑这些情况我全遇到过4.1 DNS 正常但依旧报错元凶可能是 fastestmirror有一次我处理一台服务器curl 测试 mirrorlist 地址完全正常但 yum 就是慢吞吞地报错。排查到最后发现是fastestmirror插件在捣乱。fastestmirror插件会在 yum 执行时自动测试多个镜像的速度优先选择最快的一个。当配置文件里的mirrorlist还指向失效地址时插件会反复做无效请求结果就是长时间等待最终报错或回退失败。解决办法有两个。一是改配置时坚持把mirrorlist注释掉从根上避免插件去请求它。二是直接禁用插件sed -i s/enabled1/enabled0/ /etc/yum/pluginconf.d/fastestmirror.conf或者修改/etc/yum.conf把默认启用插件的开关关掉plugins0我个人的习惯是在 EOL 系统上直接禁用 fastestmirror。反正所有仓库都指向固定归档地址了测速已经没有意义反而多一层故障隐患。4.2 GPG 签名校验报错别急着关 gpgcheck切换到 vault 源后有时会遇到公钥缺失或签名校验失败的报错Public key for xxx.rpm is not installed这种情况多发生在长期未更新的机器上系统缺少 CentOS 7 的 GPG 公钥。不要条件反射式地把gpgcheck1改成gpgcheck0这是把安全底线降级了。正确的是导入对应的公钥文件rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7如果公钥文件本身丢失可以重新安装对应密钥包centos-release或epel-release或者从归档源下载公钥再导入。4.3 clean all 之后 makecache 卡死有台机器执行yum makecache时卡在“determining fastest mirrors”这一步二十分钟没动。这不是网络问题是插件逐个测试镜像站点超时。按 4.1 的方式关掉 fastestmirror 之后makecache 十几秒就完成了。所以如果你用的还是默认配置文件我建议先禁用插件再执行清理缓存。另外还有一种情况仓库配置里baseurl写成了https://但服务器时间不准SSL 握手报证书错误。CentOS 7 的老机器时间同步服务经常失灵如果 makecache 报证书或校验错误先date看下系统时间再用ntpdate或 chrony 同步一遍。4.4 内网离线机连 vault 都访问不了外网可达的机器按第 3 章操作就能修复。但很多内网服务器只开放了特定端口根本访问不到vault.centos.org。这种情况下最实用的方案是做一个本地 yum 源。最简单的做法是用 CentOS 7 的 ISO 镜像做本地源。把 ISO 上传到服务器然后挂载mkdir -p /mnt/cdrom mount -o loop /opt/CentOS-7-x86_64-DVD-2009.iso /mnt/cdrom新建一个本地源配置文件例如/etc/yum.repos.d/local.repo[localiso] nameCentOS 7 Local ISO baseurlfile:///mnt/cdrom/ enabled1 gpgcheck0然后把所有原来失效的源文件移走mkdir -p /etc/yum.repos.d/disabled mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/disabled/ mv /etc/yum.repos.d/epel*.repo /etc/yum.repos.d/disabled/最后执行yum clean all yum makecache。ISO 源虽然软件包版本是固定的但作为应急安装基础依赖已经完全够用。需要注意gpgcheck0只适合这种离线临时环境不要用到生产环境常规源上。如果内网有专门的软件仓库服务器那就用一台有外网的机器通过reposync把归档仓库同步下来再用createrepo生成元数据。注意reposync和createrepo分别属于yum-utils和createrepo包在源失效前就要提前安装准备。4.5 容器里跑的 CentOS 7 同样要改Docker 容器里使用 CentOS 7 镜像源失效问题一样会爆。我曾经遇到一个构建环境容器内执行 yum install 时报同样错误。由于容器镜像大多是精简版可能没有 vim 和 curl直接用 sed 处理更省事sed -i s|^mirrorlist|#mirrorlist|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|^#baseurl|baseurl|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|http://mirror.centos.org/centos/$releasever|http://vault.centos.org/7.9.2009|g /etc/yum.repos.d/CentOS-Base.repo yum clean all yum makecache如果容器里连 sed 都没有那就换基础镜像吧这个系统太精简了后面维护也会很痛苦。5. 源修复只是应急CentOS 7 之后的长期打算5.1 修复完源系统依然处于“裸奔”状态yum 源修复可以让系统继续安装软件、继续做依赖解析但这里必须把话说清楚 CentOS 7 已经停止维护后续不会再有任何官方安全更新。修复源只是让这台机器“能继续工作”并不代表它“安全”。线上业务如果还跑在 CentOS 7 上等于一直暴露在没有安全补丁的状态下。我的处理原则是能用修复方案稳住现有环境但同时在项目计划里给迁移安排一个明确的优先级。迁移的时间窗口越长后续面临的风险就越高。至少需要梳理清楚下面几件事当前所有运行在 CentOS 7 上的服务清单和依赖关系各业务的数据备份方案和备份验证结果配置文件的版本管理尽量把手工改动的配置收进代码仓库可回滚的迁移方案比如提前准备系统镜像快照或整机备份5.2 三条迁移路线的取舍参考从实际运维角度看CentOS 7 迁移主要有三种方向。我用表格简单列一下对比迁移方向RHEL 兼容性迁移成本维护周期适合场景CentOS Stream 8/9与 RHEL 同源属于滚动发布的中间版本中等yum 源和软件版本差异小按 Stream 版本独立节奏维护想继续留在 CentOS 生态且能接受滚动更新模式AlmaLinux / Rocky Linux面向 RHEL 兼容重建社区维护稳定中等可直接在 CentOS 7 上做系统迁移工具升级跟随 RHEL 生命周期通常 8 到 10 年生产环境做平滑迁移需要可靠长期维护Debian / Ubuntu LTS不兼容 RHEL 体系软件包格式不同较高应用需要重新编译部署按各发行版 LTS 周期维护借机做架构升级愿意接受更大的改动量如果你只是想把现有业务尽快稳定住我建议优先考虑 RHEL 兼容路线迁移过程中业务系统的改动量最小。如果本身运维团队对 Debian 系更熟而且应用没有强依赖 RHEL 的某些特性第三条路线也不差。不要因为“换系统”听起来成本高就一直拖着拖到官方源彻底不可用的时候连应急修复的机会都会越来越少。5.3 建议做一个源健康监控CentOS 7 源已经处于“半只脚入土”的状态它什么时候再次出现故障完全不可预测。与其被动等业务反馈不如主动监控。我在处理完源问题后给相关服务器加了一个简单的巡检脚本#!/bin/bash REPO_URLhttp://vault.centos.org/7.9.2009/os/x86_64/repodata/repomd.xml if ! curl -sI --connect-timeout 5 $REPO_URL | grep -qE 200|301|302; then echo $(date %F %T) CentOS 7 yum repo check failed: $REPO_URL /var/log/yum-repo-check.log fi放到 crontab 里每天跑一次crontab -e 0 6 * * * /opt/scripts/check-centos7-repo.sh有告警可以直接发给值班群。这个脚本成本很低但能避免下次源出问题时全业务一起踩雷。5.4 一点个人经验CentOS 7 源失效这个问题我在不同环境里处理过很多次最深的体会是不要急着背命令先把报错拆开看。是 DNS 解析失败还是 404是单个仓库挂掉还是所有仓库挂掉这决定了完全不同的处理路径。repomd.xml拉取失败和包安装失败是两回事混在一起排查会浪费大量时间。另外一点很实用修改源配置时尽量做到“最小变更”。只注释该注释的mirrorlist只替换该替换的 baseurl不要把仓库文件里的其他参数顺手改掉否则排查时你又多了一堆变量。每次改完都执行一次yum clean all yum makecache做验证别让旧缓存掩盖问题。最后再分享一个小技巧。处理这类问题时我会先把/etc/yum.repos.d/里所有.repo文件全部拉出来看一眼。很多 CentOS 7 服务器不止配置了官方源和 EPEL还残留了各种第三方源和内部私有源。它们虽然平时不显眼但在主源失效的同一个时间点往往也会一起出问题。把整个目录里的仓库状态都过一遍再针对性修复远比盯着某一条报错要高效得多。 CentOS 7 yum源失效怎么办？切换vault归档源最全修复指南
凌晨一点值班手机响了。业务那边反馈所有新环境初始化失败我登录一台故障机执行yum update日志干净利落地甩出一行红字Could not resolve host: mirrorlist.centos.org。看到这行报错我心里基本有数了这多半不是网络抽风而是 CentOS 7 的 yum 源进了生命周期终止后的“失联区”。CentOS 7 在 2024 年 6 月 30 日停止维护官方维护计划早就公布过。但 CentOS 7 至今仍是存量最大的 Linux 发行版之一大量线上业务、离线机房、老构建机都还在用它。官方源退役后默认请求的mirrorlist.centos.org和mirror.centos.org/centos/7/路径会逐步不可用表现就是 yum install 报错、yum update 失败、依赖解析直接崩溃。更麻烦的是这类报错不只有一种长相有时是 DNS 解析失败有时是 404有时干脆卡在 mirrorlist 测速上。排查不仔细很容易绕弯子。这篇文章把我实际处理这个问题的完整过程写出来包含报错类型辨别、排查顺序、Base 源和 EPEL 源的配置修改、缓存清理以及几个特别容易踩的坑。如果你正被 CentOS 7 的 yum 源问题折磨或者想提前储备这个运维操作场景的处理方案直接照做即可。1. 报错现场CentOS 7 源失效的几种典型长相1.1 最容易遇到的几类报错先说结论CentOS 7 源失效不会只有一种表现形式。我实际处理过的服务器里最常见的是下面这三种。第一种DNS 解析类型Could not retrieve mirrorlist http://mirrorlist.centos.org/?release7archx86_64repoosinfracontainer error was 14: curl#6 - Could not resolve host: mirrorlist.centos.org第二种仓库校验失败类型One of the configured repositories failed (CentOS-7 - Base), and yum will now exit第三种元数据 404 类型http://mirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found这三种表面症状差异很大。第一种看起来像 DNS 没配好第二种像是仓库配置损坏第三种像文件路径写错。但它们的根因是同一件事CentOS 7 进入生命周期终止EOL状态后官方仓库维护重点已经转移到归档目录老仓库不再生成新的repomd.xml部分 URL 直接返回 404部分mirrorlist接口干脆不再对版本 7 返回可用镜像列表。也就是说不是你的网络坏了而是远端真的“没有这个东西了”。1.2 为什么 CentOS 7 的源会集体消失CentOS 7 的完整版本是 7.9.2009这也是该系列最后一个正式版本。任何软件发行版只要停止维护官方通常会把历史仓库从“主下载目录”挪到“归档目录”避免占用主目录的空间也避免用户继续收到已不维护的包。CentOS 项目的归档位置就是vault.centos.org。对 yum 源来说默认情况下 CentOS 7 的 Base、Updates、Extras 三个仓库会去请求mirrorlist.centos.org/?release7archx86_64repoosmirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml一旦官方把主目录里的centos/7/内容移走这两个地址就变成无效状态。镜像列表返回不了可用镜像主目录返回 404yum 自然拉不到任何仓库元数据。需要注意EPEL 源Extra Packages for Enterprise Linux也存在类似问题。EPEL 7 同样停止维护默认的download.fedoraproject.org/pub/epel/7/路径也会失效需要切到归档路径archives.fedoraproject.org/pub/archive/epel/7/。2. 动手前的排查先分清楚是真的源失效还是本地网络故障2.1 三步定位问题改配置之前我建议先花几分钟做一遍快速定位避免把网络问题错怪到源头上。第一步用yum repolist看具体是哪个仓库报错。报错信息里通常写了仓库名比如 CentOS-7 - Base、CentOS-7 - Updates或者 EPEL。记住这个名字后面要定向处理。第二步手动用 curl 测试关键 URL。如果报错里带着 mirrorlist 地址就测 mirrorlist如果带着具体 repodata 路径就测 repodata。curl -I --connect-timeout 5 http://mirrorlist.centos.org/?release7archx86_64repoos curl -I --connect-timeout 5 http://mirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml如果 curl 返回 200 或 302说明网络和域名解析都没问题问题在别的仓库或配置细节。如果 curl 返回 404可以基本确认是远端归档问题。如果 curl 报Could not resolve host先查 DNScat /etc/resolv.conf再用ping或者dig试几个常见域名。如果 curl 超时检查出网防火墙和代理配置。公司内网环境经常有代理限制yum 默认不走代理需要在/etc/yum.conf里显式配置proxy。第三步把/etc/yum.repos.d/目录里的.repo文件全部列出来确认系统里除了默认源之外还有没有第三方源。很多服务器会残留各种第三方软件源它们如果也指向 CentOS 7 时代的老地址一样会报错。2.2 备份配置文件修改任何系统配置文件前备份是底线操作。yum 源配置文件虽然改动量不大但一旦替换出错连恢复现场都很麻烦。mkdir -p /root/yum-repo-backup/$(date %F) cp -r /etc/yum.repos.d/* /root/yum-repo-backup/$(date %F)/如果后续改动出问题直接把这个目录里的文件拷回去就能恢复。另外我习惯顺手记录一下当前系统版本和架构cat /etc/redhat-release uname -mCentOS 7 的最终版本号是 7.9.2009架构一般是x86_64这两个信息在下一步配置里会用到。若服务器是aarch64等 ARM 架构路径中的架构参数要对应替换。3. 核心修复把 yum 源切换到归档源3.1 修改 CentOS-Base.repoCentOS 7 的默认源配置位于/etc/yum.repos.d/CentOS-Base.repo。修复原则其实很简单把失效的mirrorlist和mirror.centos.org地址全部替换成vault.centos.org/7.9.2009/下的对应路径。最稳妥的方式是手工编辑逐段替换。下面是我实际用过的配置片段[base] nameCentOS-$releasever - Base baseurlhttp://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [updates] nameCentOS-$releasever - Updates baseurlhttp://vault.centos.org/7.9.2009/updates/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [extras] nameCentOS-$releasever - Extras baseurlhttp://vault.centos.org/7.9.2009/extras/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7注意这里有三个关键点。第一mirrorlist行必须注释掉或者删除。否则即使你写了正确的baseurlyum 有时仍会去请求 mirrorlist 接口轻则多绕一段请求重则直接报错。第二路径里的7.9.2009是 CentOS 7 的最终版本号。不要写成7。vault.centos.org/7/不一定稳定官方归档目录按完整版本号组织7.9.2009才是准确的归档目录名。第三$basearch变量可以保留yum 会自动替换成x86_64或aarch64。$releasever在 CentOS 7 上通常等于7但我建议直接写死完整版本号减少变量解析带来的不确定性。如果你不想手工编辑也可以用 sed 快速替换。默认的 CentOS-Base.repo 里baseurl是注释状态mirrorlist是启用状态处理方式就是取反再换地址sed -i s|^mirrorlist|#mirrorlist|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|^#baseurl|baseurl|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|http://mirror.centos.org/centos/$releasever|http://vault.centos.org/7.9.2009|g /etc/yum.repos.d/CentOS-Base.repo这套命令在绝大多数默认配置的 CentOS 7 系统上可以直接复用。第三行的目的是把文件里的变量形式地址替换成固定的归档地址注意单引号防止 shell 展开。3.2 处理 EPEL 源EPEL 是 CentOS 7 里最常用的第三方软件源很多额外包都依赖它。如果系统里装了epel-release/etc/yum.repos.d/epel.repo同样需要改。先确认一下rpm -qa | grep epel-release有输出就说明 EPEL 源存在。编辑/etc/yum.repos.d/epel.repo把mirrorlist注释掉baseurl改成归档地址[epel] nameExtra Packages for Enterprise Linux $releasever - $basearch baseurlhttps://archives.fedoraproject.org/pub/archive/epel/7/$basearch enabled1 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7如果你用了 epel-testing同样处理[epel-testing] nameExtra Packages for Enterprise Linux $releasever - Testing - $basearch baseurlhttps://archives.fedoraproject.org/pub/archive/epel/7/testing/$basearch enabled0 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7这里有个特殊情况。如果系统里根本没有安装epel-release却需要使用 EPEL 中的软件包那就先别急着装包。因为老版本的epel-releaserpm 文件自带的仓库配置也会指向失效地址。正确做法是先到 EPEL 归档目录下载与 CentOS 7 匹配的epel-releaserpm然后用rpm -ivh安装装完再按上面的方式修改仓库文件。3.3 清理缓存并验证修复结果源配置改完后第一件事不是直接 yum install而是清理缓存和重建元数据。原因很简单本地/var/cache/yum里可能还残留着旧的仓库元数据它会把 yum 引导到老地址上导致改了半天仍然报错。yum clean all yum makecacheyum clean all会清掉所有仓库的元数据缓存和临时文件。yum makecache会按当前配置文件重新拉取所有启用仓库的repomd.xml这一步如果顺利执行说明源配置已经生效。接下来跑一遍yum repolist确认仓库数量正常yum repolist输出里应该能看到base、updates、extras和epel等仓库状态正常。最后做个实际测试yum -y update这里注意CentOS 7 已经 EOL别指望还能拉到大量更新但命令执行过程不报 404、不报Could not resolve host就说明 yum 源本身已经恢复可用。如果只想装某个软件也可以直接yum -y install package验证。4. 实操中的坑这些情况我全遇到过4.1 DNS 正常但依旧报错元凶可能是 fastestmirror有一次我处理一台服务器curl 测试 mirrorlist 地址完全正常但 yum 就是慢吞吞地报错。排查到最后发现是fastestmirror插件在捣乱。fastestmirror插件会在 yum 执行时自动测试多个镜像的速度优先选择最快的一个。当配置文件里的mirrorlist还指向失效地址时插件会反复做无效请求结果就是长时间等待最终报错或回退失败。解决办法有两个。一是改配置时坚持把mirrorlist注释掉从根上避免插件去请求它。二是直接禁用插件sed -i s/enabled1/enabled0/ /etc/yum/pluginconf.d/fastestmirror.conf或者修改/etc/yum.conf把默认启用插件的开关关掉plugins0我个人的习惯是在 EOL 系统上直接禁用 fastestmirror。反正所有仓库都指向固定归档地址了测速已经没有意义反而多一层故障隐患。4.2 GPG 签名校验报错别急着关 gpgcheck切换到 vault 源后有时会遇到公钥缺失或签名校验失败的报错Public key for xxx.rpm is not installed这种情况多发生在长期未更新的机器上系统缺少 CentOS 7 的 GPG 公钥。不要条件反射式地把gpgcheck1改成gpgcheck0这是把安全底线降级了。正确的是导入对应的公钥文件rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7如果公钥文件本身丢失可以重新安装对应密钥包centos-release或epel-release或者从归档源下载公钥再导入。4.3 clean all 之后 makecache 卡死有台机器执行yum makecache时卡在“determining fastest mirrors”这一步二十分钟没动。这不是网络问题是插件逐个测试镜像站点超时。按 4.1 的方式关掉 fastestmirror 之后makecache 十几秒就完成了。所以如果你用的还是默认配置文件我建议先禁用插件再执行清理缓存。另外还有一种情况仓库配置里baseurl写成了https://但服务器时间不准SSL 握手报证书错误。CentOS 7 的老机器时间同步服务经常失灵如果 makecache 报证书或校验错误先date看下系统时间再用ntpdate或 chrony 同步一遍。4.4 内网离线机连 vault 都访问不了外网可达的机器按第 3 章操作就能修复。但很多内网服务器只开放了特定端口根本访问不到vault.centos.org。这种情况下最实用的方案是做一个本地 yum 源。最简单的做法是用 CentOS 7 的 ISO 镜像做本地源。把 ISO 上传到服务器然后挂载mkdir -p /mnt/cdrom mount -o loop /opt/CentOS-7-x86_64-DVD-2009.iso /mnt/cdrom新建一个本地源配置文件例如/etc/yum.repos.d/local.repo[localiso] nameCentOS 7 Local ISO baseurlfile:///mnt/cdrom/ enabled1 gpgcheck0然后把所有原来失效的源文件移走mkdir -p /etc/yum.repos.d/disabled mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/disabled/ mv /etc/yum.repos.d/epel*.repo /etc/yum.repos.d/disabled/最后执行yum clean all yum makecache。ISO 源虽然软件包版本是固定的但作为应急安装基础依赖已经完全够用。需要注意gpgcheck0只适合这种离线临时环境不要用到生产环境常规源上。如果内网有专门的软件仓库服务器那就用一台有外网的机器通过reposync把归档仓库同步下来再用createrepo生成元数据。注意reposync和createrepo分别属于yum-utils和createrepo包在源失效前就要提前安装准备。4.5 容器里跑的 CentOS 7 同样要改Docker 容器里使用 CentOS 7 镜像源失效问题一样会爆。我曾经遇到一个构建环境容器内执行 yum install 时报同样错误。由于容器镜像大多是精简版可能没有 vim 和 curl直接用 sed 处理更省事sed -i s|^mirrorlist|#mirrorlist|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|^#baseurl|baseurl|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|http://mirror.centos.org/centos/$releasever|http://vault.centos.org/7.9.2009|g /etc/yum.repos.d/CentOS-Base.repo yum clean all yum makecache如果容器里连 sed 都没有那就换基础镜像吧这个系统太精简了后面维护也会很痛苦。5. 源修复只是应急CentOS 7 之后的长期打算5.1 修复完源系统依然处于“裸奔”状态yum 源修复可以让系统继续安装软件、继续做依赖解析但这里必须把话说清楚 CentOS 7 已经停止维护后续不会再有任何官方安全更新。修复源只是让这台机器“能继续工作”并不代表它“安全”。线上业务如果还跑在 CentOS 7 上等于一直暴露在没有安全补丁的状态下。我的处理原则是能用修复方案稳住现有环境但同时在项目计划里给迁移安排一个明确的优先级。迁移的时间窗口越长后续面临的风险就越高。至少需要梳理清楚下面几件事当前所有运行在 CentOS 7 上的服务清单和依赖关系各业务的数据备份方案和备份验证结果配置文件的版本管理尽量把手工改动的配置收进代码仓库可回滚的迁移方案比如提前准备系统镜像快照或整机备份5.2 三条迁移路线的取舍参考从实际运维角度看CentOS 7 迁移主要有三种方向。我用表格简单列一下对比迁移方向RHEL 兼容性迁移成本维护周期适合场景CentOS Stream 8/9与 RHEL 同源属于滚动发布的中间版本中等yum 源和软件版本差异小按 Stream 版本独立节奏维护想继续留在 CentOS 生态且能接受滚动更新模式AlmaLinux / Rocky Linux面向 RHEL 兼容重建社区维护稳定中等可直接在 CentOS 7 上做系统迁移工具升级跟随 RHEL 生命周期通常 8 到 10 年生产环境做平滑迁移需要可靠长期维护Debian / Ubuntu LTS不兼容 RHEL 体系软件包格式不同较高应用需要重新编译部署按各发行版 LTS 周期维护借机做架构升级愿意接受更大的改动量如果你只是想把现有业务尽快稳定住我建议优先考虑 RHEL 兼容路线迁移过程中业务系统的改动量最小。如果本身运维团队对 Debian 系更熟而且应用没有强依赖 RHEL 的某些特性第三条路线也不差。不要因为“换系统”听起来成本高就一直拖着拖到官方源彻底不可用的时候连应急修复的机会都会越来越少。5.3 建议做一个源健康监控CentOS 7 源已经处于“半只脚入土”的状态它什么时候再次出现故障完全不可预测。与其被动等业务反馈不如主动监控。我在处理完源问题后给相关服务器加了一个简单的巡检脚本#!/bin/bash REPO_URLhttp://vault.centos.org/7.9.2009/os/x86_64/repodata/repomd.xml if ! curl -sI --connect-timeout 5 $REPO_URL | grep -qE 200|301|302; then echo $(date %F %T) CentOS 7 yum repo check failed: $REPO_URL /var/log/yum-repo-check.log fi放到 crontab 里每天跑一次crontab -e 0 6 * * * /opt/scripts/check-centos7-repo.sh有告警可以直接发给值班群。这个脚本成本很低但能避免下次源出问题时全业务一起踩雷。5.4 一点个人经验CentOS 7 源失效这个问题我在不同环境里处理过很多次最深的体会是不要急着背命令先把报错拆开看。是 DNS 解析失败还是 404是单个仓库挂掉还是所有仓库挂掉这决定了完全不同的处理路径。repomd.xml拉取失败和包安装失败是两回事混在一起排查会浪费大量时间。另外一点很实用修改源配置时尽量做到“最小变更”。只注释该注释的mirrorlist只替换该替换的 baseurl不要把仓库文件里的其他参数顺手改掉否则排查时你又多了一堆变量。每次改完都执行一次yum clean all yum makecache做验证别让旧缓存掩盖问题。最后再分享一个小技巧。处理这类问题时我会先把/etc/yum.repos.d/里所有.repo文件全部拉出来看一眼。很多 CentOS 7 服务器不止配置了官方源和 EPEL还残留了各种第三方源和内部私有源。它们虽然平时不显眼但在主源失效的同一个时间点往往也会一起出问题。把整个目录里的仓库状态都过一遍再针对性修复远比盯着某一条报错要高效得多。