安装telnet引发的惨剧

最新推荐文章于 2023-12-01 12:47:46 发布

33号球手

最新推荐文章于 2023-12-01 12:47:46 发布

阅读量386

点赞数

文章标签： linux centos 运维 glibc

本文链接：https://blog.csdn.net/sinat_29220797/article/details/120214696

版权

本文详细记录了一次在CentOS6.4上使用错误的yum源安装telnet，意外升级glibc导致服务器异常的过程。通过分析日志、重做软连接、救援模式恢复系统等步骤，最终成功修复了服务器，恢复了正常登录。过程中强调了低版本系统不应使用高版本yum源、慎删libc.so.6以及救援模式下的正确操作。同时提到了逻辑卷组激活、NFS挂载和硬件不兼容等问题的解决方案。

摘要由CSDN通过智能技术生成

0 环境
环境：centos 6.4
起因：因centos 6.4 需要安装telnet。安装过程中使用了centos 7.9 的yum源进行升级。导致服务器异常。通过堡垒机登录显示需要密码，输入正确的密码后也无法登录。直接跳回登录界面。本地登录也是同样的效果。

现在开始复盘整个过程：
1 安装telnet
通过连接到centos7.9的yum源，执行yum install telnet --nogpgcheck 进行安装。–nogpgcheck在生产环境不需要，可能是因为配置了/etc/yum.repo.d/centos-local.repo中的gpgcheck=0导致没有检测。
在这里插入图片描述

安装完成
在这里插入图片描述

2 异常
导致的后果是如下：通过正确的账号密码也无法登录
在这里插入图片描述

3 日志分析
查看linux日志 /var/log/secure
在这里插入图片描述

4 重做软连接
原先先通过将/lib64/libc.so.6 重新做软连接到libc-2.12.so（原有服务器为libc-2.12.so）,但是发现libc-2.12.so的包已经被删除了。考虑到重新安装glibc-2.12的包，使用了linux的rz命令，将rpm包进行上传（sftp功能已无法使用）。
4.1 安装rz命令
yum install lrzsz --nogpgcheck
4.2 上传glibc 2.12 的相关安装包
在这里插入图片描述

4.3 安装(不强制安装会导致安装不成功，显示更高的版本已安装)
rpm -ivh * --nodeps --force
4.4. 将libc.so.6的连接换回libc-2.12.so
4.4.1 删除旧的连接
（这个步骤很危险，可能会导致整台机的服务挂掉，看到下面这个connot open shared object file的报错，会导致服务器很多命令都用不了)
cd /lib64
rm -rf libc.so.6
在这里插入图片描述

4.4.2 切换libc.so.6
执行下面命令后，会发现命令可以继续使用
export LD_PRELOAD="/lib64/libc-2.17.so"
在这里插入图片描述

4.4.3 重新做连接
命令可以继续执行。但是secure日志开始报错。
ln -s /lib64/libc-2.12.so /lib64/libc.so.6
5 登录测试
服务器还是继续无法登录，查看发现secure日志会有很多的报错：
在这里插入图片描述

查看发现服务器有很多的连接还是2.17的版本，原先还打算通过更改这些命令的连接到2.12的，通过测试发现删除某个连接后，整台服务器的任何命令都使用不了。切不可这样子做。
在这里插入图片描述

6 重启
看看重启服务器是否生效，发现服务器直接卡死
在这里插入图片描述

7 救援模式恢复系统
接下来就开始搞救援模式：
7.1 挂盘，虚拟机可以直接挂盘
在这里插入图片描述

7.2 开机使用CD-ROM
重新开机，按下esc键进入（如果开机太快，无法进入到救援模式，可以找到虚拟机的CentOS 6.4.vmx这个文件（对应的虚拟机），然后在文末加入bios.forceSetupOnce = “TRUE”，重启启动即可。
在这里插入图片描述

7.3 进入到救援模式：Rescue Installed System

在这里插入图片描述

进入到救援模式
在这里插入图片描述

7.4 救援模式下恢复文件
7.4.1原有服务器的目录挂在/mnt/sysimage下，进入到/mnt/sysimage/lib64的目录下，删除旧的连接2.12，连接到新的
在这里插入图片描述

7.4.2 切换到原有的服务器，重新启动服务器
chroot /mnt/sysimage
在这里插入图片描述

经过搜索才发现，这个是原先服务器因为缺少了/bin/sh /bin/bash才会报这个错。将救援模式下的拷贝过去即可。
在这里插入图片描述

拷贝： cp /bin/sh /mnt/sysimage/bin/
cp /bin/bash /mnt/sysimage/bin

切换
chroot /mnt/sysimage
重启
reboot
在这里插入图片描述

8 使用系统盘启动
重新选择不CD-ROM盘重启即可,按-+号进行选择
在这里插入图片描述

10 重启服务器
自检过程中，等到即可，大概等待几分钟
在这里插入图片描述

启动完成，完成修复
在这里插入图片描述

10 其他问题：
10.1 逻辑卷组无法正常激活问题
一台存储比较大的服务器因磁盘空间比较大，导致正常激活逻辑卷。
在这里插入图片描述

照样进入到/mnt/sysimage目录下，通过lvscan查看有那个逻辑卷异常
Couldn’t find device with uuid ‘pQMQJ3-Rq3M-kQD9-M6DB-UWLi-Dyk4-3pWoa7’.
Couldn’t find all physical volumes for volume group milan.
通过命令lvchange -ay /dev/centos 逻辑卷组名进行激活。在/mnt/sysimage 创建一个新的目录，然后将逻辑卷组通过mount /dev/centos /mnt/sysimage/test的方式挂载过来，然后进行上面的操作即可
10.2 windows NFS的挂载方式，然后输入密码即可
mount -t cifs //192.168.1.126/linux_nfs /mnt/linux_nfs/ -o username=linux
10.3 硬件不支持问题，跳过即可。
在这里插入图片描述

11 总结：
1 低版本的服务器切不可使用高版本的yum源进行安装软件，因可能同步升级了glibc等核心的库，导致服务器无法正常使用。 glibc 库无法进行回滚
2 删除libc.so.6属于高风险的操作，不到万不得已不要轻易操作
3 如果是虚拟机的化，就得打好快照，留个后路。
4 如果不小心升级导致了这个问题，正确的操作步骤是救援模式–拷贝sh,bash–切换系统盘启动–重启