2009 年 7 月 25 日晚 20 点左右,我正要打开新网代理商平台准备注册几个域名,突然 NOD32 跳出来报警。我觉得蹊跷,直接打开新网首页,发现 NOD32 依旧提示木马。如下图所示,点击小图可以欣赏到高清、无码、激情的大图。

分析首页 HTML 代码可以看到是新网公告这个二级域名下被挂了马:

- 阅读剩余部分 -

最近学到这种提纲式的文章写作方式,顺便记录最近发生的琐事几则。

1、强大的 Google 企业套件

公司邮箱使用 Google 企业套件,有一天我登录后发现这样一幕:

2、新域名后缀 .tel 开始宣传

众多 .tel 的代理商已经开始宣传工作了,这是一个有意思的视频小片段:

感兴趣的朋友可以在这里下载到这个片段。

3、新网 URL 转发服务器持续癫痫

由于受到政策面收缩的影响,新网提供 URL 转发服务的服务器最近不断地出问题。作为新网代理商,我名下包括 xuchao.org 在内的众多域名受到影响。新网方面答复说 URL 转发中不和谐的链接太多,导致服务器 IP 被查封,更换了 N 个都不行。现场截图:

- 阅读剩余部分 -

上周单位有个同事生日,不仅收到了鲜花、蛋糕,还有一些有意思的小玩意。说来也巧,这个小妹妹的生日也恰好是 6 月 26 日。更为神奇的是年月日一个数字都不差,这让我多少有点吃惊,在现实中遇见同年同月同日生毕竟是稀少。

晚上请我们吃饭,在去往酒店的路上,我又一次把手机落在出租车上。这是我第二次在天津将手机落在出租车上了,也是第二次有惊无险地拿回了手机。天津人大都友好、热情,所以出租车司机也很少例外。席间心有余悸,于是我又拿出相机来练手了——虽说到天津这么久以来都没怎么拍过,技术不但没有进步反而倒退得厉害。

一段看图不说话时间。

- 阅读剩余部分 -

最近准备重新回归运维,很好。前一阵子易先生打电话说服务器上 session 失效,他在公司又不方便 ssh 上去看。于是我为了自己的博客勉为其难上去看了一下,结果发现 /var 下面居然爆满溢出了。

www# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    989M     59M    851M     7%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ad0s1d    989M    2.2M    908M     0%    /tmp
/dev/ad0s1e     19G    1.6G     16G     9%    /usr
/dev/ad0s1f    989M    910M   -384K   100%    /var
/dev/ad0s1g    124G    1.7G    113G     2%    /www
/dev/ad2s1d    9.7G    1.4G    7.5G    16%    /database
/dev/ad2s1e    139G     42G     85G    33%    /backup
在啧啧称赞之外,准备找出在 /var 下面所有大于 1MB 的文件:

www# find /var -xdev -size +2048 -ls| sort -r +6 这个搜索结果是相当的恐怖,可以用眼花缭乱来形容当时的屏幕滚动。强行中止后发现绝大部分文件都集中在 /var/spool/clientmqueue 这个目录下面。那么这到底是个什么目录呢?

原来,当使用 sendmail 发邮件,或者系统默认要发邮件(譬如 crontab)的时候,首先会把邮件复制到这个目录里,然后等待 MTA 处理。MTA 做的事情就是把这个目录中的邮件转移到 /var/spool/mqueue,然后再发往目的地。

在 /var/spool/clientmqueue 下产生大量文件的情况,通常是因为没有合适的 MTA 来发送邮件,于是都堆积在这里了。假如这里的邮件并不是你需要的,比如由 crontab 产生的信,你可以简单地删除。

还有一种情况,当这个目录下面的文件数量足够多的时候,直接 rm -f * 的话会被提示 Argument list too long。没事,下面两个命令会帮助你搞定问题:

find /var/spool/clientmqueue/ -type f –delete 或者

find /var/spool/clientmqueue/ -type f -exec rm {} \+ 不过这两条命令要求 find 的版本较新,如果你的文件版本较低,可尝试:

find /var/spool/clientmqueue/ -type f -exec rm {} \; 到这里,我们已经搞明白 /var 爆满的原因。可以判断的是,易先生服务器的问题就在于系统中有用户启用了 crontab,且 crontab 中执行的程序有输出内容。这些内容会以邮件形式发给 crontab 的用户,而 sendmail 又没有启动,所以就大量产生了这些队列文件。

解决的办法很简单,在 crontab 中命令的最后加上:

>/dev/null 2>&1 这样输出的内容会被直接抛弃,问题就得以解决了。

最后也顺便提一下禁用 sendmail 的事情。本地 MTA 正确工作是 Unix 系统正确工作的一个必要条件。盲目禁止 sendmail 意味着对安全的不关注。如果你不打算启动任何邮件服务,就不应该使用 sendmail_enable="NONE",而应使用 sendmail_enable="NO"。

当然,你也可以考虑用下面的办法来彻底消除其影响,但我认为没什么必要。在 /etc/make.conf 中加入:

NO_SENDMAIL=yes
INSTALL=install
然后 make buildworld installworld,然后用 find 删除 lib、libexec、usr/bin、usr/sbin 等目录中没有被碰过的文件,最后删除 /etc/mail、/etc/rc.d/sendmail 等文件。这个方法来源于网络,没有亲自实验,请谨慎操作。

首先向各位致歉。因为前几天调整了文章分类,所以最近的一些文章又重新被 feed 输出了。因为这次彻底把原来的域名 301 重定向到新域名上面了,于是花了点时间修改了每篇文章中引用的图片地址,但很多站内链接还没来得及修改。

之所以要调整文章分类,我想,最大的原因还是因为自己觉得自己正在慢慢地远离技术道路。这个世界上像明城同学这样执着的人不多了,在支持他的同时我也为自己深深地遗憾了一把。既然不再专业、不再执着,就让我更不专业吧。

上个月说到自己忙碌的状态,一一同学引用了我的部分文字,也谈到了工作状态与效率的问题。这段时间以来我一直在设法调整,我觉得最重要的一点是学会个人时间管理。如果我们不能信任自己的大脑,就把这项工作交给软件来做吧。

首先推荐一个轻量级的约会提醒软件(感谢 FT 的推荐),它可以帮助我们管理行程、约会、备忘等一些容易被忘记和忽略的事情。在这里你可以下载到这个小软件。

然后是一个记录和分析计算机窗口活动的小软件。我记得几年前使用过,后来嫌麻烦就没有坚持。但这个小软件十分不错,可以记录某段时间内计算机的窗口激活情况,帮助我们分析这段时间我们到底把时间花在哪里了,到底有多少时间在工作。同样提供本地下载

最近也用到了一些项目进度管理软件。当然不是像 Project 这样的巨头,我更倾心于轻量的、开源的小软件,比如说这个 GanttProject。放几张截图,有兴趣的朋友可以到这里自行了解详情。

时间线管理:

资源管理:

嗯,很好,又是一个多月没有更新的突然爆发。