说到服务器维护,很多刚接触 Linux 的朋友听到“升级”或者“打补丁”这几个字,心里可能咯噔一下。毕竟,谁也不想在自己忙得焦头烂额的时候,因为一个 yum update 或者 dnf upgrade 导致服务挂掉,甚至数据丢失。但别担心,AlmaLinux 作为 RHEL(Red Hat Enterprise Linux)的完美二进制兼容替代品,它的生态系统其实非常成熟且稳健。今天咱们不整那些晦涩难懂的术语堆砌,我就把自己这些年踩过的坑、总结出的最佳实践,掰开了揉碎了讲给你听。我们要做的,不是盲目地执行命令,而是像做外科手术一样精准、安全地完成系统更新。
首先,你得明白一个核心概念:“滚动更新”和“大版本升级”是两码事。 对于 AlmaLinux 8 或 AlmaLinux 9 来说,日常的 dnf update 主要是安装安全补丁和小版本修复,这通常是平滑的;而当你从 8.x 跨到 9.x,或者从 9.0 跨到 9.1 时,那才是真正需要小心翼翼的“大手术”。我们的目标很明确:既要保证系统的安全性和新功能,又要确保业务零中断,数据零丢失。
第一步:知己知彼——评估当前环境
在动手敲任何命令之前,最重要的动作其实是“停下来看一看”。很多升级失败的原因,往往不是因为命令本身错了,而是因为我们对当前环境的依赖关系不够了解。
假设你现在有一台运行着 Nginx、PostgreSQL 和自定义 Python 应用的 AlmaLinux 服务器。你需要先搞清楚几件事:
当前版本确认: 打开终端,输入
cat /etc/os-release。你会看到类似这样的输出:NAME="AlmaLinux" VERSION="8.7 (Purple Manul)" ID="almalinux" ...记下这个版本号。如果你打算跨大版本升级(比如从 8 升到 9),这一步至关重要,因为不同版本的包管理器行为、内核版本以及底层库都有差异。
磁盘空间检查: 升级过程需要下载新的 RPM 包并解压安装,临时文件可能会占用大量空间。运行
df -h /查看根分区使用情况。如果/var或/tmp空间不足,升级过程可能会中途崩溃。建议预留至少 2-5GB 的额外空间用于缓存和临时文件。关键服务状态: 运行
systemctl list-units --type=service --state=running。记录下所有正在运行的服务。有些服务在升级期间可能需要重启,甚至某些旧版本的依赖库被移除后,新服务可能无法启动。
第二步:黄金法则——备份,备份,还是备份!
我知道你很想跳过这一步直接看命令,但请相信我,这是整个流程中最值得花时间的部分。数据丢失是不可逆的,而重新部署系统只是时间问题。
全系统快照(如果使用云主机) 如果你使用的是 AWS EC2、阿里云 ECS 或 DigitalOcean Droplet 等云服务器,最简单、最可靠的方法是使用快照(Snapshot)。在控制台创建一个系统盘快照。这个过程通常只需要几分钟,而且它备份的是整个磁盘块,包括文件系统元数据、隐藏文件和未分配空间。这是防止升级失败的终极保险。
本地文件系统备份
如果没有云快照功能,或者你希望更精细地控制备份,可以使用 rsync 或 tar。例如,备份 /home 目录和用户配置文件:
# 创建备份目录
sudo mkdir -p /backup/alma_pre_upgrade
# 使用 rsync 同步关键数据,保留权限和符号链接
sudo rsync -avz --exclude='/proc' --exclude='/sys' --exclude='/dev' / /backup/alma_pre_upgrade/root_backup/
# 单独备份数据库,假设你用的是 PostgreSQL
sudo systemctl stop postgresql
sudo pg_dumpall > /backup/alma_pre_upgrade/pg_full_backup.sql
sudo systemctl start postgresql
注意:如果你使用的是 LVM(逻辑卷管理),可以在升级前创建一个 LVM 快照,这样可以在不停止服务的情况下对根分区进行一致性备份。这对于生产环境来说是高级玩家的选择。
第三步:日常维护——安全补丁的安装策略
对于大多数用户来说,频繁的大版本升级并不是常态,更多的是日常的安全补丁安装。AlmaLinux 继承了 RHEL 的高稳定性,日常更新通常不会破坏现有功能。
推荐做法:自动化 + 监控
你可以配置 dnf-automatic 来自动安装安全补丁。编辑 /etc/dnf/automatic.conf:
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
这里的关键是 upgrade_type = security。这意味着只有被标记为“安全”的更新才会被应用,避免了非必要的功能变更带来的潜在风险。
手动更新的最佳实践
如果你选择手动更新,请务必分步进行:
只检查不安装: 先运行
sudo dnf check-update。这会列出所有可用的更新,但不会实际修改系统。仔细查看列表,看看是否有你熟悉的软件包被更新。如果有非预期的重大版本变更(比如 Python 从 3.6 跳到 3.9),你需要暂停并调查原因。分阶段安装: 不要一次性运行
sudo dnf upgrade -y。虽然-y很方便,但它剥夺了你中途叫停的机会。建议先更新核心组件:sudo dnf update kernel* sudo dnf update glibc*观察系统反应,如果没有报错,再更新其他应用层软件。
重启内核: 如果内核更新了,必须重启才能生效。在重启前,确保所有关键服务已经优雅停止。你可以使用
reboot命令,或者更温和地sudo shutdown -r now "Kernel update requires reboot"。
第四步:跨越鸿沟——从 AlmaLinux 8 升级到 9
这是最容易出问题的环节。跨大版本升级涉及到底层库的重大变更(如从 glibc 2.28 到 2.34),以及包管理器的变化。AlmaLinux 官方推荐使用 leapp 工具来进行这一操作。
为什么不用 dnf distro-sync?
因为 dnf distro-sync 只能在同大版本内同步包版本(例如从 8.4 升到 8.8)。跨大版本需要解决依赖冲突、配置迁移、二进制兼容性等问题,leapp 就是为此设计的专用工具。
升级前的深度准备
安装 leapp 工具链:
sudo dnf install leapp-upgrade leapp-data-almalinux预检(Pre-upgrade audit): 这是最关键的一步。
leapp会模拟升级过程,检测所有可能导致失败的问题。sudo leapp preupgrade运行结束后,它会生成一份报告,通常位于
/var/log/leapp/leapp-report.txt。你需要仔细阅读这份报告。常见问题包括:- 第三方仓库冲突:EPEL 或其他非 AlmaLinux 官方源的包可能与新版本不兼容。
- 自定义配置:某些服务的配置文件格式在新版本中已弃用。
- 内核模块:DKMS 编译的内核模块可能需要重新编译。
解决阻碍项:
leapp会将问题分为“错误”、“警告”和“信息”。只有“错误”会阻止升级。你需要针对每一个错误进行处理。例如,如果某个第三方包导致冲突,你可能需要暂时禁用该仓库或卸载该软件包。你可以使用
leapp answer --section remove_pam_pkcs11_module_check.confirm=True这样的命令来回答leapp提出的交互式问题,或者修改/var/lib/leapp/answerfile文件来批量处理。
执行升级
当预检通过,且你已经解决了所有阻碍项后,就可以开始真正的升级了:
sudo leapp upgrade
这个过程会比较长,因为它需要下载大量的新包并进行复杂的依赖解析。升级完成后,系统会提示你重启。
sudo reboot
重启后,系统会自动进入升级后的引导流程。再次登录后,运行 cat /etc/os-release 确认版本是否已变为 AlmaLinux 9。
升级后的清理
升级完成后,旧的内核和不再需要的包可能还留在系统中。运行以下命令清理:
sudo dnf autoremove
sudo package-cleanup --oldkernels --count=1
第五步:避坑指南——常见失败场景及应对
即使做了万全准备,意外也可能发生。以下是几个典型的“翻车”现场及其解决方案:
场景一:依赖地狱(Dependency Hell)
- 现象:
dnf报错,提示无法解决依赖冲突,或者某个关键包被回滚。 - 原因:通常是因为启用了多个第三方仓库(如 EPEL, Remi, Docker CE),它们提供的包版本与 AlmaLinux 官方源冲突。
- 对策:
- 临时禁用第三方仓库:
sudo dnf --disablerepo='*' --enablerepo='baseos,appstream' update。 - 如果必须使用第三方包,尝试在
leapp预检阶段就将其移除或替换为官方兼容版本。 - 使用
dnf history undo回滚最近的失败事务。
- 临时禁用第三方仓库:
场景二:服务启动失败
- 现象:升级后,Nginx 或 MySQL 无法启动,日志显示缺少共享库(
.so文件)。 - 原因:GLIBC 版本升级后,旧的二进制文件可能链接到了不存在的旧版库。
- 对策:
- 检查日志:
journalctl -xeu nginx.service。 - 重新编译或重新安装该服务:如果是源码安装的软件,需要重新编译;如果是 RPM 包,运行
sudo dnf reinstall <package-name>。 - 使用
ldd命令检查二进制文件的依赖:ldd /usr/sbin/nginx,找出缺失的库。
- 检查日志:
场景三:配置文件冲突
- 现象:升级过程中提示配置文件已修改,询问是保留原样还是安装新版本。
- 原因:管理员手动修改过配置文件,而新版本的包也默认修改了它。
- 对策:
- 永远不要盲目选择“Y”。
- 选择
n(保留原配置文件),然后手动比对差异:diff /etc/nginx/nginx.conf /etc/nginx/nginx.conf.rpmnew。 - 将必要的配置变更合并到你的配置文件中。
第六步:给小朋友也能听懂的比喻
为了让你更直观地理解这个过程,我们可以把 AlmaLinux 的升级比作给一栋正在住人的大楼做外墙翻新和内部电路改造。
- 日常补丁(Security Update):就像是大楼的保安发现某扇窗户锁坏了,赶紧换个新锁。这不影响住户的生活,甚至住户都不知道换过锁了,但大楼更安全了。
- 大版本升级(Major Upgrade):这就像是把大楼的电线全部换掉,从老式的铜线换成更先进的智能线路。
- 备份:相当于在动工前,让所有住户把贵重物品打包好,放在安全的仓库里。
- Leapp 预检:相当于工程师拿着图纸,提前检查每一面墙能不能拆,每一根梁有没有问题,列出所有可能出错的清单。
- 执行升级:工人们进场施工,可能会暂时停电停水(服务重启)。
- 重启:施工结束,大家搬回大楼,发现灯更亮了,网速更快了,但有些老式插头(旧软件)可能插不进新插座(新系统),需要适配器(重新编译或重装软件)。
结语:信任源于掌控
升级 AlmaLinux 并不是一场赌博,而是一次可控的工程实践。只要你遵循“备份-预检-分步执行-验证”的流程,失败的概率可以被降到最低。记住,技术专家的价值不在于从不犯错,而在于拥有将错误影响控制在最小范围的能力。
在实际操作中,建议你先在测试环境中完整演练一遍升级流程,特别是跨大版本升级。只有在测试环境一切正常后,再在生产环境执行。这种“先试后动”的习惯,是你作为系统管理员最宝贵的职业素养。
最后,保持好奇心,多阅读 AlmaLinux 的官方文档和社区论坛。每一次升级都是一次学习的机会,当你熟练掌握这些技巧后,你会发现,维护一台 Linux 服务器其实充满了秩序之美和控制之乐。现在,去检查一下你的系统吧,也许一个新的安全补丁已经在等你了。
