依云's Blog

从这里看到 ssh 的 Control master 特性之后，就在~/.ssh/config里启用了这个特性：

ControlPath ~/.ssh/master-%r@%h:%p
ControlMaster auto
ControlPersist yes
Compression yes

会话连接复用，对于以交互操作的使用，很不错的！对低延迟的服务器可能只是少了用户认证过程，但对于连接国外服务器，少了 TCP 握手、SSH 握手与认证等来来回回的过程，连接会快非常多的，尤其是对于常用的服务器，比如 GitHub 之类的，提速非常明显。

然后，问题就来了：系统挂起再恢复之后，大部分连接会 stalled，需要手工断开连接。即使配置了超时，它也不一定及时。于是我想，既然 netctl-auto 之类的服务能够在挂起系统时适当处理，那么我是不是也能写一个用户级的 systemd 服务来处理这件事情呢？

于是我按系统级的配置方法弄好了，结果什么也没有发生……后来才明白，只有系统级的 sleep.target，没有用户级的啊。

在 Arch Linux 官方论坛看到有人这么尝试，让系统级的 systemd 调用用户级的 systemd。配置有点不对，但是想法是非常好的！

于是就有了我现在用的方案：

[Unit]
Description=sleep.target of a systemd user session
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
User=%I
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus
RemainAfterExit=yes
ExecStart=/usr/bin/systemctl --user start sleep.target
ExecStop=/usr/bin/systemctl --user stop sleep.target

[Install]
WantedBy=sleep.target

启用（enable）user-sleep@1000.service之后，系统挂起时，就会调用 ID 为 1000 的用户的用户级 systemd，也 reach sleep.target 啦。当然这个用户级的 sleep.target 也得自己写：

[Unit]
Description=Sleep
Documentation=man:systemd.special(7)
DefaultDependencies=no
StopWhenUnneeded=yes

然后就可以让用户级的服务WantedBy=sleep.target啦～

从一开始使用 Arch Linux，我就选择了 slim 作为登录管理器。因为它轻量嘛，而且配合 Arch Linux 自己做的主题也挺漂亮的：

所以即使 slim 不再使用配置文件来指定有哪些桌面环境可用，改用无法指定顺序的 .desktop 文件，我只好告诉 pacman，不要升级 slim 了。

于是就这么用了很久，直到 lightdm 出世，直到 slim 所使用的托管网站关闭、停止开发，我也依然在用 slim。

直到有一天，那是在 systemd 开始使用用户级别的 session D-Bus 之后。我登出了会话，再次登入时，发现整个系统都不好了，因为 DBUS_SESSION_BUS_ADDRESS 环境变量没有被设置，导致程序找不到 session bus 而自动启动了一个。可我用户级别的 systemd 还在旧的 session bus 里呢，联系不上了。当然 tmux 里所使用的 session bus 也开始混乱了（我有让 tmux 从环境里更新各种 window 中的 DBUS_SESSION_BUS_ADDRESS 变量）。

究其原因，是因为 slim 没有正确地处理 sesssion。从 loginctl 及 systemd-cgls 可以看到，重新登录 slim 之后，进程并没有处在新的会话里，而是复用了旧的会话。

systemd 上，会话管理是 pam_systemd 来管理的，同时它会引入 DBUS_SESSION_BUS_ADDRESS 环境变量。PAM 会话是有一个 leader 进程的，它的结束标志着这个会话的结束（当然里边存活的进程还会继续存在）。比如文本终端登录用的 login，每一次登录都是一个新进程。比如 sshd，每个连接都是由单独的子进程来处理，PAM 会话也是那个时候打开的。然而 slim 却是在父进程里打开了 PAM 会话。于是 pam_systemd 一看，这个 session leader 怎么又要打开会话啦？报错：

8月 02 21:54:32 lilyforest slim[669]: pam_systemd(slim:session): Cannot create session: Already running in a session

所以，slim 下，只有第一次登录是正常的……

所以是时候换个跟得上时代的登录管理器了。那就 lightdm + GTK greeter 好了。

这个我以前也用过，不过没怎么配置所以背景一片漆黑，难看死了。这次制作了张背景图，在/etc/lightdm/lightdm-gtk-greeter.conf里配置一下

[greeter]
background=/usr/local/share/pixmaps/background.png

咦？还有头像？那就放一个~/.face好了。什么？lightdm 你没权限读取它？OK，给你权限：

setfacl -m u:lightdm:x ~
setfacl -m u:lightdm:r ~/.face

我的 HOME 目录的权限是 750，别人（other）进不来的，所以要给 lightdm x 权限。

最终的样子就是这样，也挺漂亮的，功能还挺全 :-)

2021年07月11日更新：轻聊版已经不可用。

截图

注：图中的文字方框已经解决。

安装使用

测试过的 Wine 版本为 1.7.52、1.7.54。1.7.53 是坏的。1.6 系列大概跑不起来。

Wine 环境下载地址（签名，使用的新 key）。压缩包中安装的是官方完整版的 QQ 轻聊版 7.7（安装文件名 QQ7.7Light.exe）。

文件最后更新于2016年1月29日。

1. 下载文件并解压、找个地方放好（移动之后启动图标会失效）。
2. 如果系统上没有 simsun.ttc 字体，去网上下一个放到 ~/.fonts 中。或者到解压出来的 Wine 环境里 winetricks fakechinese 也行。
3. 运行解压出来的目录下边的install-icon.sh脚本来安装启动图标

安装好之后，在你通常找所有已安装的应用程序的地方就可以找到「Wine QQ 轻聊版」的启动图标了。你也可以运行解压出来的目录下边的qq脚本来启动，但必须在那个目录下运行。

在火狐里点击「加入QQ群」之类tencent://协议的链接时，也是可以调用到的哦～不过即使已经登录，也会开启新的 QQ 登录界面。但是不这样又会有更严重的问题，所以凑合着用吧。

其它调整，如使 QQ 无限制地访问文件系统（默认只允许访问 C 盘）、更改一些文件的存放位置、字体选择与渲染选项，请自行修改。想要 Flash 的也请自己 winetricks 安装。

已知问题

• 记不住密码
• 密码框需要耐心地点几下才能开始输入
• 表情图片只有启动后的第一次使用时正常，之后弹出窗口的内容不能正常显示
• 窗口周围部分的显示不正常（可能和 Awesome 有关）
• 使用 Windows 内建的移动窗口功能（拖动窗口边框、标题栏）时可能会导致窗口开始避开鼠标指针（可能和 Awesome 有关）
• 部分群文件下载能够成功，但是界面上看到的进度一直是0字节未完成状态（比较小的文件不受影响）

制作步骤

由于之前的 TM2013 已经很久没更新了，有很多功能都跟不上（比如群公告、语音消息等），所以我又 Wine 了新版本。QQ 轻聊版感觉就是 QQ 标准版去掉了广告，不用付费开通会员来去掉那些干扰广告了。

首先 winetricks 一下：

winetricks sandbox riched20

然后把 Windows 版本设置为Windows 8.1（大于 XP 即可）。不设置安装不上，因为缺少CmRegisterCallback函数。

将 QQ7.5Light.exe 安装文件链接到 C 盘内，安装。

再打开 winecfg，作如下设置：

• 设置 Windows 版本为 Windows XP
• 「增加程序设置」，找到 drive_c/Program Files/Common Files/Tencent/QQProtect/Bin/QQProtect.exe 文件，设置其版本为 Windows 8.1（不然会出错）
• 回到「默认设置」，切换到「函数库」标签，添加「txplatform.exe」「函数库顶替」，并且设置为「禁用」

禁用 TXPlatform.exe 会导致tencent://链接不能在已有的 QQ 里打开。但是启用它会导致登录不了或者退出不了（卡住）的情况。

从 Windows 上复制 iphlpapi.dll，放到 system32 目录，并设置原装优先，以绕过「查找」对话框打开时卡死的问题。

修改system.reg注册表文件，设置 Tahoma 的 FontLink 项（不然部分文字乱码）：

[Software\\Microsoft\\Windows NT\\CurrentVersion\\FontLink\\SystemLink] 1420549548 0
"Tahoma"="simsun.ttc,SimSun"

当然你也可以把这里的宋体替换成你想要的任何字体。

另外，这里有人在制作并维护 Wine QQ 精简版。

2015年11月12日更新：更新到 QQ 轻聊版 7.7。旧版用户以 Windows 8.1 版本号来运行 7.7 的安装程序即可更新。

旧的 QQ 轻聊版 7.5 Wine 环境下载地址（签名，使用的新 key）。压缩包中安装的是官方完整版的 QQ 轻聊版 7.5（安装文件名 QQ7.5Light.exe）。

2016年3月5日更新：请禁用QQProtectUpd.exe或者将drive_c/Program Files/Common Files/Tencent/QQProtect目录及其下的所有文件设置为只读（chmod -R -w 目录），以免 QQ 自动后台更新之后崩溃。

最近打算把闲置了许久的树莓派重新利用起来。交给它的第一个任务是：做路由器。于是去弄了个 USB 无线网卡，型号是 TP-Link WN823N 版本 2.0。买的时候没注意，拿到手才知道这款需要自行安装驱动。还得使用特制版本的 hostapd。

驱动名叫 8192eu，或者 rtl8192eu，随便啦。GitHub 上有多个版本，我使用的是 Mange/rtl8192eu-linux-driver。因为 gcc 及内核更新的原因，需要修改两处：

diff --git a/Makefile b/Makefile
index 0c800f8..85058fa 100644
--- a/Makefile
+++ b/Makefile
@@ -13,6 +13,7 @@ EXTRA_CFLAGS += -Wno-unused-label
 EXTRA_CFLAGS += -Wno-unused-parameter
 EXTRA_CFLAGS += -Wno-unused-function
 EXTRA_CFLAGS += -Wno-unused
+EXTRA_CFLAGS += -Wno-date-time

 #EXTRA_CFLAGS += -Wno-uninitialized

diff --git a/os_dep/linux/rtw_android.c b/os_dep/linux/rtw_android.c
index 98f0d31..8a2ee56 100644
--- a/os_dep/linux/rtw_android.c
+++ b/os_dep/linux/rtw_android.c
@@ -337,7 +337,7 @@ int rtw_android_cmdstr_to_num(char *cmdstr)
 {
        int cmd_num;
        for(cmd_num=0 ; cmd_num<ANDROID_WIFI_CMD_MAX; cmd_num++)
-               if(0 == strnicmp(cmdstr , android_wifi_cmd_str[cmd_num], strlen(android_wifi_cmd_str[cmd_num])) )
+               if(0 == strncasecmp(cmdstr , android_wifi_cmd_str[cmd_num], strlen(android_wifi_cmd_str[cmd_num])) )
                        break;

        return cmd_num;

然后，本文的主题来了：我需要 ARM 版的驱动！因为我的树莓派没有键盘也没有显示器，也没有网线什么的。除了电源和 SD 卡，它只有一块无线网卡了。所以只能交叉编译了。

本来呢，内核使用的构建系统非常棒，一切都会很顺利的。但是，我不要先交叉编译个 ARM 版内核。于是我遇到了这个问题。scripts 目录下的二进制文件是编译模块的时候需要执行的，然而我的机器并不能执行 ARM 版本的二进制。

好吧，不就是一些小程序么。把我本机的复制过去就可以跑了嘛。结果开心地看着各源码文件被编译成目标文件之后，遇到 modpost 报了这么个错误：

FATAL: section header offset=11258999068426292 in file '/ldata/DATA/src/rtl8192eu-linux-driver/8192eu.o' is bigger than filesize=1094666

大概是因为我的系统是 64 位的，然而 ARM 是 32 位的吧。不过我没兴趣去找一个 i686 版本的 modpost 来尝试了。真要在我笔记本上跑 ARM 程序又不是不可以，我们有 qemu 嘛。虽然是模拟器，不过我不觉得它会比在我那树莓派上运行慢 :-)

以下是整个完整的步骤：

首先说明一点，我使用的是 Arch Linux ARM。树莓派官方提供的 Raspberry 镜像里东西太多了，我的 SD 卡放不下我也用不着。而且它是基于 Debian Wheezy 的，没有 systemd 可用。

新建一个目录rpi，开始啦！

因为要运行 ARM 版的 modpost 程序，我们先下载树莓派的 gcc-libs、glibc，并解压出其 /usr/lib 下的文件：

wget https://mirrors.ustc.edu.cn/archlinuxarm/armv6h/core/gcc-libs-5.2.0-2-armv6h.pkg.tar.xz https://mirrors.ustc.edu.cn/archlinuxarm/armv6h/core/gcc-libs-5.2.0-2-armv6h.pkg.tar.xz.sig https://mirrors.ustc.edu.cn/archlinuxarm/armv6h/core/glibc-2.22-1-armv6h.pkg.tar.xz https://mirrors.ustc.edu.cn/archlinuxarm/armv6h/core/glibc-2.22-1-armv6h.pkg.tar.xz.sig
gpg --verify glibc-2.22-1-armv6h.pkg.tar.xz.sig
tar xf glibc-2.22-1-armv6h.pkg.tar.xz usr/lib || true
gpg --verify gcc-libs-5.2.0-2-armv6h.pkg.tar.xz.sig
tar xf gcc-libs-5.2.0-2-armv6h.pkg.tar.xz usr/lib
[[ ! -f lib ]] && ln -s usr/lib lib

要编译内核模块，当然少不了 linux-*-headers 包了：

wget https://mirrors.ustc.edu.cn/archlinuxarm/armv6h/core/linux-raspberrypi-headers-4.1.6-3-armv6h.pkg.tar.xz https://mirrors.ustc.edu.cn/archlinuxarm/armv6h/core/linux-raspberrypi-headers-4.1.6-3-armv6h.pkg.tar.xz.sig
gpg --verify linux-raspberrypi-headers-4.1.6-3-armv6h.pkg.tar.xz.sig
tar xf linux-raspberrypi-headers-4.1.6-3-armv6h.pkg.tar.xz usr

不必每次更新 gcc-libs 和 glibc，只要它们能跑 modpost 程序就可以了。但是内核头文件是要和系统上运行的内核匹配的。

我们删掉 ARM 版的 scripts 目录，换上本机的版本。但是 modpost 例外。同时要修改 Makefile.modpost，使之使用 qemu-arm 来运行 modpost 程序：

pushd usr/lib/modules/4.1.6-3-ARCH/build
mv scripts/mod/modpost .
rm -rf scripts
cp -r /usr/lib/modules/$(uname -r)/build/scripts .
sed -i '/^modpost =/s/scripts/qemu-arm scripts/' scripts/Makefile.modpost
mv modpost scripts/mod
popd

最后就可以编译啦。把交叉编译工具链（签名）的路径加到 $PATH 里去。还要设置 QEMU_LD_PREFIX 到我们解压出来的那些文件所在的目录好让 qemu-arm 能够找到需要的库文件。然后进入驱动目录，开始编译！

path+=/ldata/DATA/soft/arm-lilydjwg-linux-gnueabi/bin
export QEMU_LD_PREFIX=$PWD
cd ../rtl8192eu-linux-driver
make CROSS_COMPILE=arm-lilydjwg-linux-gnueabi- KSRC=../rpi/usr/lib/modules/4.1.6-3-ARCH/build ARCH=arm
gzip 8192eu.ko

就酱。

试错几次之后，终于把配置写对了，于是我看到树莓派的 Wi-Fi 灯闪动了，随即从系统日志看到 hostapd 和 dnsmasq 都报告它连上网了～然后 ssh 登陆过去：

Last login: Tue Jun 11 22:57:29 2013 from 192.168.2.101

两年零三个月没进去过了呢。然后，我换 USTC 源，执行了pacman -Syu！跨越两年零三个月的滚动更新，然而除了很多配置文件有新版本需要手工合并外，并没有发生什么特别的事情，就更没有滚挂了=w=

后来我也尝试在树莓派上直接编译内核模块（因为内核升级了嘛）。结果表明，交叉编译是正确的选择！在树莓派上编译这个模块的时间，我的笔记本估计可以编译出整个内核了……

这是我编译的 8192eu 模块 及签名文件，对应内核版本 4.1.6。

至于 hostapd，下载这个，把其中的wpa_supplicant_hostapd-0.8_rtw_r7048.20130424.tar.gz里hostapd目录下的东西编译了就好。只需要指定CC变量就可以交叉编译成功。

这是我编译的 hostapd 及签名文件。配置文件中要写driver=rtl871xdrv。

ThinkPad 键盘上的第一行键现在默认在不按下Fn键时执行多媒体按键功能，按下Fn时才能执行F1-F12的功能，对于像我这种 Vim 和 htop 等的用户来说颇为不便。还好，BIOS 选项里可以改回来。

然后我遇到了 X250，发现Insert和End键怎么也受那个选项的影响了！也就是，如果F1-F12设置得方便了，那么End键就需要Fn键配合。而Home、End这种光标移动键虽然很少用，但毕竟还是要用到的，比如在 htop、weechat、mutt 以及不支持自定义编辑键的 Qt 程序里的时候。

所以呢，我在~/.Xmodmap里把这两个键交换了：

keysym End = Insert
keysym Insert = End

这下子用笔记本上的键盘是没问题了。可是我用外接键盘的话，这两个键就又反过来了 Orz……

当然网上会有 udev 规则，在插上外设时跑个脚本什么的。可不管怎么映射，总有个键盘的按键是反的啊！

仔细询问 Google 之后，在 Gentoo 的论坛里终于发现这么一条线索：

To alter keymap of a particular keyboard you need to issue EVIOCSKEYCODE ioctl on corresponding /dev/input/eventX node.

所以，找到相应的 event 设备文件之后，只需要 ioctl 一下就可以了？可是EVIOCSKEYCODE是个什么鬼啊……

找过 manpages、头文件、内核文档、Google 之后，我不得不相信这个东西真的没文档！于是只好看源码了……还好有 LXR，不用在本地近一个G的源码里搜索。

所以，翻完文档又试验，最终有了这个程序：

#include<sys/ioctl.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<stdio.h>
#include<stdlib.h>
#include<linux/input.h>

#define EVENT_FILE "/dev/input/by-path/platform-i8042-serio-0-event-kbd"

int main(int argc, char **argv){
  unsigned int codes[][2] = {
    {0xd2, 107}, //Insert -> End
    {0xcf, 110}, //End -> Insert
    {0, 0},
  };
  int fd = open(EVENT_FILE, O_RDONLY);
  if(fd < 0) {
    perror("open " EVENT_FILE);
    exit(1);
  }

  unsigned int (*p)[2];
  for(p=codes; *p[0]; p++){
    if(ioctl(fd, EVIOCSKEYCODE, *p)) {
      perror("ioctl EVIOCSKEYCODE");
      exit(1);
    }
  }
  return 0;
}

那个EVENT_FILE当然就是笔记本键盘的节点啦，在/dev/input/by-path下很容易识别的。

编译之后，每次启动系统后执行一次就可以了（大概）。

对了，顺便说一下，找那些代码可以用 showkey 和 getkeycodes 之类的命令。当然我们有 setkeycodes，但是它不能为指定键盘单独设置。传进去的参数，第一个整数是 scancode，就是硬件上报的编码，第二个是 keycode，内核给键的编码，不同硬件的不同 scancode 可以对应同一个 keycode（比如本文所做的）。然后文本终端还有 keymap、X Window 还有键盘布局和 xmodmap，大概是把 keycode 映射到可读的键名。

曾经，我让 Awesome 收养孤儿进程，以保持一个清晰的进程树。后来我又想让 zsh 也做这个 prctl 系统调用，免得子进程 fork 之后跑太远。比如 Wine 跑起来就好多个服务进程，如果不能把它们全部关掉的话，再启动另一个版本的 Wine 会出问题的。而当我启动好些个不同版本的 Wine 环境之后，只看到 Awesome 下边挂了一堆 Wine 的进程，却不知道哪些属于哪个 Wine 环境的了。

zsh 本身并不支持做这个调用，不过如同 Python 和 Lua 一样，zsh 也可以通过共享库来扩展功能。不同的是，zsh 模块是没有文档的……好在 zsh 源码里提供了一个 example 示例模块。把它改改就有了以下代码：

把这两个文档保存到 zsh 源码目录的Src/Modules下，可能还需要编辑一下config.modules文件，然后编译就可得 subreap.so 文件。把这个文件放到/usr/lib/zsh/$ZSH_VERSION/zsh/subreap.so然后就可以用了：

zmodload zsh/subreap
subreap

模块加载之后，多了个subreap内建命令。不带参数即调用prctl(PR_SET_CHILD_SUBREAPER, 1)，这样不管其子进程怎么 fork，都会在此 zsh 的进程树之下。使用subreap -u来取消这个设置。

如果你不想编译而又是 Linux 64 位系统，可以试试我编译好的版本：下载地址, 签名, SHA1: 09eb1cc9ebf6ec1e681641c0a60f57425cbb1e8c。

不用 sudo 也可以跑 LXC 虚拟机啦。使用 root 权限的 LXC 虚拟机，里边的 root 权限就是真实的 root 权限，虽然不太能够跑出来。而利用用户命名空间来启动的普通权限的 LXC 虚拟机则只在那个虚拟机里有 root 权限，从外面看跟一普通用户一样的。

首先需要一枚启用了CONFIG_USER_NS的内核。使用以下命令查看：

zgrep USER_NS /proc/config.gz

部分发行版会默认禁用用户命名空间功能，需要手动启用，参见 vagga 的安装文档。而 Arch Linux 不喜欢给软件打补丁，而这个特性又被认为是不安全的，所以并没有启用。当然这并不妨碍自己编译一个启用了这个特性的内核啦，比如 linux-lily 从 4.0.1 开始启用此特性。

注意：这个特性被认为不安全的，会时不时地爆出个提权漏洞（比如前不久这个），请谨慎启用。

内核支持没问题的话就可以开始配置了。以下配置过程主要参考 Arch Linux 论坛里的这篇帖子。

首先给自己配置一些子 UID 和子 GID，也就是自己的分身。我在/etc/subuid和/etc/subgid内写下如下内容

lilydjwg:100000:65536

意思是说，我（lilydjwg）被授权使用从 100000 开始的 65536 个 UID 和 GID。这一步是需要 root 权限的。这个配置好之后就可以创建用户命名空间了，比如：

lxc-usernsexec -m u:0:100000:1 -m g:0:1000:1 -m g:1:100000:1 -- /bin/zsh

此命令是说，创建一个用户命名空间，其中 UID 从 0 开始，实际对应于外边 100000 开始的 UID，总共分配一个；GID 从 0 开始，实际对应于外边 1000 开始的 GID，总共分配一个。执行之后可以看到新启动的 zsh 已经是 root 权限了。不过cat /etc/shadow就会发现还是没权限 :-D 在里边 touch 个文件的话，在外边看会是 UID 为 100000 的用户创建的。我之所以要指定 GID 的映射，是因为我的 HOME 目录外人读不了的。为了加载 zsh 的配置，就把自己的 GID 映射给它了。

注意：如果这里没有包含 /etc/subgid 中的 GID 区间，那么 shadow 4.6 将不允许 setgroups，导致命令失败。（只要有任意一部分即可。）

当然我也可以把自己的真实 UID 映射过去，这样子除了被里边的进程自认为有 root 权限之外没什么别的差异。用户命名空间要配合别的命名空间一起用才有意思。

然后要配置一下 cgroup，不然 lxc 会报错的。这一步也是需要 root 权限的。

echo 1 | sudo tee /sys/fs/cgroup/cpuset/cgroup.clone_children

for d in /sys/fs/cgroup/*; do
    sudo mkdir $d/$USER
    sudo chown -R $USER: $d/$USER
done

用处后边再说。

虚拟机里的网络是分开的。默认是没有网络的。想要的话得先授权，向/etc/lxc/lxc-usernet文件里写入

lilydjwg veth br0 10

其中br0是桥接用的网络接口名。没有就自己建一个：

brctl addbr br0
ifconfig br0 192.168.57.1
iptables -t nat -A POSTROUTING -s 192.168.57.1/24 -j MASQUERADE

这些当然也是需要 root 权限的。

还要告诉 LXC 使用用户命名空间：在~/.config/lxc/default.conf写入：

 lxc.include = /etc/lxc/default.conf
 lxc.id_map = u 0 100000 65536
 lxc.id_map = g 0 100000 65536

然后，去弄一个 LXC 系统镜像吧：

lxc-create -t download -n lxcname

名字自己起。这个命令会让你选择你要的发行版和版本的。这一步不需要 root 权限了。镜像文件列表可以看这里。

等它跑完之后新的 LXC 虚拟机的 root 文件系统已经就绪了。不过在启动它之前先去编辑一下它的配置文件，加入网络配置。默认它位于~/.local/share/lxc下与 LXC 虚拟机同名的目录下。

在配置文件里加上

lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.ipv4 = 192.168.57.4
lxc.network.name = eth0

在启动之前还要做一件事——将当前进程加入到之前创建的 cgroup 中：

for d in /sys/fs/cgroup/*; do echo $$ > $d/$USER/tasks; done

然后就可以启动 LXC 虚拟机啦。当然是不需要 root 权限的：

lxc-start -F -n lxcname

当然，得给里边的 root 用户设置一个密码，不然登录不了的。可以使用 lxc-usernsexec 来 chroot 过去：

lxc-usernsexec -- chroot rootfs /bin/bash

2019年07月31日更新：修正 lxc-usernsexec setgroups 可能失败的问题。

首先安装 bluez 包。我用的版本是 5.30。其次安装 blueman。

启动蓝牙服务：

systemctl start bluetooth.service

然后使用 blueman-manager 之类的命令启动 blueman。这时会在系统托盘看到蓝牙图标。点右键选择「添加新设备…」，完成配对。

然后，如果是要往手机发文件的话，是没有问题的，但是收的话，会失败。原因是，默认接收文件前会先询问用户要不要接收，而 blueman 不知道怎么搞的根本没反应……

解决方案是：直接启动一个默认接收文件的 obexd 就好了：

killall obexd
/usr/lib/bluetooth/obexd -r tmpfs -n -a

-r指定收到的文件存哪里，默认是 $XDG_CACHE_DIR 下的 obexd 目录，即默认是 ~/.cache/obexd。这里的路径是相对于用户主目录的。

-n是不要以守护模式运行，会把日志输出到终端而不是系统日志。

-a就是重点——接收所有文件——了。

obex 这套东西的文档在/usr/share/doc/bluez/dbus-apis/下有。

Linux 下遇到点问题还真是折腾，声称完成某一功能的软件一大堆，结果装好了，要么根本不知道怎么用（gnome-bluetooth、bluedevil），要么适用版本不匹配（obexpushd、ArchWiki 等网上的过时信息），要么有 bug 用不了（blueman）。

不过好的一点是，不涉及闭源的软件和协议，而又有足够的时间和能力的话，问题总是能够解决的。不像 Windows 或者 Android，遇到问题两眼一摸黑，只能不断地重试和重装，看看人品会不会爆发一下。

最后，折腾好久终于传输成功的照片：

北京好不容易下了场大雨，没想到雨后还出现了彩虹～

（失眠了，干脆起来写文。）

调试时经常会有抓包的需求。通常，我在本地用图形界面的 Wireshark 来抓包及解析，而对于远程服务器，因为没有图形界面，只好使用 tcpdump 抓包到文件然后复制到本地拿 Wireshark 看了，这样就不能实时查看抓到的包了。当然 tcpdump 也可以实时输出，但是信息太少、难以阅读，功能也过于简单，比如我要跟踪流啊、不同的流用不同的颜色高亮啊、添加注释啊、时序分析啊，tcpdump 完全没办法做到。实际上复杂一点的协议解析它都做不到。

一直没去研究 Wireshark 如何从标准输入读取网络包数据。大概是某天下意识地按了一下Alt-h看到了 Wireshaark 的 man 手册，才知道原来 Wireshark 支持这么多参数！图形界面的程序支持各种可选参数的可不多见。Wireshark 指定-i -就可以从标准输入读取数据，不过要同时指定-k，不然得在图形界面里点「Start」开始抓包。

那怎么把抓到的数据包发送到标准输出呢？实际的抓包操作不是 Wireshark 直接执行的。Wireshark 又不是 360，既然能以普通用户身份执行需要特权的操作，那么就会有一个无图形界面的工具来辅助。它就是 dumpcap。查阅其 man 手册可知，把抓到的数据输出到标准输出的选项是-w - -P（-P 指定使用 pcap 格式，不然会使用 pcap-ng 格式，Wireshark 不认）。还可以给定其它选项，比如只抓 lo 网络设备上的包用-i lo，或者指定一个过滤器如-f 'port 1234'（具体语法见pcap-filter的 man 手册）。一定要记住不要把传输抓包数据的数据包也抓到了哦～

比如：

ssh lxc-debian sudo dumpcap -P -w - -f "'not port 22'" | \
  wireshark -i - -k

这样就可以实时看到远程主机上的网络包了～通过 ssh 执行命令时引号得用双层的。使用 sudo 是因为我那个 Debian 的 dumpcap 没有特权。

这是我查看知乎私信时不小心瞅到的问题所触发的。由于 Go 在国内的兴起，我对这个问题也多有思考，就放在这里记录一下好了。知乎的链接我就不贴了，带 nofollow 的都懒得贴了。

首先，我们搞清楚问题是什么。或者说，我反对的究竟是什么？

静态链接，即早期唯一的一种链接出二进制可执行文件的方式，把所有程序需要用到的库全部打包到一个文件里边。后来，由于存储空间越来越不够用，所以发展出了动态共享库，也就是把库编译成 so、dll 或者 dylib 这种由动态库装载器在程序运行前或者运行时进行链接的方案。

静态链接的优点：

1. 方便分发，不会因为库的升级而导致程序无法运行。这一点没有严格指定依赖版本的 Arch Linux 用户应该都有所体会。当你更新某个库（比如 boost 或者 icu 什么的）之后，动态链接到旧库的程序会出错。

2. 效率稍高。这个反正人类是体会不到的。

基于第一点，用于急救的重要程序最好使用静态链接，特别是 busybox。以前我会安装 busybox 的，后来因为 Arch 改用动态链接 C 库了，对于我不再有意义，所以卸载了。以后 C 库如果出问题就直接重启进救援系统了。

另外我还有静态链接的 32 位 Vim，为的是在 Vim 依赖库更新而 Vim 没更新时依旧有个顺手的编辑器可用。我一直自行编译 Vim 因此这个曾经十分有用。不过由于现在对经常变动导致问题的解释器支持采用运行时动态链接，所以基本不受影响了。

静态链接的缺点：

这个可以列出长长的一串了。

1. 占用磁盘空间。我就不怎么喜欢 Haskell 写的程序，太占硬盘了，一个程序就几十M。当然换新电脑之后目前硬盘空间有富余。但是它们还是会渐渐被我的各种源码和虚拟机什么的填满的。

2. 占用内存空间。可执行文件在执行时是需要映射到内存中的。如果使用动态链接，那么因为是同一文件，所以在内存时只需要映射一份就可以了。而静态链接，不仅因为来源于不同的文件而需要加载、映射多次，而且因为来自于不同的构建等原因，逻辑上相同的代码往往并不会造成映射之后的内存页相同，使得内存去重机制（如 UKSM）失效。

   别说内存是白菜价，除非你来给我手上的笔记本、VPS、服务器、路由器、单板机等都配置个几十G的内存，我付给你等质量的白菜。还记得比尔·盖茨说过的话吗——「640K足够了」。够了吗？

3. 占用 I/O 带宽。可执行文件越大，在内存里没有缓存时需要从外存读取的数据也就越多，耗时也就越长。而因为文件体积增大，内存资源越发不够用，I/O 缓存越少，导致缓存命中更低。

4. 占用网络带宽。你可执行文件是从网上下的吧？你在国内看个视频还挺流畅，但是到世界各地去下软件你试试看？

5. 运行时链接。我写了一个程序，支持 MySQL、SQLite3、PostgreSQL、MongoDB、Oracle 等等等等数据库。但是你显然不会用到所有的数据库支持吧？那你为什么要所有这些数据库的连接库来用一个 SQLite3 数据库的功能呢？使用运行时链接（dlopen 那些函数），程序可以在运行的时候动态判断并加载它此次运行所需要的动态库。

6. 升级。openssl 爆出了一个很严重的安全漏洞，已经被修复了，你怎么办？当然是升级呗。那你希望是更新一个几M的包然后重启服务器解决问题，还是下载好几百M的程序、更新每一个你所用到的使用了 openssl 的程序？更何况那些程序本身不一定都更新了，也许为了安全你得自行编译其中的很大一部分（你可以期望有一个安全团队在半夜爬起床去更新一个软件，但是你觉得上千项目的开发者都会这么做吗）。你也不一定能够找到所有静态链接了有漏洞的 openssl 版本的程序，万一漏掉一个，你整个服务器的安全性就没了（所以 openssl heartbleed 漏洞更新之后建议是重启系统而不是重启各服务）。

更别说更底层的库了，比如 C 库或者 C++ 库。不至于人家更新了一行代码，你就要重装整个系统吧？

静态链接有它自身的用处，但是它并不适合所有情况，甚至并不适合大多数情况。动态链接以其微小的运行效率损失为代价，为不论是最终用户还是开发者、打包者提供了更为优秀的库管理方案。之所以很多人看到静态链接相对于动态链接的优势，我认为还是因为他们没什么机会看到静态链接、尤其是大量静态链接会带来的问题。

你不需要把程序都静态链接。你需要的只不过是一个优秀的包管理器和维护团队而已。