Kylin离线安装deb包全攻略：从依赖收集到本地源搭建

1. 离线环境下的核心挑战与整体思路1.1 为什么说离线安装最怕的是依赖地狱Kylin系统在国内的政企、军工、金融这些行业里出现频率很高不管你是运维还是开发迟早会在它上面部署中间件、数据库、监控采集器、OCR软件这类东西。大多数情况下你拿到手的是rpm或者tar包稍微好点的会给你deb包但真正让整套安装卡壳的从来不是软件本身而是它的一长串依赖。我记得有一次在内网环境装fluent-bit这个工具本身几十MB结果debian依赖链拖出来二十多个包从libyaml到libsystemd少一个就给你甩脸色。离线环境的本质问题是你没有办法用现成的apt源实时拉依赖。所以在没有网络的机器上做dpkg部署核心不是“会敲dpkg -i”而是先把依赖关系搞清楚、把所有需要的deb包找齐、再按正确的顺序装进去。这个过程一旦理顺几百台机器批量部署也就变成一个拷贝粘贴的活。这也是我写这篇文章的原因我把从环境摸底、依赖收集、打包运输到本地源搭建的全流程拆开讲尽量让你照着我做就能少踩坑。1.2 两种主流部署方案的取舍先说结论Kylin离线部署deb包有两种主流做法分别对应不同规模第一种是“单机小批量依赖包安装”适合只部署一两台机器、安装的软件本身依赖不复杂的情况。核心做法是在一台联网的同版本Kylin机器上用apt download把依赖包全部下载下来拷贝到离线机器后dpkg -i批量安装。优点是轻量、不污染系统缺点是如果你要装的东西有几十上百个依赖手工管包会比较累。第二种是“搭建本地deb源”适合几十台以上的批量部署或者你需要反复往不同机器上装同一套软件。它的思路是在离线环境里建一个目录把所有deb包放进去运行dpkg-scanpackages生成索引再把这个目录配置成apt源这样离线机器就可以像在线一样用apt install装软件依赖自然会被解析。优点非常明显缺点是需要多几个步骤去初始化源。我的经验是如果你只是应急装上fluent-bit、某个OCR软件用第一种如果要在一批新交付的Kylin服务器上落地一套技术栈直接上第二种。后面我会把两种方式的每一环都讲清楚。2. 动手前的准备工作环境和依赖关系梳理2.1 先确认架构和系统版本别在第一步就装错包Kylin系统最常见的是Kylin Linux Advanced Server V10它有两个大版本分支一个是x86_64架构另一个是arm64架构也就是常说的大飞腾、大鲲鹏。你如果误把x86_64的deb包拿到arm64机器上装dpkg会直接报“Architecture: amd64”不匹配这种错很低级但特别好犯尤其是从网上下载包的时候很多人看到Kylin V10就下载没注意架构。所以开工前先把环境名敲出来uname -m cat /etc/os-release如果输出是aarch64那你后面的所有下载命令都必须带architecturearm64如果是x86_64就对应amd64。另外一点要留意系统小版本差异比如V10 SP1和SP2的源可能不一样最好让下载依赖的那台联网机器和离线目标机保持同一小版本。如果找不到一模一样的版本退一步也要保证系统源和内核版本差异不大否则个别依赖的版本号会卡得很死。2.2 用一个联网的同版本机器收集依赖信息离线部署最省心的前提是你手上有一台能联网且系统版本尽量一致的Kylin机器它的作用是做依赖分析和包下载。没有的话你只能手动从第三方镜像站下载麻烦且容易漏所以项目开始前先协调这样一台“跳板机”非常值得。拿到机器后我习惯先把apt源更新一遍确保索引是最新的然后再动手分析要安装的软件。比如要离线安装fluent-bit可以在联网机器上先尝试安装一下让apt把依赖关系暴露出来apt-get install -y fluent-bit如果直接安装成功那这台机器上已经把这个包的所有依赖都拉下来了。接下来你可以用apt-cache depends查看它的依赖项也可以从/var/cache/apt/archives里把缓存下来的deb包全部捞出来。实际部署中不一定每个软件都能直接装成功所以更多时候我采用下一节的方式用命令精确下载依赖包。2.3 用apt-rdepends把依赖树摸透有依赖树工具会方便很多我常用apt-rdepends它能递归列出某个包的所有依赖比apt-cache depends一层层看高效很多。联网机器上先装上apt-get install -y apt-rdepends然后分析目标包apt-rdepends fluent-bit输出结果会包含一大堆包名里面既有Depends声明也有PreDepends甚至还有Recommends。这个输出比较冗长我一般会加一个过滤只保留deb包名并且排除已安装的包这样下载任务就精确多了。从中还能发现一些Kylin系统自带但版本偏老的依赖包这时候就要做版本对比避免下载了不兼容的高版本。我自己的经验是这一步不要偷懒。你在这里花十分钟看清楚依赖后面离线机器上就不会反复出现“依赖缺失”的连环报错。3. 高效实用依赖包批量下载与离线安装3.1 用apt download代替手动找包拿到依赖清单后最直接的做法是逐个用apt download下载。这个命令会在当前目录下载deb包但不会安装它非常适合离线打包。我先建一个干净的目录比如/opt/debsmkdir -p /opt/debs cd /opt/debs如果依赖数量多手工一个包一个包敲不现实我习惯把apt-rdepends的结果做一次循环下载apt-rdepends fluent-bit | grep -v ^ | grep -v ^$ | sort -u | while read pkg; do apt-get download $pkg 2/dev/null || echo skip: $pkg done注意这里面有个细节apt-rdepends的输出里有包名和依赖关系混在一起有的行带缩进有的行带版本号所以我把输出做了文本过滤实际执行前我会先打印清单检查一遍。另外一些包可能已经缓存过或者版本冲突下载失败也可以先记下来后面统一解决。下载完检查一下数量ls /opt/debs | wc -l你会发现一个package的安装包数量可能比自己预想多很多这就是依赖的累积效应。目录里除了目标软件还会有libc相关的底层库、系统组件这些统统是拷贝到离线环境时需要的。3.2 拷贝到离线机器后的安装顺序和标准操作包到了离线机器后安装顺序是个技术活。理论上dpkg不会自动处理依赖所以缺了父包就装不下去。最笨但最稳的办法是把所有deb包放到同一个目录然后反复执行dpkg -i让系统自动跳过还缺依赖的包等前置包装好后再补装cd /path/to/debs dpkg -i *.deb如果一次没有完全成功再执行一遍直到没有报错为止。原因很简单第一轮dpkg会把能装的都装上第二轮时前置依赖已经就位剩下的包就能正常解包安装了。两轮还不行的说明某些包真的缺少依赖或版本不对这时候优先用apt-show-versions对比版本或查看具体报错信息。我推荐的干净做法还是把本地源搭起来再装这个后面讲。但如果只是应急你可以搜索是否有预先做成all-in-one的离线包很多在Kylin生态里混的老手会自己维护一套常用软件的deb依赖目录遇到同类需求直接打包带走。3.3 实操案例给Kylin arm64离线装fluent-bit拿fluent-bit举例它是一个日志采集器常用于EFK和Prometheus监控体系里。公司内网环境用的是Kylin Linux Advanced Server V10 arm64版没有外网我得在几十台机器上部署fluent-bit。我在联网的arm64 Kylin机器上执行apt-cache policy fluent-bit apt-rdepends fluent-bit /tmp/fluent_deps.txt下载依赖到/opt/fluent-bit-debs后我检查了一下发现里面包含了libyaml、libsystemd、libpq等常见依赖包。把这些包打成tartar czf fluent-bit-offline-debs.tar.gz /opt/fluent-bit-debs离线机器上解压后我先执行dpkg -i第一轮确实有包因为依赖未满没装上但第二轮后所有包就位fluent-bit服务也能正常启动了。整个过程大概十分钟比之前我手动一个个找包快得多。3.4 安装后如何验证依赖完整性装完之后别急着跑业务先看看系统里有没有“半安装”的包dpkg -l | grep ^iU\|^iF\|^iH如果出现iU或iF状态说明某些包处于异常状态。修正办法是再跑一次dpkg --configure -a或dpkg -i --fix-broken。更稳妥的做法是apt-get check它会把所有依赖问题统一列出来比凭感觉排查靠谱。对于生产环境我还会额外记录每个包版本方便后续变更时对照。4. 进阶搭建本地deb源让大批量部署事半功倍4.1 为什么要从“拷贝安装”升级到“本地源”在Kylin这种国产系统上如果你只装一台两台dpkg -i的方式够用。但当你面对一批新交付的机器每台都要装同一套软件栈的时候反复拷贝deb包再dpkg -i就很痛苦。更麻烦的是dpkg -i不管依赖解析装到一半日志一长串很容易漏掉某个包。所以真实生产环境里我会直接搭建一个本地deb源。本地源的好处有三个第一apt install会自动解析依赖不再需要手工维护安装顺序第二同一个源码目录可以被很多机器共享部署时只要配置一次sources.list第三后续往源里补充新包非常方便下次部署直接apt update就能看到新版本。对于Kylin Advanced Server这种要频繁出环境的系统来说这招几乎是必备技能。4.2 用dpkg-scanpackages生成索引文件本地源的核心就是让apt认识你的deb目录方法是在目录里生成一个Packages索引。先安装dpkg-devapt-get install -y dpkg-dev然后把所有deb包放到一个固定目录比如/opt/kylin-local-repo再执行cd /opt/kylin-local-repo dpkg-scanpackages . /dev/null | gzip Packages.gz这里面的/dev/null是覆盖文件列表参数我们不需要记录原始deb来源所以传空。生成Packages.gz后目录就成了一个可被apt识别的最小仓库。为了让apt读取更顺手我习惯同时生成一个Release文件但这个不是强制要求。4.3 离线机器上配置sources.list并安装打开离线机器上的/etc/apt/sources.list在末尾加入本地源deb [trustedyes] file:/opt/kylin-local-repo ./或者更规范的写法是用/etc/apt/sources.list.d/local-repo.list新建一个文件内容一样。加完执行apt-get update然后你就能像在线环境一样安装了apt-get install -y fluent-bitapt会从本地源里读取依赖信息并自动处理。如果以后你有新的deb包要加直接把包丢进目录重新执行一遍dpkg-scanpackages并更新Packages.gz即可。这个流程也是很多企业内部软件源镜像的简化版思路。4.4 本地源配合HTTP服务给几十台机器同时使用如果机器数量多我建议把本地源目录用Nginx或Python的http.server共享出去比如cd /opt/kylin-local-repo python3 -m http.server 8080这样其他离线机器只要把源地址改成deb [trustedyes] http://源服务器IP:8080/ ./就能统一从源服务器拉取依赖。这种方式把“部署依赖”这件事变成了一次服务器配置非常适合批量交付。需要注意的是生产环境的防火墙策略要放行对应端口并且尽量在内网稳定的服务器上跑源服务。5. 常见问题与排查技巧实录5.1 遇到waiting for cache lock或者could not get lock该怎么处理很多人在Kylin上遇到过这个提示E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock出现这个的原因是有另一个apt或dpkg进程还在运行。新手看到这个多半会慌张以为系统坏了。排查方法很简单先看是谁占着锁ps aux | grep -E apt|dpkg如果确实有apt进程在执行等它跑完就好如果没有进程了可能是上次异常退出留下的锁文件。此时可以确认安全后手动删除锁文件但注意不要随意删除先检查进程是否真的不存在sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock sudo dpkg --configure -a这个操作我一般放在最后的手段而且操作完要立刻检查dpkg状态避免残留半安装包影响后面的部署。5.2 提示“Depends: xxx but it is not installable”的原因与对策离线环境下这类报错特别常见。它通常意味着deb包本身没问题但它的某个依赖既不在当前系统的已装列表里也不在你提供的下载目录中。这时候不要盲目重装先把报错里提到的包名记下来回到联网机器上单独下载apt-get download 缺失的包名还有一个容易被忽略的坑有些包依赖的是“虚拟包”或由多个包提供的公共接口比如default-jre这种虚拟包。你包的来源里可能没有对应实现这时候需要找到具体提供者比如openjdk-11-jre-headless。一旦遇到这种问题用apt-cache search去找实现包再把它加入本地源即可。5.3 架构不匹配和版本冲突的典型报错架构不匹配的报错长这样dpkg: error processing package xxx (--install): package architecture (amd64) does not match system (arm64)解决方案没有捷径只能去下载正确架构的deb包。版本冲突则常见于目标软件要求libc6 2.34但Kylin自带的libc6版本偏低。这种时候你有两个选择要么找该软件更早的兼容版本要么升级系统库但升级系统库风险很大可能影响现网应用。我的建议是优先选软件版本除非你非常清楚系统升级的影响面。5.4 版本优先级导致的源污染问题如果既配置了local源又保留着外网源在离线环境中很容易出现apt挑到过期的第三方源。所以离线机器的sources.list里我会注释掉所有外网源只保留本地源。就算保留也要让本地源的优先级更高用apt-pin配置cat /etc/apt/preferences.d/local-repo EOF Package: * Pin: origin Pin-Priority: 1001 EOFPin-Priority设为1001高于普通源的500apt就会优先选用本地源的版本。这个小技巧可以避免隔三差五出现“为什么装的是旧版”的困惑。5.5 多架构库混用Multilib的问题Kylin上有些业务组件是32位和64位混合的比如某些银行客户端、车控软件。安装32位deb包时dpkg经常会告诉你需要i386架构支持而系统默认只启用了arm64或amd64。这时需要添加架构支持但离线模式下往往没有对应的multiarch源非常麻烦。解决思路是事先在联网机器上把对应架构的deb依赖一起拉下来然后利用dpkg --add-architecture i386添加架构支持再安装对应包。这一步极容易出问题如果不是明确需要我不会随便在Kylin服务器上启用多架构。5.6 爆出非零状态码但日志不明确的排查思路碰到dpkg返回非零状态码但日志藏在deep里的场景有个快速定位技巧。记住任何安装报错第一件事不是查日志而是看dpkg缓存find /var/lib/dpkg/info -name *.list | xargs grep -l 故障关键字处理这种问题没别的诀窍从dpkg输出和apt-cache policy的输出两条路走基本能定位到具体包。还有一点别忽略安装脚本失败的情况。部分deb包在postinst脚本里做环境检测或服务启动脚本失败会导致安装失败。这时把/etc/dpkg/dpkg.cfg里的日志打开或者用sudo dpkg --configure -a -o DPkg::Options::--force-confold可以保留旧配置避免脚本交互中断。6. 实操总结与个人经验6.1 不同规模环境下的策略选择我把这几年在Kylin上离线部署deb依赖包的经验归纳成一套选择逻辑单机临时安装、依赖数量少于20个的用apt download加dpkg -i生产环境或者批量交付超过10台机器的一开始就配置本地deb源如果是长期需要反复部署的技术栈比如监控全家桶、大数据组件那就连HTTP源一起搭好后续所有机器都能共用。这样做最大的收益不是省了一次拷贝而是把部署变成标准的apt install再也不用天天和依赖打架。6.2 几个让我少走弯路的细节一是所有下载的deb包来源保持同源不要今天从A镜像拉一批明天从B镜像拉一批混着用容易遇到依赖版本不一致。二是拷贝deb包到离线机器后先执行md5sum校验再用dpkg -i安装防止传输过程中文件损坏。三是建立一个软件包版本清单记录每个软件包和依赖包的版本后续排查问题时能快速知道系统处于什么状态。最后还有个小习惯我在本地源目录里会放一个README写上这个源是什么时候构建的、支持哪些软件、来源是哪里。看似多余但过了半年再来看这个源的时候你会感谢当初的自己。