第一步：启动一个新实例

启动一个新的 EC2 实例。

• 这个实例与需要被缩减 EBS 卷容量的实例尽可能相同，其中，操作系统和实例类型必须相同，所在的 AWS 区域及子网也必须相同。
• 可以不为其添加密钥对。
• 其 EBS 卷容量为需要缩减到的容量。
• 添加储存时取消勾选「终止时删除」。

待实例启动后，终止（非停止）实例。

第二步：附加新的 EBS 卷

上一步终止新的实例后，其 EBS 卷被保留且已从实例分离，并拥有所有我们需要的分区，因此，我们不需要再进行任何分区操作啦。

转到 EBS 管理页面，将新的 EBS 卷连接到需要被缩减 EBS 卷容量的 EC2 实例。

第三步：迁移数据

列出所有可用块设备的信息，发现新的 EBS 卷是 nvme1n1，其中 nvme1n1p1 就是我们迁移的目标分区，而 nvme1n1p14 和 nvme1n1p15 是引导所需要的分区，我们不用理会它们：

1
2
3
4
5
6
7
8
9
10

root@ip-***:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1      259:0    0   30G  0 disk
├─nvme0n1p1  259:1    0 29.9G  0 part /
├─nvme0n1p14 259:2    0    3M  0 part
└─nvme0n1p15 259:3    0  124M  0 part /boot/efi
nvme1n1      259:4    0   20G  0 disk
├─nvme1n1p1  259:5    0 19.9G  0 part
├─nvme1n1p14 259:6    0    3M  0 part
└─nvme1n1p15 259:7    0  124M  0 part

挂载并清除新分区内所有数据：

1
2
3

mkdir -p /mnt/newebs
mount /dev/nvme1n1p1 /mnt/newebs
rm -rf /mnt/newebs/*  # 也可以格式化新分区

迁移根目录*（选做：深入理解各参数的含义）*：

1

rsync -aAHXxvP / /mnt/newebs/  # 如果没有 rsync，请安装

第四步：修复引导（大部分情况不需要）

列出卷的 UUID：

1
2
3
4
5
6
7
8
9

root@ip-***:~# blkid
/dev/nvme0n1: PTUUID="********-****-****-****-************" PTTYPE="gpt"
/dev/nvme0n1p1: UUID="********-****-****-****-************" TYPE="ext4" PARTUUID="********-****-****-****-************"
/dev/nvme0n1p14: PARTUUID="********-****-****-****-************"
/dev/nvme0n1p15: SEC_TYPE="msdos" UUID="****-****" TYPE="vfat" PARTUUID="********-****-****-****-************"
/dev/nvme1n1: PTUUID="********-****-****-****-************" PTTYPE="gpt"
/dev/nvme1n1p1: UUID="********-****-****-****-************" TYPE="ext4" PARTUUID="********-****-****-****-************"
/dev/nvme1n1p14: PARTUUID="********-****-****-****-************"
/dev/nvme1n1p15: SEC_TYPE="msdos" UUID="****-****" TYPE="vfat" PARTUUID="********-****-****-****-************"

• 由于我们创建了一个和需要被缩减 EBS 卷容量的实例配置相同的实例，并取得了它的 EBS 卷，在大部分情况下，新卷和旧卷各分区的 UUID 应该是相同的，因此不需要修复引导。
• 如果不是这样，请修复引导，替换引导配置中的 UUID 即可，此处不赘述。

第五步：替换根设备

1. 取消挂载新 EBS 卷：

1

umount /mnt/newebs

1. 转到实例管理页面，停止（非终止）需要被缩减 EBS 卷容量的实例。
2. 在实例信息中的储存分页，复制根设备名称，一般为 /dev/xvda。
3. 转到 EBS 管理页面，断开新旧两个 EBS 卷的连接。
4. 重新连接新 EBS 卷到该实例，设备处填入先前复制的根设备名称。
5. 重新启动该实例。
6. 验证实例工作正常后，为旧 EBS 卷创建一个快照作为备份，就可以删除它了。
7. 某些情况下，停止并重新启动实例可能导致 IP 地址变更，如果你有一个指向该实例的域名，记得修改 DNS 记录。

Done!

是不是很简单w

环境

• 路由器：OpenWrt 21.02.0-rc3
  • 绝大部分厂商的原厂固件的 IPv6 防火墙都是残缺的，请不要使用原厂固件
  • 光猫应当配置为桥接模式并使用路由器拨号，请不要让光猫承担它不该承受之重
• 需要暴露的主机：Debian GNU/Linux 11
  • 当然也通用于其他 Linux 发行版

准备工作

确认已经取得 /64 的 IPv6 子网

一般可在路由器管理页面确认，也可通过其他方式确认。
如果获得的子网大小不是 /64 ，本文仍可供参考，但需要有一些小改动。
如果只能取得 /128 的子网（整个子网只有一个地址），这种梦回 IPv4 时代的情况通常出现在校园网，考虑到没法换 ISP，要不……行而上学，不行退学？
下文中，我们假定取得的子网是 2001:2002:2003:2004::/64。

确认 ISP 没有阻止入站连接

如果路由器使用的是 OpenWrt，默认的防火墙规则不会阻止 ICMP 入站连接；如果是其他路由器固件，请先完全关闭防火墙。
本文假设系统防火墙已经被恰当配置，不会阻止需要暴露的端口的入站连接。

1. 访问 ip.sb，取得当前设备的 IPv6 临时公网地址，我们假设它是 2001:2002:2003:2004::1234。
2. 尝试在外部网络 ping 上述 IPv6 公网地址。
   • 最简单的方式是，在 Android 手机上通过 Termux 使用蜂窝移动网络 ping。（应当先确定 Termux 能连接到 IPv6）
3. 如果能 ping 通，则进行下一步。如果不能，通常没有必要再进行下一步。
4. 向 OpenWrt 添加一条通信规则（访问 cgi-bin/luci/admin/network/firewall/rules）以临时允许入站连接：
   • 允许 TCP 和 UDP，源区域为 wan (包含 wan, wan6)，目标区域为 lan，操作为接受，其余留空，保存并应用。
5. 在本机挂载一个 web 服务，如 python3 -m http.server 8321，8321 可以替换为自己选定的端口（如为 80, 443 等端口，可能需要 root 权限）。
6. 尝试在外部网络访问这个端口，如 curl http://[2001:2002:2003:2004::1234]:8321。
7. 更换端口重试几遍，重点留意 80, 443, 8080 等常见端口有无被封锁；如被封锁，尝试不常见的端口。
8. 关闭 web 服务，删除先前创建的通信规则，保存并应用。如果是其他路由器固件，请重新打开防火墙，并想办法刷入 OpenWrt。

如果 ISP 阻止了入站连接，请考虑换一家 ISP。
有些路由器的原厂固件可能无法关闭 IPv6 防火墙并造成假阳性结果，请考虑使用 OpenWrt。

取得设备的不变后缀

选项一：EUI-64（推荐）

EUI-64 地址有着我们需要的优点：后缀固定不变、前缀实时更新。一般情况下，我们应该使用它。如果获得的子网大小不是 /64，可能不按预期工作。

Linux:

1

sudo ifconfig

Windows（需要提权）:

1
2

set-netipv6protocol -RandomizeIdentifiers Disabled  # Windows 默认不使用 EUI-64，启用它
ipconfig /all

1. 找到目前用于连接互联网的网络适配器。
2. 找到一个 IP 地址，它应该类似于 2001:2002:2003:2004:****:**ff:fe**:****，它就是该设备的 EUI-64 地址。
3. 记下 ****:**ff:fe**:**** 的部分，下文假设它是 1:20ff:fe77:2077。
4. 验证 EUI-64 地址（可选）：参见 通过EUI-64自动生成IPv6地址和IPv6链路本地地址（Link-Local Address） | CCIE 工程师社区。

选项二：不使用不变后缀，使用临时 IPv6 地址

并不推荐使用临时地址，这将导致防火墙规则难以编写。

请直接跳到下一节。

选项三：DHCPv6

并不推荐使用 DHCPv6，因为它总是落后于网络变化。如果家宽重拨导致分配到的 v6 子网变化，它根本不会自动更新，只有等到租约到期（一般是 12h）续租时才会更新。

首先选定一个 IPv6 后缀如 a1cd（也可不选定。默认分配的后缀一般是设备特定且不变的，不选定则自行记录默认分配的后缀）。
注意：有时候，在系统的默认配置下并没有完整的 stateful DHCPv6 支持，此时请使用其他方法。本文亦不含有打开 stateful DHCPv6 的教学。（DHCPv6 坏坏）

1. 在 OpenWrt 为需要的设备创建一个静态地址分配（访问 cgi-bin/luci/admin/network/dhcp），指定租期如 5m（因租约到期才会自动刷新，必须设定为较短的值以确保 DHCPv6 分配维持最新），填写选定的 IPv6 后缀（也可留空），保存并应用。
2. 物理上重新连接目标设备。
3. 刷新页面，在页面底部的 已分配的 DHCPv6 租约 里确认确实为该设备正确分配了需要的后缀和租期。
4. 如果租期没有被正确分配，仍为默认的 12h，则该设备不适合该方法。（除非能获得不变的 IPv6 子网）

配置防火墙

向 OpenWrt 添加一条通信规则（访问 cgi-bin/luci/admin/network/firewall/rules）：

• 协议：TCP 和 UDP
• 源区域：wan (包含 wan, wan6)
• 目标区域：lan
• 目标地址：
  • 使用 EUI-64 或 DHCPv6：::<需要暴露的主机的后缀>/::ffff:ffff:ffff:ffff，如 ::1:20ff:fe77:2077/::ffff:ffff:ffff:ffff 或 ::a1cd/::ffff:ffff:ffff:ffff（如果子网大小不是 /64，请自行改变掩码）
  • 使用临时地址：留空（注意：这会导致其他主机一并暴露，请避免同时留空目标端口）
• 目标端口：
  • 暴露特定端口：<需要暴露的端口或端口范围>
  • 整台主机暴露：留空
• 操作：接受
• 高级设置
  • 限制地址类型：仅 IPv6
• 其余维持默认
  • 特别提醒：源端口留空，只填目标端口

配置 DDNS

编写更新脚本

以 Cloudflare API 为例。
替换如下脚本中的环境变量，存放至合适的位置。

DNS ID 需要通过 Cloudflare API 查询获得，也可通过审查元素抓包获得。

使用 EUI-64 或 DHCPv6

在需要暴露的主机上运行，也可在同一子网下别的主机（含路由器）上运行，因此适合需要暴露的主机为 Windows 等比较坏坏的操作系统的情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CURRENT_IP=$(curl -s ipv6.ip.sb)
CURRENT_PREFIX=$(echo $CURRENT_IP | cut -d : -f 1-4)  # 如果子网大小不是 /64，此处需要修改
SUFFIX=<固定后缀>
DNS_RECORD=<域名>
ZONE_ID=<Zone ID>
DNS_ID=<DNS 记录 ID>
TOKEN=<API token>
if [ "$(cat /run/current_prefix 2>/dev/null)" != "$CURRENT_PREFIX" ]; then
        echo $CURRENT_PREFIX > /run/current_prefix
        curl -s \
             -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$DNS_ID" \
             -H "Content-Type:application/json" \
             -H "Authorization: Bearer $TOKEN" \
             --data '{"type":"AAAA","name":"'$DNS_RECORD'","content":"'$CURRENT_PREFIX:$SUFFIX'","ttl":1,"proxied":false}'
fi

使用临时地址

只能在需要暴露的主机上运行。

1
2
3
4
5
6
7
8
9
10
11
12
13

CURRENT_IP=$(curl -s ipv6.ip.sb)
DNS_RECORD=<域名>
ZONE_ID=<Zone ID>
DNS_ID=<DNS 记录 ID>
TOKEN=<API token>
if [ "$(cat /run/current_ip 2>/dev/null)" != "$CURRENT_IP" ]; then
        echo $CURRENT_IP > /run/current_ip
        curl -s \
             -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$DNS_ID" \
             -H "Content-Type:application/json" \
             -H "Authorization: Bearer $TOKEN" \
             --data '{"type":"AAAA","name":"'$DNS_RECORD'","content":"'$CURRENT_IP'","ttl":1,"proxied":false}'
fi

定时执行

使用 crontab

1

crontab -e

增加一行如下，注意替换 /path/to/script/。示例为每分钟执行一次，如需修改，可参考 crontab.guru。

1

* * * * * /path/to/script/setDNS.sh

使用 systemd

setDNS.service

放置到 /etc/systemd/system/ 下，注意替换 /path/to/script/。

1
2
3
4
5

[Unit]
Description=check IPv6 address and set DNS record

[Service]
ExecStart=/bin/sh /path/to/script/setDNS.sh

setDNS.timer

放置到 /etc/systemd/system/ 下。

1
2
3
4
5
6
7
8
9

[Unit]
Description=monitor IPv6 address and set DNS record minutely

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

即时启动并添加到开机启动。

1
2
3

sudo systemctl daemon-reload
sudo systemctl start setDNS.timer
sudo systemctl enable setDNS.timer

原本想购入一块 Raspberry Pi，奈何价格长期虚高，就在某天从女票票手里顺走了一块 PINE H64 Model B。往一张 TF 卡里灌入 Armbian 的镜像，就可以愉快地玩耍了。

Armbian 衍生自 Debian。对于 Debian 系，当你需要管理软件包时，通常会使用 apt 来完成。而要搜索软件包，则有 apt search 和 apt-cache search 两种方式，它们的搜索范围、结果详细度、输出的可读性都不尽相同，且通常后者是更快的。

自某个时候开始，在某些灌入 Armbian 的设备上，使用 apt search 搜索软件包变得无可容忍地慢，而 apt-cache search 却仍然保持着较高的速度。Armbian 论坛上的这个 topic 讨论了这个问题。

总地来说，这个问题与 apt 对软件包列表（存放于 /var/lib/apt/lists/ 中）的压缩有关，由于压缩被默认打开，且 lz4 压缩方式优先级较高，软件包列表被以 lz4 的方式压缩。在上述 topic 中，部分用户将压缩方式改为 gzip，解决了这个问题，因此 Armbian 已经合并了一个 Pull Request，提高了 gzip 的优先级，现在 Armbian 上的 apt 已经会默认使用 gzip 来压缩软件包列表。

然而，将压缩方式改为 gzip 显然不能解决所有用户的问题，上述 topic 中仍旧有不少用户反馈这个问题没有得到解决。实际经过测试，改回默认的优先级（优先使用 lz4 压缩）也不能解决问题。因此，最根本的解决方法就是，关闭压缩。

解决方法

1
2
3

sudo echo 'Acquire::GzipIndexes "false";' | sudo tee /etc/apt/apt.conf.d/99disable-compression
sudo rm /var/lib/apt/lists/*.gz  # 如果你的压缩方式是 lz4，请对应更改
sudo apt update

或者，你也可以只使用 apt-cache search，它总是相当快的。

后记

上游问题?

这似乎是一个上游问题。Armbian 在 2018 年 6 月对 apt 增加了一条默认配置 Acquire::GzipIndexes "true";，使得软件包列表的压缩被默认打开，但 apt search 慢的问题似乎要到 2020 年才出现。Debian 则默认没有配置压缩，因而掩盖了这个问题。
在 Debian GNU/Linux 10 (buster) on Windows 10 x86_64 上测试，得到了这样的结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

time apt search python
time apt-cache search python

# 未配置压缩（Debian 默认配置：不被压缩）
# apt search python  1.10s user 0.38s system 80% cpu 1.840 total
# apt-cache search python  0.34s user 0.14s system 99% cpu 0.481 total

# 开启压缩（默认优先级：被 lz4 压缩）
# apt search python  67.92s user 6.86s system 99% cpu 1:15.20 total
# apt-cache search python  0.38s user 0.18s system 99% cpu 0.568 total

# 开启压缩（Armbian 优先级：被 gzip 压缩）
# apt search python  678.15s user 6.50s system 99% cpu 11:25.26 total
# apt-cache search python  0.47s user 0.10s system 98% cpu 0.575 total

磁盘用量

不必担心关闭压缩后磁盘用量会大幅增长，事实上不会增加太多，磁盘空间并没有时间宝贵。关闭压缩后，Armbian 初始的软件源的软件包列表也仅仅占用 100M 左右的空间，确实不能明白默认开启压缩的用意。

关于 PINE H64 Model B

可以在这里下载适用于它的 Armbian 镜像。它的 TF 卡槽只有 HS 级别，并不支持 UHS。一张 4K 读写性能不太差的卡就能满足使用。
产品页和 PINE64 wiki 都写错了 WiFi 能力，它只能使用 2.4GHz 频段，不支持 11ac。
PINE H64 Model A 实际是一款流产的产品，由于它采用的 Allwinner(R) H6 SoC 在 PCIe 上的天坑，它的 mPCIe 插槽不再有很大的意义，没有 mPCIe 插槽的 Model B 就是这么诞生的。

那么，为了让脑海中漂泊无依的思绪找到其中一个归宿，绒布也就有了地球。