1
15
2014
12

被 Tornado coroutine 对异常的异常支持坑了

>>> 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 在遇到这种情况时会打印错误日志,参见文档

Category: python | Tags: python tornado coroutine
1
11
2014
5

使用 inspect.lua 查找 Awesome 配置引入的内存泄漏

所谓「相见恨晚」,说的就是我第一次看到 inspect.lua 的感觉啊!Lua 这个超小型主打嵌入的语言,连 Readline 都要第三方库来支持,自然是没 Python 那样的补全功能了。不仅如此,连一个展示其数据结构的函数都没有。包括自己在内,不少人零零散散写过各种打印 Lua 表的函数,但像 inspect.lua 这样子优秀的还是第一次见到。

基本用法啊示例什么的不说了,直接在对象上调用 inspect 函数就可以得到一个(可能是巨大的但一定不会是无限的)字符串表示,递归的结构会依据其类型和一个序号来辨识。

既得此神器,自然要用来看看我那自从升级到 3.5 版本之后就一直在慢慢泄漏内存的 Awesome 了:

>>> awesome-client
awesome#inspect = dofile('tmpfs/inspect.lua')
awesome#f = io.open('tmpfs/output.lua', 'w')
awesome#f:write(inspect(_G))
awesome#f:close()
awesome#f = nil

然后就是慢慢察看了。我注意到了这么一个变量:

  raise_on_click = {
    [<client 13>] = true,
    [<client 12>] = true,
    [<client 14>] = true,
    [<client 15>] = true,
    [<client 16>] = true,
    [<client 17>] = true,
    [<client 18>] = true,
    [<client 19>] = true,
    [<client 20>] = true,
    [<client 21>] = true,
    ...
  }

这个变量由来已久,好像现在已经偏离了当初的设计目的了……不管它,反正呢,它里边保留了所有 Awesome 正管理的客户端对象,有 100 多个呢。可是,我怎么会同时有那么多窗口呢,明明才十几个啊?

检查一下配置文件,终于知道问题在哪里了:

diff --git a/rc.lua b/rc.lua
index ad06296..c1422bd 100644
--- a/rc.lua
+++ b/rc.lua
@@ -991,7 +991,7 @@ end)
 client.connect_signal("focus", function(c) c.border_color = beautiful.border_focus end)
 client.connect_signal("unfocus", function(c) c.border_color = beautiful.border_normal end)

-client.add_signal("unmanage", function(c)
+client.connect_signal("unmanage", function(c)
     raise_on_click[c] = nil
 end)
 -- }}}

add_signal是 Awesome 3.4 的用法,3.5 应该用connect_signal才对。这里的client.add_signal是 Awesome 自己用的另外一个意思的函数……

Category: 编程 | Tags: Lua awesome
12
29
2013
30

rsync+btrfs+dm-crypt 备份整个系统

生成目录!

目标:增量式备份整个系统

怎么做到增量呢?rsync + btrfs 快照。其实只用 rsync 也是可以做到增量式的1,但是支持子卷的 btrfs 可以做得更好:

  1. 快速删除旧的备份
  2. 更简单的备份逻辑
  3. 子卷可以设置成只读(这是个很重要的优点哦~)
  4. btrfs 支持压缩。系统里有好多文本文件的,遇到压缩效果不好的文件 btrfs 会自动放弃压缩

为什么要备份整个系统呢?——因为配置一个高度定制化的系统麻烦啊,只备份部分数据的话还可能漏掉需要的文件。另一个优点是可以直接启动到某个备份

备份了整个系统,包括各种公开或者隐私的数据,一堆 cookies 和帐号配置,邮件和聊天记录等。难道就不需要加密一下下吗?于是,在 btrfs 之下再加一层 dm-crypt 加密。

介绍完毕,下边进入正题。

准备工作

首先,需要一个足够新的 Linux 内核,因为 btrfs 还是「实验特性」,每个版本都会有大量改进。如果用比较旧的内核就有可能出事。我用的是 3.12.6 版本。其次,安装 rsync 和 cryptsetup。

当然还要准备硬件:一块希捷 BackupPlus 1T USB 3.0 移动硬盘,以及一枚Express Card 34mm 转 USB 3.0 扩展卡,因为我的笔记本没有 3.0 的接口。注意使用 USB 3.0 扩展卡,内核需要载入 pciehp 模块,否则会出现不能识别 3.0 的设备或者后续接上去的设备的情况。Arch 官方内核将这个模块直接编译进内核了,而我自己编译的很不幸没有,只好重新编译了下内核。

PS: 这俩家伙一起配合工作,写入峰值能达到 110MiB/s,比我笔记本自身的硬盘还要快。

然后是分区、格式化。我使用了 GPT 分区表。为了安装 grub 以便启动,最好在开头分配 2M 空间给 grub 使用,不然会很麻烦2。记得给这个分区 bios_grub 标志(GParted「管理标志」里勾上即可)。下一个分区是 ext4 格式的启动分区。我会在这里放一个 Arch Linux Live 系统用于维护任务,以及用于启动到备份的内核和 initramfs。因为备份的分区会被加密,所以必须把内核和 initramfs 放在另外的地方。接下来的一个分区放加密过的备份数据用的。

像这样初始化加密分区:

cryptsetup luksFormat /dev/sdc3

密码要长,但也一定要记住密码,因为除了穷举外是没有办法恢复的。

初始化完毕之后就可以使用密码打开该设备了:

cryptsetup open /dev/sdc3 lilybackup

最后的参数是一个名字,它会是解密后的设备在 /dev/mapper 下的文件名。

如果一切完毕,要记得(在卸载文件系统之后)关闭该设备:

cryptsetup luksClose lilybackup

dm-crypt 是块设备级的加密。我们还要在其上建立文件系统:

mkfs.btrfs /dev/mapper/lilybackup

然后挂载之,并建立相应的目录和子卷结构。比如我的:

* backup (dir)
  * home (dir)
    * current (subvol, rw)
    * 20131016_1423 (subvol, ro)
    * 20131116_2012 (subvol, ro)
    * ...
  * root (dir)
    * current (subvol, rw)
    * 20131016_1821 (subvol, ro)
    * 20131116_2128 (subvol, ro)
    * ...
* run, for boot up directly, with edited /etc/fstab (dir)
  * home (dir)
    * 20131116 (subvol, rw)
    * ...
  * root (dir)
    * 20131116 (subvol, rw)
    * ...
* etc, store information and scripts (subvol, rw)

我把备份数据放到 backup 目录下,/ 和主目录 /home/lilydjwg 分开备份的。每个备份是使用日期和时间命名的快照子卷。除了用于每次同步的 current 目录外其它的子卷都是只读的,以免被意外修改。在 run 目录下是用于直接运行的,可写。这些可以按需建立。

开始备份

这是我备份 / 使用的脚本。是一个 zsh 脚本,这样可以避免 bash 中特殊字符可能带来的问题,虽然 bash 有 shellcheck 可以静态分析出可能有问题的地方。

这个脚本带两到三个参数。第一个是 / 的位置,因为我一般会直接从运行的系统执行备份,但也有可能使用另外的维护系统(比如系统滚挂掉的时候)。第三个参数是用于确认操作的。不加它的话会以 --dry-run 参数来运行 rsync。rsync 很复杂,所以最好先演习一遍以避免不小心手抖了做错事 =w=

为了避免日后对照着 rsync 手册来揣摸每个单字母选项的意义,我在这里全部使用了选项的完整形式。反正我是 zsh 用户,那么长的命令中大部分字符都是 zsh 给我补全出来的 =w=

#!/bin/zsh -e

cd $(dirname $0)

if [[ $# -lt 2 || $# -gt 3 ]]; then
  echo "usage: $0 SRC_DIR DEST_DIR [-w]"
  exit 1
fi

src=$1
dest=$2
doit=$3

if [[ $doit == -w ]]; then
  dry=
else
  dry='-n'
fi

rsync --archive --one-file-system --inplace --hard-links \
  --human-readable --numeric-ids --delete --delete-excluded \
  --acls --xattrs --sparse \
  --itemize-changes --verbose --progress \
  --exclude='*~' --exclude=__pycache__ \
  --exclude-from=root.exclude \
  $src $dest $dry

比较重要的几个 rsync 选项:

--archive
我们要备份,所以请保留所有信息
--one-file-system
只备份这个文件系统的内容,不要跑到 /sys 啊 /proc 啊 /dev 啊 /tmp 这类目录里去了。这也省得自己手动排除
--numeric-ids
文件的所有者信息使用数字而不要解析成用户名/组名。避免在跨系统使用时出差错
--exclude-from=root.exclude
root.exclude文件中读取额外的排除列表
--acls --xattrs
保留文件 ACL 和扩展属性

我发现的 / 里需要排除的目录如下:

/var/cache/*/*
/var/tmp/
/var/abs/local/
/var/lib/mongodb/journal/

其中第一项写成那样是因为,我要保留 /var/cache 下的一级目录。

主目录的备份是类似的过程,只是更加复杂罢了。当我写我的主目录的备份脚本的时候,深切地体会到有圣人说过的一句话——过早的优化是万恶之源。因为我使用 eCryptfs 加密主目录时为了避免可以公开的文件被加密造成性能损失,做了一系列的软链接。它们一直在给我带来各种小麻烦和不爽……

注意这些脚本要以 root 的身份运行。待所有备份脚本跑完之后,对那个 current 子卷做一个只读快照就好了:

sudo btrfs subvolume snapshot -r current $(date +'%Y%m%d_%H%M')

下次要更新备份时是一样的步骤:跑同步脚本,创建新快照。第一次同步会比较慢,跑了一个多小时吧。后边的增量备份就比较快了,十几分钟就好。

从备份启动

要启动,首先把 grub 装过去。把 Arch Linux live 系统的配置写好,当然还有启动备份系统的配置,如下:

search --no-floppy --fs-uuid --set=root 090dcc64-2b6d-421c-8ef6-2ab3321aec62

menuentry "Archlinux-2013.12.01-dual.iso (x86_64)" {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod ext2

    set isofile="/images/archlinux-2013.12.01-dual.iso"
    echo "Setup loop device..."
    loopback loop $isofile
    echo "Loading kernel..."
    linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201312 img_dev=/dev/disk/by-label/lilyboot img_loop=$isofile earlymodules=loop
    echo "Loading initrd..."
    initrd (loop)/arch/boot/x86_64/archiso.img
}

menuentry "Archlinux-2013.12.01-dual.iso (i686)" {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod ext2

    set isofile="/images/archlinux-2013.12.01-dual.iso"
    echo "Setup loop device..."
    loopback loop $isofile
    echo "Loading kernel..."
    linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201312 img_dev=/dev/disk/by-label/lilyboot img_loop=$isofile earlymodules=loop
    echo "Loading initrd..."
    initrd (loop)/arch/boot/i686/archiso.img
}

set ver=3.12.6
menuentry "Arch Linux $ver backup" {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod ext2

    echo    'Loading Linux kernel ...'
    linux   /boot/vmlinuz-linux-lily-$ver root=/dev/mapper/lilybackup rw cryptdevice=/dev/disk/by-uuid/815d01ea-6390-460f-8c82-84c9e9497423:lilybackup rootflags=compress=lzo,subvolid=0 break=postmount
    echo    'Loading initramfs...'
    initrd  /boot/initramfs-$ver-backup.img
}

各个设备的卷标、UUID 和文件路径自己调整。最后一项需要的文件在后边准备,先介绍一下几个参数:

root
根分区所在的设备。是解密后的设备路径或者用 UUID 也可以。不过没关系的,这里不会有冲突的
cryptdevice
如果使用密码(而不是密钥文件)加密的话,这里是冒号分隔的两个参数:你的加密设备是哪个文件,以及它解密之后叫什么名字。
rootflags
这个是给我们的 btrfs 用的。指定要启用 lzo 算法压缩,使用根子卷。实际上根子卷里不是 Linux 系统的根。这里我只是让脚本把它挂载到/new_root上而已,脚本会因为找不到/sbin/init而进入一个 shell 的
break=postmount
即使根没有问题,也请在挂载好它之后给我一个 shell,我可能需要做一些调整

内核很简单,直接 cp 过去就好了。initramfs 要另外生成。这是我用来生成的 mkinitcpio.conf.crypt 文件:

MODULES="btrfs"
BINARIES="/usr/bin/btrfs"
FILES=""
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck shutdown"
COMPRESSION="xz"

重要的地方:内核模块 btrfs 一定是要的,另外我还需要 btrfs 程序来操作子卷。在 HOOKS 数组的 filesystems 前添加了 encrypt,用于在启动时询问密码并解码根分区。

我还准备添加 vi 程序来着,但是它说终端类型不认识,还说 /var/tmp 目录不存在。于是索性把自己静态链接的 vim 扔到内核一块去了。Vim 内建常见终端类型的数据,不那么挑剔的。zsh 所需要的文件太多,也放弃了。

然后使用 mkinitcpio 命令生成 initramfs 镜像:

sudo mkinitcpio -c mkinitcpio.conf.crypt -g initramfs-backup.img

然后把生成的文件复制到启动分区的相应路径下。

注意:如果你在 Arch Linux live 系统中为另外的内核生成该 initramfs,要指定内核和内核模块路径的根。一定不要将内核模块所在的目录软链接到/lib/modules,那样 mkinitcpio 不会添加任何块设备的内核模块的。我使用的命令如下:

mkinitcpio --kernel /run/archiso/img_dev/boot/vmlinuz-linux-lily-3.12.6 -r /mnt/backup/root/20131227_2044 --config mkinitcpio.conf -g /run/archiso/img_dev/boot/initramfs-3.12.6-backup.img

文件准备完毕,就可以启动过去了。注意我没有在备份分区的 run 目录下建立子卷,因为我准备进入 initramfs 之后再建立它们。

PS: 因为 BIOS 不支持,所以必须从 USB 2.0 来启动。在 Linux 内核启动的时候,可以将移动硬盘接到 USB 3.0 扩展卡上。具体时机是,initramfs 载入完毕,内核开始打印日志的时候。

进入备份系统

启动之后,会进入 initramfs 的 shell。在这个没有任务管理的 ash 中,使用 btrfs 命令在 /new_root/run 目录下建立新的子卷,注意不要加 -r 这个表示只读的选项了:

btrfs subvolume snapshot ../backup/root/20131016_1423 root/20131016
btrfs subvolume snapshot ../backup/home/20131016_1423 home/20131016

因为文件系统树的挂载结构变了,所以得拿准备好的 vim(或者 vi,如果你没准备 vim 的话)去编辑 root/20131016/etc/fstab 文件,将那些不会成功的挂载项都去掉,添加新的正确的项。PS: 如果使用 vim 的话,记得进去先set nocp一下,不然会是兼容模式,和 vi 一样只能撒消一步的。

/dev/mapper/lilybackup  /       btrfs   rw,relatime,compress=lzo,subvol=run/root/xxx     0 0
/dev/mapper/lilybackup  /home/lilydjwg  btrfs   rw,relatime,compress=lzo,subvol=run/home/xxx     0 0

然后 cd /,卸载 /new_root 并重新以子卷挂载之:

cd /
umount /new_root
mount -o compress=lzo,subvol=run/root/20131016 /dev/mapper/lilybackup /new_root

如果是因为找不到 /sbin/init 而进来这个 shell 的,那么就tail /init,最后那行是需要执行的命令(当然有些修改):

exec env -i "TERM=$TERM" /usr/bin/switch_root /new_root /sbin/init

如果是因为break=postmount参数而进来的,直接按Ctrl-D退出 shell 即可。

启动会继续进行,systemd 启动了,各种服务陆续启动中~~

如果很不幸地,忘记修改/etc/fstab了,或者有错,那么 systemd 会毫不留情地「Welcome to emergency shell」。不过现在更正也为时未晚。在编辑完 fstab 之后,要先执行下systemctl daemon-reload再退出那个 emergency shell。

接下来应该能一路顺利地到达指定时间的系统啦 =w=

时间机器打造完成哦耶~~

参考资料

Category: Linux | Tags: linux grub grub2 btrfs Arch Linux
12
14
2013
12

豌豆荚:黑水洗不白应用

豌豆荚说火狐更新了,但是签名变了,需要谨慎升级:

豌豆荚:火狐有更新

于是,本来应试是这样子的火狐:

火狐国际版:热门网站 火狐国际版:书签

变成了这个样子,桌面还多了个奇怪的图标:

火狐中国版:热门网站 火狐中国版:书签 火狐中国版:「二维码」图标

我看到这堆乱七八糟的网站之后,只好自行去 Mozilla 的 FTP 站点下载国际版火狐,并验证了一下签名:

29674 ~tmp/firefox
>>> wget ftp://ftp.mozilla.org/pub/mozilla.org/mobile/releases/latest/android/multi/fennec-26.0.multi.android-arm.apk ftp://ftp.mozilla.org/pub/mozilla.org/mobile/releases/latest/android/multi/fennec-26.0.multi.android-arm.checksums ftp://ftp.mozilla.org/pub/mozilla.org/mobile/releases/latest/android/multi/fennec-26.0.multi.android-arm.checksums.asc
29675 ~tmp/firefox
>>> gpg --recv-keys 15A0A4BC
gpg: 下载密钥‘15A0A4BC’,从 hkp 服务器 keys.gnupg.net
gpg: 密钥 3A06537A:公钥“Mozilla Software Releases <releases@mozilla.org>”已导入
gpg: 需要 3 份勉强信任和 1 份完全信任,PGP 信任模型
gpg: 深度:0 有效性:  1 已签名:  4 信任度:0-,0q,0n,0m,0f,1u
gpg: 深度:1 有效性:  4 已签名:  0 信任度:4-,0q,0n,0m,0f,0u
gpg: 合计被处理的数量:1
gpg:           已导入:1  (RSA: 1)
29676 ~tmp/firefox
>>> gpg --verify fennec-26.0.multi.android-arm.checksums.asc
gpg: 于 2013年12月06日 星期五 01时11分05秒 CST 创建的签名,使用 RSA,钥匙号 15A0A4BC
gpg: 完好的签名,来自于“Mozilla Software Releases <releases@mozilla.org>”
gpg: 警告:这把密钥未经受信任的签名认证!
gpg:       没有证据表明这个签名属于它所声称的持有者。
主钥指纹: 2B90 598A 745E 992F 315E  22C5 8AB1 3296 3A06 537A
子钥指纹: 5445 390E F5D0 C2EC FB8A  6201 057C C3EB 15A0 A4BC
29677 ~tmp/firefox
>>> grep -F fennec-26.0.multi.android-arm.apk fennec-26.0.multi.android-arm.checksums
f6b14fbb5847cd87c8821cfd71beba8f64c7059e05a555c31e6ea8168905a54def6be8d20b0766b5f35f10b63efb73225d20cb4bfa04383b66d396d33f743242 sha512 26553667 fennec-26.0.multi.android-arm.apk
b20f6faa9d88171fb504eaf1a323918c md5 26553667 fennec-26.0.multi.android-arm.apk
5ffb036fa664fbbb59e750ec50b44a781af9565e sha1 26553667 fennec-26.0.multi.android-arm.apk
29678 ~tmp/firefox
>>> sha1sum fennec-26.0.multi.android-arm.apk
5ffb036fa664fbbb59e750ec50b44a781af9565e  fennec-26.0.multi.android-arm.apk

顺便看了看这两个版本火狐签名用的密钥:

29753 ~tmp/firefox
>>> unzip -p fennec-26.0.multi.android-arm.apk META-INF/RELEASE.RSA | keytool -printcert
所有者: CN=Release Engineering, OU=Release Engineering, O=Mozilla Corporation, L=Mountain View, ST=California, C=US
发布者: CN=Release Engineering, OU=Release Engineering, O=Mozilla Corporation, L=Mountain View, ST=California, C=US
序列号: 4c72fd88
有效期开始日期: Tue Aug 24 07:00:24 CST 2010, 截止日期: Sat Jan 09 07:00:24 CST 2038
证书指纹:
         MD5: B1:E1:BC:EE:27:33:02:5E:CE:94:56:E4:19:A8:14:A3
         SHA1: 92:0F:48:76:A6:A5:7B:4A:6A:2F:4C:CA:F6:5F:7D:29:CE:26:FF:2C
         SHA256: A7:8B:62:A5:16:5B:44:94:B2:FE:AD:9E:76:A2:80:D2:2D:93:7F:EE:62:51:AE:CE:59:94:46:B2:EA:31:9B:04
         签名算法名称: SHA1withRSA
         版本: 3
29754 ~tmp/firefox
>>> unzip -p org.mozilla.firefox-1.apk META-INF/RELEASE.RSA | keytool -printcert
所有者: CN=Release Engineering, OU=R&D, O=Mozilla Online, L=Beijing, ST=Beijing, C=CN
发布者: CN=Release Engineering, OU=R&D, O=Mozilla Online, L=Beijing, ST=Beijing, C=CN
序列号: 514de131
有效期开始日期: Sun Mar 24 01:06:57 CST 2013, 截止日期: Thu Aug 09 01:06:57 CST 2040
证书指纹:
         MD5: D7:C9:FC:AE:D0:3B:9F:24:43:33:DD:41:15:65:CD:8A
         SHA1: 1A:97:FA:6D:9D:83:DB:84:BE:77:1C:72:60:42:48:7C:85:83:D4:60
         SHA256: 02:A7:BC:81:02:74:C9:ED:38:93:3B:06:3D:1A:48:A8:4F:88:CB:11:C6:40:CA:A1:6C:F8:AA:FA:66:E3:C6:3A
         签名算法名称: SHA1withRSA
         版本: 3

那个中国特色的版本的密钥声称自己是 Mozilla 北京。估计和电脑上的中国版火狐一样,真是他们搞的吧。其实 Opera Mobile 我也不小心装过中国版的(名叫「欧朋浏览器」),不过比火狐中国版稍微好点,首页上那堆我用不到的网站很容易就删掉了,而中国版火狐我没能找到要怎么办。

看来以后一些手机应用的升级得自己来做了呢,标榜能「洗白白」应用的豌豆荚不小心就会给我塞点一堆广告的中国版应用……

Category: Android | Tags: Android 火狐 中国特色
12
9
2013
5

替换 Awesome 内建的桌面通知

Awesome 用户们,你们有没有觉得 Awesome 那个 naughty 组件的通知很丑?

Awesome notification

这样子是不是好一些?

Xfce notification

Linux 的桌面通知机制是使用 D-Bus 通信的。所以,要换个桌面通知的流程如下:

  1. 让旧的桌面守护进程释放对应的 D-Bus 目的地名;
  2. 运行新的桌面守护进程。

首先安装个新的通知守护进程,比如我安装的xfce4-notifyd

阅读 Awesome 的naughty.lua代码之后,发现 Awesome 其实能够「慷慨」地释放org.freedesktop.Notifications这个通知用的地址的:

$ awesome-client
awesome#return dbus.release_name("session", "org.freedesktop.Notifications")
   boolean true

使用awesome-client告诉 Awesome 执行这条语句,释放这个 D-Bus 目的地址。返回true就表示执行成功了。如果喜欢的话,当然可以把这句写到rc.lua里去。

其实做到这一步就可以了。在需要时 D-Bus 会自动激活 xfce4-notifyd 的进程。当然也可以手动运行:

$ /usr/lib/xfce4/notifyd/xfce4-notifyd

还可以使用xfce4-notifyd-config命令来进行简单的配置哦。当然,这个替换对于从 Awesome 脚本里直接调用 naughty 不起效的。

从上边的图片可以看到,XFCE 的通知支持按钮的,Awesome 不支持这个。不过,它们都支持类似这种<span color="blue">蓝色文字</span>Pango 文本标记语法

要换回使用 Awesome 来显示通知的话,先关掉其它通知守护进程,然后让 Awesome 告诉 D-Bus 它要来处理这个地址上的消息:

awesome# return dbus.request_name("session", "org.freedesktop.Notifications")
   boolean true

最后来吐槽一下 C 公司的notify-osd,就是 Ubuntu 上默认那个看上去不错的黑框框。它不支持 Pango 文本标记也就罢了,不能同时显示多条通知只能一个个地来也就罢了,像 fcitx 这样往通知上放点按钮你猜会怎么着?——

notify-osd

竟然出来个夺取窗口焦点的弹框……

11
27
2013
10

恢复火狐地址栏图标及 HTTPS 站点标识

大约一年前,火狐 14 发布的时候,取消了在地址栏显示网站图标的功能,而且重新设计了 HTTPS 网站的标识。那个白色背景上的绿色标识我很不喜欢,于是通过给 omni.ja 文件打补丁的方法恢复了之前的样式:

  • HTTP 网站图标:

    HTTP favicon

  • HTTPS 域名显示:

    HTTPS domain

  • HTTPS 「经营者」显示:

    HTTPS identity

  • 部分 chrome URL 显示(我自己照着改的):

    Chrome URL

可是,火狐 21 对这部分代码进行了重构,我找不到相关部分的代码了。于是,我一直还在使用火狐 20。直到前几天。

实际上,恢复在地址栏显示网站的扩展有不少,但无一例外,它们都只是恢复网站图标的显示。有个插件也恢复了 HTTPS 网站的浅蓝色域名显示,但是没有已认证的「经营者」的绿色显示。而且,它的代码是通过定时器每隔几百毫秒就执行一次,相比事件响应的方法太没效率了。

于是,使用代码片断速记器(默认快捷键Shift+F4),配合 Firebug 查看 chrome://browser/content/browser.xul,根据之前的样式表,我终于得到了以下解决方案(实际上上边的截图是我这个解决方案应用之后的)——

首先,安装 userChromeJS 扩展。这个扩展使得在火狐启动时加载 userChrome.js 文件。

其次,userChrome.js 文件,使地址栏显示网站图标并在正确的时机切换。它位于火狐配置目录下的 chrome 目录下:(注意已有新版

if(location == "chrome://browser/content/browser.xul"){
  (function(){

  var eTLDService = Components.classes["@mozilla.org/network/effective-tld-service;1"]
                    .getService(Components.interfaces.nsIEffectiveTLDService);

  function updateIcon(event){
    var tab = event.target;
    if(tab != gBrowser.selectedTab){
      return;
    }
    var icon = tab.image || 'chrome://mozapps/skin/places/defaultFavicon.png';
    document.getElementById('page-proxy-favicon').src = icon;
    var identity = document.getElementById('identity-box');
    if('verifiedDomain'.indexOf(identity.className) != -1){
      var identityLabel = document.getElementById('identity-icon-labels');
      identityLabel.collapsed = false;

      var domain = eTLDService.getBaseDomain(tab.linkedBrowser.lastURI);
      document.getElementById('identity-icon-label').value = domain;
    }
  }

  var container = gBrowser.tabContainer;
  container.addEventListener("TabSelect", updateIcon, false);
  container.addEventListener("TabAttrModified", updateIcon, false);

  })();
}

这部分,特别是标签页事件,参考了 MDN 的相关文档

最后,HTTPS 和 chrome URL 的样式文件,放到同目录下的 userChrome.css 中,有点长:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

/* 地址栏图标 */
#identity-box {
  background-image: linear-gradient(hsl(0,0%,98%), hsl(0,0%,92%));
  box-shadow: 0 1px 0 hsla(0,0%,0%,.05) inset;
  -moz-border-end: 1px solid rgba(0,0,0,.1);
  -moz-margin-end: 3px !important;
}

#identity-box:hover:active,
#identity-box[open="true"] {
  background-image: linear-gradient(hsl(0,0%,92%), hsl(0,0%,82%));
  box-shadow: 0 1px 1px hsla(0,0%,0%,.3) inset,
              0 1px 3px hsla(0,0%,0%,.3) inset;
}

/* Text colors for each:
 *
 * rgb(38, 76, 129) hsl(215, 55, 33)
 * rgb(71, 153, 0)  hsl(92, 100, 30)
 * rgb(229, 115, 0) hsl(30, 100, 45)
 */

#identity-box.verifiedDomain {
  background-image: linear-gradient(hsl(215,60%,92%), hsl(215,58%,88%));
  box-shadow: 0 1px 0 hsla(215,54%,33%,.05) inset;
  -moz-border-end-color: hsla(215,54%,33%,.2);
  color: hsl(215,54%,33%);
}

#identity-box.verifiedDomain:hover:active,
#identity-box.verifiedDomain[open="true"] {
  background-image: linear-gradient(hsl(215,80%,80%), hsl(215,67%,65%));
  box-shadow: 0 1px 1px hsla(215,54%,33%,.7) inset,
              0 1px 3px 1px hsla(215,54%,33%,.5) inset;
}

#identity-box.verifiedIdentity {
  background-image: linear-gradient(hsl(91,70%,90%), hsl(93,60%,81%)) !important;
  box-shadow: 0 1px 0 hsla(92,81%,16%,.05) inset !important;
  -moz-border-end-color: hsla(92,81%,16%,.2) !important;
  background-repeat: inherit !important;
  background-color: transparent !important;
}

#identity-box.verifiedIdentity:hover:active,
#identity-box.verifiedIdentity[open="true"] {
  background-image: linear-gradient(hsl(92,65%,70%), hsl(92,40%,48%)) !important;
  box-shadow: 0 1px 1px hsla(92,81%,16%,.6) inset,
              0 1px 3px 1px hsla(92,81%,16%,.5) inset !important;
}

#identity-box.chromeUI {
  background-image: linear-gradient(hsl(29,70%,95%), hsl(31,60%,90%)) !important;
  box-shadow: 0 1px 0 hsla(30,81%,25%,.05) inset !important;
  -moz-border-end-color: hsla(30,81%,25%,.2) !important;
  background-repeat: inherit !important;
  background-color: transparent !important;
}

#identity-box.chromeUI:hover:active,
#identity-box.chromeUI[open="true"] {
  background-image: linear-gradient(hsl(30,65%,85%), hsl(30,65%,70%)) !important;
  box-shadow: 0 1px 1px hsla(30,81%,25%,.6) inset,
              0 1px 3px 1px hsla(30,81%,25%,.5) inset !important;
}

另外,新版火狐又有一点令我不满了:滚动到页面底部和顶部也会使用平滑滚动,不喜欢。还是这个是可选的,设置 general.smoothScroll.otherfalse 就可以了。

2013年11月29日更新:自火狐 23 起,地址栏搜索会使用搜索栏的默认搜索引擎。对于我这种拿地址栏搜网站、搜索栏查字典的用户来说,这很难以忍受。于是找到 keyword.URL Hack! 这个扩展,新建字符串设置keyword.URL为 Google「手气不错」地址https://www.google.com/search?hl=zh-CN&btnI=1&q=,终于又回到从前二者兼俱的时候。

2014年3月25日更新:更新了脚本,在载入过程中不会显示错误的图标了。

Category: 火狐 | Tags: 火狐 userChrome
11
25
2013
9

被冻结的时间

那天中午,照例在网上闲逛时,却得知,那条时间线将永远停留在那时候,永远不会再流动了。不会再有新的消息,也不再会作出回应。

也并不是所有这样的事件都会如此高调地宣告它的发生。

有时,只是突然想起,有个人,很久很久都没有出现过了。

然后发现,询问的消息如石沉大海,有去无回。

甚至都没有办法去搜寻,因为我所知道的信息是那么不完整。

网络世界中,人与人,就像由虚拟的线联系起来。

那些带来温暖和慰藉的线,经常都是那样的纤细。

或者在某个不被注意的瞬间消逝,或者在最后的告别之后断掉。

Mark Pilgram 主动 410 时我只是唏嘘。

当有朋友对我说永别时,我惊讶、不敢置信,亦无限惋惜。

而那些悄然丢失的联系,只能埋藏起来,等待下一次被发掘。虽然明知那几乎不可能。

那些被冻结的时间,那些不会有回应的消息,那些永远的失去。

Category: 未分类 | Tags:
11
24
2013
2

X Window 中的剪贴板

这原本是我在知乎上的一个回答,现在略作修改,放在博客上。


很多 Linux 用户知道,除了通用的Ctrl-C/Ctrl-V剪贴板外,Linux 桌面上还有另一套剪贴板可以用。

首先澄清一下,这个功能不属于 Linux,而是属于它(目前)所广泛使用的显示服务程序——X WindowX Window 的历史比 LinuxVim 都要古老呢。现在所使用的版本 X11 也是 1987 年就已经发布了的。

X Window 目前被广泛使用的用于 X Window 客户端(使用 X Window 的程序)间交换数据的剪贴板有两个:primary selectionclipboard

Primary selection,通常,内容被选择时会被放到这里,按鼠标中键时被获取并粘贴。

例外一火狐浏览器中只有用户主动选择的内容才会被放到 primary selection,由网页代码导致的选择不会修改用户的 primary selection。
例外二Vim / GVim 的「可视」选择默认并不放到 primary selection。有选项可以设置成这样。
例外三:一些网站(如 GitHub)用的 Ace 在线编辑器,在用户「选择」时并不创建真正的选择区,它只在用户按Ctrl-C等键时做一些处理,因此在 Ace 编辑器中选中复制、中键粘贴无效。
例外四Wine 不支持 primary selection。

Clipboard,这就是大家熟悉的剪贴板了,图形界面程序中Ctrl-C复制,Ctrl-V粘贴。终端里因为快捷键会冲突,所以这些图形界面常用的快捷键使用的时候都要按住 Shift 键。

关 于 X Window 剪贴板要注意的地方:以上剪贴板的内容都不是保存在 X 服务器上的,而是客户端程序说,「我请求提供这个剪贴板的数据」(X 服务器通常会允许这样的请求)。另外的程序要粘贴时就会通过 X 服务器向这个程序请求:「请把 XX 剪贴板的数据给我。」所以,X Window 剪贴板上的内容会在拥有它的程序退出后自动被清除。所以一般人会需要用剪贴板管理器来更持久一些地保存剪贴板数据。

关于 X 协议细节可能有些不对,不过大体上是这个样子的啦。

还有没什么程序用到的 secondary selection,以及 Vim 偶尔会用到的 cut buffers(共8个,Vim 和 xterm 会用第一个)。Cut buffers 似乎是由 X 服务器保存数据的。Vim 在挂起时为了避免请求剪贴板数据的程序长时间等待会把自己的选择区内容写到 CUT_BUFFER0。

火狐似乎设置了很短的剪贴板请求超时时间,因此,从远程程序请求剪贴板数据时,可能因为网络延迟导致火狐没有及时得到数据而放弃。

Category: Linux | Tags: linux X Window X window
11
21
2013
8

虾米歌词下载、Python Requests 库,以及 HTTP Keep-Alive

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 网站。

Category: python | Tags: python tcp http
11
15
2013
5

在 Awesome 下对 Wine 运行的 TM.exe 使用 Alt+数字键来切换标签页

现在我一直在使用 Wine 运行 TM2013。这个版本支持一个窗口里以标签页的方式放多个对话了。然后就遇到一个问题——不同平台切换标签页的快捷键是不同的!

Linux 使用Alt+数字,Mac OS X 使用⌘数字,而 Windows 则使用Ctrl+数字。像火狐这种多平台支持得非常好的程序,不仅有一个适合其所运行平台的默认值,而且也可以通过手动修改about:config来使用其它平台上的习惯。但是,TM 显然不可能这么体贴。

不过我是 Linux + Awesome 用户嘛,怎么可能轻易就妥协呢。既然 TM 自己不认,那我让 Awesome 在Alt+数字时给 TM 的窗口发Ctrl+数字就好了嘛。想法是好的,现实却不那么美好,Awesome 不支持直接给窗口发送指定按键。于是只好调用 xdotool 命令了。因为按 Awesome 快捷键的时候,焦点会暂时移出原窗口,所以我指定了窗口 ID。延时的解决方法没这个优雅:

-- {{{ bind_alt_switch_tab_keys
alt_switch_keys = awful.util.table.join(
    -- it's easier for a vimer to manage this than figuring out a nice way to loop and concat
    awful.key({'Mod1'}, 1, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+1') end),
    awful.key({'Mod1'}, 2, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+2') end),
    awful.key({'Mod1'}, 3, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+3') end),
    awful.key({'Mod1'}, 4, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+4') end),
    awful.key({'Mod1'}, 5, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+5') end),
    awful.key({'Mod1'}, 6, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+6') end),
    awful.key({'Mod1'}, 7, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+7') end),
    awful.key({'Mod1'}, 8, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+8') end),
    awful.key({'Mod1'}, 9, function(c) awful.util.spawn('xdotool key --window ' .. c.window .. ' ctrl+9') end)
)
function bind_alt_switch_tab_keys(client)
    client:keys(awful.util.table.join(client:keys(), alt_switch_keys))
end -- }}}

然后在 TM 的窗口上调用这个函数就可以了。唯一有点小遗憾的是,fcitx 的图标在按 Awesome 快捷键时会切换一下。

Category: Linux | Tags: wIne Awesome X Window TM

| Theme: Aeros 2.0 by TheBuckmaker.com