选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
之前用的邮件系统是基于 postfix、Cyrus IMAPd、amavisd-new等软件在2006年搭建的，跑了5年多，作为不折腾会死星人，对这套系统一直有相当多的不满意，举例来说：
Cyrus IMAPd支持 foo+box@domain.tld，也就是如果foo用户的邮箱中存在’box’这个子目录时直接投递到那个子目录很有问题；
Cyrus IMAPd采用的是自己的邮箱格式。支持这种格式的只此一家；我虽然不是Maildir的fans，但Maildir是一种事实标准，而且处理起来工具也要多的多；
amavisd-new和postfix的集成原先是采取双MTA的方式进行的，这种做法会导致至少多一倍的磁盘I/O（好处是在系统过载的时候不影响进信），并且由于多了一个环节有可能引入更多的不确定性【1】；
当然其实更重要的还有：
为了便于备份而采用的 ZFS 快照和远程复制机制，以及，
原先的服务器和我的物理距离太远，为了访问速度必须要做迁移。
新的方案大致如下，有时间慢慢整理howto出来：
现在还差一个队列前会话期间反垃圾的策略服务。之前采用的是 postfix-gps，找了一圈没有找到一个让人感觉靠谱的，所以准备找时间自己拿 twisted 重新写一个然后开源放出来。
【1】这个说法可能是有争议的。我认为以milter方式集成的好处是对方看到的是超时而不是已经将邮件收下，因此出现问题的机会要少一些。
Read more...很久以前我曾经建议过别人使用足够长的一大串英文单词作为密码，现时这样做已经完全不能保障安全了。
Colin Percival最近在 一篇文章 中提到了这样的数据：使用价值 $10k 的 GPU 破解使用MD5的34位英文密码（例如"You will never guess this password"）所需要的时间仅为两小时（如果使用专用的硬件，以$1M投资的ASIC可以在一秒之内完成破解）。如果密码长度不够长的话，采用了特殊符号的帮助也不大。足够复杂的8位密码，例如"6,uh3y[a"使用 $10k 的 GPU 破解只需10个小时。
因此，我认为现时应采取的密码策略应该是：
确保每个网站都使用不同的随机密码，这些密码的内容应包括大小写字母、数字__和__特殊符号，且密码不应少于12位。
确保每个网站都是用不同的随机密码尤其重要：因为你可能不知道哪个网站什么时候被人骇掉，即使其密码进行过hash处理，如果很短、不包括大小写字母/数字/特殊符号的，或者选用了不适当的hash算法（如MD5），仍然是会被穷举出来的。
我自己最近十年使用的密码生成器可以在 这里 访问。
Read more...以前一直没注意过这个问题，今天在邮件列表看到 Matthew Flemming 发的邮件才知道实际上 C 标准并不保证 sizeof(void *) == sizeof(int(*)(void))。不过，几乎所有的现代系统上这个等式都是成立的。
例外的情况是类似 x86 实模式这类分段的内存模型中，函数指针可能默认是个far pointer（不过话说，现在还有人为这样的硬件写C吗？）；另外据说IA64上也不一样，不过没有办法证实或证伪。
Read more...这次休假前头一天晚上收到了 ISC 发来的安全公告 CVE-2011-1910。我起草完 FreeBSD 安全公告 FreeBSD-SA-11:02.bind.asc 之后就去休假了，这里补上这个漏洞的说明。
无论你是否使用 DNSsec，只要用 BIND 9.x 来做 DNS 缓存解析服务（而不仅仅做Authoritive DNS服务），就有可能受到这个漏洞的影响。而攻击的方法也相当简单，攻击者只要建立一个 DNS 域，令在回应域名不存在的同时发回一个大的 RRSIG RRset，即可触发 BIND 的某处断言令其退出。
由于目前坊间已经出现了针对这一问题的攻击，FreeBSD 安全团队在收到 ISC 安全公告之后立即发布了对应的安全公告和二进制更新。使用受支持的安全分支的用户可直接用 freebsd-update 获得更新，安装之后使用 /etc/rc.d/named restart 重启服务即可。
Read more...APC BE550G 是一种廉价的UPS，支持以 USB 线通知被保护的系统或查询状态。
在 FreeBSD 上可以用 apcupsd 来配合 USB 通知使用。
去年大河发生过一次停电事故，所以买了一个 UPS 来配合自己的机器；今天大河又来了一次大约90分钟的停电，算是完成了对 UPS 的完整测试。
UPSCABLE usb
UPSTYPE usb
DEVICE
POLLTIME 60
LOCKFILE /var/spool/lock
SCRIPTDIR /usr/local/etc/apcupsd
PWRFAILDIR /var/run
NOLOGINDIR /var/run
ONBATTERYDELAY 6
BATTERYLEVEL 8
MINUTES 3
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0
NETSERVER on
NISIP 127.0.0.1
NISPORT 3551
EVENTSFILE /var/log/apcupsd.events
EVENTSFILEMAX 1024
UPSCLASS standalone
UPSMODE disable
STATTIME 0
STATFILE /var/log/apcupsd.status
LOGSTATS off
DATATIME 0
FACILITY DAEMON
SENSITIVITY H
WAKEUP 60
LOWBATT 02
SELFTEST 336
上述设置中比较重要的：
其他一些数据：
最近忙得要死，今天看到 谷奥 的 消息 说 Google Analytics 可以抓访问时的速度数据了，于是部署了一下。
另外，十年以后突然跟你要大学专业课介绍的国家真的伤不起。
Read more...今天收到一封奇怪的钓鱼信，它声称来自 Domain Registration of America，准确地说出了我的名字和拥有的域名中的两个，并建议我立即把域名转移到他们那里。
开价是……一年$30。
用这么坑爹的价钱是想提醒我这是钓鱼邮件吗？
当然，这事其实还没完。我仔细看了一下这封信，发现后面的小字写的还是很详细的，或者说，人家只是一个proposal，姜太公钓鱼愿者上钩的意思。这个事情奇怪的地方在于，邮寄的成本并不太便宜，算上人工的话，如果是美国工人做这个事情的话，算上邮费，一封信怎么也得有$1才能邮寄到我这里；另一方面，减去域名注册的成本，两个域名续费一年的利润大概是$45，也就是说，需要至少1/45的人上当才能把成本打平。
把钓鱼信邮寄到硅谷是怎样的国际主义精神啊，不理解，谁能帮忙理解一下这种商业模式？
Read more...住在西海岸的同学可以在 West Coast and Alaska Tsunami Warning Center 这里找到相关的信息，以及对这次本州地震的海啸模拟。
从美国地震局网站上 看，余震仍然在继续中。
另外，今年的 AsiaBSDCon 仍会如期举行。
Read more...最近做一个存储的项目，顺手在家测试了一下实际数据的dedup。操作系统是 FreeBSD 8.2 配合一组总共大约3MB的patch来跑ZFS v28，硬件是 Atom D510 配合 4G 内存。
初步测试的主要目的是取得一些感性认识而不是进行定量分析。
首先是支持的算法。ZFS默认使用的是SHA256，不做校验；刚开始测试的时候不懂事，开了校验，发现速度慢的没法忍受（需要继续研究到底是为什么，个人评估应该是因为校验本身触发的读操作导致），关闭校验则会好很多。
ZFS提供了一个事先评估dedup效果的方法，使用zdb -S pool名字来看。
为了避免过分dedup导致数据存储可靠性方面的问题（例如，有某块数据实际上在pool中有200个引用，但实际上只有一份，那么一旦那个数据块出问题的话就会导致200份都出问题），可以设置 dedupditto。
在事后可以用zdb -DD pool名字来查看实际的效果。
下面是某pool中实际的效果：
DDT-sha256-zap-duplicate: 1034868 entries, size 440 on disk, 142 in core
DDT-sha256-zap-unique: 3745115 entries, size 461 on disk, 148 in core
DDT histogram (aggregated over all DDTs):
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 3.57M 151G 117G 123G 3.57M 151G 117G 123G
2 908K 27.5G 22.7G 24.3G 1.91M 63.0G 52.6G 56.1G
4 57.1K 1.15G 862M 983M 269K 5.37G 3.84G 4.40G
8 40.5K 436M 228M 320M 428K 4.75G 2.47G 3.43G
16 4.73K 36.2M 20.6M 31.3M 89.2K 687M 387M 591M
32 295 2.37M 901K 1.66M 12.1K 99.1M 36.3M 69.5M
64 100 708K 224K 524K 8.52K 58.6M 19.0M 44.7M
128 20 10K 10K 80K 3.46K 1.73M 1.73M 13.8M
256 13 76K 39.5K 76K 4.77K 26.2M 13.5M 27.1M
512 11 18.5K 13K 48K 8.05K 12.5M 8.90M 34.9M
1K 8 4K 4K 32K 11.8K 5.91M 5.91M 47.3M
2K 6 20K 5.50K 24K 14.1K 44.8M 12.6M 56.6M
4K 3 1.50K 1.50K 12K 15.2K 7.59M 7.59M 60.7M
8K 1 512 512 4K 16.0K 7.98M 7.98M 63.8M
16K 1 512 512 4K 30.9K 15.4M 15.4M 124M
64K 1 512 512 4K 83.5K 41.8M 41.8M 334M
Total 4.56M 180G 141G 149G 6.45M 225G 176G 188G
dedup = 1.27, compress = 1.28, copies = 1.07, dedup * compress / copies = 1.52
过几天找个Fusion-IO来在iSCSI上实际跑些VM试试看。
Read more...今天 Colin 在blog上介绍说 他刚刚修正了一个 TarSnap 重大安全漏洞。简单地说，用来加密密钥文件的AES-CTR实现时，计数器没有增加（正确的实现中计数器应该每次递增），导致在已知明文时能够通过加密块推算出一块数据使用的密钥，并用它来解密余下的数据。
这个漏洞会导致通过某种渠道获得使用受影响的版本（从1.0.22到1.0.27，包含首尾）上传的加密数据的人，在知道其对应明文的情况下能够解密这些数据。
这是tarsnap目前首次发现安全方面的问题，它也再次说明了对于加密代码的安全审计是非常必要的。
PS 漏洞发现者得到了Colin之前承诺的奖金。欢迎大家继续捉虫。
Read more...