隔离网安装为什么难
一句话总结
安装闭路电视难以实现的真正原因是计算依赖性和安装方面是分开的**。计算所需的信息被分成了两边。
为什么需要这个？
请求总是这样来的。“请给我拿一个驱动程序文件。”
收到后输入的话会出现这样的错误。
The following packages have unmet dependencies:
nvidia-driver-550 : Depends: nvidia-kernel-dkms-550 but it is not installable
据说再出去拿那个的话就没有别的了。往返用USB三次左右就过去了半天，携带审议一天只能有一次。
怎么行动
计价和安装的分离
依赖性解决器（depsolver）的输入有两种。
- 存储库元数据全部——哪些软件包提供什么，要求什么
- 安装对象系统的当前状态——已经安装了什么？
封闭网内部没有1号，外部也没有2号。这种分离是问题的本质。
解决办法有两条。
- 移动已解决的结果——从外部计算所需的软件包列表，只携带这些文件。
- 将整个存储库移动——复制元数据，让内部重新计算。
虽然从小开始会先去第一处，但**大多数组织最终会去第二处。**因为重复携带的话，第一种方式的管理成本会急剧增加。
安静地消失的东西
在1号方式中，最危险的是没有错误，安静地退出包裹。
**第一，已经安装的东西在结果中消失。**依赖性计算假设的是“正在计算的系统的当前状态”。已经安装在连接网络设备上的库被处理为“不需要”，从列表中删除，这一事实只有在封闭网络内部才会显现出来。
**第二，版本不同，结果也会不同。**如果连接网设备是24.04，安装对象是22.04，解决结果可能会不同。
第三，忘记了架构。noarch/all如果在arch指定中遗漏包，Python模块或设置包就会全部丢失。
第四，处理弱依赖（Recommends）。 计算时被排除在外，但安装时是默认包含的，所以有时会被要求。也有反对意见。
所以正石是以空根为基准计算的。在apt方面--print-uris首先挑选并审查要收到的列表，--download-only收到后确认那个束缚是否在自己体内闭合(closure)。
完整性——两个不同的问题
关于通过媒体的文件，有两个问题需要问。
| 问题 | 回答 | 工具 |
|---|---|---|
| 传输中是否损坏了 | Check Island | sha256sum -c |
| 这是真的从那边来的吗 | 署名 | GPG验证，dpkg-sig，rpm --checksig |
**仅包含在同一媒体中的校验和码，如果媒体整体变更，校验和码也会一起变更。**所以仅凭校验和码无法保证来源。实质性的保证来自签名。
而且manifest中没有但媒体中包含的文件也需要检查。遗漏会很快暴露为安装失败，但添加的文件却没有人知道。从携带审查的角度来看，这才是更大的问题。
携带记录
打包中不仅要包含文件，还要包含记录。
| 项目 | 例 | 为什么 |
|---|---|---|
| 捆绑ID | gpu-airgap-2026-08-20 |
连接服务器和捆绑包的键 |
| 快照日期 | 2026-08-20 |
在哪个时间点是内容呢？ |
| 对象版本 | ubuntu 24.04 / driver 550.90.07 |
在玹的前提 |
| 生成命令 | apt-get install --download-only ... |
再现的核心 |
| 媒体哈希 | 整个档案的SHA-256 | 媒体单元完整性 |
| 携带时间·负责人 | — | 审计要求 |
6个月后，应该能够回答“这个服务器是在哪个时间点通过内容安装的？”的问题。
携带前制作清单的方法
在闭路电视非法进口中最常见的失败不是不完整，而是丢失。一旦进入就 因为很难再次出现，所以制作清单的方法本身就成为程序的核心。
**人不会设定依赖性。**给软件包管理员说“要安装这个需要什么 问“需要吗”，然后直接写下答案。
# 데비안 계열: 의존성까지 통째로 내려받는다
apt-get install --download-only --reinstall -o Dir::Cache::archives=./pkgs <패키지>
# RHEL 계열
dnf download --resolve --alldeps --destdir ./pkgs <패키지>
# 파이썬: 해시까지 고정해서
pip download -r requirements.txt -d ./wheels --require-hashes
**集装箱图像用摘要形式保存。**用标签保存的话，在外面收到的和里面收到的 使用可能有所不同。
skopeo copy --all docker://registry/app@sha256:... dir:./images/app
--all如果没有这个，只会包含现在这个电脑的架构。携带对象不同
在架构界面中会遇到“manifest unknown”。
**GPU方面版本配对特别严格。**驱动程序、容器工具包、CUDA、框架的 组合必须正确。即使只有一处不正确，也会出现“找不到GPU”，在封闭网络内 不能收到其他版本。在外面试着搭建一次同样的组合然后把那个列表 就那样携带。
**一起记录安装顺序。**创建离线存储库，并指向该存储库 设置好，一起放入按顺序安装的脚本。在里面用手找到顺序 这需要时间，而且无法重现。
**还包括恢复方法。**如果安装驱动程序后出现问题，请恢复到以前的版本。 应该回去，但如果没有之前版本的软件包的话就无法恢复。现在 安装的版本的软件包也一起携带。
在现场相遇的样子
epoch的陷阱。 Debian/RPM都可以在版本前面放epoch（1:550.90.07-0ubuntu1). **文件名中不包含epoch。**但是，在版本比较中，epoch是最优先考虑的。如果只看文件名判断“这个更最新”，可能会出错。这就是为什么需要在manifest中写完整版本字符串的原因。
在下次确认中看到的东西
在接下来的测验中，依赖性计算的两个输入，校验和签名的作用，宣言的 首先区分两向验证。确认判断标准后，从下一个模块开始，从软件包捆绑的 实际生成依赖性图和安装顺序。