依云's Blog

都是《冰雪奇缘》惹的祸，不仅画面美仑美奂，音乐激荡人心，而且还玩多语言版本的主题曲。

而 you-get 竟助纣为虐，把歌词给下回来了！只叹 soimort 没有好人做到底，留一个语义不详的 JSON 让我情何以堪。

好在 muzuiget 才识不凡，有码略释其义，遂如我光影、声音、文字三位一体之愿！

编成代码数十行，只为女王歌一曲：

#!/usr/bin/env python3

import json
import sys

def cmtjson_reader(f):
  data = json.load(f)
  for o in data:
    c = o['c'].split(',')
    m = o['m']
    # see
    # https://github.com/muzuiget/niconvert/blob/master/niconvert/libsite/acfun.py
    start = float(c[0])
    yield start, m

def format_time(t):
  s, ms = divmod(t, 1)
  s = int(s)
  ms = int(ms * 1000)
  m, s = divmod(s, 60)
  h, m = divmod(m, 60)
  return '%d:%02d:%02d,%03d' % (h, m, s, ms)

def crt_writer(f):
  i = 0

  fmt = '%d\n%s --> %s\n%s\n\n'
  try:
    while True:
      t, m = yield
      ts = format_time(t)
      if i != 0:
        f.write(fmt % (i, format_time(old_t), ts, old_m))
      i += 1
      old_t = t
      old_m = m
  except GeneratorExit:
    f.write(fmt % (
      i+1, format_time(t), format_time(t+2), m))

def main():
  w = crt_writer(sys.stdout)
  w.send(None)
  old_d0 = 0
  for d in cmtjson_reader(sys.stdin):
    if d[0] < old_d0:
      break
    w.send(d)
    old_d0 = d[0]

if __name__ == '__main__':
  main()

mplayer 君虽识得 UTF-8 之码，却不通 fontconfig 之术，部分文字沦为了下划线。又及。

稍微了解一点类 UNIX 系统的进程管理的都知道，当一个进程的父进程死亡之后，它就变成了孤儿进程，会由进程号 1 的 init 进程收养，并且在它死亡时由 init 来收尸。但是，自从使用 systemd 来管理用户级服务进程之后，我发现 systemd --user 管理的进程总是在它之下，即使进程已经 fork 了好几次。systemd 是怎么做到的呢？

对一个软件的实现有不懂的想了解当然是读它的源码了。这种东西可没有另外的文档，因为源码本身即文档。当然之前我也 Google 过，没有得到结果。在又一个全新的源码树里寻寻觅觅一两天之后，终于找到了这个：

        if (arg_running_as == SYSTEMD_USER) {
                /* Become reaper of our children */
                if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
                        log_warning("Failed to make us a subreaper: %m");
                        if (errno == EINVAL)
                                log_info("Perhaps the kernel version is too old (< 3.4?)");
                }
        }

原来是通过prctl系统调用实现的。于是去翻 prctl 的 man 手册，得知PR_SET_CHILD_SUBREAPER是 Linux 3.4 加入的新特性。把它设置为非零值，当前进程就会变成 subreaper，会像 1 号进程那样收养孤儿进程了。

当然用 C 写不好玩，于是先用 python-cffi 玩了会儿，最后还是写了个 Python 模块，也是抓住机会练习一下 C 啦。有个 python-prctl 模块，但是它没有包含这个调用。

#include<sys/prctl.h>
#include<Python.h>

static PyObject* subreap(PyObject *self, PyObject *args){
  PyObject* pyreaping;
  int reaping;
  int result;

  if (!PyArg_ParseTuple(args, "O!", &PyBool_Type, &pyreaping))
    return NULL;
  reaping = pyreaping == Py_True;

  Py_BEGIN_ALLOW_THREADS
  result = prctl(PR_SET_CHILD_SUBREAPER, reaping);
  Py_END_ALLOW_THREADS

  if(result != 0){
    return PyErr_SetFromErrno(PyExc_OSError);
  }else{
    Py_RETURN_NONE;
  }
}

static PyMethodDef mysysutil_methods[] = {
  {"subreap", subreap, METH_VARARGS},
  {NULL, NULL}    /* Sentinel */
};

static PyModuleDef mysysutil = {
  PyModuleDef_HEAD_INIT,
  "mysysutil",
  "My system utils",
  -1,
  mysysutil_methods,
  NULL, NULL, NULL, NULL
};

PyMODINIT_FUNC PyInit_mysysutil(void){
  PyObject* m;

  m = PyModule_Create(&mysysutil);
  if(m == NULL)
    return NULL;
  return m;
}

编译之后，

>>> import mysysutil
>>> mysysutil.subreap(True)

然后开子进程，不管它 fork 多少次，都依然会在这个 Python 进程之下啦。

但是，这样子不太好玩呢。如果我登陆之后所有启动的子进程都在一个进程之下不是更有意思么？于是我打上了 Awesome 的主意，因为它支持运行任意的 Lua 代码嘛。于是我又给这个 prctl 调用弄了个 Lua 绑定。最终的版本如下：

#include<lua.h>
#include<lualib.h>
#include<lauxlib.h>

#include<sys/prctl.h>
#include<sys/wait.h>
#include<errno.h>
#include<string.h>
#include<signal.h>

static int l_setsubreap(lua_State * L){
  int reap;
  if(lua_isboolean(L, 1)){
    reap = lua_toboolean(L, 1);
  }else{
    return luaL_argerror(L, 1, "not a boolean");
  }
  if(prctl(PR_SET_CHILD_SUBREAPER, reap) != 0){
    return luaL_error(L, "prctl failed: %s", strerror(errno));
  }
  return 0;
}

static int l_ignore_SIGCHLD(lua_State * L){
  signal(SIGCHLD, SIG_IGN);
  return 0;
}

static int l_reap(lua_State * L){
  int pid, st;
  pid = waitpid(-1, &st, WNOHANG);
  lua_pushinteger(L, st);
  lua_pushinteger(L, pid);
  return 2;
}

static const struct luaL_Reg l_lib[] = {
  {"setsubreap", l_setsubreap},
  {"reap", l_reap},
  {"ignore_SIGCHLD", l_ignore_SIGCHLD},
  {NULL, NULL}
};

int luaopen_clua(lua_State * L){
  lua_newtable(L);
  luaL_setfuncs(L, l_lib, 0);
  return 1;
}

除了调用 prctl 外，还增加了显式忽略 SIGCHLD 信号，以及非阻塞地调用 waitpid 收割单个僵尸进程的函数，因为 Awesome 本身没处理子进程退出，我一不小心弄出了好几个僵尸进程……对了，那个 waitpid 要注意给弄成非阻塞的，不然一不小心就会出问题。

用的时候就是这样子，可以写到rc.lua里，也可以在 awesome-client 里调用：

package.cpath = package.cpath .. ';/home/lilydjwg/scripts/lua/cmod/?.so'
clua = require('clua')
clua.setsubreap(true)
clua.ignore_SIGCHLD()

最终，我的进程树成了这样子：

可以看到，由 Awesome 启动的进程已经全部待在 Awesome 进程树之下了。systemd --user 是由 PAM 启动的，所以不在 Awesome 树下。但是，那些 dbus 的东西和 gconfd-2、at-spi 之类的是怎么回事呀……

>>> python -m this | grep -A1 -F Errors
Errors should never pass silently.
Unless explicitly silenced.

因为要捕获子进程的标准输出、标准错误以及退出状态码，用 callback 写会非常麻烦，因为三者全部完成才能进行下一步操作。而使用 Tornado 的 coroutine 就很方便了，示例如下：

from tornado.gen import coroutine, Task
from tornado.process import Subprocess

@coroutine
def run_cmd(cmd):
    p = Subprocess(
        cmd,
        stdout = Subprocess.STREAM,
        stderr = Subprocess.STREAM,
    )
    out, err, code = yield [Task(p.stdout.read_until_close),
                            Task(p.stderr.read_until_close),
                            Task(p.set_exit_callback)]
    return out, err, code
    # For Python below 3.3, use
    # raise Return((out, err, code))

yield 一个 Task（或者 Future）的列表的话，它们会并发执行，全部执行完毕之后才会返回到这个 yield 位置继续执行。简洁干净。（不过我要吐槽一下为什么必须传列表，传元组就不对……）

于是乎，调用各种外部命令的部分被我由一堆回调改成了 coroutine，除了 yield 关键字有些别扭外，整个代码可读性好多了 :-)

可是后来，发生了这样的一件事：通过日志能看到一个 coroutine 前边的代码执行了，而后边的代码却没有执行，中间也没有 yield 到别的地方去！看上去非常诡异。

恰好前些天刚好看到一很不错的 Python 调试器 pudb。于是去执行中断的地方打断点（import pudb; pu.db），然后单步跟踪。这才发现原来是中间有个语句抛出了异常，然后这个异常被 coroutine「吃掉」了……示例代码如下：

#!/usr/bin/env python3

from tornado.gen import coroutine
from tornado.ioloop import IOLoop

@coroutine
def two():
  print('two entered')
  1 / 0
  print('two leaving')

@coroutine
def one():
  print('one entered')
  yield two()
  print('one leaving')

if __name__ == '__main__':
  one()
  IOLoop.current().start()

结果是：

one entered
two entered

执行从发生异常的那个位置中断了，并且没有任何错误消息被记录。（PS: 要是在 coroutine 里使用 try...except 的话是能抓到它的。）

以「tornado coroutine exception」为关键字找到了这个以及这个。原来 coroutine 的异常是被它返回的那个 Future 对象「吃掉」了。如果是在 Tornado 的 HTTP 服务里（RequestHandler），Tornado 的 web 模块会处理并记录这种异常。然而我是在 web 模块之外使用的，所以得自己来处理了：

#!/usr/bin/env python3

from tornado.gen import coroutine
from tornado.ioloop import IOLoop

@coroutine
def two():
  print('two entered')
  1 / 0
  print('two leaving')

@coroutine
def one():
  print('one entered')
  yield two()
  print('one leaving')

def _future_done(fu):
  fu.result()

if __name__ == '__main__':
  fu = one()
  fu.add_done_callback(_future_done)
  IOLoop.current().start()

这样就能看到有异常发生了：

one entered
two entered
ERROR:concurrent.futures:exception calling callback for <Future at 0x7f286c0bcf90 state=finished raised ZeroDivisionError>
  ...
  File "t.py", line 9, in two
    1 / 0
ZeroDivisionError: division by zero

那个异常的 Traceback 很长很长。没有原生的良好的协程支持的代价吧，不知道 Python 3.4 的 asyncio 里会不会好一些。

2014年8月2日更新：asyncio 在遇到这种情况时会打印错误日志，参见文档。

Requests

这是我第二次用 Requests 了。上一次是个下小说的脚本。我已经不记得自己为什么路过了 httplib2，也路过了 urllib3，却最终买了 Requests 的账。也许是不喜欢 httplib2 那个 Google Code 的首页，也许是厌倦了 urllib* 这种名字。不过我想更多的是开门见山的首页，以及开篇那段让人无法拒绝的介绍：

Requests is an Apache2 Licensed HTTP library, written in Python, for human beings.

Python’s standard urllib2 module provides most of the HTTP capabilities you need, but the API is thoroughly broken. It was built for a different time — and a different web. It requires an enormous amount of work (even method overrides) to perform the simplest of tasks.

Things shouldn’t be this way. Not in Python.

相比之下，中文翻译太差了（而且已经陈旧了）。我在这里再译一个版本：

Requests 是使用 Apache2 许可证的 HTTP 库。用 Python 编写，为人类编写。

Python 标准库中的 urllib2 模块提供了你所需要的大多数 HTTP 功能，但是它的 API 烂出翔来了。它是为另一个时代、另一个互联网所创建的。它需要巨量的工作，甚至包括各种方法覆盖，来完成最简单的任务。

事情不应该是那样的，在 Python 世界里。

Requests 使用的是 urllib3，因此继承了它的所有特性。Requests 支持 HTTP 连接保持和连接池，支持使用 cookie 保持会话，支持文件上传，支持自动确定响应内容的编码，支持国际化的 URL 和 POST 数据自动编码。现代、国际化、人性化。相见恨晚。

Keep-Alive

以前一直以为 Keep-Alive（连接保持）就是节省了 TCP 连接建立的时间。直到渐渐了解了 TCP 慢启动。直到自己偶然间亲自对比了一次。

使用 httrack 默认参数下载 PostgreSQL 9.3 文档，一千多个页面，29 分钟。后来才注意到 httrack 的 Keep-Alive 支持要写参数手动启用。

使用 wget，默认会使用 Keep-Alive 来复用已有连接。几乎同样的页面，只花了 12 分钟。

urllib3 说 它使用 Keep-Alive 单连接从 Google 下载 15 个页面比使用 urllib 每次建立新连接快了一倍。我这里的结果比它的测试还要好呢。

也许，支持 Keep-Alive，是我的 nvchecker 使用 pycurl 要快很多的很重要的一个原因吧。

其它

可惜的是，Requests 不支持 Tornado 的异步调度框架。不过还好，那边我可以用 libcurl，虽然 API 不 Pythonic，至少 cookie 管理和连接管理都很健全。

对了，虾米歌词下载脚本还是在老地方，歌词的获取参考了 you-get 的代码。Requests 的作者 Kenneth Reitz 也有一些其它有意思的东西，包括之前我发现但没意识到是他做的的、用于 HTTP 客户端测试的 Httpbin 网站。

我收取邮件一直用的是 getmail，然而它有个问题：在网络不好的时候会挂在 recv 系统调用上，等好几个小时都有可能。还好我用的 crond 是 dcron，它知道同一个任务，在上一次任务还没执行完时即使时间到了也不应该再次执行，省了我一堆 flock 锁。不过，这样子导致我收不到邮件也不行啊。

以前也研究过一次，看到 getmail 有设置 socket 的超时时间啊，没整明白。最近网络又老是抽风，而且相当严重，导致我得不断地用 htop 去看、去杀没有反应的 getmail 进程。烦了，于是一边阅读 getmail 源码，一边使用 strace 观察，再配合 iptables 这神器，以及 the Silver searcher，终于找到了问题所在。

原来，由于 Python 的 SSL 对非阻塞套接字的支持问题¹²，getmail 在使用 SSL 连接时会强制使用阻塞式的套接字（见代码getmailcore/_pop3ssl.py:39以及getmailcore/_retrieverbases.py:187）。也许 Python 2.7 已经解决了这个问题，但是看上去 getmail 还是比较关心 Python 2.3 和 2.4。不过就算是 SSL 支持不好，调用下alarm不要一直待在那里傻傻地等嘛……也许，大部分 getmail 用户很少遇到足够差的网络？

于是考虑 fetchmail。花了两三天的业余时间终于弄明白我的需求该怎么配置了：

set daemon 300
set logfile ~/etc/log/fetchmail.log

defaults proto pop3 timeout 120 uidl
keep fetchsizelimit 0 mda "procmail -f %T"

poll pop.163.com interval 2
username "username" password "password"

poll pop.gmail.com
username "username" password "password"
ssl

poll pop.qq.com interval 2016 # 7 days
username "username" password "password"

但结果就是，除了 GMail 好一点，我让它「对从现在起所收到的邮件启用 POP」就没太大问题之外，腾讯还好，没几封邮件。网易那边，几百封旧邮件全部拖回来了…………

其实这个问题也还好，毕竟是一次性的。可我看它的日志，又发现，它每次收到 GMail 时，都会打印有多少封邮件已读。难道说，它每次去收邮件时都要列出所有可以用 POP3 收取的邮件，然后挑出没有收取过的？想到如果是这样，以后它每次取邮件时都要先取几千上万条已读邮件列表……这不跟 Google App Engine SDK 操作数据库加 offset 时前边所有数据全部读一遍一样扯淡吗……

于是又回来折腾 getmail。其实就这么一个问题，解决了就好。本来是准备去学学ptrace怎么用的，结果忍不住了，直接拿 Python 调 strace 写了这个：

#!/usr/bin/env python3

'''wait and kill subprocess if it doesn't response (from network)'''

import os
import sys
import select
import tempfile
import subprocess

timeout = 60

def new_group():
  os.setpgrp()

def main(args):
  path = os.path.join('/dev/shm', '_'.join(args).replace('/', '-'))
  if not os.path.exists(path):
    os.mkfifo(path, 0o600)
  pipe = os.open(path, os.O_RDONLY | os.O_NONBLOCK)
  p = subprocess.Popen(['strace', '-o', path, '-e', 'trace=network'] + args, preexec_fn=new_group)

  try:
    while True:
      ret = p.poll()
      if ret is not None:
        return ret
      rs, ws, xs = select.select([pipe], (), (), timeout)
      if not rs:
        print('subprocess met network problem, killing...', file=sys.stderr)
        os.kill(-p.pid, 15)
      else:
        os.read(pipe, 1024)
  except KeyboardInterrupt:
    os.kill(-p.pid, 15)

  return -1

if __name__ == '__main__':
  try:
    import setproctitle
    setproctitle.setproctitle('killhung')
    del setproctitle
  except ImportError:
    pass
  sys.exit(main(sys.argv[1:]))

Python 果然快准狠 ^_^

代码在 winterpy 仓库里也有一份。

这还是我编程时第一次用到进程组呢。没办法，光杀 strace 进程没效果。嗯，还有非阻塞的命名管道。

PS: 去 GMail 设置页看完那个选项的具体名字后离开，结果遇到这个：

你这是让我「确定更改」呢还是「取消取消更改」呢……

ICMP 套接字是两年前 Linux 内核新加入的功能，目的是允许不需要 set-user-id 和CAP_NET_RAW权限的 ping 程序的实现。大家都知道，set-user-id 程序经常成为本地提权的途径。在 Linux 内核加入此功能之前，以安全为目标的 Openwall GNU/*/Linux 实现了除 ping 程序之外的所有程序去 suid 化……这个功能也是由他们提出并加入的。

我并没有在 man 手册中看到关于 ICMP 套接字的信息。关于 ICMP 套接字使用的细节来自于内核邮件列表。

使用 ICMP 套接字的好处：

1. 程序不需要特殊的权限；
2. 内核会帮助搞定一些工作。

坏处是：

1. 基本没有兼容性可讲；
2. 需要调整一个内核参数。

这个内核参数是net.ipv4.ping_group_range，是一对整数，指定了允许使用 ICMP 套接字的组 ID的范围。默认值为1 0，意味着没有人能够使用这个特性。手动修改下：

sudo sysctl -w net.ipv4.ping_group_range='0 10'

当然你可以直接去写/proc/sys/net/ipv4/ping_group_range文件。

如果系统不支持这个特性，在创建套接字的时候会得到「Protocol not supported」错误，而如果没有权限，则会得到「Permission denied」错误。

创建 ICMP 套接字的方法如下：

import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_ICMP)

它的类型和 UDP 套接字一样，是SOCK_DGRAM，不是SOCK_RAW哦。这意味着你不会收到 20 字节的 IP 头。不仅仅如此，使用 ICMP 套接字不需要手工计算校验和，因为内核会重新计算的。ICMP id 也是由内核填的。在接收的时候，内核会只把相应 id 的 ICMP 回应返回给程序，不需要自己或者要求内核过滤了。

所以，要组装一个 ICMP ECHO 请求包头很容易了：

header = struct.pack('bbHHh', 8, 0, 0, 0, seq)

这五项依次是：类型（ECHO_REQUEST）、code（只能为零）、校验和（不需要管）、id（不需要管）、序列号。

接收起来也简单，只要看一下序列号知道是回应自己发的哪个包的就行了。

这里是我的一个很简单的实例。

附注：Mac OS X 在 Linux 之前实现了类似的功能。但是行为可能不太一样。有报告校验和需要自己计算的，也有报告发送正确但是返回报文是乱码的。另，FreeBSD 和 OpenBSD 不支持这个特性。

上篇成功让 mosh 走 UDP 洞，连接上了在 NAT 后边的主机。然而，很多有用的协议都是走 TCP 的，比如能传文件的 ssh、访问我的 MediaWiki 的 HTTP。TCP 洞难打，于是在想，OpenVPN 可以使用 UDP 协议，那么把双方用 OpenVPN 连起来，不是可以想用什么传输层的协议都可以了吗！于是，有了新的脚本。

与 mosh 相比，打洞部分主要的不同有：

1. OpenVPN 的可配置性强，不需要 hack 即可让它绑定到需要的端口。
2. OpenVPN 本身使用证书认证，因此把证书部分保存在客户端，余下的部分（包含双方使用的 IP 地址和端口号）可以通过打好的洞明文发送，不用怕被攻击。所以跑我这个脚本的话，当前工作目录要可写，以便保存双方即将使用的配置文件。
3. OpenVPN 客户端会自动忽略对方发过来它不认识的配置信息，不用想办法避免。
4. OpenVPN 需要 root 权限，因此脚本调用了 sudo，需要及时输入密码。

在实验过程中也遇到了一些坑：

1. Python 里没办法将已连接的 UDP socket「断开连接」，即将一个已经connect的 UDP socket 恢复到初始时可接收任意地址数据的状态。原本以为connect(('0.0.0.0', 0))可以的，结果客户端这边始终收不到服务端发送的 OpenVPN 配置信息。Wireshark 抓包看到内核收到数据后发了 ICMP Port Unreachable 错误之后才明白过来。
2. MTU 的问题。默认值会导致刚开始传输正常，但随后收不到数据的情况。添加mssfix 1400配置解决。（其实这个 OpenVPN man 手册里有写。）
3. 超时的问题。先是没注意到 OpenVPN 服务端说没有配置keepalive的警告，结果连接空闲几分钟之后，「洞」就失效了。加上keepalive 10 60解决。

配置中没有加默认路由，所以连接上之后唯一的效果就是，两个主机分别多出了同一网段的两个 IP 地址，相互间可以进行 TCP 通信了～～

对了，客户端连接时需要一个包含 OpenVPN 证书信息的文件，其格式为：

<ca>
# ca.crt 文件内容
</ca>

<cert>
# crt 文件内容（只需要 BEGIN 和 END 标记的那部分）
</cert>

<key>
# key 文件内容
</key>

PS: 有这个想法后不久，发现 None 已经做过类似的事情了。不过脚本有点多，是使用第三方服务器而不是像我这样手工交换地址的。

又是一篇关于 UDP 打洞的文章。之前写过关于在完全圆锥型（full cone）NAT的文章中如何使用 socat 命令打洞。根据那篇文章里的知识，连接到一个 full cone NAT 后边的 mosh 不成问题。不过，我现在的网络是受限圆锥型（restricted cone）NAT 了呢！

也就是复杂了一些。双方要向中间服务器和对方都发送数据包才可以。另外就是，客户端（mosh-client）这边得使用在打洞期间使用的端口号才行。

打洞流程根据维基百科，双方通过中间服务器（还是我的 udpaddr 啦）交换地址，双方均向得到的地址发送一数据包，然后开始正常通讯。比较麻烦，于是有了这个脚本：

#!/usr/bin/env python3

import socket
import re
import sys
import subprocess

udp_server = ('xmpp.vim-cn.com', 2727)
addr_re = re.compile(r"\('(?P<ip>[^']+)', (?P<port>\d+)(?:, (?P<cport>\d+))?")

def main(server):
  sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
  sock.settimeout(2)
  print('Send message...')
  sock.sendto(b'req from holepunch.py\n', udp_server)
  msg, addr = sock.recvfrom(1024)
  print('Got answer from %s: %s' % (addr, msg))
  m = addr_re.search(msg.decode())
  if not m:
    print("Error: can't parse answer.")
    sys.exit(1)
  m_ip = m.group('ip')
  m_port = int(m.group('port'))
  port = sock.getsockname()[1]
  print('Got my IP and Port: (%r, %s, %s).' % (m_ip, m_port, port))

  msg = input('> Peer address: ')
  m = addr_re.search(msg)
  if not m:
    print("Error: can't parse input.")
    sys.exit(2)
  p_ip = m.group('ip')
  p_port = int(m.group('port'))
  c_port = int(m.group('cport'))

  print('send initial packet and wait for answer...')
  sock.sendto(b'HELO\n', (p_ip, p_port))
  try:
    msg = sock.recvfrom(1024)
    print('Received:', msg)
  except socket.timeout:
    print("Timed out (it's normal).")

  if server:
    sock.close()
    print('Starting mosh server...')
    msg = subprocess.check_output(['mosh-server', 'new', '-p', str(port)])
    secret = msg.split()[3].decode()
    print('Connect with:\nMOSH_KEY=%s MOSH_CPORT=%s mosh-client %s %s' % (secret, c_port, m_ip, m_port))
  else:
    print('done.')

if __name__ == '__main__':
  server = len(sys.argv) == 2 and sys.argv[1] == '-s'
  main(server)

如果 mosh 服务器端位于受限 NAT 后，还需要给 mosh-client 打个（我随手写的很 dirty 的）补丁以便指定客户端使用的 UDP 端口号：

diff --git a/src/network/network.cc b/src/network/network.cc
index 2f4e0bf..718f6c5 100644
--- a/src/network/network.cc
+++ b/src/network/network.cc
@@ -176,6 +176,11 @@ Connection::Socket::Socket()
     perror( "setsockopt( IP_RECVTOS )" );
   }
 #endif
+
+  if ( getenv("MOSH_CPORT") ) {
+    int port = atoi(getenv("MOSH_CPORT"));
+    try_bind( _fd, INADDR_ANY, port, port);
+  }
 }

 void Connection::setup( void )

然后，连接流程如下：

1. mosh 服务端运行holepunch.py -s命令，客户端运行holepunch.py；
2. 双方看到自己的地址信息（依次是IP, 外网端口, 本地端口）后，复制并发送给对方；
3. 双方输入对方的地址。为了节省时间（mosh-server 只会等一分钟，NAT 上的端口映射也是有时效的），只要输入的一行内包含上述地址信息的文本即可，前后可以有不小心复制过来的多余字符；
4. 服务端将得到一行包含 mosh 的密钥的命令。将此命令发送对客户端；客户端运行此命令连接。如果 mosh-client 的名字不是标准名字，需要自行修改；
5. 一切顺利的话就连接上啦！

mosh 服务端输出示例：

>>> holepunch.py -s
Send message...
Got answer from ('202.133.113.62', 2727): b"Your address is ('180.109.80.47', 3169)\n"
Got my IP and Port: ('180.109.80.47', 3169, 8127).
> Peer address:  Port: ('222.95.148.73', 5223, 55473). 
send initial packet and wait for answer...
Timed out (it's normal).
Starting mosh server...

mosh-server (mosh 1.2.4)
Copyright 2012 Keith Winstein <mosh-devel@mit.edu>
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[mosh-server detached, pid = 5202]
Connect with:
MOSH_KEY=1apguNqtfN/K4JSvllnJxA MOSH_CPORT=55473 mosh-client 222.95.148.73 5223

mosh 客户端输出示例：

>>> holepunch.py
Send message...
Got answer from ('202.133.113.62', 2727): b"Your address is ('222.95.148.73', 5223)\n"
Got my IP and Port: ('222.95.148.73', 5223, 55473).
> Peer address: rt: ('180.109.80.47', 3169, 8127)
send initial packet and wait for answer...
Timed out (it's normal).
done.

2013年10月20日更新：想要通过打出来的 UDP 洞进行 TCP 通信吗？参见文章通过 OpenVPN 让 TCP 使用 UDP 洞。

一些天前，根据加州旅客的文章《kindle paperwhite越狱更换屏保》获得了自己的 Kindle Paperwhite 的 root 权限，就开始想着给它编译些东西了。恰巧小虾也在玩交叉编译，而且是 Python，于是自己也照着编译。

交叉编译 Zsh

交叉编译 Python 比编译 zsh 要难不少，所以，先简要说一下 zsh 等能够「无障碍交叉编译」的使用 Autotools 构建系统的软件是怎么编译的。

首先，弄清楚几个概念。「host」是指程序要运行的目标平台，「build」是指编译该程序的平台，而在编译编译器时会遇到的「target」则指的是其生成的文件所运行的平台。（参见CLFS 构建手册）

其次，得找个交叉编译器。有些发行版可能仓库里就有。但是 Arch 没有，所以我还是用的 zshaolin 的这个工具链。下回来解压了，把它的bin目录加到$PATH里。Zsh 里可以这么写：

path+=/path/to/arm-dyne-gcc_64bit-x-arm7a-21jan12/bin

然后就可以去 zsh 源码目录下开始编译啦。还是那三步，只是参数有些不一样而已：

mkdir build-arm && cd build-arm
../configure --host=arm-dyne-linux-gnueabi --enable-multibyte --enable-pcre --with-term-lib='ncursesw'
make
make DESTDIR=/kindle/software/zsh-5.0.2 install

且慢！我指定了--enable-pcre，却没有去检查自己是否有这个库。可能是 bug 吧，zsh 的 configure 脚本并没有检测到我其实没有 pcre 的 ARM 版库文件，于是它接着在很多检测过程中加入了-lpcre，导致检测结果与实际不符（比如它认为我的目标系统上没有setpgid()函数）。编译安装 pcre 到工具链的 sysroot 下后再次编译通过。

再编译一些需要的库

所以你看，使用 Autotools 构建系统的软件交叉编译起来挺容易的，加上需要的--host参数就好了。其它诸如 file、ncurses、readline 也是这么编译安装的。下边说说那些比较「个性」的软件的编译参数。它们基本上都必须在源码目录编译。

首先是 zlib：

CHOST=arm-dyne-linux-gnueabi ./configure
make && make DESTDIR=/kindle/software/zlib-1.2.8 install

TLS/SSL 很有用！OpenSSL：

CC=arm-dyne-linux-gnueabi-gcc LD=arm-dyne-linux-gnueabi-ld AR=arm-dyne-linux-gnueabi-ar RANLIB=arm-dyne-linux-gnueabi-ranlib ./Configure shared linux-armv4
make
make INSTALL_PREFIX=/ldata/media/temp/kindle/software/openssl-1.0.1e install_sw

注意最后不是make install哦，那个会安装一堆不需要的文档的。

对了，我好像忘记说了，以上软件make install之后的操作：

1. 删除文档，比如 rm -rf share/man
2. 复制到工具链的 sysroot 下，命令：

   tar c . | tar xv -C /path/to/arm-dyne-gcc_64bit-x-arm7a-21jan12/arm-dyne-linux-gnueabi/sysroot
   

3. 给二进制文件们减肥啦（以下命令需要 zsh；非 zsher 请自行使用合适的 find 命令代替）：

arm-dyne-linux-gnueabi-strip **/*(*)

另外再附上 ncurses 的配置命令好了：

../configure --host=arm-dyne-linux-gnueabi --with-shared --with-normal --without-debug --without-ada --enable-widec --enable-pc-files --prefix=/usr/local

是的，我把软件都安装到/usr/local下了。在编译 Python 3.3 时的事实表明，这是给自己找麻烦……

编译 Python 啦

好了，准备工具完毕，我们来真正开始编译 Python 啦！

按照小虾的文章，首先修改Modules/Setup.dist文件，把需要的模块去掉注释。一定要把最后的xxsubtype给注释掉！因为它只是很无聊的示例模块……

除了要安装模块对应的程序库外（比如要 curses 模块就得先安装 ncurses 等），还要注意一点：如果开启 readline 支持的话，把它后边的-ltermcap删掉！

开始配置了：

mkdir build-arm && cd build-arm
echo ac_cv_file__dev_ptmx=yes > config.site
echo ac_cv_file__dev_ptc=no >> config.site
export CONFIG_SITE=config.site
../configure --host=arm-dyne-linux-gnueabi --build=arm --enable-shared --disable-ipv6

根据实际 ssh 过去的结果，我的 Kindle 有/dev/ptmx但是没有/dev/ptc，所以往config.site文件里写上那么两句。没办法，交叉编译时脚本不知道目标系统里是否有这两个设备文件。当然，你都设置成no也是没什么问题的。

--build=arm这系统纯粹是 Python 的这个配置脚本要求的，和之前所说的常见使用方法不一样的。IPv6 支持需要的某函数配置脚本找不到，那就禁用掉好了。

配置完成，开始 make？

根据所开启的模块支持不同，在编译过程中很有可能地，你会遇到Parser/pgen无法执行的问题。它被编译成 ARM 版了，当然无法执行了！解决方案是这样子的：

修改pyconfig.h中SIZEOF_LONG为正确值（比如 64 位 x86 下是8）。如果已经是对的就不要动了。然后重新生成个本地可运行的pgen：

rm Parser/*
make CC=gcc Parser/pgen

接着把pyconfig.h改回去。然后，为了避免pgen被重建，我们让 make 认为pyconfig.h没有被修改过：

touch -t 200001010000 pyconfig.h

继续编译！

如果又出来了架构不对的情况，删除刚刚编译pgen时编译出来的目标文件吧：

rm Parser/*.o
touch -t 210001010000 Parser/pgen

touch pgen 的原因是，不能让 make 又把它编译成本地不能运行的 ARM 架构的了。

架构不对的目标文件可能还有一些，按照错误提示删掉就好了。

最后，要生成 Python 的可执行文件啦！很可能地，你会遇到类似这个的错误（我自己这里的错误信息已经没啦，下边这个由加州旅客提供）：

libpython3.3m.a(timemodule.o)：在函数‘py_process_time’中：
/home/jiazhoulvke/Python-3.3.2/./Modules/timemodule.c:1076：对‘clock_gettime’未定义的引用
/home/jiazhoulvke/Python-3.3.2/./Modules/timemodule.c:1082：对‘clock_getres’未定义的引用

查阅clock_getres的 man 文档得知：

Link with -lrt (only for glibc versions before 2.17).

于是，复制 make 最后执行的那条链接命令，在后边加上lrt吧。如果crypt没有定义的话，还要加上-lcrypt。

终于可以安装啦

接下来，当然是把程序安装到 Kindle 上啦！首先执行个make DESTDIR=xxx install安装到某个目录，然后进去清理下吧：

arm-dyne-linux-gnueabi-strip **/*(*)
cd lib/python3.3
# 删除所有你不想要的模块，比如测试代码（`test`，不是`unitest`哦）、tk/idle，
# 还有 distutils 里一堆乱七八糟的东东

# 删除 Python 源码和 pyc 文件，我们只要 pyo 文件就好啦=w=
rm **/*.pyc?
# 在 zip 文件里 Python 可不认 __pycache__……
perl-rename 's=__pycache__/([^.]+).cpython-33.pyo$=\1.pyo=' **/*.pyo
rmdir **/*(/)
zip -9r ../python33.zip .

然后，把生成的python33.zip放到 Kindle 的/usr/local/lib目录下，Python 二进制文件也放到对应的位置。记住，库文件要使用 tar 而非 scp 来传输！像这样子：

tar c libz.so* | ssh kindle tar xv -C /usr/local/lib

其实不少库 Kindle 上已经有了，比如这里的 zlib。不过很奇怪，使用系统自带的 zlib 运行 Python 时会报如下警告：

python3: /usr/lib/libz.so.1: no version information available (required by /usr/local/lib/libpython3.3m.so.1.0)

另一个我发现无关紧要的警告是让你设置PYTHONHOME环境变量的：

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]

其实不设置也是没关系的。

哦对了，现在我们的 Python 应该还跑不起来的吧！有可能缺少一点库文件的哦！把之前编译生成的对应的库文件全部拿tar扔到/usr/local/lib下吧。再说一遍，使用scp传输的话软链接会变成其指向的文件，浪费掉 Kindle 上宝贵的存储空间！

库文件扔进去之后，首先确认/etc/ld.so.conf里已经包含了/usr/local/lib，然后执行下ldconfig。

终于，我们的 Python 在 Kindle 上跑起来啦！

后记，及下载链接

这个是我编译的 Python 的文件大小：

-rwxr-xr-x 1 root root 5.4K Sep 15 00:15 /usr/local/bin/python3.3
-r-xr-xr-x 1 root root 4.0M Sep 15 00:15 /usr/local/lib/libpython3.3m.so.1.0
-rw-r–r– 1 root root 2.2M Sep 15 00:43 /usr/local/lib/python33.zip

主要支持特性有：SSL、readline、ncurese、zlib、中日编码集、Unicode 数据库等。最后再放百度网盘下载链接（包括好些东东哦）。

最后我要说一句，Kindle 才是真正的 Linux 啊！编译起来如此方便！还各种常见库（包括 glibc、zlib、OpenSSL、GTK 2）都有。想之前给 Android 编译点东西得砍掉多少特性啊！又有多少软件死活编译不成功 :-(

PS: Kindle 虽然也用 Java 的，但是它有 X Window，还有 GTK 2 以及 Awesome 窗口管理器哦～可惜它的 Awesome 没开启 D-Bus 支持。

更新：lxml

今天（2013年9月17日），成功编译了 Python 最著名的 XML 处理模块——lxml。编译方法是，指定CC环境变量，复制python3 setup.py build时出错的那两条编译命令并修改，编译出来目标文件存起来。将CC指定为自己的脚本来「生成」它想要的文件。链接时手动改命令链好就行。

因为有 .so 文件，lxml 不能打成 zip 包。因此我直接将*.pyc和*.pyo文件连同.so文件一同复制到 Kindle 的/usr/local/lib/python3.3/lxml下。由于版本不匹配，需要把libxml2.so.2.9.1文件也传到 Kindle 中去，覆盖了 Kindle 中旧版本的库文件，希望不会有问题。

Vim 7.4 刚刚发布了！（怎么没有 Vim 7.4c d e f 了呢=w=）

主要新特性如下：

1. 新的更快的正则引擎，与旧的同时存在，并且可以指定使用哪个。
2. 更 pythonic 的 Python 接口。
3. 位操作函数。
4. luaeval() 函数。
5. 其它新增函数、部分函数功能增强。
6. 自动命令部分添加了InsertCharPre、CompleteDone、QuitPre、TextChanged和TextChangedI事件。
7. rxvt-unicode 终端的鼠标支持。
8. 等等。

Python 部分的改进主要如下：

1. vim.bindeval函数可以获得 Vim 的字典、列表或者函数对象。
2. buffer 和 window 对象以及vim模块添加了vars属性，用于存取局部于缓冲区、窗口以及全局的 Vim 变量。
3. 可以从{rtp}/python2、{rtp}/python3、{rtp}/python导入模块。
4. 添加了新的 tabpage 对象用于操作标签页。
5. Vim 错误会自动转成 Python 异常。
6. vim.buffers改用缓冲区作为键，因此可以方便地从缓冲区号找到对应的 buffer 对象。
7. 添加了类似其它解释器接口的:pydo和py3do命令。
8. 添加了 Vim 函数pyeval()和py3eval()。其返回值会自动转换成 Vim 对象。
9. 所有接受str对象的接口，现在能够同时接受unicode（Python 2）或者bytes（Python 3）对象。
10. window 对象添加了 .col 和 .row 属性。
11. 添加和修正了一些 Vim 添加对象的dir()方法。
12. vim.vvars用于访问v:开头的特殊变量。
13. vim.options以及 buffer 和 window 对象的options属于用于像字典那样存取 Vim 的全局或者局部选项。
14. vim.strwidth函数，功能和 Vim 内建函数strwidth一致。
15. 可能有更多没有写到发行说明中的内容。

详情请:help version-7.4。

附：我编译的 Windows 32 位和 64 位版本： http://lilydjwg.is-programmer.com/pages/19540.html#win-vim

我维护的 Arch Linux lilydjwg 仓库也有 64 位的 gvim 和 vim。

2014年12月2日更新：现在我打包的 Vim 在 Arch Linux 中文社区源里了，名字叫 vim-runtime-lily、gvim-lily 以及 vim-lily。