1. 为什么需要离线下载软件包
在日常的Linux系统管理中，我们经常会遇到这样的场景：生产环境的服务器出于安全考虑被隔离在内网，无法直接连接互联网；或者我们需要在多个环境部署相同的软件，但每个环境都重复下载依赖既耗时又浪费带宽。这时候，离线安装就显得尤为重要。
我管理过不少金融行业的服务器，这些机器通常都部署在严格隔离的网络环境中。记得有一次要给20台服务器部署监控系统，如果每台都联网安装，不仅效率低下，还会带来安全隐患。正是这种场景让我深刻体会到离线安装的价值。
DNF（Dandified YUM）作为新一代的RPM包管理器，相比传统的YUM有着更快的依赖解析速度和更简洁的命令语法。它能够智能地处理软件包之间的依赖关系，这正是我们实现离线安装的关键。通过DNF的--downloadonly参数，我们可以只下载软件包及其依赖项而不安装，这在以下场景特别有用：
- 需要在多台无网络环境的机器上部署相同软件
- 希望预先下载软件包以便后续快速安装
- 需要将软件包及其依赖打包成离线安装介质
- 网络带宽有限，希望集中下载后分发
2. 准备工作与环境检查
在开始离线下载之前，我们需要做一些准备工作。首先确认你的系统是否已经安装了DNF。大多数现代Linux发行版如Fedora、CentOS 8+、RHEL 8+都已经默认使用DNF替代了YUM。可以通过以下命令检查：
dnf --version如果系统提示命令未找到，你可能需要先安装DNF。对于较老的系统，可能需要先启用EPEL仓库：
yum install epel-release yum install dnf接下来，我们需要创建一个专门的目录来存放下载的软件包。我习惯在/opt下创建专门的目录，这样既不会干扰系统目录，也方便后续打包：
mkdir -p /opt/offline_packages chmod 755 /opt/offline_packages在实际操作中，我发现很多人在下载前会忽略一个关键步骤：清理旧的缓存。DNF会缓存已下载的包，这可能导致我们无法获取最新版本。建议先执行：
dnf clean all3. 使用DNF下载单个软件包
让我们从最基本的场景开始：下载单个软件包而不安装。假设我们需要下载nginx，命令非常简单：
dnf download nginx这个命令会将nginx的RPM包下载到当前目录。但这里有个问题：它不会自动下载依赖项。在实际项目中，我遇到过不少因为漏掉依赖而导致安装失败的情况。
要下载主包及其所有依赖，我们需要使用--resolve参数：
dnf download --resolve nginx这个命令会分析nginx的所有依赖关系，并把它们一并下载下来。在我的测试中，nginx在CentOS 8上大约有20个依赖包，这个命令能够一次性全部获取。
如果你想指定下载目录，可以结合--destdir参数：
dnf download --resolve --destdir=/opt/offline_packages nginx下载完成后，建议检查一下获取的包是否完整：
ls -lh /opt/offline_packages | wc -l4. 批量下载多个软件包及其依赖
在实际工作中，我们经常需要同时下载多个相关联的软件包。比如部署LAMP环境时，需要同时下载Apache、MySQL和PHP。DNF提供了几种方式来实现批量下载。
第一种方式是直接在命令中列出所有需要的包：
dnf download --resolve httpd mariadb-server php但这种方法有个缺点：如果某个包下载失败，整个过程就会中断。在我的经验中，更可靠的做法是使用--downloadonly参数配合install命令：
dnf install --downloadonly --downloaddir=/opt/offline_packages httpd mariadb-server php这个命令的优点是它会模拟完整的安装过程，确保所有依赖都能正确解析。我曾经用这个方法成功下载了包含87个包的复杂环境。
对于更复杂的场景，比如需要下载整个软件组（如"Development Tools"），可以使用：
dnf groupinstall --downloadonly --downloaddir=/opt/offline_packages "Development Tools"5. 高级技巧与常见问题解决
在长期使用DNF离线下载的过程中，我积累了一些实用技巧。首先是版本锁定问题。有时候我们需要特定版本的软件包，可以通过以下方式指定：
dnf download --resolve --downloaddir=/opt/offline_packages nginx-1.20.1另一个常见问题是依赖冲突。当系统中已经安装了某些软件的不同版本时，DNF可能会拒绝下载。这时可以尝试--allowerasing参数：
dnf download --resolve --allowerasing --downloaddir=/opt/offline_packages conflicting-package对于需要从特定仓库下载的情况，可以使用--repo参数：
dnf download --resolve --repo=epel --downloaddir=/opt/offline_packages special-package我遇到过最棘手的问题是依赖循环。A依赖B，B又依赖A。这种情况下，可以分步下载：
dnf download --downloaddir=/opt/offline_packages packageA dnf download --downloaddir=/opt/offline_packages packageB6. 离线安装与验证
下载完所有需要的包后，接下来的关键步骤是离线安装。将/opt/offline_packages目录打包传输到目标机器：
tar czvf offline_packages.tar.gz -C /opt offline_packages在目标机器上解压后，可以使用以下命令安装：
dnf install /opt/offline_packages/*.rpm或者更推荐的方式是创建一个本地仓库：
createrepo /opt/offline_packages dnf config-manager --add-repo=file:///opt/offline_packages dnf install nginx这种方法的好处是可以自动处理依赖关系，就像联网安装一样方便。我在一次跨数据中心部署中，用这个方法成功安装了50多台服务器的软件环境。
7. 最佳实践与经验分享
经过多次实战，我总结出一些DNF离线下载的最佳实践。首先是目录结构管理。我建议按项目或环境创建子目录：
/opt/offline_packages/ ├── web_servers │ ├── nginx │ └── apache └── databases ├── mysql └── postgresql其次是元数据记录。每次下载后，我都会创建一个README文件记录下载的软件版本和日期：
echo "nginx 1.20.1 downloaded on $(date)" >> /opt/offline_packages/README对于团队协作，我建议将下载的包纳入版本控制。虽然RPM文件是二进制文件，但可以用Git LFS管理：
git lfs track "*.rpm" git add . git commit -m "Added offline packages for nginx 1.20.1"最后是定期更新。即使离线使用，软件也需要安全更新。我设置了一个每月检查更新的日历提醒，确保离线包不会过时。
