覆盖libc.so.6的惨痛教训

背景
问题
原因
解决
- 1、当前session未断开
- 2、OS崩溃重启，所有ssh session断开
惨痛教训
- 1、对于上产环境的内核依赖库文件不能随意覆盖、删除。
- 2、 scp 文件覆盖问题
总结
参考

背景

发生时间: 2022年11月28日08:55:20
偷了个懒，在安装tmux的时候直接从别的服务器上copy二进制文件，而且是跨OS 版本的。缺少一些lib库文件，直接从安装好的机器上copy过来。然后系统就崩了。惨痛的教训.

为了在线上安装环境依赖，给glibc库升级，由于线上环境libc.so版本低，不支持安装，所以手贱把动态库中的libc.so.6给移走了，直接导致Linux系统崩溃，系统瘫痪，所有用户均被强制退出。
意识到缺少对libc.so的认识，以为跟普通的lib包类似，直接把新版的so软连过去就可以满足安装和升级，现在哦豁… 软链不软链已经不重要了，反正腿是软趴趴的。

问题

执行tmux 命令发现缺少相关库依赖文件. 于是一波S操作。

目标机器

 ~]$tmux new -s etl01
tmux: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory~]$tmux new -s etl01
tmux: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by tmux)
tmux: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libevent-2.0.so.5)
tmux: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib64/libevent-2.0.so.5)
tmux: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /usr/lib64/libevent-2.0.so.5)

tmux安装成功的机器

 ⚡ root@master1  /tmp  scp -p /usr/lib64/libevent-2.0.so.5 10.50.10.43:/usr/lib64/
root@10.50.10.43's password:
libevent-2.0.so.5                                                                                                       100%  291KB 107.7MB/s   00:00⚡ root@master1  /tmp ⚡ root@master1  /tmp ⚡ root@master1  /tmp  scp -p /lib64/libc.so.6 10.50.10.43:/lib64/
root@10.50.10.43's password:
libc.so.6                                                                                                                 0%    0     0.0KB/s   --:-- ETApacket_write_wait: Connection to 10.50.10.43 port 22: Broken pipe
lost connection✘ ⚡ root@master1  /tmp  scp -p /lib64/libc.so.6 10.50.10.43:/lib64
ssh: connect to host 10.50.10.43 port 22: Connection refused
lost connection✘ ⚡ root@master1  /tmp  scp -p /lib64/libc.so.6 10.50.10.43:/lib64
ssh: connect to host 10.50.10.43 port 22: Connection refused
lost connection

22端口down了，我就知道系统崩了。因为之前测试环境搞过一次，而这次是正式环境。

原因

libc.so.6 是很基础的库(glibc)，是软连接到在Linux系统中基本的命令，有很多可执行文件都会依赖这个共享库。当不小心把这个库改名字或者移走了，都会导致不同程度的异常，可以借助LD_PRELOAD变量和"ldconfig"命令来恢复这个共享库。前提是终端没有断开的情况下操作。
libc.so.6是一个类似于WINDOWS下的一个快捷指向型的文件，而 linux有两种库，分别为：glibc、libc

解决

解决分为两种情况

1、当前session未断开

如果发现问题的当下没有关闭当前terminal就比较好恢复。一旦关闭窗口将无法重新连接(可以自己新建窗口试下)，重启机器后也将无法进入系统。必须使用第二种方式修复

LD_PRELOAD允许你定义在程序运行前优先加载的动态链接库,因此在使用ln前就加载了lib库，而不是等到使用ln时加载，这样就能临时使用命令了

LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6

2、OS崩溃重启，所有ssh session断开

对于OS 直接崩溃的，比较难搞。我的属于这种，OS 直接重启了。而且起不来的那种。
当时登入ILO单用户模式，OS 在重启，一大堆trace，看着就好不了的那种。

主要思路
1、急救模式Rescue mode
2、rescue模式选则挂载sysinages 这个FS
3、在这个挂载点把之前的libc.so.6恢复

详细操作见参考【2】

惨痛教训

1、对于上产环境的内核依赖库文件不能随意覆盖、删除。

例如
①　内核级的 /lib64
②　系统级的 /usr/lib64
③　Root用户级别的/usr/local/lib64

2、 scp 文件覆盖问题

scp 命令默认会覆盖源文件，没有交互模式询问你是否覆盖。对于敏感文件scp 之前先确认目标服务器上是否存在，如果存在应先备份再进行后续操作.

总结

此次事件是因对系统层认知不足, 根本原因就是我使用了高版本 2.17 的libc.so.6,覆盖了系统的2.12版本导致的问题。
对于这个错误操作我做出深刻检讨, 对事件负全责。望今后自己和同事能引以为戒，避免再次发生此类事件.

参考

【1】修改libc.so.6导致崩溃解决
【2】救援模式恢复