最近项目里来了一批银河麒麟v10的机器网络环境完全隔离任务是在上面部署一堆业务软件所有deb包只能靠U盘往里搬。听起来像是小众需求实际上做过的朋友都知道内网部署、工控机房、敏感业务环境里这种事情每天都在发生。银河麒麟和统信UOS这两个系统都属于Debian系软件包格式和安装机制一脉相承真上手之后你会发现难点从来不是“怎么装一个deb”而是怎么把依赖链、公钥、架构、版本这些坑一个个填平。这篇文章我按实战顺序整理了一套完整流程从在联网机器上下载deb包到离线机器上安装排错再到批量交付自建本地软件源每一步都有命令、有原理、有现场记录适合正在做国产系统软件适配、内网软件分发或者手里正好有一台离线UOS/麒麟机器想装点东西的朋友直接照着操作。1. 离线安装不是冷门需求内网环境才是常态1.1 为什么会有大量断网机器涉密环境、生产控制网络、金融业务内网这些场景普遍切断了外网连接。数据安全要求摆在那里运维的原则就是能不开通就不开通。还有一类是工控设备和专用终端系统装完可能三五年不动生产环境里出了问题远程通道都没有所有修复只能靠本地介质。在这种环境里很多开发者习以为常的东西会全部失效——apt update连不上源、pip下载超时、npm仓库打不开唯一可行的办法是离线把软件包带进去。我做过的国产系统部署项目里大概一半以上的目标机器都是这类纯内网状态。刚开始也天真过想着能不能临时开放网络装完再断实际执行起来发现根本行不通安全审批流程太长很多环境物理隔离就是物理隔离没有任何讨价还价的余地。所以离线安装不是应急方案而是一项需要好好设计的常规交付能力。1.2 银河麒麟和UOS的Debian血统银河麒麟V10和统信UOS在软件包管理上完全沿用了Debian的dpkg/apt体系。麒麟V10的版本基线大多对应Debian 10Buster统信UOS不同版本分别基于Deepin 20、Deepin 23的底座往下追还是Debian那一套。这意味着在联网机器上能用的包管理逻辑到了离线机器上依然成立只要理解Debian的依赖规则和安装机制两台机器之间的迁移就只是介质传递的问题。但这里有个关键误区镜像系统的血缘接近不等于可以直接拿Ubuntu的软件包硬上。Debian、Ubuntu、Deepin、麒麟之间的核心库版本差异很大跨源安装经常会把系统搞坏。我见过太多人图省事直接下载Ubuntu仓库里的包回来装结果glibc、libstdc这类基础库被联动升级装完之后系统直接起不来。离线环境下系统一旦损坏修复成本比联网环境高出一个数量级。1.3 离线安装的完整闭环离线安装的整体链路并不复杂但每一条链路分支都有隐藏的坑。大致分四步第一在联网机器上把目标软件及其全部依赖下载成deb文件第二通过U盘、移动硬盘或内部文件服务器传递到目标机器第三用dpkg或本地apt源按依赖顺序安装第四验证软件可运行并把过程中踩过的依赖坑记录下来形成清单。前面两步决定“包齐不齐”后面两步决定“装得上装不上”。这篇文章的章节就是按这个链路展开的。下载阶段容易漏依赖、抓错版本拷贝阶段要考虑文件系统和文件大小限制安装阶段要面对公钥校验、依赖缺失、架构不符三个经典问题最后如果机器数量多还得上升到自建本地源的高度。2. 动手前的三连问架构、系统代号和包名定位2.1 架构标识一对就少一半麻烦在动手下载任何deb包之前先搞清楚目标机器的CPU架构。命令很简单uname -m dpkg --print-architecture前者显示内核看到的硬件架构后者是dpkg在软件包管理层面使用的架构标识。在x86机器上通常输出x86_64和amd64在飞腾、鲲鹏这类ARM平台上输出aarch64和arm64龙芯平台上能看到mips64el或loongarch64。很多人第一次接触时会犯迷糊——amd64是不是只能给AMD CPU用不是Intel和AMD的x86_64 CPU在Debian系里统一用amd64标识ARM平台的arm64就是aarch64。uname -m输出dpkg --print-architecture输出常见平台x86_64amd64Intel/AMD 台式机、服务器aarch64arm64飞腾、鲲鹏等ARM架构整机mips64elmips64el龙芯3A/3B等旧平台loongarch64loongarch64龙芯新平台下载deb包时务必严格对应架构列装错了会直接报wrong architecture白忙一场。尤其在国产整机项目里一栋楼里可能同时存在x86和ARM两种机器离线包目录要分开建混在一起后面排查会非常痛苦。2.2 系统代号决定该参考哪条依赖基线架构确认之后还要确认系统版本和Debian基线的对应关系cat /etc/os-release cat /etc/debian_version我见过不少银河麒麟V10的机器/etc/os-release里写着Kylin V10/etc/debian_version里写着10.11这说明它的软件包基线是Debian 10 Buster。统信UOS的家庭版早期对应Debian 10底座Deepin 20.9附近也还是Debian 10切到Deepin 23之后才逐渐往Debian 11靠拢。搞清这个对应关系价值在于去联网机器上下包时你知道应该参考哪个Debian版本的依赖关系。比如目标机的libc6是2.28这是Debian 10的标准版本从Debian 11源里下的包很可能要求libc62.31以上装上去依赖就对不上。后面排错章节我会详细讲这个问题的表现这里先记住一句话离线包的“版本基线”必须与目标系统一致跨基线就是给自己挖坑。2.3 包名定位是最容易被低估的环节包名定位是第一道拦路虎。用户要装的是MySQL网上搜出来一堆“银河麒麟MySQL离线安装包”下载回来一看乱七八糟还不如自己动手老老实实查。我的习惯是在联网机器上先查准确名称apt-cache search mysql-server apt-cache show mysql-server | grep -E ^(Package|Version|Depends|Architecture):apt-cache show的输出里有完整的依赖列表这一行信息在后续下载依赖时会反复用到。如果是单位内部开发的软件直接找发包方要完整的deb包和依赖清单比自己猜包名靠谱得多。还要提醒一点很多软件看起来是deb实际根本不是。Node.js官方提供的是tar.xz二进制包Python的openpyxl、playwright是走pip的包Visual Studio那套是独立安装器。它们的离线方法完全是另一条路线别一并混入deb体系。我见过有人拿着apt download nodejs下载出来的老掉牙版本和官网新版对不上号徒增工作量。3. 联网机器上把deb打包带走三种可靠姿势3.1 apt download单个包的精准搬运在联网机器上下载deb最直接的方式是apt downloadmkdir ~/offline-pkgs cd ~/offline-pkgs apt download mysql-serverapt会解析软件源信息把对应deb文件下载到当前目录而不是放到/var/cache/apt/archives。这个工具的特点是“不做依赖计算”只负责把一个指定包从源里取出来适合已经确定缺哪个包、需要精确补漏的场景。比如后期安装时报缺libaio1就在联网机器上执行apt download libaio1拷过去补上就行。单独用的时候少但它是所有离线下载动作里最基础的一块积木。它最大的好处是产物位置可控、文件名可预期拷贝时不会漏。3.2 apt-get install --download-only一次带全依赖这是离线部署的标配做法。在联网机器上执行sudo apt-get install --download-only -y mysql-server ls -lh /var/cache/apt/archives/执行时apt会做一次完整的依赖计算把所有需要新安装或升级的包下载到/var/cache/apt/archives目录但不实际安装。结果是主包和完整依赖链一次备齐。然后把目录里的deb全部拷走mkdir -p ~/offline-pkgs cp /var/cache/apt/archives/*.deb ~/offline-pkgs/这里藏着离线部署里最容易翻车的一个变量download-only计算出来的依赖清单和当前这台下载机器的已装软件情况强相关。如果联网机器上已经装了某个依赖库apt就不会把它加入下载清单而目标机器上可能根本没装这个库。等你到了离线环境安装时才发现少包那叫一个难受。所以最稳妥的做法是找一台和目标机器系统版本、预装软件情况尽量一致的机器来下载。如果条件不允许就把目标机器上dpkg -l的包清单拿过来跟下载结果逐一比对。我把这个细节放在前面是因为很多人的离线包装到一半缺依赖回头查根因基本都出在这个环节。另外download-only选中的依赖版本还受到软件源配置影响。如果联网机器配的是Ubuntu源下载出来的候选包可能与Debian基线不一致。尽量使用与目标系统对应的源这是离线包能不能用的分水岭。3.3 deb-src 源码包仓库里没有现成包时的兜底有些软件在既定仓库里没有预编译包或者官方只提供源码。这时需要下载源码包并在联网机器上完成构建deb-src http://deb.debian.org/debian buster main apt update apt source 包名源码包下载后会得到三个文件.dsc描述文件、.tar.xz上游源码、.debian.tar.xz打包规则。然后展开并构建dpkg-source -x 包名.dsc cd 包名-*/ dpkg-buildpackage -us -uc -b构建会生成新的deb文件拿到离线机器上安装即可。执行dpkg-buildpackage之前需要把build依赖装齐而这些依赖本身往往也是一大批deb包所以在联网阶段就要一并download-only出来备用。这种方式一般只在找不到二进制包时才用。我遇到过内网要装一个小众音视频处理库官方只发源码包最后就是靠这条路在联网机器上编译出deb一次性成功。它的代价是需要干净、完整的构建环境如果目标机器上还要继续编译那build依赖也要一起带过去工程量瞬间变大。三种下载方式的定位可以简单对比方式核心命令依赖处理适合场景单包下载apt download 包名不带依赖补缺、精确获取某个包全家桶下载apt-get install --download-only自动计算并下载完整应用离线搬运源码构建apt sourcedpkg-buildpackage手动准备build依赖仓库无现成二进制包4. 目标机器安装的核心战场依赖关系和安装顺序4.1 dpkg -i *.deb 一把梭的真相把deb包拷贝到离线机器后战斗才真正开始。很多人第一反应是执行sudo dpkg -i *.debshell会把*.deb按字典序展开成参数序列dpkg再按这个顺序逐个处理。问题在于字典序和依赖顺序完全不是一回事。比如a包依赖z包但a.deb的字典序排在z.deb前面dpkg先装a依赖不满足报错一片继续装z又提示前面的a还没配置好。运气好的话最后用apt -f install能收尾运气差的话dpkg的数据库状态就乱了。要理解这个现象得先明白dpkg的定位它是个很“笨”的工具只负责解包、写进数据库、执行维护脚本不检查依赖是否满足。真正管理依赖的是apt但apt在离线环境没有可用软件源于是出现了一个真空地带dpkg有能力装但不知道顺序apt知道顺序但没有源可用。离线安装策略的核心就是想办法把这个真空地带补上。4.2 两条靠谱的安装路径第一条路径按依赖顺序手动安装。下载阶段如果用的是download-only可以在联网机器上把依赖关系导出一份带过去apt-cache depends mysql-server然后从依赖底层往上逐层执行dpkg -i。思路很简单包少的时候很管用包多了就考验耐心。实际项目里我通常先把这批包里的顶层包找出来再一层层往下清依赖相当于手动模拟一遍apt的解析过程。第二条路径更省心把离线目录伪装成一个最小本地源让apt自己解析依赖。操作如下cd ~/offline-pkgs apt-ftparchive packages . Packages sudo apt update sudo apt install -y mysql-serverapt-ftparchive会扫描当前目录的deb文件生成Packages索引。apt update读取这个索引后就能在本地目录内闭环解析依赖把dpkg的笨重和apt的智能结合起来了。这是我在单机离线安装中最常用的方式比手动按顺序敲命令省太多事。唯一需要注意的是当前目录如果缺某个依赖包apt会尝试从外部在线源补所以安装前最好把/etc/apt/sources.list里的在线源临时注释掉避免它去外网碰运气。如果apt-ftparchive不在系统里先装apt-utilssudo apt install apt-utils4.3 一个完整场景离线装MySQL 5.7.44拿网上经常搜到的“银河麒麟V10 SP2服务器版安装MySQL 5.7.44”举例。这类任务在离线环境里非常典型。在联网机器上如果默认源里已经没有5.7版本需要先配置MySQL官方的APT源然后再执行sudo apt-get install --download-only -y mysql-server-5.7下载结果通常包括mysql-server、mysql-client、mysql-common、libmysqlclient21以及libaio1、perl、libmecab2这类“看起来和MySQL没关系”的底层依赖。很多人手动下包时最容易漏掉这些小依赖而download-only在计算阶段已经自动补齐了这就是我推荐它的核心原因。包拷到离线机器后我用本地源方式安装。装完验证sudo systemctl status mysql mysql -uroot -p能正常进入MySQL命令行这个离线部署就算闭环了。整个过程中凡是用dpkg -i硬装的十有八九会卡在某个看似无关的小依赖上凡是走本地源方式的基本一次通过。5. 离线安装报错现场密钥、动态库和版本冲突排查全过程5.1 NO_PUBKEY公钥缺失的完整处理链路离线环境里最典型的报错是apt update或安装过程中出现The following signatures couldnt be verified because the public key is not available: NO_PUBKEY 1234567890ABCDEF根因是deb仓库在生成Release文件时用仓库私钥做过签名系统里没有对应的公钥apt默认不信任这个源拒绝使用。在线环境下一条命令就能拉取公钥离线环境下只能走“导出再导入”的路子。在联网机器上导出公钥gpg --export 1234567890ABCDEF pubkey.asc apt-key export 1234567890ABCDEF pubkey.asc把pubkey.asc拷到离线机器后执行sudo apt-key add pubkey.asc麒麟V10和UOS系统大多还兼容apt-key方式。如果系统较新、使用signed-by方式就把导出的公钥文件放到/etc/apt/trusted.gpg.d/或对应源的keyring位置并在sources.list里加上signed-by/usr/share/keyrings/xxx.gpg参数。这里有一个经验公钥缺失往往在apt update阶段就暴露了别等到安装时才发现。离线机器上第一次配置源之后先跑一遍apt update把密钥问题提前解决掉比装到一半再回头处理痛快得多。5.2 动态库缺失ldd告诉你还差谁另一个高频报错是软件装完后启动时报error while loading shared libraries: libxxx.so.1: cannot open shared object file这说明主包已经装上了但它链接的动态库不在系统里。排查链路分三步第一步用ldd查看可执行文件的依赖ldd /usr/bin/你的程序第二步记下显示not found的库名在联网机器上查这个库属于哪个包apt-file search libxxx.so.1输出结果类似libxxx1: /usr/lib/x86_64-linux-gnu/libxxx.so.1意思是这个动态库由libxxx1这个包提供。第三步把这个包下载下来带回去装上。价格不贵但动态库缺失最让人头疼的还不是安装本身而是它往往意味着下载阶段漏了依赖。漏掉的原因通常是下载机器上恰好有旧版本库download-only认为已经满足就不列进清单目标机器却没这个库。所以对于直接通过dpkg -i安装的包事前做一遍全量ldd检查很有必要。5.3 版本冲突和架构报错版本冲突的典型报错是The following packages have unmet dependencies: mysql-server: Depends: libc6 ( 2.31) but 2.28-10 is installed这种基本是跨源下载造成的目标系统里libc6版本低你下载的包是从更高版本Debian源拿的运行库要求高于目标系统基线。解决办法只有一个——换成与目标系统Debian基线一致的源重新下载。硬刚的话升级glibc极有可能把整台系统搞挂得不偿失。架构报错更直观dpkg: error processing archive xxx_amd64.deb (--install): package architecture (amd64) does not match system (arm64)下载阶段没看架构标识装上去必然报错。在飞腾、鲲鹏、龙芯这类平台上尤其常见下包前用dpkg --print-architecture确认一遍比事后折腾高效得多。批量部署时我还会给离线包目录直接按架构命名比如pkgs-amd64、pkgs-arm64从源头上杜绝拿错包。6. 单机交付升级到批量交付自建本地软件源才是终局方案6.1 为什么单机拷贝不可持续单台机器用U盘来回拷贝还能忍到了几十台、上百台机器或者软件需要持续更新版本的阶段“离线目录加U盘”的方案就撑不住了。每次版本迭代都要重新准备一轮离线包挨台机器跑光是拷贝和核对哈希就能耗掉大量时间。批量项目里最终方案一定是自建本地软件源内网机器通过apt install正常安装软件唯一的区别是源地址指向自己的服务器。6.2 用apt-ftparchive搭建简易本地源先在一台内网服务器上建一个目录把搜集到的deb包全部放进去cd /srv/apt-repo apt-ftparchive packages . Packages apt-ftparchive release . ReleasePackages文件记录了每个deb的名字、版本、架构、依赖、大小和校验信息apt全靠它解析依赖Release文件是这个仓库的元信息。之后把/srv/apt-repo通过nginx或httpd发布出去。客户端配置sudo tee /etc/apt/sources.list.d/local.list EOF deb [trustedyes] http://内网IP/apt-repo ./ EOF sudo apt update sudo apt install -y 你的软件两个细节必须说清楚。第一源路径末尾的./不能丢它表示Packages文件就在当前目录。第二[trustedyes]的作用是跳过GPG签名验证——自建仓库默认没有签名公钥不加这个参数apt update会直接拒绝。如果安全要求必须签名就用自己的GPG私钥给Release文件签名再把公钥发给所有客户端导入。6.3 用reprepro管理多版本和增量发布简易本地源在软件少、更新频率低的场景够用。软件多了需要分main、updates组件还要管版本回滚apt-ftparchive就吃力了。这时候推荐repreproreprepro -b /srv/apt-repo --component main --architecture amd64 includedeb buster ./你的软件_1.0_amd64.debincludedeb会把deb导入仓库自动更新Packages和Release索引同时维护多个发行版和多个组件发布、删除、导出都很规范。我在一个跨系统项目里同时维护了Debian 10底座的麒麟源和Debian 11底座的UOS源客户机分别配不同路径增量发布时一条命令就能完成。6.4 内网批量环境的配置纪律批量部署时目标机器最好统一镜像、统一架构。一个arm64源和一个amd64源要分开维护混用会立刻引发“wrong architecture”满天飞。另外如果内网机器之前配置过外部在线源记得注释掉或在/etc/apt/sources.list.d/里删除对应文件只保留本地源这样才能保证离线环境的纯粹性。批量机器的软件源配置建议通过脚本或配置管理工具统一下发避免人工一台台改漏。7. 实操沉淀下来的几条经验7.1 下载机器的系统基线是最容易翻车的变量离线包不是“有就行”而是“和你的目标环境同源”才行。我吃过一次亏在一台Ubuntu 22.04上给麒麟V10准备离线包download-only把一堆Ubuntu的新版本库带了出来拷到麒麟机器后libc6冲突整批白干。后来老老实实找了一台与目标系统Debian基线一致的机器做下载一次成功。现在我的习惯是接离线任务的第一件事就是问清楚目标机的系统版本和预装环境然后照着这个状态去准备下载环境。7.2 介质和哈希拷贝环节最容易被忽略FAT32格式的U盘不支持单个超过4GB的文件MySQL全家桶偶尔会有大包内部大型软件更明显。要么换exFAT或NTFS要么把离线目录拆成多个子目录分批拷。拷完之后第一件事是校验哈希sha256sum *.deb sha256.txt到了目标机器上再比对一遍能避免U盘拷贝过程中文件损坏带来的“灵异安装失败”。这个动作看起来多余但确实救过我一次——一个十几GB的离线包目录拷到一半U盘出问题个别文件静默损坏不校验的话装到一半才发现排查起来非常费劲。另外提醒一下拷贝完成后别急着拔盘先看一遍df -h确认剩余空间很多离线包体积大目标机器磁盘太满也会导致安装失败。7.3 认清软件打包形态别被deb思维绑架最后一条经验来自项目里反复出现的错位Node.js装的是tar.xzPython的包走pipVisual Studio是独立安装器Docker离线部署要导镜像。每个生态都有自己的离线方法论不能拿着deb的锤子砸所有钉子。处理这种事情我的顺序是先确认软件官方有没有离线安装包没有的话再看它是基于什么运行时——如果是Python就准备pip download的wheel包目录如果是Node就准备好npm pack或直接搬运node_modules如果是C生态就看静态链接版本实在不行再考虑源码编译或容器镜像。定好路线再动手比到目标机器上才发现装法不对要舒服得多。7.4 最后补一个实用小技巧批量部署前把目标机器上的dpkg -l导出成清单和准备带入的离线包目录做个对照。重点看两件事目标机器哪些包已经存在、哪些包会触发升级。某些基础库一旦升级到更高版本可能连带影响其它业务软件这种事前发现比事后补救划算得多。我后来养成了习惯每次做完一批机器都会把这个对照清单存档下次同类项目直接复用省掉一大半试错成本。