Jan 162012
 

今天在新系统上装QQ的时候碰到问题了,装好的QQ只要打开聊天窗口必然崩溃,是整个QQ一下子自动退出那种,查了半天log发现在eventlog里有关于MFC模块的Error。因此推断大约又是系统安装的MFC版本和QQ使用的版本有兼容问题。

通过一通google之后发现这样一个KB: http://support.microsoft.com/kb/961894/en-us

看起来跟QQ自动退出的问题一点不相关是么,但是装了这个KB,问题解决=_+

阴魂不散的DLL Hell啊。

 Posted by at 9:34 am
Aug 242011
 

早就计划新一轮的硬件升级,怎奈预算不到位一直拖着。这两天过生日从张总那里得到强劲支援,于是一咬牙,大换血。

这次主要升级三大件,目标是讲平台换至Intel近期比较牛X的Sandybridge,其它暂且不动。因此硬件清单为:

CPU: Intel Sandybridge I5 2500K(张总支援)

主板: ASRock  Z68 Exetreme 4

内存: 三星金条30nm 4G X2

散热: Thermalright HR-02 Macho

CPU没得说,普通使用的话目前主流CPU都已经是性能过剩了。选择I5 2500K而不是I7 2600K的原因是I7仅仅多了一个HT功能,可以打到4C 8T,而I5本身只有4C 4T。HT出来的4个核心无法与实际CPU核心相比,而且在某些多线程不敏感的程序或游戏中,HT多出来的thread还可能带来负面性能影响。另外的区别就是I7多了2M的L3 cache。这点数量的性能差异,基本仅仅在测试中才能提现出来,平时实际应用基本感觉不到。另外发烧友中风传,选择I5,超频性能更好。

主板本来在ASUS的P8Z68系列和ASRock这块板中犹豫不决,选择华硕意味着更好的稳定性和售后服务,但华擎这块板的功能附加更多,且华擎高端主板今年表现极为抢眼,这块EX4甚至获得了Tom’s Hardware的年度编辑选择奖。因此在和张老板讨论了许久后,决定两人一起选择华擎。

内存方面,张总彪悍的入了Corsair Vengeance(海盗船复仇者) 4G x2,据说是能冲击2133频率的牛条子。而我个人认为内存延迟和带宽在Sandybridge时代因为L2+L3的多级缓存,已经对于系统整体性能的影响微乎其微,因此选择了廉价的普条。怎奈看中的三星黑条无货,只好选择了金条,但好处是刚好本月上市的金条换用了新的30nm的颗粒,性能和功耗都可能有不俗的表现。

散热器这里特别值得一提。本次升级我和张总两人的目标都是想小超一把稳定使用的,因此散热方面不能太省,同时兼顾静音需求。在否定了太过高端的变形金刚之流后,发现了HR-02 Macho这个YY货,这散热器是HR-02的简化版,没有采用HR-02的回流焊和镀镍工艺,节省了不少成本,但同时附送了一个14CM的超大扇子,价格也相当有性价比。而后就个人装机后的体验来说,这个散热确实超值。
首先偷一下专业摄影师张总的图,可以看到主板和散热的盒子那是相当的抢眼,而Sandybridge的U现在的包装相对于以往老U缩水了不。

接下来都是本人用手机拍的图了,效果惨不忍睹,只能凑合看了。

首先就是这个巨大的散热器

拆开看更恐怖

附送的14寸风扇,全速运转转速1200左右,静音效果相当不错

CPU以及附送的原装风扇,由于32nm的U功耗不大,附赠的风扇也相对不给力,属于直接扔垃圾箱的货。

接下来是主板,卖相相当不错。注意左上角各种I/O接口的配备,那是相当之多,比较不同的就是上边有3组USB2输出和一组USB3输出,左边有8个SATA输出,蓝色的4个为SATA 3G,白色的是SATA 6G。另外Debug灯和板上自带的大power botton和reset button我很喜欢。

 

安装CPU内存条,并上好散热器后的主板。手机拍照有一点反光就糊了。这散热大到几乎占据了一半的主板版面,感觉主板都像是Micro-ATX版型了,而实际上,这可是标准的ATX大板。

放在机箱上准备上电点亮了,机箱是前几年败的P183,由于电源下置,因此这里是把机箱倒过来放了,为了能让电源线顺利接上主板

简单的接了电源,以及DVI线和一个USB键盘,满足最低启动要求。Z68可以利用Sandybridge的内置GPU,连显卡都不用插了。

顺利点亮,现在的主板大多用UEFI替换掉了BIOS,因此自检界面看起来也细致了很多。这里认出默认3.3G的I5 2500和8G内存。

UEFI的设置界面看起来就是一个简单的GUI。键盘鼠标都可以使用,还好只用键盘的操作并不复杂。这是在默认3.3G情况下的温度和供电情况。CPU温度44度,稍微有点高。原因是在BIOS时,CPU其实是全负荷运转的。另外我家室内的环境温度也稍微有点高,没有开空调。

发现ASRock的UEFI有自动超频功能,于是小小实验了一把,结果发现相当给力,直接给拉到了4.8G的主频

发现此时温度和电压也相当给力,加压加到了1.424V,有点高了。但至少表示,这块CPU的潜力还算不错,估计经过调教后应该会有不错的成绩。我的目标是在4.5G频率下长期使用,此时电压最好在1.3V左右。

简单测试完毕,剩下的就是装入机箱了。这里show一下我的P183,个人相当喜欢这款箱子,电源下置,是在右下角,左下角有两个硬盘笼子。这里show的是我的背板走线,可以看到大部分连接线都可以从背面走,正面就会显得极为整洁,同时也不会影响到内部散热。

正面玉照,可见相当整洁,唯一不完美的地方就是8Pin辅助电源供电必须从正面走,因为我这个线走背面恰好不够长,只能这样凌空飞过去了。

最后装上显卡,这样就基本完工了。从这个图可以看到这个散热器无论是高度还是宽度都是相当恐怖,我20CM宽度的机箱,竟然差点装不下这个巨物。

至此告一段落。剩下的就是装系统,超频,以及其它调教工作了,咱们下回再说。

 

May 062010
 

DNS污染作为一个已知的安全问题已经存在了好长时间了。但是一直以来没有十分好的办法来解决这个问题。比较一劳永逸的解决方案是DNSSec,但应用它要求在所有DNS通讯上实现安全协议,实施难度相当于把整个DNS生态重新搭建一遍,因此一直以来没有什么厂商来推动。DNS的安全问题也就一直被睁一只眼闭一只眼地忽略了。

这两天翻文章的时候翻到了ICCAN网站上,发现他们公布的DNSSec实施Timeline已经快到期了:

Planned High Level Timeline

  • December 1, 2009: Root zone signed for internal use by VeriSign and ICANN.  ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.
  • January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.
  • Early May, 2010: All root servers are now serving the DURZ.  The effects of the larger responses from the signed root, if any, would now be encountered.
  • May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.
  • July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.

 

根据这个Timeline,在7月1日起,根zone应该就可以承担整个Internet的DNSSec的查询流量。

从今天刚刚发布的这篇文章来看–《Status Update, 2010-05-05》,实施DNSSec的兄弟们已经做好了一个实现准备好的假根Zone — Deliberately Unvalidatable Root Zone (DURZ),然后接下来的时间内观察并研究DNSSec的流量,并决定是否进一步将其推向生产环境。

简单来说,DNSSec已经迫在眉睫了,如果一切顺利的话,我们将在2个月后得到一个安全健壮的DNS系统,届时我们将可以把自己的域名置于安全证书的签名保护下,以免于DNS污染或其他DNS安全问题。讽刺的是,7月1日刚好是某一直致力于阻挠和破坏Internet信息流通的某政党的生日,希望它在当天收到这个礼物的时候表情不会太难看。

Jan 222010
 

最近感情有些不顺,于是就花钱消遣着玩,其中就包含这个键盘,应该算是目前我入手价钱最贵的一把了。

最近狂迷机械键盘,啥东西都想拿来玩玩,刚好KBC组织了一批团购,用自有品牌OEM做了这款机械键盘,于是就脑袋发热定了一把。

 

看看名牌,虽然Ducky这个名字有点俗,不过这个Logo放在这个位置,比想象的还是好一些的:

 my 011

拿下键帽验证一下,如假包换的Cherry黄金MX茶轴:

my 012

附送的一套墨绿色31键字母键帽,USB-PS2转接器,还有一个拔键器,都是好东东:

my 013

指示灯是嵌入在键位下面的,这样感觉很帅,有3个蓝色的是传统的NumberLock、CapsLock和ScrollLock,另外在F9-F11放了三个红灯,配合多出来的控制键可以实现锁Win键的效果,以及CapsLock和Ctrl互换的效果(某Linux键盘布局习惯)

my 014

108键布局,多出来的就是这4个按键了,这些按键其实是扩展多媒体按键,因此无需驱动可以使用,对于机械键盘来说,能配有多媒体按键的都算是异类了。

 my 015

来看键帽局部:

my 016

最后是和我的Cherry G8000青轴的合照:

 my 010

单从外表做工来看,几乎和Filco不分上下了,不过比起Cherry来看还是有些区别,因为Cherry特有的无钢板技术和分层键帽斜度的设计其它厂商是根本无法抄来的,这款OEM的自然也不可能有。不过超薄边的设计是Cherry没有的。那指示灯的设计也足够炫。还有多媒体键的设计也是其它机械键盘所不具备的。综合来讲,是一款很值得收藏的键盘了。

手感方面的话,基本上只要是同种类的机械键盘都有些雷同了,唯一的区别就是Cherry键盘是无钢板而其他所有机械键盘都是背面有钢板的,这会带来稍稍的手感差异。这款键盘的手感跟其他品牌的茶轴并无太大差别,唯一能给我带来注意的是空格键的手感稍有不同,比较安定,不会晃,敲起来很舒服,估计是双卫星轴的设计导致的。

这键盘前前后后从订购到到手足足花了2个月时间,期间除了下单到工厂,制作,出货外,还有些时间是因为台湾那边台风导致货物无法出海。不过好事多磨,等了这么久还是拿到了,品质完美!南京的主任还随键盘发了张贺卡过来,并主动给我延长到5年保修,有这样的商家真是造福发烧友^_^

Dec 282009
 

新搞了个VPS,打算把Blog以及全套行头迁移过来。

以前的那套图省事,用了CentOS5 Kloxo AllinOne BOX。基本上依靠这个CP搞定了全套,主要是人懒不想折腾而已。这次换了个新的VPS提供商,心血来潮想折腾Debian。所以把过程记录下来,避免以后不折腾了却忘记自己当初怎么搭。

总体思路还是采取懒汉办法,有官方源的从官方源安装,没官方源找第三方社区源,再没有的话自己做deb,无论如何,避免从源代码直接编译。

首先把最简单的MySQL装上,用官方源,一句话搞定:

apt-get install mysql-server

MySQL配置文件稍后再搞,对于小Blog来说MySQL的优化意义不大。

其次是nginx,说实话这东西不熟,不过貌似最近挺流行,Debian Lenny也将其收进官方源了,那就简单apt之

apt-get install nginx

简单netstat看一下发现80已经在监听了,访问http://<IP>发现出现欢迎页“Welcome to nginx!”,接下来就是怎么让PHP在nginx上跑起来。

很没技术含量不是,很不幸后面的也没啥技术含量。一破Blog日IP不过300折腾个什么劲啊,不就是一个玩儿么。

PHP稍微麻烦点,因为Nginx没有像Apache那样的SAPI调用PHP的方式,而是使用FastCGI来调。这里就存在一个对PHP的FastCGI进程如何管理的问题。官方源的php5-cgi本身没有进程管理机制。一个比较好的选择是用spawn-fcgi(源自lighttpd的小东东)来起PHP进程,结果查了一下spawn-fcgi到现在还在sid呆着。还有一个选择是使用php-fpm来做FastCGI进程管理,这东西的灵活性比spawn-fcgi还要高不少,但代价是要往PHP源代码里打Patch才能用,也就意味着–要重新编译整个PHP。

简单权衡了一下,我觉得我还是想用php-fpm,但是又想偷懒不编译源代码,于是就求助于第三方二进制源了。随便搜了一下发现还真有正合适的– http://www.dotdeb.org/,这个社区致力于维护Debian下的LAMP类软件的非官方二进制包,恰好它们近期重做了PHP,使用了PHP5.3.1版本,并集成入了Suhosin安全补丁。最让人舒服的是吧php-fpm做成了一个php5-fpm的安装包,并给其加了SysV类的启动脚本,这样PHP的FastCGI方式即可以有自己单独的conf文件,又有单独的init.d控制脚本,可谓完美。

无废话说干就干。

修改/etc/apt/source.list,加入dotdeb的源设置:

deb http://php53.dotdeb.org stable all
deb-src http://php53.dotdeb.org stable all

然后apt之:

apt-get update
apt-get install php5-cgi php5-fpm

这样PHP就算完事了,简单验证一下,运行如下命令,观察phpinfo()输出是否正常:

php-cgi –i

再保险点看一下PHP的FastCGI进程有没有跑起来,ps aux|grep php,应该能看到有进程为”/usr/bin/php5-fpm –fpm-config /etc/php5/fpm/php5-fpm.conf”在跑。

剩下的事就是搞定nginx的配置文件把站点建好,并让其能调用后台的PHP。这个dotdeb社区源做的php5-fpm好心到都提供了一个nginx的example配置文件,放在/etc/php5/fpm/nginx-site-conf.sample,改改拿来用就好了。

我是将其复制到/etc/nginx/sites-enabled/opslife.com.conf,然后简单修改几个参数,改好的配置文件是这样:

#
# nginx-site-conf.sample:
# Php Site configuration for nginx webserver
#
# 1. set server root /path/to/your/website;
# 2. Rename this file. Copy it to /etc/nginx/sites-available, /etc/nginx/sites-enabled
#    or otherwise ensure that this file is included by the nginx.conf
# 3. Restart nginx webserver, and php-fpm service.
#

server {

        root  /home/dawnh/opslife.com;

        server_name     opslife.com www.opslife.com d9.opslife.com;
        listen          80;

        access_log  /var/log/nginx/opslife.com.access.log;

        location / {
                index  index.html index.htm index.php;
        }

        #error_page  404  /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
                root   /var/www/nginx-default;
        }

        # pass the *.php scripts to php-fpm listening on tcp port 9000
        #
        location ~ \.php$ {

                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;

                include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SERVER_NAME $http_host;
        fastcgi_ignore_client_abort on;
        }

}

这样站点配置就算是完成了,/etc/init.d/nginx restart重启后,新站点应该就会跑起来了,使用域名opslife.com、www.opslife.com、 d9.opslife.com都应该访问到新建立的站点。

最后再验证一下,扔一个info.php放到/home/dawnh/opslife.com,内容就一句:

<?php phpinfo();?>

由于主域名还没指过来,先用子域名访问测试,直接访问http://d9.opslife.com/info.php,看到返回正确的phpinfo信息。到此最后一步也算顺利完成。

 

剩下就是把wordpress的东西从老的VPS迁移过来了,依旧是没什么技术含量。有空再记录。

Sep 182009
 

前两天在delphij老大的blog中看到了一篇《使用DSR模式实现单IP服务冗余》,觉得很有意思,因为这个实现方式与我以往所见到的有些不同,通过关闭ARP响应来解决虚拟IP在负载均衡设备和服务器上可能冲突的问题。随即提问了一下我所熟悉方式的实现是否可行,勤恳的delphij竟然又写了一篇来解释这个问题。不过这篇的思路似乎与我原来的想法有点出入,所以仔细又思考了一下,最终决定还是要完整的阐述一下我的思路。

我虽然见过一些DSR的实现方式,然而只不过是阅读架构文档而已,想当然来的东西跟最后实际实施出来的东西肯定有差距,所以把自己认为的设计思路记录下来,看看最终是否可行。

首先是拓扑图:

DSR

介绍一下简单的信息:

  • Public VLAN直连Internet,LB和Router分别有一个网卡接口连在这里,用于承载Internet的虚拟IP自然也就是绑在LB连在Public VLAN的NIC上了,方便起见,随便起个IP: 202.96.100.100(202.96段是中国电信骨干IP段,很多坏事都是这里发生的:D)
  • Internal VLAN是放服务器集群的网段,当然就用私有地址,就用典型的192.168.1.0/24吧,这里的Server使用IP 192.168.1.101

首先从数据流角度来看(红色箭头上的标号):

  1. 客户发起到请求: 61.152.X.X:1025 –> 202.96.100.100:80
  2. 负载均衡设备通过匹配包,发现目的IP为虚拟IP,根据Load balance算法挑选一台Server,将数据报直接路由到这台Server,不做任何修改(减TTL不算)61.152.X.X:1025 –> 202.96.100.100:80
  3. Server看到数据报的目的IP是虚拟IP,并发现虚拟IP绑定在自己的lo上,认为目的地是自己,OS派发到应用层Web Server处理Request并生成结果,结果数据包变为 202.96.100.100:80 –> 61.152.X.X:1025
  4. 数据报发往路由器,路由器看到目的地为客户IP,路由到Internet去。

这个过程与传统NAT方式的Load Balance的区别在于,LB不修改目的地址,直接将数据报通过路由的方式转发给服务器集群。然而这里的难点就在于:如果不修改目的IP,那必须让Server能够对发往虚拟IP的请求做出响应,那就必须要把虚拟IP绑定在Server端,因此虚拟IP就同时出现在了两个地方:LB和Server,解决这个冲突就是完成DSR的关键所在。对于此点引用delphij的原话:

实现DSR结构的关键是,通往Internet路由器的那个网络上,只有负载平衡设备在网络上宣示虚拟出来的那个IP的MAC地址,这样,当请求进来的时候,数据会发到负载平衡设备,而不是某一台服务器上。

Delphij采用的方法是,将服务器上网卡的ARP功能关闭,这样服务器虽然绑定了虚拟IP,但不会对外界对于虚拟IP的MAC地址解析请求做出响应,所以完美解决了IP重复的问题。缺点是ARP一关Server自己会找不到Router或者网络内的其他服务器,因此需要手工维护一个静态ARP表。

而我所采用的方式,是不将虚拟IP绑定在实际网卡上,只是绑定在Server的还回(lo)上,这样依旧可以起到缩减ARP响应域的作用。

Delphij认为这样会需要一个额外的Public IP,不过我认为如果Server放在私有地址VLAN的话,应该是不需要额外的IP,在如图的这种拓扑中应该可以完美的工作。只要LB和Server中作出如下配置(红色罗马数字):

I.  Load Balancer要特别设置的地方有:

  • 需要有合适的负载均衡算法以便于把流量分发给不同的Server。
  • 对于TCP这种有状态的服务,需要使用较为宽松的状态机制来维持会话。

这里引用delphij的pf命令为例,如下,round-robin是负载均衡算法,keep-state(slopppy)是宽松状态匹配,这一点对于DSR也是尤为重要,因为DSR的特点就是从Server发回的响应不经过LB,LB看不见回去的响应包,所以Session track必须能容忍这种半吊子连接。而且这里似乎也必须修改Session的timeout时间,否则会有问题,这里无关者略过:

    FreeBSD pf规则举例:pass in on em0 route-to { em1 内网IP1, em1 内网IP2, em1 内网IP3 } round-robin proto tcp from any to 公网IP port http keep state (sloppy)

II.  Server端需要的设置:

  • 在lo上绑定虚拟IP 202.96.100.100,这样Server才会认为目的地是自己。
  • Web Server本身要使用虚拟IP作为监听IP,比如Apache配置Virtualhost的话这样用:<VirtualHost 202.96.100.100:80> ,如此以来Web server会对到虚拟IP的请求做出响应,且响应的源地址也是虚拟IP而不是自己网卡上的私有IP。
  • Server将默认网关设置为Router的IP,这样对于请求的响应就会发往Router而不会返回LB了。

III. Router上应该不需要什么特殊设置,知道把发往Internet的包路由出去就行

这样整个DSR就应该能走通了,不过这个玩法我也只是想出来而已,还没有经过实践,当初看到过F5的nPath实现,应该就是这么种玩法,不过估计实际应用时应该会有我这里没有想到得地方,所以有时间的话,最好还是找几个设备搭一下看看吧,先把设想架构放这儿,改天回来验证。说实话,delphij指出这里必须要有一个额外的公网IP才能保证知道出去的包怎么走,我这点还是没有想通。不管怎样,写出来让大家指正吧,至少在写这篇的过程中,我已经将自己以前没考虑到得一些细节补充完整了,对于自己来说,也算是不小的收获。

Sep 122009
 

最近工作比较郁闷,忙里偷闲又拿起EQ2来玩,其实就是在四处逛大陆看风景,偶尔做几个任务玩玩。结果发现SOE把库那克这块大陆设计的还是蛮有意思的,于是就有了记录点东西的冲动。

自从库那克回归以来,众多冒险者就蜂拥而至,毕竟这里埋藏着很多自EQ1以来的传说中的宝藏。然而对我这个不称职的吟游诗人来说,宝藏那是绝对没有兴趣,只是想来见识一下好玩的生物和事儿而已。目前统治这片大陆的种族是蜥蜴人,一个丑陋而又野蛮的种族,一点都提不起我的兴趣来。然而蜥蜴人在这里驯化了众多生物当坐骑,这个是我感兴趣的东西。于是我的近期目标就是看看能不能弄一个拉风的坐骑来玩玩。毕竟对于一个终日在诺拉斯游荡的人来说,跑得快才是保住性命的头等大事。因此即使是号称跑得最快的吟游诗人,也希望能够有个高速坐骑。

于是我就跑到蜥蜴人聚集地Rillss去四处打听。终于打听到一个叫Sliza的女蜥蜴人能给我想要的东西。于是我就去找她,据说她是个美女,当然见多识广的诗人是不会被当地土著的说法误导,所谓蜥蜴人中的美女如我所料,就是这个样子的:

EQ2_000047

这个神经质的女人当然不能随意满足我的要求,让我帮他去野人山上偷水晶,还让我去侦查一个最近来到库那克的野蛮人部落的情况。在费劲九牛二虎之力后,终于一一满足了这个女人的要求。最后她终于答应我给我一头当地驯化好的雷犀牛,但最后的条件是,要去野蛮人部落里拿一本书,然而没人知道这部书在那里,除了那些野蛮人…..她给我出了一个馊主意:野蛮人对于一种生物戒心不大,只要伪装成这种生物,自然能够接近他们。于是我就引以为真的接过了这个女人给的魔法面具,然后就发生了这种情况,我变成了老鼠人:

EQ2_000012

当我看到自己这个尊容时,差点没笑趴下,这也太可爱了>_<,哪里是我冷酷的黑暗精灵啊,哈哈,再看我战斗时的勇姿,这是路经某诅咒之地时被仙人掌妖怪袭击时的战斗:

EQ2_000013

跑了好远的路终于到达了极北之地,也就是这个野蛮人部落Order of Rime的营地了,果然他们对于我这个形象没有什么戒心,但我觉得他们是忍着笑的>_<

这些野蛮人的来头果然很神秘,他们是从冰山上迁徙过来的,并且在他们当中也混杂有其他的种族,例如博学者和冰巨人,总之是个很奇怪的族群,既不像正义,也不是邪恶,似乎也有他们自己的信仰,路上看到一个站岗的冰巨人,于是未经同意跟他合影一张,这里我用了作弊的拍摄方法,否则以我变成鼠人后的身高,连巨人的膝盖也达不到-_-,而且,这家伙似乎根本就没看见我:

EQ2_000022

这里的人会说诺拉斯公共语,因此打听了一阵子后,顺利拿到想要的书,于是立刻回头去报告女蜥蜴人,其实真正原因是–这里太冷了!

走之前,特地去参观了部落王座,是用两条海龙拉动的冰山,据说他们就是一直用这种方法迁徙的:

EQ2_000024

回去的时候发现海边竟然有蜥蜴人的Sokoka站,那就可以飞回去了,Sokoka是蜥蜴人的远程交通工具,飞行速度不错,这是飞离极北部落的最后留念,可以远远看到背后停靠在海边的王座,此时已经不用以老鼠人身份示人,可以看到我的黑暗精灵飒爽的身姿0_o:

EQ2_000025

找到蜥蜴人后她很满意,立刻给了我一头犀牛,蜥蜴人虽然粗俗,但是信誉还是不错的。只是她没跟我说,给我的竟然是一头黑皮犀牛,还给配了个金色的鞍,超级恶俗,让我这高等的暗精坐在上面,那简直就是–黑啊!

EQ2_000027

而且该死的女蜥蜴人没告诉我,犀牛跑起来是前后脚不同节奏,加上庞大的身躯,造成的后果就是跑起来屁股左右扭,人在上面坐着要被摇得东倒西歪。该死!怪不得犀牛虽然是大陆上非常能跑的生物,但是蜥蜴人们从来都是坐着慢慢走的,他们没有告诉我>#<

 

EQ2_000044

诺拉斯上每天都会碰到新奇的事儿,当然最终结果就不一定是想象的那么有意思了。如果哪天你看到一个黑皮精灵起着金鞍碳烤蜥蜴呼啸而过,那就是我了。

Sep 112009
 

在本月的周二补丁日,微软发布了一组补丁用于修复存在于TCP/IP协议栈上的漏洞。可以从http://www.microsoft.com/technet/security/bulletin/MS09-048.mspx看到微软的更新声明。

同时,Cisco也发布了用于解决存在于IOS同样漏洞的补丁,声明于此http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml

发布补丁其实并没什么稀奇的,特地为这个漏洞/补丁写一篇Blog的原因是这个漏洞背后有点非常有意思的八卦:

  • 这个漏洞能造成的影响其实相当巨大,当初问题被发现时,非常多的TCP/IP协议栈实现都被证明是存在问题的。而在接下来的一段时间内,发现这个问题的几个人开发了一个攻击工具,经证明可以对Windows/Linux/BSD等等的机器发起攻击,仅仅需要发起数kbps的流量,持续几分钟之后就会导致目标服务器完全停止响应。
  • 可被攻击的目标非常广泛,任何有端口在监听的服务器、PC甚至路由器都会被攻击。
  • 实际这个问题属于协议的设计缺陷,所以当发现者公布这个问题时,他们没有使用漏洞(Vulnerability)这个词,而是使用了瑕疵(Flaw)。
  • 厂商们对此问题的反应是承认此瑕疵存在,但因为对其修补需要反复的研究论证后才可能实现,因此拖了相当久的时间。Linux似乎挺早就做了相应的修补措施,但MS和Cisco却花了一年多直到今天才真正去修复这个瑕疵。以至于发现者其一还没有熬到这个问题修复就已经驾鹤西去。

其实这个问题的原理并不是很复杂,它起源于针对SYN Flood的解决方案SYN Cookie,对于SYN Flood/SYN Cookie不了解的人可以先补补课,这里有篇不错的文章:http://www.ibm.com/developerworks/cn/linux/l-syncookie/index.html

简单说,SYN Flood是因为攻击者发送虚假的SYN包而本身不做其他任何多余的工作,而被攻击者在接收到SYN后需要进行一系列建立Session、分配内存等资源分配的操作,导致攻击者可以用极小的代价耗尽被攻击者的所有资源,从而达到DoS(Denial of Service)的效果。而SYN Cookie则使服务器在接到SYN后并不立即进行资源分配,而是将SourceIP:SourcePort – DestinationIP:DestinationPort的4元组通过某稍微复杂但又不怎么消耗资源的算法转换得到一个值放入SYN/ACK的ISN中发送出去(称作Cookie)。此时真正的客户会响应这个SYN/ACK并在发回的ACK再次包含这个Cookie,服务器通过验证Cookie和四元组是否对应来判断客户是否合法后,才进行资源的分配工作。伪造SYN的攻击者因为无法收到或者猜出Cookie,无法完成三次握手,也就达成不了DoS的效果了。

而这个TCP/IP协议栈的瑕疵的思路是将SYN Cookie的思路用于攻击,客户端本身不消耗资源,也不维护连接状态,通过在发送的包中加入Cookie来辨识服务器,通过构建特定包使服务器完成三次握手,完成后服务器必然开始分配连接所需要的资源,例如维持连接状态表,分配内存,定时器。在此之后攻击者发送0窗口的ACK通知服务器这一端没有足够的buffer来传输数据,这样服务器就会持续维持此连接,并分配定时器定时来探测攻击者的窗口是否打开。此时攻击者所要做的只是间隔一定时间内继续发送0窗口包告诉服务器继续维持连接,但攻击者本身仍机不需要消耗任何资源。反复此过程多次,服务器中将会有多个持续的连接,虽无数据传输,但服务器本身需要维持这些链接,并还需要不时触发定时器来探测窗口,导致服务器的协议栈资源被大大消耗,到达一定程度后,服务器会因为资源耗尽而停止响应。

问题的发现者撰写了很详细的资料用于描述这个问题,我将个人认为非常不错的一个PPT放到Google Docs上供大家研究,Sockstress是作者开发出来验证这个漏洞可以被利用造成DoS的工具:

作者的主页上还有更多的资料可供研究:http://sockstress.com/

目前这个漏洞在这一年内究竟有多少真正实现DoS的案例还没有统计资料,个人认为应该有不少实际被攻击成功的例子,但只是没有广泛引起关注而已。

对于此问题的修复,MS和Cisco都没有披露补丁的原理,个人猜测是加强对于恶意空置连接的检测,并强制对端如果持续0窗口一段时间后强行关闭连接并释放资源。因为协议RFC本身并未对此作出强制或建议规定,各厂商的协议栈实现可能会有所不同。就像SYN Cookie当初的情况一样,实现本身对RFC的要求有所相违背,但为了保护协议栈本身却不得不做出此类抉择,估计这也是厂商拖了这么久才真正放出补丁的原因之一吧。不知以后的RFC中是否对比会有所补充。

说了这么多东西,其实我个人并不是对这个漏洞的实现细节特别感兴趣,只是刚好最近这个事儿比较热门,而我工作上上维护的某个Service的程序设计行为与这个漏洞的原理有非常大的共通之处。程序本身的行为对协议栈造成了很大的压力,刚好最近流量突增,使得部分服务器过载而开始间歇性罢工,一帮兄弟们在焦头烂额的想办法修,所以实在是想对这个漏洞吐个槽。程序本身的行为设计时就没考虑周全,流量增加到Server撑不住才想办法修,对于运营人员来说,实在不是什么令人爽得起来的事,

最后附送一个SLashdot上对这个事儿讨论的链接:http://it.slashdot.org/story/09/09/08/1839258/Microsoft-Cisco-Finally-Patch-TCP-DoS-Flaw,其实这个站上的人们也挺有娱乐精神的,吵着吵着就跑题,甚至连Windows NT最早某些工具用了BSD协议代码的那些旧八卦也挖出来了。无聊时看看还真提神-_-

Aug 102009
 

周五还一大堆事,临下班被Boss叫去谈话,竟然被说近几个月我的Performance不好,我实在无话可说。于是就郁闷了一整个周末。

谈话结束后时间有点来不及,于是赶紧往上海剧院赶,结果下了地铁走路的那一段时间被突如其来的一阵暴雨给当头浇湿。

到现场后也没怎么跟票贩子谈价钱直接拿了一张就往里冲。在检票的时候就听见里面响起了《Tomorrow》。

现场的人数比我想象的还要多一些,不过还是没有满座。对于像下川这样影响力一般的歌手在中国来看,结果也还算可以。

不过到场的Fans还是比较疯狂,自叹没办法跟这群人拼,所以悄悄退到旁边看。,前排的那群人基本上是站了全场,我挑的位置在前排右侧,要想看完整那也只能陪他们站全场了。不过我发现一个问题就是下川JJ和我一样是个左撇子,左手拿话筒的话做唱歌都是面朝左边,因此从下面来看她基本上是在对着右边唱,而且又经常跑到舞台这半边唱,让我们这半边的人感觉很爽。

现场的音响效果不错,据说比以前的Live都要好(以前的我没有去过)。不过我这次确实听到了Live里很少见到的实时混音特效,也就是唱到需要特殊后期处理的地方会有实时的特效出来,想必是后台混音师的功劳。估计也只有小型Live可能实现,大型的这么搞会累死人。Band的几个人都很个性,Solo也很猛,比较搞笑的是左边那个Bass手是长发且扎马尾辫,男女难辨,还以为是早乙女Alto来客串的呢,最后问别人终于证实是个伪娘。

现场气氛不错,下川状态也不错,一直听完还觉得不够过瘾,对于我来说,在魔都呆了这么久终于找到一次机会来听了一场,也算是满足了。

随身能拍摄的也就是一部破手机,在晚上根本拍不清人,也就没留下什么照片了。还好和谐社的Jimmy大人每次Live必会亲自上阵拍摄全过程,因此也就留下些质量还算不错的视频可以分享了,如下:

 

这只是个开场,后面全系列如果有人感兴趣可以去Jimmy的blog看下川的专题:

http://hexieweekly.blogbus.com/c1756923/

或者直接通过Youku看这个专辑,包含了上一场和这一场的Live:

http://www.youku.com/playlist_show/id_121587.html

 

好了就写这么多了。这几天终于开始慢慢理解一句话的含义:高调做事,低调做人。