关于一堆可疑的SNMP包

很久以前,我系的CRF(管理计算机资源的)来找过我,说我机子被黑了。我观察之后没啥症状,就问他们为啥那么说。
他们拿出来一个单子,说你机子往外发可疑的包,只有被黑了才发这种包。
我看了一眼,貌似我的机子在广播SNMP包。我觉得这事情也不是那么奇怪,毕竟一堆程序依赖snmp库,但是他们觉得有问题。
于是我在防火墙加了个规则,说如果有这种包就记录一下并且扔掉。其他还干了很多事情,例如换私钥之类,总之很麻烦。之后,他们就不来找我了……
系统里的确偶尔会记录下这种包的发送记录。那时候尝试看了一眼,没看出为啥,也就没有管。

过了很久之后,一天我看着这些记录,觉得很烦躁,想着干脆研究清楚为啥会发这些破包。
首先,那些个记录里记录了发包者的UID。在我的机子上,记录的UID是colord的UID。
colord是啥呢?可以参见http://www.freedesktop.org/software/colord/intro.html。基本上是个管理色彩配置的东西,如果你不是特别关心你颜色显示得是否准确,其实有没有都无所谓。
colord发SNMP包还是很难让人理解。ldd看一眼,发现colord并没有链接libnetsnmp,net-snmp也不是他的依赖。
观察一下colord的依赖,其他貌似都挺无辜,但是有个可选依赖是sane。我机子上恰好也装了sane。
sane是啥呢?参见http://www.sane-project.org/,Scanner Access Now Easy(这Now是硬插进去的吧!),是个管扫描仪的东西。
sane倒是依赖net-snmp,所以多半是它干的好事。

之后把colord和sane代码扒下来看一眼,大概知道是怎么回事情了。
说colord有个sane插件,嘛大概扫描仪也需要色彩配置。这个插件会启动一个叫colord-sane的程序,这个程序链接到了libsane。sane有个插件叫magicolor,管理Konika Minolta的一个系列的扫描仪。
colord因为某些原因要更新设备列表,于是调进那个插件。插件启动colord-sane,导致sane也让他的插件们更新设备列表。那个magicolor系列扫描仪估计比较高级,能够联网。magicolor插件更新设备列表就去群发SNMP包,在本地网上找这个扫描仪。这个包被CRF看见了……
其实也怪那个SNMP请求范围太广。他发的SNMP包基本上就是让本地所有的SNMP设备向他报告自己是啥设备,有啥功能之类。这看上去当然挺危险……

最后说这个过程是怎么触发的。在开始打记录之后,我发现当我插拔手机/平板的时候,那个记录会一起出现。这种事情很容易联想到UDEV,sane和colord其实都装了UDEV规则,而这里引起问题的是colord的规则。那个规则说,只要USB设备插入/拔出,并且有gphoto支持,就给colord发个通知。Android的手机/平板当然在这个范围,于是引发了一系列事件,最后SNMP包就发出去了……

总体现象是你插拔手机会发SNMP包,谁知道里面有这么一个过程……
如果有个工具,能够告诉他触发条件和结果,问他中间的因果关系,倒是会方便不少。好像也不是搞不出来,不过貌似没啥学术价值……

挂了一块希捷移动硬盘

这块希捷硬盘是我台机上硬盘里最年轻的一块,居然就挂了……
Power On Hours也就刚过一年,买来还不到两年。希捷最近真是不行……

挂掉的是Seagate Expansion 3TB,里面的硬盘是希捷酷鱼7200.12(ST3000DM001)。
花了不少功夫拆开来,里面就是一块硬盘插在一个小电路板上。
貌似这个移动硬盘散热很糟糕,最高温度超过60,平时跑着也有55+。看看其他硬盘也就40度左右的温度,可能散热不好是挂掉原因之一。
整个硬盘盒上部完全密封,就底下有些眼,难怪散热不好……

做了个盘面扫描,碰到坏块很慢所以就做了一点。貌似挺有规律,基本上是坏掉2块,好一块,坏掉2块,好7-8块,然后重复。每块大小大约是286M。第一个坏块是第三块。
这些坏掉的部分估计物理上有啥共同的地方,具体也不清楚。说这个硬盘是三碟装,没看出有啥关系……
恢复数据挺麻烦的,稍微大点的文件就可能读不出来,只好跳过去。幸好这盘才用了500G,多数也不是啥重要的数据,所以损失不大……

台机上另外的本科买的WD Elements 1TB(15862小时)一点问题也没有,开机时间都快赶上这货两倍了。
另外台机内部的其他硬盘,包括古老的西数硬盘(120G,20377小时),希捷硬盘(500G,17794小时)都没有问题。
难道传言最近希捷不行了是真的…… 以后还是避开希捷买西数算了……

胡写脚本于是又bug了

说写一个monitor进程是否在跑的脚本,本来用的是ps ax | grep $sig | grep -v grep。
这个脚本写的时候好好的,用xxx.sh &跑也没问题。但是只要一关那个term分页,就挂了……

把ps ax的内容dump出来看,居然右边被切掉了……
那当然是宽度问题,改成ps axww就好了。想想看见过别人脚本里的ps axww,原来是这个道理……

想是有term分页的时候,输出检测用的是term宽度,所以没有被切。分页干掉之后输出宽度没法检测了,于是用了个默认值,于是就被切掉了…… 加上ww之后想多宽就多宽,就不会被切了……
胡写还真是能写出奇怪的bug…… 而且要不是这次$sig出现在比较靠右的位置还发现不了…… 说不定哪天换sig就莫名其妙不工作了……

ps. 其实用pgrep -f就完了么……