CentOS 7离线安装MongoDB 4.2：RPM依赖与systemd自启全攻略

干运维的人大概都经历过这种场景：内网机房断网，业务等数据入库，你拿到一台最小化安装的 CentOS 7，需要装 MongoDB 4.2，还要求重启服务器之后服务自己拉起来。在线装一个 yum install 三分钟，但断网环境下没有预先准备的离线包，只能原地干瞪眼。

这不是一篇纯理论教程，是实际离线部署落过地的方案。整个过程拆开看并不复杂：备齐 RPM 包、写对 mongod.conf、启动后设置 systemd 开机自启。但每步都有几个容易踩的坑，比如依赖缺失、SELinux 拦截、systemd 和 mongod 的 fork 模式冲突。我把这些全部收敛到一段脚本里，照着拷贝就能用，适合要给内网交付环境的运维同学，也适合第一次做离线部署的开发者。

1. 离线安装的整体思路与方案选型

1.1 为什么断网场景必须提前准备离线包

在线装 MongoDB 时，yum 会自动从源里拉依赖，网络通畅，一条命令就完事。但断网环境最大的问题是“未知”，你不知道目标机器缺哪些依赖，也不知道缺的依赖到底属于哪个包。如果不做预准备，手动 rpm -ivh 大概率会砸在libcrypto.so.10()(64bit) is needed这种错误上。

离线部署的核心，就是在能联网的机器上，把所有安装所需的 RPM 全部拉下来，再通过移动介质、堡垒机或临时局域网传进目标机。这个过程必须在同一种操作系统、同一种 CPU 架构下完成。用 CentOS 8 的包去装 CentOS 7 基本是给自己找麻烦，aarch64 的包硬塞给 x86_64 也一样不行。

我习惯把这套过程拆成三层：RPM 包层、配置文件层、systemd 服务层。RPM 包层负责“装着”，配置文件层负责“跑起来”，systemd 服务层负责“重启后还在”。任何一层断链，整套部署都不算成功。

1.2 安装包准备与传递的两种方式

准备离线包有两条路。第一条是用 yumdownloader 或 repotrack 从 yum 仓库拉取所有依赖；第二条是手工从网页下载 RPM，再根据 rpm 提示逐个补依赖。第二条太折腾，不建议。我更推荐 repotrack，它会连目标机器上可能已经装过的依赖也一并拉下来，虽然包数量多一些，但到了内网不会出现“少一个包”的尴尬。

安装包准备好之后，传递方式看现场条件。USB、临时局域网、堡垒机文件上传都可以。最好先打成 tar.gz，传过去再解压，避免一堆小文件传输中断。目标位置我一般固定放/opt/mongodb-rpm，安装脚本也是按这个路径写的，随包带上一个 md5 校验文件，防止传输出错。

1.3 从 RPM 安装到开机自启的完整链路

安装流程不能是“把目录里 rpm 全部放进去，然后 rpm -Uvh *.rpm”这么简单。手动 rpm 对包间依赖的解析能力有限，顺序不对照样失败。我实践下来的规范链路是：

1. 用yum localinstall一次性安装本地 RPM 包，让 yum 完成依赖计算。
2. 确认 mongod 系统用户、数据目录、日志目录存在且权限正确。
3. 修改/etc/mongod.conf，明确端口、绑定地址、数据目录、日志路径。
4. 启动 systemd 服务，并执行systemctl enable mongod。
5. 检查端口、日志、开机自启项。

每步成功后再进入下一步。这看起来普通，但每一步都是踩坑换来的。比如没确认数据目录权限就启动，服务一启动就退出，日志里全是Permission denied；又比如先start忘了enable，机器重启后又得手动起服务。

2. 关键配置与依赖关系拆解

2.1 MongoDB 4.2 官方 RPM 包的组成

MongoDB 4.2 的 RPM 不是一个大包，而是一组。mongodb-org-server提供 mongod 守护进程，mongodb-org-shell提供 mongo 客户端，mongodb-org-tools提供mongodump、mongoexport等备份导出工具，mongodb-org-mongos是分片集群的路由组件。单机部署只需要 server 和 shell，但运维上建议把 tools 也带上，后面备份导数据总会用到。

如果你直接装mongodb-org这个元包，它会把所有组件全部拉进来。离线环境也能装，但依赖面会大不少。我更倾向于只下载实际需要的几个包，离线包体积能小一点。本文场景是单节点，所以目标是 server + shell + tools。

2.2 隐藏的依赖风险：从 libcrypto 说到 yum 本地源

MongoDB 4.2 的 RPM 依赖 openssl-libs 提供的libcrypto.so.10和libssl.so.10。CentOS 7 默认装了 openssl 1.0.2 通常没事，但最小化安装少了 openssl-libs 时，就会卡住。类似的依赖还可能有 net-snmp-libs、cyrus-sasl-lib、lz4 等，手动逐个去查真的会怀疑人生。

因此准备阶段直接把依赖拉全是关键。有了整套 RPM 后，安装时用yum localinstall /opt/mongodb-rpm/*.rpm，并加上--disablerepo=*，强制 yum 只从当前目录和系统已装的包里做依赖解析。这样做的好处是，yum 会像在线安装一样自动处理安装顺序，而不会傻傻地尝试连接不可达的远程仓库。

本地源不是必须的。如果只装一台机器，localinstall 更干净。但如果内网有几十台机器要批量交付，做一个本地 yum 源也有价值，那属于另一个话题，这里不展开。

2.3 mongod.conf 里最容易被忽略的三个参数

MongoDB 4.2 的默认配置模版里有几个坑。

第一个是processManagement.fork。在 systemd 环境下必须设为false，否则 mongod 自己 fork 成后台进程，systemd 会误判服务状态，重启后可能出现服务假死。

第二个是net.bindIp。默认是127.0.0.1，装完只能本机连。要改成0.0.0.0之前，必须先确认认证已经开启，否则等于把数据库裸奔在网络上。

第三个是security.authorization。默认是disabled，并且建用户和开认证的顺序不能反。如果一上来就在 mongod.conf 里写authorization: enabled，然后启动服务，此时数据库里还没有任何用户，本地 shell 也没权限建用户。正确做法是临时以无认证模式启动，建好管理员后再打开认证并重启。这个顺序问题，等会遇到的时候再细说。

3. 离线安装脚本：从检查到自启动一步到位

3.1 脚本设计思路与运行前提

我写的脚本尽量做到“缺什么就明确报什么”。前置条件是 root 运行，/opt/mongodb-rpm目录下已经放了全部离线 RPM，包括 MongoDB 本体和依赖包。脚本不联网，不做在线源。如果目录不存在或者没有 RPM，直接退出，而不是走到一半才报错。

脚本默认绑定地址是127.0.0.1，如果业务需要远程访问，把BIND_IP改成0.0.0.0，同时把AUTH_ENABLE改成yes。我故意加了个保护逻辑：如果你把BIND_IP改成了非回环地址但AUTH_ENABLE仍为no，脚本会强制回退回127.0.0.1并提示原因。这个保护是我真实环境吃过亏之后才加上的，无认证裸奔的教训不想来第二次。

3.2 完整脚本（可直接保存使用）

#!/bin/bash # 离线安装 MongoDB 4.2 并配置开机自启 # 适用：CentOS 7.x x86_64，MongoDB 4.2.x # 前置：/opt/mongodb-rpm 下已有全部离线 RPM set -e MONGO_RPM_DIR="/opt/mongodb-rpm" MONGO_CONF="/etc/mongod.conf" MONGO_DB_PATH="/var/lib/mongo" MONGO_LOG_PATH="/var/log/mongodb" MONGO_PORT="27017" # 需要远程访问时改为 0.0.0.0，但必须同时把 AUTH_ENABLE 设为 yes BIND_IP="127.0.0.1" AUTH_ENABLE="no" ADMIN_USER="root" ADMIN_PASS="Mongo@2024" if [ "$(id -u)" -ne 0 ]; then echo "请使用 root 运行" exit 1 fi if [ "$BIND_IP" != "127.0.0.1" ] && [ "$AUTH_ENABLE" != "yes" ]; then echo "警告：远程绑定必须开启认证，BIND_IP 已回退为 127.0.0.1" BIND_IP="127.0.0.1" fi echo "===== 1. 检查离线包目录 =====" if [ ! -d "$MONGO_RPM_DIR" ]; then echo "目录 $MONGO_RPM_DIR 不存在，请先同步 RPM 包" exit 1 fi RPM_COUNT=$(find "$MONGO_RPM_DIR" -maxdepth 1 -name "*.rpm" | wc -l) if [ "$RPM_COUNT" -eq 0 ]; then echo "目录中没有 RPM 包，无法继续" exit 1 fi echo "检测到 $RPM_COUNT 个 RPM 文件" echo "===== 2. 检查是否已安装 =====" if rpm -q mongodb-org-server &>/dev/null; then echo "mongodb-org-server 已安装，脚本退出" exit 1 fi echo "===== 3. 安装 MongoDB 及依赖 =====" yum -y --disablerepo=* localinstall "$MONGO_RPM_DIR"/*.rpm echo "===== 4. 准备数据目录和日志目录 =====" mkdir -p "$MONGO_DB_PATH" "$MONGO_LOG_PATH" chown -R mongod:mongod "$MONGO_DB_PATH" "$MONGO_LOG_PATH" echo "===== 5. 生成临时配置并启动 =====" cat > "$MONGO_CONF" <<EOF systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log storage: dbPath: /var/lib/mongo journal: enabled: true processManagement: fork: false pidFilePath: /var/run/mongodb/mongod.pid net: port: $MONGO_PORT bindIp: 127.0.0.1 EOF systemctl daemon-reload systemctl start mongod if [ "$AUTH_ENABLE" = "yes" ]; then echo "===== 6. 创建管理员用户 =====" for i in $(seq 1 15); do if mongo --host 127.0.0.1 --port "$MONGO_PORT" --quiet --eval "db.runCommand({ping:1}).ok" | grep -q 1; then break fi sleep 1 done mongo --host 127.0.0.1 --port "$MONGO_PORT" <<EOF use admin db.createUser({ user: "$ADMIN_USER", pwd: "$ADMIN_PASS", roles: [ { role: "root", db: "admin" } ] }) EOF fi echo "===== 7. 停服务，写入最终配置 =====" systemctl stop mongod if [ "$AUTH_ENABLE" = "yes" ]; then AUTH_LINE="authorization: enabled" else AUTH_LINE="# authorization: disabled" fi cat > "$MONGO_CONF" <<EOF systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log storage: dbPath: /var/lib/mongo journal: enabled: true processManagement: fork: false pidFilePath: /var/run/mongodb/mongod.pid net: port: $MONGO_PORT bindIp: $BIND_IP security: $AUTH_LINE EOF echo "===== 8. 启动并设置开机自启 =====" systemctl start mongod systemctl enable mongod echo "===== 9. 状态检查 =====" systemctl status mongod --no-pager | head -n 15 || true ss -tnlp | grep "$MONGO_PORT" || true

如果AUTH_ENABLE是no，第 6 步不会创建用户，最终配置里的 security 段只是注释，默认只在本机使用。这个场景适合还没有规划业务账号的测试环境。

3.3 脚本里每个关键动作的取舍

第 3 步值得单独解释。yum -y --disablerepo=* localinstall "$MONGO_RPM_DIR"/*.rpm和直接rpm -Uvh *.rpm差别非常大。rpm 对包间依赖的解析能力有限，多个包只要顺序不对就报错；yum 则会把命令行给到的包和系统已装包一起做依赖计算，集合完整的情况下安装顺序由它自己处理。--disablerepo=*在断网环境很重要，否则 yum 发现某个包在本地集合里没匹配时，会去访问远程仓库，不可达地址会让每个包都等一次超时。

临时配置绑定127.0.0.1是为了先创建管理员。如果把最终配置直接写进去，尤其是开启认证，然后 start，后边的 mongo 建用户命令会因为权限不足而失败。两阶段配置虽然多一次服务重启，但可控性强很多。

最后一步systemctl enable mongod对应开机自启。CentOS 7 的 MongoDB RPM 自带mongod.service文件，enable 后会在/etc/systemd/system/multi-user.target.wants下生成软链。有些老教程会让你用 chkconfig，在 systemd 环境里别混着用。

4. 配套脚本：在有网环境准备离线安装包

4.1 利用 repotrack 自动解析依赖

离线包需要在有网环境准备。我建议选一台和线上相同系统版本的机器，CentOS 7.x x86_64 即可，不必和线上硬件一致。先把 MongoDB 4.2 的 yum 源配上，再安装 yum-utils，然后用 repotrack 把当前需要的 RPM 全部拉到目录里。

#!/bin/bash # 在有外网的 CentOS 7 机器上执行 mkdir -p /root/mongodb-offline cd /root/mongodb-offline cat > /etc/yum.repos.d/mongodb-org-4.2.repo <<'EOF' [mongodb-org-4.2] name=MongoDB 4.2 Repository baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc EOF yum -y install yum-utils repotrack mongodb-org-server mongodb-org-shell mongodb-org-tools ls -lh *.rpm | tail -n 20

为什么用 repotrack 而不是 yumdownloader？yumdownloader --resolve会跳过已安装在当前机器上的依赖包。如果准备机器恰好已经装了 net-snmp-libs、openssl-libs，它就不会下载这些 RPM，但内网目标是最小化安装，这些包不存在，安装就会缺依赖。repotrack 不管当前机器装没装，都会把依赖全部拉下来。代价是包数量膨胀到几十个，但稳定优先，硬盘空间不值一提。

4.2 离线包传到内网后的检查清单

包准备好之后，先确认版本和架构。在目录下执行rpm -qip *.rpm | grep -E "^(Name|Version|Architecture)"，确保所有包都是 MongoDB 4.2、x86_64，并且各组件版本一致。最典型的问题是 server 是 4.2.20、shell 是 4.2.24，虽然运行大概率没问题，但没必要给自己埋雷。

打成压缩包时注意保留文件，tar 加-z即可。传进内网后解压到/opt/mongodb-rpm，再做一次 md5 校验，避免大文件传输出问题。我习惯在同一个包里放一个check_env.sh，内容很简单：检查是否 root、检查 27017 端口是否被占用、检查/var/lib/mongo是否已有旧数据。旧数据目录是隐藏坑，如果之前装过其他版本 MongoDB，新装的 4.2 会因为没有 clean shutdown 拒绝启动，报 lock file 相关错误，处理起来很费劲。

5. 常见问题与排查实录

5.1 安装完成后 mongod 启动失败

启动失败先看日志，不要反复systemctl start。日志路径默认在/var/log/mongodb/mongod.log，也可以用journalctl -u mongod -n 50看 systemd 捕获的输出。

最典型的是数据目录权限不对，日志里出现Unable to create/open lock file或Permission denied，执行chown -R mongod:mongod /var/lib/mongo /var/log/mongodb基本能解决。

另一种情况是端口被占用。用ss -tlnp | grep 27017查看，有进程占用就换端口或停掉旧进程。注意 MongoDB 异常退出后 dbPath 下会有mongod.lock，不能直接删，先确认没有 mongod 进程，再评估是否需要处理旧锁。

5.2 能本地连但远程连不上 27017

这类问题按“本机 → 防火墙 → SELinux → 配置”的顺序排查。本机能连说明 mongod 进程本身正常。先看配置里bindIp，如果是127.0.0.1，远程当然连不上。如果已经是0.0.0.0，再看防火墙，firewall-cmd --list-all确认 27017/tcp 已放开，需要执行：

firewall-cmd --permanent --add-port=27017/tcp firewall-cmd --reload

接着是 SELinux。CentOS 7 默认 enforcing，mongod 监听的端口是否放行很容易被忽略。最粗暴的验证是临时setenforce 0，能连了就是 SELinux 拦截。生产环境不建议直接关，应评估内网安全策略后添加规则。

5.3 开机自启不生效

systemctl enable mongod执行过，重启后服务还是没起来？先执行systemctl list-unit-files | grep mongod，看 mongod.service 是否显示 enabled。如果显示 disabled，说明 enable 没生效，多半是之前手动 stop 后没重新 enable。

如果显示 enabled 但重启后没起来，看下/etc/systemd/system/multi-user.target.wants/mongod.service是否存在。还有一个容易踩的点：改了/etc/mongod.conf里的 pidFilePath，但对应目录在 systemd unit 的 RuntimeDirectory 里没有创建。默认/var/run/mongodb会自动生成，别改成奇怪路径，保持默认能省很多事。

5.4 认证开启后脚本连接权限问题

创建用户后重启，再用 mongo 连接就需要带账号密码了。命令是：

mongo --host 127.0.0.1 --port 27017 -u root -p 'Mongo@2024' --authenticationDatabase admin

提示Authentication failed时，先确认用户名是在 admin 库创建的，连接参数里也要指定--authenticationDatabase admin。另一个坑是密码里带$等特殊字符，Bash 不加单引号会被变量展开，结果跟原密码不一致。脚本化运维时建议密码统一用字母、数字、下划线组合，省去转义问题。

认证开启后，不要指望 localhost 免密连。MongoDB 的 localhost exception 只允许“数据库还没有用户时创建第一个用户”，之后所有连接都要走认证。

6. 用在生产环境前的最后几点经验

6.1 建议保留一份纯净的安装包目录

脚本安装过一遍之后，/opt/mongodb-rpm里还会有所有依赖 RPM。跑完脚本后不要删，也不要在里面混入其他软件包，下次新机器上线直接复用。万一某次安装失败需要重装，先把已装的 mongodb 组件卸载干净，再重跑脚本，比手工改配置快得多。

我还建议把脚本和 RPM 包放到一个版本化的目录里，比如mongodb-4.2.24-x86_64-offline/，包内放一个 README，记录来源路径、生成时间、校验和。内网环境多了之后，版本管理混乱的教训我是吃过的。某台机器是 4.2.20，另一台是 4.2.24，时间一长没人记得哪个包适配哪个脚本，完全靠目录名是不行的。

6.2 版本加固与后续维护建议

MongoDB 4.2 已经算是老版本，如果你的业务没有强制要求，建议评估更新版本。但如果确实要用 4.2，部署时注意几点：开启认证、限制 bindIp、设置足够大的文件句柄。文件句柄在 systemd 下默认 1024，对 MongoDB 来说不够，可以创建一个 override 文件：

mkdir -p /etc/systemd/system/mongod.service.d cat > /etc/systemd/system/mongod.service.d/override.conf <<'EOF' [Service] LimitNOFILE=64000 LimitNPROC=64000 EOF systemctl daemon-reload systemctl restart mongod

这个步骤不在基础脚本里，因为配置项和业务负载相关，但生产环境一定要加。我个人的习惯是每次交付前跑一个完整的“重启验证”：reboot 后登录，执行systemctl status mongod和mongo --eval "db.runCommand({ping:1})"确认服务恢复。这比任何检查项都直接。脚本保证的是绝大部分环境能一次通过，重启验证保证的是你交出去的机器真的达到“开机自启动”这个目标。