Streaming Music的方法

最近之前买的虾米会员过期了,忘了续了…… 于是看了眼目前可用的几种方案…… 虾米 买了会员国外才能用,不过会员很便宜,有不靠谱的自己写的客户端,速度有时候不太行。 也有些歌下架了。会员一个月可以下100首。好像没有无损来着。 网易 一样买了会员才能用。只有Linux客户端,BSD下面只能跑网页版,Wine出来的有点问题。速度也是有时候不行。 有些歌下架了,其中某些可以靠黑科技下下来,某些就不行。买了会员一个月可以下300首。号称很多歌有无损。 Spotify 不付钱有广告,有不少想听的东西找不到。好像有Linux客户端来着,据说Wine出来的客户端也还行,当然也有网页版。速度没有问题。 Google Music 不付钱没法搜,只有电台。很多歌没有。没有PC客户端只有网页版,网页版还有傻逼DRM…… Apple Music 反正也要付钱来着?一样也是缺东西,PC客户端就不要想了……   所以总的来说都很糟糕。其他还有QQ音乐啦酷狗啦酷我啦之类的,酷我这种好像就没有版权下架的情况…… 目前暂时用的是曲线救国的路径,先从网易那边下下来,然后利用Google提供的云存储传上去,再用手机streaming…… 但是Google没有客户端,网页依赖DRM,所以BSD上还是没法用…… 考虑把Google提供的云存储换成自己的云存储,自己架一个服务器然后用符合标准的客户端听…… 不过VPS肯定不行,存储太小,只能用NAS或者在自己家里弄个服务器再搞个动态域名之类的了……

关于监控系统

事情的起因是实验室的一台服务器重启之后起不来了,看了一下发现有快硬盘坏了。 顺便看了一下,另一块也差不多了。 按理说这种事情都有监控脚本盯着,本不该发生的。 结果跑去监控的机子上一看,原来那个机子的邮件系统坏了6个月了…… 邮件系统坏掉的原因是Arch某次升级的时候貌似postfix要手动干点事情,否则就起不来。 所以光有监控系统是不够的,还需要 a. 监控监控系统的系统,这样下去貌似没完…… b. 在正常工作的时候也报告一把,这样挂了就能知道。 但是天天收到正常报告也会烦,如果都从收件箱过滤掉,那就没意义了…… 所以好像也没啥好办法…… PS. 邮件队列里堆了94万封邮件…… 上次跑实验跑出来的,幸好没发出去……

又换了一家VPS提供商……

一开始是PhotonVPS,后来是linode,接着Amazon EC2,现在跑到了DigitalOcean…… 换linode因为PhotonVPS时常网络不好偶尔还重启,换EC2因为linode只有PV的虚拟机而FreeBSD一直不支持64位的PV,换DigitalOcean因为它终于支持FreeBSD了并且便宜性能好还有GitHub的100刀优惠…… 搬家倒是挺方便,把数据库、网页、配置打包拷过去就完了…… 这回能呆久一些就好了…… 毕竟搬家还是要费一些功夫的……

关于一堆可疑的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小时)都没有问题。 难道传言最近希捷不行了是真的…… 以后还是避开希捷买西数算了……