atpX

自建 S3 兼容对象存储服务 Garage

2026-03-01T09:35:01Z

以前使用 AWS S3 / Cloudflare R2 这些公有云产品时总放不开手脚，公开资源得套一层缓存来降低请求量，生怕账单被刷爆。对比几个开源 S3 兼容项目后，选择 Garage 的原因很简单，轻量够用，分布式设计以及针对高延迟场景优化，让节点走出大厂数据中心，可以到处「捡破烂」。

虽然也不是非得用 S3，重要数据每天都有自动任务备份，也没重要到没了就天塌了，主要图个紧跟时代浪潮，搭建自己的数据基石。

搭建 Garage

这里简单的记录下 Garage 安装及配置过程。

编辑配置

创建 garage.toml 配置文件，具体完整配置参考官方文档：

metadata_dir = "/var/lib/garage/meta" # 元数据存放目录
data_dir = "/var/lib/garage/data" # 对象数据存放目录
db_engine = "sqlite" # 可选 lmdb / sqlite / fjall
# metadata_auto_snapshot_interval = "6h" # 自动对元数据进行快照

replication_factor = 3 # 副本数量，单节点设置为 1
compression_level = 1 # zstd 压缩级别，默认 1，越低 CPU 开销越低
block_size = "1M" # 默认 1MB，如果存储大文件且网络较好可适当增加

rpc_bind_addr = "[::]:3901" # 集群 RPC 通信端口
rpc_public_addr = "127.0.0.1:3901" # 集群填公网 IP:3901
rpc_secret = "<RPC secret>" # RPC 通信密钥，`openssl rand -hex 32` 生成

[s3_api]
s3_region = "garage" # 自定义区域名
api_bind_addr = "[::]:3900"
root_domain = ".s3.example.com" # S3 API 访问根域名，<bucket>.s3.example.com

[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.example.com" # web 访问根域名，<bucket>.web.example.com
index = "index.html"

[admin]
api_bind_addr = "[::]:3903"
admin_token = "<admin token>" # 管理接口 Token，`openssl rand -base64 32` 生成
metrics_token = "<metrics token>" # 指标接口 Token，`openssl rand -base64 32` 生成

如果有前置 web server，可以把除 RPC 外的端口绑定在本地 localhost，通过反代访问提高安全性。两处 root_domain 的设置对应 bucket 的两种访问风格：

路径 (Path)：root_domain 设置为 s3.example.com，访问地址：https://s3.amazonaws.com/<bucket>/<key>
虚拟主机 (Virtual Hosted) ：root_domain 设置为 .s3.example.com，访问地址：https://<bucket>.s3.amazonaws.com/<key>

虽然公有云都在力推虚拟主机风格，例如 AWS 计划停止支持路径风格，但都是基于海量用户下的更高性能和安全需求。两种风格我都进行了测试，最后个人项目还是使用路径风格更方便，不需要额外申请一张 *.s3.example.com 证书，而且能避免一些潜在的问题，比如 bucket 名称中带 . 时会导致证书不匹配。

启动服务

Garage 使用 Rust 开发，可以选择直接下载运行编译好的二进制文件，并通过 systemd 管理：

vim /etc/systemd/system/garage.service

[Unit]
Description=Garage Data Store
Documentation=https://garagehq.deuxfleurs.fr
After=network-online.target
Wants=network-online.target
StartLimitBurst=5
StartLimitIntervalSec=60

[Service]
User=garage
Group=garage
Environment='RUST_LOG=garage=info'
ExecStart=/path/to/garage -c /path/to/garage.toml server
Restart=on-failure
RestartSec=10
NoNewPrivileges=true
LimitNOFILE=42000

[Install]
WantedBy=multi-user.target

也可以简单的通过 Docker Compose 启动服务：

services:
  garage:
    image: dxflrs/garage:v2.2.0
    container_name: garage
    network_mode: host
    environment:
      - TZ=Asia/Shanghai
      - RUST_LOG=garage=info
    restart: unless-stopped
    volumes:
      - ./garage.toml:/etc/garage.toml
      - ./meta:/var/lib/garage/meta
      - ./data:/var/lib/garage/data
    # ports:
    #   - 3900:3900
    #   - 3901:3901
    #   - 3902:3902
    #   - 3903:3903

设置一个别名来更方便的执行 Garage 命令，在 ~/.bashrc 中添加下面内容后 source ~/.bashrc：

alias garage="docker exec -it <container name> /garage"
# e.g. alias garage="docker exec -it garage /garage"

查看 Garage 当前状态：

garage status

如果使用了 UFW 防火墙和 Docker 容器端口映射，可能由于规则冲突导致无响应，可以简单的通过 ufw disable 关闭防火墙（不推荐）或者容器配置文件中 network_mode 使用 host 模式解决。

如果有多个节点，在每个节点上用相同的配置文件启动 Garage 后（注意 RPC Public IP 不同），依次添加其他节点，任意节点添加一次即可，会自动发现并同步到整个集群：

garage node connect <garage node id>
# 如果配置了 ufw 防火墙需要互相放行端口
# ufw allow from <node ip> to any port 3901

接下来为所有节点配置 layout：

garage status
garage layout assign <node id> -z <zone name> -c <storage capacity> -t <tag name>
# e.g. garage layout assign c66tu81zk2k2w1z8 -z dc1 -c 10g -t raspi

应用配置：

garage layout show
garage layout apply --version 1

如果后期修改了节点配置需要按提示使用更高的版本号。

添加存储桶

首先创建一个名为 test-bucket 的存储桶：

garage bucket create test-bucket
# 查看 bucket 信息
garage bucket list
garage bucket info test-bucket

一个存储桶通过单个或多个 API key 管理，创建 API key 用来管理 test-bucket 桶：

garage key create test-key
# 查看 API key 信息：
garage key list
garage key info test-key

记得将 Key ID 和 Secret key 信息保存到安全的地方。赋予该 API key 对 test 桶的访问或管理权限：

garage bucket allow \
  --read \
  --write \
  --owner \
  test-bucket \
  --key test-key

之后就可以使用 S3 API 兼容的工具 Rclone / CyberDuck 等连接到 Garage 进行管理了。比如使用 Rclone 连接，在配置文件 ~/.config/rclone/rclone.conf 中添加：

[garage]
type = s3
provider = Other
access_key_id = GKXXX
secret_access_key = xxxxxx
region = garage
endpoint = https://s3.example.com
# 如果是虚拟主机风格设置为 false
path_style_access = true

Garage 相对于 AWS S3 这些来说没有存储桶策略（Bucket Policy），如果要公开访问某一个桶，可以将其设置为网站模式：

garage bucket website --allow <bucket>

配置 Nginx

可以通过 Nginx 将 S3 API 更安全的反代出去：

server {
    listen 443 ssl;
    server_name s3.example.com;
    ...
    location / {
        client_max_body_size 0;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 300;
        proxy_max_temp_file_size 0;
        proxy_pass http://127.0.0.1:3900;
    }
}

如果使用虚拟主机风格，还需要解析 *.s3.example.com，存储桶网站模式的配置同理。推荐配置一些策略防止扫描或添加缓存，保证性能和后端安全性。

升级程序

升级 Garage 前建议阅读更新文档说明，保证安全的升级。其中：

小版本更新（如从 v0.8.0 到 v0.8.1）：推荐运行 garage repair --all-nodes --yes tables 检查健康度，没问题的话逐个节点升级即可。
大版本更新（如从 v0.7.1 到 v0.8.0，不支持跨版本）：检查健康状态后对所有节点的 metadata 进行快照 garage meta snapshot --all ，复制备份 cluster_layout 文件后逐个升级。

修复/替换节点

Garage 推荐 replication_factor 至少使用 3 副本策略来保障数据安全，此时如果 1 个可用区故障，集群依然可以正常读写；如果 2 个可用区故障，进入只读模式。因此当可用区发生故障时，建议尽快修复或者替换其他节点。

a. 如果某个节点数据盘损坏，但元数据 metadata 还在，只需要更换数据盘后挂载到原来的 data 目录，使用下面命令进行修复即可：

garage repair -a --yes blocks

b. 如果某个节点数据全丢无法恢复，或者单纯想换一个节点：

# 将新节点加入集群
# garage node connect <garage node id>
# garage status
garage layout assign <new node id> --replace <old node id> \
    -z <zone name> -c <storage capacity> -t <tag name>
# -z <zone name> 和 -c <storage capacity> 需与旧节点保持一致
garage layout show
garage layout apply --version <new version>

两种情况都可以使用 garage stats -a 监控，等待 resync queue length 归零则表示迁移同步完毕。

Web UI 管理

如果你偏向于图形界面操作，可以使用开源的第三方工具 garage-webui 在网页上方便的查看服务状态，管理节点、存储桶、API key 和对象文件。官方也正在开发 garage-webadmin 项目，目前需要自行编译。

services:
  garage:
  ...
  webui:
    image: khairul169/garage-webui:latest
    container_name: garage-webui
    restart: unless-stopped
    volumes:
      - ./garage.toml:/etc/garage.toml:ro
    network_mode: host
    environment:
      # BASE_PATH: "/garage"
      API_BASE_URL: "http://127.0.0.1:3903"
      S3_ENDPOINT_URL: "http://127.0.0.1:3900"
      # htpasswd -nbBC 10 "USERNAME" "PASSWORD"
      # 生成的字符串中带 $ 特殊符号，可以用 $$ 转义或通过 .env 文件设置变量
      # .env > GARAGE_UI_USER_PASS='test:$2y$10$2A4...'
      AUTH_USER_PASS: ${GARAGE_UI_USER_PASS}

使用感受

目前自建 Garage 使用了一周多，初步备份了一些文件，本站图片也迁移了上去，最大的感受是足够轻量，日常使用资源占用较低，在 1C1G 的 VPS 上也能良好运行。节点分布在海外三个不同的城市，同时 BOOM 的几率应该是 World War III 或者三体人入侵级别，作为一个从 2020 年开始维护至今的项目，有不少的用户，可靠性上应该没问题。

计划作为个人长期服务运行下去，只是如果后期数据量越来越多，需要同时扩容三个节点，成本也不算低。现在存储原厂们~~只做 AI 生意~~产能不足导致内存和硬盘价格飞涨，显得公有云对象存储服务都更有性价比了，不过 S3 兼容的好处是可进可退，只要价格到位，基石也是可以搬得动的。

EOF

赏阅。悦赏！

听风的歌

2026-02-01T15:03:02Z

午休时常常走到江边散步，边角处有两张长椅，很少有人来，是个不错的地方。就冬天来说，这里的风不算太冷，只要不夹杂水汽，也能凑合着相处一下。

晴天的时候总是很热闹，不停歇的风，如果恰好闭上眼睛，过去的故事就会浮现上来，没那么精彩，不好也不坏。随着身子不断暖和，一不留神就会被拉进梦里，梦中有一条很长的窄桥，窄到连转身都做不到，下边是引诱着你跳下去的湍流，直到你咬着牙勉强走到对面，才被一阵寒意惊醒。

阴天时候的风似乎温柔一些，吹不走的雾霾笼罩着对岸，一动不动，只有眼前的江水会随风流去。如果运气足够好，遇到一阵烟雨，就能品尝到泥土搭配野草的味道，和记忆中的味道一样，不会变味，也不会有人来。

风贴过耳边和与音乐交汇成只存在于当下的旋律，带来不断变化的思绪。有时也会有无休止的麻雀声催促着你离开，但我总是想多坐一会，继续听风的歌。

每当离开这里的时候，会有一种恍惚。记不清在这长椅上被风偷走的时间，好在想象力尚可，它一定是只带走了喧闹和午间的梦。

EOF

赏阅。悦赏！

偶尔是深夜就好了

2025-10-19T16:12:02Z

秋天的深夜总是让人上瘾，没有工作、没有嘈杂，难得能属于自己的时间。哪怕坐在那里什么都不想，只要打开半扇窗任凉风吹来，就能得到久违的平静。

深夜中坐在桌前，读过去的文章，能发现更隐晦的情感；听过去的音乐，能捕捉未曾注意的旋律；想过去的人和事，却依旧匆匆而过。

度过白天是一件很消耗法力值的事，我无法想象没有夜晚的世界。但现代社会拒绝夜晚、拒绝沉默，我们连做梦都要保持在线。小时候面对夜色总会不由地加快脚步，如今不再担心夜晚，还是无法停下，哪怕能走慢一点也好。

深夜中走上街头，有人疲惫不堪，有人努力证明自己的存在，白天无情地吞噬一切，最初的目的也被遗忘。在历史洪流的邮轮上，永远灯火通明，船上的人载歌载舞，河里的人随波漂流。

即使明天要一早起来，也仍想在这深夜中多停留一会儿。或许我想要的不是深夜，而是无人打扰的自己，可在白天的馈赠下，偶尔是深夜就好了。

EOF

赏阅。悦赏！

新玩具 AirPods Pro 3

2025-09-23T14:24:58Z

最近受限于公交车上的时间 ，手里的 Air/EarPods 都已力不从心，产生了降噪耳机的需求。刚好 AirPods Pro 3 发布，去店里试戴对比了 AirPods 4 降噪版，发现两款的降噪效果差距还是挺明显的，虽然不太喜欢入耳式耳机，为了更好的降噪效果还是购入了 AirPods Pro 3。

AirPods Pro 3.

其实前几天我也测试了吃灰多年的森海塞尔 IE60 在通勤路上的隔音效果，入耳式耳机本身就带有物理降噪的效果，差强人意基本能凑合。但有个小问题，在绝大多数手机没有 3.5mm 接口的今天，必须配一个带 DAC 的 Lightning/Type-C 转接头，小尾巴吊着总不舒服，上下车时也容易把线挂到别人身上。

目前 AirPods Pro 3 使用了两天，可能是各种评测视频拉高了我的预期，实际体验仅仅是能满足我的降噪需求，没有别的惊喜，也没有任何惊艳的感觉。音质不评价，无线耳机谈音质就是耍流氓，就这个价位来说，要评价大抵也是差评。而主动降噪（ANC, Active Noise Cancellation）的效果，也不像那些视频中说的一样完全的「Mute All」，只能说多数场景下可以较为出色的完成任务，85分合理，再多就信仰了。

主观的体验是 ANC 能隔离约 80% 的声音（低频、持续噪音），大幅降低 10% 的声音（中低频的短促噪音），还有 10% 的声音（高频、突发噪音）效果有限。或许出于安全、耳压不适感等方面的考虑，苹果在固件上有意限制了降噪能力，但这不是我该考虑的因素。

具体到通勤场景，本身车轮滚动和电动机的噪音由于通过座椅传播的原因，变成了类似底噪的存在，不会引起太多注意，而附近乘客大声交谈的声音、咳嗽声依旧比较明显，因此短视频外放的声音仍然会困扰到你，只能调大音乐音量。步行时的表现会更好一些，只有自己轻微的脚步声和擦肩而过路人短暂的说话声。办公室等环境比较稳定、声波更好「预测」的场景表现就更好，只能隐约听到一些交谈声，搭配音乐能大幅提高午休质量。

关于耳塞，本次 AirPods Pro 3 配备了五种尺寸的硅胶耳塞（XXS/XS/S/M/L），我主要测试了 XS、S 和 M 号三种。对我来说 XS 号最舒服，但降噪效果有明显的下降；S 号刚好能放入耳道，但每次刚戴上一段时间里会有明显异物感，降噪效果不错；M 号刚好卡在耳道口，会有一点轻微的胀耳朵，降噪效果略好于 S 号。最后决定选择 M 号做为日常使用，也更贴近以往佩戴入耳式耳机的体验。

总的来说，这次的 AirPods Pro 3 能解决我的一些刚需，但依旧 H2 芯片，不支持无损传输和普通的音质，原价购入肯定不划算。要说购买建议的话，只推荐有降噪需求的用户购买，毕竟也算是果牌 TWS 耳机的护城河功能了，同时不管你是初次购买还是换代升级，都还是过段时间晚买享折扣更好。

EOF

赏阅。悦赏！

公交车上的时间

2025-09-15T12:16:03Z

现在工作通勤需要乘坐单程一小时的公交车，为了利用好这段被「偷走」的时间，我试图在车上找些事做，但并不容易。作为一个会晕车的人，静坐还好，只要多玩一会儿手机或者看书就很容易中的头晕目眩的魔法。因此找件「积极向上」又不至于让我「口吐芬芳」的事是我近期的目标。

公交车本身是个复杂的生态系统，大体由放学的小朋友、看短视频的青年人、热闹聊天的中老年人以及一些沉默不语的人，带着他们每一天的心情组成。每个人都会被动地散发出各自的气场，一不留神就会被吸进去。

一般情况下，听音乐是必要的流程，但老旧的挂耳式耳机在这种场景下已经不堪重任，不加到 50% 音量以上很难听个响，音量过高又对耳朵不好，最近几天越来越不愿意戴上耳机了。或许是时候换一款降噪耳机，还能解锁听播客和有声书的支线任务。

好在我上下车都靠近起终点站，基本能有座位，看着人来人往也成为了一件可以稍微解闷的事。不过无论是早上还是晚上，摇摇晃晃到最后总会犯困，我也时常主动寻求犯困，可总归是不太舒服的，还会担心坐过站，意识在悬崖边徘徊反而更累。

更多的时候，我的视线会逃到窗外，途中有一半的路程是城乡公路，一面是山一面是江，也算有山有水，但上班的思绪会提醒你这不是旅途的风景，挤在窗里的山水由此也变得缺少韵味，无心欣赏，只剩得发呆与胡思乱想。夏日的尾巴也总是热情奔放，车内空调显得力不从心，还有雨天独特的气味也十分耐人，浑浊湿润的空气让心情也会降低几度。一时间确实很难找到「有意义」的事做。

其实我对于公交车上的时间不算讨厌，除了这些不可避免的缺点外，算是一段没有太多束缚的时间，不用自己开车一直保持注意力，还经济环保。有时时间很慢，数着二十几个站怎么也数不完，有时时间又很快，一晃过神就到站了。或许我只是先入为主的认为了这段时间应该做一些事才好，不然就浪费掉了。但仔细想想，这段时间和上班并无二致，只是少了一些不管好坏的即时反馈，公交车除了舒适性和更耗时外，没太多值得抱怨的，而工作中要抱怨的就太多了。能利用上这段时间固然很好，什么都不做也没差嘛，过于追求反而会掉进焦虑的漩涡，也罢。

在没有交通工具的时间里，人们没有如何度过这段被「偷走」时间的烦恼，它本身就是生活的一部分。想必从某一天开始，当我不再走这条路时，记忆的自我修正也会让这段的时间多少变得更有趣一点，成为谈笑过去的一部分。到那时，「找回」的时间又会花到哪里去呢。

EOF

赏阅。悦赏！

从 WHOIS 到 RDAP

2025-05-12T15:23:23Z

前几天在我自己的 WHOIS 查询工具上查询 .dev .app 等 Google 注册局的域名时返回错误，才发现 Google 已经关闭 WHOIS 服务器并停止了 whois.nic.google 的 DNS 解析，在 IANA 上查询 whois 服务器一行也显示为空。

原来今年一月 ICANN 就发布了文章「ICANN Update: Launching RDAP; Sunsetting WHOIS」，自 2025 年 1 月 28 日起，RDAP (Registration Data Access Protocol) 即注册数据访问协议将成为提供通用顶级域名（gTLD）注册信息的权威来源，正式取代历史悠久的 WHOIS 协议。

原因也很简单，WHOIS 协议 40 多年来一直作为访问域名注册数据的标准，过时的设计已无法满足当下的需求，如无标准化的格式、针对国际化缺乏支持、无法验证服务器或加密数据等。同时 WHOIS 返回的是 plain text 数据，对计算机并不友好，而 RDAP 返回的是 JSON 格式的数据，计算机更容易处理，而且 RDAP 直接通过 HTTP/HTTPS 提供服务，不需要单独的 43 端口，更加安全和高效。

一条简单的时间线：

1982 年 WHOIS 协议被定义为互联网工程任务组 (IETF) 协议。
2015 年 RDAP 协议由 IETF 发布为国际技术标准。
2019 年 ICANN 开始启动多期方案从 WHOIS 过渡到 RDAP，强制要求所有 gTLD 的注册管理机构和 ICANN 认证注册服务机构在 2019 年 8 月 26 日前需按照 RDAP 协议提供 RDDS (Registration Data Directory Services)。
2023 年 8 月 7 日《gTLD 注册管理机构基本协议》、规范 13 以及 2013 年《注册服务机构认证协议》的通用修订案正式生效。
2025 年 1 月 28 日 ICANN 正式取消了所有 gTLD 的注册管理机构和 ICANN 认证注册服务机构需要通过 WHOIS 协议提供 RDDS 的要求。

当然，ICANN 并没有要求关闭 WHOIS 服务器，注册商们可以自己决定是否继续提供服务。同时 ICANN 只管理 gTLD 域名，不管理国别域名（ccTLD），到现在也只有不到 1/3 的国别域名支持了 RDAP，更多的还是只能通过 WHOIS 查询，也意味着接下来很长一段时间都将是「交错的时代」。

降级 WHOIS 查询工具

我从 2022 年开始就一直用的自己的 WHOIS 查询工具，也一直在维护一份 WHOIS 服务器列表，支持绝大多数 TLD 查询。最开始是用 PHP 写的，去年用 Golang 重构了一番，现在自然也要与时俱进支持一下 RDAP。

WHOIS Lookup (2022-2025)

标准的做法当然是在现有的基础上添加 RDAP 支持即可，未匹配 RDAP 地址的国别域名回落到 WHOIS 查询，保证无缝过渡。但可能是修改的时候心情不好，也可能是被 RDAP 混乱的 JSON 字段感动到了，干脆删除了所有 WHOIS 相关的代码。可以说这次更新迎来了不小的退化，一些常用的国别域名比如 .cn .io .me 等都不再支持。

好处是很长一段时间时间内都不用再额外维护，只需要定期自动更新 IANA 提供的 RDAP bootstrap 数据文件，默默等待大多数 ccTLD 们支持 RDAP 的那一天。

EOF

赏阅。悦赏！

通过 WireGuard 访问 NFS 共享文件

2025-05-08T11:13:07Z

有时 VPS 的硬盘会不够用，如果只是用来存储数据，比起直接扩容/升级，趁着各种活动的时候另购一台大硬盘 VPS 往往更加划算。

跨地区挂载我一般使用 WebDAV(HTTPS) + Rclone，而同地区挂载为了速度和性能，NFS（Network File System，网络文件系统）是更好的选择。不过 NFS 自身不提供加密功能，在公网或能内网互通的机房上需通过 TLS 或 Kerberos 加密，也可以使用本文介绍的方法，利用 WireGuard 协议进行加密传输。

* 需要注意 WireGuard 协议通过 UDP 传输流量，部分服务商会对 UDP 进行 QoS，导致体验不佳。选择该方案前建议先使用 iperf3 测试 UDP 速度，确保服务商未作限制。

这里假设 VPS A 作为服务端存储数据，VPS B 作为客户端运行服务，通过 WireGuard 建立加密隧道，使 VPS B 能够安全地访问 VPS A 上的数据文件。以下操作演示环境为 Debian 12，默认以 root 用户进行。

配置 WireGuard

1. 安装 WireGuard

在两台 VPS 上都安装 WireGuard：

apt install wireguard

2. 生成密钥对

在两台 VPS 上分别生成 WireGuard 密钥对 private.key 和 public.key：

umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
umask

3. 配置 WireGuard

我这里内网 IP 选择使用 10.0.1.0/24，VPS A（服务端）的 IP 设置为 10.0.1.1，VPS B（客户端）的 IP 设置为 10.0.1.2。你可以替换为其他网段或自己喜欢的保留地址。

a. 修改 VPS A（服务端）的配置文件 /etc/wireguard/wg0.conf：

[Interface]
Address = 10.0.1.1/24
ListenPort = 51820
PrivateKey = <VPS A 服务端私钥>

[Peer]
PublicKey = <VPS B 客户端公钥>
AllowedIPs = 10.0.1.2/32

# [Peer]
# PublicKey = <VPS C 客户端公钥>
# AllowedIPs = 10.0.1.3/32

b. 修改 VPS B（客户端）的配置文件 /etc/wireguard/wg0.conf：

[Interface]
Address = 10.0.1.2/24
PrivateKey = <VPS B 客户端私钥>

[Peer]
PublicKey = <VPS A 服务端公钥>
Endpoint = <VPS A 服务端公网 IP>:51820
AllowedIPs = 10.0.1.1/32
# PersistentKeepalive = 25

c. 在两台 VPS 上分别启动 WireGuard：

systemctl enable wg-quick@wg0.service
systemctl start wg-quick@wg0.service
systemctl status wg-quick@wg0.service

d. 检查是否连接成功：

wg show

运行上面命令后如果有流量数据或者能 ping 通对方说明可以正常通信，之后建议删除两台 VPS 上的密钥文件 /etc/wireguard/private.key。

* 如果 VPS A（服务端）上开启了防火墙，记得放行 WireGuard 端口给 VPS B（客户端），比如 ufw 防火墙：

ufw allow from <VPS B 公网 IP> to any port 51820

配置 NFS

1. NFS 服务端（VPS A）

a. 安装 NFS 服务端：

apt install nfs-kernel-server

b. 添加共享目录。编辑 /etc/exports 文件，假如这里要共享 /mnt/data/share 目录，文件最后添加：

/mnt/data/share 10.0.1.2(rw,sync,no_subtree_check,no_root_squash)

这表示将 /mnt/data/share 目录共享给 IP 地址为 10.0.1.2 的客户端。

其中：

rw: 文件权限。客户端拥有读写权限。
sync: 同步写入。写操作会立即写入磁盘，比 async 更安全，但稍慢。
no_subtree_check: 禁用子目录检查。禁用可以提高性能并避免某些权限错误。
no_root_squash: 不压缩 root 权限。客户端的 root 用户拥有服务端的 root 权限（安全性较低，一般用于信任的环境），默认是将客户端的 root 映射为匿名用户。

如果选择 root_squash 记得修改目录权限，保证客户端用户能正常读写。

应用配置更改：

exportfs -ra

c. 可选安全配置。确保 NFS 服务仅监听 WireGuard 接口，并且关闭 NFSv2 和 NFSv3，只使用 NFSv4。编辑 /etc/default/nfs-kernel-server，添加设置：

# 注释前面的 RPCMOUNTDOPTS 变量行，添加下面内容
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3 -H 10.0.1.1"
RPCNFSDOPTS="-N 2 -N 3"

修改 /etc/nfs.conf：

[nfsd]
host=10.0.1.1

重启 NFS 服务：

systemctl restart nfs-kernel-server

* NFSv4 不需要 rpcbind 服务，可以禁用以避免不必要的启动和资源消耗：

systemctl mask rpcbind.service
systemctl mask rpcbind.socket

* 如果 VPS A（服务端）上开启了防火墙，记得放行 NFS 内网端口给 VPS B（客户端），比如 ufw 防火墙：

ufw allow from 10.0.1.2 to any port 2049
ufw allow from 10.0.1.2 to any port 111

2. NFS 客户端（VPS B）

a. 安装 NFS 客户端：

apt install nfs-common

b. 创建挂载点并挂载共享目录。假如这里要挂载到 /mnt/vps-a 目录：

mkdir -p /mnt/vps-a
mount -t nfs -o vers=4.2 10.0.1.1:/mnt/data/share /mnt/vps-a

现在，你可以尝试 ls /mnt/vps-a -l 查看 VPS A 上的共享文件了。

3. 开机自动挂载

编辑 /etc/fstab 文件，添加以下行：

10.0.1.1:/mnt/data/share /mnt/vps-a nfs vers=4.2,x-systemd.requires=wg-quick@wg0.service 0 0

其中 x-systemd.requires=wg-quick@wg0.service 表示在尝试挂载这个文件系统之前，必须先成功启动 wg-quick@wg0.service 服务；0 0 这两个数字分别代表 dump 命令的备份频率和 fsck 命令的文件系统检查顺序。对于网络文件系统，通常设置为 0 0，表示不进行备份和检查。

至此，成功实现了在 VPS B 系统启动时自动挂载 NFS 文件系统，通过 WireGuard 加密隧道访问另一台 VPS A 服务器上的共享文件。

EOF

赏阅。悦赏！

自建音乐串流服务探索

2025-05-06T08:00:10Z

听歌这件事似乎变得越来越麻烦。

2014 年之前，我主要用 QQ 音乐听歌，那时随便一个平台都有着丰富的曲库。2014 年，我转到了眉清目秀的网易云音乐，那时的网易云音乐还很纯粹，后来国内音乐进入了「版权时代」，看着歌曲一天天变灰也坚持用着，直到开始不务正业引入短视频等各种臃肿功能，2018 年的下架周董歌曲「打包收费」事件，让我直接卸载了网易云音乐，即使还有很长时间的会员没到期。此时国内音乐进入了「独家版权时代」，不同时开几个平台的会员很难有好的体验。好在及时醒悟过来放弃了国内音乐平台，之后一直用着 Apple Music 搭配 Spotify，算是比较省心。不过为了给消费降级趋势出一份力，去年底也取消订阅了使用 8 年的 Apple Music。

其实也是发现自己对音乐曲库的需求越来越小了，平时基本在听老歌，听歌更多时候是为了作为 BGM 增加点氛围感。我对华语音乐的记忆似乎还停留在 10 年前，对外语音乐的记忆停留在 5 年前，可能一代人有一代人的歌，新一代的歌我也很难去欣赏。现在只是偶尔去听下自己关注歌手的新曲，或者 Spotify 推荐歌单。既然如此，不如自建音乐串流服务，整理出自己的专属曲库，体验应该也差不了太多。

自建音乐服务项目有不少，我主要是听个响，有损 MP3 320 Kbps / AAC 256kbps 足以，还省空间，所以 Roon 这类很贵专业的方案是直接跳过的。同时我的音乐文件都习惯先通过 MusicBrainz Picard 整理标记，所以对服务端功能也没太多要求。过去一年里陆续尝试过 Emby/Jellyfin, Navidrome, Gonic, LMS (Lightweight Music Server) 等服务，网上能搜到很多介绍文章，这里不再多说。同时也把 iOS App Store 里能搜索到的对应客户端几乎试了个遍。

就结论来说，过去大半年里我都用着 Navidrome 服务端搭配 Amperfy 客户端。整体比较满意，美中不足的是 Navidrome 还不支持读取外挂歌词文件（等了快一年的 PR，~~应该也快了~~ 已合并）。因为这个问题有段时间换到过 Jellyfin 搭配 Manet/AmpFin，但体验下来还是不如 Navidrome + Amperfy 简单顺滑，加上 Amperfy 后来新增了 macOS 原生客户端支持，毫不犹豫的换了回来并使用到现在。

Amperfy

当然，我也知道还有一个热门的组合没尝试，经常看到网友对 Plex 的音乐软件 Plexamp 赞美有加，但很多特性需要开通 Plex Pass 会员才支持，而我对 Plex 的印象一直不太好。以前搭建过 PMS (Plex Media Server)，必须用 Plex 账号联网登录，各种隐私数据收集拉满，后来还禁止托管在 Hetzner 上。加上 Plex 一直在向流媒体服务转型，混乱的社交名流主页，对自建用户的体验越来越不重视，所以一直没尝试。但前几天看到 Plex Pass 即将涨价和阿根廷区低价 Lifetime Plan 的消息后，还是按耐不住，顺手搭上了末班车，可以说这次购买几乎是冲着 Plexamp 去的。

Plexamp

几天体验下来，先说服务端 PMS，抛开我对 Plex 的「恶意」不谈，Plex 确实比 Emby/Jellyfin 更加好看和流畅，使用上也更省心，音乐库的管理功能上倒是都差不多。在歌词这一块，Plex 目前和 Navidrome 相反，不支持内嵌歌词，只支持外挂歌词，不过如果没有本地歌词 Plex 会自动通过 LyricFind 寻找（需要 Plex Pass），可惜对于中文歌曲支持一般。

再说客户端 Plexamp，基础功能大家都一样，Plexamp 的亮点在于 UI 设计、音乐无缝切换和基于音乐（库）分析的推荐/电台功能。手机端上的体验比较满意，但不多做夸奖。桌面端上就比较失望了，Electron 应用在我这里向来是扣分的，但也不是不能接受，除非太敷衍，Plexamp 桌面端几乎就是移动端的放大版，没做过多的适配。同时也遇到了不少 bug，比如左上角关闭窗口后，后台仍在运行，但无法恢复窗口显示，只能退出进程重新打开 ~~怪不得默认隐藏窗口控件~~。也发现即使你下载了整个歌单，仍然只有从下载分栏进入歌单播放才会使用本地文件，如果从其他入口播放该歌单还是会再次下载缓存到硬盘（已在设置中开启始终优先选择下载的媒体），把缓存和下载功能分开看待的逻辑有点难以理解，于是我选择了直接把缓存拉满。更可惜的是我发现的不少 bug 都能在一些多年前的反馈帖子中找到，却不了了之或无人问津。

不过如果再次抛开我对 Plex 的「恶意」不谈，Plexamp 整体体验是不错的，对于多数想自建的用户来说算的上是比较出色的方案，无论是音乐库管理，UI 界面，还是功能性相比其他几个平台都有一定的优势。但 Plex Pass 会员现在并不便宜，如果只是为了音乐串流服务的话就不太值了。

总的来说，目前我应该会继续主力使用 Navidrome + Amperfy，等哪天 Plexamp macOS 客户端的体验更好了可能会全面切过去。其实对于自建音乐串流服务来说，选择平台往往是最简单的部分，最麻烦的还是资源获取与整理，无论是自购转录还是网上找都很花时间。好在我喜欢的歌不算太多，一年下来零零散散着整理也差不多了，不然还是建议直接订阅音乐流媒体更加舒畅。

小剧场：消失的 Plex 外挂字幕与 Plexamp 歌词

既然买了会员，也顺便再次试下 Plex 的影视媒体库，相比 Emby/Jellyfin 确实有独特的优点，但也有糟心的问题。测试网页播放时，发现 Plex 对于外挂 ASS 字幕的支持有个老问题，我的 PMS 搭建在 VPS 上，所以关闭了转码，直接通过串流播放，但 Plex 的逻辑是只要字幕包含不支持的特效就会强制转码烧录，在设置中修改 Plex Web 播放器的固化字幕选项为「仅图像模式」可以解决部分问题，但其他情况下还是会遇到错误提示「该服务器没有足够性能用于转化视频」，不加载字幕则可以正常播放，经测试同一个视频和字幕在 Jellyfin 网页播放没有问题 ~~当然 Jellyfin 有他自己的祖传方块问题~~。

那我放弃网页播放，改用第三方客户端（Infuse/Vidhub）播放。但这时发现连字幕的选项都没有了，直接无法获取。搜索半天在 Plex 论坛上发现有人提到可能是 Nginx 反代问题，试着添加下面配置后终于可以获取字幕了。

location /library/streams/ {
    proxy_pass_request_headers off;
    proxy_pass http://127.0.0.1:32400;
}

解决问题后，满意的打开 Plexamp 准备听音乐放松下，却发现所有歌曲都无法显示歌词了… 一开始还以为是客户端的 bug，重启重装研究了好一会才想到可能是修改 Nginx 配置导致的问题，注释掉后果然又可以正常获取歌词了。

于是猜测可能是某个 header 导致了无法获取字幕，测试以下配置：

location /library/streams/ {
    # 默认关闭转发 header
    proxy_pass_request_headers off;
    # 转发 Plex 自定义 header
    proxy_set_header X-Plex-Client-Identifier $http_x_plex_client_identifier;
    proxy_set_header X-Plex-Device $http_x_plex_device;
    proxy_set_header X-Plex-Device-Name $http_x_plex_device_name;
    proxy_set_header X-Plex-Platform $http_x_plex_platform;
    proxy_set_header X-Plex-Platform-Version $http_x_plex_platform_version;
    proxy_set_header X-Plex-Product $http_x_plex_product;
    proxy_set_header X-Plex-Token $http_x_plex_token;
    proxy_set_header X-Plex-Version $http_x_plex_version;
    proxy_set_header X-Plex-Nocache $http_x_plex_nocache;
    proxy_set_header X-Plex-Provides $http_x_plex_provides;
    proxy_set_header X-Plex-Device-Vendor $http_x_plex_device_vendor;
    proxy_set_header X-Plex-Model $http_x_plex_model;
    proxy_pass http://127.0.0.1:32400;
}

默认关闭 header 转发，只转发 Plex 自定义的 header，终于同时解决了两个问题。

EOF

赏阅。悦赏！

我停止了探索 Fediverse

2025-02-23T12:50:01Z

在去年的文章 Fediverse 与社交 中，最后提到 GoToSocial 的出现让我又有了一种会喜欢上在 Fediverse 中探索的错觉。但不到半年，这种错觉已然幻灭。

我对 Fediverse 的态度在前面的文章中已经很明确。虽然我喜欢 Fediverse 的理念，喜欢拥有自己的数据，喜欢没有广告，喜欢不被大公司收集隐私的感觉。但开局就单机社交的难度还是太高，你并不会成为自己的中心，反而只能困在自己的围城里。

我试图推荐给他人，但没几个人会愿意离开舒适圈去使用其他学习成本更高的平台。归根结底社交这件事并不在于去不去中心化，在什么平台，而在于参与的人，首先是个人的需求，再者是生活中的朋友，然后是有共同圈子的陌生人。我也曾多次花上一整晚去到处搜索发现，但除了媒体账号外，找不到几个感兴趣的，我喜欢的歌手、各类创作者们仍然活跃在中心化的平台上。

显然目前 Fediverse 的优点还远远不足以解决这个最大的问题。尊重每个人的实际需求，社交媒体也许并没有多少实质上的社交，发再多的动态，点赞再多的帖子都比不上发条消息找朋友开一局游戏，出门吃顿饭。

对我来说，Fediverse 最终变为了一个专用的「吐槽」回收站。因为我并没有多少独特或有价值的观点，也没多少人关心我写的内容，我发现不了别人，别人也发现不了我。同时，对不少人来说，Fediverse 最终会成为一个贴生活琐事自言自语的「树洞」，或者成为建政爱好者们无休止宣泄的地方。当然，也会有不少人在 Fediverse 找到舒适的社区和聊的来的朋友，找到快乐。

现在想来，离开社交媒体多年的我果然不会因为 Fediverse 的出现而找回那些失去的情绪。更多的只是想了解这些新技术，折腾软件的搭建、维护过程罢了，对我来说这个过程可能远比在 Fediverse 中互动更有趣。

或许去中心化和中心化并没有那么对立，人生苦短，即便是取乐，有时也需要考虑如何更轻松地取乐，权衡需求使用就好，如果我只是需要一种舒适的「吐槽」方式，那就有太多的选择了。到这里，我依然会继续使用 Fediverse，但放弃自建和探索，使用 BlueSky 或 Mastodon 等官方实例，回归为一个单纯的用户，作为吐槽工具或者新闻阅读器是个不错的结局。

EOF

赏阅。悦赏！

互联网背景噪音

2024-12-30T09:29:05Z

网站会有持续的漏洞扫描与爬虫采集；公网 SSH 会有不间断的字典爆破；搜索一分钟，伸手半小时，还能水经验；网友奇妙发言，以钓鱼引战为乐，互相问候为趣；竞技游戏就是为了让少爷们玩得舒服；出现苹果的地方就会出现「自适应」；科技饭圈，赛博割菜… 我一直试图把这些当作互联网的背景噪音。

思来想去问题出在多样性上，人脑是产生意识的物质器官，每个人都是自己的中心，这种中心性对每个人都是不可否定，绝对正确的事实，但每个人对其他陌生人又是可有可无的存在，这种矛盾导致了多数的社交性问题。

不同的人脑对自己中心性的优先级不同，低一些可以助人为乐、舍己为人，高一些可以自我主义、我即世界，就像婴幼儿一样。高低的差异很大程度上取决于成长环境，而即便是一个「成熟」的人，在互联网上考虑他人的优先级又比现实中低很多，制造噪音就是他们所理解的获得利益和乐趣的方式。就像「存在即合理」是对黑格尔原文的污染性错误翻译，但「存在即有因」，对于他们来说正确的事，我批评他们自然是不合理的。

而互联网平台的夸张标题/争议/擦边等流量式推荐算法属于更强烈的噪音，他们是墙内养蛊的竞争者，以提高自己的毒性为最高优先级，希望你参与到背景噪音中去成为他们的养分。一旦中心性来到个别集体利益上，对于他们来说绝对正确的事，我批评他们自然也不合适。

尽管我一直都在尝试无视这些噪音，甚至把一些以前常逛的网站重定向到了 localhost，但噪音过多总会有难以忍受的时候，这些噪音已经无处不在，似乎互联网上的一切都在被噪音影响并不断侵蚀，就算你发现了净土般的地方，迟早也会被污染，有一种无处可逃的无力感。

于是我也失去了继续吐槽和对抗互联网噪音的兴趣，既然无法避免，这何尝不是为忧而更忧。或许问题出在我对互联网的打开方式上，又或许互联网并不是一种可靠的消遣方式？因此我所能做的只有减少网上冲浪和提高自己的噪音过滤能力以及，多吃薯条。

EOF

赏阅。悦赏！