内网离线环境搭建本地YUM源：从RPM收集到客户端配置

接到一个任务新到的一批服务器放在内网应用明天必须上线可现在连yum install都跑不通报错信息要么是Could not resolve host要么是Cannot find a valid baseurl for repo: base/7/x86_64。手头没有外网也没有提前准备离线安装包那一刻的酸爽做过离线交付的人都懂。这也是我写下这篇内网离线环境搭建本地YUM源的由来——把一套可以在没有外网的环境下自给自足的仓库方案完完整整拆给你看。这套方案解决的是内网机器无法访问外部镜像站时如何利用一台能与外网通信或拥有离线介质的机器把需要的 RPM 包收集起来在内部搭建一个软件仓库让所有内网机器通过局域网快速安装、升级软件。适合的场景包括机房隔离区、涉密内网、云上私有网络以及偶尔断外网的办公环境。无论你是运维、实施工程师还是自己折腾私有化部署的开发者这篇文章都能帮你少走不少弯路。1. 内网部署的痛点和YUM源的定位1.1 没有外网时yum 为什么直接“罢工”YUM以及新版系统上的 DNF本身不是一个仓库它只是一个“搬运工”。你执行yum install nginx时系统会先去读取/etc/yum.repos.d/下的仓库配置文件找到baseurl或mirrorlist然后向对应的地址发起请求下载仓库元数据repodata/repomd.xml再根据元数据判断哪个包满足条件、依赖有哪些最后下载并安装。一旦内网机器和外网隔离问题就出在第一步它根本联系不上mirror.centos.org或阿里云镜像站自然就报错。很多人第一反应是“手动下载 rpm 包再过去装”但这只适合一两个软件一旦涉及几十个依赖包手动解依赖就是灾难。1.2 本地YUM源在整个架构中的位置本地YUM源的核心思路是让内网中的一台机器充当“内部镜像站”把所有需要的 RPM 包集中放在它的磁盘上用createrepo生成索引再通过 HTTP、NFS 或本地目录方式共享给其他机器。客户端只需把.repo文件指向这台内部服务器之后的所有yum install、yum update操作就和有外网时一样只是数据源变成了局域网。从架构上看它承担了三个角色包文件存储放 RPM、元数据生成器createrepo 扫描依赖关系、文件分发服务HTTP 最通用。这三个角色可以都在一台机器上也可以拆开但绝大多数场景一台就够。举个直观的例子内部有 50 台机器都要装同一个监控代理没有本地源时你要么挨个拷包要么在每台机器上挂载光盘有本地源后一条yum install -y agent全部搞定速度还比外网快得多。2. 软件包从哪来离线获取RPM包的三种可靠渠道搭建本地仓库的第一步不是建目录而是先解决“包从哪来”。我见过很多人一上来就createrepo结果目录是空的白白浪费时间。根据网络条件和软件需求主要有三种渠道实际使用可以交叉配合。渠道适合场景优点缺点系统 ISO 镜像刚需基础包、不想联网官方来源、签名完整、一次性获取只有系统发行版自带包版本固定外网机器 reposync 同步需要全量/增量复制官方源和官方源结构一致、更新方便需要有外网的机器且磁盘占用大按需拉取 repotrack/yumdownloader只部署特定应用、依赖有限体积小、目标精准每次新装应用都要重新拉包2.1 渠道一从系统 ISO 里提取 Packages这个方法最简单也最适合“还没有任何源”的冷启动。CentOS 7 的 ISO 里自带Packages/目录里面有上千个 RPM 包覆盖了系统安装和维护需要的绝大多数基础组件。mount -o loop /path/to/CentOS-7-x86_64-Minimal-1810.iso /mnt/iso mkdir -p /data/yum/centos/7/os/x86_64 cp -av /mnt/iso/Packages/*.rpm /data/yum/centos/7/os/x86_64/需要注意Minimal ISO 的包数量比 DVD ISO 少很多如果内网机器可能安装各种软件建议直接用完整 DVD ISO 或者 Everything ISO。拷贝完后ISO 自带的.discinfo、repodata不要直接复制因为后面要自己重新生成元数据旧的索引不一定匹配你的目录位置。2.2 渠道二利用有外网的机器做全量同步如果你有一台能访问外网、系统版本和目标内网一致的机器那是最舒服的。使用reposync可以把官方源的整个仓库包括 base、extras、updates甚至 EPEL镜像到本地。这个工具属于yum-utils包先安装它yum install -y yum-utils createrepo mkdir -p /data/yum/centos/7/os/x86_64 reposync -p /data/yum/centos/7/os/x86_64 --repoidbase --download-metadata--download-metadata会连官方源里的repomd.xml等元数据也同步下来但我的习惯是同步完后仍然自己执行一次createrepo确保索引绝对干净。全量同步最大的问题是体积base 仓库全量下载通常就是 3~10GBupdates 累计更夸张。建议先用--newest-only只保留每个包的最新版本配合--delete删除本地已失效的旧版本能省掉大量磁盘空间。reposync -n -p /data/yum/centos/7/os/x86_64 --repoidbase --download-metadata --delete2.3 渠道三按需拉取只下载需要的 RPM如果只是部署一个 nginx、一套 Java 环境没必要同步整个仓库。按需拉取更高效。yumdownloader和repotrack都可以做这件事区别是yumdownloader --resolve会解析依赖并下载但不会下载目标机器上已经安装过的包repotrack则会把你指定的包及其全部依赖包括已安装的都拉下来更适合离线环境直接搬运。# 在有外网的机器上 yumdownloader --resolve --destdir/tmp/rpms nginx # 或者 repotrack nginx -p /tmp/rpms我推荐在离线交付场景下用repotrack。因为它把所有依赖都打全了拷贝到内网后不会出现“装 A 时报缺少 B装 B 时报缺少 C”的连环缺依赖问题。缺点是文件数偏多不过这年头磁盘不值钱省心更重要。3. 仓库侧搭建createrepo、Web服务与文件分发3.1 createrepo 到底做了什么把 RPM 包放进目录只是第一步YUM 并不知道这个目录里有什么。createrepo会扫描目录下所有 RPM 的名称、版本、架构、依赖关系、校验和生成一组 XML 元数据集中放在repodata/目录下。客户端yum拿到这些元数据后才能在本地快速计算依赖关系、做安装决策。打个比方RPM 包是货架上的商品createrepo生成的repomd.xml就是商品目录和条码索引没有这个索引客户端根本不知道货架上有什么。仓库目录建好后执行# 安装 createrepo如果还没有 yum install -y createrepo cd /data/yum/centos/7/os/x86_64 createrepo .执行完会看到目录下多出repodata/里面是repomd.xml以及一堆*-primary.xml.gz、*-filelists.xml.gz文件。第一次扫描会比较慢包多的时候可能十几分钟属于正常现象。3.2 用 HTTP 还是 NFS 还是本地目录仓库建好后必须决定“其他机器怎么访问”。我把三种方案对比一下分发方案配置难度支持客户端数量典型场景HTTPhttpd/nginx低不限制最好用最通用强烈推荐FTP中多旧环境不推荐新用NFS低受并发限制小机房、管理节点一体化本地目录直接挂载低仅单机自己这台机器自己用最推荐的还是 HTTP。原因很简单NFS 依赖内核态协议客户端安全性、权限配置都有讲究HTTP 只需要保证端口通所有有网卡的机器都能访问。以后如果要做负载均衡HTTP 也更容易扩展。安装并配置 httpdyum install -y httpd # 把仓库目录软链到 httpd 的默认站点目录 ln -s /data/yum /var/www/html/yum systemctl enable --now httpd验证方式很直接——在仓库本机执行curl -I http://127.0.0.1/yum/centos/7/os/x86_64/repodata/repomd.xml只要返回 200说明 HTTP 分发已经通了。这里有个细节如果你直接cp -r到/var/www/html/而不是用软链接后续同步软件包时容易忘记同步路径软链接可以避免这个坑但要注意 SELinux 的标签问题见第 5 章。3.3 防火墙和开机自启内网环境经常有安全基线要求防火墙默认开着。别让 httpd 启动了半天客户端还是连不上。放行 80 端口firewall-cmd --permanent --add-servicehttp firewall-cmd --reload如果你跑的是 nginx 且用了非默认端口比如 8080记得把对应端口放行。新手最容易漏掉这一条——包也放到位了、createrepo 也执行了就是客户端连不上一查全是防火墙拦在中间。4. 客户端接入repo配置、缓存清除与GPG校验细节4.1 一个可用的 .repo 文件长什么样仓库端准备好了现在把内网其他服务器接进来。在客户端/etc/yum.repos.d/下新建一个.repo文件建议用local.repo这样的命名避免和系统自带的CentOS-Base.repo混淆。[local-yum] nameLocal YUM Repository baseurlhttp://192.168.1.100/yum/centos/7/os/x86_64/ enabled1 gpgcheck0保存后执行yum clean all yum makecache yum repolist如果repolist能看到local-yum并且包数量不是 0说明仓库已经通了。这一步成功之后内网机器上的yum install xxx就是从局域网拉包了。4.2 gpgcheck 该开还是该关上面示例里gpgcheck0这是离线内网里最常见的做法。好处是省事坏处是放弃了 RPM 签名校验。对于完全隔离的内网包来源是可控的风险可接受。但如果安全要求高建议你保留gpgcheck1并且导入对应的 GPG keyrpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7然后在.repo文件里指定gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7。这样客户端每次安装都会校验签名防止仓库文件被篡改。注意如果 ISO 或同步源里包签名和 key 不匹配会报GPG key retrieval failed此时需要重新确认 key 来源。4.3 分目录组织基础包和自定义包分开生产环境里我强烈建议把仓库按“官方基础包”和“自研/第三方包”分开建两个目录。例如/data/yum/centos/7/os/x86_64/ # 官方包 /data/yum/internal/rpms/ # 自定义包然后分别执行createrepo客户端里配置两个 repo[base-local] nameBase Local baseurlhttp://192.168.1.100/yum/centos/7/os/x86_64/ enabled1 gpgcheck0 [custom-local] nameCustom Local baseurlhttp://192.168.1.100/yum/internal/rpms/ enabled1 gpgcheck0这样做最大的好处是自研包迭代频繁更新时只需要增量处理custom-local不用动庞大的官方包目录排查问题时也能快速定位是官方依赖问题还是自有包冲突。5. 踩坑实录我从404到依赖地狱的排查链路这一章我想把实际环境里遇到过的典型问题完整走一遍而不是只给结论。看完之后你遇到类似情况心里会更有数。5.1 坑一客户端报 404无法找到 repodata现象yum makecache报错[Errno 14] HTTP Error 404 - Not Found指向的 URL 是.../repodata/repomd.xml。排查过程先在客户端执行curl -I http://192.168.1.100/yum/centos/7/os/x86_64/repodata/repomd.xml如果返回 404说明仓库端这个文件不存在。回到仓库机检查ls -l /data/yum/centos/7/os/x86_64/repodata/发现根本没有这个目录。回想一下原来刚才只是把 RPM 包复制过来了但createrepo没执行或者执行了却因为路径不对跑到了别的目录。根因元数据和包目录不在同一层。createrepo是针对目录递归生成索引的必须在包所在目录里执行或者在命令里明确指定目录。修复createrepo --update /data/yum/centos/7/os/x86_64/客户端再执行yum clean all yum makecache就通过了。5.2 坑二makecache 超时连接被拒绝现象客户端能 ping 通仓库机但yum makecache报Could not connect to 192.168.1.100:80。排查过程检查仓库机systemctl status httpdHTTP 服务正常。检查本机curl http://127.0.0.1/yum/...可以通。在仓库机上执行firewall-cmd --list-all发现services: dhcpv6-client ssh里根本没有http。根因防火墙没有放行 80 端口。内网环境经常有人忘了这一条因为它不影响本机访问只有外部客户端会被挡。修复firewall-cmd --permanent --add-servicehttp firewall-cmd --reload5.3 坑三SELinux 拦截了 httpd 对目录的读权限现象httpd 正常启动也放行了防火墙但客户端一直 403 Forbidden。仓库机本地curl也返回 403。排查过程看/var/log/httpd/error_log出现Permission denied: /data/yum/centos/7/os/x86_64/repodata/repomd.xml。看 SELinux 上下文ls -Z /data/yum/发现目录上下文是default_t而不是httpd_sys_content_t。因为/data是后挂载的数据盘和/var/www/html的默认 SELinux 类型不同httpd 无法读取。修复给仓库目录打上正确的 SELinux 类型标签chcon -R -t httpd_sys_content_t /data/yum如果以后每次重新挂载都会还原上下文用semanage fcontext做持久化或者直接放行布尔值setsebool -P httpd_read_user_content 1生产环境建议用chcon并配合semanage持久化而不是直接关 SELinux。5.4 坑四客户端一直用旧缓存装不到新包现象仓库端明明新增了某个包客户端yum install却提示没有可用包。排查过程在仓库机curl访问元数据确认包文件存在。在客户端执行yum clean all yum makecache再看yum list | grep 包名出现了。根因客户端本地有yum缓存默认在/var/cache/yum/不会自动感知仓库端的元数据变化。只要是仓库端更新了包客户端必须清缓存重建任何人都不例外。习惯每次在仓库端同步完新包后我都习惯让客户端跑一次yum clean all yum makecache或者至少yum clean expire-cache后者更快适合只是想刷新过期元数据的情况。5.5 坑五GPG key 引发安装中断现象内网客户端执行yum install时到一半报错Public key for xxx.rpm is not installed并且整个安装流程终止。排查过程仓库端建仓库时包文件自带了签名信息但客户端gpgcheck1又没有导入对应的 key于是校验失败。修复在客户端导入 key或把.repo的gpgcheck改为0。注意导入了 key 之后仓库目录里的包签名如果和 key 不匹配比如混合了不同发行版的包同样会报错这时候需要检查目录里是否混入了来自其他发行版的 RPM。5.6 坑六依赖拉取不全装包时连环缺依赖现象我曾在离线环境部署一个监控客户端用yumdownloader --resolve下载了十几个包拷贝到内网安装时却报缺少libpcre2。当时非常困惑明明在下载机器上yum localinstall是成功的。根因yumdownloader --resolve的“resolve”是相对于当前系统状态而言的。下载机上已经装了 gcc、openssl 等依赖所以这些包不会被包含在下载列表里但内网机器是全新的缺少这些底层依赖。这就是我后来坚持用repotrack的原因——它会把所有依赖无论是否已安装都完整打出来。修复在内网机器安装时用yum localinstall *.rpm或rpm -ivh *.rpm --nodeps --force后者只适合解决临时依赖不建议作为常规手段。更稳妥的是重新用repotrack全量拉一次。5.7 坑七x86_64 仓库里混入 i686 包现象客户端yum install时经常出现系统尝试安装 i686 版本的依赖包报错内容五花八门。根因同步 base 仓库时官方仓库里同时存在x86_64和i686等不同架构的包如果目录建得不分层createrepo会把所有架构混在一起客户端就可能识别到错误的架构信息。建议目录结构严格分层例如/data/yum/centos/7/os/x86_64/和/data/yum/centos/7/os/i386/不要混放。客户端archx86_64时只会到对应目录找包。如果你的内网机器没有 32 位需求同步时可以用--archx86_64或手动过滤掉 i686 包名。6. 让仓库活起来增量同步与日常维护仓库不是建完就完事的。系统升级补丁、新软件需求、CVE 漏洞修复都需要仓库保持运转。如果你有一台外网机器可以把它作为“中转站”定期把最新包增量同步到内网。6.1 增量同步的完整操作链路在有外网的机器上准备一个同步脚本#!/bin/bash # 增量同步 base, extras, updates 仓库 REPO_BASE/data/yum/centos/7/os/x86_64 reposync -n -p $REPO_BASE --repoidbase --download-metadata --delete reposync -n -p $REPO_BASE --repoidextras --download-metadata --delete reposync -n -p $REPO_BASE --repoidupdates --download-metadata --delete # 重新生成元数据 createrepo --update $REPO_BASE # 打包传输到内网仓库机如果外网机器和内网不通需要导出介质脚本里的-n是--newest-only只保留每个包的最新版本--delete会删掉本地多余但远端已经不存在的旧包。这两个参数配合起来仓库体积不会无限膨胀。createrepo --update只增量更新元数据比全量重建快得多。同步完成后如果外网机器和内网仓库机网络隔离可以通过移动硬盘/光盘把增量包传过去覆盖到目标目录后再次执行createrepo --update。6.2 设置定时任务别让仓库“过期”就算你的内网完全离线也需要定期从某个介质更新补丁。把同步脚本加入 crontab每周跑一次比较合理0 2 * * 0 /usr/local/bin/sync-repo.sh /var/log/sync-repo.log 21更新完仓库之后别忘了客户端侧的操作要么写进机器初始化脚本要么在对所有服务器统一执行yum clean all yum makecache yum check-update这里yum check-update是验证客户端和仓库连通性的好方法。如果它能列出可更新包列表说明整个链路仍然健康。6.3 私有定制包的维护方式自研包我更推荐单独建目录不要和官方包混在一起。每次构建产出 RPM 后cp new-xxx.rpm /data/yum/internal/rpms/ createrepo --update /data/yum/internal/rpms/--update参数非常快即便包不多也值得养成习惯。更新完不需要重启 httpd因为 eshi 仓库服务只是读取文件元数据重新生成后客户端yum makecache就能感知。6.4 不同发行版的兼容提醒这套方法不只适用于 CentOS 7。Rocky Linux、AlmaLinux、CentOS Stream、甚至 Fedora 都能用同样的逻辑只是仓库结构和 GPG key 不同。比如 Rocky 9 的 base 仓库名是baseos同步命令要对应调整仓库底层元数据工具也从createrepo换成了createrepo_c或dnf reposync但思路完全一致。在 Rocky 9 / AlmaLinux 9 上reposync已经集成进dnf插件体系dnf install -y dnf-plugins-core createrepo_c dnf reposync --repoidbaseos --download-metadata -p /data/yum/rocky/9/ createrepo_c /data/yum/rocky/9/baseos我之前帮朋友搭过一套 Rocky 9 的内网源原理和 CentOS 7 一模一样坑也几乎重叠。换发行版只是换命令思维模型是通用的。最后的运维心得这套本地 YUM 源方案我用了很多年从 CentOS 6、7 一直用到 Rocky 9。回头来看最重要的经验就三条第一目录结构一开始就要规划好官方包、扩展包、自定义包分清楚别全堆在一个目录第二任何同步或新增包之后仓库端必须执行createrepo --update客户端必须yum clean all makecache这两步缺一不可第三GPG 和 SELinux 的问题看着小一旦触发就是整条链路阻塞提前配置好远比事后排查省心。如果你只是临时给几台机器装个软件用 ISO 挂载就够了如果是一个长期运行的私有网络建议直接上 HTTP reposync 增量同步的方案。仓库服务本身不复杂但它会伴随你的每一次交付和升级把这套东西打磨好后面的运维会非常顺畅。