简介CentOS 7.9离线镜像源是一份适用于无互联网环境的企业级Linux系统安装与更新工具包面向系统运维、实施工程师及需要本地化软件仓库的团队。压缩包共150个文件大小155.55MB核心为143个rpm安装包配合3个gz与3个bz2压缩的元数据及1个xml索引文件可完整支撑YUM仓库的建立与依赖解析。镜像内部涵盖repodata元数据、x86_64架构软件包以及kernel-ml、ansible、ceph等常用组件说明该镜像源已预先集成多类运维场景所需软件。已有1834人学习下载适合在离线或内网环境中快速搭建本地YUM源实现批量安装、更新与版本管控。使用时可结合--disablerepo/--enablerepo切换仓库并注意包版本兼容性与定期备份以便获得安全稳定的系统运维基础。 接到过不少需求都是同一个套路生产网段与公网隔离yum 源一断装个 nginx 都费劲。CentOS 7.9 的离线镜像源说白了就是在内网搭一个“只要局域网能通就能yum install一切”的仓库。这篇文章就把我从同步镜像、生成 repodata、部署 Nginx、到客户端配置和踩坑排查的全过程写出来给准备做离线源或者正被内网环境折磨的朋友一份可以直接抄作业的参考。1. 为什么一定要靠自己搭离线源1.1 什么场景下绕不开这个活先别急着敲命令得先搞清楚你的环境到底卡在哪一环。我在实际项目里见过几类最常见的诉求核心生产网和互联网物理隔离服务器只开放内网端口运维想装tcpdump、vim、lsof这类基础工具都只能靠 RPM 包一路手动传依赖。安全审计要求不允许生产节点直接访问公网也不允许从外部下载未经验证的二进制所有软件包必须从内部统一来源分发。临时大规模交付几十台新机器要批量装 agent、装系统补丁每台都去外网拉包既慢又不稳定还容易污染机房出口带宽。这三种场景的共性就是yum 需要一个稳定的、可控的、可以随时断网复用的软件源。你从外网下载再手动rpm -ivh一次两次还能忍一旦涉及批量环境没有离线源就是灾难。1.2 离线源的构成没你想的那么玄乎所谓“离线镜像源”不是把整张系统 ISO 扔内网就算完事。它的本质是两件事一是仓库数据RPM 包 repodata 元数据二是分发通道HTTP/FTP 服务。客户端通过baseurl指向内网的这个 HTTP 服务然后 yum 就能像访问公网源一样解析依赖、校验签名、正常安装。我通常把它拆成三层来理解层次内容说明软件仓库base、extras、updates、epel等具体的 RPM 包以及repodata/repomd.xml元数据同步工具rsync、reposync、wget从上游镜像站同步库存到本地目录服务端Nginx / Apache / Caddy将本地目录变成可通过 HTTP 访问的源地址CentOS 7.9 在 2024 年 6 月 30 日已经 EOL生命周期结束官方 mirror 仓库已经整体迁移到了 vault。所以你在公网拉包的时候到底是拉mirror.centos.org的常规目录还是拉vault.centos.org的归档目录要提前想清楚。我的建议是直接以 vault 作为最终稳定源因为常规 mirror 链接随时可能被清掉或者变慢vault 是归档地址反而更适合长期离线快照。1.3 先算账磁盘、带宽和目录规划别一上来就全量同步先把规模估算一下。CentOS 7 的仓库如果只保留x86_64架构base加updates加extras加起来大概 10GB 左右如果再带上epel又是 10GB 起步。debuginfo、source 这种目录动辄几十 GB内网场景基本用不上同步时要主动排除。服务器磁盘至少预留 50GB别卡在 30GB 这种尴尬位置。同步是个长时间任务建议放在/data/centos-mirror这类独立挂载目录下别放根分区否则后续扩容很麻烦。带宽方面如果是千兆内网同步一晚上也能完成如果上游源带宽有限那就用rsync断点续传分几次拉完。2. 在公网机器上把仓库同步下来2.1 先把工具备齐否则后面全卡住同步过程要用到yum-utils提供reposync、createrepo生成元数据、rsync增量同步、nginx作为内网分发服务。如果你手头这台机器能上网直接yum install -y yum-utils createrepo rsync nginx如果你这台“公网代理机”本身也处于受限网络那就用另一台能联网的虚拟机下载这几个 RPM 和依赖用rpm -Uvh *.rpm手动装一遍。我在现场就遇到过连yum-utils都装不上的蛋疼情况所以这句话不是废话。2.2 用 reposync 还是 rsync我的选择同步 CentOS 官方仓库有两个流派reposync和rsync。我的经验是同步 CentOS 基础仓库用rsync更好因为上游 mirror 已经维护好了完整的repodata直接同步就可以用不需要本地再生成。同步 EPEL、自定义仓库用reposync更灵活它直接按 yum 仓库定义去拉包到本地后自己跑createrepo。先看标准做法。比如同步 CentOS 7.9 的base、extras、updates直接指定架构为x86_64BASE_URLhttps://vault.centos.org/7.9.2009 LOCAL_DIR/data/centos-mirror/7 rsync -avH --delete \ --exclude*.src.rpm \ --excludedebug/ \ --excludesource/ \ --excludeaarch64/ \ --excludei386/ \ --excludeppc64/ \ --excludeppc64le/ \ ${BASE_URL}/os/x86_64/ ${LOCAL_DIR}/os/x86_64/参数解释一下-a归档模式保留权限和时间戳-H保留硬链接RPM 仓库里不少包有硬链接这个参数能省不少空间--delete保证本地和上游完全一致避免残留过期包。extras和updates同理把路径里的os换成extras和updates即可。这里我特意排除了其他架构内网基本全是 x86_64没必要浪费磁盘。2.3 EPEL 仓库的同步姿势EPEL 不能直接从 vault 拉它有自己的源地址。我这里演示的是阿里云镜像站的同步方式因为在国内速度通常是最稳的。如果你在海外直接用https://dl.fedoraproject.org/pub/epel/7也可以LOCAL_EPEL/data/centos-mirror/epel/7 rsync -avH --delete \ --exclude*.src.rpm \ --excludedebug/ \ --excludeaarch64/ \ --excludeppc64/ \ rsync://mirrors.aliyun.com/epel/7/x86_64/ ${LOCAL_EPEL}/x86_64/注意EPEL 的x86_64目录下面还套了一个repodata子目录同步下来以后一般不用重新生成。但如果下游 yum 报repomd.xml校验错误多半是同步不完整重新跑一遍rsync即可。2.4 拉完之后等 repodata 确认无误再停手同步完 CentOS 仓库之后建议检查一下关键文件是否存在ls -lh /data/centos-mirror/7/os/x86_64/repodata/repomd.xmlrepomd.xml是 yum 解析仓库的核心入口客户端发起yum makecache时第一步就是请求这个文件。没有它后面全白搭。如果你后面是把这套东西继续往内网搬运那搬运过程中千万别漏掉隐藏目录或软链接。我之前遇到过把repodata目录搬没了、客户端反复报 404 的低级错误排查了半小时才发现是 tar 打包时没带隐藏属性。3. 用 Nginx 把本地目录变成可访问的软件源3.1 目录结构规划好后面省心同步下来的目录我习惯统一规划成这样/data/centos-mirror/ ├── 7/ │ ├── os/ │ │ └── x86_64/ │ │ ├── Packages/ │ │ └── repodata/ │ ├── extras/ │ │ └── x86_64/ │ └── updates/ │ └── x86_64/ └── epel/ └── 7/ └── x86_64/这种结构对应客户端的仓库定义非常直观baseurlhttp://192.168.1.10/centos/7/os/x86_64/。前后端都能少很多心智负担。3.2 最小可用的 Nginx 配置在/etc/nginx/conf.d/centos-repo.conf里写一个 server 块server { listen 80; server_name mirrors.local; autoindex on; autoindex_exact_size off; autoindex_localtime on; root /data/centos-mirror; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/repo-access.log main; error_log /var/log/nginx/repo-error.log; }autoindex on是必须的否则客户端在解析仓库时访问目录会拿到 403。try_files确保文件不存在时返回 404 而不是把请求转发到后端。配置完重启nginx -t systemctl restart nginx systemctl enable nginx3.3 验证服务端是否就绪用curl检查关键路径能不能直接访问这一步能省掉后面排查客户端时报错的时间curl -I http://127.0.0.1/centos/7/os/x86_64/repodata/repomd.xml curl -I http://127.0.0.1/epel/7/x86_64/repodata/repomd.xml返回200 OK就说明服务和文件路径都没问题。如果这里输出 403查 selinux 和目录权限如果 404查 root 和目录层级。4. 客户端 yum 配置让每台 7.9 都能用上离线源4.1 备份原有 repo 并禁用 fastestmirror客户端机器上先在/etc/yum.repos.d/下面建一个备份目录把所有官方源文件挪走mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/这一步很多人会忽略导致后面yum makecache同时在连公网源和本地源慢不说报错还很难看。另外CentOS 7 默认装了yum-plugin-fastestmirror它会在每次 yum 操作时去探测最快镜像。内网环境下这个插件纯属帮倒忙等待时间长还很智障。直接禁用sed -i s/enabled1/enabled0/ /etc/yum/pluginconf.d/fastestmirror.conf4.2 一个完整的 local.repo 长这样在/etc/yum.repos.d/local.repo里写入以下内容这里把192.168.1.10替换成你的离线源服务器地址[base] nameCentOS-7 - Base baseurlhttp://192.168.1.10/centos/7/os/x86_64/ gpgcheck0 enabled1 [updates] nameCentOS-7 - Updates baseurlhttp://192.168.1.10/centos/7/updates/x86_64/ gpgcheck0 enabled1 [extras] nameCentOS-7 - Extras baseurlhttp://192.168.1.10/centos/7/extras/x86_64/ gpgcheck0 enabled1 [epel] nameEPEL-7 baseurlhttp://192.168.1.10/epel/7/x86_64/ gpgcheck0 enabled14.3 gpgcheck 到底开不开很多离线源教程直接gpgcheck0图省事。我的建议是如果内网安全要求高且你保留了上游的 GPG keygpgcheck1更稳妥。CentOS 7 的 key 位置在/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7EPEL 的 key 在RPM-GPG-KEY-EPEL-7。如果是临时搭一把、后面就销毁的交付环境gpgcheck0能省掉导入 key 的环节也不影响功能。我一般场景是gpgcheck0然后把上游 key 备份到内网机器理由是离线源本身就是从可信渠道同步进来的包完整性在传输层已经有一定保障。当然长期生产环境还是建议把 key 一起纳入管理。4.4 客户端验证一把到位在客户端执行yum clean all yum makecache看到base、updates、epel仓库都显示metadata successfully downloaded就算成功。再随便装一个包试试yum install -y htop能装上说明整条链路是通的。如果 makecache 阶段报错看下一步的排查表。5. 实操中的坑和排查经验5.1 高频问题速查表我把现场频率最高的几个问题整理成表格基本能覆盖 90% 的报错场景现象可能原因解决方式Could not resolve host客户端 DNS 不通或 baseurl 配了域名改用 IP先ping 192.168.1.10验证网络404 Not Found访问 repomd.xml目录层级不对或 repodata 缺失curl 检查 URL 路径同步时确认repodata目录没丢[Errno 14] HTTP Error 403nginx 配置里没开autoindex打开autoindex on并重启 nginxPeer certificate cannot be authenticatedbaseurl 用了 https 但证书不受信任统一改用 http 或把 https 证书加信任Package does not match intended download同步过程中 RPM 包损坏重新 rsync或删除对应包后单独拉取Could not open/read repomd.xml这个目录下不是仓库根目录确认路径是否指向包含repodata的层级Transaction check error客户端缺 gpg key 或包依赖冲突rpm --import导入 key清理yum clean all后重试Error: Nothing to do仓库里压根没有这个包名检查源里是否包含 epel或包名大小写5.2 独家避坑经验第一同步完成后不要急着把上游源删掉。离线源搭建是长期工程后续补丁和软件包变更需要一个“同步窗口”。我在服务器上留了一个 cron 脚本每个月最后一天凌晨自动从 vault 增量同步一次再执行createrepo --update。这样内网机的yum update可以一直跟着补丁节奏走。第二CentOS 7 的源别指望用 ISO 版本直接替代。系统装完自带了 BaseOS 和 AppStream 的仓库定义但离线场景下基 OS 里的软件包很少不补齐updates和extras的话yum install很快会遇到依赖缺失。所以还是老老实实同步完整仓库。第三客户端执行yum clean all的频率要控制住。离线源的仓库元数据是不会频繁变化的除非你更新了服务端。没必要每次操作都 makecache建议在服务端同步完后写一个小脚本让客户端统一yum clean all yum makecache一次其余时间直接用缓存即可。5.3 内网环境的一些额外注意如果客户端有某些商业软件在做授权绑定会用到/etc/machine-id或者hostid这类机器标识那和 yum 源搭建没直接关系不用混在一起排查。真正容易混的其实是两个点客户端配置了代理导致内网 http 请求被代理转发出去然后超时。这种情况下curl http://192.168.1.10是通的但 yum 永远报错。干脆在 yum 配置里显式忽略代理。服务器防火墙只放行了 80/443 端口Nginx 偏偏监听 8081。这种“服务正常但外部访问不了”的问题第一反应就是ss -lntp | grep nginx确认监听端口再查防火墙。# 确保 80 端口在 firewalld 中放行 firewall-cmd --permanent --add-port80/tcp firewall-cmd --reload结尾再说几句离线镜像源这活看起来简单实际做起来细节不少。我个人体会是目录结构、同步策略、客户端 repo 定义这三样一旦定下来就别轻易改否则内网几十台机器的排查成本会呈指数增长。运维环境里最怕的不是没有方案而是每个环境都有一套自己的“临时方案”。如果你后续准备在离线源上做更多文章可以考虑把这些事顺手一起做了把epel里的常用包单独导出一个最小包清单、定期对 repodata 做一次哈希校验、再把源服务器的 Nginx 访问日志接入监控。这样整个内网分发体系就不再是个一次性工程而是可持续维护的基础设施。最后分享一个小技巧同步好的仓库目录用tar打一个快照放在另一块硬盘上。万一源服务器磁盘坏了拿到一台新机器解压再起个 Nginx半小时内就能恢复整套源服务。这个备份动作虽然笨但关键时刻真的能救命。本文还有配套的精品资源点击获取 CentOS 7.9离线yum源搭建实战：内网仓库同步与Nginx配置指南
简介CentOS 7.9离线镜像源是一份适用于无互联网环境的企业级Linux系统安装与更新工具包面向系统运维、实施工程师及需要本地化软件仓库的团队。压缩包共150个文件大小155.55MB核心为143个rpm安装包配合3个gz与3个bz2压缩的元数据及1个xml索引文件可完整支撑YUM仓库的建立与依赖解析。镜像内部涵盖repodata元数据、x86_64架构软件包以及kernel-ml、ansible、ceph等常用组件说明该镜像源已预先集成多类运维场景所需软件。已有1834人学习下载适合在离线或内网环境中快速搭建本地YUM源实现批量安装、更新与版本管控。使用时可结合--disablerepo/--enablerepo切换仓库并注意包版本兼容性与定期备份以便获得安全稳定的系统运维基础。 接到过不少需求都是同一个套路生产网段与公网隔离yum 源一断装个 nginx 都费劲。CentOS 7.9 的离线镜像源说白了就是在内网搭一个“只要局域网能通就能yum install一切”的仓库。这篇文章就把我从同步镜像、生成 repodata、部署 Nginx、到客户端配置和踩坑排查的全过程写出来给准备做离线源或者正被内网环境折磨的朋友一份可以直接抄作业的参考。1. 为什么一定要靠自己搭离线源1.1 什么场景下绕不开这个活先别急着敲命令得先搞清楚你的环境到底卡在哪一环。我在实际项目里见过几类最常见的诉求核心生产网和互联网物理隔离服务器只开放内网端口运维想装tcpdump、vim、lsof这类基础工具都只能靠 RPM 包一路手动传依赖。安全审计要求不允许生产节点直接访问公网也不允许从外部下载未经验证的二进制所有软件包必须从内部统一来源分发。临时大规模交付几十台新机器要批量装 agent、装系统补丁每台都去外网拉包既慢又不稳定还容易污染机房出口带宽。这三种场景的共性就是yum 需要一个稳定的、可控的、可以随时断网复用的软件源。你从外网下载再手动rpm -ivh一次两次还能忍一旦涉及批量环境没有离线源就是灾难。1.2 离线源的构成没你想的那么玄乎所谓“离线镜像源”不是把整张系统 ISO 扔内网就算完事。它的本质是两件事一是仓库数据RPM 包 repodata 元数据二是分发通道HTTP/FTP 服务。客户端通过baseurl指向内网的这个 HTTP 服务然后 yum 就能像访问公网源一样解析依赖、校验签名、正常安装。我通常把它拆成三层来理解层次内容说明软件仓库base、extras、updates、epel等具体的 RPM 包以及repodata/repomd.xml元数据同步工具rsync、reposync、wget从上游镜像站同步库存到本地目录服务端Nginx / Apache / Caddy将本地目录变成可通过 HTTP 访问的源地址CentOS 7.9 在 2024 年 6 月 30 日已经 EOL生命周期结束官方 mirror 仓库已经整体迁移到了 vault。所以你在公网拉包的时候到底是拉mirror.centos.org的常规目录还是拉vault.centos.org的归档目录要提前想清楚。我的建议是直接以 vault 作为最终稳定源因为常规 mirror 链接随时可能被清掉或者变慢vault 是归档地址反而更适合长期离线快照。1.3 先算账磁盘、带宽和目录规划别一上来就全量同步先把规模估算一下。CentOS 7 的仓库如果只保留x86_64架构base加updates加extras加起来大概 10GB 左右如果再带上epel又是 10GB 起步。debuginfo、source 这种目录动辄几十 GB内网场景基本用不上同步时要主动排除。服务器磁盘至少预留 50GB别卡在 30GB 这种尴尬位置。同步是个长时间任务建议放在/data/centos-mirror这类独立挂载目录下别放根分区否则后续扩容很麻烦。带宽方面如果是千兆内网同步一晚上也能完成如果上游源带宽有限那就用rsync断点续传分几次拉完。2. 在公网机器上把仓库同步下来2.1 先把工具备齐否则后面全卡住同步过程要用到yum-utils提供reposync、createrepo生成元数据、rsync增量同步、nginx作为内网分发服务。如果你手头这台机器能上网直接yum install -y yum-utils createrepo rsync nginx如果你这台“公网代理机”本身也处于受限网络那就用另一台能联网的虚拟机下载这几个 RPM 和依赖用rpm -Uvh *.rpm手动装一遍。我在现场就遇到过连yum-utils都装不上的蛋疼情况所以这句话不是废话。2.2 用 reposync 还是 rsync我的选择同步 CentOS 官方仓库有两个流派reposync和rsync。我的经验是同步 CentOS 基础仓库用rsync更好因为上游 mirror 已经维护好了完整的repodata直接同步就可以用不需要本地再生成。同步 EPEL、自定义仓库用reposync更灵活它直接按 yum 仓库定义去拉包到本地后自己跑createrepo。先看标准做法。比如同步 CentOS 7.9 的base、extras、updates直接指定架构为x86_64BASE_URLhttps://vault.centos.org/7.9.2009 LOCAL_DIR/data/centos-mirror/7 rsync -avH --delete \ --exclude*.src.rpm \ --excludedebug/ \ --excludesource/ \ --excludeaarch64/ \ --excludei386/ \ --excludeppc64/ \ --excludeppc64le/ \ ${BASE_URL}/os/x86_64/ ${LOCAL_DIR}/os/x86_64/参数解释一下-a归档模式保留权限和时间戳-H保留硬链接RPM 仓库里不少包有硬链接这个参数能省不少空间--delete保证本地和上游完全一致避免残留过期包。extras和updates同理把路径里的os换成extras和updates即可。这里我特意排除了其他架构内网基本全是 x86_64没必要浪费磁盘。2.3 EPEL 仓库的同步姿势EPEL 不能直接从 vault 拉它有自己的源地址。我这里演示的是阿里云镜像站的同步方式因为在国内速度通常是最稳的。如果你在海外直接用https://dl.fedoraproject.org/pub/epel/7也可以LOCAL_EPEL/data/centos-mirror/epel/7 rsync -avH --delete \ --exclude*.src.rpm \ --excludedebug/ \ --excludeaarch64/ \ --excludeppc64/ \ rsync://mirrors.aliyun.com/epel/7/x86_64/ ${LOCAL_EPEL}/x86_64/注意EPEL 的x86_64目录下面还套了一个repodata子目录同步下来以后一般不用重新生成。但如果下游 yum 报repomd.xml校验错误多半是同步不完整重新跑一遍rsync即可。2.4 拉完之后等 repodata 确认无误再停手同步完 CentOS 仓库之后建议检查一下关键文件是否存在ls -lh /data/centos-mirror/7/os/x86_64/repodata/repomd.xmlrepomd.xml是 yum 解析仓库的核心入口客户端发起yum makecache时第一步就是请求这个文件。没有它后面全白搭。如果你后面是把这套东西继续往内网搬运那搬运过程中千万别漏掉隐藏目录或软链接。我之前遇到过把repodata目录搬没了、客户端反复报 404 的低级错误排查了半小时才发现是 tar 打包时没带隐藏属性。3. 用 Nginx 把本地目录变成可访问的软件源3.1 目录结构规划好后面省心同步下来的目录我习惯统一规划成这样/data/centos-mirror/ ├── 7/ │ ├── os/ │ │ └── x86_64/ │ │ ├── Packages/ │ │ └── repodata/ │ ├── extras/ │ │ └── x86_64/ │ └── updates/ │ └── x86_64/ └── epel/ └── 7/ └── x86_64/这种结构对应客户端的仓库定义非常直观baseurlhttp://192.168.1.10/centos/7/os/x86_64/。前后端都能少很多心智负担。3.2 最小可用的 Nginx 配置在/etc/nginx/conf.d/centos-repo.conf里写一个 server 块server { listen 80; server_name mirrors.local; autoindex on; autoindex_exact_size off; autoindex_localtime on; root /data/centos-mirror; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/repo-access.log main; error_log /var/log/nginx/repo-error.log; }autoindex on是必须的否则客户端在解析仓库时访问目录会拿到 403。try_files确保文件不存在时返回 404 而不是把请求转发到后端。配置完重启nginx -t systemctl restart nginx systemctl enable nginx3.3 验证服务端是否就绪用curl检查关键路径能不能直接访问这一步能省掉后面排查客户端时报错的时间curl -I http://127.0.0.1/centos/7/os/x86_64/repodata/repomd.xml curl -I http://127.0.0.1/epel/7/x86_64/repodata/repomd.xml返回200 OK就说明服务和文件路径都没问题。如果这里输出 403查 selinux 和目录权限如果 404查 root 和目录层级。4. 客户端 yum 配置让每台 7.9 都能用上离线源4.1 备份原有 repo 并禁用 fastestmirror客户端机器上先在/etc/yum.repos.d/下面建一个备份目录把所有官方源文件挪走mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/这一步很多人会忽略导致后面yum makecache同时在连公网源和本地源慢不说报错还很难看。另外CentOS 7 默认装了yum-plugin-fastestmirror它会在每次 yum 操作时去探测最快镜像。内网环境下这个插件纯属帮倒忙等待时间长还很智障。直接禁用sed -i s/enabled1/enabled0/ /etc/yum/pluginconf.d/fastestmirror.conf4.2 一个完整的 local.repo 长这样在/etc/yum.repos.d/local.repo里写入以下内容这里把192.168.1.10替换成你的离线源服务器地址[base] nameCentOS-7 - Base baseurlhttp://192.168.1.10/centos/7/os/x86_64/ gpgcheck0 enabled1 [updates] nameCentOS-7 - Updates baseurlhttp://192.168.1.10/centos/7/updates/x86_64/ gpgcheck0 enabled1 [extras] nameCentOS-7 - Extras baseurlhttp://192.168.1.10/centos/7/extras/x86_64/ gpgcheck0 enabled1 [epel] nameEPEL-7 baseurlhttp://192.168.1.10/epel/7/x86_64/ gpgcheck0 enabled14.3 gpgcheck 到底开不开很多离线源教程直接gpgcheck0图省事。我的建议是如果内网安全要求高且你保留了上游的 GPG keygpgcheck1更稳妥。CentOS 7 的 key 位置在/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7EPEL 的 key 在RPM-GPG-KEY-EPEL-7。如果是临时搭一把、后面就销毁的交付环境gpgcheck0能省掉导入 key 的环节也不影响功能。我一般场景是gpgcheck0然后把上游 key 备份到内网机器理由是离线源本身就是从可信渠道同步进来的包完整性在传输层已经有一定保障。当然长期生产环境还是建议把 key 一起纳入管理。4.4 客户端验证一把到位在客户端执行yum clean all yum makecache看到base、updates、epel仓库都显示metadata successfully downloaded就算成功。再随便装一个包试试yum install -y htop能装上说明整条链路是通的。如果 makecache 阶段报错看下一步的排查表。5. 实操中的坑和排查经验5.1 高频问题速查表我把现场频率最高的几个问题整理成表格基本能覆盖 90% 的报错场景现象可能原因解决方式Could not resolve host客户端 DNS 不通或 baseurl 配了域名改用 IP先ping 192.168.1.10验证网络404 Not Found访问 repomd.xml目录层级不对或 repodata 缺失curl 检查 URL 路径同步时确认repodata目录没丢[Errno 14] HTTP Error 403nginx 配置里没开autoindex打开autoindex on并重启 nginxPeer certificate cannot be authenticatedbaseurl 用了 https 但证书不受信任统一改用 http 或把 https 证书加信任Package does not match intended download同步过程中 RPM 包损坏重新 rsync或删除对应包后单独拉取Could not open/read repomd.xml这个目录下不是仓库根目录确认路径是否指向包含repodata的层级Transaction check error客户端缺 gpg key 或包依赖冲突rpm --import导入 key清理yum clean all后重试Error: Nothing to do仓库里压根没有这个包名检查源里是否包含 epel或包名大小写5.2 独家避坑经验第一同步完成后不要急着把上游源删掉。离线源搭建是长期工程后续补丁和软件包变更需要一个“同步窗口”。我在服务器上留了一个 cron 脚本每个月最后一天凌晨自动从 vault 增量同步一次再执行createrepo --update。这样内网机的yum update可以一直跟着补丁节奏走。第二CentOS 7 的源别指望用 ISO 版本直接替代。系统装完自带了 BaseOS 和 AppStream 的仓库定义但离线场景下基 OS 里的软件包很少不补齐updates和extras的话yum install很快会遇到依赖缺失。所以还是老老实实同步完整仓库。第三客户端执行yum clean all的频率要控制住。离线源的仓库元数据是不会频繁变化的除非你更新了服务端。没必要每次操作都 makecache建议在服务端同步完后写一个小脚本让客户端统一yum clean all yum makecache一次其余时间直接用缓存即可。5.3 内网环境的一些额外注意如果客户端有某些商业软件在做授权绑定会用到/etc/machine-id或者hostid这类机器标识那和 yum 源搭建没直接关系不用混在一起排查。真正容易混的其实是两个点客户端配置了代理导致内网 http 请求被代理转发出去然后超时。这种情况下curl http://192.168.1.10是通的但 yum 永远报错。干脆在 yum 配置里显式忽略代理。服务器防火墙只放行了 80/443 端口Nginx 偏偏监听 8081。这种“服务正常但外部访问不了”的问题第一反应就是ss -lntp | grep nginx确认监听端口再查防火墙。# 确保 80 端口在 firewalld 中放行 firewall-cmd --permanent --add-port80/tcp firewall-cmd --reload结尾再说几句离线镜像源这活看起来简单实际做起来细节不少。我个人体会是目录结构、同步策略、客户端 repo 定义这三样一旦定下来就别轻易改否则内网几十台机器的排查成本会呈指数增长。运维环境里最怕的不是没有方案而是每个环境都有一套自己的“临时方案”。如果你后续准备在离线源上做更多文章可以考虑把这些事顺手一起做了把epel里的常用包单独导出一个最小包清单、定期对 repodata 做一次哈希校验、再把源服务器的 Nginx 访问日志接入监控。这样整个内网分发体系就不再是个一次性工程而是可持续维护的基础设施。最后分享一个小技巧同步好的仓库目录用tar打一个快照放在另一块硬盘上。万一源服务器磁盘坏了拿到一台新机器解压再起个 Nginx半小时内就能恢复整套源服务。这个备份动作虽然笨但关键时刻真的能救命。本文还有配套的精品资源点击获取