delphij's Chaos
选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
Posts
OpenLDAP断电导致故障修复一例
今天帮陈总研究一个奇怪的问题的时候误操作导致机器停止ssh响应，遂请机房重启。由于机房做的是power cycle，导致部分数据丢失。先前在配置OpenLDAP时，忘记在其中配置checkpoint，另外也没有对这台机器的LDAP进行备份，因此只好尝试从现有的数据库中恢复。冗余不做，日子甭过；备份不做，十恶不赦！
记录一下修复过程。
第一件事是把出问题的数据库做一份备份：rsync -av /var/db/openldap-data/ /var/db/openldap-data.old/
接着尝试slapcat。出现下面的错误：
bdb(dc=********.com): file id2entry.bdb has LSN 1/1476384, past end of log at 1/374639 bdb(dc=********.com): Commonly caused by moving a database from one database environment bdb(dc=********.com): to another without clearing the database LSNs, or by removing all of bdb(dc=********.com): the log files from a database environment bdb(dc=********.com): /var/db/openldap-data/id2entry.bdb: unexpected file type or format bdb_db_open: database "dc=********.com": db_open(/var/db/openldap-data/id2entry.bdb) failed: Invalid argument (22).尝试使用BerkeleyDB的修复工具修复：
# db_recover-4.6 -vvf Finding last valid log LSN: file: 1 offset 374639 recovery 0% completeRecovery starting from [1][374527] recovery 67% completeRecovery complete at Tue Jul 13 16:41:59 2010 Maximum transaction ID 800000c0 Recovery checkpoint [1][374639]slapcat发现问题依旧。搜索Google发现答案基本上都是从备份中恢复，看了一下Oracle的网站，关于这类问题也没有很好的办法。尝试将bdb文件dump出来再load回去：
db_recover-4.6 -vvf db_dump-4.6 id2entry.bdb > /tmp/id2entry.dump rm id2entry.bdb db_load-4.6 id2entry.bdb < ~/id2entry.dump db_recover-4.6 -vvf再次slapcat，发现对另一文件报错，用类似的方法修补之后，slapcat成功。
将slapcat的输出导出到一个文件中： slapcat > /tmp/my.ldif
然后，删除OpenLDAP数据目录：rm /var/db/openldap-data/_* /var/db/openldap-data/
\[a-z\]*
最后，重新使用导出的ldif文件恢复：slapadd -l /tmp/my.ldif。
至此，恢复完成。
Read more...FreeBSD 1U服务器参考配置
此配置确认可配合 FreeBSD/amd64 8.1-RELEASE 使用。实际运行时功率少于100W（110V电的情况下电流小于0.9A），供参考。
主板：Supermicro X8STi
机箱（含电源）：SC813MTQ-350CB
CPU：Xeon L5630
内存：Apacer 4GB ECC Unbuffered * 6
硬盘：Seagate ST31500541AS * 4说明：
此主板采用Intel X58芯片组（ICH10R，可使用 ichwd 配合 watchdogd 来启用OS监控），所选硬件支持AHCI故应在BIOS中配置为使用AHCI。L5630为低功耗版本，此主板兼容的其他CPU不会影响兼容性。此主板包含的网卡为82547L。
注意 X8STi系列主板早期的PCB与Xeon 5600系列CPU存在兼容性问题。Xeon 5600系列CPU需要使用Rev 2.0的PCB。此问题的现象是重启时过热LED闪烁且停止响应。
FreeBSD 8.1-RELEASE默认启用了MCA。如果对功耗有进一步的要求，并且机器负载不太重，可根据需要配置并运行powerd。powerd会将电源识别为"unknown"，并选择HIADAPTIVE作为profile，即在CPU占用超过running mark/2时—-默认running mark为75%，若任意CPU占用超过95%或running mark时将CPU频率调高4倍，反之令负载趋近于running mark/2。当负载不足idle mark/2时—-默认idle mark为50%，按1/32的当前CPU频率为步长降频。
目前Intel尚未发布针对L5630的新版microcode。
Read more...测试SSL
周末抽时间对网站做了一些调整。主要是把网站迁移到nginx上，不过遇到一些问题。Movable Type以FCGI::Spawn运行的时候，有时会反复出现先前的页面（例如，在mt.cgi上登录时，在提交登录之后仍会出现登录界面，而不是正常完成登录）。用ktrace看了一下FastCGI进程，结果发现之前看到的资料里面有相当多的小问题，但这个问题最终没有解决，暂时起了一个Apache来以cgi方式处理来绕过问题了。
意外的收获是，过程中发现nginx和firefox bug各一枚。
Read more...如何：为小于 /24 的 IPv4 网段实现反解析
以前一直以为这事必须由ISP以个案的方式去做，最近跟北美一家ISP接触加上查阅资料以后发现其实早就有办法，原理和普通的域名解析类似，也是可以使用delegate和glue去把解析权移交给持有IP的客户，从而减少ISP自己的负担，在这里记一笔。
为小于/24的网段实现解析主要是针对子网掩码长度为30-25这个范围。等于或大于/24的网段必须拆成/24的网段来解析，这个使用传统的DNS的做法就可以了；小于/30的网络因为地址太少，将其解析权代理出去的意义不太大。
正常的/24网段反解析最终是通过PTR记录给出的。例如，如果我们想要得到IPv4地址 1.2.3.4 的反解析结果，我们将向 DNS 解析器请求 4.3.2.1.in-addr.arpa. 的 PTR 记录。这样，系统会向上逐步查找3.2.1.in-addr.arpa.、2.1.in-addr.arpa.、1.in-addr.arpa.、in-addr.arpa.、arpa.各自的NS记录（如果本地没有缓存的话），并向其查询下一级的记录。
为了能够允许向下授权，RFC 2317 指出，我们可以进一步在最后一级，也就是 /24 的地址段的域中增加下一级的 NS glue。例如，对于从144开始的/28网段，可以将其命名为 144/28；另一方面，原本直接解析出 PTR 记录的地址，例如 1.2.3.144对应的 144.3.2.1.in-addr.arpa，则解析到一个CNAME记录，例如 144.144/28.3.2.1.in-addr.arpa。
受信域比较常用的命名规则主要有山寨的DeGroot法（使用subnet144.3.2.1.in-addr.arpa这样的名字）、RFC 2317 所推荐的起止地址法（144-159.3.2.1.in-addr.arpa这样的名字）以及 RFC 4138 所推荐的子网法（144-28.3.2.1.in-addr.arpa这样的名字）等。不过，在实际应用中，也可以使用类似的规则去完成同样的目的。
Read more...FAST 2010第二天
今天的话题都是我比较感兴趣的。
开场的Keynote是eBay的Oliver Ratzesberger的 Enterprise Analytics on Demand。eBay每天的数据增量是50TB，而每天的数据处理量是50PB。这个presentation讲了相当多的规划方面的细节。
第一篇 DFS: A File System for Virtualized Flash Storage 介绍的是一个把卷管理（并不完全是：包含了Flash的wear leveling）和文件系统集成在一起的设计。FusionIO公司提供了一种直接在PCIe接口上插的存储设备。类似这样的设计，感觉是未来Flash文件系统必须要走的一条路。
第二篇 Extending SSD Lifetimes with Disk-Based Write Caches 是一个很有意思的设计：现时磁盘的反复擦写寿命要远好于Flash，因此，在磁盘上做一个顺序写入的日志，然后再择机将数据擦写回Flash。不过这篇论文讨论的具体方案还有一定的改进余地。
第三篇 Write Endurance in Flash Drives: Measurements and Analysis 是关于 Flash 寿命的衡量方法。
Read more...FAST 2010第一天
今天去参加了在San Jose举行的 FAST ‘10 第一天的 Tech Session，FAST是 USENIX 主办的关于文件和存储技术的学术会议。记上几笔。
开场的Keynote其实讲的还算精彩，不过感觉跟会议本身关系不大（讲的主要是发展中国家的手机等设备的发展），就不介绍了。
Build a Better File System and the World Will Beat a Path to Your Door部分。第一个是本次的获奖论文 quFiles: The Right File at the Right Time，具体来说是实现了同一份data（文件）的不同view（例如，将其表现成不同分辨率、码流等）的一种通用的存取方法。个人对Semantic File System持保留态度，不过这个talk还是可以帮助拓宽一下思路。
第二篇是介绍在 WAFL 类型的文件系统（具体举例是 btrfs） 中实现倒排索引的 Tracking Back References in a Write-Anywhere File System。具体来说，是在 inode -> 块这样的单向关系基础上，增加了块->inode（包括inode版本、回收时间等）的倒排索引。paper值得看但是性能比较做的稍微有些瑕疵（用做B-Tree的时间去比较在FS中查询的时间，而没有比较建立倒排索引之后更新与在block中插入信息所引起的开销，以及两者对应的查询时间）。
第三篇指出了内存故障可能导致的问题，指出 ZFS 的 end-to-end 检查只能检测出磁盘介质或控制器偶然故障引起的问题，而系统主存中存在的问题则无法发现并可能导致数据损坏甚至系统崩溃，并提出了在 ext2 FS 中增加运行时checksum检查的方案。这篇的试验方法和结论受到了很多人的质疑。
午饭时间。
Read more...车棚该漆什么颜色？
很多争论其实是源于沟通和理解。人们的理解能力往往是有限的，这些限制很可能来自于不同的教育背景、知识面等等，因此，为了更好地理解对方，人们往往习惯于使用 自己熟悉的 知识去设法理解对方所说的。
这带来的一个现象，在技术人员之间的讨论中，就会是这样：例如，讨论应该怎么造一枚火箭，往往不会有人去随便做评论，因为他们很清楚自己并不是这个专业的人，而这件事明显需要许多非常专业的知识；而如果讨论火箭发射基地的车棚应该漆成什么颜色，则几乎每一个人都会去发表自己的意见，因为车棚的颜色是什么样子，在多数人看来往往没有造火箭那么重要，并且，似乎每个人都能够胜任这样的决策。
将讨论如何造火箭的话题，阴差阳错地变成一群人争论火箭发射场外面的车棚应该漆成什么颜色，就是我们所说的 Bikeshed 现象。
我在这一天时间里遇到了两次这种问题。第一次是我自己把冯牛说的税的算法问题想错了，第二次是我的关于什么时候该用线程的问题被另一个人活活 扯成了 线程 vs 进程的开销问题。
解决 bikeshed 是需要时间的。不过，每一个参与讨论的人，其实都可以尝试使用一些方法来减少这种情况的发生。例如：
头脑空白原则：如果对方讨论的是一个你认为自己很熟悉的话题，不要首先根据自己的理解去下结论，而要先看清楚对方到底在说什么。许多时候，我们自己的知识背景会限制我们能够看到的问题的范围，很可能对方想要讨论的并不是这些东西。
在发现争论持续了很长时间，双方各执己见时，暂时停止讨论，而不是继续论证自己的观点。一个观点的对错取决于观点本身，而不是争论双方所说的话。
避免情绪化的语言—-那不会增加你的说法的说服力。
Read more...安全：该做什么和不该做什么
很多事情都有Do’s and Don’ts，这里试着整理一下与安全有关的。
本文版权所有 © 2010 Xin LI delphij@FreeBSD.org 保留所有权利；非商业转载请注明出处 http://blog.delphij.net/， 谢绝商业转载。
安全不能建立在"别人不知道"的基础上
“别人不知道"是一种非常常见的安全 假象，举例来说，一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等，都属于这一类。
将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像，这会直接导致与系统交互的人放松警惕；其次，这样的设计往往留有"后门”，甚至是设计者不知道的后门（因为往往他们并不对这类设计进行充分的、专业的审计），容易被攻击者利用；最后，这种做法存在第三方泄密问题，即，使用这种系统的人，需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。
延缓攻击的手段不能用来阻挡攻击
有许多延缓攻击的手段，例如改变服务的端口（比较常见的如将 ssh 改为 tcp/22 以外的端口），或禁止服务程序显示自己的版本等等，或仅仅简单地启用防火墙，这些手段起到的作用只是延缓攻击，而不应作为一种安全屏障。对于多层次式的安全设计来说，采取这些措施有助于提高检测到入侵的机会，但是它们本身并不会提高安全性。
与前一种情况类似，这种做法也只是让管理员放松警惕。例如以 ssh 为例，有人认为将端口改为一个非知名端口可以避免相关的攻击，但事实是，攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中，包括简单的 port knocking 一类的保护手法，都可以使用类似分组重放这样的方法来逐步攻破。
采用层次式的安全设计
所谓层次式的安全设计，说的是在一套安全系统中包含不同层次的、存在层次式监控关系的安全结构。例如，将本地包含执行文件的那些文件系统通过一定的方式导出给监控网段的机器，就可以让那些机器在攻击者不知情，或至少不太容易注意到的情况下对入侵进行检测；通过将一些重要日志发到以不同的访问控制机制，甚至不同网络协议的记录设备上，则可以有效地检测入侵者的入侵行为，并为日后的分析留下更多的有用信息。
层次式安全在现实中也有应用。例如产品的质检，除了制造商自己进行的质量控制之外，有时分销商或政府也会进行一些抽样的检查。我们注意到，这些设计中的一个重要的特点是在不同的系统中使用不同的访问控制逻辑。例如，日志服务器必须从特定的客户端，甚至只能从某些隔离的内网登录。此时，延缓攻击的手段可以作为它的一项辅助设施，即其目的并不是阻止攻击，而是吸引攻击者在攻击目标上花费更多的时间，从而帮助入侵检测机制更容易地检测这些攻击。
不要轻信任何东西，包括X.509证书
安全系统的设计者必须对安全有全面的理解和认知。有一句很著名的话叫做 In God we trust, all others must submit an X.509 Certificate，需要注意的是，这里说的是 must submit，并没有说 submit 了就可以 trust 了。
和前面所说的层次式安全设计类似，我们的一个基本假定应该是，一个安全系统中的任何参与者，无论是用户还是计算机或程序，都是可能存在弱点的。安全系统，或用户，都不应轻信任何东西，例如，在特权隔离 (Privilege Separation) 这样一种设计中，特权进程除了完成那个非特权的子进程的请求之外，还有一个任务是维护一个"理性状态机"（Sanity DFA），这个状态机的作用是检测非特权进程的异常状况，如果发生这样的情况，则特权进程有拒绝提供服务，并杀掉非特权进程的责任。作为用户，对于系统给出的响应，除了验证对方的证书之外，也应有常识性的了解和适当的判断。
Read more...李献计历险记
法师推荐的一个 短片，有关好爱情和不朽，我们还有很多不知道的。
Read more...纪念消失的Sun
欧盟日前正式无条件批准了Oracle收购Sun的交易，至此，有着28年历史（1982 - 2010）的Sun公司作为独立公司的历史正式宣告终结，今天，Sun的网站已经变成了301 http://www.oracle.com/。
“For 28 years, Sun has stood for courage, innovation, a willingness to blaze trails, to envision and engineer the future.”
Read more...