内网环境里装软件最怕的不是缺包而是明明有网却不敢开、能开却慢得离谱。apt-get install --download-only这个参数就是给这种场景准备的一把离线搬运钥匙——它让 apt 只把 deb 包和依赖下载到本地缓存不触发安装动作你把这堆文件拷到目标机器上再装整个过程干净、可控、可复现。这篇内容面向需要在隔离网络、内网机房、批量部署环境里做软件分发的运维和开发人员也适合刚接触 Debian 系包管理、想搞明白 apt 缓存机制的朋友。我会从为什么这个参数值得单独拿出来讲切入把依赖解析、缓存路径、离线安装的完整链路、跨版本踩坑、批量分发脚本这些实操细节全部摊开最后给几套可以直接抄走的方案。全文基于 Debian/Ubuntu 系的通用实践涉及具体版本差异的地方会单独标注。1. 为什么只下载不安装是个被低估的能力很多人第一次看到--download-only会觉得鸡肋既然都要装了为什么不直接装这个疑问恰恰暴露了对 apt 工作模型的理解盲区。apt 的安装动作实际上分成两个阶段解析依赖并获取包以及解包配置写入系统。这两个阶段在默认流程里是绑死的而--download-only做的事情就是把第一阶段单独拎出来让你在 A 机器上完成取包在 B 机器上完成落盘。理解这个拆分后面所有操作才有根基。1.1 apt 的两阶段模型与缓存目录的真实结构apt 下载的 deb 包并不会随手丢在某个临时目录而是统一落在/var/cache/apt/archives/下。这个目录就是离线搬运的核心中转站。当你执行普通apt-get install时包先下载到这里然后 apt 调用 dpkg 进行解包和配置安装成功后默认会把这个 deb 删掉除非配置了保留。而加上--download-onlyapt 走完下载就停手deb 文件原封不动留在 archives 目录里等你处置。这里有个容易被忽略的细节archives 目录下除了.deb文件还会有一个partial/子目录用于存放下载中的临时文件。如果你在下载过程中中断残留的半截文件会留在 partial 里下次下载时 apt 会尝试续传或清理。做离线打包时只拷贝.deb文件不要连 partial 一起搬否则目标机器上可能出现损坏包导致的解包失败。另一个关键点是 apt 的列表缓存/var/lib/apt/lists/。这个目录存的是软件源的索引文件决定了 apt 知道哪些包、哪些版本、依赖关系如何。离线机器如果 lists 是空的或者过期的即使你把 deb 拷过去apt-get install也可能因为找不到依赖元数据而报错。所以完整的离线方案里lists 的同步和 deb 的搬运同等重要这一点后面会专门展开。1.2 和 apt-offline、apt-cdrom 这些方案的定位差异提到离线安装很多人会想到apt-offline这类专门工具或者用安装光盘做本地源。它们的定位其实不一样。apt-offline的工作方式是在离线机器上生成一个签名请求文件拿到有网机器上解析出需要下载的包列表下载完再带回离线机器安装。它适合完全不知道要装什么、让工具去算的场景但流程偏重需要两台机器来回倒腾请求文件。--download-only的定位更轻你已经明确知道要装哪个包在有网机器上把包和依赖一次性拉齐打包带走。它不依赖额外工具纯靠 apt 原生能力可控性更强。而apt-cdrom是把光盘挂成软件源适合有官方介质的情况但介质里的包版本往往滞后且更新麻烦。方案适用场景依赖解析操作复杂度版本新鲜度--download-only已知目标包批量搬运有网机器上完成低取决于源apt-offline离线机器不确定依赖离线机器生成请求中高取决于源apt-cdrom有官方安装介质介质内解析低通常滞后手动 wget deb单包、依赖简单人工判断高取决于源从表里能看出来--download-only在已知目标、追求效率和可控的场景下优势明显。我个人的习惯是单机补几个包用--download-only整批机器做基线同步才考虑搭本地源。1.3 一个真实的内网机房场景还原说个具体场景。某内网机房有一批同型号服务器系统是同一个发行版镜像装的但交付时只装了最小系统后续要补一批监控代理、日志采集、运行时依赖。机房没有外网出口只有一台跳板机能访问软件源。最朴素的做法是在跳板机上把每个包apt-get install一遍然后去 archives 里捞 deb——但这样会把包装到跳板机自己身上污染环境而且依赖关系容易漏。正确姿势是在跳板机上用--download-only把目标包连同依赖一次性拉下来打包成一个目录通过内部文件传输送到每台机器再统一dpkg -i或本地源安装。整个过程跳板机自身不装任何东西干净。这个场景几乎是我见过--download-only最高频的用法后面第 4 节的批量脚本就是围绕它设计的。2. 依赖解析download-only 到底帮你算了什么--download-only最值钱的地方不是下载这个动作而是它背后那套依赖解析。你敲下apt-get install --download-only fooapt 做的事情远比找到 foo.deb 下载复杂它会读取 lists 里的依赖元数据构建依赖树处理版本约束、虚拟包、替代依赖、架构限定最后得出一组要装这个包必须同时具备哪些包的闭包集合。这个集合才是你真正要搬运的东西。2.1 依赖闭包是怎么被计算出来的apt 的依赖解析可以类比成解一道带约束的集合覆盖题。每个包在元数据里声明了Depends、Pre-Depends、Recommends、Suggests等关系。Depends是硬依赖必须满足Pre-Depends更严格要求在解包前就满足Recommends默认也会被安装除非用--no-install-recommends关掉Suggests默认不装。apt 从目标包出发递归展开Depends和Pre-Depends遇到或关系比如a | b时按优先级选一个能满足的遇到虚拟包时找提供该虚拟包的实体包遇到版本约束 1.2时在可用版本里挑满足的。最终得到一个待下载列表。这个列表就是--download-only实际下载的内容。理解这一点很关键你在有网机器上算出的闭包和离线机器上实际需要的闭包可能不一致。原因是有网机器和离线机器的 lists 版本、已装包状态不同。如果离线机器已经装了某些依赖闭包会小一些如果离线机器的源索引更旧某些包版本对不上闭包里的版本可能装不上。这就是为什么第 3 节要强调对齐 lists。2.2 Recommends 的开关会显著改变下载体积默认情况下 apt 会安装Recommends级别的包。这个默认值在桌面环境里很合理但在服务器离线搬运场景里往往是灾难——一个看似简单的工具可能因为 Recommends 拖进来几十个包体积翻好几倍。用--no-install-recommends可以关掉这一层。代价是某些功能可能缺失比如某个命令行工具推荐安装补全脚本或文档包关掉后这些就没有了但核心功能通常不受影响。我的经验是服务器场景默认加--no-install-recommends除非明确知道某个 Recommends 是功能必需的。判断方法是在有网机器上先跑一次 dry-run看下载列表里有没有明显不相关的包。# 只看会下载什么不实际下载 apt-get install --download-only --no-install-recommends -s nginx # -s 是 --simulate 的简写输出模拟结果 # 对比加不加 --no-install-recommends 的差异 apt-get install --download-only -s nginx两次模拟的输出对比一下包数量和总体积的差距一目了然。这个 dry-run 习惯能帮你省下大量无谓的搬运。2.3 版本锁定与跨源依赖的坑依赖闭包计算还有一个隐蔽的坑跨源版本冲突。假设有网机器配了多个软件源某个依赖包在源 A 是 2.0 版本在源 B 是 1.8 版本apt 会按优先级选一个。但离线机器的源配置可能不同导致它期望的版本和你下载的版本对不上安装时报依赖版本不满足。规避方法有两个。一是下载时用apt-cache policy 包名确认实际选中的版本记录下来二是在离线机器上安装时如果版本对不上用dpkg -i直接装 deb 绕过 apt 的版本检查但要自己保证依赖顺序正确。更稳妥的做法是在有网机器上把源配置和离线机器对齐只保留必要的源减少版本歧义。提示apt-get install --download-only下载的包版本可以用apt-get install --download-only -s 包名的输出里Inst行确认格式是包名 (版本 源)。把这个输出存档离线安装时对照排查非常有用。3. 从有网机器到离线机器的完整搬运链路光知道参数不够真正落地是一套链路有网机器准备环境、下载、打包传输介质搬运离线机器还原环境、安装、验证。每一环都有细节漏一个就可能在最后一步卡住。这一节按顺序把链路走一遍重点标出容易翻车的位置。3.1 有网机器上的下载前准备下载前第一件事是更新 lists确保你算出的依赖闭包基于最新的源索引apt-get update第二件事是确认磁盘空间。/var/cache/apt/archives/所在分区要有足够余量一个稍大的包集合动辄几百 MB 到几个 GB。用df -h /var/cache/apt/archives看一眼别下到一半空间满了。第三件事如果之前下载过包archives 里可能有残留。为了打包干净可以先清空注意这会删掉所有缓存的 deb如果里面有你想保留的先备份apt-get cleanapt-get clean清空整个 archives 目录apt-get autoclean只清过期的。离线打包场景建议用 clean保证目录里只有本次要搬的包。3.2 执行下载并核对产物核心命令就一行但参数组合值得说清楚apt-get install --download-only --no-install-recommends -y 包名1 包名2 ...-y是自动确认避免交互卡住。多个包可以一次列出apt 会合并计算依赖闭包比一个个下更省事也能避免重复包。下载完成后核对产物# 列出下载的 deb 文件及大小 ls -lh /var/cache/apt/archives/*.deb # 统计总大小和文件数 du -sh /var/cache/apt/archives/ ls /var/cache/apt/archives/*.deb | wc -l这里有个实操心得下载完成后不要急着 clean先把 deb 拷出来再清。因为有些包在下载时如果已存在同版本apt 会跳过下载直接复用你以为下全了其实目录里混着旧文件。核对时留意文件时间戳确认都是本次下载的。3.3 打包、传输与校验打包时把 deb 文件单独归拢到一个目录不要连 archives 的其他内容一起打mkdir -p /tmp/offline-pkgs cp /var/cache/apt/archives/*.deb /tmp/offline-pkgs/ cd /tmp tar czf offline-pkgs.tar.gz offline-pkgs/传输环节取决于你的介质内部文件共享、移动存储、内部传输工具都行。关键是传输后做完整性校验避免半截文件。生成校验和cd /tmp/offline-pkgs sha256sum *.deb SHA256SUMS到离线机器上解包后执行sha256sum -c SHA256SUMS验证。这一步看着繁琐但能挡住大部分装到一半报包损坏的问题。我踩过一次坑通过某个内部通道传大文件中间断过一次续传结果一个 deb 的尾部损坏dpkg -i报unexpected end of file排查了半天才发现是传输问题。从那以后校验和成了固定动作。3.4 离线机器上的安装顺序与依赖处理到了离线机器有两种装法。第一种是直接dpkg -i全部 debdpkg -i /path/to/offline-pkgs/*.debdpkg会按命令行顺序尝试安装但它不解决依赖顺序。如果 A 依赖 B而 A 排在 B 前面A 会报依赖未满足。虽然 dpkg 装完所有包后通常能自愈因为 B 后来也装上了但中间会报一堆错且如果某个包真的缺依赖最后会停在半配置状态。更稳的做法是先把 deb 放进一个本地目录用 apt 从本地源装让 apt 帮你排顺序。具体做法见 3.5。第二种是dpkg -i后补apt-get install -f修复依赖但离线机器没有源-f也无从下载只能靠本地已有的 deb。所以顺序问题最好在装之前解决。3.5 用本地目录做临时源让 apt 接管顺序这是我最推荐的离线安装方式。把 deb 放到一个目录生成 Packages 索引配成file://源然后正常apt-get install# 在离线机器上 mkdir -p /opt/local-repo cp /path/to/offline-pkgs/*.deb /opt/local-repo/ cd /opt/local-repo dpkg-scanpackages . /dev/null | gzip -9c Packages.gz # 配置本地源 echo deb [trustedyes] file:///opt/local-repo ./ /etc/apt/sources.list.d/local.list apt-get update apt-get install 包名dpkg-scanpackages生成索引[trustedyes]跳过签名校验本地目录没有签名这是必要的。这样 apt 会像对待普通源一样解析依赖、排序安装顺序问题自动解决。装完后记得把 local.list 移除或注释避免以后apt-get update时反复扫这个目录。注意dpkg-scanpackages属于dpkg-dev包如果离线机器没装需要提前把它也纳入下载清单。这是个典型的工具本身也需要离线准备的循环依赖第一次做容易漏。4. 批量分发把单机操作变成可复用的脚本单台机器手动操作还行一批机器就得上脚本。这一节给一套可以直接改参数用的方案核心思路是在有网机器上维护一份包清单脚本负责下载、打包、生成校验和离线侧脚本负责解包、建本地源、安装、清理。两个脚本配合把第 3 节的链路固化下来。4.1 包清单的维护方式不要把所有包名硬编码进脚本单独维护一个清单文件比如pkglist.txt一行一个包名#开头是注释# 监控与日志 monitoring-agent log-collector # 运行时依赖 libfoo1 libbar2这样增删包只改清单脚本不动。清单本身建议纳入版本管理每次变更留痕方便回溯某台机器为什么装了这个包。4.2 有网侧的下载打包脚本#!/bin/bash set -euo pipefail PKG_LIST./pkglist.txt WORK_DIR/tmp/offline-build OUTPUToffline-pkgs-$(date %Y%m%d).tar.gz # 读取清单过滤注释和空行 mapfile -t PKGS (grep -vE ^\s*(#|$) $PKG_LIST) if [ ${#PKGS[]} -eq 0 ]; then echo 包清单为空退出 exit 1 fi apt-get update apt-get clean # 下载关掉 recommends 控制体积 apt-get install --download-only --no-install-recommends -y ${PKGS[]} rm -rf $WORK_DIR mkdir -p $WORK_DIR cp /var/cache/apt/archives/*.deb $WORK_DIR/ cd $WORK_DIR sha256sum *.deb SHA256SUMS cd /tmp tar czf $OUTPUT $(basename $WORK_DIR) echo 打包完成: /tmp/$OUTPUT du -sh /tmp/$OUTPUT脚本里set -euo pipefail保证任何一步失败立即退出避免半成品。mapfile读清单比for循环处理带空格的行更稳。下载后立刻生成校验和和包放在一起。4.3 离线侧的安装脚本#!/bin/bash set -euo pipefail ARCHIVE$1 REPO_DIR/opt/local-repo if [ -z $ARCHIVE ] || [ ! -f $ARCHIVE ]; then echo 用法: $0 离线包归档.tar.gz exit 1 fi # 解包到临时目录 TMP_DIR$(mktemp -d) tar xzf $ARCHIVE -C $TMP_DIR PKG_DIR$(find $TMP_DIR -maxdepth 1 -type d -name offline-pkgs* | head -1) # 校验 cd $PKG_DIR sha256sum -c SHA256SUMS # 建本地源 rm -rf $REPO_DIR mkdir -p $REPO_DIR cp *.deb $REPO_DIR/ cd $REPO_DIR dpkg-scanpackages . /dev/null | gzip -9c Packages.gz echo deb [trustedyes] file://$REPO_DIR ./ /etc/apt/sources.list.d/local.list apt-get update # 从清单安装 mapfile -t PKGS (grep -vE ^\s*(#|$) $PKG_DIR/pkglist.txt 2/dev/null || true) if [ ${#PKGS[]} -gt 0 ]; then apt-get install -y --no-install-recommends ${PKGS[]} fi # 清理 rm -f /etc/apt/sources.list.d/local.list apt-get update rm -rf $TMP_DIR echo 安装完成注意脚本里把pkglist.txt也一起打包进去了下载脚本里应该加一行cp $PKG_LIST $WORK_DIR/这样离线侧知道要装哪些包。安装完移除本地源配置并重新 update避免残留配置影响后续操作。4.4 脚本化之后仍然要盯的几个点脚本能省事但不能替代判断。第一个点是目标机器的基础环境差异。同型号机器如果系统版本、已装包不同依赖闭包可能不同。脚本假设所有目标机器环境一致如果实际不一致要么分组处理要么在离线侧用apt-get install -f兜底前提是本地源里有修复所需的包。第二个点是本地源的清理时机。/opt/local-repo会一直占着磁盘装完如果不再需要应该清掉。但有些团队会保留它作为应急源那就得定期更新索引否则里面的包版本会越来越旧和新装的东西冲突。第三个点是清单里的包名要精确。apt 支持虚拟包和通配但离线场景下模糊匹配容易下错东西。清单里写实体包名必要时带版本号foo1.2.3减少歧义。5. 那些年踩过的坑从报错反推问题根源离线安装的报错往往很隐晦因为 apt 在有网环境下会自动补全的东西离线时全暴露出来。这一节按报错现象归类给出排查路径。这些坑我基本都踩过写出来是希望你能少走弯路。5.1 Unable to locate packagelists 没同步离线机器上执行安装报找不到包。第一反应是 deb 没拷对但更常见的原因是离线机器的 apt lists 里没有这个包的元数据。apt 判断能不能装依赖 listslists 里没有它连本地 deb 都不看。排查ls /var/lib/apt/lists/看有没有对应源的索引文件。如果为空或很旧说明 lists 没同步。解决方式有两种一是把有网机器的 lists 一起打包搬过去/var/lib/apt/lists/整个目录二是用 3.5 的本地源方式让apt-get update重新生成索引。后者更干净推荐。5.2 Depends: xxx but it is not installable闭包缺包这个报错说明依赖树里某个包没被下载。原因通常是下载时用了--no-install-recommends关掉了某个实际必需的 Recommends或者有网机器和离线机器的源版本不一致导致某个依赖版本对不上。排查在有网机器上重新跑apt-get install --download-only -s 包名把输出里的Inst行全部列出来和离线机器上已有的包对比找出缺的那个。补下载后重新打包。如果确认是 Recommends 的问题去掉--no-install-recommends重新下载。5.3 dpkg: error processing archive ... unexpected end of file包损坏前面提过多半是传输问题。用sha256sum -c验证损坏的重新传。如果校验和本身对不上说明打包时文件就已经坏了回有网机器重新下载那个包。还有一种可能是磁盘空间不足导致写入不完整。df -h确认目标分区余量尤其是/var/cache/apt/archives/和临时目录所在分区。5.4 装完包但服务起不来配置文件与用户组缺失这个坑最隐蔽。deb 包安装时会执行postinst脚本创建用户、生成配置、初始化目录。如果安装过程中因为依赖顺序问题导致postinst执行失败包会处于已解包未配置状态dpkg -l里状态显示iU或iF。此时二进制文件在但服务起不来。排查dpkg -l | grep -E ^i[UF]找出半配置的包然后dpkg --configure -a重新配置。如果配置脚本依赖某个还没装的包先补装那个包再 configure。这也是为什么 3.5 的本地源方式更稳——apt 会保证依赖顺序postinst不会因为缺依赖而失败。5.5 跨发行版搬运的版本地狱在有网机器上下载离线机器是另一个发行版版本这是最容易翻车的场景。比如有网侧是较新的发行版离线侧是旧版下载的 deb 依赖的库版本在旧版上不存在装上去直接崩。规避原则下载机和目标机的发行版版本必须一致至少大版本一致。如果做不到就在目标机同版本的容器或虚拟机里做下载保证 ABI 兼容。跨大版本搬运基本不可行别在这上面浪费时间。报错现象最可能原因排查命令解决方式Unable to locate packagelists 未同步ls /var/lib/apt/lists/本地源重建索引Depends not installable闭包缺包apt-get install -s对比补下载缺失包unexpected end of file包损坏/传输中断sha256sum -c重新传输服务起不来postinst 失败dpkg -l | grep ^i[UF]dpkg --configure -a库版本不匹配跨发行版搬运ldd查依赖同版本环境下载6. 进阶把离线源做成长期可维护的东西如果离线安装不是一次性任务而是长期需求那每次手动下载打包就太低效了。更成熟的做法是在内网维护一个本地镜像源定期从上游同步所有离线机器都指向它。--download-only在这个体系里退居为临时补包的工具日常靠镜像源解决。6.1 用 apt-mirror 或类似工具做内网镜像apt-mirror这类工具能把上游源按架构、按组件同步到本地目录配合 Web 服务或文件共享暴露给内网机器。配置核心是mirror.list指定上游地址、要同步的发行版和组件、本地存储路径。同步是增量的第一次全量拉取体积大后续只拉变化部分。这套方案的价值在于内网机器apt-get update apt-get install的体验和外网一致依赖解析、版本管理全部由 apt 原生处理不需要人工算闭包。代价是需要一台常开的同步机和足够的存储以及定期维护同步任务。6.2 镜像源和 download-only 的分工两者不是替代关系。镜像源解决常规安装--download-only解决镜像里没有的包或临时应急。比如某个第三方软件只提供了 deb 下载链接没进官方源那就用--download-only或直接 wget 拿到 deb丢进本地源目录重新生成索引内网机器就能装了。我通常的做法是本地源目录留一个extras/子目录专门放这类手工补充的 deb和镜像同步的目录分开避免同步任务误删。dpkg-scanpackages扫描时把 extras 也纳入索引里就都有了。6.3 签名与信任本地源的安全边界本地源用[trustedyes]跳过签名在内网可控环境下可以接受但如果内网有多个团队共用最好还是给本地源做签名。用gpg生成密钥对apt-ftparchive生成 Release 文件并签名客户端导入公钥。这套流程稍繁琐但能防止本地源被篡改后分发恶意包。对于小团队、机器数量不多的情况[trustedyes]配合严格的目录权限控制只有运维账号能写本地源目录通常够用。安全边界取决于你的威胁模型不必过度设计但要知道自己在放弃什么。6.4 定期清理与磁盘水位管理本地源和 archives 缓存都会持续增长。/var/cache/apt/archives/建议配一个定期清理任务只保留最近 N 天的 deb或者干脆装完就 clean。本地镜像源则要关注同步策略只同步需要的发行版和组件别把整个上游全拉下来。磁盘水位要设告警。我见过因为镜像同步把分区塞满导致同步机本身 apt 操作失败的案例连锁反应很麻烦。给镜像目录单独挂一个分区设 80% 告警线是比较稳妥的做法。7. 几个能立刻用上的实操建议聊了这么多原理和链路最后收几个可以直接落地的习惯都是我日常反复验证过的。第一下载前先 dry-run。apt-get install --download-only -s 包名看一眼闭包确认没有意外的大包混进来再实际下载。这个动作花不了几秒能省下大量搬运和排查时间。第二校验和是标配不是可选项。sha256sum生成和验证的成本极低但能挡住传输损坏这个高频问题。打包脚本里固化这一步别靠人记得。第三本地源方式优先于 dpkg -i 批量装。让 apt 管依赖顺序比人工保证顺序可靠得多。dpkg-scanpackages那几行命令值得背下来。第四下载机和目标机的发行版版本对齐。这是跨版本搬运所有问题的根源与其事后排查库版本不如一开始就在同版本环境里下载。第五清单文件纳入版本管理。哪台机器装了什么、为什么装靠清单留痕。出问题时能快速回溯比翻历史命令靠谱。第六装完清理本地源配置。/etc/apt/sources.list.d/local.list用完移除并apt-get update避免残留配置在后续操作里捣乱。这个细节很多人会忘等到某次 update 报错才想起来。这套东西用熟了之后内网离线装软件就从每次都要折腾半天变成跑个脚本等结果。--download-only本身只是个小参数但它背后串起来的是 apt 依赖解析、缓存管理、本地源构建这一整套能力把这些打通离线环境里的包管理就不再是黑盒。
内网环境里装软件最怕的不是缺包而是明明有网却不敢开、能开却慢得离谱。apt-get install --download-only这个参数就是给这种场景准备的一把离线搬运钥匙——它让 apt 只把 deb 包和依赖下载到本地缓存不触发安装动作你把这堆文件拷到目标机器上再装整个过程干净、可控、可复现。这篇内容面向需要在隔离网络、内网机房、批量部署环境里做软件分发的运维和开发人员也适合刚接触 Debian 系包管理、想搞明白 apt 缓存机制的朋友。我会从为什么这个参数值得单独拿出来讲切入把依赖解析、缓存路径、离线安装的完整链路、跨版本踩坑、批量分发脚本这些实操细节全部摊开最后给几套可以直接抄走的方案。全文基于 Debian/Ubuntu 系的通用实践涉及具体版本差异的地方会单独标注。1. 为什么只下载不安装是个被低估的能力很多人第一次看到--download-only会觉得鸡肋既然都要装了为什么不直接装这个疑问恰恰暴露了对 apt 工作模型的理解盲区。apt 的安装动作实际上分成两个阶段解析依赖并获取包以及解包配置写入系统。这两个阶段在默认流程里是绑死的而--download-only做的事情就是把第一阶段单独拎出来让你在 A 机器上完成取包在 B 机器上完成落盘。理解这个拆分后面所有操作才有根基。1.1 apt 的两阶段模型与缓存目录的真实结构apt 下载的 deb 包并不会随手丢在某个临时目录而是统一落在/var/cache/apt/archives/下。这个目录就是离线搬运的核心中转站。当你执行普通apt-get install时包先下载到这里然后 apt 调用 dpkg 进行解包和配置安装成功后默认会把这个 deb 删掉除非配置了保留。而加上--download-onlyapt 走完下载就停手deb 文件原封不动留在 archives 目录里等你处置。这里有个容易被忽略的细节archives 目录下除了.deb文件还会有一个partial/子目录用于存放下载中的临时文件。如果你在下载过程中中断残留的半截文件会留在 partial 里下次下载时 apt 会尝试续传或清理。做离线打包时只拷贝.deb文件不要连 partial 一起搬否则目标机器上可能出现损坏包导致的解包失败。另一个关键点是 apt 的列表缓存/var/lib/apt/lists/。这个目录存的是软件源的索引文件决定了 apt 知道哪些包、哪些版本、依赖关系如何。离线机器如果 lists 是空的或者过期的即使你把 deb 拷过去apt-get install也可能因为找不到依赖元数据而报错。所以完整的离线方案里lists 的同步和 deb 的搬运同等重要这一点后面会专门展开。1.2 和 apt-offline、apt-cdrom 这些方案的定位差异提到离线安装很多人会想到apt-offline这类专门工具或者用安装光盘做本地源。它们的定位其实不一样。apt-offline的工作方式是在离线机器上生成一个签名请求文件拿到有网机器上解析出需要下载的包列表下载完再带回离线机器安装。它适合完全不知道要装什么、让工具去算的场景但流程偏重需要两台机器来回倒腾请求文件。--download-only的定位更轻你已经明确知道要装哪个包在有网机器上把包和依赖一次性拉齐打包带走。它不依赖额外工具纯靠 apt 原生能力可控性更强。而apt-cdrom是把光盘挂成软件源适合有官方介质的情况但介质里的包版本往往滞后且更新麻烦。方案适用场景依赖解析操作复杂度版本新鲜度--download-only已知目标包批量搬运有网机器上完成低取决于源apt-offline离线机器不确定依赖离线机器生成请求中高取决于源apt-cdrom有官方安装介质介质内解析低通常滞后手动 wget deb单包、依赖简单人工判断高取决于源从表里能看出来--download-only在已知目标、追求效率和可控的场景下优势明显。我个人的习惯是单机补几个包用--download-only整批机器做基线同步才考虑搭本地源。1.3 一个真实的内网机房场景还原说个具体场景。某内网机房有一批同型号服务器系统是同一个发行版镜像装的但交付时只装了最小系统后续要补一批监控代理、日志采集、运行时依赖。机房没有外网出口只有一台跳板机能访问软件源。最朴素的做法是在跳板机上把每个包apt-get install一遍然后去 archives 里捞 deb——但这样会把包装到跳板机自己身上污染环境而且依赖关系容易漏。正确姿势是在跳板机上用--download-only把目标包连同依赖一次性拉下来打包成一个目录通过内部文件传输送到每台机器再统一dpkg -i或本地源安装。整个过程跳板机自身不装任何东西干净。这个场景几乎是我见过--download-only最高频的用法后面第 4 节的批量脚本就是围绕它设计的。2. 依赖解析download-only 到底帮你算了什么--download-only最值钱的地方不是下载这个动作而是它背后那套依赖解析。你敲下apt-get install --download-only fooapt 做的事情远比找到 foo.deb 下载复杂它会读取 lists 里的依赖元数据构建依赖树处理版本约束、虚拟包、替代依赖、架构限定最后得出一组要装这个包必须同时具备哪些包的闭包集合。这个集合才是你真正要搬运的东西。2.1 依赖闭包是怎么被计算出来的apt 的依赖解析可以类比成解一道带约束的集合覆盖题。每个包在元数据里声明了Depends、Pre-Depends、Recommends、Suggests等关系。Depends是硬依赖必须满足Pre-Depends更严格要求在解包前就满足Recommends默认也会被安装除非用--no-install-recommends关掉Suggests默认不装。apt 从目标包出发递归展开Depends和Pre-Depends遇到或关系比如a | b时按优先级选一个能满足的遇到虚拟包时找提供该虚拟包的实体包遇到版本约束 1.2时在可用版本里挑满足的。最终得到一个待下载列表。这个列表就是--download-only实际下载的内容。理解这一点很关键你在有网机器上算出的闭包和离线机器上实际需要的闭包可能不一致。原因是有网机器和离线机器的 lists 版本、已装包状态不同。如果离线机器已经装了某些依赖闭包会小一些如果离线机器的源索引更旧某些包版本对不上闭包里的版本可能装不上。这就是为什么第 3 节要强调对齐 lists。2.2 Recommends 的开关会显著改变下载体积默认情况下 apt 会安装Recommends级别的包。这个默认值在桌面环境里很合理但在服务器离线搬运场景里往往是灾难——一个看似简单的工具可能因为 Recommends 拖进来几十个包体积翻好几倍。用--no-install-recommends可以关掉这一层。代价是某些功能可能缺失比如某个命令行工具推荐安装补全脚本或文档包关掉后这些就没有了但核心功能通常不受影响。我的经验是服务器场景默认加--no-install-recommends除非明确知道某个 Recommends 是功能必需的。判断方法是在有网机器上先跑一次 dry-run看下载列表里有没有明显不相关的包。# 只看会下载什么不实际下载 apt-get install --download-only --no-install-recommends -s nginx # -s 是 --simulate 的简写输出模拟结果 # 对比加不加 --no-install-recommends 的差异 apt-get install --download-only -s nginx两次模拟的输出对比一下包数量和总体积的差距一目了然。这个 dry-run 习惯能帮你省下大量无谓的搬运。2.3 版本锁定与跨源依赖的坑依赖闭包计算还有一个隐蔽的坑跨源版本冲突。假设有网机器配了多个软件源某个依赖包在源 A 是 2.0 版本在源 B 是 1.8 版本apt 会按优先级选一个。但离线机器的源配置可能不同导致它期望的版本和你下载的版本对不上安装时报依赖版本不满足。规避方法有两个。一是下载时用apt-cache policy 包名确认实际选中的版本记录下来二是在离线机器上安装时如果版本对不上用dpkg -i直接装 deb 绕过 apt 的版本检查但要自己保证依赖顺序正确。更稳妥的做法是在有网机器上把源配置和离线机器对齐只保留必要的源减少版本歧义。提示apt-get install --download-only下载的包版本可以用apt-get install --download-only -s 包名的输出里Inst行确认格式是包名 (版本 源)。把这个输出存档离线安装时对照排查非常有用。3. 从有网机器到离线机器的完整搬运链路光知道参数不够真正落地是一套链路有网机器准备环境、下载、打包传输介质搬运离线机器还原环境、安装、验证。每一环都有细节漏一个就可能在最后一步卡住。这一节按顺序把链路走一遍重点标出容易翻车的位置。3.1 有网机器上的下载前准备下载前第一件事是更新 lists确保你算出的依赖闭包基于最新的源索引apt-get update第二件事是确认磁盘空间。/var/cache/apt/archives/所在分区要有足够余量一个稍大的包集合动辄几百 MB 到几个 GB。用df -h /var/cache/apt/archives看一眼别下到一半空间满了。第三件事如果之前下载过包archives 里可能有残留。为了打包干净可以先清空注意这会删掉所有缓存的 deb如果里面有你想保留的先备份apt-get cleanapt-get clean清空整个 archives 目录apt-get autoclean只清过期的。离线打包场景建议用 clean保证目录里只有本次要搬的包。3.2 执行下载并核对产物核心命令就一行但参数组合值得说清楚apt-get install --download-only --no-install-recommends -y 包名1 包名2 ...-y是自动确认避免交互卡住。多个包可以一次列出apt 会合并计算依赖闭包比一个个下更省事也能避免重复包。下载完成后核对产物# 列出下载的 deb 文件及大小 ls -lh /var/cache/apt/archives/*.deb # 统计总大小和文件数 du -sh /var/cache/apt/archives/ ls /var/cache/apt/archives/*.deb | wc -l这里有个实操心得下载完成后不要急着 clean先把 deb 拷出来再清。因为有些包在下载时如果已存在同版本apt 会跳过下载直接复用你以为下全了其实目录里混着旧文件。核对时留意文件时间戳确认都是本次下载的。3.3 打包、传输与校验打包时把 deb 文件单独归拢到一个目录不要连 archives 的其他内容一起打mkdir -p /tmp/offline-pkgs cp /var/cache/apt/archives/*.deb /tmp/offline-pkgs/ cd /tmp tar czf offline-pkgs.tar.gz offline-pkgs/传输环节取决于你的介质内部文件共享、移动存储、内部传输工具都行。关键是传输后做完整性校验避免半截文件。生成校验和cd /tmp/offline-pkgs sha256sum *.deb SHA256SUMS到离线机器上解包后执行sha256sum -c SHA256SUMS验证。这一步看着繁琐但能挡住大部分装到一半报包损坏的问题。我踩过一次坑通过某个内部通道传大文件中间断过一次续传结果一个 deb 的尾部损坏dpkg -i报unexpected end of file排查了半天才发现是传输问题。从那以后校验和成了固定动作。3.4 离线机器上的安装顺序与依赖处理到了离线机器有两种装法。第一种是直接dpkg -i全部 debdpkg -i /path/to/offline-pkgs/*.debdpkg会按命令行顺序尝试安装但它不解决依赖顺序。如果 A 依赖 B而 A 排在 B 前面A 会报依赖未满足。虽然 dpkg 装完所有包后通常能自愈因为 B 后来也装上了但中间会报一堆错且如果某个包真的缺依赖最后会停在半配置状态。更稳的做法是先把 deb 放进一个本地目录用 apt 从本地源装让 apt 帮你排顺序。具体做法见 3.5。第二种是dpkg -i后补apt-get install -f修复依赖但离线机器没有源-f也无从下载只能靠本地已有的 deb。所以顺序问题最好在装之前解决。3.5 用本地目录做临时源让 apt 接管顺序这是我最推荐的离线安装方式。把 deb 放到一个目录生成 Packages 索引配成file://源然后正常apt-get install# 在离线机器上 mkdir -p /opt/local-repo cp /path/to/offline-pkgs/*.deb /opt/local-repo/ cd /opt/local-repo dpkg-scanpackages . /dev/null | gzip -9c Packages.gz # 配置本地源 echo deb [trustedyes] file:///opt/local-repo ./ /etc/apt/sources.list.d/local.list apt-get update apt-get install 包名dpkg-scanpackages生成索引[trustedyes]跳过签名校验本地目录没有签名这是必要的。这样 apt 会像对待普通源一样解析依赖、排序安装顺序问题自动解决。装完后记得把 local.list 移除或注释避免以后apt-get update时反复扫这个目录。注意dpkg-scanpackages属于dpkg-dev包如果离线机器没装需要提前把它也纳入下载清单。这是个典型的工具本身也需要离线准备的循环依赖第一次做容易漏。4. 批量分发把单机操作变成可复用的脚本单台机器手动操作还行一批机器就得上脚本。这一节给一套可以直接改参数用的方案核心思路是在有网机器上维护一份包清单脚本负责下载、打包、生成校验和离线侧脚本负责解包、建本地源、安装、清理。两个脚本配合把第 3 节的链路固化下来。4.1 包清单的维护方式不要把所有包名硬编码进脚本单独维护一个清单文件比如pkglist.txt一行一个包名#开头是注释# 监控与日志 monitoring-agent log-collector # 运行时依赖 libfoo1 libbar2这样增删包只改清单脚本不动。清单本身建议纳入版本管理每次变更留痕方便回溯某台机器为什么装了这个包。4.2 有网侧的下载打包脚本#!/bin/bash set -euo pipefail PKG_LIST./pkglist.txt WORK_DIR/tmp/offline-build OUTPUToffline-pkgs-$(date %Y%m%d).tar.gz # 读取清单过滤注释和空行 mapfile -t PKGS (grep -vE ^\s*(#|$) $PKG_LIST) if [ ${#PKGS[]} -eq 0 ]; then echo 包清单为空退出 exit 1 fi apt-get update apt-get clean # 下载关掉 recommends 控制体积 apt-get install --download-only --no-install-recommends -y ${PKGS[]} rm -rf $WORK_DIR mkdir -p $WORK_DIR cp /var/cache/apt/archives/*.deb $WORK_DIR/ cd $WORK_DIR sha256sum *.deb SHA256SUMS cd /tmp tar czf $OUTPUT $(basename $WORK_DIR) echo 打包完成: /tmp/$OUTPUT du -sh /tmp/$OUTPUT脚本里set -euo pipefail保证任何一步失败立即退出避免半成品。mapfile读清单比for循环处理带空格的行更稳。下载后立刻生成校验和和包放在一起。4.3 离线侧的安装脚本#!/bin/bash set -euo pipefail ARCHIVE$1 REPO_DIR/opt/local-repo if [ -z $ARCHIVE ] || [ ! -f $ARCHIVE ]; then echo 用法: $0 离线包归档.tar.gz exit 1 fi # 解包到临时目录 TMP_DIR$(mktemp -d) tar xzf $ARCHIVE -C $TMP_DIR PKG_DIR$(find $TMP_DIR -maxdepth 1 -type d -name offline-pkgs* | head -1) # 校验 cd $PKG_DIR sha256sum -c SHA256SUMS # 建本地源 rm -rf $REPO_DIR mkdir -p $REPO_DIR cp *.deb $REPO_DIR/ cd $REPO_DIR dpkg-scanpackages . /dev/null | gzip -9c Packages.gz echo deb [trustedyes] file://$REPO_DIR ./ /etc/apt/sources.list.d/local.list apt-get update # 从清单安装 mapfile -t PKGS (grep -vE ^\s*(#|$) $PKG_DIR/pkglist.txt 2/dev/null || true) if [ ${#PKGS[]} -gt 0 ]; then apt-get install -y --no-install-recommends ${PKGS[]} fi # 清理 rm -f /etc/apt/sources.list.d/local.list apt-get update rm -rf $TMP_DIR echo 安装完成注意脚本里把pkglist.txt也一起打包进去了下载脚本里应该加一行cp $PKG_LIST $WORK_DIR/这样离线侧知道要装哪些包。安装完移除本地源配置并重新 update避免残留配置影响后续操作。4.4 脚本化之后仍然要盯的几个点脚本能省事但不能替代判断。第一个点是目标机器的基础环境差异。同型号机器如果系统版本、已装包不同依赖闭包可能不同。脚本假设所有目标机器环境一致如果实际不一致要么分组处理要么在离线侧用apt-get install -f兜底前提是本地源里有修复所需的包。第二个点是本地源的清理时机。/opt/local-repo会一直占着磁盘装完如果不再需要应该清掉。但有些团队会保留它作为应急源那就得定期更新索引否则里面的包版本会越来越旧和新装的东西冲突。第三个点是清单里的包名要精确。apt 支持虚拟包和通配但离线场景下模糊匹配容易下错东西。清单里写实体包名必要时带版本号foo1.2.3减少歧义。5. 那些年踩过的坑从报错反推问题根源离线安装的报错往往很隐晦因为 apt 在有网环境下会自动补全的东西离线时全暴露出来。这一节按报错现象归类给出排查路径。这些坑我基本都踩过写出来是希望你能少走弯路。5.1 Unable to locate packagelists 没同步离线机器上执行安装报找不到包。第一反应是 deb 没拷对但更常见的原因是离线机器的 apt lists 里没有这个包的元数据。apt 判断能不能装依赖 listslists 里没有它连本地 deb 都不看。排查ls /var/lib/apt/lists/看有没有对应源的索引文件。如果为空或很旧说明 lists 没同步。解决方式有两种一是把有网机器的 lists 一起打包搬过去/var/lib/apt/lists/整个目录二是用 3.5 的本地源方式让apt-get update重新生成索引。后者更干净推荐。5.2 Depends: xxx but it is not installable闭包缺包这个报错说明依赖树里某个包没被下载。原因通常是下载时用了--no-install-recommends关掉了某个实际必需的 Recommends或者有网机器和离线机器的源版本不一致导致某个依赖版本对不上。排查在有网机器上重新跑apt-get install --download-only -s 包名把输出里的Inst行全部列出来和离线机器上已有的包对比找出缺的那个。补下载后重新打包。如果确认是 Recommends 的问题去掉--no-install-recommends重新下载。5.3 dpkg: error processing archive ... unexpected end of file包损坏前面提过多半是传输问题。用sha256sum -c验证损坏的重新传。如果校验和本身对不上说明打包时文件就已经坏了回有网机器重新下载那个包。还有一种可能是磁盘空间不足导致写入不完整。df -h确认目标分区余量尤其是/var/cache/apt/archives/和临时目录所在分区。5.4 装完包但服务起不来配置文件与用户组缺失这个坑最隐蔽。deb 包安装时会执行postinst脚本创建用户、生成配置、初始化目录。如果安装过程中因为依赖顺序问题导致postinst执行失败包会处于已解包未配置状态dpkg -l里状态显示iU或iF。此时二进制文件在但服务起不来。排查dpkg -l | grep -E ^i[UF]找出半配置的包然后dpkg --configure -a重新配置。如果配置脚本依赖某个还没装的包先补装那个包再 configure。这也是为什么 3.5 的本地源方式更稳——apt 会保证依赖顺序postinst不会因为缺依赖而失败。5.5 跨发行版搬运的版本地狱在有网机器上下载离线机器是另一个发行版版本这是最容易翻车的场景。比如有网侧是较新的发行版离线侧是旧版下载的 deb 依赖的库版本在旧版上不存在装上去直接崩。规避原则下载机和目标机的发行版版本必须一致至少大版本一致。如果做不到就在目标机同版本的容器或虚拟机里做下载保证 ABI 兼容。跨大版本搬运基本不可行别在这上面浪费时间。报错现象最可能原因排查命令解决方式Unable to locate packagelists 未同步ls /var/lib/apt/lists/本地源重建索引Depends not installable闭包缺包apt-get install -s对比补下载缺失包unexpected end of file包损坏/传输中断sha256sum -c重新传输服务起不来postinst 失败dpkg -l | grep ^i[UF]dpkg --configure -a库版本不匹配跨发行版搬运ldd查依赖同版本环境下载6. 进阶把离线源做成长期可维护的东西如果离线安装不是一次性任务而是长期需求那每次手动下载打包就太低效了。更成熟的做法是在内网维护一个本地镜像源定期从上游同步所有离线机器都指向它。--download-only在这个体系里退居为临时补包的工具日常靠镜像源解决。6.1 用 apt-mirror 或类似工具做内网镜像apt-mirror这类工具能把上游源按架构、按组件同步到本地目录配合 Web 服务或文件共享暴露给内网机器。配置核心是mirror.list指定上游地址、要同步的发行版和组件、本地存储路径。同步是增量的第一次全量拉取体积大后续只拉变化部分。这套方案的价值在于内网机器apt-get update apt-get install的体验和外网一致依赖解析、版本管理全部由 apt 原生处理不需要人工算闭包。代价是需要一台常开的同步机和足够的存储以及定期维护同步任务。6.2 镜像源和 download-only 的分工两者不是替代关系。镜像源解决常规安装--download-only解决镜像里没有的包或临时应急。比如某个第三方软件只提供了 deb 下载链接没进官方源那就用--download-only或直接 wget 拿到 deb丢进本地源目录重新生成索引内网机器就能装了。我通常的做法是本地源目录留一个extras/子目录专门放这类手工补充的 deb和镜像同步的目录分开避免同步任务误删。dpkg-scanpackages扫描时把 extras 也纳入索引里就都有了。6.3 签名与信任本地源的安全边界本地源用[trustedyes]跳过签名在内网可控环境下可以接受但如果内网有多个团队共用最好还是给本地源做签名。用gpg生成密钥对apt-ftparchive生成 Release 文件并签名客户端导入公钥。这套流程稍繁琐但能防止本地源被篡改后分发恶意包。对于小团队、机器数量不多的情况[trustedyes]配合严格的目录权限控制只有运维账号能写本地源目录通常够用。安全边界取决于你的威胁模型不必过度设计但要知道自己在放弃什么。6.4 定期清理与磁盘水位管理本地源和 archives 缓存都会持续增长。/var/cache/apt/archives/建议配一个定期清理任务只保留最近 N 天的 deb或者干脆装完就 clean。本地镜像源则要关注同步策略只同步需要的发行版和组件别把整个上游全拉下来。磁盘水位要设告警。我见过因为镜像同步把分区塞满导致同步机本身 apt 操作失败的案例连锁反应很麻烦。给镜像目录单独挂一个分区设 80% 告警线是比较稳妥的做法。7. 几个能立刻用上的实操建议聊了这么多原理和链路最后收几个可以直接落地的习惯都是我日常反复验证过的。第一下载前先 dry-run。apt-get install --download-only -s 包名看一眼闭包确认没有意外的大包混进来再实际下载。这个动作花不了几秒能省下大量搬运和排查时间。第二校验和是标配不是可选项。sha256sum生成和验证的成本极低但能挡住传输损坏这个高频问题。打包脚本里固化这一步别靠人记得。第三本地源方式优先于 dpkg -i 批量装。让 apt 管依赖顺序比人工保证顺序可靠得多。dpkg-scanpackages那几行命令值得背下来。第四下载机和目标机的发行版版本对齐。这是跨版本搬运所有问题的根源与其事后排查库版本不如一开始就在同版本环境里下载。第五清单文件纳入版本管理。哪台机器装了什么、为什么装靠清单留痕。出问题时能快速回溯比翻历史命令靠谱。第六装完清理本地源配置。/etc/apt/sources.list.d/local.list用完移除并apt-get update避免残留配置在后续操作里捣乱。这个细节很多人会忘等到某次 update 报错才想起来。这套东西用熟了之后内网离线装软件就从每次都要折腾半天变成跑个脚本等结果。--download-only本身只是个小参数但它背后串起来的是 apt 依赖解析、缓存管理、本地源构建这一整套能力把这些打通离线环境里的包管理就不再是黑盒。
