CentOS 7 在 2024 年 6 月 30 日正式停止维护了,这意味着 CentOS 官方仓库里的所有软件包都停止更新,而且官方源从 2024 年 8 月开始陆续迁移到 vault.centos.org 归档站点。很多还在生产环境里跑着 CentOS 7 的朋友,某天突然执行yum update发现提示 404,或者下载软件包直接失败,才意识到需要马上处理 yum 源的问题。
这篇文章就来完整梳理 CentOS 7 更换 yum 源的整套流程:为什么要换、怎么选源、替换的完整步骤、常见报错怎么排查、以及几个平时没人提醒的坑。不管你是刚接触 Linux 的新手,还是被 EOL 折腾到想骂人的老运维,照着下面的思路操作,基本都能把源的问题一次性解决。
1. 先把原理搞清楚:yum 源到底是什么
1.1 yum 的工作机制
yum(全称 Yellowdog Updater Modified)是 CentOS 7 默认的软件包管理器。它的核心工作机制说简单也简单:你执行yum install或者yum update的时候,yum 会读取本地配置的仓库地址(也就是 yum 源),去远程服务器上获取软件包的元数据(包括包名、版本号、依赖关系等),然后根据这些元数据计算出需要安装哪些软件包以及依赖包,最后依次下载并安装。
yum 源配置文件放在/etc/yum.repos.d/目录下,文件后缀必须是.repo。系统启动时会读取这个目录下所有.repo文件,把它们合并成一个可用仓库列表。所以更换 yum 源,本质就是修改这些.repo文件里的地址。
1.2 为什么 CentOS 7 必须换源
CentOS 7 停止维护(EOL)之后,官方仓库发生了这些变化:
- 官方源停止更新:
mirror.centos.org上的 CentOS 7 仓库不再推送任何新软件包,安全漏洞也不再修补。 - 仓库内容被迁移并删除:旧仓库地址会先重定向到
vault.centos.org,但 vault 站点上的历史版本也只保留一段时间。到 2024 年 8 月之后,大量旧地址直接返回 404。 - epel 源同样受影响:EPEL(Extra Packages for Enterprise Linux)仓库虽然还在维护,但它的基础依赖会引用 CentOS 官方源,官方源不可用之后,EPEL 源在中国大陆的网络环境中同样大面积失效。
也就是说,不换源的话,你面临的问题不只是“装不了新软件”,还包括“已有的 yum 操作全部报错”“系统无法通过 yum 安装任何依赖包”。对于生产环境来说,这就是必须马上解决的故障。
提示:如果你的 CentOS 7 系统已经完全不打算通过 yum 安装软件,只跑现有服务,理论上也可以不换源。但只要你某天想装一个补丁包、装个 Nginx 或者 PHP 扩展,yum 源就是绕不过去的坎。
1.3 换源前必须了解的兼容性
CentOS 7 的软件包目录结构和发行版本对应关系是固定的,不同的镜像源只是文件存储位置不同,软件包内容是完全一致的(都是 CentOS 官方编译好的 RPM)。所以换源不存在“兼容性问题”,你只需要保证两件事:
.repo文件中写的 baseurl 地址里的系统版本号(7和7.9.2009)和你的系统匹配。- 仓库地址实际存在,不是空目录或者已经 404。
这也是很多一键换源脚本的原理:它做的事情无非是下载一套新的.repo文件,再把原来的Base.repo、Extras.repo、Updates.repo等文件清理掉或改为只读备份。
2. 换源前准备:备份、确认、排查
2.1 系统版本确认
很多人在换源时忽略了一个细节:先搞清楚自己的 CentOS 7 具体是哪个小版本。虽然大版本都是 7,但 7.2、7.9 的软件包会有细微差异,仓库路径也可能不同。
执行以下命令确认:
cat /etc/redhat-release uname -a输出类似CentOS Linux release 7.9.2009 (Core)就是正常的。绝大多数换源脚本都会根据这个来判断仓库路径是否正确。
另外要确认系统架构:
arch一般是x86_64。如果你用的是 ARM 架构的服务器(比如鲲鹏、飞腾),那么 baseurl 里对应的系统架构也应该写aarch64,而不是x86_64。这一点在我接触过的换源教程里几乎都没提,但实际踩坑的人非常多。
2.2 检查现有 yum 配置
在动手改配置之前,先看一眼当前系统的 yum 源状态:
yum repolist如果显示repolist: 0,说明没有任何可用仓库,这是最典型的情况。如果报错Cannot find a valid baseurl for repo: base/7/x86_64,说明仓库地址已经失效,返回 404。
2.3 网络连通性排查
这里要专门提一个热搜词里出现的场景:“centos7 无法 ping 通百度”。很多朋友一看这句描述就直接下结论说网络不通,然后去折腾网卡,其实多数组网环境下 ping 不通和 yum 源不可用是两回事。
- ping 不通公网域名:先确认 DNS 配置是否正确,
cat /etc/resolv.conf里有没有可用的 nameserver。 - ping 不通 IP:用
ping 223.5.5.5(阿里 DNS)或ping 114.114.114.114测试。如果 IP 能通、域名不通,那就是 DNS 的问题。 - yum 源 404 但网络通:这种情况属于官方源迁移后地址失效,直接换源即可,不用去排查网卡。
2.4 备份现有配置
换源之前务必备份原来的.repo文件,这不是做样子,而是真正的保险措施。万一新源出了问题,你可以快速恢复原状。
mkdir -p /etc/yum.repos.d/backup cp -a /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/或者更简单一些,直接移动:
mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/注意我选择了mv而不是cp,因为替换源的时候最好让目录下只保留一套新的.repo文件,否则多个仓库文件里如果有互相冲突的配置,会导致后面排查起来非常痛苦。
3. 主流镜像源的选择与替换实操
3.1 三个主流源怎么选
CentOS 7 在国内比较常用的镜像源有三个:阿里云、清华 TUNA、中科大 USTC。另外网易 163 也有,但实际用下来更新频率和稳定性略逊一筹,所以我不太推荐。
| 镜像源 | 地址 | 优势 | 适合场景 |
|---|---|---|---|
| 阿里云 | mirrors.aliyun.com | 国内访问速度好,阿里云 ECS 用户推荐 | 一般服务器、云主机 |
| 清华 TUNA | mirrors.tuna.tsinghua.edu.cn | 高校背景,同步及时,稳定性好 | 教育网、科研环境 |
| 中科大 USTC | mirrors.ustc.edu.cn | 内容全,含 EPEL、SCL 等扩展仓库 | 需要第三方源较多的环境 |
选源的时候注意一点:不要反复换来回比速度,选一个能用、速度快、稳定的就行。因为换源的过程本质是把.repo文件里的地址改掉,换来换去反而容易搞乱。
3.2 阿里云源替换完整步骤
我把替换过程写成一步一步可以直接执行的命令。
第一步,先备份原有 repo:
mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/第二步,下载阿里云的 CentOS 7 repo 文件:
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo如果curl命令报错,可以先安装(这里需要临时用到系统自带的源,不一定可用),也可以用wget。如果 wget 和 curl 都没有,可以手动用 vim 创建文件,把下面内容写进去:
[base] name=CentOS-$releasever - Base - aliyun baseurl=http://mirrors.aliyun.com/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7 [updates] name=CentOS-$releasever - Updates - aliyun baseurl=http://mirrors.aliyun.com/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7 [extras] name=CentOS-$releasever - Extras - aliyun baseurl=http://mirrors.aliyun.com/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7这里你可能会问,为什么 baseurl 里用的是$releasever和$basearch这种变量,而不是直接写7和x86_64?因为 yum 在读取配置时会自动把$releasever替换成系统的 release 版本号(从/etc/redhat-release读取),把$basearch替换成系统架构。这样一份配置文件可以同时适配多种环境,这也是官方源默认的写法。
第三步,清理缓存并重新生成:
yum clean all yum makecacheyum clean all会清空/var/cache/yum下的缓存文件。这一步必须做。因为旧的缓存里存的是失效仓库的数据,不清理的话,即使换了新源,yum 可能还是去读旧缓存,导致报错。
第四步,验证:
yum repolist正常输出会显示 base、updates、extras 三个仓库,数量几百到几千不等。只要能列出仓库数量就说明换源成功。
3.3 清华源替换完整步骤
清华源的 CentOS 7 repo 文件可以这样获取:
mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.tuna.tsinghua.edu.cn/help/centos/不过清华源的帮助页返回的是一个 HTML 页面而不是直接的 repo 文件,直接用 curl 存下来会有问题。稳妥的做法是手动创建:
vim /etc/yum.repos.d/CentOS-Base.repo写入以下内容:
[base] name=CentOS-$releasever - Base baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=https://mirrors.tuna.tsinghua.edu.cn/centos/RPM-GPG-KEY-CentOS-7 [updates] name=CentOS-$releasever - Updates baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=https://mirrors.tuna.tsinghua.edu.cn/centos/RPM-GPG-KEY-CentOS-7 [extras] name=CentOS-$releasever - Extras baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=https://mirrors.tuna.tsinghua.edu.cn/centos/RPM-GPG-KEY-CentOS-7然后同样执行yum clean all && yum makecache。
3.4 中科大源的替换
中科大的源地址是mirrors.ustc.edu.cn/centos/。配置方式类似,这里不再重复写 repo 文件内容,只提醒一点:中科大的源默认支持 http 和 https 两种访问方式,gpgkey路径写https://mirrors.ustc.edu.cn/centos/RPM-GPG-KEY-CentOS-7是没问题的。
3.5 一键换源脚本
如果你管理的机器比较多,一台台手动改太浪费时间。我分享一个自己常用的一键脚本(基于阿里云源),你可以根据实际情况改一下源地址:
#!/bin/bash # CentOS 7 一键换阿里云源 # 使用前确认系统为 CentOS 7 if [ "$(id -u)" -ne 0 ]; then echo "请以 root 身份运行" exit 1 fi mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ 2>/dev/null curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo if [ $? -eq 0 ]; then yum clean all yum makecache yum repolist else echo "文件下载失败,请检查网络后重试" fi这个脚本的逻辑不复杂,但有几个细节要注意:
- 开头判断用户是否为 root,避免权限不足导致半途失败。
mv时加了2>/dev/null,因为可能没有.repo文件可以移动,报错信息会干扰判断。- 脚本结束前执行
yum repolist做验证,不用再手动跑一遍。
4. 扩展场景:EPEL 源、本地源与第三方源
4.1 EPEL 源的替换
EPEL 仓库对 CentOS 7 来说非常重要,很多软件(如 Nginx、Redis、Certbot)都在 EPEL 里。但 EPEL 源地址同样受到官方源迁移的影响,需要同步替换。
以阿里云 EPEL 源为例:
curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo清华源的 EPEL 是:
curl -o /etc/yum.repos.d/epel.repo https://mirrors.tuna.tsinghua.edu.cn/help/epel/同样,清华源的帮助页返回的是 HTML,需要手动处理。我建议直接写:
[epel] name=Extra Packages for Enterprise Linux 7 - $basearch baseurl=https://mirrors.tuna.tsinghua.edu.cn/epel/7/$basearch failovermethod=priority gpgcheck=1 gpgkey=https://mirrors.tuna.tsinghua.edu.cn/epel/RPM-GPG-KEY-EPEL-7替换完成后同样要yum clean all && yum makecache。
4.2 本地 yum 源配置
本地 yum 源常用于离线环境。思路是:准备一台能联网的机器,下载所有需要的 RPM 包,拷贝到内网机器上,再把内网机器的 yum 源指向本地目录。
配置方法很简单:
mkdir -p /mnt/localrepo # 把 RPM 包放到 /mnt/localrepo 目录下 createrepo /mnt/localrepo然后创建/etc/yum.repos.d/local.repo:
[localrepo] name=Local Repository baseurl=file:///mnt/localrepo enabled=1 gpgcheck=0注意baseurl的格式,本地路径必须写成file://加绝对路径。这一步我见过太多人写错,少了file://前缀直接导致 yum 无法识别。
createrepo命令如果没安装,需要先通过 yum 安装:
yum install -y createrepo如果是完全离线的机器,你需要先从其他机器下载createrepo的 RPM 包,再手动安装。这里会用到 rpm 安装的依赖处理,如果你发现依赖很多,直接用yum install是最省事的。
注意:本地源一般设置
gpgcheck=0,因为本地的 RPM 包来源是自己或内部团队,校验 GPG 的意义不大。如果坚持开启 gpgcheck,需要用rpm --import导入对应的公钥。
4.3 其他常见第三方源
除了 EPEL,CentOS 7 常用的还有 SCL(Software Collections)、IUS、Remi 等源。这些源通常也需要修改 baseurl 指向国内镜像。
以 SCL 源为例,阿里云上有对应的地址:
curl -o /etc/yum.repos.d/CentOS-SCLo.repo https://mirrors.aliyun.com/repo/centos-sclo.repo这个源主要用来装高版本的开发工具,比如 Python 3.8、MySQL 5.7、PostgreSQL 等。如果你只是日常使用,不需要装这些,可以暂时不配 SCL。
4.4 源替换后的软件安装验证
源换完之后,实际验证环节也值得单独说说。很多人跑完yum makecache觉得没问题就走了,直到某天真正yum install时才暴露问题。
我建议你在换源后顺手装一个小包,验证完整流程是否可用:
yum install -y xdotool为什么选 xdotool?因为热搜词里正好有yum install xdotool。这个包本身很小,依赖也很少,非常适合做安装验证。如果你装完之后发现它能正常安装,说明 base 源的下载、解析、依赖处理都没问题。
如果你还需要验证 EPEL 源,可以试着安装一个相对大一点的包,比如yum install -y htop,htop 在 EPEL 里,能装成功就说明 EPEL 源也正常。
另外,建议顺手验证一下yum update是否可用:
yum update -y这里有个坑:yum update 会把系统里所有已安装软件包升级到仓库中的最新版本。在 CentOS 7 停服之后,镜像源的版本是“冻结”的,但你本地的系统如果之前没更新过,yum update 会一次性拉很多包。生产环境建议不要直接在业务高峰期跑 yum update,而是要规划时间窗口,同时提前做好备份。
5. 常见问题与排查技巧
5.1 换源后报错汇总
我把实际操作中遇到的典型问题整理成一张速查表,方便你按图索骥。
| 报错/现象 | 原因 | 解决方法 |
|---|---|---|
Cannot find a valid baseurl for repo: base/7/x86_64 | 仓库地址 404,源已失效 | 重新配置 baseurl,指向可用镜像 |
Downloading Packages: 警告:/var/cache/yum/x86_64/7/centos-sclo-rh/packages/r... | 下载过程中缓存目录写入失败或中断 | yum clean all后重新 makecache,检查 /var/cache/yum 是否存在 |
Could not resolve host: mirror.centos.org | 网络 DNS 无法解析或源地址失效 | 更换域名,或者检查 DNS 配置 |
[Errno 14] HTTPS Error 404 - Not Found | baseurl 路径不匹配 | 确认路径中系统版本号、架构是否正确 |
Public key for xxx.rpm is not installed | GPG 公钥未导入或配置错误 | 将 gpgcheck 改为 0,或导入对应源的 GPGKEY |
Package xxx is not available | 仓库中不存在该软件包 | 确认是否配置了对应扩展源(EPEL、SCL) |
5.2 缓存目录警告处理
热搜词里有一条很典型的报错:downloading packages: 警告:/var/cache/yum/x86_64/7/centos-sclo-rh/packages/r。
这个报错的本质是 yum 下载软件包时写入缓存目录失败,或者缓存目录被部分清理。最直接的解决方式:
rm -rf /var/cache/yum/* yum clean all yum makecache yum install -y 软件包名rm -rf /var/cache/yum/*这个操作可能会有人觉得太粗暴,但说实话在 yum 源已经失效的情况下,缓存里存的基本都是无效数据,清掉没有任何风险。这也是 CentOS 官方文档里建议的标准处理方式。
5.3 换源后仍然 404
我遇到过一种情况:阿里云源文件下载成功后,yum repolist依然报 404。排查后发现原因是原来/etc/yum.repos.d/里残留了一个CentOS-SCLo-scl-rh.repo文件,里面的 baseurl 指向的还是官方地址,这个文件没有被清理干净。
所以再次提醒:换源前用mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/把所有旧文件都移动走,只保留新写入的文件。
5.4 GPG 校验错误的处理
gpgcheck=1时如果系统导入的 GPG 密钥和仓库不一致,会在 makecache 或安装软件包时报错。解决思路有两个:
- 方法一:把对应
.repo文件里的gpgcheck=1改成gpgcheck=0。在国内内网环境,这是比较多见的做法,因为源本身是可信的。 - 方法二:重新导入正确的公钥。比如阿里云源:
rpm --import http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-75.5 防火墙和代理问题
如果你的服务器在比较严格的网络环境中(比如有出站白名单),可能遇到 yum 可以下载元数据,但下载 RPM 包时中断的情况。这时候检查两个方面:
iptables -L -n或firewall-cmd --list-all确认出站规则。- 如果走 HTTP 代理,确认
/etc/yum.conf中的proxy配置是否正确。yum 默认不会读取环境变量http_proxy,必须在 yum 主配置文件中显式设置。
proxy=http://proxy.example.com:8080 proxy_username=user proxy_password=pass5.6 换源过程中误操作恢复
如果换到一半发现新源也不可用,或者配置文件写错了,最快的恢复方式是使用之前的备份:
rm -f /etc/yum.repos.d/*.repo mv /etc/yum.repos.d/backup/*.repo /etc/yum.repos.d/ yum clean all && yum makecache如果你的备份目录也不小心被清掉了,还有一条后路:CentOS 官方把最终版的所有仓库镜像都归档到了 vault.centos.org,你可以手动指向这个站点。但 vault 站的下载速度在国内一般,属于“能用但不快”的状态。顺手贴一个 vault 源配置模板:
[base] name=CentOS-$releasever - Base baseurl=https://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck=0 [updates] name=CentOS-$releasever - Updates baseurl=https://vault.centos.org/7.9.2009/updates/$basearch/ gpgcheck=0 [extras] name=CentOS-$releasever - Extras baseurl=https://vault.centos.org/7.9.2009/extras/$basearch/ gpgcheck=0这里我特意把gpgcheck设置成 0,因为 vault 是一个归档站点,密钥文件是否长期保留有不确定性。
5.7 多台机器批量换源
如果你手里有几十台 CentOS 7,不想一台台登录操作,可以用pssh或ansible批量执行。我比较常用的是 ansible,playbook 写起来很直观:
- hosts: all become: yes tasks: - name: backup old repo files shell: mkdir -p /etc/yum.repos.d/backup && mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ - name: download new repo file get_url: url: https://mirrors.aliyun.com/repo/Centos-7.repo dest: /etc/yum.repos.d/CentOS-Base.repo - name: clean yum cache shell: yum clean all && yum makecache这个 playbook 的逻辑也参考了“换源脚本”的思路,但用 ansible 跑起来更规模化。实际执行前建议先落一两台机器做试点,确认没问题再全量铺开。
6. 几个实操心得与细节补充
换源这个操作本身不难,难的是在不同环境下把细节处理到位。最后分享几个我踩过坑之后总结出来的心得。
第一,千万别在 yum 源配置里同时开启两个不同厂商的仓库作为同一软件包来源。比如你配置了阿里云的 base 源,又在另一个.repo文件里配置了清华的 base 源,表面看“双保险”,实际上 yum 会随机或按优先级选择一个仓库来安装软件包,如果两边版本号不一致,轻则反复提示依赖冲突,重则装到一半报错。
第二,yum makecache的时间比想象中长。首次生成缓存需要下载仓库里所有软件包的元数据,这个量级通常在几十 MB 到几百 MB 不等。如果你网速一般,看到卡在某个进度条不要急着中断,多等一会儿。我当时在一台带宽 1Mbps 的机器上换源,makecache 跑了将近二十分钟。
第三,如果系统里同时有 EPEL 源和官方源,而且都要换,我建议先换官方源、makecache 成功后再换 EPEL。因为 EPEL 的部分包依赖了官方源的软件包,如果两个源同时是失效状态,可能会在依赖解析阶段报错,干扰排查。
第四,别忘了/etc/yum.conf里的keepcache参数。默认值是 0,也就是安装完成后会自动删除缓存的 RPM 包。如果你希望保留下载的软件包(比如为了搭建本地源),把keepcache=1打开,所有安装过的 RPM 都会留在/var/cache/yum/目录下。我之前搭离线安装环境的时候,就是靠这个配置攒出了一套完整的本地 RPM 包集合,后面在内网机器上安装软件就再也不用到处找包了。
最后再提一个很多人忽略的点:换源之后最好重启一次系统或者至少重启一下相关服务再观察一段时间。虽然 yum 不会因为换源而崩溃,但如果有 cron 任务或监控脚本依赖 yum 做定时更新,换完源后它们的行为可能和之前不一样,比如缓存更新的频率、日志输出路径等。重启的作用不是让配置生效,而是让所有依赖 yum 的服务在一个干净的状态下重新初始化,避免某些进程持有旧的仓库句柄导致后续操作异常。
CentOS 7 已经走进了生命周期终点,但对还在使用的朋友来说,yum 源替换这件事只要做对一次,后续维护就会顺畅很多。希望这份经验能帮你少走一点弯路。