包管理与基础服务

• BIOS+MBR 启动流程
• UEFI+GPT 启动流程
• 差异

BIOS+MBR 启动流程：BIOS 自检 → BIOS 读取 MBR（第一个扇区，512 字节，含引导程序 + 分区表）→ 加载引导程序（GRUB stage1）→ stage1.5 → stage2 加载内核 → initramfs → 挂载根 → init。MBR 分区表最多 4 主分区、2TB 限制。UEFI+GPT 启动流程：UEFI 固件 → 读取 ESP（EFI System Partition，FAT32）→ 从 ESP 加载 EFI 引导程序（GRUB UEFI 版）→ 加载内核 → initramfs → 挂载根 → init。GPT 支持 >2TB、更多分区、有备份分区表。差异：一是固件接口（BIOS vs UEFI），二是引导方式（MBR 扇区 vs ESP 上的 EFI 应用），三是分区表（MBR vs GPT），四是设备支持（GPT 支持大磁盘）。UEFI+GPT 是现代标准，支持安全启动（Secure Boot）、更大磁盘、更快启动。调试：UEFI 用 efibootmgr 查看启动项，GRUB 用 grub2-mkconfig 生成。

核心是"固件 + 引导 + 分区表"。BIOS 读 MBR 引导，UEFI 从 ESP 加载 EFI 应用，GPT 支持大磁盘与安全启动。

• dpkg -i 不处理依赖
• apt install 解析依赖
• 差异

dpkg -i 直接安装 deb 包，不做依赖解析（不自动安装依赖、不检查依赖是否满足），若依赖缺失会报错（"dependency problems"）或留下半配置状态；apt install 通过 apt 仓库索引解析依赖，自动安装缺失的依赖包（从仓库下载），保证依赖满足。差异：dpkg -i 是底层安装工具（不处理依赖），apt install 是上层（自动解析依赖）。安装本地 deb 包：若需依赖处理，用 apt install ./local.deb（apt 会解析依赖）；若用 dpkg -i 需手动 apt-get -f install 修复依赖。实践：本地 deb 包用 apt install ./pkg.deb（自动处理依赖），或 dpkg -i 后用 apt-get -f install 修复。dpkg 适合无依赖的简单包或需精确控制；apt 适合需要依赖解析的场景。

核心是"是否解析依赖"。dpkg -i 不处理依赖可能半配置，apt install 自动解析并安装依赖，本地包用 apt install ./pkg.deb。

• half-configured 状态
• 触发器失败
• 修复

dpkg 安装中断（如断电、进程被杀）会留下 half-configured（半配置）、half-installed 等状态，或触发器（triggers）处理失败。修复路径：一是 dpkg --configure -a（配置所有未配置的包，处理半配置与触发器）；二是 apt-get -f install（修复依赖与破损包）；三是查看失败包 dpkg -l | grep ^iF（识别半配置），dpkg --configure <pkg> 单独配置；四是若触发器失败，重跑 dpkg --configure -a 或清空触发器缓存（/var/lib/dpkg/triggers）；五是极端情况 dpkg --force-... 强制或移除损坏包。路径：先 dpkg --configure -a，再 apt-get -f install，最后单独处理问题包。注意不要随意删 /var/lib/dpkg 状态文件。触发器失败常因 postinst 脚本失败，需看日志定位。

核心是"修复半配置与触发器"。用 dpkg --configure -a 处理半配置，apt-get -f install 修复依赖，定位失败包。

• 底层包工具 vs 高层包管理器
• 依赖解析
• 差异

dpkg 与 rpm 是底层包安装工具（.deb/.rpm），不做依赖解析，只负责安装/卸载/查询单个包；apt（Debian 系）与 yum/dnf（RHEL 系）是高层包管理器，基于仓库索引自动解析依赖、安装依赖包、处理升级。差异：dpkg↔rpm 是底层（直接操作包、无依赖），apt↔yum/dnf 是上层（依赖解析、仓库管理）。dnf 是 yum 的下一代（RHEL 8+，性能/依赖更优，取代 yum）。关系：apt 用 dpkg 做底层，dnf/yum 用 rpm 做底层。选型：底层精确控制用 dpkg/rpm，日常安装/依赖用 apt/dnf。依赖解析：apt/dnf 用仓库元数据解依赖，dpkg/rpm 手动。dnf 比 yum 更快、依赖解析更健壮（libsolv）。跨系：Debian 用 apt/dpkg，RHEL 用 dnf/yum/rpm。

核心是"底层 vs 高层 + 依赖解析"。dpkg/rpm 底层无依赖，apt/dnf 高层自动解析，dnf 取代 yum。

• CentOS Stream 定位
• RHEL 发行节奏
• 差异

CentOS Stream 是 RHEL 的"滚动发行"中间版本，位于 Fedora 与 RHEL 之间：CentOS Stream 是 RHEL 的"开发预览线"，持续接收上游更新，比 RHEL 更早包含新功能，是"滚动的 pre-release"；RHEL 是稳定发行版，按固定版本周期（如 8.x、9.x）发布，每个版本长期维护（10 年），特性稳定。差异：CentOS Stream 滚动更新（更接近上游、更新快），RHEL 版本化稳定（长期维护、变更保守）。CentOS 8 之后，CentOS Linux 转为 CentOS Stream，不再作为 RHEL 的免费重建版，而是 RHEL 开发中间线。生产环境：需要稳定长期维护用 RHEL（或兼容发行版），追求快速跟进用 CentOS Stream。工程影响：CentOS Stream 的更新节奏/维护策略与 RHEL 不同，需评估稳定性。

核心是"滚动预览 vs 稳定版本"。CentOS Stream 是 RHEL 的滚动开发线，RHEL 是版本化长期维护，稳定性不同。

• GPG 签名原理
• 包签名校验
• 完整性

GPG 包签名用公钥/私钥：发行方用私钥对包内容签名（哈希），使用者用公钥验证签名。校验流程：导入发行方 GPG 公钥（如 rpm --import、apt-key）、验证包签名（rpm --checksig、apt 自动校验）、确认签名匹配（验证来源与完整性）。原理：签名是用私钥加密的包哈希，验签用公钥解密哈希并与实际计算哈希比对，一致则包未被篡改且来自持钥方。应用：rpm 用 rpm --checksig pkg.rpm 验证，apt/dnf 配置 GPG key 自动校验仓库包；GPG 校验保证包来源可信（非伪造）与完整（未被篡改）。运维：安装包启用 GPG 校验（gpgcheck=1），导入官方 key，防止供应链攻击。注意：公钥本身需可信（密钥指纹核对），避免信任被篡改的 key。

核心是"公钥验签保来源与完整"。发行方私钥签名、用公钥验签（rpm --checksig），gpgcheck=1 防篡改。

• dnf 取代 yum
• 性能与依赖
• 工程意义

RHEL 8 起用 dnf 取代 yum（yum 命令仍保留为 dnf 的别名/软链）。dnf 基于 libsolv（现代依赖解析库），依赖解析更快、更健壮，支持更丰富的命令（dnf history、dnf module、transaction 管理），性能优于旧 yum（Python 2 实现）。工程意义：一是依赖解析质量提升（libsolv 处理复杂依赖）；二是命令扩展（模块化、历史回滚、事务）；三是性能与维护（dnf 是活跃维护的前端）。迁移：yum 命令在 RHEL 8+ 仍可用（映射到 dnf），脚本可兼容；但新特性用 dnf。运维：用 dnf 管理包（dnf install/update/history），利用 dnf history 回滚，dnf module 选流。注意 RHEL 8 的 yum 是 dnf 的兼容层，行为一致。

核心是"现代依赖解析 + 新特性"。dnf 用 libsolv 依赖解析更快更健壮，支持 history/module 等，yum 是兼容别名。

• apt pinning 优先级
• 多仓库版本选择
• 防降级

apt pinning（/etc/apt/preferences.d/）用 Pin 与 Pin-Priority 控制从哪个仓库/版本选择包。优先级（Pin-Priority）决定 apt 选择版本：高优先级（如 1000）优先选该版本，低优先级（如 100）作为候选，低于 0 表示不安装。多仓库混用（内网镜像 + 官方源）时，若内网镜像版本旧而官方源新，apt 可能选官方新版本（意外升级）或内网旧版本（意外降级）。用 pinning 固定优先级：给内网镜像高优先级（Pin: origin ... Pin-Priority: 1000）确保优先用内网版本，或给某个包锁定版本（Pin-Priority: 1000 防变更）。避免意外降级：设置 Pin-Priority 控制版本选择，或用 apt 的 hold（apt-mark hold pkg）锁定版本。要点：pinning 语法（Pin: release/version/candidate），优先级排序，校验 apt-cache policy pkg 确认所选版本。

核心是"用 Pin-Priority 控制版本选择"。多仓库混用会意外升级/降级，用 preferences 设优先级或用 apt-mark hold 锁定版本。

• dnf history 记录事务
• yum/dnf history undo
• 回滚边界

dnf history 记录包管理事务（安装/升级/卸载），dnf history list 查看历史，dnf history undo <id> 撤销某个事务（回滚该事务的变更，如升级回退、安装卸载）。回滚边界：一是 undo 只影响该事务涉及的包，不能撤销后续互相依赖的变更；二是只能回滚"包安装/升级/卸载"类操作，不能回滚配置文件修改、数据变更（包管理只管理包，不管应用数据）；三是卸载时依赖的包可能被一并处理，undo 需有仓库（旧版本包需仍可获取）；四是已卸载包/已升级版本的旧包需在仓库或缓存中。边界：dnf history 是包级事务回滚，不覆盖应用数据/配置；通过 dnf 的 RPM 事务保证回滚。运维：重大升级前记录 dnf history，出问题 history undo 回退，但需确认旧版本可用与依赖边界。

核心是"包级事务回滚 + 边界"。dnf history undo 只回滚包安装/升级/卸载，不覆盖应用数据/配置，需旧版本可用。

• AppStream 模块与流
• 选流/切换
• 回退与恢复

AppStream 模块化（modularity）把软件包分组为模块（module），每个模块有多个流（stream，即版本线，如 nodejs:18、nodejs:20）。选流：dnf module list 查看，dnf module enable nodejs:20 或 dnf module install nodejs:20 选择流并安装。切换版本：dnf module reset nodejs 重置当前流，再 dnf module install nodejs:18 切换（或 disable+enable）。回退：切换/升级后可用 dnf module reset + 旧流重装，或 dnf history undo 回退事务。模块流切换失败恢复：一是 dnf module reset 重置模块状态；二是 dnf module remove 移除当前模块再重装；三是 dnf history undo 回退到切换前；四是清理 dnf 缓存（dnf clean all）重试；五是检查模块流是否存在/仓库是否更新。要点：切换流可能改变包版本，注意依赖与数据兼容；恢复用 reset/history。

核心是"模块流选版 + 重置恢复"。AppStream 模块用流选版本，切换用 reset+install，失败用 module reset/history undo 恢复。

• fpm 打包
• spec 文件
• 最小实践

自制 rpm/deb 包的最小实践：一是用 fpm 快速打包（fpm 是通用打包工具，把目录/文件打包为 rpm/deb）：fpm -s dir -t rpm -n app -v 1.0 /path/to/files；fpm 自动生成 spec/control 并调用 rpmbuild/dpkg-deb。二是用 rpm spec 文件（RHEL 系）手动写 .spec（Name/Version/Release/%install/%files），用 rpmbuild -bb 构建。最小实践要点：一是正确设置 Version、Release、Architecture；二是 %files 列出安装文件（用 %attr 设权限）；三是 %install 把构建产物安装到 %{buildroot}；四是校验依赖（Requires/Depends）；五是签名（可选）。fpm 适合快速打包，spec 适合精细控制。打包前测试安装/卸载。安全：文件权限、属主正确，含脚本（%post/%postun）注意。

核心是"打包工具 + 元数据"。fpm 快速打包目录，spec 精确控制 rpm 构建，需正确设置版本/文件/依赖/权限。

• initramfs 作用
• 驱动缺失
• 故障链与修复

initramfs（initrd）是启动时加载的临时根文件系统，包含挂载根分区所需的驱动（磁盘控制器、文件系统、LVM、加密等）。故障链：内核启动 → 加载 initramfs → initramfs 中的 init 尝试加载驱动、挂载根 → 若 initramfs 缺少必要驱动（如新磁盘控制器驱动、文件系统驱动、LVM 模块），挂载根失败 → 报"Failed to mount root"或进入 emergency，无法完成启动。原因：initramfs 生成时未包含所需驱动（未更新、新硬件、驱动模块被排除）。修复：一是用 dracut --force（RHEL）或 update-initramfs -u（Debian）重建 initramfs，包含当前硬件驱动；二是确认内核模块存在（lsmod/modprobe）；三是从 rescue 环境修复（chroot 重建 initramfs）。排查：看启动日志（dmesg）确认挂载根失败原因，确认驱动模块存在。本质：initramfs 是"临时引导根"，驱动缺失则无法挂载真实根。

核心是"驱动缺失→无法挂载根"。initramfs 需含挂载根所需驱动，缺失则启动失败，用 dracut --force 重建。

• repotrack 下载依赖闭包
• yumdownloader 下载
• 离线安装

repotrack（dnf 插件）下载指定包及其全部依赖（依赖闭包），repotrack pkg 把 pkg 及其所有依赖下载到当前目录，用于离线环境安装；yumdownloader 只下载指定包（不含依赖，除非 --resolve），yumdownloader --resolve pkg 下载包及其依赖。差异：repotrack 默认下载完整依赖闭包（含依赖），yumdownloader 默认只下载指定包（--resolve 才含依赖）。用途：离线环境打包——先在有网机器用 repotrack/yumdownloader --resolve 下载依赖闭包，拷贝到离线机器，用 rpm -ivh *.rpm 或 dnf install ./ 安装。实践：隔离/内网环境（无外网）需要预下载依赖闭包。注意：下载的包需架构匹配、依赖完整；用 dnf install ./download/*.rpm 安装。依赖闭包完整性决定离线安装成败。

核心是"下载依赖闭包供离线安装"。repotrack 下载完整依赖闭包，yumdownloader --resolve 也含依赖，离线机器用 rpm/dnf 安装。

• rpm --checksig 验签
• debsums 校验文件
• 完整性

rpm --checksig 验证 rpm 包签名（GPG 签名）与包内容完整性，rpm --checksig pkg.rpm 检查签名（来源）与 MD5/SHA 校验（内容未被篡改）；debsums 用 dpkg 记录的包文件校验（MD5）校验已安装的 deb 包文件完整性，debsums pkg 检查包文件是否被修改（检测被篡改/损坏文件）。差异：rpm --checksig 校验"包文件"（签名+内容），debsums 校验"已安装文件"（与安装时校验比对）。应用：rpm --checksig 用于安装前验证包来源与完整性；debsums 用于审计已安装包文件是否被篡改（防后门/漂移）。实践：安装前 rpm --checksig、rpm -V 验证已安装文件；debsums 定期校验包文件。二者都基于哈希/GPG 实现完整性，防篡改与损坏。

核心是"包签名 vs 已装文件校验"。rpm --checksig 验包签名与内容，debsums 校验已安装文件与安装时哈希比对。

• rpm 数据库损坏
• rpm --rebuilddb 重建
• 事务中止处置

rpm 数据库（/var/lib/rpm）存包元数据，损坏会导致 rpm 查询/安装失败（"rpmdb" 错误）。修复路径：一是备份数据库（/var/lib/rpm 下文件或备份目录）；二是 rpm --rebuilddb 从现有 RPM 文件重建数据库；三是若 --rebuilddb 失败，用 rpm --rebuilddb --dbpath=/var/lib/rpm 或恢复备份，或 rpm -qa --dbpath 查。事务中止（interrupted transaction）：rpm 安装中断（断电/进程被杀）会留下未完成事务，处置：一是 rpm --rebuilddb 重建可能修复；二是查看 rpm -qa 是否有半装包，用 rpm -e 卸载或 rpm -ivh --force/--reinstall 完成；三是清理 /var/lib/rpm/.rpm.lock 锁（确保无进程占用）；四是必要时导入备份数据库。注意：store 状态文件（__db*）损坏删除后会重建。路径：先备份、rebuilddb、处理半装包、必要时恢复备份。

核心是"重建数据库 + 处理半装包"。rpm --rebuilddb 从 RPM 重建数据库，事务中止需处理半装包（卸载/重装）并清理锁。

• rpm trigger 机制
• 配置更新触发
• 应用

rpm 触发器（trigger）是 rpm 包安装/卸载/升级时触发的脚本，用于在相关包变更时执行动作。类型：%triggerin（被触发包安装时）、%triggerun（被触发包卸载时）、%triggerpostun（卸载后）等。工程应用：一是配置更新——当某包安装/升级时，触发其他相关服务的配置刷新/重新加载（如安装新内核触发 grub 更新、安装证书触发服务 reload）；二是包间联动——一个包变更时触发关联包的动作（如升级 openssl 触发依赖它的服务重启）。实现：在 spec 文件的 %trigger 段指定触发条件（万 triggers 关系），触发脚本在目标包安装时执行。注意：trigger 是包级钩子，需谨慎（可能影响升级稳定性）；触发脚本幂等、失败处理。应用价值：让包变更自动联动相关配置/服务，减少手工操作。验证：rpm -q --triggers 查看触发脚本。

核心是"包变更触发联动脚本"。rpm trigger 在相关包安装/卸载时触发脚本，用于配置刷新/服务联动，需幂等。

• systemd 启动流程
• SysV init 兼容
• 差异

systemd 是现代 init 系统，startup 流程：systemd（PID 1）→ 默认 target（default.target）→ 按依赖启动各 services/targets，并行启动，用 unit 文件描述。SysV init 是传统 init：按 /etc/rc.d/rc*.d 的脚本按顺序（S/K 编号）启动/停止服务，runlevel 对应。兼容性：systemd 兼容 SysV init——通过 systemd 的 sysvinit 兼容层，能运行 /etc/init.d/ 下的 SysV 脚本（systemd 生成 wrapper unit），并支持 runlevel 向 target 映射（如 runlevel 3 → multi-user.target）；systemctl 可管理 SysV 脚本服务。差异：systemd 并行、依赖驱动、单元化，SysV 顺序、脚本化；systemd 更快、更结构化。兼容实践：旧 SysV 脚本可被 systemd 管理（systemctl enable/start），但建议迁移到 unit 文件。systemd 的 SysV 兼容保证旧脚本可用。

核心是"并行单元化 vs 顺序脚本化 + 兼容"。systemd 并行依赖驱动，兼容 SysV 脚本（/etc/init.d）与 runlevel 映射到 target。

• versionlock 插件
• 锁定版本
• 防意外升级

yum versionlock（dnf versionlock）插件锁定软件包版本，防止 yum/dnf update 意外升级被锁定的包。用法：yum versionlock add pkg 锁定当前版本，yum versionlock list 查看，yum versionlock delete pkg 解锁，yum versionlock clear 清空。dnf 用法类似（dnf versionlock ...）。原理：locked 包在 update 时被排除，保持当前版本，避免版本漂移导致问题。工程应用：生产环境锁定关键包版本（如数据库、运行时），防止自动升级引入不兼容；配合定期评估手动升级。注意：versionlock 只影响包管理器升级，不阻止手动 rpm 安装；锁定过多会阻碍安全补丁，需平衡（锁定 vs 安全更新）。运维：对关键包 versionlock，安全补丁单独评估。配置：安装 yum-plugin-versionlock 或 dnf 内置。

核心是"锁定版本防漂移"。versionlock 插件在 update 时排除锁定包，保持版本，生产锁关键包但要平衡安全补丁。

• GPG key 轮换
• 签名失效
• 应急

仓库 GPG key 轮换：发行方更换 GPG 公私钥时，需导入新公钥并更新仓库元数据签名，客户端需信任新 key。过程：投入新 key 签名、客户端 rpm --import/apt-key add 导入新公钥、移除旧 key（可选）、验证 gpgcheck。签名失效应急：若仓库包签名验证失败（key 过期/被吊销/不匹配），会出现"package is not signed"或 GPG 校验错误，导致无法安装。应急：一是确认是否需要更新 key（新 key 导入）；二是核对 key 指纹（防止 trust 被替换）；三是若 key 过期，导入新 key 或临时降低 gpgcheck（不推荐，仅应急）；四是检查时间同步（证书/gpg 依赖时间，时间错会导致签名失效）。实践：轮换前预导入新 key、灰度验证；失效时先查时间与 key 状态，再更新 key。注意勿随便禁用 gpgcheck（供应链风险）。

核心是"key 轮换 + 失效应急"。轮换需导入新 key 并验证，签名失效先查时间与 key 状态，再导入新 key，勿随便禁用 gpgcheck。

• 内核启动参数
• ro/quiet/nomodeset
• 作用

内核启动参数（在 GRUB 的 linux 行添加）：ro 使根文件系统以只读挂载（启动早期只读，initramfs 后切换 rw，保证启动一致性）；quiet 抑制内核启动日志（只显示错误，减少刷屏），调试时移除；nomodeset 禁用内核图形模式设置（KMS），用旧版 VGA 模式显示，用于显卡驱动问题时的启动排查（黑屏/花屏时用）。作用：ro 保证启动期根分区只读（一致性、防破坏）；quiet 精简启动输出；nomodeset 解决显卡驱动导致的黑屏/无法启动。运维：调试启动问题在 GRUB 编辑 linux 行加/删参数；查明黑屏问题加 nomodeset，看启动日志删 quiet。参数是临时（GRUB 编辑）或永久（/etc/default/grub GRUB_CMDLINE_LINUX + grub2-mkconfig）。

核心是"三个启动参数作用"。ro 只读根、quiet 静默日志、nomodeset 禁用图形模式，用于启动一致性/调试/显卡问题。

• 多内核并存
• grub2-set-default
• 安全回滚

系统升级内核后多个内核版本并存（/boot 中多个 vmlinuz）。管理默认启动内核：grub2-set-default <entry> 设置默认启动项（或 grub2-set-default 0 按编号），grub2-editenv list 查看 saved_entry，grub2-mkconfig -o /boot/grub2/grub.cfg 重新生成配置。安全回滚：升级内核后若新内核起不来，可回滚——重启时在 GRUB 菜单选旧内核；或事先 grub2-set-default 旧内核 设置默认；grub2-mkconfig 后确认 menuentry 顺序。避免重启起不来：一是升级后保留旧内核（不清除），确认新内核能启动再清理；二是设置默认启动项为已验证的旧内核；三是 grub2-set-default 指向旧 entry 并验证；四是必要时从 GRUB 临时选旧内核。实践：升级内核后保守起见保留旧内核用于回滚，New 内核验证通过后再删除旧内核并更新 grub。注意 UEFI 用 grub2 的 efiboot 管理。

核心是"默认项 + 保留旧内核回滚"。grub2-set-default 设默认启动项，升级后保留旧内核并验证新内核，避免回滚无门。

• Linuxbrew/Homebrew 定位
• 与系统包管理器冲突
• 生产限制

Linuxbrew（Homebrew on Linux）是用户级包管理器，把软件装在用户目录（~/.linuxbrew），不依赖 root，与系统包管理器（apt/yum/dnf）并存。冲突：一是路径冲突——Linuxbrew 的 bin 在 PATH 前，可能覆盖系统命令版本（如 brew 的 python 覆盖系统 python），导致行为不一致；二是依赖冲突——Linuxbrew 自带依赖，与系统库版本可能冲突（链接/加载不同 glibc）；三是重复安装——同一软件系统与 brew 各一份，版本/配置分离，维护混乱。生产环境限制：一是 Linuxbrew 面向用户级/开发，非系统级，不适合多用户/生产服务器的统一管理；二是无系统级集成（systemd、多用户、审计、安全策略）；三是升级/回滚与系统包不一致；四是安全与合规（软件来源、签名、审计难统一）。实践：生产用系统包管理器并统一管理，避免 Linuxbrew 混用；开发/临时环境可用，但需注意 PATH 与依赖隔离。

核心是"用户级 vs 系统级 + 冲突"。Linuxbrew 用户级安装、PATH 覆盖系统命令、依赖冲突，生产应统一用系统包管理器。

• apt-cacher-ng 缓存代理
• 配置
• 缓存作用

apt-cacher-ng 是 Debian/Ubuntu 系的软件包缓存代理（HTTP 代理），把客户端下载的 .deb 包缓存到本地，后续相同请求直接命中缓存，减少外网带宽与重复下载。配置：安装 apt-cacher-ng，配置代理地址（默认 3142 端口），客户端配置 APT 使用代理（/etc/apt/apt.conf.d/ 中 Acquire::http::Proxy "http://cache:3142"）或 DNS 把 archive.ubuntu.com 指向 cache。缓存作用：一是省带宽（同一版本只下载一次）；二是加速（内网命中）；三是离线环境可预填充缓存。运维：监控缓存磁盘（/var/cache/apt-cacher-ng），配置 Volatile 缓存策略，多客户端共享。apt-cacher-ng 适合多机 Debian 环境集中缓存，减少仓库流量。注意：apt-cacher-ng 只缓存，不缓存元数据/签名校验不变。

核心是"缓存代理省带宽"。apt-cacher-ng 缓存 .deb 包，客户端走代理命中缓存，减少外网流量与重复下载。

• apt-mirror 同步 Debian 仓库
• reposync 同步 RPM 仓库
• 差异

apt-mirror 用于 Debian/Ubuntu 系，同步 APT 仓库到本地镜像（生成 mirror 目录，含 Packages/Release 元数据与 .deb），客户端用 sources.list 指向本地镜像；reposync 用于 RHEL 系，同步 yum/dnf 仓库到本地目录（下载 RPM 与元数据），配合 createrepo 创建本地仓库，客户端用 yum 指向本地。差异：apt-mirror 面向 APT（Debian），reposync 面向 RPM（RHEL），都是"把远端仓库同步到内网搭建本地镜像"。实现：apt-mirror 用 mirror 配置文件（source 列表）同步；reposync 用 reposync --repoid 下载 + createrepo 生成元数据。用途：内网/离线环境搭建本地仓库，客户端从本地镜像安装，省带宽、可控版本。选型：Debian 系用 apt-mirror，RHEL 系用 reposync + createrepo。两者都需定期同步与磁盘规划。

核心是"Debian 与 RPM 的同步工具"。apt-mirror 同步 APT 仓库，reposync+createrepo 同步 RPM 仓库，搭建内网本地镜像。

• mrepo 仓库管理
• repomanage 清理
• 配合

mrepo 是 RPM 仓库管理工具，用于同步/维护多个 RPM 仓库（支持从远端同步、生成本地仓库、管理多发行版仓库），内置 createrepo 生成元数据；repomanage 是清理工具，用于管理仓库目录中 RPM 文件的保留策略（repomanage old 列出旧版本用于删除，repomanage new 列出最新版本保留）。配合：mrepo 同步仓库并生成元数据，repomanage 清理旧版本 RPM（保留最新 N 个，删除冗余），二者配合保持内网仓库"最新且不冗余"。应用：重要的内网 YUM 仓库在 mrepo 同步后用 repomanage 定期清理旧包，控制磁盘占用并保持仓库干净。注意：repomanage 清理后需重新 createrepo 更新元数据。运维：建立同步+清理+重建元数据的定时任务。

核心是"同步 + 清理 + 重建元数据"。mrepo 同步维护仓库，repomanage 清理旧版本 RPM，清理后重建元数据。

• yum-utils 工具
• 常用工具
• 运维脚本

yum-utils（dnf-utils）提供一组 yum/dnf 辅助工具，常用：yumdownloader（下载 RPM 包，--resolve 含依赖）、repotrack（下载依赖闭包）、repoquery（查询仓库包信息，依赖/版本/文件）、reposync（同步仓库）、debuginfo-install（安装调试包）、package-cleanup（清理旧包/孤儿包）。在运维脚本中的应用：一是 yumdownloader/repotrack 下载离线安装包；二是 repoquery 查询依赖与包信息（脚本化判断）；三是 package-cleanup 清理旧内核/孤儿包（yum 后清理）；四是 reposync 搭建内网仓库。工具链让运维脚本能查询/下载/清理/同步包，支撑自动化与离线部署。注意 yum 命令兼容 dnf-utils。实践：脚本中优先用 repoquery 查询、yumdownloader 下载，定期 package-cleanup 清理。

核心是"yum 辅助工具集"。yum-utils 提供 yumdownloader/repotrack/repoquery/reposync/package-cleanup 等，支撑脚本化包管理。