一次CentOS7 glibc灾难的全链路修复

000

作者：wanger
公众号：运维开发故事
博客：https://devopstory.cn

背景

有一台Centos 7的服务器执行系统命令提示GLIBC的错误，在后来排查中发现是有更新过系统，系统中同时存在centos7和centos8的包导致系统库损坏，这台服务器上安装了编译打包的环境，重装成本很高，还是尽力去修复吧，下面是修复过程

图片

修复过程

  1. 首先挂载centos7的iso镜像进入救援模式， 使用 ISO 里的 rpm 包重新安装 glibc 。

进入救援模式后，CentOS 会提示是否挂载原系统分区到 /mnt/sysimage，输入1之后回车就可以了

图片

  1. 切换到原系统环境，结果chroot命令都无法执行了
chroot /mnt/sysimage

图片

  1. 当前只能在在救援环境里用 rpm --root 重装了。首先挂载并查找 ISO 里的 glibc 包
mount /dev/cdrom /mnt/cdrom
find /mnt/cdrom -name "glibc*.rpm"
  1. 直接在原系统根目录安装，因为 chroot 已经坏掉，要用 --root 指定路径
rpm --root /mnt/sysimage -ivh --force --nodeps /mnt/cdrom/Packages/glibc-2.17-*.rpm
rpm --root /mnt/sysimage -ivh --force --nodeps /mnt/cdrom/Packages/glibc-common-2.17-*.rpm

参数解释：

  • --force --nodeps → 强制覆盖，不检查依赖（因为依赖链也可能损坏了）

  • --root /mnt/sysimage → 指定修复目标系统

可以看到rpm --root 装进去了，但 %post/trigger 脚本在目标根里执行失败（iconvconfig、/bin/sh 都被坏掉的 glibc/ld 撞到了），所以还需要“不跑脚本，强制覆盖一遍”，再让系统能 chroot，最后在 chroot 里用 yum 正常收尾

图片

先覆盖安装glibc 与 glibc-common，但禁止执行脚本，避免再次触发坏环境，

rpm --root /mnt/sysimage -Uvh --force --nodeps --nopre --nopost --notriggers \
  /mnt/cdrom/Packages/glibc-2.17-*.rpm \
  /mnt/cdrom/Packages/glibc-common-2.17-*.rpm

--nopre --nopost --notriggers = 不跑 %pre/%post/%trigger，避免上面截图中的 scriptlet failed, exit 127。

下面截图就是执行完成了

图片

  1. 修复关键链接
ln -sf /lib64/ld-2.17.so   /mnt/sysimage/lib64/ld-linux-x86-64.so.2
ln -sf /lib64/libc-2.17.so /mnt/sysimage/lib64/libc.so.6

图片

  1. 绑定必要伪文件系统后再 chroot
mkdir -p /mnt/sysimage/mnt/cdrom
# 挂载 ISO 到目标系统的 /mnt/cdrom
mount /dev/sr0 /mnt/sysimage/mnt/cdrom

mount -o bind /dev  /mnt/sysimage/dev
mount -o bind /proc /mnt/sysimage/proc
mount -o bind /sys  /mnt/sysimage/sys

chroot /mnt/sysimage /bin/bash
ls /mnt/cdrom/Packages | grep glibc

图片

  1. 在 chroot 里用 ISO 做一个临时 repo
cat >/etc/yum.repos.d/cdrom.repo <<'EOF'
[cdrom]
name=CentOS7 ISO
baseurl=file:///mnt/cdrom
enabled=1
gpgcheck=0
EOF

图片

  1. 让 glibc 及相关包重装一遍
yum reinstall -y glibc glibc-common

这里发现安装失败了，glibc的版本有冲突， centos7.9的系统里还残留了 glibc 的 el8 版本，这可能就是系统为什么坏掉的原因

图片

  1. 检查下系统 有哪些 glibc 包并将其删除
rpm --root / -qa | grep glibc

把所有 el8 结尾的 glibc 包都删掉，只保留 el7 的

rpm  -e --nodeps glibc-headers-2.28-164.el8.x86_64
rpm  -e --nodeps glibc-langpack-zh-2.28-164.el8.x86_64
rpm  -e --nodeps glibc-devel-2.28-164.el8.x86_64
rpm  -e --nodeps glibc-locale-source-2.28-164.el8.x86_64
rpm  -e --nodeps glibc-langpack-en-2.28-164.el8.x86_64

图片

  1. 在 chroot 里清理并重装 glibc和其他可能损坏的包
yum reinstall -y glibc glibc-common
yum reinstall -y nss-softokn-freebl nss nscd libgcc libstdc++ bash coreutils

可以看到glibc安装成功了，但是安装其他包的时候报错了

说明系统里还残留了 EL8 的 libcrypt（来自 libxcrypt 包）。
CentOS 7 的 libcrypt.so.1 是 glibc 自带的（libcrypt-2.17.so），而 EL8 的 libcrypt.so.1 来自 libxcrypt，需要 GLIBC_2.25。  CentOS 7 的 glibc 只有 2.17，所以所有调用 libcrypt.so.1 的程序都会报错。

图片

直接把 libxcrypt（EL8）* 移除，并把 libcrypt 换回 el7 的版本即可。

不要在 chroot 里跑，全部在外层用 --root /mnt/sysimage 执行，避免被坏的 libcrypt 影响。

找出系统里与 crypt 相关的 EL8 包

rpm --root /mnt/sysimage -qa | egrep -i 'libxcrypt|libcrypt|glibc'

卸载 el8 的 libxcrypt 系列

rpm --root /mnt/sysimage -e --nodeps libxcrypt-4.1.1-6.el8.x86_64
rpm --root /mnt/sysimage -e --nodeps libxcrypt-devel-4.1.1-6.el8.x86_64

图片

纠正 libcrypt 的实际文件与链接（el7 应该存在 libcrypt-2.17.so）

ls -l /mnt/sysimage/lib64/libcrypt*
ln -sf /lib64/libcrypt-2.17.so /mnt/sysimage/lib64/libcrypt.so.1

图片

再次执行就不会报错了

yum reinstall -y glibc glibc-common
yum reinstall -y nss-softokn-freebl nss nss-util nspr libgcc libstdc++ bash coreutils

图片

  1. 刷新缓存
/sbin/ldconfig
/usr/sbin/iconvconfig || true
  1. 回到救援模式外层，解除绑定并卸载cdrom,之后重启
umount /mnt/sysimage/{dev,proc,sys} 
umount /mnt/sysimage/mnt/cdrom 
reboot
  1. 重启后登录系统发现刚输入用户名立刻提示 “Login incorrect”，可能还是PAM认证这块有损坏了，进入救援环境继续排查，在进救援模式的过程中发现了下面的报错。systemd 会调用 /usr/sbin/sulogin 来提供 root 登录，系统里sulogin 不见了导致现在无法登录 。

图片

sulogin 属于 util-linux 包，还是进入救援模式重装

mount -o bind /dev  /mnt/sysimage/dev
mount -o bind /proc /mnt/sysimage/proc
mount -o bind /sys  /mnt/sysimage/sys
chroot /mnt/sysimage /bin/bash
mount /dev/sr0 /mnt/cdrom
find /mnt/cdrom/Packages -name "util-linux*.rpm"
rpm -ivh --force --nodeps /mnt/cdrom/Packages/util-linux-2.23.2-65.el7.x86_64.rpm
ls -l /usr/sbin/sulogin
exit
umount /mnt/sysimage/{dev,proc,sys}
reboot

图片

  1. 重装util-linux后发现还是不行，于是又继续排查
ls -l /etc/nsswitch.conf*
ls -l /etc/pam.d/login
ls -l /etc/pam.d/system-auth 
ls -l/etc/pam.d/password-auth

当我使用authconfig 重建system-auth/ password-auth等默认规则时发现问题了

authconfig --enableshadow --passalgo=sha512 --update

这里明显是 /sbin/authconfig 被换成了 Python3/EL8 的版本，CentOS7 的 authconfig 是 shell+perl 脚本，不会报这种 Python 错，说明el8的包还是没清理干净，登录认证的包也被污染了

图片

  1. 确认util-linux的包是否正确，centos7的包正常应该是2.23版本
rpm -qpi /mnt/cdrom/Packages/util-linux*.rpm | grep Version

因为 login 流程靠 PAM + sulogin，所以需要覆盖安装一下 PAM & shadow-utils

rpm -ivh --force --nodeps /mnt/cdrom/Packages/pam-1.1.8-23.el7.x86_64.rpm
rpm -ivh --force --nodeps /mnt/cdrom/Packages/shadow-utils-4.6.5.el7.x86_64.rpm

覆盖安装 authconfig

rpm -ivh --force --nodeps /mnt/cdrom/Packages/authconfig-6.2.8-30.el7.x86_64.rpm

重新生成 PAM 配置，结果发现还是报错

authconfig --enableshadow --passalgo=sha512 --update

这里他提示的是缩进错误，** **应该还是Python3 解释器在运行（Python3 对混用缩进更严格），而 CentOS 7 应该用 Python2.7， 这说明系统里还残留了 EL8 的 python3或者**/usr/bin/python****指到了python3。  **

图片

查看当前python确实指到了python3上

python -V

安装centos7的python（2.7.5）并修改python的默认解释器

rpm -ivh --force --nodeps /mnt/cdrom/Packages/python-2.7*.el7.x86_64.rpm
ln -sf /usr/bin/python2.7 /usr/bin/python
python -V

重新生成 PAM 模板并刷新链接，这次发现没有报错了

/usr/bin/python2.7 /sbin/authconfig --enableshadow --passalgo=sha512 --update

刷新动态库链接

/sbin/ldconfig

图片

修改完之后再次重启

图片

  1. 重启发现还是无法登录系统，并且我在进救援模式使用vim编辑器时又发现了报错，libnsl.so.1 和 glibc 版本不匹配，说明系统里还是残留了 el8的libnsl，需要清理el8的包并重装一次glibc核心库

图片

再次重新覆盖安装glibc，需要跳过签名和摘要校验不然会报错

mount /dev/sr0 /mnt/sysimage/mnt/cdrom
rpm --root /mnt/sysimage -Uvh --force --nodeps --nopre --nopost --notriggers --nosignature --nodigest \
  /mnt/sysimage/mnt/cdrom/Packages/glibc-2.17-317.el7.x86_64.rpm \
  /mnt/sysimage/mnt/cdrom/Packages/glibc-common-2.17-317.el7.x86_64.rpm

图片

上步执行成功之后再把几个关键软链接校正并刷新缓存

ln -sf /lib64/ld-2.17.so            /mnt/sysimage/lib64/ld-linux-x86-64.so.2
ln -sf /lib64/libc-2.17.so          /mnt/sysimage/lib64/libc.so.6
ln -sf /lib64/libcrypt-2.17.so      /mnt/sysimage/lib64/libcrypt.so.1
ln -sf /usr/lib64/libnsl-2.17.so    /mnt/sysimage/lib64/libnsl.so.1

# 为目标根刷新 ld 缓存（不用 chroot）
/sbin/ldconfig -r /mnt/sysimage

安装glibc核心包及相关软件重装一遍

mount -o bind /dev  /mnt/sysimage/dev
mount -o bind /proc /mnt/sysimage/proc
mount -o bind /sys  /mnt/sysimage/sys
chroot /mnt/sysimage /bin/bash
mount /dev/sr0 /mnt/cdrom
yum reinstall -y glibc glibc-common pam shadow-utils util-linux nss nss-softokn-freebl nspr nss-util || true
/sbin/ldconfig

上步执行完成后进行验证

readlink -f /lib64/libnsl.so.1      # 现在应为 /usr/lib64/libnsl-2.17.so
readlink -f /lib64/libcrypt.so.1    # 现在应为 /usr/lib64/libcrypt-2.17.so
ldd /bin/login | grep 'not found' || echo "login deps OK"
getent passwd root                  # 应能打印出 root:... 这一行

都返回正常后重启登录，可以看到已经修复完成可以正常登录系统

exit
umount /mnt/sysimage/{dev,proc,sys} 2>/dev/null
reboot

图片

总结

这次事故的本质是el8包误混入el7引发glibc系列错配，libc/libcrypt/libnsl 与 PAM/NSS、util-linux、authconfig 等系统组件都被损坏，由于系统包被污染的很严重，这次的修复过程可谓是一波三折。

修复过程是在救援环境用 同版本的ISO 将 glibc 家族强制回滚，修复ld-linux、libc、libcrypt、libnsl等关键软链，恢复 PAM/登录链路并将默认 Python 指回 2.7版本。

最后还是要说一句：操作不规范，运维两行泪！

最后，求关注。如果你还想看更多优质原创文章，欢迎关注我们的公众号「运维开发故事」。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！

你还可以把我的公众号设为「星标」，这样当公众号文章更新时，你会在第一时间收到推送消息，避免错过我的文章更新。

我是 wanger，《运维开发故事》公众号团队中的一员，一线运维农民工，云原生实践者，这里不仅有硬核的技术干货，还有我们对技术的思考和感悟，欢迎关注我们的公众号，期待和你一起成长！

------本页内容已结束，喜欢请分享------

© 版权声明
THE END
故障恢复
喜欢就支持一下吧
点赞0
分享
  • 运维开发故事的头像-运维开发故事
  • 运维开发故事
    2256.8W+22
    由一群志同道合的小伙伴共同维护，有运维也有开发，内容不限于Linux运维，devops工具链，k8s容器化技术，监控，日志收集，网络安全，Python或GO开发，团队成员有乔克、wanger、冬哥、素心、华仔、郑哥、姜总、夏老师
相关推荐
运维开发故事-一次CentOS7 glibc灾难的全链路修复
一次CentOS7 glibc灾难的全链路修复
一次CentOS7 glibc灾难的全链路修复
2小时前 0
评论 抢沙发
运维开发故事的头像-运维开发故事

昵称

取消
昵称

请填写用户信息：

  • 昵称(必填)
  • 邮箱(必填)
表情
[aoman][baiyan][bishi][bizui][cahan][ciya][dabing][daku][deyi][doge][fadai][fanu][fendou][ganga][guzhang][haixiu][hanxiao][zuohengheng][zhuakuang][zhouma][zhemo][zhayanjian][zaijian][yun][youhengheng][yiwen][yinxian][xu][xieyanxiao][xiaoku][xiaojiujie][xia][wunai][wozuimei][weixiao][weiqu][tuosai][tu][touxiao][tiaopi][shui][se][saorao][qiudale][se][qinqin][qiaoda][piezui][penxue][nanguo][liulei][liuhan][lenghan][leiben][kun][kuaikule][ku][koubi][kelian][keai][jingya][jingxi][jingkong][jie][huaixiao][haqian][aini][OK][qiang][quantou][shengli][woshou][gouyin][baoquan][aixin][bangbangtang][xiaoyanger][xigua][hexie][pijiu][lanqiu][juhua][hecai][haobang][caidao][baojin][chi][dan][kulou][shuai][shouqiang][yangtuo][youling]
代码

请输入代码：

确认
图片

分类