今天某开发人员找到我说, 腾讯云某某某跳板机远程连接不上啦, 赶紧给看看..... 影响项目进度啦
好家伙, 又把服务器搞挂了, ping ,telnet.... 先招呼一通, 果然 22 端口挂掉了... 检查了下安全组没啥问题
问题机器系统 CentOS7.6, 通过腾讯云 VNC 后台登录上去服务器, 这里说明下原理, VNC 相当于通过 console 方式连接到云主机, 不依赖于网络. 当咱们云服务被各种 "不可抗力" 因素导致网络不通或者 sshd 挂掉的情况下可以通过 VNC 的方法进行登录.
腾讯云主机 VNC 登录入口
首先 netstat -anltp|grep 22 看看端口情况, emmm... 空白一片.
接下来咱们重启下 sshd 服务:
systemctl restart sshd.service
果然没有那么简单哈, 报错了, 咱们查看一下 sshd 状态看看具体是啥报错
systemctl status sshd.service
查看 sshd 状态
以上一堆东西比较有用的是这一句:
error while loading shared libraries: /lib64/libcryto.so.10: .... short
什么意思呢? 意思是哎呀, sshd 服务重启失败了, 原因是载入库文件时失败, 太短了... 短. 说白了, 损坏了
OK , 咱们接着看
ls -l /lib64/libcrypto.so
/lib64/libcrypto.so 库文件
原来是做了软链接到了 / lib64/libcrypto.so.1.0.2k 下
ls -l libcrypto.so.1.0.2k
libcrypto.so.1.0.2k 损坏
果然, libcrypto.so.1.0.2k 损坏了, 咱们找个健康的机器看看正常的文件有多大.
正常 libcrypto.so.1.0.2k 大小是 2.5M
诊断完毕:/lib64/libcrypto.so.1.0.2k 文件损坏
修复此文件有 2 种方法:
1, 使用 CentOS 7.6 系统镜像进行修复
2, 从健康机器上直接复制过去修复
但是这里是腾讯云, 第一种方法行不通, 且费时费力, 面对项目进度压力果断选择第二种方法;
但是问题又来了, 咱们应该怎么复制呢? 作为一个传统运维, 首先想到的肯定是 scp,ftp..... 各种文件传输方法, 再不行就搭个 web 服务器 wget / curl 下载下来, 还有牛逼的开发运维直接就 python 搭建简易文件服务器. 但是很遗憾,/lib64/libcrypto.so.1.0.2k->/lib64/libcryto.so.10 在系统内地位非常搞, 咱们常用的工具都依赖于这个文件, 这就导致咱们目前能想到的命令都被封死了, 包括 yum 命令. 且腾讯云 VNC 后台智能执行命令输入输出, 无法进行文件传输, 这可怎么办呢?
咱们修复归修复, 总不能影响开发人员工作, 先把这台跳板机的公网 ip 转移到另外的服务器先让开发用起来:
登录到腾讯云 CVM 控制台 -> 找到相应的服务器 -> 公网 ip -> 转为弹性公网 ip -> 转到弹性公网 ip 控制台找到该公网 ip
-> 解绑 -> 绑定到该集群下另外一台服务器充当临时跳板机
公网 ip 转换为弹性公网 ip
传统的办法不行, 咱们就发挥脑洞, 创建一块云硬盘.
创建云硬盘
挂载云硬盘
云硬盘目前是白菜价, 按量计费一小时才 1 分钱, 容量无所谓嘛, 反正咱们文件只有 2.5MB, 硬盘名随意填就好啦, 提交创建.
创建好后咱们把该云硬盘挂载到另外一台健康的 CentOS 7.6 的云主机上, 挂载好后咱们通过 SSH 或者 VNC 的方式连接上去
fdisk -l
看一下新挂载的硬盘分区是什么分区路径
fdisk -l 查看分区信息
格式化化分区:(注意下面的命令千万不要写错了, 写成 vda 你就凉凉了)
mkfs.ext4 /dev/vdb
格式化分区为 ext4
创建一个临时路径
mkdir -p /mnt/tmp
挂载硬盘到该临时路径
mount /dev/vdb /mnt/tmp
复制健康的 libcrypto.so.1.0.2k 到云硬盘
cp /lib64/libcrypto.so.1.0.2k /mnt/tmp
ls -l /mnt/tmp 检查一下, 确保 libcrypto.so.1.0.2k 大小是 2.5M 无误
OK, 万事俱备, 只欠东风, 咱们把云硬盘解挂载后再挂载到问题机器上
umount /mnt/tmp
然后到腾讯云硬盘控制台进行解挂载
卸载云硬盘
然后重新挂载到问题机器上, 重复刚刚挂载的动作:
- mkdir -p /mnt/tmp
- mount /dev/vdb /mnt/tmp
接下来咱们进行文件恢复:
cp /mnt/tmp/libcrypto.so.1.0.2k /lib64
检查一下:
- ls -lh /lib64/libcrypto.so.1.0.2k
- /lib64/libcrypto.so.1.0.2k
OK, 确认没问题了, 咱们重启 sshd
systemctl restart sshd.service
重启 sshd
SSH 连接没问题了, netstat 观察端口 22 也起来了, 完美修复. 解挂载和释放掉刚刚的临时云硬盘, 修复成本 0.01 元 (手快网络好的同学可以做到 0 元). 把弹性公网 ip 切换回这台机器丢回去给研发狠狠骂一顿, 收工..
啰啰嗦嗦说了这么多, 其实想传达给大家一个思路, 在云上当传统运维工具 scp ,ftp, Web server 甚至 yum 命令都失效的情况下, 咱们可以通过云硬盘的方式来往虚拟机传输文件, 以完成修复工作.
最后, 感谢大家观看, 我是你们的朋友 Mr.JC, 咱们下回见~~
来源: https://www.qcloud.com/developer/article/1603131