选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
关于Scalability这个词的中文译法，目前还没有一个非常确切的定论。一些文献中将其翻译为"可扩充性"，而"扩充"指的主要是Scale up；而在一些实际的用法中，Scalability还包括Scale down，因此，“可伸缩性"也许是比较贴近原文意思的说法。
互联网应用的可扩充性体现在两个方面：其一，是能够对系统容量进行扩充，也就是说，这个系统各个组件能够提供的服务的量，能够在需要的时候予以扩充（特别是通过添加新的服务器等等）。其二，是这种扩充是有效率的扩充，即，增加硬件投入时，其投入与所产生的效果是接近甚至达到成比例增加的。通常说来，“可扩充"同时暗含的需求是用户的使用习惯尽可能保持不变。如果我们关注某一具体的计算节点，可扩充性还应体现于提高计算节点性能，例如增加其CPU数量或内存容量时，能够相应地改善系统的容量或响应时间，等等。
而另一方面，“可缩减性"主要指的则是说一套系统能够运行在尽可能少的软硬件环境之中。对于大型互联网公司而言，这一点可能并不重要，而对初创公司来说这一点则非常重要。
在设计互联网应用的时候，充分地考虑系统的可伸缩性，能够极大地减少日后的维护开销，并帮助决策者对于投资所能获得的回报进行更加精准的估计；另一方面，高可伸缩性的系统往往会具有更好的容灾能力，从而提供更好的用户体验。
与解决很多其他问题类似，改善可伸缩性最常用的方法就是分治法(Divide and Conquer)。分治属于大道理一类，在实践中，我们比较常用的分治策略包括：
今天基本上算是正式把在XO的机器搬空了，8个机架。过两天缓过点劲来再过去整理残留的杂物。累。
Read more...记一下备忘。其实跟单用户模式差不多……
首先用console确认一下是否真的不能登录。
断电，启动交换机，按住面板上的MODE键，SYS指示灯会闪烁，到绿时松手。在console上看，此时会给出switch:提示符。
加载交换机的Flash文件系统：flash_init（这步操作基本上相当于fsck然后mount）。
加载IOS引导加载器：load_helper。（这两步在交换机启动时会在Console上给出说明）。
将Flash上的config.text改名：rename flash:config.text flash:config.bad
引导IOS。由于已经将config.text改名，这一步之后IOS会初始化一个新的配置文件，并且已经将密码去掉：boot
不进入Configure dialog（回答n），enable，然后将配置覆盖回来：rename flash:config.old flash:config.text
设置密码：configure terminal, enable secret, enable password，line console 0，password（如果设置了vty密码，还需要进入对应的vty进行设置）。
最后，wr m将配置写入。show run看一下配置，如果没有问题，reload确认一下。
Read more...公司把IDC搬到了AT&T，最近几天一直都在加班。
这家机房的基础设施和服务都不错，唯一的问题是他们卖东西的时候和AT&T的接入服务一样—-有时候有意无意地去混淆一些概念。说到这里得提一句，导致我决定不使用AT&T的DSL服务的原因就是，他们居然把动态IP说成是一个feature，并强调这个feature能够提供更好的安全性，这样的"包装"真是让我觉得非常不舒服。
和在国内看过的那些机房比，AT&T的这家机房里面的用户不算多，客户的规模也不算是非常大。休息的时候在IDC里面转了一圈，看了看别家的机架情况，一些感想（IDC不让拍照片）：
很多公司的业务和技术/经济实力从设备和布线就能看得出来了。
不过看看AT&T给一些公司代做的布线和我们自己的布线，虽然也还算比较整齐，不过我还是得说，我们这是工程，他们是工业……
Read more...下周一的8.0-BETA2会包含这个。CAM/AHCI是按照CAM框架重写的AHCI驱动（之前是ata(4)），提供了包括NCQ等硬件特性的支持，并改善了对SATA光驱的支持。与OpenBSD的实现不同，FreeBSD实现通过扩展CAM框架使其直接对ATA设备提供支持。
目前使用该驱动的办法是在引导過程中加载ahci.ko，或编译 device ahci 进内核。注意，CAM/AHCI驱动使用与ata(4)不同的命名规则。
Read more...27了，不能再假装年轻了。
Read more...In memorial of Michael Jackson (1958.08.29 - 2009.06.25)
“Heal The World”
There’s A Place In
Your Heart
And I Know That It Is Love
And This Place Could
Be Much
Brighter Than Tomorrow
And If You Really Try
You’ll Find There’s No Need
To Cry
In This Place You’ll Feel
There’s No Hurt Or Sorrow
DNS是目前互联网上使用最为普遍，同时也是漏洞很多的一个协议。DNS投毒攻击（Poisoning）是一种比较常见的攻击手法，具体而言，通常一台 DNS 缓存服务器能够影响大量的客户机，通过投毒攻击，能够使得大量用户访问某个具体域名时得到不正确的结果（例如，钓鱼网站，等等）。
为了减少DNS投毒攻击的威胁，有两项非常重要的安全实践，其一是将权威DNS服务器（这些服务器负责解析某些特定的域名）与缓存 DNS 服务器（这些服务器负责代替其他机器解析域名，并将结果在其本地缓存，以减少权威 DNS 服务器负载和不必要的网络间流量）分开部署，并启用 DNSsec；其二，是限制 DNS 缓存服务器的可访问来源 IP，并在边界路由器上过滤来自不受信路由器，但来源 IP 字段是本网络的数据包。
由于 DNSsec 目前还没有被广泛部署，限制能够访问 DNS 缓存服务器的来源 IP 是缓存服务器配置的一项非常重要的部分。我们知道，UDP协议中，来源IP字段是可以伪造的（这也是为什么TCP协议要比UDP安全的原因，因为它使用三次握手机制来提高伪造来源 IP 的难度），而 DNS 协议的普通查询建立在 UDP 之上（这是出于显而易见的性能考虑；在实际实现中，许多 DNS 服务器支持以 TCP 方式进行查询），而其事务 ID 只有 16 个 bit，很容易伪造，因此，攻击者通过向 DNS 缓存服务器发出查询受害域名的请求包，并同时发送大量伪造的 DNS 回应，并在这些伪造回应中人为地设置较大的 TTL，就很有机会"污染"缓存 DNS 服务器的本地缓存，并在其中长期滞留，从而达到影响更多客户机的目的。
针对 DNS 投毒攻击，目前并没有真正的遏制方法，所有采取的措施，包括 DNS 缓存服务器的查询端口随机化等等，都只是将攻击者成功的机会减少一些量级。真正解决这类攻击的方法只有 DNSsec 和 IPsec。
对于企业网络管理员来说，通过在企业内部架设 DNS 缓存服务器并进行合理的配置，能够有效地减少 DNS 投毒攻击的风险。这类网络往往采用的是不被路由的 RFC 1918 内网 IP 地址，并通过 DHCP 来对客户机进行配置，因此可以通过后者来将客户机 DNS 指定为内部的 DNS 缓存服务器。具体来说，企业内部 DNS 应配置为只监听内网，同时在访问外网时，尽可能利用 NAT 机制对其访问源地址、源端口进行随机化处理。
Read more...在 Apache 文档中提到，不能在单个 IP 上同时有多个按名字识别的虚拟主机(“named virtual host”)。不完全是这样。
HTTPS协议的过程是：服务器首先与客户机之间进行服务器身份验证并协商安全会话，然后，客户端向服务器发送 HTTP 请求。这样一来，在客户端开始发送请求之前，服务器就已经把证书发给了客户端（客户端根据本地的根证书去验证证书链，等等）。而最重要的是，为了表明身份，这个证书的周知名称（“Common Name”）填写的应该是域名，否则浏览器会给出警告。
既然在这个过程中，客户端就所访问的域名所处的地位是"被告知"的地位，因此，客户端再发出的 Host: 请求头也就显得不那么有意义了。另一方面，如果客户请求的域名与周知名称不符，浏览器也会给出警告。至少，在表面上看是这样。
不过，对于自行签署的证书，以及一些发证机构而言，其实还可以签署一种普适HTTPS证书，这种证书的周知名称一栏是 *.domain.tld 这样的形式，即其主机名部分可以是任意字符串，而只有域名部分是确定的。
当然，这种证书的安全性有一定的负面影响：由于一个证书可以验证整个域下面的所有服务器，一旦其被破解，则所有加密通讯也就同时失密了（当然，可以每台服务器使用自己的单独的证书），不过这个问题并不是太严重，通常还算是尚可接受的范围。另一个潜在的影响是，某些手机上运行的浏览器不能正确处理这种证书，不过这个问题仅限于希望给手机提供服务的网站。
因此，简而言之，符合这样几个条件的前提下，是可以在同一个IP上部署多个HTTPS虚拟主机的：a) 这些虚拟主机是同属于同一域名的子域名 b) 拥有普适证书 c) 正确地配置Apache。
Apache配置要点