November 9, 2007 – 1:02 pm
公司的网络一直是走得移动的企业宽带，貌似是光纤到楼的吧。3个月前去申请从2M扩容到10M。对方很早就说做好了，但是从我本地网关出口的流量监控来一直都没突破过2M。
昨天下午，网络突然不通了，于是报修。半小时后来了个扛着笔记本的技术员，把本子往出口网线处一接，ping了下对端，不通，然后就说了句去对端机房看看，就跑了。
然后就是持续到今天上午的网络瘫痪，移通的说法在换了n个版本后，网络还是依旧不通。
一上午没办法干活不行，于是再把出口接上自己看看能不能查到线索，于是发现了如下tcpdump结果：
09:55:00.006472 00:00:00:22:25:8c > ff:ff:ff:ff:ff:ff, ethertype ARP (0×0806), length 42: arp who-has 211.X.X.33 tell 211.X.X.34
09:55:01.003376 00:00:00:22:25:8c > ff:ff:ff:ff:ff:ff, ethertype ARP (0×0806), length 42: arp who-has 211.X.X.33 tell 211.X.X.34
09:55:01.763189 00:0b:be:51:b9:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0×8100), length 64: vlan 209, p 0, ethertype ARP, arp who-has 211.X.X.34 tell 211.X.X.33
09:55:01.791808 00:0b:46:2b:e2:82 > 01:00:0c:cc:cc:cd, ethertype 802.1Q (0×8100), length 68: vlan […]
October 18, 2007 – 4:09 pm
前一阵子看到了MySQL Proxy这个东西出世，就推断将会从这个玩艺发展出很多架构方面翻新的花样，还没来得及研究，这就有人有研究成果了。
如下图：
通过MySQL Proxy实现一个连接池，并在其中分辩客户端连接为读或写操作，将不同操作导向到不同的后端数据库服务器，来实现性能的提升。
具体实现方法和步骤参考原文：
http://jan.kneschke.de/2007/8/1/mysql-proxy-learns-r-w-splitting
October 15, 2007 – 10:36 am
突然想到我个人做网民满十周年了，然后就顺便查了一下中国互联网的历史，发现至上个月9月20日起，刚满20周年，并且找到了一个十分有趣的东西，如下图：
看不懂？没关系，其实我也看不懂，只有懂德文的才能看懂:D
只需要知道一件事：这是中国联入互联网发往国外的第一封信件，目的地是德国，此图片为这封信的打印件。
而这封信的内容只有一句话：
Across the Great Wall we can reach every coner in the world.
这对于中国互联网20周年来说，这可真是一个莫大的讽刺阿。
所以后面我再加一句：
Now we have the Great Fire Wall.
September 11, 2007 – 11:20 am
今天看到这么一则新闻：DMTF Accepts New Format for Portable Virtual Machines from Virtualization Leaders
说是几个“Leader”厂商正拟定统一虚拟机的格式，以便于在各种产品中移植以及确立标准，这几个“Leader”来头不小，以下： Dell, HP, IBM, Microsoft, VMware, XenSource 。
有标准可依大家都高兴，不过估计又会出现虚拟机产品同质化的问题吧。不过对于Full Virtualization这种形式来说，解决方案比较重要，由固定几个大公司把持标准应该不是坏事。
个人更关心OS Level Virtualization。
September 6, 2007 – 12:42 pm
今天碰到了一个DNS解析记录总是不生效的troubleshooting案例，故障现象很诡异，有部分解析记录是完全没有问题的，而有部分则完全不生效。通过dig诊断来看就好像根本不存在这几条记录一样，而这几条记录又是确确实实地写在了zone file里。
正在莫名其妙的时候，发现log里在加载这个zone的时候有这样一条日志：loading master file /var/named/xxxxxx.zone: CNAME and other data。
还有一条标明了行号，于是检查，发现在此行配置了一条MX记录，同时下面还有一行是同一子域名配置了一条CNAME记录。于是怀疑对于同一子域名不能同时存在这两种记录，删除其MX，reload发现没有日志出现。再dig，发现先前解析不出来的记录都恢复正常。
然后回顾了一下，认为我这个推断是正确的。因为CNAME本身就是将子域名委派至其他DNS服务器解析管理，此时其自身配置的A与MX应当失效，所以不应该存在此类记录才对。BIND在此应该是拒绝zone file里同时写了同一子域名的CNAME与其他记录。
再想了一下，刚才故障中正常的解析都是位于此条之上的记录，失败的都是位于之下，说明BIND在加载zone的时候是按照配置文件逐条读入，碰到失败则放弃之下的所有内容，所以才有此奇特的故障现象。
后经测试，有CNAME存在时，确实A和MX都不能建立，否则报错，NS倒是可以，但是不起作用。
看来有空还是要好好研读RFC，一些细节方面的东西不能忽视。
August 29, 2007 – 8:39 pm
Wordpress的URL静态化其实是通过Apache的URL Rewrite功能实现的伪静态话。在开启这个功能后，blog的根目录会生成一个.htaccess的文件，通过这个文件的一些配置项，来实现URL静态化功能。默认创建的.htaccess内容如下：
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
简单来说，就是将访问到非实际存在的文件或者目录的URL全部转向至index.php。index.php接受到这个URL后可以根据这个URL的某些部分来确定要访问的具体页面。
然而启用这个静态化之后，会发现Dremhost后台通过 analog 6.0搭建的访问日志分析工具会访问不到了，会直接跳出Wordpress theme的404页面。原因大概是因为这套系统的入口是http://yourdomain/stats/这样的URL，实际/stats/是在Dreamhost的Apache配置中通过Alias指令添加的虚拟目录，并不存在于站点目录下。然而.htaccess中已经通过URL Rewrite将不存在实际文件或路径的URL直接定向到index.php中去了，因此/stats/这个虚拟目录就无法被访问了。
解决办法自然是修改URL Rewrite的配置，让其额外对待/stats/这个URL。将.htaccess中的代码增加2行，变成如下即可：
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/(stats/|missing\.html|failed_auth\.html) [NC]
RewriteRule . - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
这样修改后/stats还会按照原有Dreamhost的配置访问，同时又不影响Wordpress的静态化功能。
此技巧来自Dreamhost的Wiki，另外还有其他Blog或CMS程序的配置方法，具体可以访问这个页面了解：http://wiki.dreamhost.com/index.php/Mod_rewrite
August 21, 2007 – 12:46 pm
这个应该不算是新闻了吧。具体被入侵的时间应该是8月6号，10号左右有新闻放出来。然而当时一直没有更确切地细节放出来，入侵原因也不明。今天偶然看到一篇Eweek的文章，才发现原因很简单—-服务器没及时打补丁-_-b
原文链接如此：http://www.eweek.com/article2/0,1895,2171318,00.asp
引用一句话：the servers have not been upgraded past breezy due to problems with the network card and later kernels. This probably allowed the attacker to gain root.
其实也就是说因为硬件与高版本内核兼容性的问题导致不能升级到无缺陷的内核版本，进而被人利用内核漏洞拿到了root，再然后被上了个sniffer嗅探到了明文密码，据推测可能是ftp帐号。再进一步控制掉整个服务器群。最后似乎拿来干坏事的时候才被发现服务器已经被人光顾了……
话说要适应商业化运作需求，就必须要有出了问题有人来擦屁股。开源社区整天东一头西一头的翻新花样出新奇玩艺儿，对老东西的维护修补却欠缺热情。花钱买东西的人，就是要你这东西能持续不断的服务，才不管你新东西怎么怎么好来的。而一个持续稳定地框架，确实是一个活跃过了头的社区最缺乏的东西。
话又说回来，你不做有人帮你做。各大发兴版厂商是干什么吃的，不就是在有限的几年内把社区在这几年吐出来的东西加工起来卖得么。这里的怪现象是：越有实力的厂商，发布周期越长，商业用户黏着度越高。象RH，Suse。但越亲近用户的厂商，就推陈出新越快，但往往不是那么好混，象Mandrake。这种厂商一旦用户见异思迁，倒掉也不过是瞬间的事情。说是厂商还不如说是一个商业运作的社区。Ubuntu这方面可谓做到了极致，有一群疯子般的开发团队，半年一个版本的速度也可谓前无古人后无来者。但话说回来了，即使有号称Server的版本，谁敢拿它的东西跑企业应用？半年一次翻新，受得了么？还难保不说这个Server版可能过几天就人去楼空掉链子？这次更绝，一个毛病把自己老窝都给毁了…..
再指责谁谁谁bug多漏洞多是不现实的，现在这个年代，谁也不比谁好多少。有严谨的补救计划才是正道。微软虽然以补丁多著称，好歹如果每个月第二个周二都按时打，一般都没出过大问题。而所谓的“高级”Unix like的sysadmin，恐怕也就Linux的root们没有打补丁的习惯的多。
说道补丁又想起一件好玩的事。前两天世界范围内skype大掉线，原因猜测是啥的都有，终于这两天好了，官方blog出来这么一篇声明：What happened on August 16，有意思了，微软的Patch Tuesday竟然导致号称跨平台的skype瘫痪成这样，是该说Windows普及还是skype说谎呢？
结论：只有一个，不打补丁者害人害己。
这是一段神奇的代码，传说能够揭开这段代码背后秘密的人，都会莫名其妙得人间蒸发，更有传说，这段代码关系着一个巨大的宝藏，对于这个宝藏，没有人知道它何时何地出现，但人们都知道，它的名字，叫做GFW。
新浪关于海外邮件通信问题的说明
http://vip.sina.com.cn/loginbefore/news-maintext070717.html
网易关于海外邮件通信问题的说明
http://vip.163.com/vip/notice.html
万网关于海外邮件通信问题的说明
http://www.net.cn/service/a/zytz/200707/2312.html
新网关于与海外邮件通信问题的说明
http://bulletin.xinnet.com/News/200771710226.html
中国频道关于与海外收发邮件的特殊问题
http://www.china-channel.com/hot_news.asp?ID=737
中资源关于海外邮件通信问题的说明
http://www.zzy.cn/file/07-07-17.htm
35互联关于与海外收发邮件的特殊问题
http://www.35.com/xinwenzx/xinwenzx_news.asp?ID=516
263关于与海外收发邮件的特殊问题
http://gmail.263.net/news1-0.html
尚易关于与海外收发邮件的特殊问题
http://www.corpease.net/service_12_87.htm
在这诸多路豪强的英雄帖中，我们都发现了同样的一句话：近期互联网国际线路出口不稳定
据说，这是宝藏现世的征兆。
于是，怀着梦想的人们相继出发，去找寻这秘密。
少年阿，命运之轮已经开始转动，传奇从今天开始。
本文由和谐语言书写，个中滋味请自行揣摩。
最后骂一句：诚彼娘之非阅！
IIS7是伴随着新一代Windows Server操作系统发布的新的WebServer。从目前为止其特点来看，这一代相比IIS6应该会有一个质的飞跃，因此从Windows Server Codename “Longhorn”开始的每个公开预览版本，IIS都是我最感兴趣的。
Beta3发布之后，微软IIS开发团队的Bill Staples大牛在IIS blog上撰文写了关于IIS7在beta3之后加入的几个新特性。在此大体介绍一下这篇文章并意译一下，然后掺杂点自己对于新版本试用中的几点看法，希望有更多的人来关注和使用IIS7。
原文链接如下：http://blogs.iis.net/bills/archive/2007/04/25/what-s-new-in-iis7-beta-3.aspx
前几天购买的Hostmonster的Hosting plan跑得好好得突然挂了。检查发现traceroute从骨干网就过不去了，看来是被某BOSS级隐藏超级设备给吃了，无奈搬回Dreamhost。
最近发现比较有空，就仔细研究了一下Dreamhost的基础架构，发现还是很有意思的，记录如下，不断补充中。
