今天是2023年10月1日不少实施工程师趁假期在机房加班。手里拿着的要么是银河麒麟V10的安装盘要么是统信UOS的镜像包而面对的却是一台连不到互联网的内网机器。这时候最让人头疼的事就是怎么把deb包干净利落地离线装上去。网上搜“银河麒麟安装软件命令”、搜“统信UOS离线安装deb包”答案七零八落。这篇博客把我自己实测过的完整套路整理出来内容包括怎么提前把依赖链收集全、怎么通过dpkg和apt在本机搞定安装、怎么搭一个可复用的离线本地源以及安装过程里最容易踩的坑。适合正在做信创项目交付的运维工程师也适合在自己电脑上装国产系统想练手的技术爱好者。1. 项目概述与离线安装的成因1.1 为什么离线安装deb包这么麻烦先说一个基础概念。deb是Debian系Linux的软件包格式银河麒麟和统信UOS虽然是国产操作系统但它们都沿用了dpkg/apt这一套包管理机制。所以你在银河麒麟上用的命令和在统信UOS上基本一样这也是本文能同时覆盖这两个系统的原因。麻烦就麻烦在依赖上。一个deb包几乎从不孤立运行。比如你装一个Node.js它的运行时需要一堆lib库装一个MySQL依赖链更夸张动辄二十多个包。这种关系在在线环境里不算事因为apt会自动解析依赖并顺手下下来。但在离线环境里没有这个“自动物流”装一个包容易装完整一套依赖就要提前把所有零件都准备好。可以这么理解在线安装好比叫外卖你只需要下单配送、调料、餐具全有人处理离线安装则是自己去超市采购除了主菜还得按菜谱把油盐酱醋、葱姜蒜一样不落全买回来。如果少了一瓶酱油后厨dpkg就算强行把菜下了锅最后端上来的也是半生不熟的东西。软件能装上却跑不起来就是这么来的。1.2 你的“离线”属于哪一类不同离线场景解决方式完全不同。我在项目里大致把“离线”分成三类场景类型典型环境最合适的方案完全物理隔离保密机房、内网专机目标机完全不联网提前在联网机器上把所有deb下载好做成离线源拷入只允许访问局域网单位内部有apt镜像站或FTP不能访问公网把内部镜像挂载成apt源用apt install在线般操作目标机无外网但有管理通路通过运维通道传文件可以执行命令用dpkg批量安装或临时搭本地源很多人一听到“离线安装”就用dpkg硬装单个包结果报依赖错误后手足无措。实际上只要提前把安装包和它的依赖链都拿到手离线环境的体验可以做到和在线几乎一样。判断自己属于哪一类场景是第一步后面所有准备工作和步骤都会围绕这个判断展开。2. 离线安装前必须做对的4件事2.1 确认目标机架构与系统版本这一步看起来基础但翻车率极高。银河麒麟V10和统信UOS都有多个CPU平台版本常见的有x86_64Intel/AMD、aarch64飞腾、鲲鹏、麒麟、loongarch64龙芯等。一个给x86平台做的deb包放到ARM平台上必然报错反过来也一样。在目标机上执行这三个命令结果一目了然uname -m # 输出CPU架构如x86_64、aarch64 dpkg --print-architecture # 输出软件包架构如amd64、arm64 cat /etc/os-release # 查看系统名称与版本比如x86_64对应的deb架构就是amd64aarch64对应arm64。下载deb包时一定要和这个架构匹配。我见过多次把amd64的MySQL装到飞腾服务器上报了一堆“Architecture not match”却还在反复重试的案例纯属浪费体力。同时要注意系统版本。银河麒麟V10有服务器版和桌面版UOS也有不同的版本号虽然deb包大多通用但少数与内核模块强绑定的软件如网卡驱动、虚拟化工具必须精确匹配版本。下载前尽量去官方源按版本号选择。2.2 找到安全的deb包来源离线环境下的软件来源基本是这些联网机器上通过系统的官方软件源从apt仓库下载软件官网提供的.deb包官方离线升级包或补丁包内部已有环境导出的deb文件。这里必须强调一句优先使用官方源里的deb不要随便从第三方网站下载。互联网上很多所谓“绿色版”“免安装版”的deb里面往往掺着编译时注入的脚本安装时直接以root权限执行等于把系统钥匙交给了来历不明的文件。如果你拿到的安装包来自不可信渠道安装前强烈建议用deepin-elf-verify这类工具验证包签名和完整性。统信UOS官方也有对应的校验工具网上搜“deepin-elf-verify银河麒麟”就能找到用法。判断一个源的真实性可以先在联网机器上查看源配置确认官方仓库地址后再用apt的download功能从仓库里拉包。这样拉下来的deb本质上与服务器上的完全一致签名可查可信度高。2.3 提前把依赖链收集齐全这是整个离线安装成功率的分水岭。收集依赖有两种常见方式我推荐组合使用。第一种简单直接针对单个包apt-cache depends 包名 # 查看依赖列表 apt download 包名 # 下载包本体但这样需要手动逐一下载依赖依赖套依赖时容易漏。更聪明的做法是用apt的打印URI功能把所有需要下载的文件URL一次性列出来apt-get install --print-uris -y 包名 | grep http | awk {print $2} | sed s///g urls.txt拿到urls.txt后在联网机器上用wget循环下载while read url; do wget -c $url; done urls.txt还有一种更省事的方式用apt-get的纯下载模式在联网机器的包缓存里提前存好所有依赖mkdir /tmp/offline_pkgs cd /tmp/offline_pkgs apt-get download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks 包名 | grep ^[ |] | awk {print $2} | sort -u)把这条命令里的包名替换成你要安装的软件即可。它会把主包和所有依赖的deb全部下载到当前目录。这个下载量看着大其实一个中型软件也就几十MB到一两百MB。2.4 介质选择、传输与校验验完架构、拉完依赖接下来就是搬运。最常用的介质是U盘和移动硬盘注意文件系统格式。FAT32不支持超过4GB的单文件如果deb包很大或者软件包泛滥到整个目录加一起超过4GB尤其要小心。建议把U盘格式化成exFAT或ext4再拷贝。拷贝完成后到目标机上用sha256sum做一次完整校验防止传输过程中文件损坏。下面这段代码通常能发现90%的传输问题# 在目标机上对比校验值 cd /media/user/U盘挂载目录 sha256sum *.deb /tmp/checksum_from_media.txt cd /home/user/offline_pkgs sha256sum -c /tmp/checksum_from_media.txt只要有一行显示FAILED就说明有文件在拷贝时损坏了别硬着头皮装。另外下载下来的deb文件名不建议修改apt对包名和版本号有强依赖改名后dpkg虽然能装但apt索引会找不到对应版本后面再做依赖修复时容易出问题。3. 实操三种离线安装核心方法3.1 单包直装dpkg -i安装单个deb最基础也最有限的安装方法命令就一行sudo dpkg -i ./软件包名.deb在目标机上进入deb文件所在目录执行这条命令包就被记录了。如果该包的所有依赖都已经被系统满足它会安静地安装完成。用dpkg -l | grep 包名可以确认是否装好。这套流程最简单适合依赖本来就完整的场景。比如在原来的系统上备份了一个deb包想在新装的同版本系统里恢复又或者这个软件本身很轻量只依赖coreutils这些系统必带的基础库。局限性很明显一旦提示dpkg: dependency problems - leaving triggers unprocessed说明依赖不满足。这时候不要硬着头皮用--force-all那只是在给后续挖坑。后面第五节我会具体说怎么排查依赖问题。3.2 批量安装目录内一次安装所有deb当你已经通过apt download把主包和依赖都下载到了同一个目录最直接的安装方式就是cd /path/to/offline_pkgs sudo dpkg -i *.deb注意尽量不要用dpkg -i a.deb b.deb这种逐个指定包名的做法因为如果a依赖b、b依赖cdpkg会像剥洋葱一样反复检查命令容易中途报错。把整个目录的deb通过通配符一起交给dpkg它会尽量把所有包都置于“待配置”状态相当于一次性处理整条链。如果dpkg还是提示依赖问题可以紧接着执行一次sudo apt-get -f install这个命令会尝试修复破损的依赖。在离线环境下apt可能因为无法从网上拉取依赖而失败但只要依赖的deb文件都在本地执行这条命令往往能依靠本地缓存的deb把依赖补齐。这也是我把“批量下载”和“批量安装”放在一起讲的原因——它们的组合几乎能应付绝大多数软件包。3.3 构建可复用的离线本地源如果你要在一个批次里部署几十台机器或者需要反复安装不同的软件强烈建议在U盘或本地目录里搭一个离线本地源。这个做法的本质是把一个U盘变成你的“微型软件仓库”所有机器都能通过apt从它上面安装。搭建步骤我记录一下实测很稳定。首先在联网机器上安装dpkg-devsudo apt-get install dpkg-dev然后把所有下载好的deb放到同一个目录比如/var/offline_repo用下面的命令生成包索引cd /var/offline_repo dpkg-scanpackages . /dev/null | gzip Packages.gz把整个/var/offline_repo目录连同Packages.gz拷贝到U盘。到目标机上把这个目录拷贝到本地比如/var/offline_repo然后在/etc/apt/sources.list.d/下新建一个本地源配置文件deb [trustedyes] file:///var/offline_repo ./之后正常使用apt即可sudo apt-get update sudo apt-get install 目标软件这就是全文中我最推荐的方法。因为dpkg批量安装虽然快但它不经过apt的依赖数据库安装后系统里并不一定留有完整的软件列表与依赖追踪记录。而用离线本地源经由apt安装依赖关系全部落在系统的数据库里后续卸载、升级都能正常操作。首次搭建花十分钟之后每台机器只要拷贝一次U盘省下的时间不可估量。4. 完整落地案例Node.js与MySQL的离线部署4.1 案例一Node.js离线安装全记录我们团队最近在内网服务器上部署一套前端构建环境需要装Node.js架构是飞腾arm64平台系统是银河麒麟V10服务器版。第一步在联网机器上准备好依赖目录mkdir -p /tmp/node_offline cd /tmp/node_offline apt-get download $(apt-cache depends --recurse --no-recommends --no-suggests nodejs | grep ^[ |] | awk {print $2} | sort -u)第二步把下载好的约二十个deb包连同目录一起传到目标机放到/data/offline_pkgs下。第三步批量安装cd /data/offline_pkgs sudo dpkg -i *.deb这一步的输出来到中间可能会卡在某个依赖上但把包全放在一个目录里dpkg通常能自己调整顺序。装完后验证node -v npm -v如果提示找不到命令检查一下/usr/bin或/usr/local/bin下有没有node的符号链接必要时手动建立链接。另外Node.js的npm在安装后偶尔会报缺少python3、gcc之类这些不需要全部都装只有当你打算本地编译原生模块时才依赖它们。4.2 案例二MySQL 8离线安装全记录MySQL比Node.js麻烦得多动辄二十到三十个依赖包而且很多包之间存在循环引用比如mysql-common和mysql-server互相依赖。在线环境还好离线环境下如果直接用dpkg装很容易陷入“先有鸡还是先有蛋”的报错循环。我用的是本地源方案穿过依赖地狱的体验要好得多。在联网机器上先下载MySQL主包和所有依赖这一步不要再手动列哪些包了直接交给脚本循环下载。然后在同一个目录里执行cd /tmp/mysql_offline dpkg-scanpackages . /dev/null | gzip Packages.gz把整个目录拷贝到目标机的/opt/mysql_repo下。在目标机上创建源文件/etc/apt/sources.list.d/mysql-offline.list写入deb [trustedyes] file:///opt/mysql_repo ./然后执行sudo apt-get update sudo apt-get install mysql-serverapt会自动解析依赖顺序哪怕是看似循环的依赖它也能按拓扑排序逐级安装。装完后的数据目录初始化等工作和在线安装完全一致不会因为来源是离线源而产生差异。顺带提醒MySQL 8在Debian系上的默认认证插件是caching_sha2_password银河麒麟V10和统信UOS与Debian系的兼容性都不错一般不会有问题。但如果你是把Windows客户端连过来记得在初始化时考虑密码策略和认证插件的匹配。5. 常见问题与排查技巧实录5.1 依赖缺失Unmet dependencies这是离线安装的头号敌人。报错往往长这样dpkg: dependency problems prevent configuration of xxx: xxx depends on libssl1.1 ( 1.1.0); however: Package libssl1.1 is not installed.排查思路分四步。第一步列出这个包到底缺什么apt-cache depends 包名第二步确认这些依赖deb是否已经在目录里ls *.deb | grep libssl第三步如果依赖的deb并没有被下载到回到联网机器把漏掉的包补下并重新带着传输。第四步如果依赖已存在但还是报错可能是版本号不满足比如系统里已有libssl1.1.1但包要求libssl1.1.1e以上。这种情况通常是因为不同系统的包版本库基线不同先卸载反复版本再安装或寻找对应版本号的deb包。在离线环境下最忌讳的做法是一看到依赖错误就用dpkg --force-all强行安装。这样系统会记录一个“损坏的已安装状态”后续任何软件管理操作都会卡住连卸载也麻烦。5.2 架构不匹配Architecture not match典型的报错是这样dpkg: error processing package mysql-common (--configure): package architecture (arm64) does not match system (amd64)排查思路非常简单先看目标机架构再对比deb包架构。文件名里一般都有线索比如xxx_1.0_amd64.deb表示给x86_64平台用的xxx_1.0_arm64.deb才是给飞腾、鲲鹏等ARM平台用的。有些人会尝试用dpkg --force-architecture强行装上去我劝你千万别试。装上去的结果是CPU指令不兼容软件运行时会直接段错误比没装还难受。正确做法永远是回到下载源把对应架构的包拿回来。5.3 密钥环与仓库签名校验问题离线环境里搭本地源后经常会遇到apt拒绝使用这个源因为它的GPG签名无法验证。报错通常是这样的The following signatures couldnt be verified because the public key is not available: NO_PUBKEY xxxxxxxx在本地源配置中加上[trustedyes]可以绕过这个校验但这样做有风险——如果离线源里混进了恶意包apt会照单全收。更稳妥的做法是把信任的公钥导入系统。在联网机器上导出公钥然后拷贝到目标机导入# 联网机器上 apt-key export KEYID repo-key.gpg # 目标机上 sudo apt-key add repo-key.gpg对于从官网下载的deb包可以先用deepin-elf-verify验证包签名确认无误后再安装。这条习惯在项目交付时特别重要因为很多安全评测会核查目标机是否按来源可信的软件。5.4 安装完成却打不开软件这一条和依赖、权限都有关。走了离线安装流程后软件装是装上了但启动时报找不到动态库。这时候用三个命令排查which 软件名 # 找到可执行文件位置 ldd $(which 软件名) # 查看动态库依赖哪些not found ldconfig -p | grep 库名 # 检查库是否在系统缓存中发现缺库的常见原因是安装包和库版本不匹配比如安装的软件是面向更高版本系统的在旧系统上缺少新版的glibc。这种跨版本问题在离线环境几乎无法通过装依赖解决属于“依赖版本天花板”问题。处理办法要么找对应系统版本的软件安装包要么检查是否有/usr/local/lib类路径未加入动态库搜索范围在/etc/ld.so.conf.d/下添加配置并用ldconfig刷新。6. 写在后头个人实操心得与避坑清单走完这一整套流程我最大的体会是离线安装deb包失败的人十有八九不是栽在命令上而是栽在“准备”上——架构没确认、依赖没拉全、介质没校验这些都是逃不掉的。根据我自己的实测经验有几个屡试不爽的习惯。第一凡是遇到要批量部署的环境我一定优先搭离线本地源而不是dpkg批量装因为apt数据库能真正记录每个包的来源和状态后续维护少操很多心。第二下载deb包的时候一定要记下当时在联网机器上执行的确切命令和日期方便下次复用同一批包避免混入不同源版本的包。第三U盘传文件后不要急着拔先在目标机上跑一遍sha256sum校验这一分钟的成本能省出后面一整天的排错。最后再分享一个小技巧把常用的Node.js、MySQL、Nginx这些中间件的deb离线包连同sources.list配置和打包说明一起做成一个“离线工具箱”U盘每次遇到新环境直接照着流程跑基本能稳定复现。安装一次就顺手把工具箱补一层时间长了你会发现那些曾经让人头疼的“离线安装”项目其实只是准备阶段的勤奋程度问题。希望这篇从2023年10月1日开始整理的内容能帮你在内网部署时少走几趟弯路。