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

10 小时 57 分钟前
 oferge0311

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

感谢。

1352 次点击
所在节点    Linux
49 条回复
cslive
10 小时 42 分钟前
命令写在/etc/rc.local 里
oferge0311
10 小时 28 分钟前
@cslive 是重启前的检查,避免出现因为 fstab 文件而重启失败,进行规避。写在自启文件里面的化,没这个而此操作的必要性吧? fstab 本身就会在启动时会操作一遍的阿
cslive
10 小时 22 分钟前
@oferge0311 #2 不要动 fstab 文件,"mount /dev/sdb /mnt"写在/etc/rc.local 里即可,你动 fstab 拼错了或者 nfs 挂载不上卡住了启动不起来进救援模式改文件很麻烦,写在/etc/rc.local 不会影响启动,最多目录挂不上去
oferge0311
10 小时 16 分钟前
@cslive 最多目录挂不上。。。。。 如果是数据盘呢,如果是 nfs 共享存储呢。。。大批量主机,你这个方法能正常拉起系统吗,要做到的是减少工作量,但后续的检查工作不比 1 台机器起不来修的工作量要小阿,难道还要在重启之后执行一遍 mount -a 吗
Kirkcong
10 小时 13 分钟前
我们的方案是,分批重启,一天重启个五六台
kenX
10 小时 12 分钟前
需求都这么明确了,丢给 ai 出个脚本不行了?
oferge0311
10 小时 10 分钟前
@kenX 用 ai 跑了脚本了,但是主机批量蛮大的,预计的情况也不一定,我不太想使用。出问题肯定算。。。
oferge0311
10 小时 9 分钟前
@Kirkcong 五六台。。。。我们的机器还是蛮多的,测试灾备的主机环境是这个的千倍多,生产比测试灾备的要多几倍
cslive
10 小时 8 分钟前
@oferge0311 #4 我已经说的很清楚了,这种方法能保证重启,挂不上去那肯定你命令有问题,盘有问题,nfs 网络问题,这些是你要想办法解决的
Kirkcong
10 小时 6 分钟前
@oferge0311 所以这是个长期计划,半年一年差不多了
oferge0311
10 小时 5 分钟前
@cslive 要做到的是重启前的检查呀,fstab 文件拿最简单的,defaults 没有 s 都会起不来进入救援。
Kirkcong
10 小时 3 分钟前
@oferge0311 你们可以多分几个人,每天多重启几台。如果你说生产机器也面临这个问题,那我只能说架构整体太脆弱了,怎么会允许这种事情呢?如果是前人留下的,那就看愿意花多少成本去填坑了。
dream10201
10 小时 1 分钟前
改成开机不自动挂载,访问挂载目录才自动挂载,这样就不会影响到开机。
oferge0311
10 小时 1 分钟前
@Kirkcong Linux 这个开源项目,内核漏洞不断的被发现,厂商不断的发布补丁,不断的打,太多了,压根属于上上上一个还没打完,又来新的,只能是可着优先级高的业务系统进行操作了。而且我也不想去管这个,不是该操的心,只想看看能不能学到一种方法,丰富自己的同时还能减轻工作,毕竟每次遇到机器起不来修也很麻烦,走各种流程
oferge0311
9 小时 59 分钟前
@Kirkcong 生产环境已经算好了的,问题少的,顶多遇到个 fstab 和网络网卡问题,其他都是配合应用解决它们的服务,测试和灾备环境才是真正属于,运行时候就是个雷,重启才发现。几台可不止,测试灾备最多一晚上 1000 台,生产目前最多是 600 多,几乎都是一个业务的。
Kirkcong
9 小时 53 分钟前
@oferge0311 没办法,只能不断的打补丁。你这个场景里面最大的问题不在于怎么做到 runtime to permanent.而是说架构本身没设计好,比如我们的机器,不管是 dsr 还是 psr,所有机器都统一配置,需要持久化的东西都在 ansible playbook ,即便没有挂载上的,直接跑 mount -a 即可。甚至每个机器安装的 rpm 、pip modules 都是一样的,全都由 ansible role 管理,而 ansible 文件则放在 bitbucket 中。

如果你不是管事的,那就直接把这问题报告上去,说清楚现状,以及风险点。怎么决策是上面的事情。你千万不要去做任何冒险的事情,因为一旦出了事,都是你的;如果弄好了,没什么收益,并且出事的概率极大。
oferge0311
9 小时 48 分钟前
@Kirkcong 明白您的意思,但根据这一季度做的这几万台,能正常拉起系统的,一般都甩不到我们身上。我也不去做这个问题报告,和+1 领导说一下这个问题,+1 领导是技术的,如果是他提供的脚本,肯定是比我从 ai 跑出来的脚本,从”安全与执行“要强的。我们也是用 ansible 操作,机器太多,后续要替换其他的了。我们有个镜像仓库,补丁包打到里面,yum update 去指定对应的仓库名称的特定包,都是写好的 yaml [都是+1 写的]
june4
9 小时 45 分钟前
都要重启了为什么不能变化下系统状态呢?重启了不是又重置了。如果 mount -a 出问题,那就先别重启,通知人修复机器问题再重启,否则不是明知故意个留个雷在这机器吗 反正也是要解决这个问题的
oferge0311
9 小时 44 分钟前
@Kirkcong 目前就是重启前升级失败的问题,这种一般都是跑 playbook 时的 python 被应用改了,或者 rpm 需要 rebuilddb 重构一下,或者也就是存储满了,升级不了。现在就是有点钻牛角,想要简单且不那么冗余的预防这个重启后系统失败拉起的点。前面 6 楼老师说的直接跑 ai 脚本出来也行。我在试 13 楼老师的取消开启不自动挂载方案在我的本地机,但这种应该不适合在大批量生产环境。有种不如不做,做了反而怪你。
oferge0311
9 小时 43 分钟前
@june4 我有考虑过如果先执行 mount -a 是不是万事大吉,但生产环境的 mount -a 如果出现挂载点重复等操作,也不是不可能存在的,如果覆盖挂载,比重启起不来去修还要麻烦。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1237351

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX