Linux on cyp0633's Blog

安装 Arch Linux 「未曾设想的道路」

Thu, 02 May 2024 10:06:00 +0800

TL;DR：使用EndeavourOS的LiveCD可以与官方ISO一样安装Arch Linux，还能享受Gparted、浏览器、文字编辑器等图形界面软件的便利。

在数次尝试中，使用Arch Linux官方LiveCD的tty界面安装系统总是令我感觉十分不便，或许我还是需要一个带图形界面的安装器，但又不愿意抛弃命令行安装方法。然而，虽然Arch Linux并没有提供图形化LiveCD，但是与其共享同一个软件库的EndeavourOS有啊！LiveCD里带的工具也算比较全乎。

理论存在，开始实践。

分区

分区反倒是我觉得最困难的。

这一步要先考虑好将内核镜像装到EFI分区还是系统分区 /boot里面（对应 EFI 分区的挂载点）。前者会多花至少100MB空间，但不管怎么样，都应该先保证EFI分区空间足够。联想给了一个仅260MB的EFI分区（/dev/nvme1n1p1），而且后面跟着的就是MSR和Windows系统分区，不敢动，所以选择后者，又不是不能用.jpg。

然后可以先将Arch的系统分区分出来了。我分了一个Btrfs分区（/dev/nvme0n1p2），有两个子卷 @ 和 @home，分别挂载到 / 和 /home。分区操作很容易使用Gparted搞定，然后在终端中输入：

sudo btrfs subvolume create /mnt/@
sudo btrfs subvolume create /mnt/@home
sudo umount -R /mnt
sudo mount -o subvol=@ /dev/nvme1n1p2 /mnt
sudo mount --mkdir -o subvol=@home /dev/nvme1n1p2 /mnt/home
sudo mount /dev/nvme1n1p1 /mnt/efi

这时候带一个桌面环境的LiveCD的优势又体现出来了：可以一边用Gparted看分区，一边在终端里操作。

安装

然后就是正常的安装流程了。换完源之后进入root账户，然后：

1
2

pacstrap -K /mnt base linux linux-firmware nano intel-ucode btrfs-progs networkmanager iwd man-db man-pages # 每人需要的包不同
genfstab -U /mnt >> /mnt/etc/fstab

建议在生成完fstab之后检查一下，确定btrfs的子卷挂载点是对的。然后就是chroot进入新系统，设置时区和硬件时间：

1
2
3

arch-chroot /mnt
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
hwclock --systohc

以及本地化、主机名、密码等等，参考Arch Wiki就行了，不要忘了。也可以先enable一下NetworkManager和iwd的service。

然后是引导器，我使用rEFInd，先按照Wiki中的步骤安装即可，会自动添加Btrfs驱动。注意其chroot环境下会添加LiveCD的分区信息（而非新系统的），所以不如全图图掉，从 Arch Wiki 示例上换个新的 /boot/refind_linux.conf（chroot路径），以下配置已加入Btrfs子卷配置。

plaintext

1
2
3

"Boot using default options"     "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw rootflags=subvol=@ add_efi_memmap initrd=@\boot\intel-ucode.img initrd=@\boot\amd-ucode.img initrd=@\boot\initramfs-%v.img"
"Boot using fallback initramfs"  "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw rootflags=subvol=@ add_efi_memmap initrd=@\boot\intel-ucode.img initrd=@\boot\amd-ucode.img initrd=@\boot\initramfs-%v-fallback.img"
"Boot to terminal"               "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw rootflags=subvol=@ add_efi_memmap initrd=@\boot\intel-ucode.img initrd=@\boot\amd-ucode.img initrd=@\boot\initramfs-%v.img systemd.unit=multi-user.target"

这时候图形界面的另一个优点就体现出来了，可以直接从Arch Wiki里方便地复制内容。这里的PARTUUID可以用 blkid 查看，输入Btrfs分区的UUID即可（子卷的你也找不到啊）。另外不要忘了针对性地更改 /efi/EFI/refind/refind.conf（chroot路径），以检测Arch Linux initramfs和Btrfs子卷。

确定步骤都正确走完了的话，就可以重启了。rEFInd会自动把自己设为默认的。

后续工作

重新启动后当然是tty了，用NetworkManager连上网之后，就可以装些别的了。我装了这些：

`1`	`sudo pacman -S gnome sudo vi adobe-source-han-sans-otc-fonts`

仅供参考，有需要的自己装就行。

Armbian + R2S 番外篇：透明代理

Sun, 17 Sep 2023 20:46:00 +0800

透明代理这个东西说起来很容易理解，就是设备感知不到有的流量被代理，却有开了代理的效果。这个东西对于学习境外内容的体验提升很大，因为部分应用并不遵循系统代理设置，或设置很麻烦。避免将代理配置文件存放在电脑上，也可以防止电脑上的应用窃取代理信息。

透明代理本身在中文互联网已经是聊烂了的话题，但使用Nftables实现的透明代理很少，在主路由上实现透明代理的更少。我的网络拓扑大概是：外部网络 - R2S - 无线AP - 其他设备。本文将基于这个拓扑，实现在R2S上使用Nftables实现透明代理。

这个东西作为上篇文章的一个小节显得有点喧宾夺主了，所以就单独写一篇文章吧。

前置知识

只需要基础的计网知识，以及初步了解Nftables（起码能看懂规则）。

另外丢掉那张老旧的（you know what）Netfilter数据包流向图吧，由于Nftables的链是可以自由添加、自定义优先级的，现在它应该是这样¹：

Netfilter 数据包流向图

思路

要达到的效果是这样的：

DHCP服务器将默认DNS服务器指向本机的Telescope DNS，由其负责解析²，直连DoH
局域网内通信不经过代理工具，包括DHCP等特殊服务
其他来自局域网内的TCP/UDP流量都经过代理工具，由代理工具分流
不代理路由本身流量，暂时没需求

也就是说流量会经过Nftables和代理工具两次分流。对于较为固定、不高于三层的分流规则，交给Nftables效率更高；而对于按站点分流之类的规则，则交给代理工具，更灵活。

对于第一条，局域网内机器发送数据包的路径为：

局域网内客户端发出DNS请求
Nftables prerouting 对目的为局域网内的请求进行直连，不代理
Telescope DNS接收到请求（此处设未缓存）
Telescope DNS向上游发出请求，不带任何meta mark
Nftables postrouting 进行NAT
远程DNS服务器收到请求，返回结果
Nftables prerouting 对来自局域网外的请求直连
Telescope DNS收到上游回复
Telescope DNS将结果返回给客户端
Nftables postrouting 进行NAT
客户端收到回复

对内网的包：

局域网内客户端发出请求
Nftables prerouting 对目的为局域网内的请求进行直连，不代理
进入 forward 链，转发给目标机器或/同时被本机处理

对分流决定代理的正常TCP/UDP流量：

局域网内客户端发出请求
Nftables prerouting 对于来自局域网、目标为外网的请求，进行 tproxy
代理工具接收并封装请求，并发送到代理服务器，带有meta mark 2
Nftables postrouting 进行NAT
代理服务器处理代理请求，返回结果
Nftables prerouting 对于来自外网的请求，不代理（直接发往代理工具）
代理工具接收并解封装请求，将结果返回给客户端
Nftables postrouting 进行NAT
客户端收到回复

对于决定不分流的正常TCP/UDP流量，其实也和上面相似，只不过代理工具直接将请求发往目标服务器，目标服务器也直接把结果返回给代理工具。

实现

类似于 Xray TProxy 透明代理之类的本机透明代理方案很多，一般也适用于旁路由。核心的规则其实就两条，也就是在 prerouting 的链上加入（tproxy 仅支持 prerouting）：

perl

1
2

ip protocol tcp tproxy to 127.0.0.1:12345 meta mark set 1
ip protocol udp tproxy to 127.0.0.1:12345 meta mark set 1

然而就以上面链接中这篇教程的配置为例，它包含如下三行规则，通过跳过目的为本地IP的代理，同时避免了远程服务器发回的流量被重新代理和局域网内主机间流量被代理的问题：

perl

1
2
3

ip daddr $RESERVED_IP return
ip daddr 192.168.0.0/16 tcp dport != 53 return
ip daddr 192.168.0.0/16 udp dport != 53 return

第二个问题很好理解。而这些规则能解决第一个问题，主要原因在于主路由已经做好了NAT，看起来已经是从远程主机IP发往代理客户端主机IP的流量了，也就是有了目的IP在上述范围内的特征。同样的方法却不能套到主路由上，因为NAT一般在 postrouting 阶段去做，而 tproxy 一般在 prerouting 阶段进行³。此时，网络层的目的IP仍然是本机的外网IP，而非192.168.0.1这样的局域网IP。

然而，出于某些原因，我们并不能在 postrouting 阶段等待NAT完成后再更改目的IP⁴，也就是说这个阶段已经不能把数据包拐到代理上面了。考虑到 tproxy 的作用阶段，实际上在 prerouting 中同时进行Nftables阶段的分流和 tproxy 更为合适。相应的，为了识别远程服务器发回流量，我们要添加一条规则，也就是源IP不在内网IP段中，则不代理。

另外不管是上面的教程还是Linux kernel文档³，都指出 tproxy 应搭配自定义IP route使用，以让透明代理的包正确地传输到本地。在进行透明代理的同时为数据包附上meta mark 1，这样就可以被以下两条命令定义的路由规则捕获，然后被传输到本地：

bash

1
2

ip rule add fwmark 1 lookup 100 # 对于带标记 1 的包，使用编号为 100 的路由表（100 没有什么特殊含义）
ip route add local 0.0.0.0/0 dev lo table 100 # 对于路由表 100，经过 lo 设备发送到 0.0.0.0

实验表明去掉这两条规则后，无法正确进行透明代理。由于 tproxy 并不会修改数据包本身的内容，所以我猜测该数据包可能会按照默认策略路由，不会进入本地回环为代理工具所接收。

接下来就该配置代理软件了。我个人建议使用Xray-core，需要添加入站：

json

{
  "inbounds": [
    {
      "tag": "all-in",
      "port": 12345,
      "listen": "127.0.0.1",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    },
  ]
}

并且建议为每个出站都设定meta mark不为1：

json

{
  "outbounds": [
    {
      "streamSettings":{        
        "sockopt": {
          "mark": 2
        },
      },
    },
  ]
}

在添加了上面的规则后，发现连不上新设备了，查找DHCP服务器的日志也并未发现端倪。发现由于DHCP的Discover目标为广播IP，并未被排除代理，所以被代理工具截留。我使用的workaround为添加一条规则，对目标为udp/67端口的数据包不代理，DHCP恢复正常。

宿舍的网络竟然有外界可以直接访问的公网IP（震惊），所以个人还加了 filter 表，用于防止外界白嫖代理。这个看一下下面的配置文件就明白，我不多讲。

配置

如果你希望使用此配置文件，请根据你路由器的接口分配、网段分配、代理工具等情况进行修改。另外也不要忘了添加 ip 路由规则。

perl

#!/usr/sbin/nft -f

flush ruleset

define RESERVED_IP = {
    192.168.0.0/24,
    0.0.0.0/8,
}

define WANLINK = lan0
define LANLINK = eth0

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname $WANLINK masquerade
    }
}

table ip filter {
    chain input {
        type filter hook input priority 0; policy accept;
        # only accept local/LAN traffic to tproxy
        ip saddr != $RESERVED_IP tcp dport 12345 drop
    }
}

table ip xray {
    chain prerouting {
        type filter hook prerouting priority mangle; policy accept;
        # source not from LAN (e.g. server reply), don't proxy
        ip saddr != $RESERVED_IP return
        # dest loopback or local traffic, don't proxy
        ip daddr $RESERVED_IP return
        # allow dhcp traffic (daddr may be 255.255.255.0)
        udp dport 67 return
        # tproxy traffic
        ip protocol {tcp,udp} tproxy to 127.0.0.1:12345 meta mark set 1
    }
}

IPv6

本节参考⁵

IPv6透明代理的实现与上面相似，甚至可以不用建新表，而是修改 xray 表即可。

IPv6对应的路径设置如下：

bash

1
2

ip -6 rule add fwmark 1 table 106
ip -6 route add local ::/0 dev lo table 106

这里我直接将修改后的 xray 表列在下面：

perl

table inet xray {
    chain prerouting {
        type filter hook prerouting priority filter; policy accept;
        ip daddr { 127.0.0.0/8, 224.0.0.0/4, 255.255.255.255 } return
        ip6 daddr 2408::/16 return
        meta l4proto tcp ip daddr 192.168.0.0/16 return
        ip daddr 192.168.0.0/16 udp dport != 53 return
        ip6 daddr { ::1, fe80::/10 } return
        meta l4proto tcp ip6 daddr fd00::/8 return
        ip6 daddr fd00::/8 udp dport != 53 return

        # tailscale
        udp sport 41641 return
        udp dport 41641 return
        udp dport 3478 return
        udp sport 3478 return

        meta mark 2 return
        meta l4proto { tcp, udp } meta mark set 1 tproxy ip to 127.0.0.1:12345 accept
        meta l4proto { tcp, udp } meta mark set 1 tproxy ip6 to [::1]:12345 accept
    }

    chain divert {
        type filter hook prerouting priority mangle; policy accept;
        meta l4proto tcp socket transparent 1 meta mark set 1 accept
    }
}

如果你的代理工具只监听了IPv4地址，那么需要同时监听IPv6 [::1]:12345。

优化

Nftables数据包追踪

在编写Nftables配置的时候，经常可能有疑问，这个数据包到哪里去了。可以使用 nft monitor trace 监视特定数据包的流向和规则判定过程，详细使用方法见 ⁶。

米家设备无法连网

如果开启透明代理的情况下，发现米家设备无法联网（或者无法绑定到App），而关闭透明代理又恢复，那么可能是因为米家设备需要连接域名 mijia cloud（是的你没看错，中间一个空格），代理工具嗅探到了这个域名并尝试解析以分流，但其无法正常处理⁷，于是走默认。可以通过查看代理工具的日志来验证这个情况，Xray-core和Clash都可能会有这个问题。

解决方法是跳过这个域名的嗅探分流，如Xray-core加上这一段：

json

{
  "inbounds": [
    {
      "sniffing": {
        "domainsExcluded": [
          "mijia cloud"
        ]
      }
    }
  ]
}

干出这个事的小米工程师真该拉出去祭天。

境内流量完全直连

上述的配置会令境内外流量均经过代理工具，最直接的问题就是访问速度变慢。但可能也有些其他后果。

曾遇到一个非常玄学的问题，如国服原神“连接超时”，国服星穹铁道错误“1001_1”等。即使设置了正确的分流规则和DNS解析，也可能无法登录。抓包发现有许多和米哈游的TCP连接被reset掉，暂时不知道根本原因。

个人的解决办法是使用Nftables进行国内IP分流，具体可见这篇文章。实测使用该措施后，由于不需要回到用户态过代理软件，日常上网也会快一点。不过若依赖于特定代理软件的附加功能，如Xray-core的Full Cone NAT，则对于绕过的流量，也会一并失去这些功能。

此处附一个适用于IPv4和IPv6的转换脚本，将APNIC的数据转换为nftables格式，并输出到标准输出：

python

import re

# Function to calculate subnet mask from number of IPs
def get_cidr_from_size(size):
    import math
    return 32 - int(math.log2(size))

def parse_ip_ranges(file_path):
    v4_list = []
    v6_list = []

    # Regular expressions for extracting IPv4 and IPv6 ranges
    ipv4_regex = r'apnic\|CN\|ipv4\|([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\|(\d+)\|'
    ipv6_regex = r'apnic\|CN\|ipv6\|([0-9a-fA-F:]+)\|(\d+)\|'

    with open(file_path, 'r') as file:
        for line in file:
            # Check for IPv4
            match_v4 = re.search(ipv4_regex, line)
            if match_v4:
                ip = match_v4.group(1)
                size = int(match_v4.group(2))
                # Calculate CIDR from the size
                cidr = get_cidr_from_size(size)
                subnet = f"{ip}/{cidr},"
                v4_list.append(subnet)

            # Check for IPv6
            match_v6 = re.search(ipv6_regex, line)
            if match_v6:
                ip = match_v6.group(1)
                prefix_length = int(match_v6.group(2))
                # Construct the subnet
                subnet = f"{ip}/{prefix_length},"
                v6_list.append(subnet)

    return v4_list, v6_list


def generate_nftables_rule(file_path):
    v4_list, v6_list = parse_ip_ranges(file_path)

    # Format the output in nftables style
    v4_rules = "define chnroute_list_v4 = {\n" + "\n    ".join(v4_list) + "\n}"
    v6_rules = "define chnroute_list_v6 = {\n" + "\n    ".join(v6_list) + "\n}"

    return v4_rules, v6_rules


if __name__ == "__main__":
    file_path = 'delegated-apnic-latest'  # Replace with your actual file path

    v4_rules, v6_rules = generate_nftables_rule(file_path)

    # Print the results
    print(v4_rules)
    print(v6_rules)

https://thermalcircle.de/doku.php?id=blog:linux:nftables_packet_flow_netfilter_hooks_detail 另外这也是一篇极佳的Nftables入门文章，推荐阅读。 ↩︎
或许有人担心这会影响Xray-core的域名分流，但其域名分流是依靠sniffing头中的SNI实现的，即使Xray-core得不到解析前的域名，也不会受到影响。 ↩︎
https://www.kernel.org/doc/Documentation/networking/tproxy.txt ↩︎ ↩︎
https://serverfault.com/a/125913 ↩︎
https://xtls.github.io/document/level-2/tproxy_ipv4_and_ipv6.html ↩︎
https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing ↩︎
https://github.com/XTLS/Xray-core/issues/293 ↩︎

启用 AMD P-State EPP 调频驱动

Tue, 12 Sep 2023 23:05:00 +0800

Arch Linux的Linux 6.5内核终于在前几天进入了 core 软件库，其中一个重要的特性就是默认启用了P-State EPP (Active) 调频驱动¹。调频驱动不同于调速器，前者与特定的CPU有关；而后者与电源方案有关，如 powersave 就是一直运行在最低频率。

amd-pstate 是AMD CPU性能调频驱动，它在Linux内核中的现代AMD APU和CPU系列上引入了新的CPU频率控制机制。新机制基于协作处理器性能控制 (CPPC)，它提供比传统ACPI硬件P-state更精细的频率管理。当前的AMD CPU/APU平台使用ACPI P-State驱动程序来管理CPU频率和时钟，仅在3个P-state下进行切换。CPPC取代了ACPI P-state控制，并为Linux内核提供了灵活、低延迟的接口，以直接向硬件传达性能提示。

amd_pstate CPPC有3种操作模式：自主（active）模式、非自主（passive）模式和引导自主（guided）模式。通过不同的内核参数可以选择active/passive/guided模式。

在自主模式下，平台会忽略所需的性能级别请求，并仅考虑设置为最小、最大和能量性能首选项寄存器的值。

在非自主模式下，平台直接通过所需性能寄存器从操作系统获取所需的性能水平。

在引导自主模式下，平台根据当前工作负载并在操作系统通过最小和最大性能寄存器设置的限制内自主设置操作性能级别。

amd_pstate=active 是低级固件控制模式，由amd_pstate_epp驱动程序实现，并在命令行中将amd_pstate=active传递给内核。在此模式下，如果软件想要偏向CPPC固件的性能 (0x0) 或能效 (0xff)，amd_pstate_epp驱动程序会向硬件提供提示。然后CPPC功耗算法将计算运行时工作负载，并根据电源和热量、核心电压和其他一些硬件条件调整实时核心频率。²

简而言之，相比默认的 acpi_cpufreq，P-State能够让CPU从操作系统处直接获得性能需求hint，并进行更细粒度的频率控制。P-State EPP（active模式）响应更快，并能自定义hint，达到类似于调速器的效果。

P-State EPP支持Zen 2或更新的AMD CPU。本人使用的是联想R7000 2020，AMD Ryzen 7 4800H，也算是喝到了一大口汤吧。

启用CPPC

P-State EPP依赖于CPPC（Collaborative Processor Performance Control），所以首先要在BIOS中启用CPPC。请自查BIOS内是否有此选项，如果没有，需要使用 Smokeless_UMAF 访问BIOS中的隐藏选项，步骤如下。本文作者与插件作者不对任何损坏负责。

下载仓库中的 UMAF_BETA.zip，解压到一个空的FAT32格式的U盘中
用此U盘引导启动
进入Device Manager - AMD CBS - NBIO - SMU³

在这里应该就可以看到CPPC选项。即使已经显示Auto或者Default，也需要手动Enable。设置完成后按保存重启即可。

启用P-State EPP

可以直接运行上图中的 cpupower 工具来查看当前的调频驱动。如果你和我一样已经在运行Linux 6.5，那么可能什么都不用做了。

不同内核版本对P-State EPP的支持如下：

6.5起，默认启用P-State EPP¹
6.4起，支持Guided Autonomous模式⁴
6.3起，支持EPP，但默认不启用⁵⁶
5.17起，支持P-State

如果在使用6.3或6.4，开启EPP的方法就是添加内核参数，amd_pstate=[active|passive|guided]。关于如何修改内核参数，可参见 ArchWiki: kernel parameters。

其他优化

可以使用 auto-epp 来自动传递EPP hint，以在离电情况下功耗更低，或接入电源时性能释放更强。

在启用EPP的情况下，也可以直接将调速器设为 powersave，完全靠调频驱动进行调频⁷。

体验

在启用P-State EPP调频驱动后，CPU各内核的频率能够在适当的时候（如浏览网页等场景）降低至400 MHz（见下图的频率范围），在有需求时也能快速拉起频率。相比于之前最低频率仅能低至1.3GHz，此举有望能大幅降低低负载的package功耗。

启用 P-State EPP 后的效果

在进行简单的浏览网页和编写代码时，使用 balance_performance hint，流畅度完全没有问题。笔记本离电时使用 power hint，提频更消极，跑不满笔记本的高刷新率，但功耗更低；使用独显混合模式，续航大约4小时，遥遥领先于Windows，比同样60Wh电池的MBP13 2020（Intel）更强；若关闭独显，可能对续航有更大的提升。

此外也有网友称出现了重启的问题，反正我没遇到。

Armbian，更适合 R2S 软路由的系统

Fri, 14 Jul 2023 14:54:00 +0800

OpenWrt的困境

人们安装OpenWrt，是因为他们觉得它比路由器或者嵌入式设备的原厂固件更好用。

——《使用 OpenWrt 的理由》

不错，作为一个路由器系统来说OpenWrt确实实现了相对官方固件更好的可玩性。实际用久了自然会发现OpenWrt作为一个Linux来说是非常难用的，这点突出体现在其包管理上。官方软件源各种残缺，第三方软件源也充斥着野包，让我想起了用CentOS的时候。开发者倾向于为传统大发行版打包，相比较而言极少看到过opkg。OpenWrt官方甚至不建议升级软件包 ¹，因为包管理器并没有能力升级OpenWrt本身……这对Tailscale和Xray-core等需要经常更新的软件来说很致命。

整个OpenWrt给人的印象也是能省则省，因为它需要照顾到大量低性能的设备，甚至低至8MB Flash、32M RAM的设备；前文提到的包管理器区别是因为opkg不支持ABI兼容性监测；对于普通的Linux发行版也有诸多其他不同。而对于R2S这种1GB RAM的设备来说，倒没必要这么节省。更何况即使在Armbian上，日常占用RAM也仅有300MB，这里面还有100MB以上是Xray-core的缓存。

我并没有说OpenWrt不适合路由器使用，它的大部分配置都能点几下就完成设置，也有更多的中文资料，还有很多开箱即用的网络优化，在社区活跃开发者的帮助下，它十分适合路由器使用。但若是想要跳出插件开发者设定的笼子，尝试稍高级一点的玩法，OpenWrt就会显得各种别扭。而Armbian基于Debian或者Ubuntu，都是许多Linux用户再熟悉不过的发行版，因此使用Armbian不是找罪受，反而能够利用已有的其他Linux使用习惯和资料，是一个偷懒的选择。

因此，本文希望为读者提供另一种软路由的思路，让R2S兼有传统主路由的功能，又有更熟悉的Linux发行版体验。

我的网络拓扑大概如下（无线路由器连接的各个设备仅为示意）。R2S作为主路由使用，~~Redmi AC2100~~ （已升级为小米AX3000）作为AP，不存在旁路由。

网络拓扑

安装Armbian

安装Armbian的第一步就像OpenWrt一样，从官方网站下载对应的img（本文使用基于Ubuntu的Jammy），然后用你的工具烧录进SD卡。将R2S接入电源，指示灯应该闪烁。

初始设置需要将其WAN或LAN口接到另一台 已经启用DHCP 的路由器上，想办法找到其IP地址（比如进管理员后台），然后使用SSH登录，初始用户名和密码分别为 root 和 1234。注意其此时不能作为一个开箱即用的路由器，也就是说不能直接接入电脑。

登入后有一个初始引导，跟着做就行了，没什么好说的。然后这就是一个标准的Linux系统了，基本可以直接遵循其他Linux的操作方法。但国内许多用户会到手换源，由于Armbian是基于其他发行版做的，所以换源不完全一样。其软件源有两个位置，均需要更改：

/etc/apt/sources.list 与你安装的版本所基于的发行版有关，如Armbian Jammy基于Ubuntu Jammy，就换对应的源（如清华源，注意Ubuntu使用Ports源）；
/etc/apt/sources.list.d/armbian.list 是Armbian专属软件源，也要换（仍然如清华源）。

配置路由器功能

OpenWRT说白了也是个Linux，作为一个路由器所需要的功能也有许多方案可以通过后期手动安装实现。

顺着走到这一步，执行 ip l，一台R2S的显示应该类似于下面这样：

plaintext

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
4: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff

此处我把外部网络（相对，如上层路由器）插到了 lan0 上，局域网设备则均连接至 eth0，相当于许多OpenWRT包所做的反转WAN和LAN口。如无特别说明，后面的操作均按照这个来。

R2S的LAN是USB 3.0转接的网卡，而WAN是PCIe网卡。进行高速传输时，USB造成的中断会大量消耗性能，所以对于内网流量，将其扔给性能更高的WAN口。R2S在小包较多时速度明显下降，也是基于同样的原因。

DNS

DNS用于将主机名解析为IP地址。由于传统DNS查询是明文的，可以被中间人任意截留修改，部分运营商会进行DNS污染，以达到加广告或封锁境外网站的目的。因此，使用DoH（DHS-over-HTTPS）和DoT（DNS-over-TLS），并对国内和国外域名进行分流，就有其意义。

下文介绍了几种DNS转发器的的配置方案。其中，EasyMosdns自带了较完善的方案，而TelescopeDNS的配置文件较为简明，都能有效对抗DNS污染。

TelescopeDNS

此处使用 Telescope DNS 负责监听53端口，为局域网内设备进行解析，并根据条件将其发送至不同的DNS服务器。

虽然我有透明代理的需求，但是本着解耦的原则（说白了就是怕Xray-core挂掉全都上不了网），还是由单独的DNS转发器处理局域网查询吧。

Armbian默认使用systemd-resolved解析DNS并占用25端口，由于其仅能监听本机请求而不能接受局域网内其他机器的请求[^7]，需要将其禁用。此外需要将 /etc/resolv.conf 指向127.0.0.1以将本机的DNS查询转发至Telescope DNS。

以下是我的配置文件，读者可以参考。

toml

listen = "192.168.0.1:53"
disable_qtypes = ["AAAA"] # 禁用 IPv6 解析

[cache]
size = 4096

[hosts] # 为 DoH 域名指定 IP 地址，防止回环解析（指解析所必需的 DoH 域名本身也需要解析）
"doh.pub" = "1.12.12.12"
"cloudflare-dns.com" = "1.0.0.1"

[groups]
  [groups.clean] # 境内域名
  doh = ["https://doh.pub/dns-query"] # 腾讯 DNSPod DoH
  dns = ["114.114.114.114"]
  concurrent = true
  no_cookie = true # DNSPod 可能需要
  redirector = "oversea_ip2dirty" # 按照下方同名 redirector 设置重定向

  [groups.dirty] # 境外域名
  dns = ["208.67.222.222:5353", "176.103.130.130:5353"]
  doh = ["https://cloudflare-dns.com/dns-query"] # Cloudflare DoH
  gfwlist_file = "/etc/ts-dns/gfwlist.txt"

[redirectors]
  [redirectors.oversea_ip2dirty]
  # 解析后如发现ip地址不匹配cnip，则重定向到dirty组解析
  type = "mismatch_cidr"
  rules_file = "/etc/ts-dns/cnip.txt"
  dst_group = "dirty"

为了让本机的DNS解析通过本机的服务器，需要更改默认的DNS解析器。

EasyMosdns

Mosdns以强大的功能而闻名，但对于不想花时间配置的人来说，使用别人配好的方案也能十分舒适，比如 EasyMosdns。

因为它和Mosdns都没有被大部分发行版打包，所以在Armbian上，需要先手动安装对应版本的Mosdns，然后将上述repo内的文件丢进对应目录。至于Systemd单元等文件，可以参见 AUR。

默认监听53端口，可以在 /etc/mosdns/config.yaml 中设置。

dnsmasq 整合

确实dnsmasq可以当DNS转发器啊，但因为它对DNS污染抗性比较差，所以我肯定不会单独用它的。不过可以把它套娃，在本机上做两层转发。

如果你希望做两层转发，那么需要将嵌套的转发器监听端口改一下，比如5353，将这个地址改为dnsmasq的上游DNS，并且把dnsmasq的cache size设为0（否则第一次查询大概率失败）；如果你希望把dnsmasq的DNS禁掉，那么这三个设置都不用动，然后给dnsmasq加个 -p0 启动参数就可以了。

DHCP

DHCP用于为局域网内的设备分配各自的IP地址，同时也会传递网关、默认DNS等信息。在我的网络拓扑中，由软路由充当DHCP服务器，其他设备则仅需自带的DHCP客户端。

一般来说Linux的网络连接由systemd-networkd或NetworkManager之类的东西管理（包含DHCP客户端），而在基于Ubuntu的系统上有个好东西叫做Netplan，用于在前述两者等一系列工具之上再构建一层抽象，以求简化其配置。

该机型Armbian的Netplan配置文件位于 /etc/netplan/armbian-default.yaml。未经修改的文件类似于：

yaml

1
2
3

network:
  version: 2
  renderer: NetworkManager

要将软路由作为DHCP服务器，需要先将对应接口的DHCP客户端关掉（路由器一般当然不能从局域网其他主机取得IP地址了），然后再为其单独安排一个IP地址。再次提醒，我计划把局域网设备插在 eth0：

yaml

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eth0:
      dhcp4: false # 这个 false 是关掉 DHCP 客户端
      addresses: [192.168.0.1/24] # 网段自定，后面对应修改

保存后不要忘了使用 sudo netplan try 测试配置文件是不是写对了，没问题的话就确认。

至于DHCP服务器，我起初选择了 coredhcp。其并不支持SLAAC宣告，故对IPv6环境并不友好；而dnsmasq虽然看起来麻烦，但实际上只需要动几个配置项就行了，而且对IPv6比较友好。

照例是配置文件：

yaml

server4:
    listen:
        - "%eth0" # 只监听 eth0 接口的请求
    plugins:
        - lease_time: 3600s
        - server_id: 192.168.0.1 # 填路由器 IP 就行
        - dns: 192.168.0.1 # 重要，设置为路由器 IP 以指向路由器上的 DNS
        - router: 192.168.0.1 # 网关，主路由兼具代理功能，所以这里也是路由器 IP
        - netmask: 255.255.255.0 # 子网掩码
        - range: /etc/coredhcp/leases.txt 192.168.0.2 192.168.0.254 12h # 分配地址文件，起始地址，结束地址，租约时间

NAT

NAT对局域网内IP和端口号二元组与外网IP和端口号二元组之间建立联系，并进行转换。此处使用的工具是 nftables。依托其强大的规则体系，我们可以自由选择转发暴露的端口，以及内外能访问的服务等。

nftables 官方文档 ² 给了我们一个很好的基础配置，我也知道其他高级用途也需要依托 nftables，此处按下不表。但要做到NAT，只需要用一张 nat 表的 masquerade 规则。

perl

#!/usr/sbin/nft -f

flush ruleset

define WANLINK = lan0

table ip nat {
        chain  prerouting {
                type nat hook prerouting priority -100;
        }
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oif $WANLINK masquerade
        }
}

要暂时应用Nftables规则，可以使用 sudo nft -f <filename>，永久应用则需要将其保存到 /etc/nftables.conf，并设置权限755。

启用IP转发

只有启用代理转发，流量才能进入Netfilter的 forward 链，从而不经本地用户程序而向外转发。

在 /etc/sysctl.d/ 下新建一个文件，名字随意（如 98-ip-forwarding.conf），内容为：

plaintext

1
2

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

然后运行 sudo sysctl -p 使其生效。这样，软路由就有了将不属于它的包转发出去的能力。

PPPoE

安装 pppoeconf，然后运行它就可以了。它的底层是 pppd，所以修改配置也需要到 /etc/ppp/ 里面修改。

使用PPPoE上网后，会生成一个 ppp0 虚拟网卡，它充当了WAN口的作用；使用原来的WAN接口是无法直接联网的。使用透明代理等需要指定接口的应用时请务必注意。

进阶应用

按照上面的步骤配置完毕后，如无意外，软路由本身和接入其的设备应该已经可以上网了。然后是一些相比OpenWrt，Armbian没有out-of-box支持的。

透明代理

请阅读 Armbian + R2S 番外篇：透明代理一文。

另外，如果使用Tailscale，实测透明代理可能会与Tailscale规则冲突（实测23/8/26有此现象），从而导致上不了网的严重问题，所幸1.48.0开始Tailscale增加了Nftables支持，将其启用似乎可以解决这个问题。在 /etc/default/tailscaled中加入 TS_DEBUG_FIREWALL_MODE=nftables 即可³。

基本防火墙

将这些规则加入之前的 nftables 配置，可以对内外网进行基本的隔离。修改自 ⁴。

perl

table inet filter {
        chain inbound {
                type filter hook input priority 0; policy drop;
                ct state vmap { established : accept, related : accept, invalid : accept } counter
                ip protocol icmp icmp type { destination-unreachable, echo-reply, echo-request, source-quench, time-exceeded } limit rate 5/second accept
                tcp dport 22 accept
                iifname vmap { lo: accept, $WANLINK : jump inbound_world, $LANLINK : jump inbound_private }
        }
        chain inbound_world {
                ip saddr { $RESERVED_IP } drop
        }
        chain inbound_private {
                ip protocol . th dport vmap { tcp . 22 : accept, udp . 53 : accept, tcp . 53 : accept, udp . 67 : accept }
        }
        chain forward {
                type filter hook forward priority 0; policy accept;
        }
}

UPnP / NAT-PMP

UPnP和NAT-PMP本质上是类似的东西，类似于一个自动的路由器端口映射。可以使用 MiniUPnPd 来实现。

Ubuntu和Debian已经打包了 miniupnpd 和 miniupnpd-nftables 两个包，安装时会自动进入向导，分别填入内网接口（eth0）和外网接口（lan0），并选择启用即可。

Full Cone NAT

Nftables的NAT行为 masquerade 是Symmetric NAT。打游戏的应该会需要Full Cone NAT，可以参考一下这个实现。需要编译对应的 libnftnl、nftables 和 nft，以及内核模块。

如果你使用Xray-core透明代理，那么它已经帮你用神奇的方式实现了Full Cone NAT⁵。但在实现透明代理时，需要将所有流量转发至Xray-core进行分流，以防不同分流规则下NAT行为出现不同。

另外还可以使用 einat-ebpf，使用时需禁用上述NAT Nftables规则中的 MASQUERADE 链，实测Armbian内核支持该程序eBPF所需的内核选项，性能良好，较为易用，无需重新编译内核模块或使用第三方代理工具。

MSS Clamping

我不只一次见网友说自己搭的软路由访问某些网站非常慢，而换回硬路由就正常。这是因为多数家用路由器默认对IPv4下的TCP开启了MSS (maximum segment size) Clamping。

《开启 IPv6 后网速变得很慢？可能是 PMTU 黑洞的问题》

简而言之就是家用硬路由会自动帮你设置MSS，而软路由不会，造成被路径上丢包只能重传。进行MSS Clamping后，终于能跑满300M宽带了。

在Nftables中添加以下内容：

perl

table inet filter {
    chain forward {
        type filter hook forward priority 0; policy accept;
        tcp flags syn tcp option maxseg size set rt mtu
    }
}

IPv6

以网上资料的细碎程度，IPv6其实也是一个进阶应用；但是感觉对自己来说，即使没有全局梯也不能没有IPv6，所以就挺拧巴的，这也是我把它放在最后的原因。如果你对IPv6没有那么熟悉，我强烈建议你展开下面的内容看点更拧巴的现象和我的理解，防止配完黑人问号。

常用的路由器 IPv6 部署方案解析

IPv6的情况与IPv4不同，路由器较少使用DHCPv6来为局域网设备分配IP地址（而且支持也像屎一样 [^13]），更常用的叫做无状态地址自动配置（SLAAC，StateLess Address Auto Configuration），一般来说路由器会选择LAN上前缀的一个 /64地址块，向局域网内进行宣告，然后各个主机通过某种方式，自己在这个 /64里选择一个地址（并非一个设备直接分走一个 /64，所以运营商只给 /60而不是 /56并没有什么问题；感谢 V2EX @dalaoshu 的纠正）。因为一个 /64实在是太巨大了，所以一般也不会冲突。

诶，看起来拧巴的事情来了：本人使用的长沙联通宽带，光猫已改为桥接路由器拨号；而对于PPPoE，协议本身会给路由器 ppp0 指定一个 /64的地址 [^14]。不知细心的你是否发现了，我们没说过 ppp0 在委托的那个子网里面——事实上也确实不在。当执行 ip -6 addr 时，就会得到以下看起来十分抽象实际上却又合理的输出（节选）：

bash

$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2408:aaaa:450:3650:4c43:81ff:fe4d:9cac/60 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::4c43:81ff:fe4d:9cac/64 scope link
       valid_lft forever preferred_lft forever
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 state UNKNOWN qlen 3
    inet6 2408:bbbb:451:50b6:7a88:efdb:db94:4b77/64 scope global temporary dynamic
       valid_lft 259001sec preferred_lft 85804sec
    inet6 2408:bbbb:451:50b6:4e43:81ff:fe4d:9cac/64 scope global dynamic mngtmpaddr
       valid_lft 259001sec preferred_lft 172601sec
    inet6 fe80::4e43:81ff:fe4d:9cac peer fe80::16eb:8ff:feb2:b27d/128 scope link
       valid_lft forever preferred_lft forever

说它抽象吧，是因为在我的直觉里，似乎IPv6不会分配私有IP，所以大家都是平等的设备，也理所应当属于一个子网；说它合理吧，是既然IP转发启用了，那么路由器就可以将其送达该有的目的地，路径也并不需要跟着网段走。事实上，WAN口的 /64是通过PPPoE的SLAAC获得的，这与LAN口的DHCPv6-PD获得的前缀来源不同，所以才会出现两个地址不在同一网段的情况。

其实类比IPv4也是很好理解的：运营商给一个普通路由器的WAN口分配了一个公网IP；同时路由器通过DHCP将内网的私有地址分配给各个主机，LAN口也获得了一个该网段下的私有地址。IPv6情况其实差不多，只是上面的私有地址段变成了通过DHCPv6-PD获得的公网地址段，通过某个公网地址能够直接路由到特定的主机，无需经过NAT而已；子网内的DHCPv4也变成了SLAAC，不过结果上没区别，都是主机获得了自己的IP。

评论区有人提到了IPv6的一些奇怪情况；此外关于PD和SLAAC，也可以多阅读这篇文章作为参考。

好的，逼叨完了，结果很明了了：我们需要配置的有

一个能进行DHCPv6-PD的客户端，
一个能进行SLAAC宣告的程序，和
让路由器本身获得IPv6。

第一个事好说，用得很广泛的是 wide-dhcpv6-client$^包$。安装后编辑 /etc/wide-dhcpv6/dhcp6c.conf。以下给出一个示例，它从运营商请求一个非临时的前缀，然后将这个前缀委托给 eth0，让 eth0 获得一个 /64地址。

perl

interface ppp0 { # 通过 ppp0 进行 DHCPv6
    send ia-pd 0; # 发送 Prefix Delegation 消息
    send ia-na 0; # 请求非临时地址（non-temporary address）
    script "/etc/wide-dhcpv6/dhcp6c-script";
};

id-assoc pd 0 { # PD 0 的配置
    prefix-interface eth0 { # 将前缀委托给 eth0
        sla-id 0; # SLA ID，即网段编号
        sla-len 0; # SLA 长度，即用掉整个 PD
    };
};

id-assoc na 0 {}; # NA 0 的配置，留空就行

这是一个很基础的配置，如果想整更多花活，建议读 manual。

重启一下服务，如果看到 eth0（或自己定义的LAN）上有了一个大于 /64的非私有IP，那么就是成功了，不出意外的话route也会为你配好；否则可以自行使用 dhcp6c -Df -c /path/to/conf <interface> 进行debug。

现在连上设备并不能用SLAAC，因为我们还没有配置路由宣告。如果你已经使用 dnsmasq 作为DHCP服务器，那么宣告非常简单：仅需要在配置文件中加类似下面这一行。

plaintext

`1`	`dhcp-range=::1000,::1fff,constructor:eth0,slaac,ra-names`

我来详细解释一下：

即使向运营商申请了非临时前缀，也可能变，所以前缀不能写死，要自动从接口获取
constructor:eth0 指的是分配给 eth0 的IP段
::1000,::1fff 指的是所有IPv6地址，当然不能给IPv4做SLAAC不是嘛
slaac 指的是选择外部分配的前缀，而非 fe80 开头的内网IP段
ra-names 代表进行SLAAC宣告，不进行DHCPv6，并将主机添加到DNS

第三个事情看起来很玄学。在远古的Linux内核中，当开启IPv6 forwarding的时候，即使 net.ipv6.conf.all.accept_ra 不为0，其也会自作主张地停止进行SLAAC，导致路由器WAN（eth0）接口无法获取IPv6地址；而在不那么老的内核上，将其设为2，就可以同时开启IPv6 forwarding和进行SLAAC⁶。

这样，局域网下的设备就可以通过IPv6上网了，没有邪道DHCPv6。

逃离 WordPress

Sat, 10 Jun 2023 20:08:14 +0800

迁移博客或许是每一个Blogger的宿命。

动机

如你所见，这是一个Hugo站点。而在这个域名中，曾经运行着WordPress。

你或许知道我的博客本来是WordPress的，而WordPress虽然大而全，但作为一个博客来说确实有点太重了。这倒不是“我可以不用你不能没有”的问题，而是不用就要关掉的问题，留着就会有各种漏洞，虽然网站没啥真正有价值的东西，但怪烦的。基于维护性和可移植性的优势，我早就想用静态网站生成器代替WP了（这个在两周年的文章中有提到），但苦于重定向做起来怪麻烦的，便一直拖着没有做。

那为什么下定决心了呢？还是因为WordPress的可维护性。当初我将网站从Vultr迁到腾讯云，一部分也是因为承载的网站越来越多，天天干爆内存，然后每次 mariadbd 就会当炮灰被杀掉。腾讯云轻量香港确实爽，2G RAM随便造……了一年。就在前两天，这个现象又出现了。很快，服务器的硬盘也不知道怎么回事就满了（不是swap的锅），这次死的又是 mariadbd。

之所以迁移起来困难，一直没干，一方面是因为目录结构不同，需要逐个手动重定向；而另一方面是WordPress上还有很多条评论，我不想丢掉。和这两者比起来，把文章扒下来转成Markdown反而成了相对容易的工作。

托管、生成器和主题

虽然静态网站可以直接用Caddy去serve，但本着 ~~“用自己的不如用别人的”~~ 尽量减少故障的原则，选择一般人使用的第三方托管方案，而这意味着又要经历常见的服务商选择问题了。老实说，Netlify、Vercel和GitHub Pages用户群都挺多，体验也都不错；微软的新服务Azure Static Web App也还可以，甚至有香港数据中心，但它是依托GitHub Actions的，build起来有点慢，最重要的原因是Azure那令人发指的控制台。看起来Netlify在中国大陆的速度比Vercel快一点，又没有GH Pages被墙得那么多，试了试几种网络环境发现没有什么访问问题，所以就选了Netlify。

没有选择Azure还有一个重要的原因。头抬起，这是Azure的控制面板，可看到为粗糙的边缘，请坐和放宽：

至于网站生成器的选择，老实说，考虑到我稀烂的前端水平，我的选择有点跟着主题走，顶多对主题进行一点魔改。做出这个决定时，有hexo-theme-icarus和hugo-theme-stack两个选择摆在我面前，最终因为我对Go的喜爱（以及前者带有jQuery）而选择了后者。

加载首页只需要200KB出头，相比之前去掉图片还有2MB，很香啊！还能细粒度控制KaTeX加载，这么久终于体会到了抠流量的快感（误）。

Hugo的主题有一个好，就是不用学PHP就可以魔改，我 ~~大概可能也许~~ 有能力按照自己的需求改一改吧。

当前进度：

选择托管平台：Netlify
选择生成器：Hugo
选择主题：hugo-theme-stack
魔改主题

文章

Markdown导出WordPress文章这件事，有人做过解决方案了，导出的Markdown有front matter，看起来交给Hugo基本没有什么阻碍。但是实际操作起来坑还是很多的，光是把文章导出再导入，就花了我三天时间 ~~（一边摸鱼）~~。

其一是图片的存储必须要整个移走，之前WordPress历经了三种存储图片方式，分别是WordPress自带图片存储、Cloudreve + OneDrive存储，最后是阿里云对象存储。自己铲屎山的时候才意识到，这三种方式实质上混杂在文章之中，而且由于WordPress问题，内部图片也是通过指向网站的链接管理的，也就是说WordPress存储的图片还要分IP+端口、域名+端口和域名访问。一不做二不休，干脆直接换个存储桶吧，路径正好也跟页面的slug对应，折腾起来也会容易很多。顺便推荐一波Cyberduck，比阿里的OSS Browser好用多了。

其二是各种复杂样式问题，包括但不限于分栏、复杂表格等，不可否认用WordPress的可视化编辑器确实很方便，但如文字颜色等属性是基于自定义CSS class实现的，

当前进度：

导出WordPress文章
导入文章
设定分类
设定标签
i18n
友链

评论是博客重要的内容，我的计划是写个小工具，从WordPress的REST API导出评论，然后导入第三方评论工具。这个事情会在所有文章都搬过来之后去做。

基于上面好线路服务器资源紧缺的现状，我挑选评论系统时将资源消耗放在了较重要的地位，也就自然盯上了无Node.js后端的Commento和Remark42。然而前者需要PostgreSQL，后者文档不太明白不说，还需要额外的注册登录才能评论，这与之前填入基本信息即可评论的初衷不符，于是转向了Twikoo。其使用Docker自行搭建的情况下，仅占用了70MB内存，文章详情页也仅需多加载150KB左右，算下来还是比较节省资源的。

果然，用的人多是有原因的……

当然也不是用的人少就一定不好用，毕竟我最后还是反复横跳到了Artalk。可选的多站点支持，50KB额外开销，Go后端，完善的文档……该给的确实都给了。折腾这么多，现在应该能安心了吧。

如果你对我做的转换工具感兴趣，可以查看下方链接。

当前进度：

部署新评论系统：Artalk
写转换工具：https://github.com/cyp0633/WP2Artran
导出，再导入

重定向

把评论都搬过来后，WordPress站点基本就没有值得留意的东西了，这个时候就可以把WordPress的permalink重定向到Hugo来了。

最后发现RSS倒是做了重定向，但是某些固定页面没做，就直接把DNS改了。之前那些页面就寄掉了。还好筛选过，也没有太大损失。

当前进度：

设置文章重定向：Hugo aliases已经做好了
设置RSS、友链等固定链接重定向

后记熟悉Netlify的读者应该知道，同一个站点可以分配多个domain。在上面的一切都做完之后，我将新博客放在了 <next.cyp0633.icu>，让它跟旧博客共存了一段时间。再确认运行正常之后，我将 <cyp0633.icu> 也指向了新博客，就此宣告了旧站的结局。然而Google搜索认为 <next.cyp0633.icu> 是规范网址，换言之不再索引 <cyp0633.icu>。可以在 netlify.toml 中添加如下的重定向规则，以直接将 <next.cyp0633.icu> 重定向到 <cyp0633.icu>：

toml

[[redirects]]
  from = "https://next.cyp0633.icu/*"
  to = "https://cyp0633.icu/:splat"
  status = 301
  force = true

用 Rust uutils 替换 Windows PowerShell 内置 cmdlet

Sat, 20 May 2023 00:00:00 +0000

更新：适用于Linux的Windows子系统（WSL2）已更新 2.0 版本，一定程度上解决了之前占用端口等弊病。再加上之前更新的许多实用功能，个人已经使用WSL2的zsh基本代替了Windows下的PowerShell，故本文的意义不再像以前那么大。

uutils是一个用Rust重写的GNU Coreutils，也就是Linux上的 cp、mv、touch 等程序的一个实现。虽然在Windows的PowerShell中执行这些命令也能得到类似于Linux的结果，但实际上是一个PowerShell内置cmdlet的alias，在某些情况下的兼容性并不是那么好。本文探索一种用uutils的命令替代PowerShell内置cmdlet的方法，以让Windows的命令行体验更加Unix化（虽然还是没那么Unix就是了）。

uutils/coreutils

安装uutils

可以使用预编译的二进制安装，也可以使用源代码编译安装。由于后面添加自动补全还需要源代码，所以我选择后者。

如果不需要shell自动补全，那么可以直接从上面GitHub仓库的releases下载对应的压缩包（coreutils-version-x86_64-pc-windows-{msvc|gnu}.zip），将解压后的coreutils.exe放在任何一个PATH下的目录下即可。至于如何添加PATH，此处不再赘述，很容易搜到。

默认编译或下载到的是multi-call binary，即调用方式为 coreutils.exe <command>，本文也按照这个情况书写。也可以编译为分离的二进制文件，具体请参考上面的GitHub Readme。

编译源代码需要先安装 Rust 工具链，未安装的请移步教程。

在你认为合适的位置，使用以下命令将其安装到Rust存放二进制文件的地方：

powershell

1
2
3

git clone https://github.com/uutils/coreutils
cd coreutils
cargo install --path . --features windows

编译出的二进制文件一般在 %HomePath%/.cargo/bin里面，应该是默认添加到PATH的。安装完成后可以开一个新的PowerShell，运行 coreutils 以验证是否安装完成。

为PowerShell添加自动补全

自动补全的主要用处大概是输入参数的时候能够按tab补全，如 ls --di 按下tab可以补全为 ls --directory。

有点类似于Bash的. bashrc初始化脚本，PowerShell的自定义设置由profile管理。用户profile的路径内置于PowerShell的 $profile环境变量，可以直接在PowerShell中运行 notepad $profile 来编辑。

但自动补全文本量很大，可以将每个命令的补全各自写入一个文件，然后在profile中引用。对于把补全文件放在同一个文件夹内的情况，可以在profile中添加以下内容：

powershell

$completionsPath = "C:\path\to\completions"  # Replace with the path to your completions directory

# Get all completion script files in the specified directory
$completionScripts = Get-ChildItem -Path $completionsPath -Filter "*.ps1" -File

# Load each completion script
foreach ($script in $completionScripts) {
    . $script.FullName
}

这样就可以加载C:\path\to\completions（自己定义）里的补全预设了。

然后回到coreutils的源代码文件夹中，用PowerShell执行以下命令：

powershell

1
2
3

foreach($cmd in'b2sum','b3sum','base32','base64','basename','basenc','cat','cksum','comm','cp','csplit','cut','date','dd','df','dir','dircolors','dirname','du','echo','env','expand','expr','factor','false','fmt','fold','hashsum','head','join','link','ln','ls','md5sum','mkdir','mktemp','more','mv','nl','numfmt','od','paste','pr','printenv','printf','ptx','pwd','readlink','realpath','relpath','rm','rmdir','seq','sha1sum','sha224sum','sha256sum','sha3-224sum','sha3-256sum','sha3-384sum','sha3-512sum','sha384sum','sha3sum','sha512sum','shake128sum','shake256sum','shred','shuf','sleep','sort','split','sum','tac','tail','tee','test','touch','tr','true','truncate','tsort','unexpand','uniq','unlink','vdir','wc','yes') {
    cargo run completion $cmd powershell > "C:\path\to\completions\$cmd.ps1"
}

这样就可以把自动补全输出到你自定义的补全预设目录（还是别忘了替换路径）。

取代PowerShell自带cmdlet alias

现在每次都要先输一个 coreutils 命令才能调用，既不方便也没法用自动补全，干脆直接把命令映射过来。

直接 Set-Alias 是不成功的，因为PowerShell自带alias。在profile中再添加以下内容：

powershell

foreach($cmd in'b2sum','b3sum','base32','base64','basename','basenc','cat','cksum','comm','cp','csplit','cut','date','dd','df','dir','dircolors','dirname','du','echo','env','expand','expr','factor','false','fmt','fold','hashsum','head','join','link','ln','ls','md5sum','mkdir','mktemp','more','mv','nl','numfmt','od','paste','pr','printenv','printf','ptx','pwd','readlink','realpath','relpath','rm','rmdir','seq','sha1sum','sha224sum','sha256sum','sha3-224sum','sha3-256sum','sha3-384sum','sha3-512sum','sha384sum','sha3sum','sha512sum','shake128sum','shake256sum','shred','shuf','split','sum','tac','tail','test','touch','tr','true','truncate','tsort','unexpand','uniq','unlink','vdir','wc','yes') {
    Remove-Alias $cmd -ErrorAction SilentlyContinue
    Set-Item function:$cmd -Value {coreutils $cmd $args}.GetNewClosure()
}

（修改自这个 Gist）

因为 sleep、tee 和 sort 不允许修改，所以只好删掉了。

如果没有意外的话，再打开一个PowerShell，就可以使用新的uutils了。

参考资料：

从 Docker 到 Podman

Tue, 07 Mar 2023 00:00:00 +0000

我烦Docker很久了。倒不如说我烦 “屁大点事都要容器化” 很久了，但在不得不用的时候，与其用自成一体的Docker，不如用同样遵守OCI的Podman。

由于Docker和Podman基本能够兼容，这里是一些个人碰到可能比较有意思的用法。我也不知道会不会继续写，什么时候会写。

与systemd结合

PROTECTED_0 已被弃用，请参考使用 Quadlet 的新方法

现在使用 podman generate systemd，会提示 DEPRECATED command: It is recommended to use Quadlets for running containers and pods under systemd.

Red Hat 文档

Docker有 dockerd，能自主控制容器的启动与停止，Podman没有。相比Docker，Podman的特点之一就是与systemd的融合，毕竟两个玩意全都是Red Hat自家的，他们大概也不想再做一个daemon。

解决办法就是，Podman容器可以使用systemd单元来控制启停等功能。举个例子，如果是root用户的容器，可以直接运行下面的命令，生成一个systemd单元：

bash

`1`	`podman generate systemd --new <container_name> > /etc/systemd/system/<service_name>.service`

记得替换你自己的容器名称和单元名称。虽然前后两个名字不统一又不是不能用，但个人强烈建议统一一下，可能能免去一些玄学问题。然后就可以用平常管理systemd单元的方法来管理它了。

Podman推荐的用systemd管理容器的方式是Quadlet。一个Quadlet形似systemd unit，但又神似docker-compose YAML。相比于已经弃用的 podman-systemd ，Quadlet表现能力更强，更容易编辑。看一眼 redis.container 示例¹就明白了：

ini

[Unit]
Description=Redis container

[Container]
Image=docker.io/redis
PublishPort=6379:6379
User=999

[Service]
Restart=always

[Install]
WantedBy=local.target

详细的文件结构在 Podman 的文档中有说明。除上面的 .container 示例外，还有.kube、.network 和 .volume 文件分别描述基于K8S的服务、容器网络设备和卷。

编辑完成后，要将上面的文件放进下面的目录之一²：

$HOME/.config/containers/systemd/（rootless container）
/usr/share/containers/systemd/
/etc/containers/systemd/

然后运行 systemd daemon-reload，就可以自动生成对应的systemd unit。比如在我的设备上，刚刚的 redis.container 生成的systemd unit就在 /run/systemd/generator/redis.service：

ini

# Automatically generated by /usr/lib/systemd/system-generators/podman-system-generator
#
[Unit]
Description=Redis container
SourcePath=/etc/containers/systemd/redis.container
RequiresMountsFor=%t/containers

[X-Container]
Image=docker.io/redis
PublishPort=6379:6379
User=999

[Service]
Restart=always
Environment=PODMAN_SYSTEMD_UNIT=%n
KillMode=mixed
ExecStop=/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
ExecStopPost=-/usr/bin/podman rm -f -i --cidfile=%t/%N.cid
Delegate=yes
Type=notify
NotifyAccess=all
SyslogIdentifier=%N
ExecStart=/usr/bin/podman run --name=systemd-%N --cidfile=%t/%N.cid --replace --rm --cgroups=split --sdnotify=conmon -d --user 999 --publish 6379:6379 docker.io/redis

[Install]
WantedBy=local.target

当然，放出来的目的只是展示会生成一个怎样的文件，实际有需要时都是编辑Quadlet的。

从其他格式生成

坏消息是似乎无法直接为一个已经存在的容器生成Quadlet了；但也有好消息，只要能搞来 podman run 命令（或docker-compose YAML），就可以使用 PROTECTED_1 工具生成Quadlet。比如：

bash

$ podlet podman run --name redis -p 6379:6379 --restart always --user 999 docker.io/redis
# redis.container
[Container]
Image=docker.io/redis
ContainerName=redis
PublishPort=6379:6379
User=999

[Service]
Restart=always

开机启动

截至编写本文时，由于Quadlet生成的systemd unit是自动生成、可能改变的，所以无法enable³（会提示 Failed to enable unit: Unit is transient or generated）。

解决办法是在Quadlet中添加任何 [Install] 栏的内容，比如之前的 redis.container，或者参考官方文档的做法：

ini

1
2

[Install]
WantedBy=multi-user.target default.target

然后就可以自动开机启动了。

自动更新镜像

Red Hat 文档

手动重新找到同样的参数更新，不仅麻烦还不安全。Podman自带了一个 auto-update 工具，可以自动更新镜像，但依赖systemd unit。

适用于 PROTECTED_0 的方法（已弃用）

先创建个新容器，至于用 run 还是 create 其实都没什么关系。但不要忘了指定 io.containers.autoupdate label。属性可以为 registry 或者 local。

bash

`1`	`podman create --label io.containers.autoupdate=registry --name <container_name> <image_name>`

然后还要创建一下systemd单元，方法如上，这里再次建议单元名为容器友好名称，或者那个64位的随机hex值。

在上文容器Quadlet中的 [Container] 一栏中，添加一行 AutoUpdate=，后面的值从下面的选项中选一个：

registry：更新的时候会pull一下
local：有需要的时候得手动pull，如果本地镜像更新，用本地的替换

启用systemd单元后，建议先试一下：

bash

`1`	`podman auto-update --dry-run`

看名字也知道不会真的更新，只不过看看是不是配置对了。真正更新的时候把 --dry-run 去掉就行。

这玩意看起来更像是 apt update && apt upgrade 或者 pacman -Syu 之类的工具。如果更新失败，它也会自动进行回滚。

Netavark和Nftables

Netavark是Podman依赖的网络组件，后者需要前者创建虚拟网络等。而Nftables是iptables的替代品，依托Netfilter，用于创建防火墙规则或重定向等操作。

Netavark的默认后端是iptables。当Podman涉及到创建Pod等与虚拟网络有关的操作时，iptables-nft会操作Nftables创建一个链，而这个链的名字常常因为各种原因已经使用，于是会出现以下错误信息：

plaintext

`1`	`Error: starting container xxxxx: netavark: code: 1, msg: iptables: Chain already exists.`

这时需要在 /etc/containers/containers.conf 里，将后端替换为Nftables⁴：

conf

[network]
firewall_driver = "nftables"

如果版本比较老，可以改成 "none"。