RHEL 9软件源配置：本地源、镜像源与内网自建源实战

1. 先想清楚"源"这件事：为什么它决定了一台机器的可用性

装完最小化系统的第一件事，绝大多数人都会去敲dnf install，然后发现卡住、超时、报 404。这时候问题八成不在网络，而在软件源——也就是 repo。本地源和镜像源这两条路，看起来只是配置文件里几个 URL 的差别，实际决定了后续半年里这台机器是"能自己装东西"还是"每次都要找人拷 rpm 包"。我把这两套配置当作交付前的固定动作，无论是给测试机装环境、给内网机器做离线部署、还是给一批机器做同版本基线，都是先落源、再装包。

这篇文章讲的是 RHEL 9 这一类系统上的软件源落地：怎么用一张安装 ISO 做出可用的本地源，怎么把公共镜像站的仓库接到系统里，以及内网里怎么搭一个大家共用的镜像仓库。读者画像大概是三种人：刚接手 Linux 的新手，被Could not resolve host折磨过；做运维的，手里有一堆没有外网的内网机；还有一种是自己搭实验环境的，想省下每次装包找依赖的时间。核心关键词就是本地源、镜像源、repo 配置，后面的内容都围绕它们展开。

我先把三者的定位摆出来，因为选错形态是后面所有问题的根源。本地源的本质是"文件路径当仓库"，它不依赖任何网络，稳定性最高，缺点是内容固定在一张 ISO 的范围内，更新滞后；公共镜像源的本质是"把仓库搬到离你近的服务器上"，覆盖面广、能拿到更新，缺点是受网络质量和站点可用性影响；内网自建源是前两者的折中，用一次带宽换长期稳定，适合机器数量超过十台的场景。

2. 三种源的取舍逻辑，以及一个必须对齐的版本号

2.1 本地源、公共镜像源、内网自建源的适用边界

我一般按"机器数量 × 网络条件"两个维度来选。单台机器、能上外网，直接用公共镜像源，五分钟搞定；单台机器、完全隔离，用 ISO 做本地源，镜像挂上就能用；五台以上、需要长期维护，我会花半天时间做内网源，因为后面每台机器都要重装、都要装同样的包，一次性投入很快就能回本。这三种方案的对比我整理成了下面这张表，选型时直接对照就行。

方案	依赖网络	更新时效	初始成本	典型场景
ISO 本地源	否	固定在该 ISO 发布时点	挂载 + 写一个 repo 文件	隔离环境、装机验证、批量基线
公共镜像源	是	跟随站点同步周期	换 baseurl + 清缓存	开发机、测试机、临时环境
内网自建源	仅同步时	由自己的同步策略决定	需一台中转机和存储	机房、实验室、多机交付

这里有个容易被忽略的判断点：本地源不只是"离线替代品"，它还是版本一致性的锚点。你在十台机器上都挂同一张 ISO，装出来的基础包版本就完全一致，排查问题时不会出现"这台是 9.2 那台是 9.4"的尴尬。所以在做需要严格复现的实验时，我宁可用本地源，也不用镜像源去追最新。

2.2 版本号对齐：$releasever是绝大多数报错的源头

repo 文件里常见的baseurl=https://<镜像站>/rhel/$releasever/BaseOS/$basearch/os/，这两个变量是 dnf 在运行时展开的。$basearch一般是x86_64或aarch64，比较好确认；$releasever就麻烦一点，它取的是系统识别到的版本号，在 RHEL 9 上通常解析成9，而不是9.0、9.4这种带小版本的写法。

问题在于，很多公共镜像站的目录结构是9/、9-stream/、9.4/混着放的，你写$releasever展开成9，结果站点目录叫9.4，直接 404。我的做法是在写 repo 文件之前先手工确认目录：用浏览器或者curl -I探一下目标路径是否存在，确认后再决定是用$releasever还是直接硬编码小版本号。硬编码看起来不够"优雅"，但它换来的是不会因为系统小版本升级而突然断源。

提示：dnf报错Failed to download metadata for repo 'xxx'时，先别急着怀疑网络，用浏览器把拼出来的完整 URL 打开看一眼，十次里有六次是路径写错了。

另一个常见坑是本地源和镜像源混用时的版本错位。比如系统是 9.4，ISO 是 9.0 的，那么从本地源装的老版本包和从镜像源装的新版本包可能产生依赖冲突。我的处理原则是：同一个仓库族（BaseOS / AppStream）不要在同一个优先级上同时来自两个不同小版本的源，要么统一用 ISO 版本，要么统一用镜像站的当前小版本，别混着来。

3. 动手之前：三分钟摸清家底

3.1 用几条命令确认系统身份和现有源状态

别急着写配置文件，先确认你面对的到底是什么系统。下面这几条命令我几乎是条件反射地敲：

cat /etc/os-release uname -m dnf repolist --all ls /etc/yum.repos.d/

第一条确认发行版和版本号，主要看VERSION_ID；第二条确认架构，决定$basearch的值；第三条列出所有已定义的仓库，包括被禁用的，能看出系统出厂自带了哪些 repo 文件；第四条看目录里有哪些.repo文件，方便判断是改造现有的还是新建一个。

这里有个实操细节：/etc/yum.repos.d/下如果已经有一堆仓库文件，绝大多数是官方订阅源，在没订阅的机器上它们全是 401 或者超时。这些文件留着会让每次dnf makecache都白等一轮超时。我的做法是先建一个备份目录，把这批文件整体移走，再按需新建：

mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/

移走而不是删除，是因为某些场景下还要回头参考原来的配置写法，删了就得重新找。

3.2 ISO 文件的获取与完整性确认

本地源依赖安装介质。如果你拿到的是物理光盘，插进去之后用lsblk或blkid找到设备名，通常是/dev/sr0；如果是下载的 ISO 文件，先确认文件完整——sha256sum对一下官方公布的校验值，这一步别省，我有一次因为 ISO 传输中断导致挂载后目录里少了AppStream，排查了快一个小时才想到是文件本身坏了。

sha256sum /path/to/rhel-9.0-x86_64-dvd.iso

确认无误后再做挂载。另外一个必须提醒的点：用 DVD 版 ISO，不要用 Boot 版。Boot 版只有引导文件，里面没有Packages目录，挂上去之后BaseOS里空空如也，配置写得再对也装不了包。判断方法很简单，看 ISO 大小——完整 DVD 镜像通常是几个 GB 级别。

顺带看一眼磁盘空间，/var/cache/dnf在首次makecache时会占几十到几百 MB，空间太紧张的话先把缓存目录挪到别处，或者定期dnf clean packages。

4. 本地源落地：从挂载到 dnf 能用的完整链路

4.1 挂载方式的选择与目录结构确认

挂载这一步有两种做法：如果是物理光驱，直接mount /dev/sr0 /mnt/iso；如果是 ISO 文件，用 loop 设备mount -o loop。我习惯统一建一个固定挂载点/mnt/iso，因为后面写进 repo 文件的路径要长期稳定，临时换个目录又得改配置。

mkdir -p /mnt/iso mount -o loop,ro /path/to/rhel-9.0-x86_64-dvd.iso /mnt/iso ls /mnt/iso

挂载完一定要ls看一眼。RHEL 9 的 DVD 目录下应该能看到BaseOS、AppStream两个目录，以及EULA、RPM-GPG-KEY-*之类的文件。这两个目录就是两个独立的仓库，需要分别配成两个 repo 段——这是新手最容易漏的地方，只配了BaseOS，结果dnf install vim一路报缺包，因为vim在AppStream里。

ro参数别省，只读挂载能避免误操作破坏介质内容，对 loop 挂载来说也省得文件系统被写脏。

注意：如果挂载点位于 SELinux 会检查的路径下，偶发出现 dnf 读不到目录内容的情况。可以用ls -Z /mnt/iso看一眼上下文，必要时用restorecon -Rv /mnt/iso复位。绝大多数默认配置下不会碰到，但排障时值得先排除这一项。

4.2 repo 文件的关键参数逐条说明

在/etc/yum.repos.d/下新建local-iso.repo，内容大致如下：

[local-baseos] name=Local ISO BaseOS baseurl=file:///mnt/iso/BaseOS enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release cost=100 [local-appstream] name=Local ISO AppStream baseurl=file:///mnt/iso/AppStream enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release cost=100

逐条说为什么这么写。baseurl用file://协议加绝对路径，三个斜杠不能少——写成file://mnt/iso会被当成主机名mnt，报一个很迷惑的解析错误。enabled=1表示默认启用，本地源我一般保持常开。gpgcheck=1是包签名校验，很多人为了省事改成 0，我不建议：本地源的内容虽然来自官方介质，但校验开着几乎不增加开销，却能在介质被篡改或损坏时给出明确报错。gpgkey指向本机的公钥文件，如果这个路径不存在，可以从 ISO 里拷一份出来：

cp /mnt/iso/RPM-GPG-KEY-* /etc/pki/rpm-gpg/

cost是 dnf 原生的仓库成本参数，默认 1000，数值越小优先级越高。把本地源设成 100，意味着同样的包在两个仓库里都有时，优先从本地源取——这样在内网环境下能最大限度减少对外网的依赖。注意cost只在"同一个包多仓库可选"时起作用，它不是万能的优先级开关。

还有个可选参数module_hotfixes=true，如果本地源和模块流（module）混用时出现元数据解析报错，加上它经常能绕过去。原理是让 dnf 忽略模块过滤，直接把仓库当普通仓库处理。副作用是模块流的管理能力失效，所以只在排障时临时用，别常态挂着。

4.3 让挂载在重启后依然有效

mount是临时的，重启就没了。要长期可用，得写进/etc/fstab。ISO 文件用 loop 挂载的写法：

/path/to/rhel-9.0-x86_64-dvd.iso /mnt/iso iso9660 loop,ro 0 0

物理光驱的写法是/dev/sr0 /mnt/iso iso9660 defaults,ro 0 0。写完之后一定要用mount -a验证一遍，别直接重启——fstab写错会导致系统进 emergency mode，远程机器上这一下就很难受了。mount -a不报错、df -h能看到挂载点，才算过关。

如果你的场景是"只在装包时需要源，平时不需要"，那fstab里加noauto更合适，需要时手动mount /mnt/iso。这样开机不依赖介质在位，物理光驱拔掉也不会影响启动。

配置完成后走一遍标准验证流程：

dnf clean all dnf makecache dnf repolist

repolist输出里应该能看到local-baseos和local-appstream，且包数量不是 0。如果包数量显示 0，说明路径指到了空目录，回去核对ls /mnt/iso/BaseOS是不是真有Packages。

5. 镜像源配置：baseurl 怎么写、缓存怎么管、优先级怎么排

5.1 从公共镜像站取仓库的配置模板

公共镜像站的用法是把baseurl从file://换成https://，其余结构一样。我不会在文章里写死某一个站点的域名，因为站点目录结构会变，写死了过几个月就失效。给你一个模板，把占位符换成你实际确认过的路径即可：

[mirror-baseos] name=Public Mirror BaseOS baseurl=https://<镜像站域名>/rhel/9/BaseOS/$basearch/os/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release cost=500 skip_if_unavailable=1 [mirror-appstream] name=Public Mirror AppStream baseurl=https://<镜像站域名>/rhel/9/AppStream/$basearch/os/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release cost=500 skip_if_unavailable=1

skip_if_unavailable=1是实用参数：当这个仓库临时不可达时，dnf 跳过它继续处理其他仓库，而不是整体失败。在有本地源兜底的情况下，这个参数能明显提升体验——外网抖一下，dnf install不至于直接挂掉。

cost=500让它排在本地源（100）之后。这个组合的实际效果是：装包时优先从本地 ISO 取，本地没有的再从镜像站补。我在隔离和半隔离环境里常用这个搭配。

换源之后必须清缓存。dnf 会缓存仓库元数据，不清的话它还在读旧的baseurl：

dnf clean all dnf makecache --refresh

--refresh强制忽略缓存有效期重新拉取，比单纯makecache更彻底。第一次makecache可能会慢一点，因为要下载repomd.xml和各仓库的 primary 元数据，正常情况一两分钟内完成。

5.2 仓库优先级和包冲突的处理思路

多仓库并存时，同一个包在不同仓库里有不同版本是常态。dnf 的默认行为是选版本最高的，而不是选优先级最高的仓库——这点和很多人的直觉相反。cost影响的是同版本情况下的选择顺序，不是版本高低。理解这一点能省下大量困惑。

真要控制"某个包必须从某个仓库装"，有两个办法。一是临时指定仓库：

dnf --disablerepo='*' --enablerepo=local-appstream install vim

二是用dnf repoquery先查清楚包在哪些仓库里有、各自什么版本：

dnf repoquery --info vim dnf repoquery --show-duplicates vim

--show-duplicates特别有用，它会把所有仓库里同名包的版本都列出来，一眼就能看出冲突来源。我排查"为什么装的是老版本"这类问题时，第一件事就是敲它。

另一个容易忽略的东西是模块流。RHEL 9 的AppStream里有大量以模块形式组织的软件（如某些语言的运行时），模块有自己的启用状态。dnf module list能看到当前启用的流。本地源和镜像源的模块元数据如果不一致，可能出现"这个包明明在仓库里，却提示没有可用版本"。这时候先dnf module list <包名>，看清楚是不是模块流的问题，再决定是dnf module reset还是换个流。

5.3 GPG 校验失败怎么定位

gpgcheck=1会带来一类报错：Public key for xxx.rpm is not installed或者GPG signature verification failed。前者是gpgkey路径不对或没导入，后者是包的签名和公钥不匹配。

排查顺序我固定这么走：先rpm -qa gpg-pubkey*看本机已导入哪些公钥；再确认gpgkey指向的文件存在且可读；最后用rpm --checksig <包路径>单独验一个包，确认是包的问题还是仓库配置的问题。如果确认是公钥缺失，手工导入一次：

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

还有一种情况是系统时间严重偏差导致签名校验的证书有效期判断出错。容器里、旧虚拟机上经常碰到。date看一眼，不对就先把时间同步好再重试——这个坑很隐蔽，因为报错信息不会提示你时间问题。

6. 内网自建源：一次投入换长期稳定

6.1 用同步工具做离线仓库

机器一多，每台都去外网拉包就很不经济，尤其是带宽紧张的机房。做法是找一台能访问外网的中转机，把仓库同步到本地磁盘，再用 HTTP 服务发出去。同步用reposync，索引重建用createrepo_c，两个工具都在dnf-utils和createrepo_c包里。

dnf install -y dnf-utils createrepo_c httpd mkdir -p /var/www/html/repo/{BaseOS,AppStream} reposync --repoid=mirror-baseos --download-metadata -p /var/www/html/repo/BaseOS reposync --repoid=mirror-appstream --download-metadata -p /var/www/html/repo/AppStream

--download-metadata是关键参数，它把仓库的元数据一起拉下来，省掉后面createrepo重建的步骤。不加的话只有 rpm 包，客户端拿不到索引，一样用不了。如果确实只拉了包，就补一步：

createrepo_c /var/www/html/repo/BaseOS createrepo_c /var/www/html/repo/AppStream

同步是个吃磁盘的活，完整同步两个仓库大概要几十 GB。第一次同步前先df -h看看，别同步到一半满了留下半套数据。我一般会加个--newest-only只拉最新版本，能省不少空间，代价是拿不到历史版本的包。

同步完启动 HTTP 服务，注意防火墙和 SELinux：

systemctl enable --now httpd firewall-cmd --permanent --add-service=http firewall-cmd --reload restorecon -Rv /var/www/html/repo

restorecon这一步不能省。/var/www/html下的文件如果不是正确的 SELinux 上下文，httpd 会返回 403，而错误日志里只写 permission denied，很容易误判成文件权限问题。

6.2 客户端指向内网源的写法

客户端这边就是标准 repo 文件，baseurl换成内网地址：

[internal-baseos] name=Internal Mirror BaseOS baseurl=http://<内网服务器地址>/repo/BaseOS/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release cost=200

内网源和本地源可以共存，cost设成 200 让它在 ISO 之后、公网之前。这样一套优先级链就是：ISO（100）→ 内网源（200）→ 公网镜像（500），既保证了离线可用，又保证了包的新鲜度。

如果你的场景是定期同步，写个 systemd timer 或者 cron 就行，每周跑一次同步脚本，同步完自动createrepo_c --update更新索引。脚本里加个set -e和日志重定向，出问题能追溯。

7. 常见问题排查实录：这些坑我都踩过

7.1 高频报错速查表

排障时最耗时间的不是修，是判断往哪个方向修。我把这些年遇到的高频报错整理成表，按报错关键字直接对号入座，能省掉大部分试错。

报错关键字	大概率原因	处理动作
Failed to download metadata	baseurl 路径错、站点目录变更	手工打开完整 URL 验证
Cannot find a valid baseurl	变量展开后路径不存在	查$releasever实际值，改硬编码
Could not resolve host	域名解析问题	nslookup确认，检查/etc/resolv.conf
Public key not installed	gpgkey 路径错或未导入	rpm --import手工导入
GPG signature verification failed	包与公钥不匹配、系统时间错	校验时间，确认公钥版本
No available modular metadata	本地源缺模块元数据	加module_hotfixes=true临时绕过
Nothing to do	包已被装、或仓库里确实没有	dnf repoquery确认包是否存在
Error: GPG check FAILED	介质损坏	重新校验 ISO 的 sha256
Permission denied（httpd 侧）	SELinux 上下文不对	restorecon -Rv
curl error 60	证书校验失败	检查系统 CA 包、时间

这张表覆盖了八九成的场景。剩下的疑难杂症基本都要靠dnf -v或dnf --debuglevel=10输出细节来定位，日志量很大但信息很全，把baseurl展开后的实际 URL 和 HTTP 状态码找出来，问题基本就明了了。

7.2 几个不在文档里的经验

第一，先验证 URL 再写配置文件。我现在的习惯是拿到一个镜像站，先用curl -I把拼好的repodata/repomd.xml路径探一遍，返回 200 才往 repo 文件里写。这一步三十秒，能省掉后面十分钟的疑惑。命令长这样：

curl -I "https://<镜像站域名>/rhel/9/BaseOS/x86_64/os/repodata/repomd.xml"

注意必须是repodata/repomd.xml，而不是BaseOS/目录本身——有些站点目录列表被禁用了，根路径返回 403 但仓库实际是好的，看repomd.xml才准。

第二，dnf clean all不是万能的。有些情况下元数据缓存在/var/cache/dnf之外的地方（比如libdnf的缓存），清了还是读到旧的。这时候dnf makecache --refresh或者干脆把/var/cache/dnf整个目录删掉再重建，效果更彻底。

第三，别在同一个系统上留太多 repo 文件。每多一个仓库，每次makecache和每次装包都要多一轮元数据比对，机器多了感知很明显。我一般控制在三到四个：本地源两个（BaseOS + AppStream）、业务需要的话再加一个内网源或扩展仓库，仅此而已。那些"以防万一"留着的不用的源，实际上只贡献了超时时间。

第四，本地源和镜像源的包版本差异要在交付文档里写清楚。这不算技术问题，但很影响后续维护。接手的人不知道你这套源的优先级设计，看到某个包版本偏老会觉得是配置错了。我在 repo 文件里会加一段注释说明用途和优先级顺序，成本很低，收益很高。

第五，物理光驱挂载时注意介质在位。用fstab自动挂载物理光驱的机器，如果开机时光盘不在位，可能卡在启动阶段。这类场景我建议noauto，需要时手动挂，别为了省一次mount冒启动失败的风险。

8. 关于重复配置这件事，我的实际做法

我现在做源配置基本是脚本化的：一个脚本负责挂 ISO、建挂载点、写两个本地源 repo 文件、清缓存、验证；另一个脚本负责按环境变量替换镜像站域名生成镜像源 repo 文件。两个脚本加起来不到一百行，但把每次交付的手工操作压到了两条命令。

这么做的原因很实际：手写 repo 文件的时候，最容易错的地方不是逻辑，是拼写。AppStream写成Appstream、file:///少一个斜杠、$basearch写成$baserach，这些错误肉眼扫一遍看不出来，跑起来才报错。脚本化之后这类错误一次都没有了，因为路径是固定的。

另外提醒一句，本地源和镜像源这两套配置不是二选一的关系，实际生产中经常是同时存在的。本地源保证"任何情况下都能装基础包"，镜像源保证"能拿到更新的版本和更多的软件"。把优先级设计好，两者配合起来比单独用任何一个都舒服得多。唯一要守住的原则是版本一致性——同一个仓库族不要跨越两个不同的小版本来源，这条守住了，剩下的都是参数调整的活。