离线rpm包及依赖下载全攻略：从yum源解析到内网安装

1. 为什么离线rpm包这个问题值得单独写一篇在一个完全断网的机房或者等保要求极严的内网环境里装软件应该是每个运维都绕不过去的坎。我见过不少同事的日常工作状态就是生产环境不敢乱动测试环境又没法访问外网需要装个MySQL或者Nginx手头却只有一台能上网的笔记本。于是只能开着浏览器一个个敲rpm包的下载页手动搜依赖、点下载运气好的时候二十分钟搞定运气不好依赖套依赖一上午就这么耗没了。我自己最开始也干过这种人肉递归解析依赖的蠢事。后来慢慢摸索出一套比较顺手的离线rpm和依赖包下载方法这里把常用的几条路子和坑都整理出来。这篇文章主要解决三个问题一是怎么快速把一个rpm包以及它牵扯到的所有依赖全部下载到本地二是怎么把这些包安全稳妥地带进离线环境完成安装三是怎么判断下载下来的东西是不是真的够用别再出现装到一半提示缺依赖的尴尬情况。适合看这篇内容的人大概是刚接触Linux的运维新手、需要在内网部署服务的开发同学以及时不时要给客户现场装环境的交付工程师。如果你已经对yum和rpm的基本概念有点了解那操作起来会更顺手但即使你是纯小白跟着命令抄也能跑通。2. 先搞清楚yum、rpm和依赖解析这三者之间的关系在动手下载离线包之前我觉得有必要先花点时间把基础概念理清楚。因为很多人并不是不会敲命令而是不清楚命令背后依赖是怎么算出来的结果下载了一堆包回到内网还是装不上。RPM是Red Hat系LinuxCentOS、Rocky、Fedora这些的软件包格式一个rpm文件本质上就是一个打包好的软件里面带上了安装所需的文件、脚本和元信息。元信息里最关键的一部分就是Requires字段也就是这个包运行所依赖的其他共享库、命令或软件包。比如你要装一个编译好的Nginx它可能依赖libpcre.so.1而libpcre.so.1又由pcre这个rpm包提供pcre本身又可能依赖别的库这就是一条完整的依赖链。yum或者dnf做的事情就是解析这条依赖链在配置好的软件源仓库里找到所有需要的包然后自动安装。在线环境下你感受不到这个过程有多复杂因为yum全帮你做完了。可一旦到了离线环境yum的软件源仓库指向的是网上的镜像站网络不通就什么都装不了。所以我们的核心思路是在一台能联网、并且系统版本和架构跟目标机器一致的机器上提前把目标包以及整条依赖链上的所有rpm文件下载到本地然后带到离线机器去安装。这里有个容易被忽视的前提下载机的发行版、大版本号、架构必须和目标机一致或者非常接近。比如在CentOS 7上用yum下载的依赖拿到Rocky Linux 9上大概率是装不上的因为底层的glibc版本、库路径都变了。很多时候大家抱怨离线装个软件比登天还难根子就在这一步没做对。还有一点需要提前说明rpm本身不解析远程依赖它只是一个打包安装工具。你手动rpm -ivh一个包时它只会检查当前系统里已经装了哪些库缺了就直接报错不会帮你去网上下。想让它自动装依赖必须配合本地repo或者手动把依赖包按顺序喂给它。所以下面的所有方法本质上都是围绕如何把依赖链完整收集起来这件事在展开。3. 五大主流下载离线rpm和依赖包的工具选型对比3.1 yumdownloader轻量级选手适合单独下载指定包yumdownloader是yum-utils工具包里的一个命令作用非常纯粹从yum源里下载指定的rpm文件到当前目录可以指定只下载二进制包或者src源码包还能通过--resolve参数顺带解析并下载依赖。它适合的场景是你只需要某个软件本身的rpm文件依赖可以单独处理或者你明确知道目标机器上已经装了哪些基础依赖不需要整条依赖链冗余下载。因为它的解析能力其实比较有限--resolve只往下分析一层还是递归分析完全取决于yum的行为实践下来它对深层依赖的支持不太稳定。安装方式yum install -y yum-utils下载单个包yumdownloader --resolve nginx这个命令会把nginx和它的直接依赖都拉下来放进当前目录。但它有几个明显短板第一如果nginx依赖AA又依赖B有时候B不会被完整带下来第二它只会解析当前yum源里的依赖关系如果某个依赖只在第三方源里而你又没启用那个源就会提示找不到。3.2 repotrack全依赖链无死角我最推荐的生产环境方案repotrack也是yum-utils包提供的工具但它的行为跟yumdownloader完全不同。官方的描述是download all dependencies for a package也就是把一个包的所有递归依赖全部下载下来一个不漏。它是用Yum的依赖解析引擎去遍历整棵依赖树然后把你需要的所有rpm文件从前到后全部拉取到本地目录非常适合用来准备离线仓库。用法几乎和yumdownloader一样repotrack --archx86_64 nginx后面可以跟-p参数指定下载目录repotrack -p /data/rpm_cache --archx86_64 nginx注意--arch这个参数它可以限制只抓某个架构的包避免把i686、noarch一堆乱七八糟的全部弄下来。不过这里要小心如果一个依赖没有对应架构的包repotrack会报错而不是自动降级这时候可以根据报错信息手工调整。实际体验下来repotrack是这几个工具里对依赖链处理最完整的我准备离线环境基本都是先用它跑一遍再用其他工具补漏。3.3 dnf download新世界玩家的默认选择在CentOS 8、Rocky 8/9、Fedora这些较新的系统上包管理器已经从yum换成了dnfyum命令只是一个兼容性软链接。dnf自带一个download插件不需要额外安装yum-utils就能用。基础用法dnf download nginx这个命令默认只下载指定包本身不解析依赖。加上--resolve后才会把依赖也带下来dnf download --resolve --alldeps nginx--resolve解析依赖并下载--alldeps包括所有依赖连已经安装过的也会拉取在某些版本里这个参数不生效需要留意dnf download最大的好处是它是dnf原生自带的不需要额外装包在离线安装新系统的场景下非常方便。但它也有一个明显短板在部分版本中--resolve只解析直接依赖不能像repotrack那样递归完整收集。所以要备离线依赖时我一般只在老机器上没有repotrack可选的情况下才用它。3.4 yum --downloadonly老Linux玩家熟知的插件方案在yum年代很多教程会教你先安装yum-plugin-downloadonly插件然后通过命令yum install --downloadonly --downloaddir/data/rpm_cache nginx来实现只下载不安装的效果。这个方案在CentOS 6/7上用得非常广泛因为当年的yum默认没有downloadonly行为不装插件的话这个命令会直接真安装。到了dnf时代dnf install --downloadonly已经内置了不再需要额外插件dnf install --downloadonly --downloaddir/data/rpm_cache nginx这个方案的好处是语法和正常的yum install完全一致你不需要额外学习新命令想装什么就下载什么。坏处是它必须把依赖解析过程完整跑一遍那么你的机器上yum源必须是通的。另外--downloadonly在下载时如果目标目录里已经有同名rpm文件它会跳过下载这个特性有时候反而是个坑因为同名但版本不同还是会跳过导致你拷贝回内网后版本不对。3.5 repoquery加手动wget最原始的保底方案如果上面的工具因为各种原因都不好使或者你想精确控制只下载特定几个包可以用repoquery来查询依赖列表然后自己拼接URL去下载。repoquery --requires --resolve nginx这个命令会列出一串包名然后你再逐个用yumdownloader或者直接拼repo源的URL下载。这个方法看起来笨但在一些极端场景下反而是最可靠的比如你需要锁定某个特殊版本的包或者需要跨多个repo源拼接依赖前面那些自动化工具可能解析不出来人肉反而可以绕过。不过我不太推荐常规场景用这个因为效率低、容易漏。它的存在意义更多是当你理解了依赖解析的原理之后可以手动作一些自动化工具做不了的事情。我用一张表把这几个工具的差异整理出来方便大家快速决策工具所属包支持系统依赖递归程度适合场景yumdownloaderyum-utilsCentOS 6/7等直接依赖为主只需要单个包或少量依赖repotrackyum-utilsCentOS 6/7等递归完整收集生产环境离线仓库准备dnf downloaddnf插件CentOS 8/Rocky/Fedora直接依赖为主视版本新系统上快速下载yum install --downloadonly插件/dnf内置CentOS 6/7 插件或dnf同install依赖解析沿袭安装习惯下载顺便装repoquery 手动下载yum-utils全系列全人工控制特殊版本、跨源补漏如果你是第一次操作建议直接选repotrack它在完整性和自动化程度上的平衡性最好。4. 完整实操从下载依赖到内网安装的全流程工具选型讲完下面走一遍完整的实战流程。这里我用一个实际案例来演示在CentOS 7.9上离线部署Nginx。整个流程分为三个大步骤准备环境、下载依赖和分析包、内网安装验证。4.1 第一步准备下载环境找一台能联网的机器系统版本和架构必须和目标离线机一致。怎么看架构和版本uname -m cat /etc/redhat-release一定要两个都确认。uname -m输出x86_64就代表64位目标机器如果是一台ARM服务器输出会是aarch64这种时候你下载的包架构就对不上拿到目标机器上安装时rpm会直接拒绝安装。确认之后先把yum源配好保证能正常访问。测试方法很简单yum clean all yum makecache如果makecache正常跑完没有报错说明源是通的。这里有个小经验如果公司内网有镜像源优先配置内网源这样下载速度能快不少而且能保证依赖解析结果跟目标环境一致。我见过有人用公网源下载后装不上就是因为内网机器配置的软件源版本和公网有差异。4.2 第二步用repotrack完整收集依赖目录规划一下我用一个专门的目录保存所有rpm文件mkdir -p /data/rpm_nginx cd /data/rpm_nginx repotrack --archx86_64 -p /data/rpm_nginx nginx执行完毕后查看一下目录ls -lh /data/rpm_nginx你会看到nginx本体加上一堆依赖包可能十几个也可能几十个。怎么判断是否下载完整这里有个小技巧用rpm命令检查每个包的依赖关系。cd /data/rpm_nginx for rpmfile in *.rpm; do echo $rpmfile rpm -qpR $rpmfile 2/dev/null | grep -E rpmlib|/bin|/sbin -v || true donerpm -qpR是查询未安装的rpm包的依赖需求列表。如果输出的依赖除了rpmlib开头的这些是rpm自身的内部依赖不用管以及一些路径依赖比如/bin/sh这种由bash或者filesystem包提供的其他都能在当前目录或者系统里找到对应提供者那基本就是完整的。一个更省事的检查方法是用repotrack的输出信息。它在解析依赖时会把所有需要的包都列出来只要命令正常结束没有报错下载目录里的文件就是一套完整的依赖闭包。4.3 第三步打包拷贝到内网机器确认齐全后把整个目录打包cd /data tar czf rpm_nginx.tar.gz rpm_nginx把这个tar包通过U盘、内网传文件工具或者运维管理平台传到目标离线机器上然后在目标机器上解压tar xzf rpm_nginx.tar.gz cd rpm_nginx4.4 第四步离线安装与验证到这一步安装方式有两种一种是用rpm命令逐个安装另一种是搭一个本地repo然后用yum install来自动安装。方式一rpm直接安装简单但要排序依赖关系很复杂时rpm -ivh需要按照依赖顺序执行否则就会报错。最简单的办法是全部一起装让rpm自己排序cd /data/rpm_nginx rpm -Uvh *.rpm --nodeps --force但是我不建议你用--nodeps因为这会跳过依赖检查可能装上之后软件运行有隐患。而且这样安装的包rpm数据库里的依赖信息是空的以后你再用yum管理这些包时容易出现各种奇怪问题。更稳妥的做法是先安装依赖再安装主包。不过手工排序很痛苦被逼无奈时可以写个简单循环多执行几次每次把能装的装上直到最后剩一个主包cd /data/rpm_nginx for i in {1..10}; do rpm -ivh *.rpm 2/dev/null break done这个办法的原理是rpm安装时会检查依赖依赖还没装的包会被跳过报错已经满足的就会装上。循环多跑几次后越往后依赖越少最终所有包都能装完。这个方法虽然土但在没有本地repo的条件下非常实用。方式二搭建临时本地repo优雅推荐如果你所在的内网环境以后还要经常装软件建议顺手搭一个本地repo一次性把本地yum源建立起来之后的所有安装都走yum依赖自动解决。yum install -y createrepo如果在目标机器上还没有createrepo这个工具有一个变通办法在下载机上下载createrepo及其依赖一起拿过去。createrepo的依赖很少基本就是python和libxml2这些下载起来很快。然后在放rpm包的目录执行cd /data/rpm_nginx createrepo .这一步会生成一个repodata目录里面有仓库的元数据。接着在/etc/yum.repos.d/下新建一个repo文件比如local.repo[local-rpm] nameLocal RPM Repository baseurlfile:///data/rpm_nginx enabled1 gpgcheck0保存后清理缓存并测试yum clean all yum makecache yum install nginx -y此时yum会从本地repo里解析所有依赖并自动安装这一套流程下来离线环境里你以后想装什么都可以按这个套路扩展。验证安装是否正确rpm -q nginx nginx -v再看下端口监听和服务状态整个部署就算完成了。5. 搭建一个可复用的离线yum仓库上面的临时repo方案只能解决当下这一个软件的安装。现实中我经常要在一台离线服务器上一口气装十几个软件比如Nginx、MySQL、Redis、Python依赖库等等。如果每次都现场下载、现场build repo效率很低。更好的做法是在源机上把所有需要的软件包和依赖全部收集到一个大目录里生成一次repo元数据长期维护。具体做法是先建一个总目录比如/data/offline_repo然后在里面分别建子目录存放不同软件的包。目录结构可以这样/data/offline_repo/ ├── nginx/ ├── mysql/ ├── redis/ ├── python3/每个子目录里放着对应软件的rpm包包括依赖收集方式就用上一节讲的repotrack。全部收集完以后在总目录上执行一次createrepo。注意createrepo默认只在当前目录扫描rpm文件不会递归扫描子目录所以你需要为每个子目录单独生成repodata或者把所有rpm文件都平铺到一个目录里。我个人推荐平铺方案原因是createrepo对多目录的支持比较绕以后新增包要反复重新生成。把所有rpm文件集中到一个目录比如/data/offline_repo/all然后cd /data/offline_repo/all createrepo .之后这个all目录就是一个完整的离线软件仓库内网机器上配置好repo文件install什么都可以自动解析依赖。维护时新增软件也很简单把新下载的rpm丢进all目录再执行一次createrepo --update .即可增量更新不会影响已有的包。这个方案还有一个额外的好处createrepo生成的repo元数据里包含了每个rpm包的校验信息你在迁移过程中如果某个文件损坏yum install时会直接报校验错误而不会装上损坏的包导致后续问题。6. 从实际踩坑中总结的依赖收集注意事项6.1 架构不一致导致的大量失败最常见的坑是目标机器是ARM架构下载机是x86_64结果下载回来一堆x86_64包拿去安装时rpm直接报wrong architecture。这个错误很显眼但也容易被人忽略因为不是每个人一开始就想到要确认架构。我的经验是拿到一台离线机器后第一件事就是执行uname -m并且把这个信息记到部署文档里。下载机上也要确认一次两边一致才继续。6.2 版本冲突和源不一致第二个高频坑是版本冲突。比如目标机器上已经有了一个旧版本的libssl而你要装的软件依赖的是另一个版本的libssl而这两个版本的包在同一个repo源里同时存在。repotrack解析依赖时可能会下载最新版导致跟目标机器上的旧版本行为不一致。碰到这种情况我的处理方法是在下载机上也模拟出目标机器的环境也就是把目标机器上已安装的包列表导出来在下载机上把它装上一遍然后再去下载目标软件的依赖。具体做法# 在目标机器上执行 rpm -qa --qf %{NAME}\n installed_pkgs.txt # 把文件传到下载机 yum install -y $(cat installed_pkgs.txt)这不保证100%一致但能显著减少版本冲突的概率。6.3 repotrack没有把弱依赖带全repotrack对硬依赖Requires字段处理得很好但对弱依赖Recommends字段有时候会漏。比如某些软件包在Recommends里定义了建议安装的组件这些组件不装软件也能跑但功能会缺失。repotrack默认不会下载Recommends的内容除非加--recommends参数。我的建议是在下载目标包之后顺手用repoquery --requires和repoquery --recommends各查一遍把缺的补上。repoquery --requires --resolve nginx repoquery --recommends --resolve nginx6.4 noarch包和特殊依赖noarch包是不分架构的rpm文件名里直接带noarch字样。这类包下载时不会引起架构问题但容易出现重复。比如同一个noarch包被多个软件依赖repotrack可能会把它重复放进来。另外有些包依赖的库来自第三方源比如EPEL、RPMForge。下载这类包时一定要同时把第三方源配置好否则repotrack会报没有可用软件包。我的做法是下载软件前先启用EPELyum install -y epel-release然后在下载命令里加上对这个源的引用或者直接用--enablerepoepel参数repotrack --enablerepoepel --archx86_64 -p /data/rpm_nginx nginx6.5 下载机的缓存文件干扰当repotrack或yumdownloader下载包时yum会先检查自己的本地缓存。如果缓存目录里有损坏的rpm文件下载可能被强制跳过导致最终拷到内网的包是坏的。所以每次下载前最好清缓存yum clean all下载完成后用rpm -K对每个rpm文件做一下完整性校验cd /data/rpm_nginx for f in *.rpm; do rpm -K $f; done看到OK才说明文件完整如果有NOKEY的提示只要不是出现类似sha1 md5 OK缺失的提示NOKEY通常只是签名密钥问题不影响文件内容完整性。7. 关于rpm命令在离线环境中几个容易踩的细节很多人离线装软件时会卡在rpm -ivh报错其实大多数报错信息都是在告诉你某个依赖缺失。下面把几个细节展开说一下。7.1 当系统提示Failed dependencies时先分清楚是硬缺还是软缺举个例子执行rpm -ivh nginx.rpm时报error: Failed dependencies: libpcre.so.1()(64bit) is needed by nginx-1.20.1-1.el7.x86_64这说明需要libpcre.so.1这个动态库它由pcre包提供。解决办法就是找到pcre的rpm先装上。这时候不要一上来就加--nodeps如果只是库缺失老老实实把依赖包装上以后维护省心很多。如果你是急着先跑起来可以用--nodeps强行装上但必须知道这是临时方案后续要把依赖补齐否则程序可能在启动时报找不到so文件。7.2 rpm和yum混用时的数据库一致性离线环境装包时可能你用了rpm -ivh装了某几个包后面又想用yum管理这时要注意rpm数据库的一致性问题。rpm装的包不会被yum记录到已安装列表里不会的yum底层还是调用rpm安装记录是共享的不会出现装了但yum看不见的情况。真正需要担心的是rpm -e卸载包时不会检查依赖可能导致系统里残留孤儿依赖后续yum操作时被这些问题坑到。所以离线环境里的包管理我建议统一用一种方式要么全走yum加本地repo要么全部用rpm手动管理两种混着用短期没事长期维护会很头疼。7.3 内网机器装完软件后记得检查服务能否自启离线环境下因为很多服务可能是手动编译或者从rpm包装的系统重启后服务不一定会自动拉起。rpm包安装的服务一般会自动注册到systemd但也要确认一下systemctl enable nginx systemctl start nginx systemctl status nginx我曾遇到过离线部署完MySQL后目标机器断电重启数据库起不来的情况。排查半天发现是SELinux拦截了MySQL的数据目录访问。RPM包安装的软件一般会自带SELinux策略但如果你做了自定义目录或者改了默认端口SELinux可能就拦上了。这类问题在线环境也会有但在离线环境里排查起来更麻烦因为没法方便地装额外的排查工具所以部署时就要顺手把SELinux状态摸清楚getenforce如果是Enforcing就需要尤其小心自定义路径的问题。8. 几种使用场景下的推荐组合方案不同的离线场景我推荐的下载工具组合其实是有讲究的。写到这里我把几种最常见的场景直接列出来大家可以照着自己匹配一下。场景一临时装一个小软件内网机就一台以后不再重复部署推荐yumdownloader --resolve或dnf download --resolve。因为包数量少、依赖简单没必要动用repotrack的全量收集时间上更快磁盘占用也更小。场景二生产环境批量离线部署同一套软件到多台机器推荐repotrackcreaterepo搭建本地repo然后每台机器配置同一个repo文件。这样几十台机器装的包版本完全一致不会出现这台装了1.2、那台装了1.3的版本漂移问题。场景三离线机器上没有createrepo也不想为了装它费事推荐repotrack收集依赖后用循环多次rpm -ivh的方式安装。所有rpm文件一起喂给它最多循环个五六次基本就能装完。这个方法在依赖数量巨大时速度慢一点但胜在不依赖额外工具。场景四目标环境与下载环境版本有偏差担心依赖解析结果不对推荐在下载机上把目标机器的已装包列表完整安装一遍再用repotrack下载。同时用repoquery --requires --resolve和repoquery --recommends --resolve做二次核对手动补齐漏掉的包。场景五用户给的软件包只提供了rpm文件本身没有任何yum源这种时候你手里可能只有几个散装的rpm但这几个rpm又依赖了一堆东西。这种情况下我建议先把已知的几个rpm装了然后看报错信息缺什么再用联网机器去搜对应的依赖包下载。虽然原始但胜在精准不会多下没用的大文件。这些场景组合下来你会发现真正需要掌握的其实就三样东西repotrack用于完整收集依赖、createrepo用于搭建本地仓库、rpm的依赖检查命令用于验证完整性。其他工具都只是锦上添花。9. 这个流程还能怎么扩展离线rpm下载这件事练熟了之后完全可以扩展到更大的范围。比如现在很多人用Kubernetes离线部署K8s集群时也要面对大量镜像和二进制包的问题。rpm包的思路可以迁移过去从一台能联网的机器上把需要的K8s组件、etcd、pause等镜像全部拉下来导出成tar文件拿到离线机器上再ctr -nk8s.io images import或者docker load进去原理是一模一样的。Python的pip包、Node的npm包离线安装也是类似的思路在联网机器上先把所有依赖包下载成wheel或者tgz拷贝到内网后禁用外网索引只从本地目录安装。甚至Maven的jar包离线仓库也是这样组织的思路都相同——在一台同构环境里提前把依赖闭包做完整然后把闭包带到目标环境。回到rpm本身我再分享一个小技巧。真要长期维护一个离线yum仓库的话建议写一个简单的脚本每次新增软件包时自动执行repotrack、把新包丢进仓库、然后createrepo --update并在本地用一台虚拟机做一次从零安装的冒烟测试。别嫌这一步麻烦我因为跳过冒烟测试翻过车deploy到客户现场才发现缺了一个包。提前在镜像环境里验证一下踩坑成本是最低的。这个topic本身涉及的内容比较多但核心就一句话离线装rpm依赖关键不在于记住某条命令而在于理解依赖链是怎么被解析的、在哪个环节用哪个工具去把依赖闭包做完整。希望这篇文章能帮你把这个流程跑通少走一些我用时间换来的弯路。