首先在 remix 配置文件 remix.config.js, 服务端启动文件 server.js 的后缀由
.js 改成 mjs，然后在 remix.config.mjs 中，将 serverModuleFormat 的值改
成 cjs。

然后在 package.json 中，去掉 type: "module"，并将 scripts 里的 server.js 全部改成 server.mjs。

这样改了之后，使用 npm run dev 可以正常启动开发环境了，但会发现修改文件时没有
HMR 没有生效，在改成 CJS 前是正常的。

通过一番查找后，发现是 CJS 加载缓存导致的。

在 server.mjs 中使用 import() 来加载 CJS 格式的模块 build/index.js 时，
缓存了该模块。原来使用 ESM 格式，可以通过改变加载文件的 query string 的方式刷新
缓存（即在 ESM 加载中由于 URL 不一样而认为是一个新的模块了），但在 CJS 中这种方
式失效了，在 CJS 加载中，该模块最后会缓存在 require.cache 里，这里 cache 是以
文件绝对路径为 key 来缓存了，所以改变文件的 URL 但没有改变文件路经是无法刷新缓存的。
如果要刷新该模块，必须要删除这里的缓存。

在是启动 npm run dev 时，server.mjs 是以 ESM 格式加载了，而 require 变量在
ESM 模块中不存在。虽然可以将 server.mjs 同样转换回 CJS 模块，但改动有点多。
还好在 node:module 内置模块中，提供了一个创建 require 的函数变量：createRequrie，
通过新建一个 require 来加载 CJS 模块，这样改动就小得多了。

首先在 server.mjs 的开头引入 createRequire 函数来创建 require 变量：

import {createRequire} from "node:module";
const require = createRequire(import.meta.url);

然后将 reimportRemixServer 函数替换成以下内容：

async function reimportServer() {
  for (const key of Object.keys(require.cache)) {
    if (key.endsWith(BUILD_PATH)) {
      delete require.cache[key];
    }
  }
  return require(BUILD_PATH);
}

这样就可以 remix v2 的默认服务器端模块格式改成 CJS 了。

一般我们在使用 KVM/QEMU 虚拟机时，都是需要创建一个 block 设备，然后格式化成文件系统作为里面的主文件系统（rootfs）来使用的。但这里有个问题，就是在创建设备文件时，需要预先设定该 block 设备的大小，一旦设置好，在使用过程中如果发现空间不足需要扩容，修改起来就不是那么方便了。

使用虚拟机的另一个问题就是怎么便捷地与宿主机交换文件，通常情况下会使用 nfs/smb 这些网络文件系统协议，但这需要先部署它们 才能使用，没办法做到开箱即用。

通过搜索发现有两种方案可以实现共享宿主机的目录给虚拟机用，分别是 virtio-fs 和 9pfs，virtio-fs 需要先启动 virtfsd 服务，通过 libvirt 来启动虚拟机时如果配置了共享目录，会自动启动该服务，但通过 qemu 直接启动虚拟时就需要手动启动 virtfsd 了。而 9pfs 则没有这个问题，是 qemu 内置支持的，也就是本文要介绍的方案了。

在两三年前，我就已经折腾过 9pfs，但那时只是试用了下就没有继续用了，印象中应该是有两个问题。

其中一个问题是文件在宿主机与虚拟机中的权限映射问题，例如有在里面用 root 用户创建一个文件，它在里面的 owner 是 root，那在外面应该是什么？这里 QEMU 提供了 security_model 参数用于控制，它的值分别是 passthrough, mapped(mapped-xattr), mapped-file, none，其中 mapped 在是将文件属性（的映射）保存在文件 xattr 属性里，mapped-file 则保存在独立的 .virtfs_metadata 文件夹内，而 none 和 passthrough 则不进行映射，none 的话相当于在虚拟机内创建的文件的 owner 为属主机的，并且无法使用 chown 来修改，passthrough 类似，但可以修改，这就要求 qemu 使用 root 权限来运行了，否则 chown 时提示权限不足。mapped 或者 mapped-file 选项对于有一点洁癖的我来说，是不希望有额外的信息写入到文件本身以及多余的是目录上的。而且这里有个很大的问题的，在宿主机上创建的文件，由于没有这些附加的属性，好像在虚拟机内是有问题的（太久的也忘记当时测的时候是什么问题了）。比较理想的是使用 passthrough 选项，使用该选项通常需要 root 权限运行 qemu，而且在虚拟机内如果使用 root 创建的文件，在宿主机上也是显示为 root owner 的文件，这样宿主机上普通用户要看的话也不方便。

而另一个问题是当时好像 linux kernel 还不支持 9p 作为 rootfstype 使用。

最近在 google 上搜索时，发现了 9p_root_fs 这个 wiki，这第二个问题来起来已经解决。而刚好最近研究了下 user namespace，发现可以使用 unshare 将当前宿主机上的普通使用切换到 root 来运行，这样对于第一个问题也比较好的解决了。

下面将以安装 Arch Linux 为例，主要参考的是 9p_root_fs，这 wiki 使用安装 debian 来例。

先确认下 /etc/subuid 及 /etc/subgid 里已经有当前用户的 subuid 及 subgid 的 map 配置：

<CURRENT_USER>:10000:65536

<CURRENT_USER>:10000:65536

下载好 Arch Linux 的安装镜像，然后运行：

unshare --map-auto --map-root-user \
qemu-system-x86_64 -machine pc,accel=kvm,dump-guest-core=off -m 2048 \
  -smp 4,sockets=1,dies=1,cores=4,threads=1 -rtc base=utc \
  -boot d -cdrom ./archlinux-x86_64.iso \
  -fsdev local,security_model=passthrough,id=fsdev-fs0,multidevs=remap,path=$PWD/base \
  -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=fs0

其中 ./archlinux-x86_64.iso 为下载的安装镜像，path=$PWD/base 配置的分享目录当前目录下的 base 文件夹。

运行后在弹窗的窗口中选择第一项，回车，进入命令行。

先挂载 9pfs 到 /mnt 目录上：

mount -t 9p -o trans=virtio,version=9p2000.L,posixacl,msize=5000000,cache=mmap fs0 /mnt

然后就可以将基础包安装到 /mnt 目录了：

pacstrap -K /mnt base base-devel linux vim man-db man-pages

装完之后运行 arch-chroot 切换到 /mnt：

arch-chroot /mnt

进行一些基本的配置，这个跟传统的 Arch Linux 安装类似，可以参考 https://wiki.archlinux.org/title/Installation_guide

然后在配置 initramfs 时将 9p 的相关模块配置进去，修改 /etc/mkinitcpio.conf 里的 MODULES=() 为：

MODULES=(9p 9pnet 9pnet_virtio)

保存，然后使用 mkinitcpio -p linux 重新生成 /boot/initramfs-linux.img。

initramfs 文件生成好后，运行下 passwd 修改好密码，安装就算完成了。这时可以退出 chroot 环境，然后运行 systemctl poweroff 关机了。

现在可以运行以下命令来启动系统了：

unshare --map-auto --map-root-user \
qemu-system-x86_64 -machine pc,accel=kvm,dump-guest-core=off -m 4096 \
  -smp 4,sockets=1,dies=1,cores=4,threads=1 -rtc base=utc \
  -boot strict=on -kernel $PWD/base/boot/vmlinuz-linux \
  -initrd $PWD/base/boot/initramfs-linux.img \
  -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=5000000,cache=mmap,posixacl console=ttyS0' \
  -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=$PWD/base \
  -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \
  -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny

启动后需要配置下网络，分别开启 systemd-networkd 和 systemd-resolved 服务：

systemctl enable --now systemd-networkd.service
systemctl enable --now systemd-resolved.service

编辑 /etc/systemd/network/20-wire.network，添加以下内容：

[Match]
Name=ens*

[Network]
DHCP=yes

保存，然后运行下 networkctl reload 使配置生效。

NOTE: 如果在安装完成后在安装某个包时出错安装不了，可以先运行下 pacman-key --populate 更新下 key

首先，这里的网站跳转、弹窗、唤起 APP 都是指在非用户的意愿下、擅自将用户带离当前
页面，跳转到或弹出一些广告、推广的页面或唤起 APP 来执行一些广告或推广操作。
主要目的是获取广告展示或点击的收益、下载安装推广软件（APP）的收益以及唤起 APP
获取其举办的活动收益。

上面的这些行为可以分为主动跟被动的。主动指是网站自己加入相关代码来触发，这种一般
出现在一些垃圾站上。被动是指网站被植入了恶意代码而触发的，这种情况可能是网站自己
并不知情的，但能发生这种情况，说明存在安全漏洞，或者安全方面做得不到位，导致网站
的流量被劫持了。

流量劫持，有可能发生 ISP 的通信设备上，还有可能在用户的路由器、电脑里（被安装了恶意软件）。

流量劫持是如何发生的呢？

先简单说下我们打开一个网站，其背后所发生的一个过程。

在浏览器中，从我们输入一个链接（URL），按回车后。

首先浏览器会将链接的域名部分提取出来，进行域名解析，以得到一个 IP 地址。

这里可能会发生第一次被劫持：DNS 劫持。那 DNS 劫持是如何发生的呢？

域名解析时，操作系统一般会向指定的 DNS 服务器请求解析，这个 DNS 服务器地址一般
是由 ISP 提供，也可以由自己来设置。如果操作系统的 DNS 服务器设置被恶意篡改了，
当系统向恶意的 DNS 服务器请求解析时，返回的 IP 地址可能已经不是真正的链接网站
的 IP 地址了。这样连接访问的内容就被劫持了。

另外还有一种 DNS 劫持，发生在我们向 DNS 服务器请求后，在 DNS 服务器返回结果到达
我们的操作系统前，中途被链路上经过的有关设备抢先返回了。由于 DNS 协议的缺陷，导
致我们的操作系统先接受了先返回 IP 地址。

我们得到 IP 地址后，浏览器会向 IP 地址发起建立 TCP 连接请求。在连接建立后，如果
我们的链接是 http:// 开头的，会直接发起 HTTP 请求，但由于 HTTP 协议是明文
（plaintext）协议，这就可能会发生被劫持。同样的，可以劫持 HTTP 请求的，还可能是
链路上途经的设备。如果本地路由器或终端被植入了恶意软件，或浏览器安装了恶意扩展
（插件），也就可能劫持 HTTP 请求的。

如果链接是以 https:// 开头，在建立 TCP 连接后，会先在其上面建立一条加密的安全
隧道，即（SSL/TLS）。TLS 的建立需要向服务器端请求包含该链接的域名的证书，浏览器
在拿到证书后，通过浏览器或系统内置的根证书对其证书校验。只有校验通过后，TLS 才
成功建立，如果校验不通过，浏览器会直接拒绝该连接。

在建立 TSL 连接后，浏览器就可以安全地向服务器发起 HTTP 请求了，因为连接是经过加
密的，所以沿途的设备就无法对其进行劫持了。但是，如果浏览器安全了恶意的扩展（插
件），还是可以对其内容进行篡改的。

上面的废话好像有点多了 :)，还是进入本文的主题吧。

先交待下背景。

最近这几天（2020-08-05），使用手机的浏览器（Firefox）打开知乎的链接时，总是会跳
转到一个淘宝的商品列表页面，看了下这个页面的链接，发现带有一个 pid 参数，熟悉
淘宝客的同学应该都知道，这是一个带有返利推广的页面来的。我心想，知乎不会缺钱到
这种份上吧，这种严重影响到用户体验的骚操作一般只会在一些垃圾站出现的。在带有这
样的疑问下，也就有了这样一篇文章，算是做下笔记吧。

其实，我最先怀疑的对象并不是知乎，而是电信运营商，会什么呢，有经验吧 ;)，这种事
在几年前是经常发生的，特别是在一些小的 ISP 上，或者在农村（有一段时间我就亲身经
历过）。不过现在由于 HTTPS 的普及，以及其他一些情况，这种事基本上已经消失了。

那现在这种是什么情况呢？

由于手机端查看不了请求，而刚好我手机端的 Firefox 版本是 68，
无法在 PC 的 Firefox 上使用 Remote Debugging，因此这里使用 chromium 来测试。

打开 chromium，按 F12 打开 DevTools，开启模拟移动端的 UA ，打开从手机端复制过来
的知乎的链接，发现可以成功复现了。

先检查知乎链接的 HTTPS 证书，发现证书是知乎的（如下图），因此这里就排除了电信运营商嫌疑了。

问题回到知乎上来，先从 HTTP 请求以及源码入手分析。

从地址栏右侧显示的拦截弹出窗口的提示图标里找到了具体的弹窗链接：

鼠标移到链接上，显示的完整地址为：https://api.ad.scjcgj.top/api/jump/tongji?mid=jump_193

用 whois 查了下这个 scjcgj.top 域名，发现经过隐私保护了。

来到 DevTools 窗口中，点击 Network 切换到 Network 面板。

先设置下界面，以方便分析。点击面板右边的设置图标按钮，然后按下图来进行设置：

然后在列表的表头处右键，弹出的菜单选项按如下设置：

经过设置后，我们就很容易的找到跟上面链接接近的域名（ad.scjcgj.top）了：

从上图可以看出来，这是一个 JS 文件，由 https://www.zhihu.com/natsume/ruoying_m_banner.html 引入。

这个 https://www.zhihu.com/natsume/ruoying_m_banner.html 就是这次问题的根源了，但先不说这个。

点击一下该行，在弹出的窗口里可以看到该请求的详情窗口。

我们切换到 Response 标签，直接查看它的源码。

这里有点意思，不知道他们是不是故意的，这里有一段已经被注释的代码，它看起来像是
正常的广告代码来的，而未注释的代码与它的功能基本一样，都是创建一个 iframe，并加
载一个链接。个人猜测，注释掉的代码应该是为了应付审核用的吧，在审核通过后，就
直接加载恶意的代码了。

我们继续分析这个 iframe 加载的链接，这个链接的域名是 api.ad.scjcgj.top，因为是
iframe 加载的，DevTools 经过上面的设置后，很容易就可以找出来了。

点击弹出详情，切换到 Response 标签查看源码，这里的代码比较正常，需要继续分析它
加载的 JS，但这里加载的比较多，一个一个的看有点麻烦。不用担心，点击旁边的
Initiator 标签，是不是发现了点什么？

这里列出页面 https://api.ad.scjcgj.top/api/report/get?cid=md-1000193&t=&h=144
里所有请求的请求链，并且已经按调用关系层级地排列好了。

如果注意看的，可以看到最后的三行的链接比较异常，这是一种自定义的协议链接，如果
应用在系统里注册了某个自定义协议，在浏览器里打开这个自定义协议的链接，就会调用
这个应用来处理这个链接。简单地说，也就可以通过点击这个链接来唤起该应用。在移动
设备为王的国内互联网环境里，这种方式已经用得炉火纯青了。

看开头的协议，我猜这三个链接分别是调用 alipay、新浪微博、以及淘宝的 APP 来的，具
体作用这里就不分析，有兴趣的可以去研究下。

从图中可以看到这三个链接都是由 JS https://c.sl.chenshengyu.cn/test/aw193.js (whois chenshengyu.cn）调用请求的。
找到这个 JS 并查看里面的内容，发现上面的三个链接是服务器端配置分发的，由接口 https://api.sl.chenshengyu.cn/api/ip/get4?cid=zhihu1
返回。这里还“人性化”地设置了时间控制，在 12 小时内，只调用一次，我猜这样可能就
不会引用用户的警觉吧。

按理说，到这里算是分析完成了，但回头看下，好像还没找到前面所说的那个弹窗的出处呀。

继续分析。

回到前面那张图里，除了 https://c.sl.chenshengyu.cn/test/aw193.js 之外，看起来比较
异常的 JS 还有（其他的几个其中一个是引入 JQuery 库，以及 cnzz 的统计代码）：

• https://ad.scjcgj.top/wap/script/md/md-1000193/ad/2/index.js
• https://ad.scjcgj.top/wap/script/md/md-1000193/b/?v=410fd1c92f660cfc4adb84b9928ac22a
• https://ad.scjcgj.top/wap/script/md/md-1000193/e/

我们一个一个来看：

https://ad.scjcgj.top/wap/script/md/md-1000193/ad/2/index.js 这个 JS 也创建了一个 iframe。
加载的链接为 https://ad.scjcgj.top/wap/script/md/md-1000193/ad/2/ad.html，查
看了里面的内容，看起来比较正常。

https://ad.scjcgj.top/wap/script/md/md-1000193/b/?v=410fd1c92f660cfc4adb84b9928ac22a 这个 JS 的
内容看起来就比较流氓了：

这里代码的意思是当你按回退键时，它会阻止你回退到上一页，直接将你带到它指定的页面里去。

https://ad.scjcgj.top/wap/script/md/md-1000193/e/ 终于从这个 JS 里找到开头说的
那个弹窗自动调用的代码了：

现在回过头来看下，发现这些网站耍起流氓来手段无所不用其极呀。不过，这个网站能乘
上知乎这辆流量大巴，我觉得还是知乎安全方面做得还不够好，让它能够有可乘之机。很
明显的，你在一个主域名的页面里（https://www.zhihu.com/natsume/ruoying_m_banner.html）引入
一个这样的不受控、看起来明显不正常的第三方域名的 JS，这相当于用户对于它来说是完
全透明的。这次它用在恶意弹窗方面可能对用户造成不了什么损失，但如果哪天它用这个
来窃取用户信息，造成的损失谁来买单呢？（PS：这让我想起之前看到过不少新浪微博的
用户无缘无故多了很多未知的关注，这里面是否有类似的问题呢？）

最近需要在一台 Linux 的 PC 上访问 Wikipedia，但不好在这台电脑上安装一些软件。刚
好自己的手机开启了 VPN 可以正常访问到 Wikipedia。然后无意间在浏览 ssh man page
时，看到可以在 Android 机上使用 ssh 的 -R [bind_address:]port 选项来开启一个
SOCKS5。这样一来，似乎就可以在 PC 上通过 SOCKS5 转发请求到 Android 机上，然后
再通过 Android 开启 VPN 来访问 Wikipedia 了。经过测试，可以正常工作，以下是折腾
过程。

PC 上确保已经开启了 sshd 了：

systemctl status sshd.service

Android 上，首先需要在 Android 安装一个 termux 的终端模拟器，这个可以通过
F-droid 或 Google Play Store 来安装。

然后打开 Termux 进入 Termux 命令行内，输入以下命令来安装 ssh 客户端：

pkg install openssh

安装成功后，就可以通过以下命令来连接到 Linux 的 PC 机上，并为 PC 机开启一个
SOCKS5 服务器，这样在 PC 机上就可以连接这个 SOCKS5 服务器了：

ssh -CNTR localhost:8080 {USER}@{HOST}

其中 {USER} 为 PC 机上的用户名，{HOST} 为 PC 机的 IP 地址。

连接上后，开启 Android 的 VPN，然后就可以在 PC 机上使用 socks5://localhost:8080 了。

NOTES:

• 如果 Android 机上安装了 AFWall+ 等防火墙应用，需要开启 Termux 可以通过 VPN。
• 如果想使用随机端口，可以把 8080 改成 0，连接后会在终端显示分配的端口号。
• 默认绑定到 127.0.0.1 和 [::1]，如果想绑定其他地址，可以加上指定的 IP 地址。
• 可能会由于手机熄屏而导致连接中断，这时，可以在手机的通知栏 Termux 下点击 ACQUIRE WAKE LOCK。

本文的操作在 Arch Linux 下进行，没有在其他 Linux 发行版下测试过，因此无法保证其他的 Linux 发行版也可以正常工作。

首先生成相应的公私钥

生成主密钥

gpg --full-gen-key --expert

PS: 这里因为要生成 ECC 类型的密钥，因此需要使用 expert 模式才可以

Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(9) ECC and ECC
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(13) Existing key
Your selection? 10

主密钥，这里选择 (10) ECC (sign only)。

Please select which elliptic curve you want:
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1
Your selection? 1

选择 EC 曲线，这里选择 (1) Curve 25519。

Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)

选择有效期，可以根据实际情况来选，默认为永不过期。

Real name:
Email address:
Comment:

这里是一些个人信息，根据实际情况来写。

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

输入完后，确定没问题后，键入 O 来完成。

之后会提示你创建 passphrase。

完成后，可以使用 gpg --list-keys 来查看上面创建的密钥：

/home/example/.gnupg/pubring.gpg

pub ed25519 2019-03-13 [SC]
4C531B4CE9A26E80BECE72EC3453101C9E098A57
uid [ultimate] Colin Cheng zbinlin@outlook.com

可以加上参数 --keyid-format <FORMAT> 来查看密钥 ID，这会在下面的步骤里用得到。

创建 ssh 登录密钥

上面操作创建了主密钥，接下来，我们可以在主密钥下创建用于 ssh 登录的子密钥。

从上面的 gpg --list-keys 列出了刚创建的主钥密的 fingerprint 为 4C531B4CE9A26E80BECE72EC3453101C9E098A57，我们可以使用以下命令进入交互模式来添加子密钥：

gpg --expert --edit-key 4C531B4CE9A26E80BECE72EC3453101C9E098A57

NOTE: --expert 必须放在 --edit-key 前面才可以生效

执行上面的命令后，将进入交互模式：

gpg>

键入 addkey 回车，来创建子密钥：

Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
Your selection? 11

由于我们需要创建的是用于 ssh 登录的密钥，因此这里选择 11，来创建具有 Authenticate 功能的密钥：

Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions: Sign

(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished

Your selection? S

这里我们不需要这个密钥用于 Sign，因此可以键入 S 取消 Sign，然后再键入 A 添加 Authenticate，最后键入 Q 进入下一步。

Please select which elliptic curve you want:
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1
Your selection? 1

这里同样选择 Curve 25519 曲线。

Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)

然后是选择有效期。

Is this correct? (y/N) y
Really create? (y/N) y

不断确认，最后回到

gpg>

这里，需要键入 save 保存并退出。

这时，如果使用 gpg --list-keys 命令：

/home/example/.gnupg/pubring.gpg

pub ed25519 2019-03-13 [SC]
4C531B4CE9A26E80BECE72EC3453101C9E098A57
uid [ultimate] Colin Cheng zbinlin@outlook.com
sub ed25519 2019-03-13 [A]

可以看到多了最后一行

sub ed25519 2019-03-13 [A]

这就是用于 ssh 的登录的子密钥，其中 sub 表示是 subkey，A 表示是 Authenticate。

类似的标志：

C: Certify
S: Sign
A: Authenticate
E: Encrypt

设置

在生成用于 ssh 登录的密钥后，还不能直接使用，需要先进行一些设置。

首先设置 SSH_AUTH_SOCK 环境变量。

在 ~/.pam_environment 文件里加入以下内容：

SSH_AGENT_PID DEFAULT=
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"

另外需要在 ~/.bashrc 或 ~/.zshrc 中加入：

export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye >/dev/null

如果使用 xfce4 作为图形界面的，由于 xfce session 会自动设置 ssh-agent，会导致上面设置的 SSH_AGENT_PID 和 SSH_AUTH_SOCK 在进入 X 后被重置（被重新设置成 ssh-agent 了），因此需要在 xfce 里禁用自动设置 ssh-agent 这个功能：

xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false

以上都设置完后，需要将上一步创建的 ssh 密钥添加到 GnuPG 的 $GNUPGHOME/sshcontrol 文件里。

首先通过 gpg --list-keys --with-keygrip 4C531B4CE9A26E80BECE72EC3453101C9E098A57 查看刚才创建的密钥的 keygrip：

pub ed25519 2019-03-13 [SC]
4C531B4CE9A26E80BECE72EC3453101C9E098A57
Keygrip = 7344328D1A4D5CDA50C6FA8B16133F744CD23FBA
uid [ultimate] Colin Cheng zbinlin@outlook.com
sub ed25519 2019-03-13 [A]
Keygrip = 35FD15CAE509225DDDACF98301526EB300415765

其中在子密钥下面的 35FD15CAE509225DDDACF98301526EB300415765 就是 ssh 密钥的 keygrip 了。

将其加入到 $GNUPGHOME/sshcontrol 里就可以了。

加好了之后，就可以通过以下命令把公钥导出来放到服务器上了：

# 找到 ssh subkey 的 id
gpg --list-keys --keyid-format long
# 导出公钥
gpg --armor --export-ssh-key 7FC2C4F53913F8FD

另外，也可以用类似创建 ssh 密钥的方式，创建一个用于 git 代码签名的 Sign 子密钥。

参考

• https://wiki.archlinux.org/index.php/GnuPG
• https://docs.xfce.org/xfce/xfce4-session/advanced

WireGuard 安装

在使用 WireGuard 之前，需要分别在服务器和本地安装。

由于本人的服务器上使用 debian 9、本地使用 Arch Linux，因此这里只给出这两种系统上的安装方式，其他系统上的安装可以在官网找到。

Debian

echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 150\n' > /etc/apt/preferences.d/limit-unstable
apt update
apt install wireguard

Arch Linux

pacman -S wireguard-dkms wireguard-tools

WireGuard 配置

WireGuard 的配置分为 Interface 和 Peer，其中 Interface 可以认为是对本地机器的配置，而 Peer 是配置连进来的机器的

在服务器和本地的大部分配置是一样的，先添加一个接口：

ip link add wg0 type wireguard

如果报错，并提示 RTNETLINK answers: Operation not supported，先检查下 wireguard 模块是否已经加载：

lsmod | grep wireguard

如果没有加载，试下执行 modprobe wireguard，如果报错，重启下机器。

在服务器端为 wg0 添加一个地址 192.168.128.1/24

ip addr add 192.168.128.1/24 dev wg0

同样在本地为 wg0 添加另一个地址 192.168.128.254/24

ip addr add 192.168.128.254/24 dev wg0

然后分别在服务器和本地添加 private key

wg set wg0 private-key <(wg genkey)

如果是要用 sudo 来执行的，需要使用以下命令：

sudo bash -c 'wg set wg0 private-key <(wg genkey)'

为服务器添加一个监听端口，本地使用随机端口就行了，不需要固定端口：

wg set wg0 listen-port 12345

以上是 Interface 的设置，下面配置 Peer。

首先在服务器上加入本地的 Peer：

需要添加本地的公钥，可以在本地通过以下命令获取：

wg show wg0 public-key

获取到公钥后，还要获取本地 wg0 上的 IP 地址（192.168.128.254）加入到 perr 的 AllowIPs 里：

wg set wg0 peer '<本地的公钥>' allowed-ips <本地 wg0 上设置的 IP 地址，如 192.168.128.254/32>

同样，把服务器上的公钥加入本地，这里要把服务器的外网 ip 作为 endpoint，这里以 wireguard.example.org 为例，要不本地就不知道连那台服务器了：

wg set wg0 peer '<服务器上的公钥>' allowed-ips 0.0.0.0/0 endpoint wireguard.example.org:12345

注：这里 allowed-ips 使用 0.0.0.0/0，这样相当于 wireguard 全局生效。

现在 wireguard 的配置基本配好了，可以通过以下命令来启动：

ip link set dev wg0 up

启动 wg0 接口，这时可以 ping 下服务器端的地址 ping 192.168.128.1，如果 ping 通说明 wireguard 正常工作了。
如果 ping 不通，检查下对方的公钥及 ip 地址是否正确了。

现在本地跟服务器已经在同一个内网上，可以彼此通信了。
但本地现在是无法通过服务器连接到外面的网络，如果需要通过服务器连接到外面的网络，要在服务器上设置流量转发和 NAT 才可以。

转发与 NAT

首先，检查下 ip 转发是否已开启：

sysctl net.ipv4.ip_forward

如果等于 1 说明已经开启，否则可以使用：

sysctl net.ipv4.ip_forward=1

来临时开启，如果想永久生效，需要编辑 /etc/sysctl.conf 文件，查找到 net.ipv4.ip_forward 这一行，把最前端的 # 号（注释）去掉，如果其值不为 1 的，改成 1。如果找不到，就把 net.ipv4.ip_forward=1 加在文件最下面。

然后使用命令 sysctl -p 来使其生效。

接下来检查下 iptables 里 filter 表的 FORWARD 链的 policy 是否为 ACCEPT：

iptables -t filter -L FORWARD

如果 policy 为 DROP，需要允许 wg0 接口才行：

iptables -t filter -A FORWARD -i wg0 -j ACCEPT
iptables -t filter -A FORWARD -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT

然后看下 nat 表的 POSTROUTING 链里是否已经做了出口的 NAT 了（这里假设服务器上连接外网的接口是 eth0）：

iptables -t nat -L POSTROUTING -v

如果还没有，使用以下命令加上：

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

PS：如果出口不是 eth0 接口的，把 eth0 换成正真的出口接口

在服务器设置好后，还要在本地加上路由，把流量转发到 wg0 接口上。

本地路由

ip route add <endpoint>/32 via <出口接口的网关IP> dev <出口接口>
ip route add default via 192.168.128.1 dev wg0 src 192.168.128.254

配置好后，可以在本地 ping 下 8.8.8.8，如果 ping 的通，并且 tracepath 8.8.8.8 的路由里有 192.168.128.1，说明已经通了。

wg-quick

通过这样配置后就可以使用 WireGuard 作为 VPN 上网了，但当前配置会在重启后失效。

如果每次重启都手动配置的话，比较麻烦。还好，WireGuard 提供了 wg-quick 命令，该命令可以读取和保存配置文件。

并且 wg-quick 也提供也 systemctl 的服务配置，这样可以设置开机自启动。

wg-quick 默认的配置目录为 /etc/wireguard，文件以 wireguard 的接口名（如上文中的 wg0）为文件名，文件名后缀为 .conf。

以下分别是服务器和本地的配置文件，保存到 /ett/wireguard/wg0.conf：

服务器：

[Interface]
Address = <服务器上设定 wg0 接口的地址，如：192.168.128.1/24>
PrivateKey = <使用 `wg-genkey` 生成的私钥>
ListenPort = <服务器上 wg0 监听的端口，如：1234>

[Peer]
PublicKey = <本地的公钥，可以使用 `echo <本地私钥> | wg-pubkey` 生成>
AllowedIPs = <本地 wg0 接口上的地址，如：192.168.128.254/32>

本地：

[Interface]
Address = <本地设定 wg0 接口的地址，如：192.168.128.254/24>
PrivateKey = <使用 `wg-genkey` 生成的私钥>

[Peer]
PublicKey = <服务器的公钥，可以使用 `echo <服务器私钥> | wg-pubkey` 生成>
AllowedIPs = 0.0.0.0/0
Endpoint = <服务器外网地址:服务器上 wg0 监听的端口，如：0.1.2.3:1234>

配置好后，可以使用 wg-quick up wg0 来启动（注意，如果你按照了上面 [WireGuard 配置](#WireGuard 配置) 命令手动配置过，需要先删除 wg0 接口和对应的路由才行）。
如果测试没问题后，可以使用 systemctl enable wg-quick@wg0.service 来设置开机自启动。

优化国内外流量

通过上面设置好后，虽然可以通过 WireGuard VPN 上网了，但有个问题，这个 VPN 是全局性的，即所有的流量都会从 VPN 里出去。
如果服务器在美国的话，在上国内的网站时，会绕了一圈，延时非常大。这时，我们可以通过策略路由的方式，分流国内外的流量，使国内的流量不用走 VPN。

在上面通过 wg-quick 启动过，如果本地配置里 AllowedIPs 设置了 0.0.0.0/0，意思是全局生效，其主要也是通过策略路由来实现的。

下面是 wg-quick 启动时的日志：

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 192.168.128.254/24 dev wg0
[#] ip link set mtu 1420 dev wg0
[#] ip link set wg0 up
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

以上的日志信息可以看出是条条命令来的，通过这些命令，大概可以猜得出 wg-quick 是如何启动的：

首先使用 ip link add wg0 type wireguard 添加一个名为 wg0、类型为 wireguard 的虚拟接口；

然后通过 wg setconf wg0 /dev/fd/63 加载配置，从 /dev/fd/63 可以看到，配置应该是通过 process substitution 的方式加载进来的；

ip address add 192.168.128.254/24 dev wg0 这条命令上面也提到过，就是为 wg0 接口添加一个 IP 地址的；

ip link set mtu 1420 dev wg0 设置 wg0 接口上的 IP 包的 mtu 值；

ip link set wg0 up 启动 wg0 接口

wg set wg0 fwmark 51820 为 wg0 接口上的包添加一个 fwmark 值，主要为了下面命令里策略路由用的；

ip -4 route add 0.0.0.0/0 dev wg0 table 51820 为一个 id 为 51820 表添加默认的路由，该路由的通过 wg0 接口

ip -4 rule add not fwmark 51820 table 51820 这条命令就是主要的策略路由，通过以上三条命令就可以实现全局的流量转发了。

由于策略路由是有优先级的，所以我们可以在把所有国内的 IP 段添加到优先于上面的这条策略路由，这样就可以不用经过 wg0 接口了。

首先要获取到国内的 IP 段，可以通过到 apnic 查询到国内的 IPv4 地址段。

该页面里的 IPv4 格式是：起始地址|地址数量，但 ip rule 要求 CIDR 格式格式，所以需要转换下。转换起来也挺简单，这里地址数量都是 2 的 n 次方，因此对其以 2 为底求地址数量的对数，然后用 32 减去其对数就可以了。

例如：

apnic|CN|ipv4|45.249.112.0|1024|20160511|allocated

起始地址是 45.249.112.0，数量是 1024，即 2^10，因此可转换成 CIDR 格式是：45.249.112.0/22，加入到策略路由就是：

ip rule add to 45.249.112.0/22 priority 1024

priority 1024 就是设置优先级的，数字小的优先级高

apnic 里的分配给国内的 IP 段比较分散，我统计了下，大概有 8 千多行。我们不可能手动添加的，因此我写了一个 Node.js 脚本 来下载 apnic 的最新分配版，然后转换下，可以导出成一个 shell 脚本来运行， shell 脚本里就是一条条上面的那种命令了。

虽然运行 shell 脚本后，把规则添加到策略路由里了，但这些路由规则也是运行时生效的，下次重启电脑后需要重新加载。这里可没有现成的自启动脚本，难道还要写个自启动脚本吗？

还好 wg-quick 里提供了相应的钩子，可以在 wg-quick 启动、关闭时执行一条 shell 命令，这样我们就可以把上面的 shell 脚本添加到 wg-quick 的配置文件里去了。这样就不详细写了，具体可以看这里的示例。

这里有个问题，由于 shell 脚本里的命令太多了，执行起来需要几秒的时间。

这里有个方案，就是先导入 shell 脚本一遍，然后使用 ip rule save 导出保存，在 wg-quick 里通过 ip rule restore 还原配置就可以了，这样速度很多，基本不用 1 秒就可以了。

但是在用 ip rule save 导出时，会把所有的规则都导出来了，包含了系统默认的和 wg-quick 添加的。再导入时，会出现规则重复或混乱的情况。至于怎么解决，这里就不展开说了，有兴趣的可以去研究下。

“智能” DNS

下面说下另一个问题。

众所周知，在国内，有些域名已经被污染了，使用运营商提示的 DNS 服务器解析出来的是不对的 IP。因此我们需要一个安全的 DNS 服务器，CloudFlare 就提供这么一组 DNS 服务器，其提供的 1.1.1.1 和 1.0.0.1 支持 DNS-over-TLS，可以有效的防止被中间人拦击污染。

但有个问题，在我这里访问 1.1.1.1 比较慢，ping 1.1.1.1 显示有 150ms 左右，如果所有的域名都通过 1.1.1.1 来解析的话，一些未被污染的域名访问起来会受到影响。

还好有网友维护了一个 ChinaGFW 的列表，里面包含了被污染的域名，刚好我本地已经搭建了 unbound 域名服务器，而且 unbound 支持 DNS-over-TLS，这样就可以把被污染的域名加入到 unbound 的规则里，把这些域名通过 1.1.1.1 来解析，其他域名还是走运营商提示的 DNS 来解析。

这里 是一个 unbound 配置文件，里面包含的被污染的域名从 ChinaGFW 里转出来的，里面的内容类似：

forward-zone:
    name: 'google.com'
	 forward-addr: 1.1.1.1@853
	 forward-addr: 1.0.0.1@853
	 forward-ssl-upstream: yes

name 表示被污染的域名，forward-addr 表示向上一级查询的 DNS 服务器，可以有多个，forward-ssl-upstream 表示开启 DNS over TLS 功能。
配置文件的最后使用

这是一个独立的配置文件，可以把它放到 /etc/unbound/ 下，然后在 /etc/unbound/unbound.conf 配置文件里加入 include: /etc/unbound/dns-over-tls.conf 来引入它。

加入后重启 unbound 服务就可以生效了。

最近将家里的路由器刷了 openwrt，当使用 ssh 连接路由器时，提示：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:............................................
Please contact your system administrator.
Add correct host key in /home/example/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/example/.ssh/known_hosts:1
RSA host key for 192.168.1.1 has changed and you have requested strict checking.
Host key verification failed.

这是由于之前在出租的房子里路由器同样是 openwrt，而且已经登录过并保存了该路由器的 RSA key fingerprint，导致与现在连接的路由器的 RSA key fingerprint 不匹配而冲突了。

最简单的解决方式是将之前的 fingerprint 从 ~/.ssh/known_hosts 里删除，但这样如果连接原来的路由器又会出现冲突。

这里可以在使用 ssh 连接时使用 -o 'UserKnownHostsFile /dev/null' 临时解决。

另外可以通过分别为不同的 host（这里是路由器）设置 HostKeyAlias 参数来区分开来，例如：

在连接出租屋里的路由器时，可以使用 ssh -o 'HostKeyAlias host1' root@192.168.1.1 连接，

在连接家里的路由器时，使用 ssh -o 'HostKeyAlias host2' root@192.168.1.1 连接。

但这样每次连接都需要添加这么长的参数，显得很麻烦，这时可以通过将参数添加到 ~/.ssh/config 里解决：

Host host1
    Hostname 192.168.1.1
    HostKeyAlias host1
    Port 22
    User root

Host host2
    Hostname 192.168.1.1
    HostKeyAlias host2
    Port 22
    User root

这样，就可以分别使用 ssh host1 和 ssh host2 来连接了。

最近，由于 Crissic Solutions 关闭了服务，导致我不得不又要去寻找其他便宜点的 VPS 了，刚好
hostdo
有优惠，有个 KVM 的套餐价格与之前 Crissic 的一样。因此有买了一年。

刚下订单后，服务没立即开通，可能需要审核，等了比较久，于是发了一个 Ticket，在第 2 天登录后，发现已经开通了。购买时机房选洛杉矶的，从广州 ping 了下 time
值只有 160-180ms 左右，已经不错了，之前的 Crissic 基本上在 200ms 以上的。

由于在下订单选择操作系统的时候，选择了 None (More OS available after provisioned) ，因此在开通后的服务还没有操作系统，需要登录 VPS Control Panel 后自行安装。于是通过它提供的 VPS Control Panel 登录链接以及用户名和密码来登录。

登录到 Control Panel 后，在界面上有个 Reinstall 的按钮，点击之后可以选择你想要
安装的操作系统。

由于之前在 Crissic 上的系统是 CentOS 6 32bit，内核比较旧，而且是 32 位的，使用起来非常不便，因此这次打算安装 CentOS 7 64bit。

由于该套餐的 VPS 的内存只有 512M，开始时还担心 64 位的系统占用内存比较大的，但安装成功后进入系统后看了下，发现只占用 60 多 M，这还可以接受。

在安装后发现了一个问题，整个分区只有 2G，这还需要对剩余的空间进行分区。但由于整个 / 分区太小了，而且 VPS 的磁盘空间只有 15G，因此打算只分一个区就行了。

既然只分一个区就只能重装系统了，回到 Control Panel 的主界面，在界面的下面有一个
CDRom 的 tab 页，点击切换过去后，在 Select 下面选择重装的系统 ISO（这里因为安装的是 CentOS 7，所以选择了 CentOS 7 x86_64 Minimal ISO），然后点击 Mount 按钮，在提示 mount 成功后，就可以在本地使用 VNC 客户端连接远程的 VPS，然后重启 VPS，VPS 会引导启动刚才 mount 的 ISO（如果重启后发现依然是引导到旧的系统的，可以在
Control Panel 的主界面下边的 Settings 标签页里，在 Boot Order 里选择 CDROM 优先的选项，然后重启 VPS）。

重装的过程非常缓慢，主要是由于网络的问题，以及安装的界面是一个 GUI 界面，导致
界面响应非常慢。比较搞笑的是，在真正开始安装时，界面上有个设置新账号的选项，
在我还未设置好账号，安装就已经完成了。

安装完成后，由于在安装时未设置 hostname，因此安装后使用：

hostnamectl set-hostname <your hostname>

来设置 hostname。

之后使用 yum update 来更新系统，但发现网络还未配置好（在安装时忘了配置了），于是使用 nmtui 命令来配置，该命令是一个 text GUI 界面，使用起来比较简单，因此这里就略过了。

更新成功后，安装 EPEL 和 SCL 源：

yum install epel-release centos-release-scl

接着安装 yum-utils，因为里面有个命令 yum-complete-transaction 可以修复在安装包的过程发现中断（比如安装软件时突然关机、死机了）时的 transaction 未完成的问题：

yum install yum-utils

由于需要使用 GCC 来编译一个 nodejs 的原生模块，因此安装了 Development Tools：

yum groupinstall "development tools"

安装 iptables-service 来控制 iptables 启用、启动、关闭等控制：

yum install iptables-services

然后开启以及启动：

systemctl enable iptables.service
systemctl enable ip6tables.service
systemctl start iptables.service
systemctl start ip6tables.service
systemctl status iptables.service
systemctl status ip6tables.service

现在需要导入新的 iptables 规则，如果不需要旧的规则，可以先清除掉：

iptables -t filter -F

然后导入：

iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A INPUT -p tcp -m tcp --dport 8822 -j ACCEPT
iptables -t filter -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -t filter -P INPUT DROP

对于 ip6tables，也同样地处理：

ip6tables -t filter -F
ip6tables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -t filter -A INPUT -i lo -j ACCEPT
ip6tables -t filter -A INPUT -p tcp -m tcp --dport 8822 -j ACCEPT
ip6tables -t filter -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
ip6tables -t filter -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
ip6tables -t filter -P INPUT DROP

（注：上面的 8822 端口是用于 ssh 服务的）

添加好后需要导出到 /etc/sysconfig/iptables 和 /etc/sysconfig/ip6tables，以
便重启后可以加载进来：

iptables-save > /etc/sysconfig/iptables
ip6tables-save > /etc/sysconfig/ip6tables

上面的操作都是在 VNC 上进行了，下面配置一下 sshd 服务，配好后就可以使用 ssh 来登录操作了。

首先，修改 /etc/ssh/sshd_config 配置文件，修改如下：

# 修改端口
Port 8822
# 启用公钥登录
PubkeyAuthentication yes
# 禁止空密码登录
PermitEmptyPasswords no
# 禁止密码登录（这一行现在先不改，在将公钥上传后再来修改
# PasswordAuthentication no

然后使用 systemctl restart sshd，但发现重启失败，原因是由于 selinux 不允许 sshd 使用 8822 端口：

grep sshd /var/log/audit/audit.log | audit2why

于是使用 semanage 为 sshd 添加 8822 端口：

semanage port -a -t ssh_port_t -p tcp 8822

（注：如果提示该命令不存在，可以安装 policycoreutils-python 包）

配好后，重新启动服务，就可以使用 ssh 来登录了。

在本地使用 ssh-keygen -t ed25519 -C vps -f ~/.ssh/<filename> 生成密钥，
然后使用 ssh-copy-id -i ~/.ssh/<filname>.pub <your vps ip> 将公钥保存到服务器端。

然后安装 nginx, rh-postgresql95：

yum install nginx rh-postgresql95

初始化 postgresql95，由于使用 scl 上的 postgresql95，因此需要使用以下命令新开一个 shell 环境来开启 postgresql95：

scl enable rh-postgresql95 bash

然后在这个新的 bash shell 中初始化：

postgresql-setup --initdb

PS: 以上两条命令最好在 root 下执行，因为第二条需要 root 权限，而如果使用
sudo postgresql-setup --initdb 会报 command not found 的错误。

初始化完成后，就可以开启 postgresql95 服务了：

systemctl enable rh-postgresql95-postgresql.service

然后启动，并查看是否启动成功了：

systemctl start rh-postgresql95-postgresql.service
systemctl status rh-postgresql95-postgresql.service

当启动成功后，就可以使用 psql 管理进行创建数据库，创建用户，导入数据库等操作
了。

如果需要切换到 postgres 账号来登录使用 psql，为了避免频繁输入 postgres 的密码，可以修改下 PAM 配置，使得当前账号可以免 postgresql 账户密码切换到 postgres 账号。

编辑 /etc/pam.d/su 配置文件，在

auth		sufficient	pam_rootok.so

一行的下面添加以下配置：

auth		[success=ignore default=1] pam_succeed_if.so user in postgres
auth		sufficient	pam_succeed_if.so user = <USER> use_uid

其中，把上面的 <USER> 替换为当前登录的账号名。如果还要添加其他用户，用户名之间用 : 分隔，如：postgres:other。

然后就可以使用以下命令进入 psql 里了：

su - postgres -c 'scl enable rh-postgresql95 psql'

（注：上面的命令是由于需要先启用 rh-postgresql95，psql 命令才可以用）

postgresql 配置好后，现在来开启 nginx 服务：

systemctl enable nginx

然后启动，并查看启动状态：

systemctl start nginx
systemctl status nginx

启动成功后，将原 VPS 上的配置文件复制到 /etc/nginx/conf.d/ 里，由于将 SSL 证书和密钥放在其他目录上，并且 CentOS 7 默认开启了 selinux，因此需要为该目录修改其 label：

chcon -v --type=httpd_sys_content_t /srv/ssl

上面的命令是临时性的，当修改该目录后，其 label 又会被删除，因此可以使用以下命令永久地使其生效：

semanage fcontext -a -t httpd_sys_content_t /srv/ssl(/.*)?
restorecon -Rv /srv/ssl

由于需要使用比较新的 Nodejs 版本，因此直接使用 Nodejs 官网提供的安装方式来安装 Nodejs：

curl --silent --location https://rpm.nodesource.com/setup_7.x | bash -
yum install nodejs

由 nginx 作为前端，后端使用 nodejs 时，在 nginx 连接 nodejs 时如果连接失败，如果在 /var/log/nginx/error.log 中发现以下错误：

2016/11/16 01:49:33 [crit] 16726#0: *26 connect() to 127.0.0.1:2368 failed (13: Permission denied) while connecting to upstream, client: x.x.x.x, server: example.org, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:2368/", host: "example.org"

这可能是由于 selinux 的 httpd_can_network_connect 的值为 off 造成的，这时可以使用以下命令修改其值为 on：

# 可以使用以下命令查看 httpd_can_network_connect 的值：
getsebool -a | grep httpd_can_network_connect
# 将 httpd_can_network_connect 设为 on
setsebool -P httpd_can_network_connect on

参考：

https://www.softwarecollections.org/en/scls/rhscl/rh-postgresql95/
https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/

解决方法

在 rollup 的配置（如 rollup.config.js）里加入：

export default {
    //...,
    acorn: {
        allowReserved: true,
    },
    //...,
}

错误分析

一般出现这种错误是由于 js 里使用了保留字（Reserved Word）作为函数名或者变量名导致的，
因为 rollup 使用 acorn 将 js 解析成 AST，而在 acorn 中，只有 ecmascript 3 才被允许使用保
留字作为函数名或变量名，更高版本的 ecmascript 默认会报错，除非使用
allowReserved: true 选项来明确允许使用。

我们写代码时，也会避免使用保留字作为函数名或变量名，但有时会使用它们作为对象的 key
来使用，例如：

var foo = {
    await: function () {
    },
};

这样使用一般没什么问题的，但如果代码通过 babel 转换后由 acorn 解析（通常我们不会
这样用的，因为 babel 本身已经内置了一个类似 acorn 的解析器，可以直接解析成 AST。
但如果在 rollup 中使用 babel，rollup 会将源代码经过 babel 转换后再由 rollup 默认的
解析器 acorn 处理）就会出现上面的那个报错了，为什么经过 babel 处理后会报错呢？

我们来看下经过 babel 处理后的代码就清楚了：

"use strict";

var foo = {
    await: function await() {}
};

可以看到，它将属性 await 的值（一个匿名函数）的函数名改成 await 这个保留字了。这时如果再将
这些代码传到 acorn 里解析，就会报错。

参考：

• rollup: https://github.com/rollup/rollup
• acorn: https://github.com/ternjs/acorn

一般地，在 curl 中，如果想以指定的 ip 来请求一个域名地，可以使用 curl http://127.0.0.1/example -H 'Host: www.example.org'
这种指定 Host 头的做法，但这在 https 中可能会失败，显示 no alternative certificate subject name matches target host name '127.0.0.1。

显然这是由于 curl 将 https://127.0.0.1 里的 127.0.0.1 而不是 Host 头用于验证证书的 subject name，而这个 ip 如果不在证书的 subject names 中,
将会导致证书验证失败。

一般的解决方案，我们可以在 /etc/hosts 或 dnsmasq 用指定 ip 解析这个域名，但这改起来显示比较繁琐。还好在 curl 7.21.3 中，提供了一个 --resolve <host:port:address>' 的
参数，让我们可以很方便地将域名解析到指定的 ip 上，例如上面的请求可以改成 curl --resolve 'www.example.org:443:127.0.0.1' https://www.example.org。

本文主要针对 Linux 非 root 用户，在没有 root 权限下如果安装及配置 NodeJS（注：这里安装的是官网上已经编译好的二进制包）。

首先到 NodeJS 的官网（https://nodejs.org/en/download/）下载对应的已经编译好的
二进制包。

这里以 CentOS 6 32bit 为例，安装 NodeJS 的 LTS 版本：

1. 下载 Linux Binaries 32bit 版本：

    curl -o node-v4.4.2-linux-x86.tar.xz https://nodejs.org/dist/v4.4.2/node-v4.4.2-linux-x86.tar.xz
   

2. 将下载好的二进制压缩包解压至指定的安装目录（这里以 ~/apps 为例）：

    mkdir -p ~/apps
    tar -xJf node-v4.4.2-linux-x86.tar.xz --no-wildcards-match-slash --anchored \
        --exclude */CHANGELOG.md --exclude */LICENSE --exclude */README.md \
        --strip 1 -C ~/apps
   

   注：如果出错并提示 xz: Cannot exec: No such file or directory，可能是未安装 xz 解压工具。这里，你可以
   重新下载 gzip 格式的压缩包（https://nodejs.org/dist/v4.4.2/node-v4.4.2-linux-x86.tar.gz），然后将上面
   命令中的 -xJf 换成 -xzf。

3. 编辑 ~/.bash_profile 或者 ~/.profile，将 ~/apps/bin 添加到环境变量 PATH 中：

    export PATH="${PATH}:${HOME}/apps/bin"
   

   注1：如果配置文件中已经有了 PATH 变量，可以在其后面添加 ${HOME}/apps/bin。
   注2：如果系统里已经安装了其他版本的 node，可以将 ${HOME}/apps/bin 放在 ${PATH} 的前面，防止使用系统使用的版本，而不是需要安装的版本

4. 现在可以使用 source ~/.bash_profile 或 source ~/.profile（如果修改的是这个配置文件），使上面的修改生效。
   这时，键入 node -v 如果可以看到刚刚安装的 node 的版本号，表明已经安装成功了。

5. 配置 npm，在 shell 中执行以下命令（如果输入 npm -v 可以看到 npm 的版本号，该步骤可忽略）：

    mkdir -p ~/apps/etc
    echo 'prefix = ${HOME}/apps' > ~/apps/etc/npmrc
   

题外：

如果系统已经安装了 NodeJS，在使用 npm -g 时，又不想使用 root 权限将 package 安装到 /usr 下面，可以通过配置 npmrc 到当前用户下。
以安装到 ~/.npm_packages 下为例：

首先将以下内容添加到 ~/.npmrc 下：

echo 'prefix = ${HOME}/.npm_packages' > ~/.npmrc

然后将 ${HOME}/.npm_packages/bin 添加到环境变量 PATH 里（添加方法见上文），当环境变量更新后，就可以使用 npm -g install <package> 将
package 安装到 ~/.npm_packages/lib 下面了。

另外这里提供一个 bash 脚本，可用于更新 NodeJS：

#!/usr/bin/env bash

if [[ -z "$1" ]]
then
    echo "Usage: ./update-node-js.sh <NODE_VERSION> [INSTALL_DIR]"
    echo "Example: ./update-node-js.sh v5.10.1 ~/apps"
    exit 1
fi

if [[ -z "$2" ]]
then
    dir=~/apps
else
    dir=$2
fi

version=$1
arch=$(uname -m)
if [[ $arch == 'i686' || $arch == 'x86_64' ]]
then
    arch='x64'
else
    arch='x86'
fi

shasum256_file=https://nodejs.org/dist/${version}/SHASUMS256.txt
url=https://nodejs.org/dist/${version}/node-${version}-linux-${arch}.tar.gz

shasum256_filename=$(basename $shasum256_file)
nodejs_filename=$(basename $url)

function cleanup {
    cd $ori
    rm -rf $tmp
}

ori=$(pwd)
tmp=$(mktemp -d)
echo "Mkdir ${tmp}..."
trap cleanup EXIT
echo "Enter ${tmp}..."
cd $tmp

echo "Downloading..."
curl -L $shasum256_file -o $shasum256_filename
curl -L $url -o $nodejs_filename
echo "Downloaded!"

echo "Verifying ${nodejs_filename}..."
grep $(sha256sum $nodejs_filename) $shasum256_filename 2>&1 1>/dev/null

if [[ $? != 0 ]]
then
    echo "Verify $nodejs_filename fail!"
    exit 1
fi
echo "Verify $nodejs_filename success!"

echo "Installing..."
dir=~zhcp/tmp/ff
tar -xzf $nodejs_filename --no-wildcards-match-slash --anchored \
    --exclude */CHANGELOG.md --exclude */LICENSE --exclude */README.md \
    --strip 1 -C $dir
echo "Install success!"

初始化数据库：

su - postgres -c "initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'"

解释：使用 postgres 用户进行登录并切换到该用户的目录，并执行命令：initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'
其中参数 -D 指定数据库存放的目录（注：在 Arch Linux 中，postgresql 默认的目录为 /var/lib/postgres，而在 CentOS 中，是在 /var/lib/pgsql）

创建用户/角色
有两种方式创建，一种是使用 createuser 命令，一种是使用 SQL 语句：

createuser <USERNAME>

CREATE USER <USERNAME> [WITH ...];
-- 或者
CREATE ROLE <ROLENAME> [WITH ...];

在上面的命令中，使用 createuser 或者 CREATE USER ...，与 CREATE ROLE ... 的区别是：前者创建的用户/角色有 LOGIN 权限，而后者为 NOLOGIN 即没有登录的权限（当然，也可以通过后面的 WITH 添加 LOGIN 权限）。

删除用户/角色：

dropuser <USERNAME>

DROP USER [IF EXISTS] <USERNAME>;
-- 或者
DROP ROLE [IF EXISTS] <ROLENAME>;

创建数据库：

createdb <DBNAME>

CREATE DATABASE <DBNAME>

删除数据库：

dropdb <DBNAME>

DROP DATABASE <DBNAME>

列出所有数据库：

使用 psql 登入后，使用：

\l

mysql 可以使用以下 SQL 语句：

show DATABASES;

在 psql 里使用（连接）其他的数据库（类似 mysql 里的 use <DBNAME>;）：

\c <DBNAME>

修改 user/role 密码：

\password [USERNAME]

或者：

ALTER ROLE XXX WITH PASSWORD 'XXXXXX';

显示表的列名（attribute）：

SELECT column_name, data_type, character_maximum_length
FROM INFORMATION_SCHEMA.COLUMNS where table_name = '<name of table>';

或者：

\d+ <name of table>

其中 <name of table> 替换为具体需要查询的表名

在 psql 中，将查询结果复制到文件中：

\copy (SELECT * FROM foo) To '/tmp/test.csv' WITH FORMAT csv

可以将 SELECT * FROM foo 替换成你需要查询的语句，/tmp/test.csv 替换成需要保存的位置，FORMAT 支持三种：text、csv、binary

重置 SERIAL 计数：

SELECT setval('<seqname>',<next_value>);

将 <seqname> 替换成具体的 sequence name，<next_value> 替换成具体的计数值 （注：如果 next_value 为 1，则新插入的下一个值为 2）

也可以使用 ALTER 语句：

ALTER SEQUENCE <seqname> RESTART WITH 1

将 <seqname> 替换成具体的 sequence name

移除某个 constraint：

ALTER TABLE <table_name>
DROP CONSTRAINT <constraint_name>;

SQL SELECT 语句的逻辑执行顺序：

FROM
ON
JOIN
WHERE
GROUP BY
WITH CUBE or WITH ROLLUP
HAVING
SELECT
DISTINCT
ORDER BY
TOP

从另一个表导入数据：

INSERT INTO author(original_id, name)
SELECT author_id, author_name
FROM (
    SELECT DISTINCT author_id, author_name FROM original
) AS t
ORDER BY author_id::int ASC;

导出数据库：

pg_dump -U {USERNAME} {DBNAME} > db.pgsql

pg_dump 导出的数据默认带有 ownership（即面里有一个 ALTER 语句修改 table 的 owner 为原来数据库里对应的 user/role），如果该数据库的 owner（user/role）在导入的 postgresql 中不存在时，可能会发生错误。可以添加 --no-owner 选项，使导出的数据不带有 onwership

导入数据库：

psql -U {USERNAME} {DBNAME} < db.pgsql

默认时，当导入数据库有错误时，psql 会忽略它并继续导入，可以使用 --set ON_ERROR_STOP=on 选项来阻止：

psql --set ON_ERROR_STOP=on -U {USERNAME} {DBNAME} < db.pgsql

如果需要导出指定的表可以使用 -t {TABLE_NAME}，多个表就加上多个的 -t {TABLE_NAME}。如果多个表的数据太大，可以使用 -j N（其中 N 为具体并行的数字）来进行并行导出，但该参数只能用于 -F d，即导出为为目录（里面每个文件对应相应的表）。通过该方式导出的数据，需要使用 pg_restore 来导入到新的数据库中。

pg_dump -t account -t author -t book_category  -t book_category_mobile -t book_img -t book_info -t book_volume -t book_chapter -U postgres -O -h localhost -p 15432 -d novel -j 8 -Fd -f db

导入：

pg_restore -U postgres -O -h localhost --role {ROLE} -p 15432 -d novel -j8 -Fd db

其中 --role {ROLE} 可以在恢复数据前使用 SET ROLE {ROLE} 将 {ROLE} 设置当前 session 的 user id。这样，在恢复数据时将使用 {ROLE} 而不是 postgres（登录用户）来操作（其权限为 {ROLE} 所拥有的）。

最近将本地的一个数据库搬到 VPS 上，在导入时出现了一个”Value too large for defined data type“的错误。通过 Google 搜索后发现没有实际的解决方案，但大致了解了下（http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type）出错的原因，可能是因为 VPS 的系统是 32bit，而其中需要导入的一个 xxx.dat.gz 文件的太大导致的。

由于在本地使用 pg_dump -Fd 来导出，该选项导出为文件夹，其中数据库的每个表的数据为一个经过 gzip 压缩的文件，后缀为 .dat.gz。该导出方式不能直接通过 psql 来导出，而需要使用 pg_restore 来导入。

由于数据库文件太大，而本地上传到 VPS 的带宽太小了，如果要重新导出为 plain text 格式再上传比较麻烦。于是想了下发现错误的原因，可能在于 pg_restore 导入时，需要对 gzip 文件进行解压操作，而由于受系统（32bit）的限制而造成的。

那能不能在外面使用先解压出来，而 pg_restore 又支持导入已解压的文件（根据它可以直接读取 toc.dat 文件推测的）呢？

根据这个猜测，先尝试下使用系统自带的 gnuzip 对其进行解压，然后再将解压出来的文件替换原来未解压的文件。

经过测试，发现可以正常解压出来，并且 pg_restore 也可以识别（支持）解压出来的文件。

安装

1. 配置 YUM 仓库，编辑 /etc/yum.repos.d/Centos-Base.repo 中的 [base] 和 [updates] 部分，在这两部分中添加以下行：

    exclude=postgresql*
   

2. 安装 PGDG RPM 文件，在 http://yum.postgresql.org 中查找你需要安装的相应版本的链接，然后运行以下命令安装：

    yum localinstall https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-6-i386/pgdg-centos95-9.5-2.noarch.rpm
   

3. 安装 Postgresql

   列出可用的包：

    yum list postgres*
   

   安装：

    yum install postgresql95-server postgresql95
   

配置

数据文件夹

PostgreSQL 数据文件夹包含了数据库所需的所有数据文件。变量 PGDATA 指向该文件夹。
在 PostgreSQL 9.0 及以上版本，默认的数据文件夹在：

/var/lib/pgsql/<name>/data

如 PostgreSQL 9.5 中：

/var/lib/pgsql/9.5/data

其他版本（7.x、8.x）中，默认在：

/var/lib/pgsql/data/

初始化

使用以下命令（只需执行一次）初始化数据库：

service <name> initdb

例如（v9.5）：

service postgresql-9.5 initdb

如果上面的命令无法工作，可以尝试直接执行安装程序：

/usr/pgsql-y.x/bin/postgresqlyx-setup initdb

例如（v9.4）：

/usr/pgsql-9.4/bin/postgresql94-setup initdb

注：postgresql 9.5 的 bin 目录里没有 postgresql95-setup，可以使用以下命令：

su - postgres -c '/usr/pgsql-9.5/bin/initdb -D /var/lib/pgsql/9.5/data'

如果需要指定编码，可以使用

su - postgres -c '/usr/pgsql-9.5/bin/initdb -D /var/lib/pgsql/9.5/data -E UTF8 --locale=en_US.UTF8'

或根据 LANG 来设置

su - postgres -c 'LANG=en_US.UTF8 /usr/pgsql-9.5/bin/initdb -D /var/lib/pgsql/9.5/data'

启动

如果你想在操作系统启动时自动启动，可以运行以下命令：

chkconfig <name> on

例如（v9.5）：

chkconfig postgresql-9.5 on

PS：如果你的系统里有 systemd，需要使用 systemctl 来开启：

systemctl enable postgresql

控制服务

如果需要控制数据库服务，可以使用：

service <name> <command>

其中，：

• start: 启动该数据库
• stop: 停止该数据库
• restart: 重启该数据库，一般用于使配置文件改变后重新生效
• reload: 重新读取 pg_hba.conf 文件（不停止该数据库的运行）

例如，启动 v9.5：

service postgresql-9.5 start

如果使用 systemd，使用以下命令替代：

systemctl enable postgresql-9.5.service
systemctl start postgresql-9.5.service
systemctl reload postgresql-9.5.service
systemctl reload-or-restart postgresql-9.5.service
systemctl restart postgresql-9.5.service

卸载

全部卸载：

yum erase postgresql95*

翻译(不完整）自：https://wiki.postgresql.org/wiki/YUM_Installation

一般情况

一般情况下，如果需要在 canvas 中获取鼠标指针坐标，可以通过监听鼠标的 mousemove（如果只需单击时的坐标，可以用 click）事件。
当事件被触发时，我们可以获取鼠标相对于 viewport 的坐标（event.clientX, event.clientY）。
同时，我们可以通过 canvas.getBoundingClientRect() 来获取 canvas 相对于 viewport 的坐标，这样我们就可以计算出鼠标在 canvas 中的坐标。

canvas.addEventListener("click", function __handler__(evt) {
    var x = evt.clientX;
    var y = evt.clientY;
    var rect = canvas.getBoundingClientRect();
    x -= rect.left;
    y -= rect.top;
    console.log(x, y); // (x, y) 就是鼠标在 canvas 单击时的坐标
});

** DEMO-1 **

设置了 border/padding

一般情况下，我们根据上面的方法获取出来的坐标是准确的，但当我们在 canvas 上添加了 border 或 padding 后，坐标就出现了偏移。

** DEMO-2-0 **

这是因为在 canvas 中，坐标区域是 canvas 元素的 content 区域，不包括 border 和 padding，而通过上面得到的坐标原点在 canvas 的 border 开始的。因此，这里还需要减去 border 和 padding。

var style = window.getComputedStyle(canvas, null);
var borderLeft = parseFloat(style["border-left-width"]);
var borderTop = parseFloat(style["border-top-width"]);
var paddingLeft = parseFloat(style["padding-left"]);
var paddingTop = parseFloat(style["padding-top"]);
canvas.addEventListener("click", function __handler__(evt) {
    var x = evt.clientX;
    var y = evt.clientY;
    var rect = canvas.getBoundingClientRect();
    x -= rect.left - borderLeft - paddingLeft; // 去除 borderLeft paddingLeft 后的坐标
    y -= rect.top - borderTop - paddingTop; // 去除 borderLeft paddingLeft 后的坐标
    console.log(x, y); // (x, y) 就是鼠标在 canvas 单击时的坐标
});

** DEMO-2-1 **

设置了 css width/height

当在 canvas 上设置了 css 的 width、height，并且与 canvas 的 width、height 属性不同时（可以非常简单对 canvas 进行放大或缩小，在移动页面上常常会使用）。从上面计算出来的坐标在 canvas 里使用又会出现偏移。

** DEMO-3-0 **

这里就需要对坐标进行修正：

var style = window.getComputedStyle(canvas, null);
var cssWidth = parseFloat(style["width"]);
var cssHeight = parseFloat(style["height"]);
var scaleX = canvas.width / cssWidth; // 水平方向的缩放因子
var scaleY = canvas.height / cssHeight; // 垂直方向的缩放因子
canvas.addEventListener("click", function __handler__(evt) {
    var x = evt.clientX;
    var y = evt.clientY;
    var rect = canvas.getBoundingClientRect();
    x -= rect.left;
    y -= rect.top;
    x *= scaleX; // 修正水平方向的坐标
    y *= scaleY; // 修正垂直方向的坐标
    console.log(x, y); // (x, y) canvas 里的坐标
});

** DEMO-3-1 **

设置了 transform

如果我们在 canvas 的 style 上添加了 transform，又有可能会导致上面计算出来的坐标出现偏移。

** DEMO-4-0 **

而且经过 transform 后很难通过已经的 API 来计算出准确的坐标？w3c 为了解决这个问题，在 CSSOM-View 中添加了一个名为 GeometryUtils 的接口，该接口提供了一系列的 api 帮助我们对页面上的点、矩形、四边形等的坐标进行转换（目前只有 Firefox 支持）。
这里我们使用其中的 convertPointFromNode 方法，直接把在 viewport 的坐标 (evt.clientX, evt.clientY) 转换成相对于 canvas 元素的坐标。
如果 canvas 同时设置了样式 width、height、box-sizing，我们可以使用 getBoxQuads 方法来获取 canvas 经过 transform 之前的元素的 width 和 height（虽然可以使用通过获取 style 的相关属性来计算，但这种方式太麻烦了）来计算出经过 css 缩放的因子。

var quads = canvas.getBoxQuads({
    box: "content",
    relativeTo: canvas
});
var bounds = quads[0];
var scaleX = canvas.width / bounds.width;
var scaleY = canvas.height / bounds.height;
canvas.addEventListener("click", function __handler__(evt) {
    var {x, y} = canvas.convertPointFromNode({
        x: evt.clientX,
        y: evt.clientY
    }, document, {
        toBox: "content"
    });
    x *= scaleX;
    y *= scaleY;
    console.log(x, y);
});

** DEMO-4-1 **

在文章的最后，贴上另一种方法的解决方案：

** DEMO-4-2 **