AIX 关键系统文件被清空问题定位过程全记录.docx
- 文档编号:10109855
- 上传时间:2023-02-08
- 格式:DOCX
- 页数:25
- 大小:1.54MB
AIX 关键系统文件被清空问题定位过程全记录.docx
《AIX 关键系统文件被清空问题定位过程全记录.docx》由会员分享,可在线阅读,更多相关《AIX 关键系统文件被清空问题定位过程全记录.docx(25页珍藏版)》请在冰豆网上搜索。
AIX关键系统文件被清空问题定位过程全记录
AIX关键系统文件被清空问题定位过程全记录
问题描述
某日接到客户反馈,某系统备机重启后telnet无法登录,提示信息如下:
telnet(testlpar1)
telnetd:
/bin/login:
Cannotrunafilethatdoesnothaveavalidformat.
.
而ssh登录显示正常。
问题定位过程
从错误提示,/bin/login文件格式有问题,参照正常系统做一番简单检查,就可以看到:
/usr/sbin/tsm文件被清空了,导致了telnet登录失败。
从另一台主机上拷贝/usr/sbin/tsm之后,telnet恢复正常。
然而,系统重启后,同样的故障再次出现:
telnetd:
/bin/login:
Cannotrunafilethatdoesnothaveavalidformat.
这样看来,系统中仍存在隐患故障点,导致了/usr/sbin/tsm每次重启过程中都会被清空。
从实际情况看,/usr/sbin/tsm文件仍然存在,访问权限也未变化。
这说明在重启过程中的破坏性动作很可能是一次类似”>/usr/sbin/tsm”的清空文件操作。
下一步需要定位/usr/sbin/tsm文件为何被清空。
AIX从4.3版本开始就提供了Audit审计功能,能够对关键系统操作进行记录。
详细的介绍文档可以参考:
考虑到tsm文件被置空之前,首先需要写打开tsm文件,这样我们只需要监控对tsm文件的写打开操作即可追踪到故障点。
而且考虑到tsm文件的权限,只有root用户才有权限将其置空。
因此,只需要监控root用户下对tsm文件的写打开操作。
使用systemaudit功能快速锁定问题点
首先编辑audit配置文件:
在监控类files中定义了文件的各种操作:
考虑到系统中文件操作很多,直接监控files类日志信息量太大不方便定位问题,因此考虑只将FILE_Open监控事件加入到默认的general类中。
修改如下,在general类中增加FILE_Open事件监控:
audit日志默认以二进制方式记录,可以通过auditpr命令转换为文本方式。
本处为方便问题定位,直接将记录方式改为stream方式,以文本格式记录系统监控事件。
修改如下:
将streammode设置为on,而binmode设置为off:
经过修改的audit配置文件:
启动并持续调整audit设置
启动audit命令后,就可以在/audit/stream.out文件上看到审计日志了:
从以下/audit/stream.out输出看,记录过于简单,看不出打开的文件名:
要看到verbose**方式的输出,必须进一步调整streamcmds**命令参数。
编辑/etc/security/audit/streamcmds命令文件,在auditpr**命令后增加-v**参数:
然后重启audit服务:
此时如果再写操作tsm文件,就能得到如下信息(为了对比,在此处做了一个cp/usr/sbin/tsm/tmp/tsm操作):
注意这里的flags是open文件操作所带的参数,flags是int型变量,其定义可以在/usr/include/fcntl.h文件里找到:
这里只简单说明与本次问题定位相关的部分,考虑到只有写打开才能修改文件,只读打开可以忽略,因此只需要监控flags二进制表示最后两位中,有一位为1的情况。
如果flags二进制值最后两位有一位为1,则说明open参数至少设置了O_WRONLY或O_RDWR。
所以,flags:
67109633二进制最后一位为1,说明是O_WRONLY方式写打开。
相应地,flags:
67108864二进制最后一位是0,说明是O_RDONLY只读方式打开。
至此,我们配置好了/usr/sbin/tsm文件的写打开监控方法。
接下来我们需要把监控操作添加到启动脚本中去,确保开机就能监控到文件操作。
将audit监控设置为随系统启动
在/etc/inittab中增加如下条目:
参考(/etc/inittab)文件,红色部分为新增:
重现故障
重启系统以重现故障点。
从/audit/stream.out日志可以看到:
结合errpt以及系统进程启动情况,可以看到/usr/sbin/tsm文件是在开机后被置空,而不是关机的过程中置空:
例如:
再次重启重现故障
查看开机后生成的probevue日志,可以看到,pid为3670140的Kshell进程对/usr/sbin/tsm进行了写打开,其groupid为2556794。
针对其进程id、父进程id、进程组id进行查看:
只有进程组id下有对应的条目:
观察probevue日志记录:
可以确认tsm文件被置空是启动cimsys服务触发,而且,从probevue监控日志输出看,停止cimsys、启动cimsys过程中各出现了一次对/usr/sbin/tsm置空的操作。
从追踪的记录可以看到/opt/freeware/cimom/pegasus/bin/cimssys.shstartcimsys脚本被执行了。
由上面的跟踪情况可以推断,问题大概率是在脚本中执行”>/usr/sbin/tsm”操作造成(因为audit和probevue跟踪得到的进程名为ksh,而不是具体的应用比如cimsys之类),因此/opt/freeware/cimom/pegasus/bin/cimssys.sh脚本有很大的嫌疑。
跟踪脚本执行
接下来需要对/opt/freeware/cimom/pegasus/bin/cimssys.shstartcimsys执行过程进行检查以及跟踪。
检查cimssys.sh脚本
对比本机与其他机器上的/opt/freeware/cimom/pegasus/bin/cimssys.sh文件,发现文件内容并未被修改。
跟踪/opt/freeware/cimom/pegasus/bin/cimssys.sh的执行过程,发现其中主要的调用都是针对/opt/freeware/cimom/pegasus/bin/CIMdiagd.sh脚本,调用参数分别是start和restart,且输出都被重定向到/dev/null了。
手动执行/opt/freeware/cimom/pegasus/bin/CIMdiagd.sh脚本:
发现/usr/bin/kill报了很奇怪的错误(如上红色部分)。
对/usr/bin/kill命令所在的d_stop函数进行set–x跟踪:
真相大白,推测在运维过程中,发生了误操作,导致将/usr/bin目录下的ls–l结果输出到了/usr/bin/kill文件中。
结果所有的符号连接文件因为含有”->”,而导致了对其源文件的清空操作。
最终造成了本次开机后无法telnet故障,以及一系列关键系统文件被清空。
说明:
此处为了简化命令输出,对出错的/usr/bin/kill进行了删减,只保留了可以说明问题的一行记录。
问题总结
由于kill命令的特殊性,通常的shell终端中,kill命令为shell内嵌,只要不使用绝对路径执行kill(即/usr/bin/kill),就不会使用到操作系统/usr/bin/kill命令,也不会触发/usr/bin/kill被误覆盖导致的问题。
从实际启动过程看,只有cimserver启动时中显式调用了/usr/bin/kill,因此触发了关键文件误覆盖故障。
但整个问题其实与cimserver无关,只是碰巧由cimserver触发。
而因为触发点恰好在系统启动过程中(初始化/etc/inittab注册项时),问题定位的复杂度略高。
定位过程中使用的audit方法,以及probevue跟踪脚本,都可以在类似问题定位中复用。
稍作修改,比如修改probevue脚本为监控unlink系统调用,也可以用来跟踪文件误删除等问题(audit方案可以直接用于监控文件误删除问题)。
环境恢复
从正常系统拷贝/usr/bin/kill命令,以及被清空的/usr/sbin/tsm文件(以及所有被重定向置空的文件)。
停止audit:
杀掉probe脚本。
从/etc/inittab中删除probe和audit对应的项目,然后重启机器。
特别说明
为维护客户隐私,所有相关数据均采用测试环境重现后抓取,请勿对号入座,谢谢!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- AIX 关键系统文件被清空问题定位过程全记录 关键 系统 文件 被清空 问题 定位 过程 全记录