===== 分割线 =====
本题取材于真实事件。
Reverier 是个干运维的,7x24 小时服务随叫随到的那种。
他负责了好几台服务器,没事还要响应各种各样的小事故(说通俗点就是擦屁股的),比如什么学弟不小心给自己的 /usr/lib 删了啊,隔壁楼实验室的学姐运维的古老 Ubuntu 14 找不到软件源了啊,楼上课题组跑 AI 的机器 CUDA 又爆了啊,室友搞二进制分析用的 PowerPC 虚拟机又起不来了什么的。
每次帮忙完,Reverier 都会去学校的 711 便利店买一瓶椰子水犒劳一下自己。
好了这是前言,然后今天 Reverier 遇到了一个离谱的事。
西安电子科技大学的一些课题组使用的古老服务器有些来源于超算中心,有些则在祖传了很久的老旧机房里,想联系到硬件管理员难如登天,联系到了他也不一定找得到钥匙。然后大伙就都用着一根网线连接着一台不知道跑了多久的 linux 机器凑合用。直到有一天,有一个哥们手滑给 glibc 卸载了。
glibc 是什么东西呢?几乎所有的现代 GNU/Linux 程序都链接在上面(musl程序毕竟是少数)。这下好了,连基础的 ls、cp、mv 都没法用了。于是这哥们开始寻找补救措施,有好几个学长的毕业论文数据还在上面呢,这要是丢了那学长们就可以和他同一年毕业了。但是怎么补救啊?手头啥也没有,于是问了一圈人,给 Reverier 冤大头找来了。现在整个服务器只有一个 shell 还活着,没有 glibc 连新的 ssh 连接都无法建立。
抢救完这一单,Reverier 感觉自己冒了一斤的汗。时间回到那个萧瑟冬天的下午,你能从这样一个棘手场景中将服务器抢救回来吗?
题目连接方式:
$ ssh [email protected] -p <port>
root 的密码: toor
注:为了降低难度,你只需要恢复 ls 和 cat 即可完成题目目标,无须恢复服务器的 glibc。
再注:此环境为一次性环境,如果没能一次性成功抢救服务器,断连之后服务器就彻底迷失在落满尘土的机房里了。(第一次抢救失败后请重启环境)
再注:平台的网络不太稳定,WebSocket连接有可能会断。如果频繁断连影响做题,你可以考虑给以下配置加入你的 ssh config 中:
Host *
ServerAliveInterval 5
ServerAliveCountMax 30
flag 文件在 /flag.txt 。