解决某研发手残导致的系统宕机问题的处理过程
背景
2022.8.8 公司一台服务器出现了宕机的现象:
所有的人都无法远程, 都提示密码错误.
但是网络还是通的.
2022.8.12 出差前一天去了一趟机房现场
发现使用键鼠登录也提示密码错误
认为很诡异, 一度跟维护同事产生冲突, 认为他们修改密码未告知.
使用rd.break的方式强改密码依旧无法登录.
最终使用一个非root用户执行登录发现可以, 但是想su 到root时提示错误
继而发现 根 目录都被赋予了 777 权限, 导致系统自保护无法登录.
解决过程-密码问题
rd.break的处理:
最开始是使用rd.break的方式去修改密码密码. 处理方式比较简单.
开机进入linux系统前的选择操作系统的界面.
点击e 进行编辑
在linux16开头的一行的末尾输入 rd.break. 并且使用ctrl+x进行启动.
进入系统后输入
mount -o remount,rw /sysroot/
然后执行
chroot /sysroot/
执行命令就可以修改密码
password root
如果要是开启了selinux 还需要执行如下命令
touch /.autorelabel
解决过程--无法登录的问题
上一步仅是记录. 其实改了密码还是不可以登录.
发现文件权限有问题后, 想到一个比较简单的解决办法. 跟改密码的方法一样.
只不过在passwd root 这一步修改为
cd /etc
chmod 644 passwd group shadow
chmod 400 gshadow
cd ssh
chmod 600 moduli ssh_host_dsa_key ssh_host_key ssh_host_rsa_key
chmod 644 ssh_config ssh_host_dsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pub
chmod 640 sshd_config
chmod 700 /var/empty/sshd
注意不同目录需要的权限不一样, 比如 密码等信息 可能必须用户有读权限, 但是非属主必须没有写权限
解决过程--解决文件权限问题
经过如上操作,重启后用户可以登录了. 不再提示密码错误
但是因为仅仅修改了几个文件权限, 比如像是su sudo等命令权限其实还是无法使用的.
这里想到很早之前信息王萌老师曾经在我不小心干翻 一个oracle RAC节点时提供的setfacl的解决思路.
当时为2016年一次POC测试. 王老师搭建了一个RAC环境 然后我很荣幸的 chmod 777 / software -R 了下.
直接宕机.
具体思路为:
找一台比较干净的机器, 需要注意尽量文件比较少,进程也比较少的机器,不然acl的列表可能会非常庞大.
mkdir /acl
getfacl / -R > /acl/dm.acl
这个命令可以递归的将当前系统的文件目录权限全部获取到.
然后将文件复制到 被开发搞崩的机器上面
setfacl --restore=/acl/dm.acl 就可以恢复.
结论
修改好后重启一下服务器.
验证可以登录
用命令打开达梦数据库
cd /opt/dmdbms/bin && nohup ./dmserver /opt/dmdbms/data/DAMENG/dm.ini &
发现达梦数据库也正常了.
问题解决.
