返回 AI 资讯
社区讨论V2EX 技术

求助:有没有无影响检查 /etc/fstab 的可靠方法?

最近在做一批 Linux 主机的 CVE 漏洞修复,遇到一个比较实际的问题,想请教一下大家有没有成熟的处理方式。 因为很多安全补丁,现在都是涉及到内核级别,安装完成后都需要重启才能真正生效,但是在批量重启主机之前,也遇到了 /etc/fstab 中存在异常配置而无法拉起的情况。 因为如果 /etc/fstab 里存在错误,比如: UUID 或设备路径错误 文件系统类型错误 挂载参数不支持 本地设备不存在 NFS 等网络文件系统不可达 其他只有实际挂载时才会暴露的问题 都有可能导致主机重启后进入救援,或无法拉起 目…

内容摘要

最近在做一批 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 思路。 感谢。

资讯来源

V2EX

原文链接

打开原文