最近在做一批 Linux 主机的 CVE 漏洞修复,遇到一个比较实际的问题,想请教一下大家有没有成熟的处理方式。
因为很多安全补丁,现在都是涉及到内核级别,安装完成后都需要重启才能真正生效,但是在批量重启主机之前,也遇到了 /etc/fstab 中存在异常配置而无法拉起的情况。
因为如果 /etc/fstab 里存在错误,比如:
UUID 或设备路径错误 文件系统类型错误 挂载参数不支持 本地设备不存在 NFS 等网络文件系统不可达 其他只有实际挂载时才会暴露的问题
都有可能导致主机重启后进入救援,或无法拉起
目前想要与大家探讨的是:
希望在 reboot 之前,对 /etc/fstab 做一次尽可能接近真实挂载结果的检查,但又不能真正执行挂载操作,也不能对当前系统状态造成影响。
我测试过:
mount -a -v -f
以及:
findmnt --verify --verbose
但实际测试下来,这两种方式的结果都无法完全和真正执行:
mount -a
的结果对应起来。
问题在于,大批量生产主机又不适合在重启前直接执行 mount -a 。
因为 mount -a 可能会把当前未挂载的文件系统真正挂载起来,也可能主动访问 NFS 、NAS 等网络存储,甚至改变当前系统状态。在复杂生产环境中,这种操作有可能产生额外影响,极端情况下甚至可能出现不可逆的问题。
所以想请教一下大家:
有没有一种相对可靠的方式,可以做到:
不实际 mount / umount 不产生真实写入 不改变当前系统状态 尽量检查出设备、UUID 、文件系统类型、挂载参数、网络挂载等问题 检查结果尽可能接近真实的 mount -a 最好适合通过 Ansible 、Shell 等方式批量执行
或者大家在做大规模 Linux 主机补丁升级、批量重启之前,通常是怎么处理 /etc/fstab 风险检查的?
感觉单纯做语法检查还不够,但真正执行挂载又风险比较大,所以想看看有没有比较成熟的 pre-reboot check 思路。
感谢。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.