米米的博客

笔者有一台小爱音箱，可惜它并不支持 AirPlay 协议。如果要将 Mac 上的音乐串流到这台音箱上播放，就需要通过蓝牙配对，体验并不理想。幸运的是，这个型号的音箱配备了 USB 接口，并且可以通过 USB 声卡的方式被电脑识别为音频输出设备。这就意味着，可以通过 Shairport Sync 等软件进行 AirPlay 协议配对，然后通过 USB 将音频流发送到这台音箱上播放。
这台音箱摆放位置旁边就是 NAS 服务器，运行着 TrueNAS Scale 25.04 系统。直接在 NAS 服务器上安装 Shairport Sync 并连接音箱是一个不错的选择。这个版本的 TrueNAS 支持运行 Docker 容器，因此软件安装上非常方便，不过在调试过程中还是踩了很多坑。本文记录一下安装过程，供参考。

检查 Alsa 配置

首先，通过 SSH 登陆到 TrueNAS 服务器上，执行cat /proc/asound/cards检查声卡是否正确识别：

1
2
3
4
5

admin@truenas[~]$ cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x6005220000 irq 199
 1 [Pro7990        ]: USB-Audio - 智能音箱 Pro-7990
                      Xiaomi Corporation 智能音箱 Pro-7990 at usb-0000:00:14.0-5, high speed

可以看到，智能音箱声卡已经被正确识别为Pro7990。接下来，我们需要检查 Alsa 的配置（特别是 Mixer）。虽然 TrueNAS 系统基于 Debian，但它本身并不包含 Alsa 工具，因此我们需要先创建一个 Ubuntu 容器，并将声卡设备映射进去。可以通过 TrueNAS 的 Web 界面创建一个 Docker 容器，选择「通过 YAML 进行安装」，并添加如下配置：

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

services:
  alsa-check:
    command:
      - bash
      - '-c'
      - sleep infinity
    container_name: alsa_mixer_check
    devices:
      - /dev/snd:/dev/snd
    environment:
      - DEBIAN_FRONTEND=noninteractive
    image: ubuntu:24.04
    privileged: True
    stdin_open: True
    tty: True

Ubuntu 的 Docker 容器启动成功后，进入容器内部的命令行，安装 Alsa 工具：

1
2

apt update
apt install -y alsa-utils

在 Ubuntu 系统上，有时我们需要对某些内核模块进行定制化修改，例如更新补丁、进行调试或加入额外日志等。完整重新编译内核会非常耗时，但好消息是：Linux 的内核构建系统允许我们仅重新编译目标模块，而不需要构建整个内核。

本文介绍如何在 Ubuntu 上为当前正在运行的内核版本重新编译一个模块，并正确安装和加载它。示例模块为 kvm-intel.ko。

准备内核源码

Ubuntu 提供了与当前内核版本在同一 ABI 下的源码，可以通过 apt-get 直接获取：

1

apt-get source linux-image-unsigned-$(uname -r)

执行后目录中通常会出现类似：

1

linux-hwe-6.8-6.8.0/

这就是 Ubuntu 为 HWE 6.8 系列内核提供的完整源码树。

同步配置与符号信息

Kernel module 的编译依赖两个关键文件：

1. .config — 当前内核的编译配置
2. Module.symvers — 内核导出的符号版本信息

这两者必须与正在运行的内核一致，否则编译出的模块会因为 ABI 不一致而无法加载。

我们将系统中的配置和符号文件复制到源码树中：

1
2

cp /boot/config-$(uname -r) .config
cp /usr/src/linux-headers-$(uname -r)/Module.symvers .

准备构建环境

执行：

1
2

make oldconfig && make prepare
make modules_prepare

当它们准备完成后，就可以只编译目标模块了。

只编译目标模块

Linux 内核允许使用 M=<path> 的方式仅构建某个目录下的模块，这大大缩短编译时间。

以 KVM 模块为例：

1

make -j$(nproc) M=arch/x86/kvm modules

只会编译：

• arch/x86/kvm/kvm.ko
• arch/x86/kvm/kvm-intel.ko（Intel 虚拟化支持）
• arch/x86/kvm/kvm-amd.ko（如果是 AMD）

以 kvm-intel.ko 为例，编译完成后可以查看模块信息：

1

modinfo arch/x86/kvm/kvm-intel.ko

可以确认版本号、依赖项、符号是否正确。

替换内核模块

为了让系统使用我们自己编译的版本，需要将它复制到系统模块目录中：

1
2

sudo cp arch/x86/kvm/kvm-intel.ko \
    /lib/modules/$(uname -r)/kernel/arch/x86/kvm/

然后更新模块依赖：

1

sudo depmod -a

这样系统就能识别新的模块文件。

加载模块

卸载旧模块后再加载新的模块。若旧模块已加载，可先移除：

1

sudo modprobe -r kvm_intel

然后加载我们编译过的模块，并附带参数：

1

sudo modprobe kvm_intel pt_mode=1

若加载成功，说明自定义模块已生效。

在家庭服务器环境或小型机房中，通过网络（PXE）启动服务器可以显著简化设备的安装流程。本文将介绍如何在 OpenWRT 路由器 + 一台内网 Linux 服务器的组合下，搭建可用于 UEFI 启动的 PXE 环境，并支持 iPXE、HTTP 启动等现代特性。

本文实验成功的环境：

• 路由器：OpenWRT（系统版本 24.10）
• TFTP / HTTP 服务器：一台内网 Linux 服务器（安装 Ubuntu 系统）
• 客户端：支持 UEFI PXE 的服务器主板

PXE 启动原理

PXE（Preboot eXecution Environment）启动主要由以下步骤组成：

1. 客户端通过网络发送 DHCP Discover
2. DHCP 服务器返回 IP 地址，并附加 PXE 相关字段：
   • next-server（TFTP server 的 IP）
   • filename（要下载的启动文件，如 snponly.efi）
3. 客户端向 TFTP 服务器请求文件
4. 使用下载到的引导器加载后续启动流程，例如：
   • iPXE（支持 HTTP、iSCSI 等）
   • Linux kernel + initrd

OpenWRT 的 dnsmasq 内置了 PXE 支持，并且可以方便地通过 LuCI 界面配置。

配置 TFTP 服务

首先，在内网 Linux 服务器上安装 TFTP 服务，用于提供必要的文件。以 tftpd-hpa 为例：

1

sudo apt install tftpd-hpa

编辑 /etc/default/tftpd-hpa：

1
2
3
4

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"

重启服务：

1

sudo systemctl restart tftpd-hpa

配置 HTTP 服务

以 Nginx 为例：

1

sudo apt install nginx

重启服务：

1

sudo systemctl restart nginx

XG - 140G - TF (ONU) 是诺基亚贝尔生产的一款光猫，为电信定制版本。这款光猫支持 2.5G 网口，配置非常不错，而且闲鱼上价格已经降到 40 元左右，性价比很高。相比于 XG - 040G 等类似型号，XG - 140G - TF (ONU) 的厚度更薄，适合弱电箱环境；带有语音功能，支持安装座机。本文记录一下这款光猫的配置过程，XG - 040G 等型号的光猫也可以参考。

获取旧光猫配置

由于这款光猫非常新，一些省份没有入库，所以运营商无法远程下发配置，只能进行手工配置。为了能够正常上网，我们需要在旧光猫上获配置参数，包括旧光猫的逻辑 ID（LOID）、上网和 iTV 的 VLAN ID、PPPoE 账号和密码等。如果有旧光猫的管理员（telecomadmin）密码，可以直接登陆后台查看这些参数。如果没有管理员密码，可以联系电信的师傅帮忙查看。

配置新光猫

将新光猫接上电源和光纤，用曲别针按住复位按钮几秒钟，等待光猫恢复出厂设置完成。然后，使用网线连接电脑和光猫的 LAN 口，通过浏览器访问192.168.1.1，使用默认管理员用户名telecomadmin和密码nE7jA%5m登录后台。
随后，访问http://192.168.1.1:8080/opid_setting.cgi，选择所在的省份。此后光猫会再次重启并恢复出厂设置。
之后，就可以开启 telnet 了，访问http://192.168.1.1:8080/system.cgi?telnet点击启用按钮即可。
这款光猫的 telnet 可以用光猫背后印的useradmin用户及对应的密码登陆，但是登陆后只有普通用户权限。我们需要获取 su 密码。注意，这个密码和 Web 后台的telecomadmin密码是不一样的。它也不会被运营商远程修改。

获取 su 密码

接下来，再次使用telecomadmin账户和默认密码登录后台。打开一个新页面，访问http://192.168.1.1:8080/dumpdatamodel.cgi，得到 XML 格式的光猫配置。在其中搜索SuPassword，可以看到一个 Base64 编码的字符串，这就是 su 密码的 AES 加密形式。我们需要将它解码成明文。笔者做了一个网页小工具，可以帮助解码，地址是：XG - 140G - TF (ONU) su 密码计算。将 Base64 字符串粘贴进去，点击解码按钮，就可以得到明文密码。这个密码之后会用到。

Web 界面配置

随后，进入光猫的配置界面，点击「网络」 → 「宽带设置」，然后将旧光猫的配置照搬进来即可。之后，找到「网络」 → 「远程管理」界面，选择左侧「宽带识别码认证」菜单，输入逻辑 ID（LOID）进行注册，此处密码似乎不影响，可以和逻辑 ID 输入一样的。

OLT 注册成功后，先前手工进行的网络配置就可以生效了。如果设置了桥接模式，可以通过电脑或者主路由进行拨号。然而，上网功能还是受到限制。因为光猫没在运营商那里入库，会遇到 ITMS 注册失败，此时光猫会将网络请求劫持到注册页面上。这个问题需要进一步解决。

解决 ITMS 注册失败

为了避免上网出现问题，我们需要让光猫觉得自己已经注册成功。这就需要用到之前的 telnet 账户了。在命令行执行

1

telnet 192.168.1.1

依次输入光猫背后印的useradmin用户及对应的密码登陆。然后，执行

1

su

输入先前解码出来的 su 密码，提升到管理员权限。然后，执行

1
2

cfgcli -s InternetGatewayDevice.X_CT-COM_UserInfo.Status 0
cfgcli -s InternetGatewayDevice.X_CT-COM_UserInfo.Result 1

此时，光猫就可以正常工作了。

参考文章：破解 2024 年新款诺基亚贝尔万兆光猫 AES 加密的 su 密码

在日常开发中，经常会遇到 Docker 拉取镜像缓慢、连接不稳定、某些仓库国内访问困难等问题。为了解决这些实际痛点，我实现重复造轮子了一个轻量级 Docker Registry 反向代理，用于中转和加速 Docker 客户端的镜像拉取请求。项目采用 Python + FastAPI 编写，实现了对多个主流仓库的透明代理。

本文将介绍实现背景、设计思路、功能特点以及代码结构，最后提供开源地址，供需要的用户部署使用。

背景

Docker 官方 Registry 对网络质量要求较高，镜像层往往较大。很多场景下，直接从 DockerHub 或 GHCR 拉取镜像会遇到超时、速率不稳定、DNS 污染、IP 限速等问题。

市面上已经有一些现成的镜像代理服务，例如 Docker 官方提供的实现了 OCI Distribution spec 的 registry，但是这样的服务配置复杂，资源要求高，难以在云服务器等环境上部署。在一些轻量级环境中，更希望使用一个灵活性更高、资源占用低的代理。

于是就有了一个目标：

写一个尽量小、足够稳定、可自部署的 Docker Registry 代理，同时保持兼容性。

设计目标

实现这个代理时，我对系统设计目标做了一些规划：

1. 兼容 Docker Registry API v2
   必须完整支持：

   • GET /v2/
   • GET /v2/auth
   • 获取 manifest / tag / blob 等路径
   • DockerHub 的 library 自动补全规则

   秘诀在于遵循 Docker 客户端的认证流程，模拟 DockerHub 的 WWW-Authenticate 行为。

2. 流式转发以降低内存消耗
   原始实现如果直接使用 resp.content，会导致 Python 在内存中加载整个 blob，动辄几百兆。这在生产环境是不可接受的。
   最终代理采用 StreamingResponse，将上游的内容以流式方式直接转发，避免占用大量内存。

3. 支持并发请求
   使用全局 httpx.AsyncClient，依赖其内部连接池来处理多并发，加上 FastAPI 的异步模型，在单 worker 的情况下也能处理多条镜像拉取流水线。

4. 支持多个仓库
   例如：

   • DockerHub
   • GHCR
   • Quay
   • Google Container Registry
   • Kubernetes Registry

   这些仓库的 API 大致一致，只需要按不同域名路由到不同的上游即可。

整体流程

代理的请求处理流程如下：

• 客户端访问 docker.example.com/v2/...
• 代理根据主机名判断应转发至哪个镜像源
• /v2/ 与 /v2/auth 按 Docker 协议处理认证
• repository 路径按需要补全 library/
• 其它请求以 streaming 方式转发
• 对 DockerHub 的 blob 307 跳转进行手动跟随
• 将上游响应回传给 Docker 客户端

整个过程对客户端透明，使其可以像访问官方仓库一样访问自定义域名。

代码结构

项目核心的 streaming 实现基于下面的模式：

1
2
3
4
5
6
7
8
9

req = client.build_request("GET", upstream_url)
upstream_resp = await client.send(req, stream=True)

return StreamingResponse(
    upstream_resp.aiter_bytes(),
    status_code=upstream_resp.status_code,
    headers=response_headers,
    background=BackgroundTask(upstream_resp.aclose),
)

开源地址

项目已在 GitHub 开源：

https://github.com/web-llm/fast-docker-proxy

如果你需要一个可控、轻量、可扩展的 Docker Registry 代理，可以直接基于该项目部署，也欢迎提交 issue 或 PR。具体使用方法请参考仓库的 README 文档。