Solo Estoy http://opslife.com 人生不过是一场旷日持久却又无法rollback的operation而已 Fri, 22 Jan 2010 08:27:57 +0000 http://wordpress.org/?v=2.9.1 en hourly 1 Ducky 108茶轴机械键盘 http://opslife.com/new-ducky-108-mechanical-keyboard/ http://opslife.com/new-ducky-108-mechanical-keyboard/#comments Fri, 22 Jan 2010 08:16:42 +0000 dawnh http://opslife.com/new-ducky-108-mechanical-keyboard/ 最近感情有些不顺，于是就花钱消遣着玩，其中就包含这个键盘，应该算是目前我入手价钱最贵的一把了。

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

 

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

 

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

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

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

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

 

来看键帽局部：

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

 

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

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

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

2008/12/03 -- 鼠标使用习惯 (7)2008/04/02 -- 好大的林子 (3)2007/08/28 -- 微软与Razer合作的Reclusa键盘个人评测 (1)2006/11/30 -- 新键盘入手，IBM 8815！ (2)2006/08/02 -- 明天超级武器到货了 (0)2006/07/27 -- 没有道的消息—-Intel将以高出AMD23亿美元的价格竟价收购ATI (1)2006/07/04 -- 据说AMD把ATI收了 (0)2006/05/14 -- 找到了解决Elite多媒体键失效的问题 (2)]]> 最近感情有些不顺，于是就花钱消遣着玩，其中就包含这个键盘，应该算是目前我入手价钱最贵的一把了。

最近狂迷机械键盘，啥东西都想拿来玩玩，刚好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年保修，有这样的商家真是造福发烧友^_^

]]> http://opslife.com/new-ducky-108-mechanical-keyboard/feed/ 0 Debian Lenny安装nginx+PHP+MySQL傻瓜手记 http://opslife.com/install-nginx-php-mysql-on-debian-lenny/ http://opslife.com/install-nginx-php-mysql-on-debian-lenny/#comments Mon, 28 Dec 2009 08:05:06 +0000 dawnh http://opslife.com/install-nginx-php-mysql-on-debian-lenny/ 新搞了个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 [...]]]> 新搞了个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迁移过来了，依旧是没什么技术含量。有空再记录。

]]> http://opslife.com/install-nginx-php-mysql-on-debian-lenny/feed/ 10 有关DSR的网络拓扑结构和实现方法 http://opslife.com/dsr-implemention/ http://opslife.com/dsr-implemention/#comments Fri, 18 Sep 2009 13:41:55 +0000 dawnh http://opslife.com/dsr-implemention/ 前两天在delphij老大的blog中看到了一篇《使用DSR模式实现单IP服务冗余》，觉得很有意思，因为这个实现方式与我以往所见到的有些不同，通过关闭ARP响应来解决虚拟IP在负载均衡设备和服务器上可能冲突的问题。随即提问了一下我所熟悉方式的实现是否可行，勤恳的delphij竟然又写了一篇来解释这个问题。不过这篇的思路似乎与我原来的想法有点出入，所以仔细又思考了一下，最终决定还是要完整的阐述一下我的思路。

我虽然见过一些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

首先从数据流角度来看（红色箭头上的标号）：

客户发起到请求： 61.152.X.X:1025 –> 202.96.100.100:80 负载均衡设备通过匹配包，发现目的IP为虚拟IP，根据Load balance算法挑选一台Server，将数据报直接路由到这台Server，不做任何修改（减TTL不算）61.152.X.X:1025 –> 202.96.100.100:80 Server看到数据报的目的IP是虚拟IP，并发现虚拟IP绑定在自己的lo上，认为目的地是自己，OS派发到应用层Web Server处理Request并生成结果，结果数据包变为 202.96.100.100:80 –> 61.152.X.X:1025 数据报发往路由器，路由器看到目的地为客户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才能保证知道出去的包怎么走，我这点还是没有想通。不管怎样，写出来让大家指正吧，至少在写这篇的过程中，我已经将自己以前没考虑到得一些细节补充完整了，对于自己来说，也算是不小的收获。

2009/09/11 -- [...]]]> 前两天在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才能保证知道出去的包怎么走，我这点还是没有想通。不管怎样，写出来让大家指正吧，至少在写这篇的过程中，我已经将自己以前没考虑到得一些细节补充完整了，对于自己来说，也算是不小的收获。

]]> http://opslife.com/dsr-implemention/feed/ 1 诗人手记：库那克的崛起 http://opslife.com/eq2-kunark-guide-1/ http://opslife.com/eq2-kunark-guide-1/#comments Sat, 12 Sep 2009 15:45:06 +0000 dawnh http://opslife.com/eq2-kunark-guide-1/ 最近工作比较郁闷，忙里偷闲又拿起EQ2来玩，其实就是在四处逛大陆看风景，偶尔做几个任务玩玩。结果发现SOE把库那克这块大陆设计的还是蛮有意思的，于是就有了记录点东西的冲动。

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

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

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

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

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

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

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

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

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

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

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

 

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

2006/05/21 -- 再回Mistmoore (0)2007/06/21 -- NDSL一天把玩手记 (3)2006/07/23 -- 又见midi音乐 (4)]]> 最近工作比较郁闷，忙里偷闲又拿起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

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

]]> http://opslife.com/eq2-kunark-guide-1/feed/ 0 TCP/IP协议栈DoS漏洞 http://opslife.com/microsoft-cisco-finally-patch-tcp-dos-flaw/ http://opslife.com/microsoft-cisco-finally-patch-tcp-dos-flaw/#comments Thu, 10 Sep 2009 16:11:49 +0000 dawnh http://opslife.com/microsoft-cisco-finally-patch-tcp-dos-flaw/ 在本月的周二补丁日，微软发布了一组补丁用于修复存在于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协议代码的那些旧八卦也挖出来了。无聊时看看还真提神-_-

2009/09/18 -- 有关DSR的网络拓扑结构和实现方法 (1)2009/06/10 -- 网生异象，必有妖孽出世 (2)2008/12/22 -- Blog访问速度优化 (2)2008/07/23 -- DNS漏洞 (5)2007/11/09 -- 弱智的上海移通 (1)2007/09/05 -- 有一点专业精神好不好?! (3)]]> 在本月的周二补丁日，微软发布了一组补丁用于修复存在于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协议代码的那些旧八卦也挖出来了。无聊时看看还真提神-_-

]]> http://opslife.com/microsoft-cisco-finally-patch-tcp-dos-flaw/feed/ 0 Mikuni 2009上海Live http://opslife.com/mikuni-2009%e4%b8%8a%e6%b5%b7live/ http://opslife.com/mikuni-2009%e4%b8%8a%e6%b5%b7live/#comments Mon, 10 Aug 2009 13:50:00 +0000 dawnh http://opslife.com/mikuni-2009%e4%b8%8a%e6%b5%b7live/ 周五还一大堆事，临下班被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

 

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

2009/03/17 -- 此刻鲜花满天幸福在身边 (4)2009/03/15 -- 纵贯线–4个老男人一场梦 (3)2008/09/21 -- 站在世界的屋顶 (1)2007/04/06 -- 星の扉 (0)2007/01/18 -- 郑智化的新EP—-飞鸟 (0)2006/11/13 -- 梁静茹–暖暖 (1)2006/08/10 -- 幸福 (0)2006/08/06 -- 音乐难得有齐豫 (2)2006/08/02 -- 明天超级武器到货了 (0)2006/07/23 -- 又见midi音乐 (4)]]> 周五还一大堆事，临下班被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

 

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

]]> http://opslife.com/mikuni-2009%e4%b8%8a%e6%b5%b7live/feed/ 3 ChinaJoy09妹子照片 http://opslife.com/chinajoy-09-show-girl/ http://opslife.com/chinajoy-09-show-girl/#comments Mon, 27 Jul 2009 16:07:24 +0000 dawnh http://www.opslife.com/?p=406 ChinaJoy妹子展游戏展年年都去，今年也没落下。只是手头现在没相机，所以今年的照片只有手机拍的了，太多未整理，一股脑丢到Flickr上面去了，刚好试试最新的Flickr插件是否能显示完整。

Next Page › ‹ Previous Page Powered by Flickr Gallery jQuery(document).ready(function(){ jQuery("#gallery-8ee26dc5 .flickr-thumb img").flightbox(); }); var flickr_gallery_8ee26dc5_page = 1; (function($){ $(document).ready(function(){ $("#fg-8ee26dc5-next a, #fg-8ee26dc5-prev a").click(function(e){ if ( $(e.target).parent().is("#fg-8ee26dc5-next") ) { flickr_gallery_8ee26dc5_page++; } else { flickr_gallery_8ee26dc5_page--; } $("#gallery-8ee26dc5 .flickr-thumb").css("visibility", "hidden"); //$("#gallery-8ee26dc5").css("background", "transparent url(http://opslife.com/wp-content/plugins/flickr-gallery/flightbox/images/loading-2.gif) scroll no-repeat center center"); $.post("/feed/", { action: 'flickr-gallery-page', pager: "O:15:\"phpFlickr_pager\":5:{s:6:\"method\";s:26:\"flickr.photosets.getPhotos\";s:4:\"args\";a:4:{s:11:\"photoset_id\";s:17:\"72157621852198360\";s:6:\"extras\";s:6:\",media\";s:8:\"per_page\";i:500;s:4:\"page\";d:1;}s:8:\"per_page\";s:2:\"30\";s:4:\"page\";i:1;s:6:\"_extra\";N;}", page: flickr_gallery_8ee26dc5_page }, function(rsp){ $("#gallery-8ee26dc5").html(rsp.html); $("#gallery-8ee26dc5 .flickr-thumb img").flightbox(); if ( rsp.page == 1 ) { $("#fg-8ee26dc5-prev").hide(); } else { $("#fg-8ee26dc5-prev").show(); } if ( rsp.page == rsp.pages ) { $("#fg-8ee26dc5-next").hide(); } else { $("#fg-8ee26dc5-next").show(); } }, 'json'); return false; }); }); })(jQuery); //-->

或者直接点这个链接看幻灯：http://www.flickr.com/photos/40857285@N03/sets/72157621852198360/show

2008/07/21 [...]]]> ChinaJoy妹子展游戏展年年都去，今年也没落下。只是手头现在没相机，所以今年的照片只有手机拍的了，太多未整理，一股脑丢到Flickr上面去了，刚好试试最新的Flickr插件是否能显示完整。

Powered by Flickr Gallery

或者直接点这个链接看幻灯：http://www.flickr.com/photos/40857285@N03/sets/72157621852198360/show

]]> http://opslife.com/chinajoy-09-show-girl/feed/ 0 大家都有病 http://opslife.com/we-bing/ http://opslife.com/we-bing/#comments Mon, 29 Jun 2009 03:17:15 +0000 dawnh http://opslife.com/we-bing/ 有关部门折腾完Bing又去折腾Google，这样下去真的是永无宁日了。微软Bing这个名字起得够有远见，我都病了你还折腾个什么劲。发的T恤更嚣张，正面我有病，背面你有病，合起来就是大家都有病！

感谢Ricky同学贡献了一个后脑勺，想看帅哥正面请移步Ricky同学的Blog。

2009/06/24 -- 我们还可以默不作声多久 (1)2007/11/06 -- OpenSocial和Android (0)]]> 有关部门折腾完Bing又去折腾Google，这样下去真的是永无宁日了。微软Bing这个名字起得够有远见，我都病了你还折腾个什么劲。发的T恤更嚣张，正面我有病，背面你有病，合起来就是大家都有病！

clip_image001

感谢Ricky同学贡献了一个后脑勺，想看帅哥正面请移步Ricky同学的Blog。

]]> http://opslife.com/we-bing/feed/ 9 我们还可以默不作声多久 http://opslife.com/%e6%88%91%e4%bb%ac%e8%bf%98%e5%8f%af%e4%bb%a5%e9%bb%98%e4%b8%8d%e4%bd%9c%e5%a3%b0%e5%a4%9a%e4%b9%85/ http://opslife.com/%e6%88%91%e4%bb%ac%e8%bf%98%e5%8f%af%e4%bb%a5%e9%bb%98%e4%b8%8d%e4%bd%9c%e5%a3%b0%e5%a4%9a%e4%b9%85/#comments Wed, 24 Jun 2009 15:27:29 +0000 dawnh http://opslife.com/%e6%88%91%e4%bb%ac%e8%bf%98%e5%8f%af%e4%bb%a5%e9%bb%98%e4%b8%8d%e4%bd%9c%e5%a3%b0%e5%a4%9a%e4%b9%85/ 今天无疑是黑暗开始降临的一天。IT人们，没有google你们还能正常工作吗？

2009/06/29 -- 大家都有病 (9)2007/11/06 -- OpenSocial和Android (0)]]> 今天无疑是黑暗开始降临的一天。IT人们，没有google你们还能正常工作吗？

]]> http://opslife.com/%e6%88%91%e4%bb%ac%e8%bf%98%e5%8f%af%e4%bb%a5%e9%bb%98%e4%b8%8d%e4%bd%9c%e5%a3%b0%e5%a4%9a%e4%b9%85/feed/ 1 网生异象，必有妖孽出世 http://opslife.com/weird-behivour-of-china-internet/ http://opslife.com/weird-behivour-of-china-internet/#comments Wed, 10 Jun 2009 13:18:41 +0000 dawnh http://opslife.com/weird-behivour-of-china-internet/ 今天晚上发现了一个极其诡异的现象，以前从大陆到海外的访问，只要一出大陆路由节点，必定平添180-200ms的延迟，然而今天却出现了这样的现象：

从中国到北美竟然只有80ms的延迟， 这是从来没有的状况。谁说海底光缆一定会带来100ms以上的延迟的？这就是铁证，立存此照！

猜想：这两天网络极其不稳定，再加上政府部门的一些动作，怀疑骨干网上某神秘设备在开始新一轮进化，目前只是抽抽疯。

Update: 次日一切如常，果然只是抽抽疯。

2009/09/18 -- 有关DSR的网络拓扑结构和实现方法 (1)2009/09/11 -- TCP/IP协议栈DoS漏洞 (0)2008/12/22 -- Blog访问速度优化 (2)2007/11/09 -- 弱智的上海移通 (1)2007/09/05 -- 有一点专业精神好不好?! (3)]]> 今天晚上发现了一个极其诡异的现象，以前从大陆到海外的访问，只要一出大陆路由节点，必定平添180-200ms的延迟，然而今天却出现了这样的现象：

traceroute

从中国到北美竟然只有80ms的延迟， 这是从来没有的状况。谁说海底光缆一定会带来100ms以上的延迟的？这就是铁证，立存此照！

猜想：这两天网络极其不稳定，再加上政府部门的一些动作，怀疑骨干网上某神秘设备在开始新一轮进化，目前只是抽抽疯。

Update: 次日一切如常，果然只是抽抽疯。

]]> http://opslife.com/weird-behivour-of-china-internet/feed/ 2