14 时 30 分，校学生 Linux 用户协会会长王永福同学简洁地介绍了活动流程安排和演讲嘉宾后，软件自由日活动正式开始。

首先，_Kerman 同学为大家介绍了他参与维护的开源幻灯片制作工具 Slidev。他讲解了 Slidev 的设计理念、功能特点以及使用场景，并现场演示了幻灯片的制作，为同学们制作幻灯片提供了一种更高效的新选择。最后，他鼓励同学们加入到 Slidev 这样的开源项目中来。

接下来，少年班学院的田佳嘉同学带来了《从一到无穷大：Lean4 是如何用程序构建数学世界的》的分享。他从 Lean4 的基本概念入手，介绍了 Lean4 在数学证明中的应用，展示了如何通过编程来构建和验证数学定理。他深刻的讲解给大家带来了许多启发，激发了同学们对形式化数学的兴趣。

茶歇之后，LUG 前会长罗嘉宏为我们分享了开源命令行绘图工具 GNUPlot 的应用场景与使用方式。他详细且直观地介绍了 GNUPlot 的基本功能和常用命令，并通过实际案例展示了如何使用 GNUPlot 进行化学相关数据的作图，让大家感受到了命令行工具的强大与便利。

随后，Pixi 项目的开发者秦慕为我们介绍了包管理器 Pixi。她从各种 Python 包管理器的优缺点与发展历史入手，介绍了 Pixi 的设计理念、功能特点以及使用场景，为同学们在开发、学习与科研中高效可靠地管理代码依赖提供了新选择。

在这之后，闪电演讲拉开帷幕。首先由来自中科大业余无线电协会的缪渠成同学介绍了其领导的卫星项目。该项目旨在挑战技术难点，计划在两年后发射一颗业余无线电卫星。他非常欢迎软件背景的同学参与其中。

闪电演讲压轴登场的是龙芯开发者关系负责人、安同开源社区创始人白铭骢。他介绍了龙芯处理器的发展历程与现状，指出了龙芯生态建设中的成就与挑战，并为同学们提供了参与龙芯生态建设的具体途径。

17 时 35 分，2025 年的软件自由日活动圆满结束。活动中大家积极交流分享，我们希望通过这样的形式，让更多的同学了解到开源社区的魅力。

每年的 SFD 活动都在 9 月的第三个周六举行，历年活动在 这里 查看，如果您有意向在下一届的 SFD 活动中分享您的经验，欢迎 联系我们。

本次活动幻灯片、录像、照片等资料已经上传 LUG FTP: https://ftp.lug.ustc.edu.cn/%E6%B4%BB%E5%8A%A8/2025.09.20_%E8%BD%AF%E4%BB%B6%E8%87%AA%E7%94%B1%E6%97%A5/

新生活力课堂主要面向刚入学的新生。在活动的上半场中，王永福同学为大家带来了《实用工具介绍》，并从科大学习生活中的需求出发，介绍了科大网络资源与一些实用工具，包括 Vlab、USTC LaTeX、LUG GitLab、科大网盘等。此外，还针对性地介绍了 LaTeX 与 Markdown，助力同学们更高效地编写作业和报告；以及 GitHub 与 Google Scholar 等平台，助力同学们更高效地进行科研。最后，王永福向新生们介绍了 LUG 与一些近期活动，欢迎大家加入 LUG，一起学习和交流。

中场休息环节，同学们进行了自由交流与提问，气氛热烈。

活动的下半场是王永福同学带来的《面向高效学习/科研/创作的 AI 工具入门》，他从 AI 工具的意义出发，介绍了多种聊天机器人、AI 编程工具、图像生成工具和视频生成工具。最后，王永福重点介绍了用于 AI 工具的提示工程，包括其重要性、原则与实用技巧，帮助同学们更有效地使用 AI 工具。

活动照片、讲稿等资料可在 LUG FTP 上查看：

• 现场照片
• 视频回放
• 《实用工具介绍》幻灯片
• 《面向高效学习/科研/创作的 AI 工具入门》幻灯片

作为合肥地区最大的 Linux 用户组织，中国科大 Linux 用户协会致力于通过 SFD 普及软件自由思想，凝聚自由软件社区，将优秀的自由软件介绍给更多开源社区的成员，最大限度帮助自由软件作者实现服务于开源社群的价值。

今年的软件自由日活动预计于 2025 年 9 月 20 日（九月第三个星期六）于中国科学技术大学（合肥）举行，现面向校内外所有社区成员公开征集软件自由日讲座或其他与主题有关的活动，有意愿的社区成员可尽快联系我们。

联系方式

往届活动和详细介绍

• 2024 SFD
• 2023 SFD
• 2022 SFD
• 2021 SFD

背景 & 原理

在使用命令行的过程中，我们经常遇到一个需求，那就是让程序在退出当前终端后保持运行。在以往，我们可能会使用 nohup 加让程序后台运行的方式，比如：

➜  ~ nohup ping 127.0.0.1 &
[1] 89083
nohup: ignoring input and appending output to 'nohup.out'
➜  ~ ps -elf |grep ping
0 S yfy        89083   88672  0  85   5 -  3352 -      11:39 pts/0    00:00:00 ping 127.0.0.1

这样在断开终端连接后，重新登陆到服务器，可以发现 ping 进程仍然在运行。nohup 默认将程序输出追加到 nohup.out 文件中，可以通过 tail 检验这一点。

➜  ~ tail -f nohup.out
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.024 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.027 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=0.035 ms
➜  ~ ps -elf |head -n1
F S UID          PID    PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
➜  ~ ps -elf |grep ping
0 S yfy        89083       1  0  85   5 -  3352 -      11:39 ?        00:00:00 ping 127.0.0.1

正常情况下，当终端退出时（如关闭终端窗口，或者 ssh 网络中断），shell 进程会给所有子进程发送一个 SIGHUP 信号，从而导致进程结束。而 nohup 可以让进程忽略掉 SIGHUP 信号，从而在后台保持运行。

Tip: ps 输出还可以观察到 ping 进程父进程变为了 1，这是因为原本的父进程 shell 已经退出，Linux 内核会将孤儿进程交由 init/systemd 进程托管。

nohup 在简单场景比较有用，但是不适用更复杂的场景。比如用户无法再对后台进程进行输入操作，并且同时维护多个进程也很不方便。不过我们其实还有更优雅、更强大的方案，那就是 tmux。

tmux 是一个终端复用器（Terminal MUltipleXer）。简单来说，tmux 的功能可以概括成一句话：在一个终端里创建多个窗口，并且将窗口分割成多个窗格，每个窗格都运行独立的 shell 进程。这样你就可以让多个应用程序同时运行，而无需打开多个终端模拟器窗口（terminal emulator，如 Xshell、PuTTY、Windows Terminal 等）。下图展示了使用 tmux 创建了一个窗口，并将窗口上下分屏成两个窗格，每个窗格都运行一个 zsh。

更重要的是，tmux 将终端和会话（session）进行了分离。我们把创建的窗口和窗格（和其中创建的所有 shell 进程及子进程）看成一个会话，用户可以随时退出（detach）当前会话，会话会在服务器后台保持运行。在之后，用户可以重新连接上（attach）这些会话，从而继续之前的工作。

原理上，tmux 采用了客户端和服务器分离的架构（C/S 架构）。用户看到和交互的是 tmux client，tmux client 中创建的窗口（和 shell 进程）连接在 tmux server 进程上。因此，当用户退出 tmux client 后，会话内容可以在后台运行。 通过 pstree 命令，可以看到上图中运行的两个 zsh 的父进程是 tmux: server。而和用户交互的其实是 tmux: client，其下面并无其他子进程。

➜  ~ pstree -u yfy|less
sshd---zsh---tmux: client
tmux: server-+-zsh-+-less
             |     `-pstree
             `-zsh---ping

在简单了解了下 tmux 的原理后，马上开始 tmux 的上手体验吧。tmux 基础使用非常简单，花 10 分钟就可以完全了解。

tmux quick start

大部分 Linux 发行版都提供 tmux 包，可以通过包管理器安装。其他安装方式（如编译安装）也可以参考官方文档：Installing · tmux/tmux Wiki。

在安装 tmux 后的第一步，我们首先创建一个 tmux 会话。运行 tmux 命令后，会进入 tmux 并创建第一个窗口，在这里你可以像往常一样执行命令。

tmux

接着我们介绍最重要的退出话会话和重连会话的方法。按下 Ctrl-B 后，再按 d 可以退出（detach）当前会话。这样会回到输入 tmux 前的 shell。

通过 tmux list-sessions 或者 tmux ls 可以查看当前所有的会话信息。

➜  ~ tmux ls
0: 1 windows (created Thu Jul  3 14:06:05 2025)

通过 tmux attach 可以连接回第一个会话。

tmux a  # attach

接下来介绍 tmux 最关键的多窗口管理功能，有了它就可以大大提升多任务操作的效率。 tmux 有 session（会话）, window（窗口）, pane（窗格）三个粒度。session 是 tmux 最大的一个粒度，session 下可以创建多个 window，window 可以分割成多个 pane。这里重点介绍窗口和窗格相关的快捷键。

窗口操作

# 创建
Ctrl-B c # 创建新的窗口
Ctrl-B & # 删除当前窗口

# 切換
Ctrl-B Tab        # 切换到刚刚的窗口
Ctrl-B p          # 切换上一个
Ctrl-B n          # 切换下一个
Ctrl-B 数字编号    # 切换到指定一个窗口

# 修改窗口名字
Ctrl-B ,          # 修改当前窗口名字

窗格操作

# 创建
Ctrl-B \"     # 上下切分
Ctrl-B %      # 左右切分
Ctrl-B x      # 删除

# 切换
Ctrl-B 方向键      # 方向键上下左右
Ctrl-B [hjkl]     # 使用 vi 风格的 hjkl 键切换，分别对应左上下右

Ctrl-B z      #  切换全屏

相信你操作了这些快捷键后，已经可以感觉到 tmux 的方便和强大了。tmux 也是一个像 vim 那样灵活性很高的软件，很多时候一个你不知道的快捷键就能极大体验。因此需要去更多尝试。tmux list-keys 可以查看 tmux 的所有快捷键绑定。

本文只介绍了 tmux 的快捷键使用方法，tmux 的软件设计非常简洁高效，以上所有快捷键都有对应它的一个子命令，比如垂直划分窗格对应 tmux split-window -v 命令。如果记不住快捷键，可以直接使用 tmux 命令。tmux man 手册的 COMMAND 章节提供了所有命令的详细解释。另外本文没有介绍 tmux 的 vi copy 模式，使用该模式可以方便查找、复制程序输出内容，该内容比较进阶，感兴趣的读者可以自行了解。

常用配置分享

tmux 像 vim 一样支持高度定制化，可以通过修改 ~/.tmux.conf 配置各种快捷键，网络上也有 oh-my-tmux 这样的项目来帮你做一些配置。接下来分享一些我长期使用下来，感觉很有必要的配置，完整配置见我的 github 仓库。

Bonus：在 ~/.bashrc 或 ~/.zshrc 中设置 alias t="tmux"，tmux attach 效率立刻提升 300%！

t      # 创建 sessin
t a    # attach 到第一个 session

修改快捷键前缀

Ctrl-B 按起来距离比较远，很不方便。可以修改成 Ctrl-X。

# prefix
set -g prefix C-x
unbind-key C-b        # disable default prefix
bind C-x send-prefix

划分窗格快捷键

窗格左右划分和上下划分快捷键比较难记。修改为下划线 _ 是上下分屏，- 是左右分屏。

# @ pane
# split current window horizontally
bind _ split-window -v -c "#{pane_current_path}"

# split current window vertically
bind - split-window -h -c "#{pane_current_path}"

鼠标操作

tmux 默认没有启用鼠标，导致无法使用鼠标滚动历史记录。启用鼠标后，还可以直接点击切换不同窗格，以及拖动选择文字复制。

set-option -g mouse on # open mouse scroll

打开窗口时默认路径

tmux 打开新窗口时，shell 的默认路径是启动 tmux 客户端时的路径。可以通过以下配置实现：

• Ctrl-X Alt-C ：更改默认路径为当前路径
• 创建 panel 时，使用当前路径（-c 参数）

bind M-c attach-session -c "#{pane_current_path}" # Alt-C, to change current path

# @ pane
# split current window horizontally
bind _ split-window -v -c "#{pane_current_path}"

# split current window vertically
bind - split-window -h -c "#{pane_current_path}"

移动窗口顺序

Ctrl-Shift 加方向键左右，可以调整 window 的顺序。

bind -n C-S-Left swap-window -t -1\; select-window -t -1
bind -n C-S-Right swap-window -t +1\; select-window -t +1

session 操作

虽然 window 和 pane 已经足够进行多任务管理了。但是 tmux 提供的多 session 操作也有其用处。适合管理若干完全不相关的任务。

修改快捷键，使其和 window 快捷键类似：Ctrl-C 创建新 session，N/P （大写）切换上一个和下一个 session。

# create session
bind C-c new-session

# session navigation
# (/)   #move to prev/next session
bind -r BTab switch-client -l  # move to last session
bind -r N switch-client -n
bind -r P switch-client -p

复制文字后不自动跳到结尾

tmux 鼠标选中文字会自动复制，但是会自动跳到结尾。有时在查看一些很长的输出历史时，并不想回到结尾，可以通过以下配置禁用跳转：

# copy select text, and don't jump to end
# https://stackoverflow.com/questions/32374907/tmux-mouse-copy-mode-jumps-to-bottom
bind -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-selection

鼠标选中文字后会进入 tmux 的 copy 模式，无法输入命令，此时可以按 q 退出。

tmux in tmux

有时候想要在 tmux 内再连接另一台服务器，然后也使用 tmux。正常情况下 tmux 快捷键只会传递给外层的 tmux 因此无法工作，但是可以使用以下配置实现按 F12 在内外 tmux 间切换。

# 按 F12 切换到内嵌 tmux，在 macos 里需要系统设置中取消 F12 占用
# 1. prefix 为 None，不再拦截快捷键
# 2. key-table 为 off，下面再绑定 off 下的 F12，使之能退出内嵌模式
# 3. 改变 statusbar 颜色，以便知道已进入内嵌模式
# 4. 如果处于特殊模式，退出
unbind -T root F12
bind -T root F12 \
  set prefix None \;\
  set key-table off \;\
  set status-style bg=colour235 \;\
  if -F '#{pane_in_mode}' 'send-keys -X cancel' \;\
  refresh-client -S

# 在 off 表里绑定 F12，恢复之前的设置，以退出该模式
bind -T off F12 \
  set -u prefix \;\
  set -u key-table \;\
  set -u status-style \;\
  refresh-client -S

另一个小技巧是：连续按两次 Ctrl-B 时快捷键会传递给内部 tmux。

参考资料

• Tmux 使用教程 - 阮一峰的网络日志
• Ham Vocke — A Quick and Easy Guide to tmux - Ham Vocke
• tmux 内联使用方法

在活动中，LUG 会长罗嘉宏同学系统讲解了 Linux 操作系统的基础知识，涵盖其开源特性、技术优势、应用场景及主流发行版本。通过详实的案例分析与技术对比，帮助在场同学对 Linux 系统形成了基本认知框架。

在随后的实践环节中，社团成员分组指导参与者进行系统安装。无论是通过校内 Vlab 平台远程体验，还是在虚拟机环境进行安装，亦或是实体设备的双系统部署，工作人员均针对不同需求提供个性化指导。现场同学通过互助协作，亲身体验 Linux 系统的安装流程。

本次活动通过理论普及与动手实践的有效结合，帮助参与者建立起对 Linux 系统的初步认知。相信在未来的活动中，会有更多精彩的内容等待着大家。

相关课程资料已同步上传至 FTP：Linux 101 第一课 & Linux Install Party

背景

USTC Hackergame 长期以来使用 Docker 及 Docker Compose 来部署和管理各种题目。对于 nc 类题目，我们使用一个简单的 Python 管理程序来为每个已验证的传入连接创建一个单独的题目运行环境容器，以保证选手之间的隔离。为了动态创建容器，我们将 /var/run/docker.sock 暴露给这个 Python 程序，以便它可以调用 Docker API 来创建容器。由于这个 Python 程序足够简单，我们认为这样做是安全的。而对于 Web 类题目，我们要求出题人在题目内部做好隔离，然而这样带来了额外的心智负担，而且容易出错，可能导致非预期解或出现能够干扰其他选手的情况。

在 2024 年 Hackergame 中，我们决定实现 Web 类题目的容器隔离方案，北京大学 GeekGame 基于我们的 nc 容器管理方案实现了一个简单的 Web 类题目容器管理方案，该方案同样通过透传 Docker Socket 实现对 Web 题目的容器管理。然而，Web 题目的反向代理比 nc 复杂得多，这使得我们对该方案的安全性存在较大的担忧，一旦该管理程序被攻破，攻击者可以直接控制整个服务器。因此，我们需要一个更安全的方案，使得即使 Web 题目的容器管理程序被攻破，攻击者也无法轻易控制整个服务器，这就需要在隔离的、低权限的环境中运行 Docker Daemon。

Rootless Docker-in-Docker

Rootless Docker 是在低权限环境中运行 Docker 的一种方案。Docker 官方提供了一种 Rootless Docker in Docker 的方案，只需要一行命令即可启动：

docker run -d --name dind-rootless --privileged docker:25.0-dind-rootless

该方案在容器中以非 root 用户（UID 1000）创建用户命名空间，并分离其他命名空间和运行 Docker Daemon。然而，该方案存在一些问题：

1. 该方案需要 --privileged 选项，以禁用 seccomp、AppArmor 和 mount masks，但这意味着容器将获得更高的权限，可能导致安全问题。
2. 该方案无法使用 cgroup 来限制容器资源使用，因为 Rootless Docker 需要 systemd 将 cgroup 路径委托给 Docker Daemon 才能执行资源限制。虽然可以用 rlimit 等方案来限制资源，但其工作在进程粒度而非容器粒度，而且可以被轻松禁用。由于 Hackergame 需要强制执行容器资源限制，该问题是致命的。

基于 Systemd User Instance 的 Rootless Docker-in-Docker

为了解决上述问题，我们采用了一个基于 Systemd User Instance 的 Rootless Docker-in-Docker 方案。该方案在 Systemd User Instance 中运行 Rootless Docker Daemon，以实现资源限制和更好的安全性。

Systemd in Docker

为了实现该方案，首先需要在容器中运行 systemd。systemd 的网站上列出了在容器中运行 systemd 的要求，对于 Docker 来说，主要有以下几点：

1. 保留 CAP_SYS_ADMIN 特权。
2. 启用私有 cgroup 命名空间，并将 /sys/fs/cgroup 挂载为可写。
3. 将 /tmp, /run, /run/lock, /var/lib/journal 挂载为 tmpfs。
4. 将 stop_signal 设置为 SIGRTMIN+3，以便 systemd 可以正确关闭。
5. 禁用 AppArmor 或 SELinux。

我们在 docker-compose.yml 中添加了以下内容来实现这些要求：

cap_add:
  - SYS_ADMIN
  - NET_ADMIN
cgroup: private
devices:
  - /dev/net/tun:/dev/net/tun
tmpfs:
  - /tmp
  - /run
  - /run/lock
  - /var/lib/journal
stop_signal: SIGRTMIN+3
tty: true
security_opt:
  - seccomp=seccomp.json
  - apparmor=unconfined
  - systempaths=unconfined

其中 seccomp.json 可以从这里获取，该文件在 Docker 默认 seccomp 配置的基础上允许了 keyctl 和 pivot_root 系统调用，这些系统调用是 Docker 所需要的。此外，该配置还一并禁用了 mount masks (systempaths=unconfined)，因为 Docker 启动容器时需要重新挂载 /sys。此外，我们还保留了 NET_ADMIN 特权，因为一些 systemd 的组件需要该特权。

需要注意的是，cgroup: private 并不会将 /sys/fs/cgroup 挂载为可写，因此我们需要在容器启动时手动处理，可以通过一个自定义的 entrypoint.sh 来实现：

#!/bin/bash

set -euo pipefail

mount --make-rshared /

# Remount cgroup
umount /sys/fs/cgroup
mount -t cgroup2 -o rw,relatime,nsdelegate cgroup2 /sys/fs/cgroup

exec /lib/systemd/systemd

Rootless Docker Daemon in Systemd User Instance

在容器中以非 root 身份运行 Docker Daemon 非常简单，只需要在容器中安装带 Rooeless 支持的 Docker：

RUN apt-get install -y ca-certificates curl && \
    install -m 0755 -d /etc/apt/keyrings && \
    curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc && \
    chmod a+r /etc/apt/keyrings/docker.asc && \
    echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian bookworm stable" > /etc/apt/sources.list.d/docker.list && \
    apt-get update && \
    apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin uidmap && \
    systemctl disable docker.service docker.socket containerd.service

并创建一个用户，假设名为 rootless，然后使用 machinectl shell rootless@ 切换到该用户，并运行 dockerd-rootless-setuptool.sh install 即可安装 Rootless Docker Daemon，安装程序会自动创建 ~/.config/systemd/user/docker.service 并将其安装到 default.target。设置环境变量 DOCKER_HOST=unix:///run/user/$UID/docker.sock 即可通过 Docker CLI 工具访问该 Rootless Docker Daemon。

Wrapping Up

将 Rootless Docker Daemon 安装脚本生成的 ~/.config/systemd/user/docker.service 文件复制出来，并创建 ~/.config/systemd/user/default.target.wants 中的相对路径符号链接，并在 Dockerfile 中添加创建用户和将这些文件到用户目录中的内容，最后通过在 /var/lib/systemd/linger 目录下创建名为用户名的空文件来使对应的 Systemd User Instance 自动启动，即可实现自动启动 Rootless Docker Daemon。

该方案最终版本代码位于 USTC-Hackergame/web-docker-manager 仓库的 rootless 目录，其中添加了一些用于持久化数据和暴露一些目录到主机的内容。

安全性分析

Rootless Docker 通过 RootlessKit 分离用户命名空间，来实现非特权用户的特权操作以创建容器，因此该方案的容器（命名空间）层次结构如下：

Host (Full Privilege)
└── systemd in Docker (UID 0, CAP_SYS_ADMIN, CAP_NET_ADMIN)
        └── RootlessKit (UID 0 in inner user namespace, with ALL capabilities; UID 1000 in outer user namespace, with no capabilities)
            └── Manager Container
            └── Web Challenge Container 1
            └── Web Challenge Container 2

若管理程序被攻破，则攻击者可以取得 RootlessKit 所创建的用户命名空间中的特权，但由于 RootlessKit 在外层用户命名空间是非特权用户，且运行在容器中，因此攻击者无法直接控制整个服务器，也无法直接访问 Host 的文件系统其他部分。

总结

通过基于 Systemd User Instance 的 Rootless Docker in Docker 方案，我们成功地实现了在隔离的、低权限的环境中运行 Docker Daemon，以实现 Web 类题目的容器隔离。该方案强制执行了容器的资源限制，并通过隔离 Docker Daemon 提高了安全性，使得即使 Web 题目的容器管理程序被攻破，攻击者也无法轻易控制整个服务器。该方案已经在 2024 年 USTC Hackergame 中应用于数道 Web 类题目并稳定运行。

尽管如此，该方案仍有改进空间，如当前外层容器仍需 SYS_ADMIN 特权，这实际上是相当大的权限，而 Sysbox 容器运行时可以在创建容器时直接分离用户命名空间，提供了一种不需要这些特权的替代方案，是一个可以探索的方向。此外，我们的方案为了方便直接禁用了 AppArmor Profile，但实际上只需要创建自定义的 AppArmor Profile 放松一些限制（如允许 mount 和放松一些路径下的限制），而不需要将其完全置于 unconfined 状态，这样可以进一步提升安全性，但仍需要进一步探索。

目的

某些课程作业附带的代码示例会通过 HTTP 的方式获取运行需要的输入数据，但是如果这个数据不巧放在某台访问速率很低的服务器上（例如不少用 .edu 域名的国外大学的课程网站上），则会使得作业的运行时间大大加长——通过只有几 KB/s 的网络下载数十 MB 的数据总不是个好主意。更有可能的是，根据作业内容，样例代码还需要做一些修改，这时候每次调试运行代码时都要去下载一次输入数据，简直难以忍受。本文将针对 Windows 用户，讲解如何在手工下载一次相关的文件后，在本地快速搭建一个 HTTP 服务器提供数据文件，以避免反复访问慢速的源地址。对于不能修改访问地址的情况，也提供了相应的对策。

为何不写针对 Linux 用户的教程呢？这是因为，由于有 Apache 和 Nginx 这类成熟好用的服务器软件，再加上 Linux 操作系统优秀的包管理器，结合网上的教程，用几分钟的时间在 Linux 平台上快速建立并运行一个 HTTP 服务器应该不是难事。而在 Windows 上，配置 IIS 这类大而笨重的服务器非常麻烦，使用 Apache/Nginx 之类的服务器软件又由于操作习惯的不同，也不方便。

使用 Python http.server

对比下面的（老旧的）EasyWebSvr，使用 Python 很容易完成一个简单的 HTTP 服务器搭建。

如果你已经安装了 Python，则可以直接使用

python3 -m http.server <port>

来以当前目录为根目录，<port> 为端口运行一个 HTTP 服务器。

如果需要指定别的目录 <path> 作为 HTTP 服务的根目录，可以使用

python3 -m http.server <port> --directory <path>

如果需要 bind 到特定的地址（对于本地服务而言，应该使用 127.0.0.1），可以使用下面的命令。bind 是指将一个网络地址（IP 和端口）与服务器软件中的套接字关联的过程，使得该服务器能接收指定地址上的网络数据。Python 的 http.server 默认值为 0.0.0.0，代表所有人都可以访问。如果只需要本地访问，则可以使用本地回环地址 127.0.0.1。

python3 -m http.server <port> --bind 127.0.0.1

使用 EasyWebServer

获取一个 HTTP 服务器

首先当然是要获取一个 HTTP 服务器了，这里我们选择的是 EasyWebSvr。这个服务器是一个体积超小（只有数十 KB）、单文件、几乎不需要配置的小型 HTTP 服务器，甚至支持 CGI 和 PHP。EasyWebSvr 是一个历史久远的开源项目，使用 MSVC 作为开发环境，而且很容易下载到它的编译好的版本（搜索 EasyWebSvr 就可以了）。下载后你将得到一个 EasyWebSvr.exe 和一些其他的文件。不用理会其他的文件（事实上它们是不必要的），直接将 EasyWebSvr.exe 复制到一个空文件夹里面就可以了。

提示：根据代码，EasyWebSvr 会 bind 到 0.0.0.0，这可能会导致安全问题。如果需要 bind 到 127.0.0.1，可能需要修改代码并重新构建。

准备数据

• 从原始的地址上手工下载一份要被访问的数据，放到上面所说的那个空文件夹里面。
• 运行 EasyWebSvr.exe，可以看到一个小窗口。
• 点击右下角的锤子按钮（菜单），选择最下面的 设置 一项。
• 在弹出的设置对话框里面，选择 主目录 为当前 EasyWebSvr.exe 所在的目录。
• 在 文档 选项卡里面勾选 允许目录浏览 和 总是显示目录内容。
• 点击 确定 结束并保存配置。
• 然后在主窗口里面点击右下方的红色按钮（在菜单按钮的边上），正常应该看到它变成蓝绿色（这时候如果有 Windows 防火墙提示，请选择允许）。
• 此时服务器就配置好了，打开浏览器输入 http://localhost 即可看到文件列表。

修改原先的代码

• 例如原先提供的代码中数据文件的 URL 是 http://some.site.edu/path/to/file/data.csv，而这份数据就和 EasyWebSvr.exe 在同一文件夹下，则将代码中的地址修改为 http://localhost/data.csv 就可以使用本地的文件服务了！
• 服务器最小化后会显示一个小托盘图标，右键点击它可以显示各种选项，包括重新显示主窗口。
• 使用完后，点击蓝绿色图标，它会变成红色，此时服务器就关闭了。

特殊情况

代码不支持修改地址

如果代码不支持修改地址（这很少见），那么也可以按照原来的 URL 在本地建立文件夹，类似下面这样：

EasyWebSvr.exe
path/                -> 建立这个目录
    to/              -> 建立这个目录
        file/        -> 建立这个目录
            data.csv -> 数据文件在这里

然后修改 hosts 文件（一般在 C:\Windows\System32\drivers\etc 里面，需要管理员权限，具体请看相关教程），加上一句

127.0.0.1 some.site.edu

然后以管理员权限运行

ipconfig /flushdns

即可。可以通过浏览器访问 http://some.site.edu/path/to/file/data.csv 来确认。这一操作会修改所有对 some.site.edu 的请求，因此用完后请删去在 hosts 中加入的那一行，然后再运行一次 ipconfig /flushdns。

原地址有非 80 的端口号

如果你拿到的地址使用了别的端口（例如 some.site.edu:8080）且不能修改，那么请在 EasyWebServer 的设置页面 端口号 处输入对应的端口号 8080，对应的访问地址就是 localhost:8080。

提示端口已被占用

这可能是因为有其他应用在使用 80 端口。通过 netstat -ano 命令可以查看机器上正被使用的端口号和对应的进程 ID。如果不希望关闭占用 80 端口的程序，那么和上面非 80 端口一样，将我们的 HTTP 文件服务器换到一个别的端口就好了，例如 8080 或者 8000，然后再次点红色圆球图标开启服务器。这时候记得访问地址也要加上对应的端口号。

2024 年 12 月 11 日 16:00 至 17:00，中国科学技术大学第十一届信息安全大赛颁奖仪式在西区 3B103 教室举行。网络空间安全学院李卫海副书记、USTC-NEBULA 战队指导老师吴文涛老师、本届比赛负责人、USTC-NEBULA 战队成员、本届比赛参赛选手出席了本次颁奖典礼。

李卫海副书记发表了精彩的颁奖致辞。他强调了信息安全在当今社会中的重要性，并对大赛的顺利举办表示由衷的祝贺。李副书记鼓励学子们在未来的道路上不断追求卓越，希望同学们能够结合实践，将在信息安全大赛中所学到的理论知识应用到实际工作中，为保护网络安全贡献自己的力量。

根据得分结果，中国科学技术大学第十一届信息安全大赛校内组评选出一等奖 1 名、二等奖 5 名、三等奖 25 名、新生奖 2 名、分类奖 5 名以及一血奖 17 名。李卫海副书记和吴文涛老师为获奖同学颁发了奖项。

叶升宇同学荣获一等奖。

叶知易、吕思源、樊一展、王凯健、杨涛同学荣获二等奖。

何煜恒、吴远韬、潘兆远、彭博、陈庆禾、向红静、杨岳、李远航、朱一鸣、熊桐睿、张天赫、刘睿博、黄嘉玮、李照阳、曹东皓、于泳昊、周恩帅、吴维卿、杨思汗、赵谱棋、陈锦锐、叶力天同学荣获三等奖。

李培锋、许傲施同学荣获新生特别奖。

叶知易、蒋皓、杨锦东、叶升宇、熊桐睿分别在综合技能（general）、人工智能（ai）、程序逆向与漏洞利用（binary）、密码学与数学（math）、网站安全（web）获得分类奖。

于泳昊、许傲施、吴书让、黄境、田佳嘉、熊桐睿、周瓯翔、陈庆禾、刘成龙、何煜恒、叶升宇、史可、樊一展、袁保杰、叶知易、杨锦东、蒋皓为各题目的首位答对者，荣获一血奖。

中国科学技术大学第十一届信息安全大赛由中国科学技术大学网络空间安全学院、中国科学技术大学团委、中国科学技术大学学生社团管理指导委员会主办，中国科学技术大学学生 Linux 用户协会、中国科学技术大学微软学生俱乐部、中国科学技术大学 NEBULA 战队和中国科学技术大学信息安全俱乐部承办。此外，复旦大学六星战队、广东海洋大学 Hor1zon 战队、哈尔滨工业大学 Linux 开源学生俱乐部、哈尔滨工业大学紫丁香 CTF 俱乐部、南京航空航天大学 Asuri 战队、吉林大学 Linux 用户协会、吉林大学 Spirit 战队、东北大学 NEX 信息安全创新团队、南方科技大学计算机研究协会、南方科技大学 COMPASS 实验室、中山大学 W4terDr0p 战队、中山大学互联网与开源技术协会、同济大学 CatTrainingForce 战队、西安电子科技大学信息安全协会、厦门理工学院信息安全协会、浙江大学 AAA 战队、上海大学开源社区、南阳理工学院计算机与信息化处理协会、上海交通大学 0ops 战队也参与了此次比赛的协办。

本届比赛于 11 月 2 日中午 12:00 正式开启，历时七天，参赛人数达到 2460 人。比赛共设置了约 35 道题目，涵盖了综合技能、程序逆向与漏洞利用、密码学与数学、Web 安全、人工智能等多个方向。命题延续了往届的优良特色，在具有一定教育意义的同时也不失趣味性，同时结合了科大特色、平衡了题目难度，适度增加了题目数量，争取让新生也能领会网络安全的魅力，在更多的方向上探索网络安全的知识、锻炼相关能力。

中国科学技术大学第十一届信息安全大赛的成功举办，不仅在学校内部激发了师生们对信息安全的浓厚兴趣，更为整个信息技术社区提供了一个展示实力、交流经验的重要平台，无疑将对同学们未来在信息安全领域的发展产生深远而积极的影响。

官方题解和参赛选手的解答公布于 hackergame2024-writeups ，欢迎大家学习交流。

本文另有英文版及在南京大学分享时使用的幻灯片。

背景

由中科大 Linux 用户协会维护的中科大开源软件镜像站是中国大陆高校访问量最大、收录最全的开源软件镜像之一。 在 2024 年 5 月至 6 月期间，我们的镜像站服务的流量大约是每天 36 TiB，主要分为以下两大类：

• HTTP/HTTPS 流量 19 TiB，请求量 1700 万
• Rsync 流量 10.3 TiB，请求量 2.18 万（如果算上一个异常的客户端，那么总数是 14.78 万）

多年以来，随着现有镜像仓库容量的增加和新镜像仓库的加入，我们的服务器硬盘容量已经十分紧张了。目前¹提供镜像服务的两台服务器的磁盘容量都已经接近极限了：

• 主（HTTP）服务器采用 XFS 文件系统，在 2023 年 12 月 18 日达到了 63.3 TiB（总容量 66.0 TiB，使用率 96%）；
• 副（Rsync）服务器采用 ZFS 文件系统，在 2023 年 11 月 21 日达到了 42.4 TiB（总容量 43.2 TiB，使用率 98%）。

两台服务器的配置分别如下：

HTTP 服务器

• 2020 年秋季搭建
• 第二代至强可扩展处理器（Cascade Lake）和 256 GB DDR4 内存
• 12 块 10 TB HDD + 一块 2 TB SSD
• 在硬件 RAID 上使用 LVM 和 XFS
• 由于 XFS（截至本次重建时）不支持压缩，因此为了应对其他分区的潜在的扩容需求，我们在 LVM VG 层面保留了 free PE

Rsync 服务器

• 2016 年底搭建
• 至强 E5 v4 处理器（Broadwell）和 256 GB DDR4 内存
• 12 块 6 TB HDD 和一些小容量 SSD 用来装系统和当缓存
• 组建了 ZFS RAID-Z3 阵列，分为 8 块数据盘 + 3 块校验盘，最后一块留作热备
• 全默认参数（仅修改了 zfs_arc_max）

这两台服务器的磁盘负载非常高，日常维持在 90% 以上，以至于即使从科大校园网内下载镜像，速度也很难达到 50 MB/s。 显然对于镜像站这种专用于存储用途的机器来说，这样的性能表现是不尽人意的。

ZFS

ZFS 以“单机存储的终极解决方案”著称。 它集 RAID、逻辑卷管理和文件系统于一体，具有包括快照、克隆、发送/接收等高级功能。 ZFS 内的所有数据都有校验，可以在硬盘出现比特翻转等极端情况下尽可能确保文件系统的完整性。 对于专用于存储的服务器来说，ZFS 看起来是个可以“开箱即用”的解决方案，但当你看到它有如此多的可调节参数之后，你马上就不会这么想了。

作为前期学习和实验，我在自己的工作站上增加了一批额外的硬盘并把它们组成了两个 ZFS pool，然后注册了一些 PT 站开始刷流来制造一些磁盘负载以便学习研究。 在 PT 站的刷流成果十分可观：这个单机的 seed box 在两年半间产生了 1.20 PiB 的上传量。

这两年刷 PT 站刷下来，我总结出来几个重要的 ZFS 学习资料来源：

• UToronto 的 Chris Siebenmann 的博客：https://utcc.utoronto.ca/~cks/space/blog/
• OpenZFS 的官方文档：https://openzfs.github.io/openzfs-docs/
• 我自己攒出的一篇博客：Understanding ZFS block sizes
  • 以及这篇博客底部列出的参考文献

经过多年的 ZFS 学习，我意识到镜像站服务器上的配置其实有很大的优化空间，方法就是 all-in ZFS 并正确地调节一些参数。

镜像站

在开工重建 ZFS pool 之前，我们需要正确地理解和分析镜像站的负载类型。简而言之，镜像站的特点是：

• 提供文件下载服务
• 也（被迫）提供“家庭宽带上下行流量平衡服务”

  （责任全在 PCDN 方）

• 读多写少，且大部分读取都是全文件顺序读取
• 能够容忍少量的数据丢失，毕竟镜像内容可以轻易地从上游重新同步回来

基于以上思考，我们分析了镜像站上存储的内容。从上图中可以看出，镜像站上总文件数超过 4000 万，其中一半的文件大小不到 10 KiB，并且 90% 的文件大小不到 1 MiB。 尽管如此，所有文件的平均大小仍然达到了 1.6 MiB。

重建 Rsync 服务器

Rsync 服务器的流量较少，但磁盘使用率较为极端，加上我们认定 Rsync 服务的重要性较低，因此在今年 6 月，我们先动手重建了这台服务器。 我们制定了如下的重建计划：

• 首先，考虑到镜像站上一半的文件都不到 10 KiB（注意我们的磁盘的物理扇区大小是 4 KiB），RAID-Z3 的开销过高，因此我们决定将其重建为 RAID-Z2 并且拆成两组 vdev。这样做还有一个额外的好处，即期望情况下我们还可以在这个 ZFS pool 中获得两倍的 IOPS，毕竟文件的每个“块”只存储在一个 vdev 上。

• 然后我们仔细研究了如何为镜像站场景调优 ZFS dataset 参数：

  • recordsize=1M：尽可能优化顺序读写性能，同时减少碎片化

  • compression=zstd：开点压缩来试试能节约多少磁盘空间

    • OpenZFS 2.2 开始将 early-abort 机制引入了 Zstd 压缩算法（Zstd-3 以上的等级）。该机制会首先尝试使用 LZ4 和 Zstd-1 来压缩数据以便评估数据的可压缩性，如果数据不可压缩（熵太大），则不再尝试用设定的 Zstd 等级压缩，而是直接原样写入磁盘上，避免在不可压缩的数据上浪费 CPU。

      我们已知镜像站上的大部分内容都是已经压缩过的，因此 early-abort 算是给我们兜了个底，让我们可以放心地开 Zstd。

  • xattr=off：镜像站上的文件不需要扩展属性
  • atime=off：镜像站上的文件不需要记录，也不需要更新 atime，可以省掉不少写入
  • setuid=off、exec=off、devices=off 也是我们不需要的挂载选项（也是一个更安全的做法）
  • secondarycache=metadata 让 L2ARC 仅缓存 ZFS 内部的元数据。这是因为 Rsync 服务器上的文件访问模式更加均匀，而不像面向终端用户的 HTTP 服务器上冷热分明，因此仅缓存元数据可以节约 SSD 寿命。

• 以及一些可能有潜在（但我们认为我们可以容忍的）风险的选项：

  • sync=disabled：禁用同步写入语义（open(O_SYNC)、sync() 和 fsync() 等）以让 ZFS 能够充分发挥写缓冲区的意义，如降低碎片率等
  • redundant_metadata=some：（OpenZFS 2.2）减少元数据的冗余度来获得更好的写入性能。

  我们认为这两个选项符合我们对镜像站仓库内容的数据安全和完整性需求的理解，它们在其他场景下不一定“安全”。

• 对于 ZFS 模块层面的参数，光是 290+ 的数量就已经很劝退了。 此处感谢 Debian ZFS 维护者兼北京外国语大学镜像站管理员 @happyaron 的帮助，我们快速找出了十几个常用的参数进行针对性调节。

  # 设置 ARC 大小范围为 160-200 GiB，并为操作系统保留 16 GiB 空闲
  options zfs zfs_arc_max=214748364800
  options zfs zfs_arc_min=171798691840
  options zfs zfs_arc_sys_free=17179869184
  
  # 设置元数据对用户数据优先级的权重为 20x (OpenZFS 2.2+)
  options zfs zfs_arc_meta_balance=2000
  
  # 允许 dnode 占用至多 80% 的 ARC 容量
  options zfs zfs_arc_dnode_limit_percent=80
  
  # 以下几行参见 man page 中的 "ZFS I/O Scheduler" 一节
  options zfs zfs_vdev_async_read_max_active=8
  options zfs zfs_vdev_async_read_min_active=2
  options zfs zfs_vdev_scrub_max_active=5
  options zfs zfs_vdev_max_active=20000
  
  # 避免因内存压力降低 ARC 读写速度
  options zfs zfs_arc_lotsfree_percent=0
  
  # L2ARC 参数
  options zfs l2arc_headroom=8
  options zfs l2arc_write_max=67108864
  options zfs l2arc_noprefetch=0
  

  另外还有 zfs_dmu_offset_next_sync，但由于它从 OpenZFS 2.1.5 开始已经默认启用了，因此我们将其从本列表中略去。

将 Rsync 服务暂时转移到由 HTTP 服务器兼任之后，我们 destroy 了原有的 ZFS pool 并重新组建了一个新的 pool，然后再从外面（上游或 TUNA、BFSU 等友校镜像站）把原有的仓库同步回来。 令我们感到惊讶的是，把总共近 40 TiB 的仓库同步回来只花了 3 天，比我们预想的要快得多。 其他的一些数据看起来也令人振奋：

• ZFS 压缩率：39.5T / 37.1T (1.07x)

  需要特别指出的是，ZFS 只显示压缩率小数点后两位，所以更高的精度，需要通过原始数据自己计算：

  zfs list -po name,logicalused,used
  

  我们更精确的压缩率是 1 + 6.57%，即压掉了 2.67 TB（2.43 TiB），约等于 9 份微信数据（不是

• 最关键的是更合理的 I/O 负载：

  

可以看出，经过几天的预热之后，I/O 负载维持在了 20% 左右，而在重建之前一直维持在 90% 以上。

重建 HTTP 服务器

我们的 HTTP 服务器是在 2020 年秋季搭建的，并且当时也有一些不同的背景。 申请这台服务器正是因为 Rsync 服务器容量过满且性能不佳，加上当时社团内也没有熟悉 ZFS 的同学，我们对 ZFS 的印象很差，所以我们决定完全避开 ZFS，使用硬件 RAID、LVM 和 XFS，其中使用 LVM 的原因是 RAID 卡不支持跨两个控制器组 RAID。 对于“内存做缓存”这部分，我们决定直接使用内核的 page cache；而对于 SSD 缓存，我们则率先吃了 LVMcache 的螃蟹。

然而这些过于“新鲜”的技术并没有带来比（现在的 ZFS）更好的体验：

• XFS 无法缩小，因此我们不得不在 LVM VG 层面保留了 free PE。同时我们也不能把 XFS 文件系统用满，因此这里就有了两层无法利用的空闲空间。
• 我们最初分配了 1.5 TB 的 SSD 缓存，但 LVMcache 又建议我们不要超过 100 万个 chunk，我们当时也没有足够的精力和知识水平去研究这个建议背后的技术细节，因此我们最终只分配了 1 TiB（1 MiB chunk size * 1 Mi chunks）的 SSD 缓存。
• SSD 缓存策略不可调，多年以后我们翻了 kernel 源码才发现它是一个 64 级的 LRU。
• 配好 cache 之后 GRUB 立刻挂了（难绷），我们调查发现原因是 GRUB 有一套自己的解析 LVM metadata 的代码，它并没有正确处理（或者说根本没处理）VG 中有 cache volume 的情况，我们不得不自己 patch 了 GRUB 才能正常开机。
• 由于我们对 LVMcache 的 chunk 不够了解，我们的 SSD 在不到 2 年的时间里就严重超过了写入寿命，我们被迫申请换新。

在 SSD 换新之后，即使我们认为我们对 LVMcache 做出了稍微合理一点的调参，坚持忽略警告采用 128 KiB 的 chunk size 和 800 万个 chunk 之后，它的性能（命中率）也并不可观：

这些年来我们已经踩够了 LVMcache 的坑了，加上 Rsync 服务器重建的巨大成功，我们重新开始相信 ZFS 是天下第一的存储方案了。 所以一个月之后，我们又制定了一个相似的重建计划准备重建 HTTP 服务器，但是有一些微小的差别：

• 我们的 Rsync 服务器采用原生的 Debian kernel + zfs-dkms，但根据我们使用 PVE 的经验，我们准备在 HTTP 服务器上直接用 6.8.8-3-pve kernel，它打包了 zfs.ko，这样我们就不用在 DKMS 上浪费时间了。
• 由于磁盘数目相同（12 块），我们也采用了两个 6 盘 RAID-Z2 vdev 的组合。
  • 考虑到这台服务器直接向用户提供 HTTP 服务，磁盘的访问模式会比 Rsync 服务器更加冷热分明，因此我们保持了 secondarycache=all 的设置（采用默认值，不动）。
  • 这台新服务器的 CPU 更新更好，因此我们把压缩等级提高到了 zstd-8 来试试能否获得更好的压缩比。
• 我们在 Rsync 服务器上已经有了一个完整的、经过 ZFS 优化过的仓库，因此我们可以直接用 zfs send -Lcp 把数据倒过来。我们最终只花了 36 小时就把超过 50 TiB 的数据都倒回来了。
• 由于两台服务器上存储的镜像仓库有所不同，HTTP 服务器上的压缩比略低一些，为 1 + 3.93%（压掉了 2.42 TiB / 2.20 TiB）。

我们把两台服务器的 I/O 负载放在一张图里对比：

上图左半部分为重建前的情况，中间部分为仅重建了 Rsync 服务器的情况，右半部分为两台服务器都重建完毕后的情况。

ZFS ARC 的命中率也十分可观：

稳定下来之后，两台服务器的 I/O 负载还更低了：

杂项

ZFS 透明压缩

我们并没有想到这么多仓库的压缩率都还不错：

有些数字看着不太对劲（比如第一个），我们认为是这个问题造成的： openzfs/zfs#7639

如果我们按照压缩量排序，结果如下：

debian-cdimage 一个仓库就占了总压缩量的 1/4。

Grafana for ZFS I/O

重建后，我们也修了一个显示 ZFS I/O 的 Grafana 面板。 因为 ZFS 的 I/O 统计数据是通过 /proc/spl/kstat/zfs/$POOL/objset-$OBJSETID_HEX 获取的，并且是分“object set”（即 dataset）累计统计的，所以我们需要先对每个 dataset 的数据做差分，再按 pool 加起来。 也就是说，一个 InfluxQL subquery 是跑不掉的。

SELECT
  non_negative_derivative(sum("reads"), 1s) AS "read",
  non_negative_derivative(sum("writes"), 1s) AS "write"
FROM (
  SELECT
    first("reads") AS "reads",
    first("writes") AS "writes"
  FROM "zfs_pool"
  WHERE ("host" = 'taokystrong' AND "pool" = 'pool0') AND $timeFilter
  GROUP BY time($interval), "host"::tag, "pool"::tag, "dataset"::tag fill(null)
)
WHERE $timeFilter
GROUP BY time($interval), "pool"::tag fill(linear)

由于 subquery 的存在，这个 query 确实有点慢，但我们也没啥能优化的。

如果要显示读写速率的话，直接把内层查询的 reads 和 writes 换成 nread 和 nwritten 就行了。

令 UC 震惊部出动的是，一个机械盘阵列竟然能跑出平均 15k、最高 50k 的 IOPS。 我们发现这个统计数字算上了 ARC hit，也就是只有一小部分 I/O 请求是真正落盘的，那就好解释了。

AppArmor

换上先进的 PVE kernel 之后，我们很快就发现同步任务全挂了（） 排查发现 rsync 在调用 socketpair(2) 的时候冒出了 EPERM，这是我们从来没遇到过的情况。 实际上这些系统调用都被 AppArmor 拦下来了，最终查到是 Ubuntu 在 kernel 里加的私货 security/apparmor/af_unix.c 导致的。 由于 Proxmox VE 的 kernel 是从 Ubuntu fork 过来的，这个私货也就被夹带到我们服务器上了。

我们发现 PVE 也打包了自己的 AppArmor features 配置，就把它直接拉过来用：

dpkg-divert --package lxc-pve --rename --divert /usr/share/apparmor-features/features.stock --add /usr/share/apparmor-features/features
wget -O /usr/share/apparmor-features/features https://github.com/proxmox/lxc/raw/master/debian/features

文件级去重

我们注意到个别仓库有大量的重复的、内容相同的目录，怀疑可能是同步方法（HTTP）的限制导致目录的符号链接变成了完整内容的拷贝。

我们想到了 ZFS 的 deduplication，于是在 ZeroTier 仓库上做了一个初步的测试：

zfs create -o dedup=on pool0/repo/zerotier
# 导入数据

# zdb -DDD pool0
dedup = 4.93, compress = 1.23, copies = 1.00, dedup * compress / copies = 6.04

结果十分可观，但考虑到 ZFS dedup 一向来糟糕的名声，我们还是不太想在镜像站上启用。 所以我们重新找了个更灵车的方案：

# post-sync.sh
# Do file-level deduplication for select repos
case "$NAME" in
  docker-ce|influxdata|nginx|openresty|proxmox|salt|tailscale|zerotier)
    jdupes -L -Q -r -q "$DIR" ;;
esac

这个用户态的文件去重工具十分好用，效果堪比 ZFS，而且没有性能损失。 我们对几个明显有重复内容的仓库跑了一下 jdupes，结果如下：

参考上述表格，我们排除了 mysql-repo，因为它的去重比例太低，不值得花费跑一遍去重产生的 I/O 负载。

总结

ZFS 解决了我们镜像站上的一大堆问题，并且有了此次调参经验，我们现在宣布 ZFS 天下第一（不是）

有了 ZFS 之后：

• 我们不再担心分区问题，ZFS 可以灵活分配。
• 我们的机械盘比别人的固态盘跑得还快，这非常 excited！
  • 我们成为了第一个不再羡慕 TUNA 的全闪服务器的镜像站！
• 零成本获得额外容量，由 ZFS 透明压缩和去重联合赞助！

思考

虽然我们的 ZFS 配置看起来非常高效，但我们也知道 ZFS 在长期运行中可能会因为碎片化而导致性能下降的问题。 我们会持续关注我们的服务器，监控长期的性能变化。

_Kerman 同学首先向大家介绍了 Slidev 的基本使用方法，包括如何安装、创建项目、添加内容等。他随后演示了如何通过 Markdown 语法添加文本、图片、代码块、表格等内容及一些高级功能，例如添加动画、如何添加交互式的内容等。最后，他还向大家展示了如何将制作好的幻灯片导出为 PDF 文件。在现场，许多同学尝试了 Slidev，创建了自己的第一个 Slidev 幻灯片项目。

小聚的最后，_Kerman 同学分享了他自己参与相关开源社区的感受，并推荐大家多参与开源社区。本次小聚的幻灯片可以在 LUG FTP 查看。