CentOS 8停服后，yum报错‘No URLs in mirrorlist’的三种修复方案（附一键脚本）

CentOS 8停服后的生存指南：从yum报错到系统迁移的完整方案

当你在某个深夜收到服务器告警，尝试用yum安装关键安全补丁时，屏幕上突然跳出那行刺眼的红色错误——No URLs in mirrorlist。这不是普通的配置错误，而是CentOS 8生命周期终结(EOL)的明确信号。作为曾经最受欢迎的企业级Linux发行版之一，CentOS 8的停服让无数运维团队面临艰难抉择：是继续维持这个"僵尸系统"，还是彻底迁移到新的生态？

1. 理解问题的根源：CentOS 8停服的连锁反应

2021年底，红帽公司宣布将CentOS Linux从稳定版本转变为滚动更新的CentOS Stream，这一决定如同在开源社区投下震撼弹。原定支持到2029年的CentOS 8提前在2022年1月31日终止所有维护，官方镜像从mirror.centos.org全面下线。这直接导致两个典型错误：

• No URLs in mirrorlist：当yum尝试连接不存在的官方镜像时返回的基础错误
• Unable to find a match：即使切换了仓库，许多软件包也因缺乏维护而消失

更棘手的是，许多企业当初选择CentOS 8正是看中其长期支持承诺，系统内可能运行着关键业务应用。突然的停服让这些系统陷入"无源之水"的困境——没有安全更新、没有bug修复、甚至无法安装新软件。

提示：继续运行EOL系统存在严重安全隐患，2023年已有利用旧漏洞攻击CentOS 8的案例报告

2. 应急方案：让CentOS 8暂时恢复包管理功能

对于需要争取迁移时间的场景，有三种主流方法可以恢复yum功能：

2.1 切换到CentOS Vault源

Vault是红帽官方存档的旧版本仓库，操作步骤：

sudo sed -i -e "s|mirrorlist=|#mirrorlist=|g" /etc/yum.repos.d/CentOS-* sudo sed -i -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-* sudo yum clean all sudo yum makecache

优缺点对比：

2.2 使用国内镜像源加速

对于国内用户，阿里云和腾讯云提供了CentOS 8的存档镜像。以阿里云为例：

sudo curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo sudo yum makecache

2.3 一键恢复脚本

将以下脚本保存为fix_centos8_yum.sh：

#!/bin/bash VAULT_URL="http://vault.centos.org" ALT_MIRRORS=( "https://mirrors.aliyun.com/centos-vault" "https://mirrors.tencent.com/centos-vault" ) echo "[1] 备份现有repo文件..." cp -r /etc/yum.repos.d /etc/yum.repos.d.bak echo "[2] 尝试连接Vault源..." if curl --output /dev/null --silent --head --fail "$VAULT_URL"; then sed -i -e "s|mirrorlist=|#mirrorlist=|g" /etc/yum.repos.d/CentOS-* sed -i -e "s|#baseurl=http://mirror.centos.org|baseurl=$VAULT_URL|g" /etc/yum.repos.d/CentOS-* else echo "主Vault源不可用，尝试备用镜像..." for mirror in "${ALT_MIRRORS[@]}"; do if curl --output /dev/null --silent --head --fail "$mirror"; then sed -i -e "s|mirrorlist=|#mirrorlist=|g" /etc/yum.repos.d/CentOS-* sed -i -e "s|#baseurl=http://mirror.centos.org|baseurl=$mirror|g" /etc/yum.repos.d/CentOS-* break fi done fi echo "[3] 清理并重建缓存..." yum clean all yum makecache echo "操作完成，请测试yum功能"

3. 长期解决方案：迁移到替代发行版

应急方案只是权宜之计，真正的出路是迁移到活跃维护的替代系统。以下是主流选项的技术对比：

3.1 Rocky Linux vs AlmaLinux技术细节

这两个最受欢迎的RHEL替代品都承诺100%兼容性：

关键差异点：

• 发布节奏：

  • Rocky Linux：通常在RHEL发布后1-2周内跟进
  • AlmaLinux：目标是在RHEL发布后1个工作日内同步

• 管理工具：

  • Rocky提供migrate2rocky转换脚本
  • Alma提供almalinux-deploy转换工具

• 最小化安装：

  # Rocky Linux dnf install @minimal # AlmaLinux dnf module install minimal

3.2 实际迁移操作指南

从CentOS 8迁移到Rocky Linux 8的完整流程：

# 1. 安装EPEL（如尚未安装） dnf install epel-release # 2. 下载迁移脚本 curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh # 3. 执行迁移 bash migrate2rocky.sh -r # 4. 验证结果 cat /etc/redhat-release uname -a

迁移前后关键文件变化：

4. 特殊场景处理：当迁移不可行时

对于无法立即迁移的关键系统，需要建立防御措施：

4.1 安全加固方案

• 网络层防护：

  # 仅允许必要端口 firewall-cmd --permanent --remove-service=http --remove-service=https firewall-cmd --permanent --add-port=443/tcp firewall-cmd --reload

• 服务隔离：

  # 创建受限的systemd单元 systemctl edit --full nginx.service # 添加: [Service] RestrictAddressFamilies=AF_INET AF_INET6 ProtectSystem=strict

4.2 关键软件编译指南

当必须从源码构建时，这个build_env.sh脚本可创建安全编译环境：

#!/bin/bash BUILD_DIR="/opt/secure_build" mkdir -p $BUILD_DIR # 安装基础编译工具 dnf --enablerepo=powertools install -y gcc make autoconf automake libtool # 创建隔离用户 useradd -d $BUILD_DIR -s /sbin/nologin builduser chown -R builduser:builduser $BUILD_DIR # 设置环境变量 echo "export CFLAGS='-O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security'" >> $BUILD_DIR/.bashrc echo "export LDFLAGS='-Wl,-z,now -Wl,-z,relro'" >> $BUILD_DIR/.bashrc echo "安全编译环境已准备在 $BUILD_DIR"

5. 架构层面的未来规划

这次CentOS变故给所有技术决策者上了一课——单一发行版依赖的风险。建议建立多层次的防御策略：

• 混合环境支持：关键服务应能在不同RHEL兼容发行版间快速迁移
• 容器化过渡：将老旧应用封装为容器，逐步迁移到新平台
• 基础设施即代码：使用Terraform、Ansible等工具实现环境可重现性

在笔者参与的一个银行系统迁移项目中，我们采用渐进式策略：先用Vault源维持业务，同时在隔离环境测试Rocky Linux，最终用Ansible Playbook实现批量迁移。整个过程耗时6周，但实现了零停机。