ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

RHEL 9.3 yum源配置详解:阿里云镜像与本地ISO离线源双方案

2026/9/29 1:34:02 拓冰建站 浏览量
RHEL 9.3 yum源配置详解:阿里云镜像与本地ISO离线源双方案 装完Red Hat Enterprise Linux 9.3之后大多数人做的第一件事就是配yum源。不配源的话你在国内网络环境下跑dnf install大概率会被红帽的订阅机制卡住要么反复提示没有注册要么直接报“Errors during downloading metadata”。这篇文章把我自己在RHEL 9.3上配置yum源的完整过程记录下来包含两条路线一条是阿里云镜像站的网络源一条是挂载本地ISO镜像的离线源两条源可以同时存在按优先级配合使用。文章内容覆盖网络源配置、本地源挂载、双源共存、常见报错排查适合刚上手RHEL 9.x的操作员也适合生产环境在内网隔离条件下需要离线安装软件的运维同学。我先从原理讲起再一步步给操作最后把排查经验也一起放进来。1. 先搞清楚RHEL默认源为什么“总是连不上”1.1 默认源和订阅机制的绑定关系RHEL 9.3的软件源和CentOS、Rocky Linux有个非常大的区别它的默认仓库不是写在普通的/etc/yum.repos.d/文件里而是由subscription-manager这个订阅管理工具动态生成。系统安装完成后/etc/yum.repos.d/redhat.repo里面的内容其实是空的只有执行了subscription-manager register并完成订阅关联之后这个文件才会被填上真正的仓库地址。这个机制带来的问题很直接如果你的机器没有订阅或者你的订阅在CDN层面访问不畅dnf去请求仓库元数据时就会一直转圈最终报错。很多朋友第一次用RHEL 9.3时遇到Errors during downloading metadata for repository其实不是网络不通而是根本没有有效的仓库地址。我在一台刚装好的RHEL 9.3上做过测试什么都不配置直接执行dnf install vim系统会卡在“This system is not registered with an entitlement server”这个提示附近等到最后就是下载metadata失败。这不是你的操作问题而是默认机制就没打算让你在未注册状态下使用官方源。1.2 为什么选择Rocky 9仓库来替代RHEL 9默认源既然官方源这条路走不通社区里最通用的替代方案是什么答案是使用二进制兼容发行版的仓库。RHEL 9.x和Rocky Linux 9.x、AlmaLinux 9.x在二进制层面完全兼容依赖关系基本一致软件包可以直接复用。阿里云镜像站上维护了Rocky Linux 9仓库、EPEL仓库等资源访问速度在国内非常理想。所以实际操作中大家普遍的做法是把RHEL 9.3的软件源指向阿里云上的Rocky Linux 9仓库。这样做不是官方行为但经过大量生产环境验证依赖解析基本不会出问题。要注意一点不要拿CentOS Stream仓库来顶替。CentOS Stream虽然也基于RHEL但它是“滚动预览版”版本节奏和RHEL 9.3不匹配装出来的依赖可能对不上。最稳妥的就是Rocky 9或AlmaLinux 9的仓库二者阿里云都做了同步镜像。明白了这一点后面配置阿里源时你就知道所谓的“换源”其实本质上是“换发行版仓库地址”并用Rocky Linux的签名密钥来校验软件包。如果你在内网离线环境连外网都访问不了那就用本地ISO镜像源这个后面会详细展开。2. 阿里云yum源配置从备份到验证的完整操作2.1 备份默认repo并关闭订阅插件配置阿里源之前第一件事是备份原有配置。RHEL 9.3默认文件虽然内容不多但养成备份的好习惯后续排查时能少走弯路。mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/接下来处理订阅插件。subscription-manager作为一个dnf插件会干扰自定义源的使用建议直接关闭它。编辑/etc/dnf/plugins/subscription-manager.conf把enabled1改成enabled0。sed -i s/^enabled.*/enabled0/ /etc/dnf/plugins/subscription-manager.conf这个插件负责在每次dnf操作时检查系统注册状态关掉之后dnf就不会再去访问红帽订阅服务器。有些朋友只改repo文件忘了关插件结果每次dnf makecache都会拖很久最后还报订阅错误这点要注意。如果你希望更彻底还可以备份后清空/etc/yum.repos.d/redhat.repo的内容。这个文件本身就是订阅管理器生成的禁用插件后不会再自动更新留着空文件不影响使用。2.2 编写阿里云镜像repo文件接下来创建阿里云源仓库文件。我习惯把所有第三方仓库放在/etc/yum.repos.d/aliyun.repo里这样一眼能看出哪些仓库是阿里源后续维护方便。先导入Rocky Linux 9的GPG签名密钥。RHEL 9.3本身自带的红帽密钥无法匹配Rocky的软件包所以这一步必须做rpm --import https://mirrors.aliyun.com/rockylinux/RPM-GPG-KEY-Rocky-9如果此时机器还没有外网也可以后面从ISO里找密钥文件离线导入这里先按在线流程走。然后创建/etc/yum.repos.d/aliyun.repocat /etc/yum.repos.d/aliyun.repo EOF [baseos] nameRocky Linux 9 BaseOS (Aliyun) baseurlhttps://mirrors.aliyun.com/rockylinux/9/BaseOS/$basearch/os/ enabled1 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [appstream] nameRocky Linux 9 AppStream (Aliyun) baseurlhttps://mirrors.aliyun.com/rockylinux/9/AppStream/$basearch/os/ enabled1 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [extras] nameRocky Linux 9 Extras (Aliyun) baseurlhttps://mirrors.aliyun.com/rockylinux/9/extras/$basearch/os/ enabled1 gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 EOF这个配置文件里有几个重点要说清楚。baseurl里我写的是9而不是$releasever这是有意为之。在RHEL系统上$releasever会自动解析成9.3但阿里云Rocky仓库的目录名是9如果用了变量就会出现404非常坑。$basearch可以保留它会自动解析成x86_64或aarch64。gpgcheck1建议保持开启。软件包签名校验是软件供应链安全的第一道防线虽然开启有时会遇到密钥导入问题但比起不做校验这点成本可以接受。如果实在搞不定密钥可以临时改成gpgcheck0但生产环境不建议长期如此。2.3 刷新缓存并测试安装配置写完执行清理和缓存生成dnf clean all dnf makecachemakecache会下载所有仓库的元数据。阿里云国内节点速度很快通常几十秒就能完成。看到Metadata cache created之类的输出就说明源已经通了。验证仓库列表dnf repolist正常情况下会列出baseos、appstream、extras三个仓库状态都是enabled。然后实测安装一个软件包验证依赖解析是否正常dnf install -y vim wget tar如果这一步顺利跑完说明阿里源已经能完全替代官方源使用。我测试时在这台RHEL 9.3上直接装了nginx和python3依赖解析都很正常没有遇到版本冲突。这里再多说一句有些第三方软件不在BaseOS和AppStream仓库里比如一些社区维护的工具。需要EPEL源时可以再加一个阿里云EPEL仓库cat /etc/yum.repos.d/epel.repo EOF [epel] nameEPEL for Rocky Linux 9 (Aliyun) baseurlhttps://mirrors.aliyun.com/epel/9/Everything/$basearch/ enabled1 gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/epel/RPM-GPG-KEY-EPEL-9 EOFEPEL是扩展软件包仓库Red Hat官方源里很多冷门工具都能从EPEL装到阿里云同样做了同步。3. 本地ISO镜像源挂载离线环境照样装包3.1 ISO镜像的目录结构先认清再挂载有些服务器在内网隔离区或者云环境网络策略很严格根本访问不了外网镜像站。这时候本地ISO镜像源就成了救命稻草。RHEL 9.3的ISO安装镜像里其实自带了完整的软件仓库数据关键是你要知道它内部的结构。把RHEL 9.3的ISO挂载起来之后可以看到根目录下有BaseOS和AppStream两个目录。这两个目录就是两个独立的仓库各自内部都有Packages和repodata目录。repodata目录里存的正是dnf需要的元数据文件所以ISO不需要额外执行createrepo直接就可以作为本地源使用。这个设计从RHEL 8时代就开始了。很多老教程还在教你createrepo自制本地源那是针对CentOS 7或更早版本的流程。RHEL 9.x完全不需要你把ISO一挂路径一指仓库就成了。3.2 挂载ISO并配置开机自动挂载先把ISO文件上传到服务器比如放到/opt目录下然后创建挂载点并挂载mkdir -p /mnt/rhel9iso mount -o loop /opt/rhel-9.3-x86_64-dvd.iso /mnt/rhel9iso-o loop参数的意思是使用loop设备挂载镜像文件这是Linux加载ISO镜像的标准做法。挂载完成后确认目录结构ls /mnt/rhel9iso/ ls /mnt/rhel9iso/BaseOS/ ls /mnt/rhel9iso/AppStream/repodata/能看到BaseOS、AppStream目录并且BaseOS下面有repodata说明镜像没问题。重启之后挂载关系会消失如果这台机器要长期使用建议写入/etc/fstab实现开机自动挂载。在文件末尾追加一行/opt/rhel-9.3-x86_64-dvd.iso /mnt/rhel9iso iso9660 loop,defaults 0 0追加完成后执行mount -a测试一下没有报错就说明fstab配置正确。注意字段之间用空格或Tab分隔路径不能写错否则重启时会因为挂载失败导致系统启动异常。3.3 基于ISO生成两个本地仓库ISO挂载好之后创建本地源仓库文件。这里我单独建一个local.repo和阿里源区分开cat /etc/yum.repos.d/local.repo EOF [local-baseos] nameRHEL 9.3 Local BaseOS baseurlfile:///mnt/rhel9iso/BaseOS enabled1 gpgcheck0 [local-appstream] nameRHEL 9.3 Local AppStream baseurlfile:///mnt/rhel9iso/AppStream enabled1 gpgcheck0 EOF这里我把gpgcheck设置成了0有朋友可能会问前面阿里源不是建议开签名校验吗为什么本地源反而关了原因是这样的RHEL 9.3的ISO里软件包使用的是红帽自己的GPG签名而系统里默认导入的密钥并不包含ISO仓库的对应密钥。你要么手动导入ISO里的RPM-GPG-KEY-redhat-release要么干脆关掉校验。在内网隔离环境、ISO文件来源可控的前提下gpgcheck0的便利性更高。当然如果安全策略要求必须开启可以在/mnt/rhel9iso/下找到RPM-GPG-KEY-redhat-release文件拷贝到/etc/pki/rpm-gpg/目录并导入然后把gpgcheck1打开。仓库文件写好后同样执行缓存刷新dnf clean all dnf makecache dnf repolist此时会看到local-baseos和local-appstream两个本地区域仓库。随便挑一个ISO自带的软件包试试安装比如httpddnf install -y httpd如果顺利装完本地源就生效了。3.4 补充用createrepo自建本地RPM目录源还有一种常见场景你手头没有ISO文件只有一个装满rpm包的目录可能是同事拷给你的也可能是之前下载好的安装包。这时可以用createrepo把这个目录变为一个标准仓库。RHEL 9.3系统里如果没有createrepo命令先通过其他可用源安装它dnf install -y createrepo_c然后把rpm包放到一个目录下执行仓库初始化mkdir -p /data/rpm-repo cp /path/to/your/rpms/*.rpm /data/rpm-repo/ createrepo /data/rpm-repo执行完会在/data/rpm-repo下生成repodata目录之后在repo文件里写[local-custom] nameLocal Custom RPM Repository baseurlfile:///data/rpm-repo enabled1 gpgcheck0这种方式适合临时收集的软件包、离线缓存包批量安装等场景。注意createrepo每次新增rpm包后都需要重新执行一次否则dnf看不到新包。4. 双源共存本地源与网络源的优先级和日常维护4.1 用priority参数控制源优先级实际使用中我建议同时保留本地ISO源和阿里云源。本地源在没有网络时提供兜底阿里源提供更多更新的软件包。两个源共存时会涉及一个问题同一个软件包两边都有dnf装哪个dnf默认顺序是按照repo文件名字母序去解析这不是我们想要的。更好的做法是通过priority插件控制。先安装插件dnf install -y dnf-plugin-priority如果这个插件没装成功也可以手动管理执行安装命令时用--disablerepo临时禁用不需要的仓库。但插件方式一劳永逸优先级别直接写在repo文件里。数字越小优先级越高。我在local.repo里设置priority1在aliyun.repo里设置priority99# local.repo [local-baseos] priority1 # aliyun.repo [baseos] priority99设置完成后再刷新一次缓存。这样dnf在安装软件时只要本地ISO里存在这个包就会优先生成本地源阿里源里独有的包才会走网络下载。既能保证离线可用又能让软件版本相对可控。4.2 双源共存时的软件版本管理双源配置带来的另一个好处是版本管理的灵活性。我举个例子RHEL 9.3 ISO镜像里的软件版本是发布时固化的比如某个内核工具停在9.3初始版本但阿里云Rocky仓库可能已经同步了9.3的更新小版本。如果你希望服务器保持相对稳定本地源的高优先级会自动挡住这些更新如果你要把安全补丁打上可以临时提权阿里源来安装特定软件包。具体操作可以这样dnf update --disablerepolocal-* -y这条命令会忽略所有本地仓库完全从阿里源拉取更新。反过来如果你要离线安装某个包并且希望阻止dnf去网络上查找dnf install -y some-package --disablerepobaseos --disablerepoappstream --disablerepoextras这样只保留本地源生效dnf找不到就报错不会走网络。掌握这两个命令组合双源之间切换就很灵活了。4.3 日常维护的几个建议双源配置不是写完就一劳永逸的有几个日常习惯我建议养成。第一定期dnf makecache。缓存过期后dnf判断仓库元数据失效会尝试自动重新下载如果阿里源恰好临时不可用安装操作就会卡住。建议crontab里每周执行一次0 2 * * 0 /usr/bin/dnf makecache --refresh /dev/null 21第二修改dnf主配置增加下载超时和重试容忍度。编辑/etc/dnf/dnf.conf在[main]下面加入timeout30 retries3 skip_if_unavailableTrue max_parallel_downloads10skip_if_unavailableTrue的作用是当某个仓库不可用时跳过它而不是中断整个操作多源共存时这个参数非常有用。max_parallel_downloads可以加快多软件包同时下载的速度国内网络带宽够用的话建议开起来。第三ISO挂载点不要随意卸载。如果双源里既有本地源又有阿里源某天你手动umount /mnt/rhel9iso后忘了处理再执行dnf操作时local仓库会报Cannot find a valid baseurl。这时候要么重新挂载ISO要么把local.repo里对应仓库的enabled改成0别让废仓库影响整体流程。5. 高频报错与排查技巧实录5.1 报错速查表配置yum/dnf源的过程中有几个报错反复出现。我把它们整理成一张速查表按表格里的思路排查大部分问题十分钟内能解决。报错信息可能原因处理方法Errors during downloading metadata for repository baseos仓库URL不可达、网络不通、DNS解析失败curl -I检查URL是否能访问检查DNS配置临时把gpgcheck改为0排除签名问题GPG key retrieval failed密钥没有导入或密钥URL被网络策略拦截从阿里云官网或ISO中导入密钥关闭gpgcheck不推荐长期Cannot find a valid baseurl for repo: local-baseosISO未挂载、挂载路径错误、repo文件路径写错mount查看挂载点ls /mnt/rhel9iso/BaseOS确认目录This system is not registered with an entitlement server订阅插件加载系统未注册修改/etc/dnf/plugins/subscription-manager.conf设置enabled0$releasever解析错误导致404RHEL上$releasever解析成9.3而仓库目录是9仓库URL中直接写死9不使用$releaseverNo match for argument软件包名称拼错或当前启用仓库中不存在该包dnf search搜索正确名称启用EPEL等扩展仓库5.2 一个真实的排查过程metadata下载失败的定位思路之前有个朋友的服务器反馈说dnf完全没法用报错就是一路metadata下载失败。他确认阿里源配置没问题手动curl仓库URL也正常。我远程看了一眼发现问题出在DNS解析上——系统的/etc/resolv.conf指向了一个内网不存在的DNS服务器域名解析超时后dnf就一直卡在下载上。这类问题建议按照“由内到外”的顺序排查先确认本机DNS解析是否正常getent hosts mirrors.aliyun.com再确认网络路由是否通ping 223.5.5.5测试公网连通性最后用curl -I直接请求仓库地址。三步走完问题范围基本就能圈定。还有一个比较隐蔽的坑有些云主机默认配了HTTP代理但代理服务器不稳定导致dnf在下载metadata时反复失败。如果你发现curl直接访问仓库没问题但dnf就是失败可以看一眼环境变量里有没有http_proxy和https_proxy必要时在/etc/dnf/dnf.conf里加一行proxy来指定代理或者直接unset http_proxy https_proxy再试。5.3 配置过程中的安全与习惯建议最后再补充几点配置yum源时的安全习惯。虽然换源本身是为了解决可用性问题但换源过程中也要注意软件供应链风险。建议所有仓库都来自可信镜像站不要随便在网上找教程里的不明仓库地址。阿里云、清华、中科大等镜像站都是长期维护的公共资源可信度相对较高。如果公司有内网源服务器优先配置内网源速度和安全性都更好。另外签名校验尽量保留。前文提到本地ISO可以关掉gpgcheck那是针对来源可信的离线文件但网络源必须开启gpgcheck1。安装软件包时如果一开始没有导入密钥dnf会提示指纹信息务必确认指纹后再接受不要盲目忽略。从习惯上看每次修改repo文件后先dnf clean all再dnf makecache确认缓存生成成功后再干别的。这能避免很多“改完配置没生效”的假象。我自己的习惯是把这一整套配置过程整理成脚本每次新装一台RHEL 9.x机器跑一遍脚本几分钟就能完成换源加本地源挂载。脚本内容其实就是本文列出的命令组合稍微加上路径判断就够了。这样既保证配置一致性也减少手工操作出错的可能。配置yum源这件事本身不复杂但细节很多尤其是RHEL这种有订阅机制的发行版换源思路和CentOS不太一样。把原理理解透了不管以后是用阿里源、华为源还是内网源都能快速上手。