日常

主域名切换至 obsp.dev

Tue, 15 Sep 2026 02:30:00 +0200

一、全新的主域名

本站的主域名将从 obsp.de 切换为 obsp.dev。~~站长希望走向更国际化的视野，而不是只专注于欧洲，因此作出了这一调整。~~ (Na ah they just like the vibe)

二、变更范围

本次变更只影响网站本身（@ 和 www）。其余所有服务仍将保留在 obsp.de 域名下，无需你做任何改动。

现阶段，obsp.dev 的 www 与 @ 会重定向到 obsp.de。2–3 周之后，重定向方向将反过来。届时 RSS 条目可能会失效，在此提前致歉。

三、身份与 WKD

root@obsp.dev 如今是站长的另一个身份。OpenPGP 密钥指纹保持不变：

TEXT

9967 35BE 4961 80AF B582 ECAB EE31 BB28 ECF6 B268

同时，该密钥现已支持通过 WKD 发现，直接运行 gpg --locate-key root@obsp.dev 即可获取。

四、DNSSEC

由于该域名仍较新，DNSSEC 暂时尚未启用。预计一个月内将正式上线，届时会采用算法 13（ECDSA-P256-SHA256）或算法 15（Ed25519）中的一种。

GoToSocial 搭建与备份心得

Sat, 27 Jun 2026 03:05:15 +0200

GTS 的安装

因为开到了甲骨文，所以决定搭建一个自己的 Fediverse 实例，思来想去选了 GoToSocial, 比较轻量级，也可以使用各种兼容 Mastodon API 的客户端，美中不足就是比较 bareminimum，像表情回应和引用之类的功能是没有的。

GTS 官方的 docker-compose.yaml 长这样：

BASH

wget https://codeberg.org/superseriousbusiness/gotosocial/raw/branch/main/example/docker-compose/docker-compose.yaml

YAML

services:
 gotosocial:
 image: docker.io/superseriousbusiness/gotosocial:latest
 container_name: gotosocial
 user: 1000:1000
 networks:
 - gotosocial
 environment:
 # Change this to your actual host value.
 GTS_HOST: example.org
 GTS_DB_TYPE: sqlite
 # Path in the GtS Docker container where
 # the sqlite.db file will be stored.
 GTS_DB_ADDRESS: /gotosocial/storage/sqlite.db
 # Change this to true if you're not running
 # GoToSocial behind a reverse proxy.
 GTS_LETSENCRYPT_ENABLED: "false"
 # Set your email address here if you
 # want to receive letsencrypt notices.
 GTS_LETSENCRYPT_EMAIL_ADDRESS: ""
 # Path in the GtS Docker container where the
 # Wazero compilation cache will be stored.
 GTS_WAZERO_COMPILATION_CACHE: /gotosocial/.cache
 ## For reverse proxy setups:
 GTS_TRUSTED_PROXIES: "172.18.0.1/16"
 ## Set the timezone of your server:
 #TZ: UTC
 ports:
 - "443:8080"
 ## For letsencrypt:
 #- "80:80"
 ## For reverse proxy setups:
 #- "127.0.0.1:8080:8080"
 volumes:
 # Your data volume, for your
 # sqlite.db file and media files.
 - ~/gotosocial/data:/gotosocial/storage
 # OPTIONAL: To mount volume for the WAZERO
 # compilation cache, for speedier restart
 # times, uncomment the below line:
 #- ~/gotosocial/.cache:/gotosocial/.cache
 restart: "always"

networks:
 gotosocial:
 ipam:
 driver: default
 config:
 - subnet: "172.18.0.0/16"
 gateway: "172.18.0.1"

我自己用的时候，因为机器上已经有运行着的 Caddy，就把关于反向代理的部分都注释掉了。

然后在 environment 底下加了几行（GTS 有个单独的 config 文件用来调整环境变量，但是你不想挂载出来的话可以直接在 compose.yml 里面写，只要把变量名全部大写， - 换成 _，在前面加上 GTS_ 就好了，参考此处）：

YAML

 GTS_ACCOUNTS_ALLOW_CUSTOM_CSS: true # 允许自定义 CSS
 TZ: Europe/Berlin
 GTS_INSTANCE_LANGUAGES: "zh,en,nl,de,fr,ja"

在 volumes 下面挂载了自定义字体：

YAML

 - /home/ubuntu/gotosocial/fonts/GeistPixel-Square.woff2:/gotosocial/web/assets/fonts/GeistPixel-Square.woff2:ro

这样做之后，就可以在 CSS 中调用啦。

CSS 美化

GTS 用户资料主题的来源有两个，一个是管理员上传主题作为备选项，另一个是用户自行编辑 CSS。这两个效果会叠加。

全站的 CSS 也是可以自定义的，我用了 Catppuccin Frappé 和 Geist Pixel Square, Fusion Pixel 的组合。

数据库和媒体的备份

说实话我对自建实例这件事一直很犹豫，因为我对自己的备份没什么信心，如果数据库损坏，签署信息的密钥会丢失，想要从这个域名重新加入联邦会非常非常麻烦。

GTS 文档里面有关于备份和恢复的详细教程，其中推荐的数据库备份法是 Borgmatic。~~不过我比较懒，在写这篇之前没有看这部分所以我没用~~

备份媒体和数据库我用的是 S3 桶，通过 rclone 挂载。

当然可以把 docker 映射到本机的文件夹里的内容一股脑全部上传，不过这样不太优雅，因为媒体文件包含远端实例的缓存，这些东西吃掉的空间比较多，但并没有备份的必要，只需要保存本实例的媒体即可。

GTS CLI tools 有 gotosocial admin media list-attachments 和 gotosocial admin media list-emojis, 只要在运行的时候加上 --local-only 的 flag 即可只列出本地媒体文件。

输出类似于这样：

TEXT

/gotosocial/062G5WYKY35KKD12EMSM3F8PJ8/attachment/original/01PFPMWK2FF0D9WMHEJHR07C3R.jpg
/gotosocial/01F8MH1H7YV1Z7D2C8K2730QBF/attachment/original/01PFPMWK2FF0D9WMHEJHR07C3Q.jpg
/gotosocial/01F8MH5ZK5VRH73AKHQM6Y9VNX/attachment/original/01FVW7RXPQ8YJHTEXYPE7Q8ZY0.jpg
/gotosocial/01F8MH1H7YV1Z7D2C8K2730QBF/attachment/original/01F8MH8RMYQ6MSNY3JM2XT1CQ5.jpg
/gotosocial/01F8MH1H7YV1Z7D2C8K2730QBF/attachment/original/01F8MH7TDVANYKWVE8VVKFPJTJ.gif
/gotosocial/01F8MH17FWEB39HZJ76B6VXSKF/attachment/original/01F8MH6NEM8D7527KZAECTCR76.jpg
/gotosocial/01F8MH1H7YV1Z7D2C8K2730QBF/attachment/original/01F8MH58A357CV5K7R7TJMSH6S.jpg
/gotosocial/01F8MH1H7YV1Z7D2C8K2730QBF/attachment/original/01CDR64G398ADCHXK08WWTHEZ5.gif

利用这个功能，我们可以在定时备份的时候对媒体文件根据本地账号进行筛选。

以 rclone 备份 docker 容器映射到宿主机的文件夹为例：

/usr/local/bin/rclone-backup-optimized.sh

YAML

#!/usr/bin/env bash
set -uo pipefail


SRC="/home/ubuntu/gotosocial/data"
MEDIA_DST="remote:bucket/media"
DB_DST="remote:bucket/db"
CONF="/home/ubuntu/.config/rclone/rclone.conf"
COMPOSE_FILE="/home/ubuntu/gotosocial/docker-compose.yaml"
SERVICE="gotosocial"  # 容器名称
GTS_BIN="/gotosocial/gotosocial" 
DB_FILE="/home/ubuntu/gotosocial/data/sqlite.db" 


# SQLite (vacuum into snapshot)
DB_OK=1; DB_OUT=""
SNAPDIR=$(mktemp -d); SNAP="$SNAPDIR/sqlite.db"
if DB_OUT=$(sqlite3 "$DB_FILE" "PRAGMA busy_timeout=10000; VACUUM INTO '$SNAP'" 2>&1); then
 CHK=$(sqlite3 "$SNAP" "PRAGMA integrity_check" 2>&1)
 if [ "$CHK" = "ok" ]; then
 if DB_OUT=$(rclone copy "$SNAP" "$DB_DST/" --config "$CONF" 2>&1); then
 DB_OK=0
 fi
 else
 DB_OUT="Snapshot integrity failed: $CHK"
 fi
fi
rm -rf "$SNAPDIR"

# list local account id 
get_ids() {
 sudo docker exec "$SERVICE" \
 "$GTS_BIN" admin media "$1" --local-only 2>/dev/null \
 | grep -oE '/[0-9A-HJKMNP-TV-Z]{26}/(attachment|emoji)/' \
 | grep -oE '[0-9A-HJKMNP-TV-Z]{26}'
}
IDS=$( { get_ids list-attachments; get_ids list-emojis; } | sort -u )

# sync media
FILTER=$(mktemp)
while IFS= read -r id; do printf '+ /%s/**\n' "$id"; done <<< "$IDS" >> "$FILTER"
printf -- '- **\n' >> "$FILTER"
MEDIA_OUT=$(rclone sync "$SRC" "$MEDIA_DST" --filter-from "$FILTER" --config "$CONF" 2>&1)
MEDIA_CODE=$?
rm -f "$FILTER"

每次备份完后，也可以用 Discord Webhook 发送提醒，防止备份失败自己不知道。

所以我在脚本中加上了：

YAML

WEBHOOK="https://discord.com/api/webhooks/.../..." 

notify() {  # $1=title $2=color $3=description
 local payload
 payload=$(jq -n --arg t "$1" --arg d "$3" --arg h "$(hostname)" --argjson c "$2" \
 '{embeds:[{title:$t, description:$d, color:$c, footer:{text:$h}, timestamp:(now|todate)}]}')
 curl -sf -H "Content-Type: application/json" -d "$payload" "$WEBHOOK" >/dev/null
}

NUM=$(printf '%s\n' "$IDS" | wc -l | tr -d ' ')
[ "$DB_OK" -eq 0 ] && DB_LINE="Database: success" || DB_LINE="Database: failed ($(printf '%s' "$DB_OUT" | tail -c 300))"
[ "$MEDIA_CODE" -eq 0 ] && MEDIA_LINE="Media: success (${NUM} local account directory/ies)" || MEDIA_LINE="Media: failed (exit $MEDIA_CODE)"

if [ "$DB_OK" -eq 0 ] && [ "$MEDIA_CODE" -eq 0 ]; then
 TITLE="GtS backup success"; COLOR=3066993
else
 TITLE="GtS backup failed"; COLOR=15158332
fi
TAIL=$(printf '%s' "$MEDIA_OUT" | tail -c 1000)
DESC=$(printf '%s\n%s\n```\n%s\n```' "$DB_LINE" "$MEDIA_LINE" "${TAIL:-（Media no output）}")
notify "$TITLE" "$COLOR" "$DESC"

好看好用的前端 Phanpy

Phanpy 的安装很懒人，因为它是纯静态的，可以直接下载 release 之后用 web server 反代，不过官方并不推荐这么做，推荐的做法是 custom build。

克隆仓库之后类似这样：

BASH

PHANPY_DEFAULT_INSTANCE=social.obsp.de \
 PHANPY_CLIENT_NAME="Observer's Space Social" \
	 PHANPY_WEBSITE="https://phanpy.obsp.de" 
 PHANPY_PRIVACY_POLICY_URL=https://social.obsp.de/about \
 npm run build

dist 文件夹里就会有我们想要的东西。

目前 Phanpy 还不支持实例白名单，所以我稍微修改了一下 src/pages/login.jsx，只能从一个特定实例登录。

给自己做一个 Garmin 表盘

Sun, 19 Apr 2026 21:52:58 +0200

这个天意表盘其实已经做好很久了，但一直没时间去优化，所以也很久没有开始写笔记。现在还存在的问题主要是（1） stroke 的图层在渲染的时候是没问题的，但是加载到我的手表上时候，秒针的图层会叠在中心圆点上，导致效果不美观；（2）只兼容支持彩显的手表。

一开始做的时候傻傻地手搓了半天指针式，效果总是不好，直到我发现 SDK 文件夹的 sample/Analog 里有指针式的模板，只要在此基础上稍作修改即可……

再加上 Garmin 官方的 Monkey C 教程和 API Docs, 似乎没有什么需要特别说的。

值得注意的是，表盘坐标轴的原点是左上角，x 轴的方向是从左到右递增，y 轴的方向是从上到下递增。在给手表加 Hashmark 和数字的时候，用作坐标的不是该元素的中心点而是最低点，所以我写了这么丑陋的东西出来：

C++

for (var i = 1; i <= 12; i++) {
 var angleDeg = (i % 12) * 30;
 var rad = angleDeg * Math.PI / 180.0;
 var radius=(width < height ? width : height) / 2 * 0.82;
 var x = width/2 + radius * Math.sin(rad);
 var y = height/2 - radius * Math.cos(rad) -32 ;

有朋友可能注意到了，我用了霞鹜文楷和 JetBrains Mono 作为中文和英数的字体。这部分我参考了这篇文章：How I wrote a watch face for my Garmin Fēnix 8+, FNT 格式的字体基本上就是把要的字全部摘出来转化为 PNG 格式，然后以 FNT 文件指示每个字分别在图片的什么地方，方便调用。在将 TTF 转化为 FNT 的时候需要用到 BMFont。BMFont 的教程网络上也有很多，此处就不再赘述了。有一点需要注意，Latin + Latin Supplement 的部分不需要想太多，直接全部勾上就可以；中文字符则比较麻烦，通常的做法是先创建一个文本文件，输入所有你需要的字符（比如我的是骄败哀胜兵必），以 UTF-8 with BOM 的格式保存后导入到 BMFont 中。在很多教程中建议的是 UTF-8，但我测试之后发现会乱码，如果你遇到差不多的问题，就在这两个格式之间来回切换，看哪个可用。

使用 GnuPG 在 Keyoxide 上验证自己的身份

Sat, 26 Jul 2025 20:57:44 +0800

前言

Keyoxide 类似于 Keybase.io，用于验证在线账户的身份同一性。

例如，在 Keyoxide.org 上搜索 contact@forgejo.org，你会看见 Forgejo 拥有 Mastodon 实例账户 @forgejo@floss.social, 域名 forgejo.org 和 Forgejo 实例账户 @forgejo@codeberg.org .

你也可以通过 OpenPGP 公钥指纹进行查询。例如，在 Keyoxide.org 上搜索我的指纹（可以在“联系”页面找到），你就能看到 Yuki 声明其拥有的 ActivityPub, Matrix, Forgejo 等账号，还有 obsp.de 这一域名。

每次进行查询时都会进行一次实时验证，验证成功的条目旁边会显示绿色的对钩。这保证了信息的及时更新。

目前 Keyoxide 采用两种身份验证系统，一种是 Ariadne Signature Profile，另一种则是已被广泛采用的 OpenPGP.

Keyoxide 是去中心化的，这不仅仅在于每个人都可以运行自己的 Keyoxide 实例，更在于 OpenPGP 采用了联邦式的信息系统。当你需要获取公钥时，你可以从大型的密钥服务器如 keys.openpgp.org 获取某电子邮件地址所对应的公钥，也可以和你的联系人进行点对点的公钥交换，还可以使用 WKD 获取公钥。

那么什么是 WKD 呢？WKD 的全称是 Web Key Directory，网络密钥目录，顾名思义，它是一种通过 HTTPS 请求网站的某一目录来获取密钥的方法。假如 Alice 的邮件地址是 alice@example.org, Bob 想要获取她的公钥，而他既不能在大型密钥服务器上搜索到有效的结果（因为 Alice 没有公开发布），直接向 Alice 询问又会浪费一定的时间等待她的回复。如果 example.org 具有对 WKD 的支持，那么 Bob 可以运行 gpg --locate-key alice@example.org 来获取她的公钥。这条命令实际上执行了以下的动作：

对 “alice” 这一字符串执行 WKD 哈希，得到哈希字符串 “kei1q4tipxxu1yj79k9kfukdhfy631xe”
- 你可以在终端运行 gpg-wks-client --print-wkd-hash alice@example.org 验证
将哈希字符串、域名 example.org 与 WKD 的通用格式结合，获得 WKD URL
- 它应该形如 https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/kei1q4tipxxu1yj79k9kfukdhfy631xe?l=alice
- 或者 https://example.org/.well-known/openpgpkey/example.org/hu/kei1q4tipxxu1yj79k9kfukdhfy631xe?l=alice
- 第一种，也就是 subdomain method URL，相比起第二种 direct method URL 更受 GnuPG 青睐
curl 这一 WKD URL 的内容
- 它没有经过 ASCII armor，而是 binary，所以是不可读的
gpg --import

你可能会发现，不同于在密钥服务器上进行的 --search-key 动作， GnuPG 不会提示你是否选择导入。这是因为发布在 WKD 上的密钥通常被认为是有效而可信的。如果 Alice 是域名 example.org 的所有者，只有她拥有对这一域名下目录的控制权，那么 WKD 发现的密钥可认为是 Alice 亲自发布的。如果 Alice只是 example.org 的用户，那么至少这一密钥是 Alice 的管理员发布的。

目前支持 WKD 的邮件提供商有 systemli.org, posteo.de, Proton, Mailfence 和 ForwardEmail 等，由于我用的 disroot.org 并没有 WKD 支持，所以你在 Keyoxide 上搜到的公钥会显示是 HKP 服务器的，而 Forgejo 为 forgejo.org 提供了 WKD 支持，Keyoxide 会显示这个公钥来自 WKD，你可以点击 WKD 链接进行查看。

如果你使用域名邮箱，你可以自己托管 WKD，如果你使用支持 WKD 的提供商的话，可以把子域名 openpgpkey CNAME 指向提供商的域名。如果提供商不支持的话你也可以直接 CNAME 到 wkd.keys.openpgp.org，这是 openpgp.org 提供的 WKD as a service 服务。

创建 Notation

假设：

你拥有一个域名 doma.in
你已经为你的电子邮件地址 you@doma.in 创建了一个公钥
你希望证明自己对这个域名的所有权

那么你需要做的事情很简单：

在公钥上创建一个注记：“我拥有 doma.in”
为域名添加一条 TXT 记录：“公钥指纹xxx说得对”（这一条记录可以选择性进行哈希）

聪明的你肯定已经发现了，这两条记录不是等价的。如果仅凭公钥上的注记，我们可以找到 doma.in，而通过 doma.in 上 TXT 记录里的指纹，我们是找不到公钥的。并且由于注记前后的指纹保持不变，你根本不知道公钥指纹xxx说了什么。我们不能也不需要从 doma.in 反推到 you@doma.in，这也就是为什么 TXT 记录可以用哈希值代替（至于为什么有人想要哈希，因为他们可能把公钥发布到了某个密钥服务器，在服务器上可以按指纹搜索反推到公钥）。

公钥上的注记在 Keyoxide 被称为 Identity Claim，这很好理解，它们是对身份所有权的声明。在声明所有权的同时，它会指示在该身份的哪里可以找到证明。被声明所有权的物品返回的记录被称为 Identity Proof，可以在诸如域名的 TXT 记录，git 实例的仓库或联邦宇宙账户的嘟文等出现。这些地方一定是只有账户所有者才能编辑的，比如你不能 claim 某 GitHub 账户的 proof 在一个不属于你 claim 的 username 下的 gist 里，道理很简单。

我们运行以下命令创建注记：

BASH

gpg --edit-key FINGERPRINT
list #列出这一指纹下的所有uid
uid N #选择你要编辑的uid
notation #添加新的注记
proof@ariadne.id=dns:doma.in?type=TXT #声明你拥有 doma.in，证据在它的 TXT 记录里
save

不同的在线身份拥有不同的 claim，你可以自行查看支持的 claim/proof 类型。总的来说 claim 都是 proof@ariadne.id=CLAIM 的格式。

创建 Proof

我们给 doma.in 加上 proof，创建一条 TXT 记录，格式是：

TEXT

openpgp4fpr: FINGERPRINT

TTL 多少都可以。

噢对，你可以用 argon2 或 bcrypt 进行哈希，保证一定程度的匿名性。Keyoxide 的文档里贴心地准备了一个哈希小工具, 直接把 openpgp4fpr: FINGERPRINT这一串输进去，然后把输出粘贴到 TXT 记录里。

现在，把你的密钥上传到 WKD 或 HKP 吧！不出意外，TTL 之内就能在 Keyoxide 搜索邮箱地址或者公钥指纹发现你声明自己拥有 doma.in 并显示验证成功了。

杂项

如果你不小心把 claim 写错的话（经常发生），重新进入 GnuPG 编辑身份的 notation 部分输入 -你写错的notation 可以删除这条 notation，如果你忘了自己写了哪些 notation，可以编辑身份的时候输入 showpref 查看。

我在大部分 proof 里使用了 argon2 哈希，不过 Matrix 用的是明文。用哈希值总是会显示验证失败，换了 bcrypt 也不行，不知道问题具体出在哪里，过段时间看看能不能复现。（更新：解决了，需要用 /plain 命令确保 Matrix 不会渲染字符串）不过影响不大，这个哈希没什么意义，除非你真的不希望只知道 proof 所在地的人发现你的 claim 所在地，并且你不会从其他渠道泄露这个联系…… 这个概率我觉得还挺小的。如果真是这种情况，最好不要 claim，会破坏你的匿名性。

Ariadne Signature Profile 的使用以及自己托管 Keyoxide 实例我还没试过，以后可能会再写一篇教程。Keyoxide 的官方文档强烈建议阅读，条理清晰，简单易懂。

本站注册服务现已开启邮件通知

Sat, 19 Jul 2025 23:51:31 +0800

Vikunja 重新开放注册，Vaultwarden, Wallos & Vikunja 的注册现在需要邮件验证。系统通知（不包括 Wallos 的自定义订阅到期通知）均会以 @noreply.obsp.de 邮件地址发送。

除了 Vaultwarden 外的服务均可使用注册时的电子邮件重设密码。

Enjoy~

本站推出新的剪贴板服务 PrivateBin

Sat, 19 Jul 2025 13:30:29 +0000

与 Microbin 比起来更加安全，所有内容在浏览器进行加密和解密，服务器对其一无所知。

服务地址：https://pb.obsp.de

由于服务器资源限制，本实例禁用上传文件功能。

电子邮件的“自动发现”

Fri, 18 Jul 2025 20:26:39 +0000

传统电子邮件客户端采用的自动发现通常通过查询域名 DNS 中特定的 SRV 记录来完成，这些 SRV 记录的标准格式如下：

TEXT

_submission._tcp SRV 0 1 587 mail.example.org.
_submissions._tcp SRV 0 1 465 mail.example.org.
_imap._tcp SRV 0 1 143 imap.example.org.
_imaps._tcp SRV 0 1 993 imap.example.org.
_pop3._tcp SRV 0 1 110 pop3.example.org.
_pop3s._tcp SRV 0 1 995 pop3.example.org.

其中 submission 和 submissions 对应的是 SMTP 服务器的 STARTTLS 和 SSL/TLS 链接，imap 和 imaps 对应 IMAP 服务器的非 TLS 连接和 SSL/TLS 连接，pop3 和 pop3s 对应 POP3 服务器的非 TLS 连接和 SSL/TLS 连接。

可以通过设置 SRV 记录的域名为 . 来明确表示该域名不支持某一特定协议的连接，并且可以通过设置 SRV 记录的优先级来向客户端传递自动配置时优先使用的协议。

Thunderbird 采用的 autoconfig 则是通过查询 https://autoconfig.example.org/mail/config-v1.1.xml?emailaddress=xxx@example.org ，返回配置的 XML 文件实现的。例如，在浏览器中访问 https://autoconfig.disroot.org/mail/config-v1.1.xml?emailaddress=example@disroot.org, 会返回如下记录：

XML

<!--
 autoconfig for Thunderbird as explained here:
 https://developer.mozilla.org/en/Thunderbird/Autoconfiguration#Configuration_server_at_ISP
 looking in path: http://autoconfig.disroot.org/mail/config-v1.1.xml 
-->
<clientConfig version="1.1">
<emailProvider id="disroot.org">
<domain>disroot.org</domain>
<displayName>disroot.org</displayName>
<displayShortName>disroot.org</displayShortName>
<incomingServer type="imap">
<hostname>disroot.org</hostname>
<port>993</port>
<socketType>SSL</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILLOCALPART%</username>
</incomingServer>
<outgoingServer type="smtp">
<hostname>disroot.org</hostname>
<port>465</port>
<socketType>TLS</socketType>
<authentication>password-cleartext</authentication>
<username>%EMAILLOCALPART%</username>
</outgoingServer>
</emailProvider>
</clientConfig>

如果你曾经使用 Migadu 提供的邮件托管服务，那么你可能会遵照 Migadu 的指引为你的域名添加如下一条 DNS 记录：

Type	Host(name)		Value (Destination)
CNAME	autoconfig	.example.org	autoconfig.migadu.com.

这条 DNS 记录是为了让你在使用自定义域名的时候让 Thunderbird 能够正确请求到位于 Migadu 网站上的 XML 记录。

Thunderbird 并不仅仅依靠 autoconfig 确定邮件服务器采用的配置。如果 autoconfig 发现失败，Thunderbird 会尝试 https://www.example.org/mozilla.xml 以及传统的 SRV 记录。Mozilla 的数据库中包含了大部分常用邮件域名的服务器配置，如果上述方法均失败，Thunderbird 会尝试从 Mozilla 服务器寻找配置。如果依然失败，Thunderbird 会开始启发式推测配置，依次尝试 imap.域名、pop.域名、pop3.域名、smtp.域名和 mail.域名，并为每个地址测试常见的 2-3 个端口。同时检查 SSL 是否可用，以及服务器在 CAPABILITIES 中声明的认证算法等信息。

新版的 Microsoft Outlook 能够使用特殊的 SRV 记录发现配置，格式为：

TEXT

_autodiscover._tcp SRV 0 1 443 autodiscover.example.org

虽然采用了 SRV 记录的格式，但 autodiscover 本质上是通过 http 请求完成的，因此大部分服务商会设置该记录的端口号为 443，这样 Outlook 就会直接请求 https://autodiscover.example.org/autodiscover/autodiscover.xml。

你也可以通过 CNAME 记录来实现这一点，例如 NameCrane 会建议用户添加这样一条 DNS 记录：

Type	Name/Host	Value
CNAME	autodiscover	eu1.workspace.org.

这样一来，Outlook 在请求 https://autodiscover.example.org/autodiscover/autodiscover.xml 时就会被重定向到 https://eu1.workspace.org/autodiscover/autodiscover.xml，不过需要注意的是，你会发现，在 curl 这一链接（需要使用用户名和密码登录）后并不会出现 XML 文本，而是出现这样的页面：

HTML

<html>
 <header>
 <title>Z-Push ActiveSync</title>
 </header>
 <body>
 <font face="verdana">
 <h2>Z-Push - Open Source ActiveSync</h2>
 <h3>GET not supported</h3> 
 <br><br>
 More information about Z-Push can be found at:<br>
 <a href="http://z-push.org/">Z-Push homepage</a><br>
 <a href="https://z-push.org/download/">Z-Push download page</a><br>
 <a href="https://github.com/Z-Hub/Z-Push/issues">Z-Push Bugtracker</a><br>
 <a href="https://github.com/Z-Hub/Z-Push/wiki">Z-Push Wiki</a> and <a href="https://github.com/Z-Hub/Z-Push/wiki/Roadmap">Roadmap</a><br>
 <br>
 All modifications to this sourcecode must be published and returned to the community.<br>
 Please see <a href="http://www.gnu.org/licenses/agpl-3.0.html">AGPLv3 License</a> for details.<br>
 </font face="verdana">
 </body>

这是因为 NameCrane 的服务器采用了 ActiveSync 协议的开源实现 Z-Push。ActiveSync 不支持采用 HTTP GET 方式直接获取记录，而是需要通过兼容的客户端获取。

这意味着 NameCrane 提供的 autodiscover 只有支持 ActiveSync 的客户端（例如 Outlook 和 emClient）才能用，而不包括普通的 IMAP/SMTP 等协议的自动发现。我在 Claws Mail 无法发现域名邮箱的配置，在 Thunderbird 上的发现我认为是通过启发式推测实现的，因为 Thunderbird 发现的邮件服务器配置是 mail.example.org 而不是 eu1.workspace.org. 为了保证能在 Thunderbird 上自动发现，NameCrane 会指导用户将 mail.example.org CNAME 指向 eu1.workspace.org 或 us1.workspace.org。

docker 部署 Ghost 博客，并自定义推送邮件服务（以 Resend 为例）

Sun, 29 Jun 2025 13:03:23 +0000

前言

Ghost 是一个美观、易用、可以自托管的开源博客平台。

与静态站点生成器（Hugo, Hexo, Jekyll, Astro, Nuxt 等）不同，Ghost 更像 WordPress 和 Typecho，需要独立的数据库，并且具有更为丰富的功能。Ghost 提供了一个管理后台，不仅可以实时保存博客文稿的写作进度，随时进行创作、编辑、发表，还能进行用户权限设置，为一个站点建立多个管理员及创作者用户。Ghost 集成了文章数据分析和触达读者的推送邮件服务，不需要单独设置定时任务或邮件内容。对于需要提供增值服务的博客，Ghost 内置的订阅功能可以识别用户的订阅状态，提供 “Subscriber Only” 的博文内容等，为专业的博客维护者提供了便利。著名的 Linux 入门博客 It’s FOSS 就是一个 Ghost 实例，如果你曾经订阅 It’s FOSS 的新闻邮件，或是注册账户在上面进行评论，那么你可能会注意到， It’s FOSS 提供了 $24 / 年的会员订阅，在登录时，会员不会在网站上看到广告。

由于 Ghost 的 docker 镜像是由社区开发者维护的，没有官方文档指导，我在安装的过程中遇到了一些波折，尤其是设置推送邮件服务。

安装和设置

我采用的是 docker 镜像维护者在文档中建议的 compose.yml，在此基础上进行了小小的改动：

YAML


services:

 ghost:
 image: ghost:5-alpine
 restart: always
 ports:
 - 127.0.0.1:2368:2368 # 改成你喜欢的端口
 environment:
 # see https://ghost.org/docs/config/#configuration-options
 database__client: mysql
 database__connection__host: db
 database__connection__user: root
 database__connection__password: ChangeItToASecretPassword
 database__connection__database: ghost
 # this url value is just an example, and is likely wrong for your environment!
 url: https://example.org
 # contrary to the default mentioned in the linked documentation, this image defaults to NODE_ENV=production (so development mode needs to be explicitly specified if desired)
 #NODE_ENV: development
 volumes:
 - ./ghost-content:/var/lib/ghost/content
 # 这里我改了映射路径，方便打包备份，
 # 如果你更喜欢 ghost:/var/lib/ghost/content 也可以自己改
 - ./config/config.production.json:/var/lib/ghost/config.production.json
 # 目的是配置邮件推送
 db:
 image: mariadb:10.6
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: ChangeItToASecretPassword 
 # 和上面那个 database__connection__password 要相同哦
 volumes:
 - ./db:/var/lib/mysql

volumes:
 ghost:
 db:

Ghost 自托管版默认通过 Mailgun 发送订阅邮件，可以直接在后台设置域名和 Mailgun API，这是唯一支持的服务提供商。当你使用 docker compose 安装并且没有指定 Mailgun 配置的时候，会尝试从本机以 noreply@example.org 的地址向注册用户和订阅者发送邮件。当然，如果服务器的 25 端口关闭，或域名没有配置合适的 spf dkim dmarc 记录，这封邮件很可能不会进入读者的收件箱。因此，我们需要编辑 docker 容器内的 /var/lib/ghost/config.production.json，让它使用合适的 SMTP 服务进行邮件推送。接下来我们会以 Resend 为例，进行配置。

先登录 Resend 后台，添加域名，这里我们使用 example.org .

添加 DNS 记录，看起来应该像是这样：

Type	Name	Content	TTL	Priority
MX	send	feedback-smtp.eu-west-1.amazonses.com	Auto	10
TXT	send	v=spf1 include:amazonses.com ~all	Auto
TXT	resend._domainkey	p=一长串字符	Auto
TXT	_dmarc	v=DMARC1; p=none;	Auto

当所有 DNS 记录验证完毕后，就可以选择 API Keys，获取 API 密钥了。你可以为每个用途单独创建一个 API 密钥，我们将刚刚创建的密钥命名为 Ghost，方便管理。

还记得刚刚我们映射出了配置文件吗？找到它，并且调整为如下的样子：

JSON

{
 "url": "http://localhost:2368",
 "server": {
 "port": 2368,
 "host": "0.0.0.0"
 },
 "mail": {
 "transport": "SMTP",
 "options": {
 "service": "Resend",
 "host": "smtp.resend.com",
 "port": 587,
 "secureConnection": true,
 "auth": {
 "user": "resend",
 "pass": "YourApiKey"
 }
 }
 },
 "logging": {
 "path": "content/logs/",
 "level": "error",
 "rotation": {
 "enabled": true,
 "count": 10,
 "period": "1d"
 },
 "transports": [
 "file",
 "stdout"
 ]
 },
 "process": "systemd",
 "paths": {
 "contentPath": "/var/lib/ghost/content"
 }
}

这样就大功告成了！所有的订阅邮件将通过 Resend 的 SMTP 服务器传送。由于你授权了该服务器使用 @example.org，产生的邮件将不会因为域名的 spf dkim dmarc 记录进入垃圾箱。

后记

Ghost 很美好，很便捷，也很惊艳——但是我最后还是选择了 Hexo，为什么呢？

我想，这大概和我的不安全感有关——免费 PaaS 和数据库不是很多，并且每次重启都会清空数据。虽然我买了服务器，自己搭建过 Typecho，设置了定时备份，但我还是害怕有一天会因为自己鲁莽的行为丢失博客的配置。我也害怕自己会有一天因为交不起几欧一个月的服务器费用，被迫将站点关停。而能免费托管静态站点的平台很多，Netlify, Statichost.eu, Codeberg Pages, SourceHut Pages… 数据的存储也无须过于担心，使用 GitHub 或 GitLab 仓库存储所有的站点内容，搬家也很轻松。

更重要的是，我更欣赏静态站点生成器的轻量和自由——可以接入 Giscus 等外部评论区，不强制读者在站点上注册才能进行评论；可以直接撰写 Markdown 格式的博文，导入和导出更加方便。阻碍我转向 Ghost 的一大原因正是我无法通过后台进行 Markdown 文章的导入，官方只提供了对 WordPress，Medium 等平台的支持，我试图通过魔改 Jekyll 迁移插件实现支持 Hexo 的效果未果。由于实在太麻烦，在经历了五秒的思想斗争后，我放弃了逐项导入所有博文的想法，决定 docker compose down 逃之夭夭。

还有，Ghost 的核心功能——会员制度，对我来说确实没什么用。我不关心博文的变现和推广，目标只有一个：当潜在读者使用搜索引擎敲下问题时，他们可能在这里找到答案。

在局域网设备上搭建 OpenCloud.eu 实例

Thu, 26 Jun 2025 15:00:15 +0000

前言

OpenCloud 是自建云存储解决方案中的新秀，类似于 NextCloud 和 ownCloud，但更加轻量化、现代化，强调安全、简洁、数字主权与团队合作，由 mailbox.org 的母公司 Heinlein Support 旗下团队研发。

由于 OpenCloud 是 2025 年 1 月新推出的产品，因此应用市场中可选的插件暂时很少。

今天我们介绍如何通过 docker compose 在局域网设备上搭建一个 OpenCloud 实例，并通过 Traefik 反代实现局域网域名访问。

在进行安装前，请确保 OpenCloud 将会运行的机器上安装着任意 Linux 发行版或 MacOS 或 WSL，已经安装 git 和 docker compose，并且至少有 1 GHz 单核 CPU 和 512 MB 内存。具体的配置可以参考官方文档。

安装步骤

OpenCloud 大大简化了局域网中 Collabora Office 实例与云盘连接的配置。由于 Collabora Office 需要 https 连接，那么你需要自行进行局域网域名的自签名 SSL 证书设置。当然，你也可以关闭强制 https，但 Collabora Office 依然强制要求每一段连接中的协议一致，也就是说，必须全程使用 http 或 https。如果你曾经在局域网中安装 NextCloud 和 Collabora Office 并且只使用 <ip>:<port> 连接，那么你就会发现，当使用 Cloudflare Tunnel 的时候，由于浏览器客户端到 CF 边缘服务器是 https，而容器内部是 http，你将无法编辑 NextCloud 中的文档。OpenCloud 的懒人版配置文件自动为 Collabora 和 OpenCloud 分配了局域网域名并且生成了证书，你只需在访问的客户端中为这些域名指定 ip 地址并手动信任证书即可。

在安装之前，确保你的机器上没有运行 Apache, Nginx 或 Caddy 等网络服务器监听 80 和 443 端口。然而，这并不意味着你需要停止正在运行的网络服务器——例如，如果你使用 Caddy 和 Tailscale 进行局域网域名访问，并且希望继续将 OpenCloud 实例通过现有的网络服务器反代，那么你需要注释掉配置文档中关于 Traefik 的部分，并修改默认配置中的域名，最后需要生成自签名证书。由于我没有进行尝试，无法提供准确的配置文件参考，未来可能会补上。

克隆项目仓库（国内的机器请自备镜像）：

BASH

git clone https://github.com/opencloud-eu/opencloud.git

进入 compose 目录：

BASH

cd opencloud/deployments/examples/opencloud_full

Docker，启动！

BASH

docker compose up -d

接下来我们需要在客户端机器的 /etc/hosts 文件中添加：

PLAINTEXT

192.168.128.28 cloud.opencloud.test
# ip 地址改成 OpenCloud 宿主机的局域网 ip
192.168.128.28 collabora.opencloud.test
# 如果是本机就改成 127.0.0.1
192.168.128.28 wopiserver.opencloud.test
# 读到这里你是不是想问
# 那手机 (Android, iOS) 怎么办
# 呃……我也不知道

在浏览器访问 https://collabora.opencloud.test, 会提示有安全风险，因为证书是自签名的。选择接受风险并继续即可。如果能看到 OK 字样，说明 Collabora Office 服务器正常运行。

此时可以访问 https://cloud.opencloud.test, 接受证书后使用用户名和密码均为 admin 登录，即可享受 OpenCloud 啦！

Btw，插件市场没有日历和任务应用，我去看了下官方文档，OpenCloud 的 CalDAV 和 CardDAV 功能是通过 Radicale 实现的，在配置文档中取消注释这一部分即可。如果你看过 Observer’s Space 之前的详细版 Radicale 设置教程, 就不需要依赖自动配置了，可以自己动手丰衣足食！

OpenCloud 的文件浏览界面如图，我挺喜欢这个 UI 的：

在 EndeavourOS 上使用 KDE Connect

Fri, 20 Jun 2025 12:22:38 +0000

如果你使用默认设置安装 EndeavourOS，那么在使用 KDE Connect 时就会发现无法寻找到局域网中的其它设备。

不必担心，这是默认的防火墙设置导致的。

右键点击任务栏的防火墙图标，选择“编辑防火墙设置”，如图所示。

在当前网络使用的策略组中勾选 “KDE Connect”.

返回 KDE Connect 设置，刷新设备列表，此时你应该能够看到局域网中的设备。

重要迁移通知

Sun, 08 Jun 2025 17:16:38 +0000

经过3个月的测试期，本站正式由 Typecho 搬迁到 Hexo。

原 Hexo 镜像站域名 hexo.obsp.de 会重定向到 obsp.de，在6个月至1年（视访问量而定）后停用。

由于使用 Giscus 作为评论区，杜绝了游客匿名评论，本站有望大幅减少爬虫机器人在评论区出没的情况。

由于 Typecho 的永久链接目录中包含 index.php，站长暂时没有找到让链接维持原样的方法。之后站长会尽可能地更新发布在各大平台上的文章链接，确保能够正确跳转。

在 Virtual Box 中安装 Windows 11 虚拟机

Thu, 15 May 2025 15:55:20 +0000

d大家好，今天分享一下在 Arch Linux (EndeavourOS) 上使用 Virtual Box 启动 Windows 11 家庭版虚拟机的过程。

下载 iso

我们可以在这里的页面下拉，找到 “Download Windows 11 Disk Image (ISO) for x64 devices”, 按照指引操作即可。

配置虚拟机

打开 Virtual Box，选择 “新建”
输入虚拟机名称
在“虚拟光盘”处选择之前下载的 ISO 文件
“类型”选择“Microsoft Windows”
“版本”选择“Windows 11（64-bit）”
勾选“跳过自动安装”
- 接下来我们需要进行一些手动操作
分配CPU、RAM和硬盘，满足这里的要求即可
确认创建虚拟机
在虚拟机的“设置-主板”中，取消勾选 EFI 和 Secure Boot
- 这是因为当启用 Secure Boot 和 EFI 的时候，无法从光驱启动，会造成启动失败
- 但是 Windows 11 安装程序的系统监测程序会检查 UEFI 和 Secure Boot 的可用性，如果无法通过检查，安装程序就会终止
- 我们稍后再来解决这个问题
在虚拟机的“设置-处理器”中，勾选“启用PAE/NX”
启动！

开始安装

选择键盘配置和地区
勾选“在这台电脑上安装 Windows 11”
此时不要选择版本或输入产品密钥
使用虚拟机软键盘键入“Shift+F10”
执行命令 regedit 打开注册表
导航到目录：HKEY_LOCAL_MACHINE -> SYSTEM -> Setup
在 Setup 下新建一项，命名为 LabConfig
添加四个 DWORD 值，名称分别为 BypassTPMCheck， BypassRAMCheck ， BypassCPUCheck 和 BypassSecureBootCheck，均赋值为1，用来绕过监测程序对 TPM 2.0，处理器、内存和 Secure Boot 的检查
退出注册表和命令行
输入 Windows 11 产品密钥，或选择版本
划分硬盘区域
按照指引完成 Windows 11 安装

完成安装

在基本设置完成和第一次启动后，关闭电源，将启动顺序调整为硬盘优先。

moto g53刷入Evolution X

Tue, 06 May 2025 17:47:44 +0000

前言

解锁有风险，刷机需谨慎！学习不认真，变砖两行泪！！！

找 ROM

moto 自带的系统不太好用，所以就要找个合适的 rom。不幸的是，moto g53 这个机型，代号penang，即使全球发售，在各大类原生OS（LineageOS，CalyXOS，DivestOS，crDroid等）的官网上也都找不到rom，更不要说吃上国内的Flyme和澎湃修改版了。

经过在互联网上坚持不懈地沙里淘金，我终于在 xda 找到了一个帖子，楼主搜罗了一些 penang可以用的 rom，其中包括 EvolutionX，Matrixx，LineageOS 和 project2by2，只有 project2by2是来自官方的。LineageOS 的刷机包是个半成品，不能用本文所说方法刷入；Matrixx的包有问题，recovery 刷入之后会无限重启。最后我就决定先刷下载得最快（hhh）的Evolution X，再刷2by2（2by2基于LineageOS）。

Evolution X 这个系统的主要特点是“让所有手机都能获得 pixel 一样的体验”，尽可能在其他厂商的产品上还原 PixelOS 的功能。在提供各种个性化选项的同时，还提供对谷歌应用伪装成 Pixel 8 Pro 和对谷歌相册伪装成 Pixel XL（解锁无限云端备份相片）的功能。但是由于没吃过猪肉，我也不知道到底多像 Pixel，再加上我本身是一个 degoogler，深入地使用g系软件只是为了狠狠地批判它，所以我对这个系统的评价难免有失偏颇。如果你是一个重视隐私/有 FOSS 情结的人，不要刷这个 rom，买个 pixel 刷 GrapheneOS 或者 LineageOS。

解 bootloader

前置条件

moto 手机解 bl 的方式比较直观，不需要过小米高考或者降级参加深度测试什么的，不过解bl的前提是在开发者选项里打开 oem unlock，这个选项对于某些新设备而言，需要等待一周左右才能开启。
找一条可以用于 USB 调试的数据线。
检查你的 PC 有没有 adb 和 fastboot 这两个命令。如果没有，从Google Android开发者下载Android Studio Ladybug，这一步需要魔法。
在你放 Android Studio 的那个文件夹里找到有 adb 和 fastboot 这两个文件的目录。不管在哪里，运行的时候记得在这两个文件存在的文件夹里运行。

开始解锁

在设置里找到“关于本机”，连续点击版本号 7 次，进入开发者模式
进入之后，打开“ USB 调试”
移除所有 Google 账号
关机，然后用 USB 数据线将设备连接到计算机
运行命令 adb -d reboot bootloader
验证设备可以被计算机识别，运行 fastboot devices
进入这个网址，拉到最下面，选择 “Proceed Anyway”
运行命令 fastboot oem get_unlock_data
将获得的输出（一般为五行以 (bootloader) 开头的字符串）拼接成连续的一串字符串
粘贴到网页中 “Paste the Device ID string into the field below to verify that your device is unlockable:” 下的空白处
根据指引完成确认和解锁

下载所需镜像

EvolutionX 的社区版 Penang 刷机包在 GitHub 可以下载，将 boot.img, dtbo.img , evolution_penang-ota-uq1a.240105.004-01232132-COMMUNITY.zip 和 vendor_boot.img 都下载下来。

开始刷机

关机状态下，长按音量下键和电源键，进入 bl
运行 fastboot flash dtbo dtbo.img
运行 fastboot flash vendor_boot vendor_boot.img
运行 fastboot flash boot boot.img
在设备上选择 “Recovery”
进入 Recovery 后，选择 “Apply Update”
选择 “Apply from ADB”
返回计算机，运行 adb -d sideload evolution_penang-ota-uq1a.240105.004-01232132-COMMUNITY.zip
侧载过程中可能会出现计算机上的进度条卡在 47% 的情况，不用着急，如果手机提示已经完成侧载，可以重启，那么就选择 “Advanced”，然后选择 “Reboot to Recovery”
进入 Recovery 后，选择 “Factory Reset”，然后选择 “Format data / factory reset”，确认
再次用上面的方法进行侧载，“Apply Update” -> “Apply from ADB” -> 运行 adb -d sideload evolution_penang-ota-uq1a.240105.004-01232132-COMMUNITY.zip，继续在卡 47% 后查看手机提示
选择 “Reboot system now”
如果你能够看见 EvolutionX 的 Logo，恭喜你，大功告成！
Enjoy~

EndeavourOS 日用初探以及 Nvidia GPU 驱动安装

Mon, 21 Apr 2025 16:22:03 +0000

前言

一个月前在我的不懈折腾下终于装上了 N 卡驱动开始快乐工作的 Manjaro，还没来得及承担打游戏和跑 LLM 的光荣任务就莫名其妙地壮烈牺牲了，具体体现在系统内选择关机之后有时无法正常进入关机状态，会冒出一堆内含关键词 nvidia 的报错并陷入循环，且风扇开始疯狂地呼呼作响。时间一长，渐渐地连开机都出了问题，经常会启动失败。于是一个念头逐渐在我脑海中成型：要不重装一下吧……

Manjaro 作为 Arch 衍生物中的日用之王，带来的负面体验很少， N 卡的问题算是其中之一，不过这不是 Manjaro 的问题。

热爱折腾的我，这次将目光转向了好评如潮的新秀 EndeavourOS。

缺点

先说缺点：

EndeavourOS 对于有魔法需求的国内用户不是很友好，当使用 Clash Verge Rev 之类的工具时，大部分的应用都会绕过代理，只能通过开 TUN 模式解决。
遇到一些不知道是（EndeavourOS 的问题）还是（KDE 的问题）还是（Wayland 的问题）的问题，
- 某网盘软件 AppImage 版本上传和下载的按钮没有反应，而 Manjaro + GNOME + X11 不会，由于无法控制变量，此处暂时没有定论
- Minecraft Launcher 每次开机后只能成功启动一次，此后再启动就会提示错误，必须重启计算机，我没有在任何其他发行版上用过 Minecraft Launcher，此处暂时没有定论
- kmail 会开启后闪退
- KDE Connect 一直找不到我的移动设备，排查确定两台设备接入了同一局域网而且能互相通信，不太清楚问题所在
- CUPS 不能像在 Manjaro 那样自动发现局域网的打印机，不过输入 socket://hostname:9100 就好了

优点，N 卡用户请看

剩下的都是优点：

如果你用的是新的 Nvidia 显卡，那么 EndeavourOS 绝对是 Arch 衍生物中不得不品的一环
- EndeavourOS ISO 镜像的 boot 引导中可以选择普通还是 N 卡设备，一般来说在这一步选择 N 卡设备，boot 进去后 install，后续就不需要再考虑驱动的问题了
- 但是我在这一步没能 boot 成功，报错的内容忘记记下来了（……）最后选择的是普通版
- 如果是这样的话也没关系，EndeavourOS 的开发者们维护的 AUR 仓库 endeavouros 中有一个非常便捷的命令——nvidia-inst，功能和使用指南可以参考官方文章和社区问答，使用它安装 Nvidia 驱动仅需 2 步：
  - yay -S nvidia-inst
  - nvidia-inst
- 如果你使用的是其他 Arch 衍生物发行版，只需按照上文中的社区问答添加 endeavouros 仓库和镜像即可
- 如果你用的是不再受 Nvidia 官方 Arch 仓库驱动支持的旧版显卡，在命令中加入 --nouveau 或 -n
- 如果你需要 Bumbleweed，在命令中加入 -b
EndeavourOS 自带镜像选择器 reflector 的 GUI，名叫 Reflector Simple，直接勾选国家或地区即可将该地区的推荐镜像源添加到镜像列表，也可以在 GUI 上选择按照速率/延迟等指标排序镜像
开发者的审美不错，
- 默认的黑暗紫色主题 KDE 和 Xfce 桌面都很漂亮
- 预装的应用不多也不少，不像 Manjaro 那样大而全（自带相当于 pacman+AUR+flatpak GUI 的应用商店这种~~邪恶的~~东西 www），也不像原味 Arch 一样只有骨架，可以说是简约主义和日用功能的完美平衡

后记

如果你和我一样，对技术一窍不通，只因 AUR 的魔力使用 Arch 的话，或者你希望在 Linux 上充分发挥 Nvidia GPU 的性能的话，EndeavourOS 非常值得一试。

最后还是要说一些和 EndeavourOS 或者我的 PC 硬件没有太大关系的碎碎念，本应另开一文，但是以下经验也算是日用体验的一部分吧！

Rime

Rime 在 KDE + X11 下的配置应该是这样的，在设置-虚拟键盘中选择 fcitx5，输入法中选择中州韵，在 /etc/environment 键入：

SHELL

XMODIFIERS=@im=fcitx 
INPUT_METHOD=fcitx 
SDL_IM_MODULE=fcitx 
GLFW_IM_MODULE=fcitx 
QT_IM_MODULE=fcitx 
GTK_IM_MODULE=fcitx

那这个时候就有小伙伴发现，如果使用的是 Wayland，fcitx 5 启动时会提示你删除 QT_IM_MODULE 和 GTK_IM_MODULE 这两行。

删除之后没有问题的话可以直接跳过这一部分，不过我在日用的时候发现，如果去掉这两行，时不时会产生丢字母的问题。具体表现为尝试输入拼音 ceshi ，只有 cshi 被保留在输入法候选框中，而 e 作为单独的字符掉落下来，键入到文本框中。这个问题说大不大说小不小，打一个完整的句子时非常烦人。即使在虚拟键盘下启用 fcitx 5 Wayland 启动器，也解决不了这个问题。

有一天我灵机一动，加上了 QT_IM_MODULE 和 GTK_IM_MODULE 这两行，然后这个问题就再也没有出现过……

OnlyOffice

这个问题是 N 卡和窗口系统的相性导致的。

问题描述：在使用 X11 窗口系统的时候，安装 N 卡驱动之后，OnlyOffice 的显示比例会变得特别大，参照这个 Issue。有时候随着 OnlyOffice 的版本更新，这个问题会自行消失，不过我最近还是遇到了。

换用 Wayland 就好了。

2025-6-9 更新：双显卡配置，Steam 游戏启动选项

先贴我的系统信息，一个英伟达独显，一个 AMD Radeon 集显：

TEXT

Operating System: EndeavourOS 
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.1
Kernel Version: 6.14.10-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7735H with Radeon Graphics
Memory: 38.4 GiB of RAM
Graphics Processor 1: NVIDIA GeForce RTX 4060 Laptop GPU
Graphics Processor 2: AMD Radeon 680M
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ASUS TUF Gaming A15 FA507NV_FA507NV
System Version: 1.0

我在运行 nvidia-inst 后又运行了 paru -S mesa lib32-mesa xf86-video-amdgpu vulkan-radeon lib32-vulkan-radeon libva-mesa-driver lib32-libva-mesa-driver mesa-vdpau lib32-mesa-vdpau ，然后就可以愉快食用了（如果不装集显的驱动就会两个卡槽都用 N 卡的 OpenGL，显示在系统信息里的会是两个英伟达 GPU）。

为什么突然现在更新呢，因为我把集显的事彻底忘在了脑后，我天真地以为只要假装集显不存在就好了。直到用 Steam 和 Proton 启动 2077 的时候一直报错（如图所示），但是正确安装驱动的情况下应该是不会有这个 OpenGL 的问题的，再加上 ProtonDB 上评级为 Native 和 Platinum 的红弦俱乐部和逆转裁判123在启动时黑屏，我不由得开始怀疑是不是自己的显卡驱动真的有问题。

在这个报错之前我完全没怀疑是显卡的问题，试了很多种启动参数都没能玩上游戏，但是这个关键的错误启发了我：2077 可能在尝试使用我的集成显卡……

于是，我在启动参数中强制游戏使用独显：_NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia %command%，问题迎刃而解。

最后我就去把集显驱动装上了……就是这样……

参考文献：PRIME

docker 自建 Ntfy 实例以及提醒功能（接入 Uptime Kuma，Wallos 等）实战

Thu, 10 Apr 2025 12:27:54 +0000

前言

大家好，两个星期没更新了，~~想必根本没有人想我罢~~

今天我们来搭建一个 Ntfy 实例，照例还是使用非常方便的 docker compose。

Ntfy 的工作原理非常简单，以官方实例 ntfy.sh 为例，这个实例是没有密码保护的，当用户在订阅任意的主题（通常是 https://ntfy.sh/themename 的格式）时，任何发送到这个主题的通知信息都会被用户获取。因此，一些使用 Ntfy 官方实例进行通知推送的软件（如 Fluffychat）会自动生成一串随机字符，防止其他用户不慎和你订阅了同一个主题而获取你的通知信息。然而，使用诸如官方实例或是 tchncs.de 的 ntfy 实例这样的实例终究会因为主题的开放而存在一定的隐私或安全风险，更多的小伙伴还是希望能够用密码保护通知内容。那么今天我们就来一起看看如何搭建和管理自己的 Ntfy 实例吧！

部署过程

Ntfy 支持多种部署方式，并且有详尽的官方文档，感兴趣的读者可以自行查阅。

直接上 compose.yml ：

YAML

services: 

 ntfy: 

 image: binwiederhier/ntfy 

 restart: unless-stopped 

 container_name: ntfy 

 environment: 

 NTFY_BASE_URL: https://ntfy.example.org 

 NTFY_CACHE_FILE: /var/lib/ntfy/cache.db 

 NTFY_AUTH_FILE: /var/lib/ntfy/auth.db 

 NTFY_AUTH_DEFAULT_ACCESS: deny-all 

 NTFY_BEHIND_PROXY: true 

 NTFY_ATTACHMENT_CACHE_DIR: /var/lib/ntfy/attachments 

 NTFY_ENABLE_LOGIN: true

 volumes: 
 - ./:/var/lib/ntfy 

 ports: 
 - 127.0.0.1:8080:80 

 command: serve

这样子，一个具有访问控制功能的 Ntfy 实例就建成了。

请配置反向代理（Nginx, Caddy, Apache 等），将 https://ntfy.example.org 反代到 localhost:8080。如果一切顺利，访问 https://ntfy.example.org 即可看到 Ntfy 网页客户端的界面！

此时，默认对所有主题的控制策略都是 deny ，我们需要创建用户，并且为它们分配可以读或写某些主题的权限。

当没有进行容器化安装时，用户的创建和管理都是通过 ntfy 命令来完成，而可执行的 ntfy 位于 docker 容器内部，此时需要指明 ntfy 所在的容器名称。由于我们在 compose.yml 中进行了命名：container_name: ntfy ，故该容器的名称应为 ntfy 。

创建用户的命令如下：

BASH

# 创建管理员，可以访问所有的主题。adminname改成你想要的管理员用户名
docker exec -it ntfy ntfy user add --role=admin adminname

# 创建普通用户，默认无法访问任何主题。username改成你想要的用户名
docker exec -it ntfy ntfy user add --role=user username

# 修改用户的访问权限，格式如下
docker exec -it ntfy ntfy access <username> <theme> <read-write/read-only/write-only/deny>

比如说，Alice 希望自己能够获取所有主题的通知，那么就执行 docker exec -it ntfy ntfy user add --role=admin alice ，根据提示输入密码。

Alice 运行着一个 Uptime Kuma 实例，她希望在服务不可用的时候收到 Uptime Kuma 向主题 uptime 的推送通知，但是又不希望 Uptime Kuma 获取到其他主题的推送通知，于是她为此创建了一个普通用户：docker exec -it ntfy ntfy user add --role=user uptimekuma , 根据提示输入密码，然后给予对应的权限： docker exec -it ntfy ntfy access uptimekuma uptime read-write 。完成之后，在 Uptime Kuma 中填写用户名 uptimekuma 、密码、实例网址和主题名称 https://ntfy.example.org/uptime 即可。

实用案例

能够使用 Ntfy 进行推送通知的应用还有很多，如哪吒探针和 Wallos 等。我们也可以通过编写自动化脚本，在任务触发或状态改变的时候订阅了某个主题的客户端发送消息。

例如，前段时间我让 Claude 写了个脚本，当有进程对 CPU 的占用超过10%的时候，就把进程的名称以及占用情况输出到一个文件中，并且将进程停止，报告到我的 ntfy 实例的一个特定主题。

脚本内容如下：

BASH

#!/bin/bash

# 设置变量
LOG_FILE="cpu_limit.log"
NTFY_URL="https://ntfy.example.io/xxxxxx"
NTFY_USER="xxx"
NTFY_PASS="xxx"
CPU_THRESHOLD=10

# 创建日志文件或清空现有文件
> $LOG_FILE

echo "$(date): 开始监控 CPU 使用率..." >> $LOG_FILE

# 持续监控进程
while true; do
 # 获取 CPU 使用率超过阈值的进程列表
 processes=$(ps aux | awk -v threshold=$CPU_THRESHOLD '$3 > threshold {print $2, $3, $11}')
 
 if [ -n "$processes" ]; then
 echo "$(date): 发现 CPU 使用率超过 ${CPU_THRESHOLD}% 的进程:" >> $LOG_FILE
 
 # 遍历每个超过阈值的进程
 echo "$processes" | while read pid cpu_usage process_name; do
 echo " PID: $pid, 名称: $process_name, CPU使用率: ${cpu_usage}%" >> $LOG_FILE
 
 # 停止进程
 kill $pid
 kill_status=$?
 
 if [ $kill_status -eq 0 ]; then
 echo " 已停止进程 $pid ($process_name)" >> $LOG_FILE
 
 # 发送通知到 ntfy
 curl -u "$NTFY_USER:$NTFY_PASS" -H "Title: CPU 限制触发" \
 -d "进程 $process_name (PID: $pid) 的 CPU 使用率达到 ${cpu_usage}%，已被停止。" \
 $NTFY_URL
 else
 echo " 无法停止进程 $pid ($process_name)" >> $LOG_FILE
 fi
 done
 fi
 
 # 暂停 5 秒后再次检查
 sleep 5
done

亲测有效~

自建MinIO配合Cloudflare Tunnel穿透排障

Mon, 07 Apr 2025 16:12:40 +0000

大家好，今天分享一下使用家里云自建 MinIO 配合 CF Tunnel 内网穿透时遇到的问题以及解决方案。

主要的问题有三个：

如何使用 docker compose 的方式搭建 MinIO ？
第一次登录的时候，为何显示 Invalid credentials ？
为什么无法在 rclone 中使用端点域名连接，只能采用 ip:port 连接？

使用 docker compose 搭建 MinIO

对于一般的用户，我们的 compose.yml 应该是像这样的：

YAML

services:
 minio:
 image: minio/minio
 command: server --console-address ":9001" --address ":9000" /data
 environment:
 MINIO_ROOT_USER: myrootuser
 MINIO_ROOT_PASSWORD: myrootpassword
 # MINIO_SERVER_URL: "https://minio.yourdomain.com" 
 # 这个变量值的指定与否，会影响你是否能成功登录。我们先不指定
 
 volumes:
 - minio-data:/data
 ports:
 - "9000:9000" # API 端口
 - "9001:9001" # 控制台端口
 healthcheck:
 test: ["CMD", "curl", "-f", "https://localhost:9000/minio/health/live"]
 interval: 30s
 timeout: 20s
 retries: 3

volumes:
 minio-data:

然后运行 docker compose up -d 即可。国内的主机记得提前设置好速度快的 docker 镜像源。

内网穿透和首次登录出错

我们在 CF 准备好两个子域名，一个是 minio.yourdomain.com ，另一个是 console.yourdomain.com 。顾名思义，前者是用于 API 端点的，而后者是用于控制台的。

进入 Zero Trust 的 Network -> Tunnels，在这里你可以看到已经配置好内网穿透的家里云主机（内网穿透的教程看我之前的文章）。将 minio.yourdomain.com 指向 http://localhost:9000 , console.yourdomain.com 指向 http://localhost:9001，不出意外的话，打开 https://console.yourdomain.com 即可成功用 compose.yml 中设置的 root 用户名和密码登录控制台创建存储桶了。

但是有一些朋友可能会发现，即使自己使用了完全正确的 root 用户名和密码，MinIO 控制台依然提示 Invalid credentials 。这是为什么呢？

就我个人的经验而言，这是因为在 compose.yml 中配置了 MINIO_SERVER_URL: "https://minio.yourdomain.com" 这一变量，而又没有为 MinIO 容器配置 SSL 证书，导致访问者到 Cloudflare 再到控制台这一段使用的是 https 协议，MinIO 内部（控制台到端点）使用的却是 http 协议。由于 MinIO 预期的是全程 https，所以连接会被拒绝。

解决的方法也很简单，首先生成一个自签名证书，假设放在 ./minio/certs ：

BASH

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/private.key -out ./certs/public.crt -subj "/CN=minio.yourdomain.com"

然后修改 compose.yml，让证书进入容器：

YAML

services:
 minio:
 image: minio/minio
 command: server --certs-dir /certs /data
 environment:
 MINIO_ROOT_USER: myrootuser
 MINIO_ROOT_PASSWORD: myrootpassword
 MINIO_SERVER_URL: "https://minio.yourdomain.com"
 volumes:
 - minio-data:/data
 - ./minio/certs:/certs  # 挂载证书目录
 ports:
 - "9000:9000" # API 端口
 - "9001:9001" # 控制台端口
 healthcheck:
 test: ["CMD", "curl", "-f", "https://localhost:9000/minio/health/live"]
 interval: 30s
 timeout: 20s
 retries: 3

volumes:
 minio-data:

这样应该就没问题了。

不过，这个问题可能的成因不止一个（比如这个），以上只是其中之一。

反代端点加 rclone 无法战胜？

提要：是的，确实无法战胜！

我在使用具有公网 ip 的服务器自建 MinIO 并且用 Caddy 反代端点的时候，会出现莫名其妙的 rclone 连接问题，具体表现为：使用同样的一对 Access Key 和 Secret Key，正确进行了 rclone 配置，唯一的变量是连接的端点填写的是 http://ip:port 或 https://minio.yourdomain.com 。使用前者可以成功连接，而后者不可以。

rclone 配置如下：

TEXT

rclone v1.69.1

- os/version: arch 25.0.0 (64 bit)

- os/kernel: 6.12.19-1-MANJARO (x86_64)

- os/type: linux

- os/arch: amd64

- go/version: go1.24.0

- go/linking: static

- go/tags: none

.config/rclone/rclone.conf：

[minio] 
type = s3 

provider = Minio 

access_key_id = xxx 

secret_access_key = xxxx 

region = us-east-1 

endpoint = https://minio.example.dev 

disable_http2 = true 

force_path_style = true 

v4_auth = true 

no_check_certificate = true 

no_system_metadata = true

“无法连接” 在我这里的表现是这样的：

BASH

[yuki@manjaro ~]$ rclone ls minio: -vv

2025/04/02 22:11:34 DEBUG : rclone: Version "v1.69.1" starting with parameters ["rclone" "ls" "minio:" "-vv"]
2025/04/02 22:11:34 DEBUG : Creating backend with remote "minio:"
2025/04/02 22:11:34 DEBUG : Using config file from "/home/yuki/.config/rclone/rclone.conf"
2025/04/02 22:11:36 DEBUG : 5 go routines active
2025/04/02 22:11:36 NOTICE: Failed to ls: operation error S3: ListBuckets, https response error StatusCode: 403, RequestID: 183285C7252CB364, HostID: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.

起初，我看了一个类似的 GitHub Issue（对不起时间有点久找不到了，找到补上），是使用 Nginx 进行反代的，然后通过加特定的 headers 解决了问题。所以我想肯定是我的 Caddy 功夫还不过关，写的反代有问题导致的。但是在使用 CF 穿透的时候又一次遇到了这个问题，而这一次没有任何 web server 安装在家里云小主机上。

我对此百思不得其解，在电脑前折腾了整整一天一夜，终于……放弃了……

当我坐在马桶前沉思的时候，突然灵光乍现：有没有可能，这不是 MinIO 的问题，不是 Caddy 的问题，不是 CF 的问题，而是 rclone 的问题？

于是我立马使用 MinIO 官方的命令行工具 mc 使用一模一样的 Access Key 和 Secret Key 对，并且用 https://域名 作为端点。令我吃惊的是，这一次我可以成功进行 ls 操作了：

BASH

[yuki@manjaro ~]$ mc ls minio 
[2025-04-02 15:42:43 CST] 0B test/ 
[yuki@manjaro ~]$ mc ls minio/test 
[2025-04-02 16:40:17 CST] 33KiB STANDARD <picturename>.jpg

完全正确，没有出现 403 错误。

看来，我的 https 设置并没有问题，问题的确是出在 rclone 上。

在 Deepseek 和 Claude 的帮助下，我对比了两个工具的请求头（完整输出太长，只截取重要部分），已经把 troubleshooting 步骤发在 rclone forum：

运行 mc --debug ls one/test 得到的 headers：

BASH

X-Amz-Date: 20250402T142607Z 
Authorization: AWS4-HMAC-SHA256 Credential=<accesskey>/20250402/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=xxx

运行 rclone -vv --dump headers --dump auth ls minio: 得到的：

BASH

X-Amz-Date: 20250402T142710Z 
Authorization: AWS4-HMAC-SHA256 Credential=<accesskey>/20250402/us-east-1/s3/aws4_request, SignedHeaders=accept-encoding;amz-sdk-invocation-id;amz-sdk-request;host;x-amz-content-sha256;x-amz-date, Signature=xxx

可以看到 Authorization 稍有不同，这是因为 rclone 默认为所有 S3 兼容存储添加了以下 headers，而这并不是 MinIO 期望的: accept-encoding;amz-sdk-invocation-id;amz-sdk-request;。

类似的问题发生在 Exoscale 对象存储上。

Rclone uses the official AWS SDK so I’d guess that this is a bug in exoscale.

问题的原因找到了，解决的方法嘛，那就是……还没有。rclone 暂时没有提供在配置文件里修改请求头的方法（也可能有，但是我没有成功），所以只能先用其它工具了。

使用docker自建e2ee开源笔记软件Notesnook服务器

Thu, 03 Apr 2025 11:57:01 +0000

2025.04.11 更新：邮件发送地址可以通过在 .env 中指定 NOTESNOOK_SENDER_EMAIL 的值来确定，这样就解决了会使用 SMTP 登录名作为发件人地址的问题

前言

笔记软件的类型非常多，划分的标准也不尽相同。以笔记的主要存储位置为标准，既有注重云端的 Notion, OneNote 和 FlowUs 等，也有本地优先的 Obsidian, Logseq 和思源笔记等；以编辑器类型为标准，既有专注于纯文本 / 富文本 / Markdown 编辑的，也有八面玲珑，兼顾日历、任务、书签管理功能的；以加密程度为标准，既有注重隐私安全的，也有注重便捷分享的。当一个笔记软件找到自己的定位，获得了一些目标人群的认可时，也往往会顾此失彼，让另一些潜在客户悄悄流失。

例如，Obsidian 以强大的文本编辑能力、本地优先，无须网络或登录账户的快速便捷性和直接使用 .md 文档作为存储格式的开放性受到了用户的交口称赞，与此同时也因为同步的不便遭到了诟病；强调隐私保护的Standard Notes，因简洁的界面、开放源代码和经第三方审计的安全性在私人笔记市场受到欢迎，但与昂贵的订阅价格无法匹配的基础功能也令用户怨声载道。

不论如何，这些赫赫有名的笔记软件都拥有自己的独门绝技。在这个硬件产品逐渐同质化的时代，软件产品的差异化，能让市场更加百花齐放，满足不同客户的需求。

今天我们尝试部署的笔记软件 Notesnook 就是一个很好的例子。Notesnook 是由巴基斯坦的一个 3 人小公司 Streetwriters 开发的，在 2021 年发布了第一个版本，并在 2022 年以 GPL-3.0 许可证发布了服务端与客户端的源代码。同样以“端到端加密”的特性作为主打卖点，与拥有 8 年历史的 Standard Notes 相比，Notesnook 是一个年轻的竞争者。与 Standard Notes 较为稳健、保守的风格不同，Notesnook 广泛地听取用户意见，积极地引入各种新功能，而它比 Standard Notes 低许多的高级版定价以及相对慷慨的免费层服务吸引了不少 Standard Notes 的忠实用户。不少用户表示，“阻碍我转向 Notesnook 的唯一障碍就是不能自托管”。随着自托管进入 Alpha 阶段和服务端 Docker 镜像的发布，“不能自托管”的时代也已经结束了。尽管官方的完整版自托管文档尚未发布，但是已经有不少用户使用了 GitHub 仓库中的 Building From Source 或 docker compose 成功进行了部署。

我们使用 docker compose 进行简便部署，并且用 Caddy 进行反代。

前置条件

docker 和 docker compose
4 个域名或者子域名，下面用 notes.example.io, mono.example.io, events.example.io, auth.example.io 指代
Caddy V2

设置 compose.yml 与 .env

官方提供了一个开箱即用的 docker-compose.yml ：

wget https://raw.githubusercontent.com/streetwriters/notesnook-sync-server/master/docker-compose.yml

大部分内容我们都是不需要修改的：

YAML

x-server-discovery: &server-discovery
 NOTESNOOK_SERVER_PORT: 5264
 NOTESNOOK_SERVER_HOST: notesnook-server
 IDENTITY_SERVER_PORT: 8264
 IDENTITY_SERVER_HOST: identity-server
 SSE_SERVER_PORT: 7264
 SSE_SERVER_HOST: sse-server
 SELF_HOSTED: 1
 IDENTITY_SERVER_URL: ${AUTH_SERVER_PUBLIC_URL}
 NOTESNOOK_APP_HOST: ${NOTESNOOK_APP_PUBLIC_URL}

x-env-files: &env-files
 - .env

services:
 validate:
 image: vandot/alpine-bash
 entrypoint: /bin/bash
 env_file: *env-files
 command:
 - -c
 - |
 # List of required environment variables
 required_vars=(
 "INSTANCE_NAME"
 "NOTESNOOK_API_SECRET"
 "DISABLE_SIGNUPS"
 "SMTP_USERNAME"
 "SMTP_PASSWORD"
 "SMTP_HOST"
 "SMTP_PORT"
 "AUTH_SERVER_PUBLIC_URL"
 "NOTESNOOK_APP_PUBLIC_URL"
 "MONOGRAPH_PUBLIC_URL"
 "ATTACHMENTS_SERVER_PUBLIC_URL"
 )

 # Check each required environment variable
 for var in "$${required_vars[@]}"; do
 if [ -z "$${!var}" ]; then
 echo "Error: Required environment variable $$var is not set."
 exit 1
 fi
 done

 echo "All required environment variables are set."
 # Ensure the validate service runs first
 restart: "no"

 notesnook-db:
 image: mongo:7.0.12
 hostname: notesnook-db
 volumes:
 - dbdata:/data/db
 - dbdata:/data/configdb
 networks:
 - notesnook
 command: --replSet rs0 --bind_ip_all
 depends_on:
 validate:
 condition: service_completed_successfully
 healthcheck:
 test: echo 'db.runCommand("ping").ok' | mongosh mongodb://localhost:27017 --quiet
 interval: 40s
 timeout: 30s
 retries: 3
 start_period: 60s
 # the notesnook sync server requires transactions which only work
 # with a MongoDB replica set.
 # This job just runs `rs.initiate()` on our mongodb instance
 # upgrading it to a replica set. This is only required once but we running
 # it multiple times is no issue.
 initiate-rs0:
 image: mongo:7.0.12
 networks:
 - notesnook
 depends_on:
 - notesnook-db
 entrypoint: /bin/sh
 command:
 - -c
 - |
 mongosh mongodb://notesnook-db:27017 <<EOF
 rs.initiate();
 rs.status();
 EOF

 notesnook-s3:
 image: minio/minio:RELEASE.2024-07-29T22-14-52Z
 ports:
 - 9000:9000
 networks:
 - notesnook
 volumes:
 - s3data:/data/s3
 environment:
 MINIO_BROWSER: "on"
 depends_on:
 validate:
 condition: service_completed_successfully
 env_file: *env-files
 command: server /data/s3 --console-address :9090
 healthcheck:
 test: timeout 5s bash -c ':> /dev/tcp/127.0.0.1/9000' || exit 1
 interval: 40s
 timeout: 30s
 retries: 3
 start_period: 60s

 # There's no way to specify a default bucket in Minio so we have to
 # set it up ourselves.
 setup-s3:
 image: minio/mc:RELEASE.2024-07-26T13-08-44Z
 depends_on:
 - notesnook-s3
 networks:
 - notesnook
 entrypoint: /bin/bash
 env_file: *env-files
 command:
 - -c
 - |
 until mc alias set minio http://notesnook-s3:9000 ${MINIO_ROOT_USER:-minioadmin} ${MINIO_ROOT_PASSWORD:-minioadmin}; do
 sleep 1;
 done;
 mc mb minio/attachments -p

 identity-server:
 image: streetwriters/identity:latest
 ports:
 - 8264:8264
 networks:
 - notesnook
 env_file: *env-files
 depends_on:
 - notesnook-db
 healthcheck:
 test: wget --tries=1 -nv -q http://localhost:8264/health -O- || exit 1
 interval: 40s
 timeout: 30s
 retries: 3
 start_period: 60s
 environment:
 <<: *server-discovery
 MONGODB_CONNECTION_STRING: mongodb://notesnook-db:27017/identity?replSet=rs0
 MONGODB_DATABASE_NAME: identity

 notesnook-server:
 image: streetwriters/notesnook-sync:latest
 ports:
 - 5264:5264
 networks:
 - notesnook
 env_file: *env-files
 depends_on:
 - notesnook-s3
 - setup-s3
 - identity-server
 healthcheck:
 test: wget --tries=1 -nv -q http://localhost:5264/health -O- || exit 1
 interval: 40s
 timeout: 30s
 retries: 3
 start_period: 60s
 environment:
 <<: *server-discovery
 MONGODB_CONNECTION_STRING: mongodb://notesnook-db:27017/?replSet=rs0
 MONGODB_DATABASE_NAME: notesnook
 S3_INTERNAL_SERVICE_URL: "http://notesnook-s3:9000"
 S3_INTERNAL_BUCKET_NAME: "attachments"
 S3_ACCESS_KEY_ID: "${MINIO_ROOT_USER:-minioadmin}"
 S3_ACCESS_KEY: "${MINIO_ROOT_PASSWORD:-minioadmin}"
 S3_SERVICE_URL: "${ATTACHMENTS_SERVER_PUBLIC_URL}"
 S3_REGION: "us-east-1"
 S3_BUCKET_NAME: "attachments"

 sse-server:
 image: streetwriters/sse:latest
 ports:
 - 7264:7264
 env_file: *env-files
 depends_on:
 - identity-server
 - notesnook-server
 networks:
 - notesnook
 healthcheck:
 test: wget --tries=1 -nv -q http://localhost:7264/health -O- || exit 1
 interval: 40s
 timeout: 30s
 retries: 3
 start_period: 60s
 environment:
 <<: *server-discovery

 monograph-server:
 image: streetwriters/monograph:latest
 ports:
 - 6264:3000
 env_file: *env-files
 depends_on:
 - notesnook-server
 networks:
 - notesnook
 healthcheck:
 test: wget --tries=1 -nv -q http://localhost:3000/api/health -O- || exit 1
 interval: 40s
 timeout: 30s
 retries: 3
 start_period: 60s
 environment:
 <<: *server-discovery
 API_HOST: http://notesnook-server:5264
 PUBLIC_URL: ${MONOGRAPH_PUBLIC_URL}

 autoheal:
 image: willfarrell/autoheal:latest
 tty: true
 restart: always
 environment:
 - AUTOHEAL_INTERVAL=60
 - AUTOHEAL_START_PERIOD=300
 - AUTOHEAL_DEFAULT_STOP_TIMEOUT=10
 depends_on:
 validate:
 condition: service_completed_successfully
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
networks:
 notesnook:

volumes:
 dbdata:
 s3data:

在这个文件中，我们可以看到，Notesnook 服务器的必需组件包括：

Vandot
MongoDB
S3 存储，这里采用了自建 MinIO 实例的方式（应该和 Ente 一样，不是必须使用 MinIO，可以接入外部 S3，不过我没试过，这里先不演示）
身份验证服务器
同步服务器
SSE，用于提醒事件
Monograph，用于分享笔记的公开链接（可以加密）。

其中需要映射到的宿主机端口是 5264（同步服务器），6264（Monograph），7264（SSE）和 8264（身份服务器）。如果这些端口被占用，你可以选择映射到其他的端口。

我们需要进行个性化设置的是 .env 文件，官方同样提供了一个示例：

BASH

INSTANCE_NAME=self-hosted-notesnook-instance 
# 改成你的实例名称


NOTESNOOK_API_SECRET= 
# 随机生成一串 >32 位的长字符串


DISABLE_SIGNUPS=false
# 这个变量目前（2025年4月3日，v1.0-beta.1）还不能起效，
# 如果你需要禁用注册功能，请在自己注册完之后添加以下变量：
# DISABLE_ACCOUNT_CREATION=1


# SMTP 配置，用于接收 2FA 代码和重设密码，可以使用你自己的邮件提供商的 SMTP 配置


SMTP_USERNAME=
# 大部分情况下，是你的邮箱用户名，例如 user@example.org 
# 当 SMTP 用户名不是发件人地址的时候，加入下面的一行：
# NOTESNOOK_SENDER_EMAIL=

SMTP_PASSWORD=
# SMTP 密码，根据你的邮件提供商的指引设置

SMTP_HOST=
# 例如 smtp.gmail.com

SMTP_PORT=
# SMTP 端口，例如 465

TWILIO_ACCOUNT_SID=
# 不需要设置

TWILIO_AUTH_TOKEN=
# 不需要设置

TWILIO_SERVICE_SID=
# 不需要设置

NOTESNOOK_CORS_ORIGINS=
# 不需要设置

NOTESNOOK_APP_PUBLIC_URL=https://app.notesnook.com
# 换成你自己的 APP 域名，如 https://notes.example.io

MONOGRAPH_PUBLIC_URL=http://localhost:6264
# 换成你的 Monograph 域名，如 https://mono.example.io

AUTH_SERVER_PUBLIC_URL=http://localhost:8264
# 换成你的身份服务器域名 https://auth.example.io


ATTACHMENTS_SERVER_PUBLIC_URL=http://localhost:9000
# MinIO 地址和端口，可以不用域名


MINIO_ROOT_USER=
# 不需要设置

MINIO_ROOT_PASSWORD=
# 不需要设置

设置完直接启动即可：docker compose up -d

反向代理配置

Nginx 和 Certbot 的配置参考这里：https://github.com/streetwriters/notesnook-sync-server/issues/20#issuecomment-2603896363

NGINX

server {
 listen 80;
 server_name auth.domain.com;
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name auth.domain.com;

 ssl_certificate /etc/letsencrypt/live/auth.domain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/auth.domain.com/privkey.pem;
 include /etc/letsencrypt/options-ssl-nginx.conf;
 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

 location / {
 proxy_pass http://localhost:8264;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
}

# Notes Server - With WebSocket
server {
 listen 80;
 server_name notes.domain.com;
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name notes.domain.com;

 ssl_certificate /etc/letsencrypt/live/notes.domain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/notes.domain.com/privkey.pem;
 include /etc/letsencrypt/options-ssl-nginx.conf;
 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

 location / {
 proxy_pass http://localhost:5264;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header Host $host;
 proxy_read_timeout 3600;
 proxy_send_timeout 3600;
 }
}

# Events Server - With WebSocket
server {
 listen 80;
 server_name events.domain.com;
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name events.domain.com;

 ssl_certificate /etc/letsencrypt/live/events.domain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/events.domain.com/privkey.pem;
 include /etc/letsencrypt/options-ssl-nginx.conf;
 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

 location / {
 proxy_pass http://localhost:7264;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header Host $host;
 proxy_read_timeout 3600;
 proxy_send_timeout 3600;
 }
}

# Monograph Server - With Cache
server {
 listen 80;
 server_name mono.domain.com;
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name mono.domain.com;

 ssl_certificate /etc/letsencrypt/live/mono.domain.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/mono.domain.com/privkey.pem;
 include /etc/letsencrypt/options-ssl-nginx.conf;
 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

 location / {
 proxy_pass http://localhost:6264;
 proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
 proxy_cache_valid 200 60m;
 add_header X-Cache-Status $upstream_cache_status;
 expires 1h;
 add_header Cache-Control "public, no-transform";
 }
}

Caddy 的配置参考这里：https://github.com/streetwriters/notesnook-sync-server/issues/20#issuecomment-2763248500

NGINX

notes.example.io {
 reverse_proxy localhost:5264
}

mono.example.io {
 reverse_proxy localhost:6264
}

events.example.io {
 reverse_proxy localhost:7264
}

auth.example.io {
 reverse_proxy localhost:8264
}

正常情况下访问 https://mono.example.io 能看到 Monograph 的默认页面就成功了。

在 Notesnook 客户端自定义服务器

下载 Notesnook 的客户端，进入 Settings -> Servers，填写以下端点：

Sync server URL: https://notes.example.io
Auth server URL: https://auth.example.io
Events server URL: https://events.example.io
Monograph server URL: https:mono.example.io

然后就可以输入你的邮箱注册账户了~

需要注意的是，与 Vikunja 和 Vaultwarden 不同，Notesnook 的邮件验证不是可选项，所以需要填写可以接收到邮件的地址。

如果需要关闭注册，可以在自己注册完后修改 .env ，加入 DISABLE_ACCOUNT_CREATION=1 。

Cloudflare Zero Trust Tunnel 内网穿透注意事项

Wed, 02 Apr 2025 14:10:15 +0000

网上用 Cloudflare Tunnel 进行穿透的教程有不少，不过对连接的部分都说得比较含糊其词。

站长个人尝试穿透家里的 x86 Debian 小主机，在安装 Cloudflared 时遇到了以下问题：

使用 Debian 脚本，遇到 not create ICMPv4 proxy: Group ID 0 is not between ping group 1 to 0 nor ICMPv6 proxy: socket: permission denied 的问题。
使用 docker 脚本，一开始没有用宿主机网络，导致连接一直超时。
使用宿主机网络后，由于默认的协议是 QUIC ，会被阻断，需要改成 HTTP2 。

最终版的运行命令：

TEXT

docker run -d --network host cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <your-token> --protocol http2

这样就好了……大概吧！

Caddy 使用 Buypass Go SSL 作为证书提供商

Mon, 31 Mar 2025 17:55:51 +0000

前言

大家好啊，今天教大家一个脱裤子放屁的 Caddy 小技巧。

由 Let’s Encrypt 获取的 SSL 证书一般有效期为 90 天。虽然可以采用 Certbot 和 acme.sh 一类的脚本，或者交给 Caddy 自动续期，但可能还是有些小伙伴想要获取有效期更长的免费证书。

Buypass Go SSL/TLS 是一家挪威证书签发商的产品，基于 ACME ，证书的有效期为 180 天。那么，如何在 Caddy 中使用它替换默认的 Let’s Encrypt 呢？

自定义兼容 ACME 的 CA 的通用语法

在没有特别指明的情况下，Caddy 通常会使用 Let’s Encrypt 或者 ZeroSSL 来作为 Certificate Authority。你也可以自定义 CA，这里有两种语法，可用于兼容 ACME 的签发者：

第一种，放在 Caddyfile 开头，作用于全局：

NGINX

{
	acme_ca https://acme.zerossl.com/v2/DV90 # 换成自定义 CA
	email hi@example.dev
}

第二种，放在每个域名的大括号里面，作用于域名：

NGINX

tls hi@example.dev {
 ca https://acme.zerossl.com/v2/DV90 # 换成自定义 CA
 }

很可惜的是，经过我的尝试，这两种语法下 Buypass Go SSL 都无法获取到证书。大概是因为 Buypass 在某次更新后添加了 ARI 支持，导致了 Caddy 的 panic:certificate worker: runtime error: invalid memory address。

解决方法有两个：一是使用 Certbot 进行注册，再手动设置 Caddy 读取获得的证书；二是使用最新的 acmez 仓库和 xcaddy 自行构建能够获取 Buypass Go SSL 证书的 Caddy 。

方法一：使用 Certbot 手动获取证书（不推荐）

按照 Certbot 的官方教程进行安装，此处不再赘述。

安装完成之后，运行如下命令：

BASH

root@acme:~# certbot register -m 'YOUR_EMAIL' --agree-tos --server 'https://api.buypass.com/acme/directory'

此时，需要使用你的电子邮件地址在 Buypass 上注册，和 ZeroSSL 是一样的。

如果你不希望你的 web server （ Nginx Apache 都可以，但不是 Caddy ！）暂时停机的话，就选用 webroot 方式完成 ACME Challenge ，需要运行的命令是：

BASH

root@acme:~# certbot certonly --webroot -w /var/www/example.com/public_html/ -d example.com -d www.example.com --server 'https://api.buypass.com/acme/directory'

如果你用的是 Caddy ，由于 Caddy 默认的 https 重定向策略，导致 80 端口的验证几乎成为了不可能做到的事（不要说可以关掉 tls ，关掉 tls 做完验证之后就要重新开启 tls 读取获得的证书，下次续期的时候就会失败）。那就选用 standalone ：

BASH

root@acme:~# certonly --standalone --email 'xxx@example.org' -d 'example.org' --server 'https://api.buypass.com/acme/directory'

然后给 Caddy 读取证书的权限：

BASH

root@acme:~# chmod 755 /etc/letsencrypt/live/ 
root@acme:~# chmod 755 /etc/letsencrypt/archive/
root@acme:~# chmod 644 /etc/letsencrypt/live/example.org/*.pem
root@acme:~# chmod 644 /etc/letsencrypt/archive/example.org/*.pem

最后在 Caddyfile 配置 tls /etc/letsencrypt/live/example.org/fullchain.pem /etc/letsencrypt/live/example.org/privkey.pem 即可。

当然，只是做实验而已，不推荐任何人进行以上操作。同时使用 Caddy 和 Certbot 的行为纯粹是吃力不讨好，Caddy 默认会升级成 https ，并对证书进行自动续期，所以你几乎感受不到证书有效期的短暂和续期的麻烦。

方法二：使用 xcaddy 构建包含最新 acmez 模块的 Caddy

首先，我们需要安装最新版的 Go 。

以 Linux x86-64 为例，运行 wget https://go.dev/dl/go1.24.1.linux-amd64.tar.gz ，然后再运行 rm -rf /usr/local/go && tar -C /usr/local -xzf go1.24.1.linux-amd64.tar.gz 和 export PATH=$PATH:/usr/local/go/bin ，最后运行 go version 验证即可。

然后，我们需要安装 xcaddy。

BASH

root@acme:~# go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
root@acme:~# export PATH=$PATH:~/go/bin
root@acme:~# xcaddy build --with github.com/mholt/acmez/v3@v3.1.1

最后，用 xcaddy 构建的新可执行文件替换掉原来的 Caddy 可执行文件。这一步的操作与 Caddy 的运行方式有关，此处仅展示 systemd 服务的替换方法。

BASH

root@acme:~# systemctl stop caddy
root@acme:~# cp /usr/bin/caddy /usr/bin/caddy.bak
root@acme:~# cp ./caddy /usr/bin/caddy
root@acme:~# chown caddy:caddy /usr/bin/caddy
root@acme:~# chmod 755 /usr/bin/caddy
root@acme:~# systemctl start caddy

此时再在 Caddyfile 中使用语法：

NGINX

{
	acme_ca https://api.buypass.com/acme/directory
	email hi@example.dev
}

就不会再出现 panic 了。

不过，如果你的网站之前已经有了 SSL 证书，那么你需要手动删除 /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory 下的证书文件，然后重启 Caddy 。访问你的网站，如果没有套 CF 的话，就能看到 Buypass 签发的证书了；如果你套了 CF ，那么看到的依然是边缘证书。

本站推出新的公益服务：Vaultwarden，Wallos，Vikunja

Thu, 27 Mar 2025 22:09:03 +0000

本站推出新的公益服务：

Vaultwarden 密码管理器，不必多说。https://vw.obsp.de

Wallos 订阅管理器。https://wallos.obsp.de

Vikunja 日程管理器，支持CalDAV。https://vikunja.obsp.de

请注意，技术上我们无法获取您保存在Vaultwarden中的密码，但是可以删库跑路。所以，做好备份！

为了避免潜在的滥用发件服务器隐患，所有服务的SMTP功能都被关闭了，这也就意味着您不能通过电子邮件重设密码。请谨记！

Enjoy~

在Codeberg Pages上使用Hexo搭建博客

Tue, 18 Mar 2025 22:16:28 +0000

前言

Numerus Fixus 项目的考试终于结束了，发挥得比较一般，没什么把握。放榜之后再整理一下自己的笔记和经验分享给大家吧（虽然感觉几乎没有人用得到，不过万一呢）。

放榜之前都是空闲时间，顺手把旧文章通过Tp2MD 插件导出了，写一写obsp 的Hexo 镜像搭建过程吧。

Typecho 的部署相对来说简单一些，可以直接docker compose，数据库每天备份，但是用久了感觉还是有点不顺手，尤其是发布和修改文章非常麻烦，每次发现错别字都要手动登录后台捉虫。也许直接从Markdown生成HTML的静态站点生成器更适合我一点。静态站点的内容可以托管在GitHub Pages、Gitlab Pages、Bitbucket Cloud和Codeberg Pages等，省去了挑选和维护服务器的烦恼，从写作文章到发布和查看效果的过程也更快速便捷。更重要的是，我发现Typecho 站点被搜索引擎抓取的时候似乎很难抓到文章标题，常常将正文的内容作为标题收录，这就导致了通过搜索关键词发现obsp 的读者往往会因为搜索引擎抓取的标题太奇怪而不愿意点进来，而Hexo 站点就没有这种缺点。Hexo 的缺点大概是每次重装系统/换新设备，都要重新配环境。其他比较出名的静态站点生成器例如Hugo 和Jekyll 我还完全没有尝试过。

这篇文章主要聚焦使用Codeberg Pages的静态站点托管服务来托管Hexo 生成的页面打造博客的过程。Hexo 的官方文档对于Git部署说得也很详细，不过我会加入一些自定义和个性化的过程，例如使用主题、利用Giscus 连接GitHub repo discussions 作为评论区等。

以下操作在基于Arch Linux的发行版Manjaro Linux（内核：Linux 6.12.17-1-MANJARO）上完成，操作系统为64位

安装必要依赖

Git 和 Node.js，由于自带，此处不再赘述，其它操作系统/发行版可以参考Hexo官方文档。

安装Hexo

Hexo 的安装非常简单：npm install -g hexo-cli

安装完成后，我们可以新建一个站点，每一个站点的设置和数据会以文件夹的形式储存，所以我们在你期望的根目录处进行init：

TEXT

$ hexo init <folder> 
$ cd <folder> 
$ npm install

这样，一个基本的站点目录结构就完成了。

新手可能会一头雾水：我的文章应该放在哪里？站点的设置文件在哪里？这个文件夹就是我的站点源码吗？

其实，Hexo生成的静态站点现在还没有出现，我们的站点文件夹中存放的是用来生成HTML文件的资源。我们可以通过使用Hexo的各种命令或者直接读写站点文件夹中的文件来修改资源，从而修改最终生成的页面。

文件夹应该是这个结构：

TEXT

. 
├── _config.yml 
├── package.json 
├── scaffolds 
├── source 
| ├── _drafts 
| └── _posts 
└── themes

很好理解，_config.yml是配置文件，package.json是应用程序的信息，scaffolds文件夹中存放模板，source存放的则是决定最终生成页面的文章内容的资源，包括尚未完成的草稿_drafts和已经准备好渲染和发布的_posts。

以Observer’s Space Hexo站为例，我用Obsidian打开~/obsp/source文件夹作为图谱，在图谱下面，可以看到我正在写的这篇《在Codeberg Pages上使用Hexo搭建博客》归属在_drafts文件夹里，而大家在Observer’s Space Hexo站上能看到的历史文章都归属在_posts文件夹里。当我们执行生成命令的时候，_drafts文件夹里的文章不会生成页面，当你准备好将它们发布的时候才会被移动到_posts文件夹，参与网页的生成。生成的HTML文件会被放在public文件夹里，当我们使用GitHub Pages/Codeberg Pages/Bitbucket Cloud的静态站点托管服务时，我们做的主要是通过Hexo命令使用Git来将本地的public文件夹与远程仓库进行同步，Pages服务通过读取仓库中的内容展示网站。（GitLab Pages的部署略有不同，GitLab用户可以参考Hexo和GitLab Pages的官方文档，此处不再赘述。）

Themes存放的是主题文件的配置，我们现在先不管它。

修改配置文件

现在我们需要做的事是修改配置文件。仍然以Observer’s Space为例，由于_config.yml太长了，我只截取重要的部分进行说明：

TEXT

title: Observer's Space Mirror #站点的标题
favicon: https://s21.ax1x.com/2025/02/11/pEn6KsJ.png #访问网站时显示的头图，我选用了可以免费使用的Google Noto Emoji中ringed planet的Android 10版本，新版设计可以参考https://emojipedia.org/ringed-planet#designs
avatar: https://s21.ax1x.com/2025/02/11/pEn6KsJ.png #网站的头像，细心的朋友可能发现我偷懒了，和头图用的是同一张嘿嘿
subtitle: '宇宙中的观星者' #副标题
description: 'This is a sister website of obsp.de. (Still in beta)' #描述
keywords: #关键词，懒得想
author: Yuki Kamiki #神木友希的大名
language: en
timezone: 'UTC'

## Set your site url here. For example, if you use GitHub Page, set url as 'https://username.github.io/project'
url: https://hexo.obsp.de #这个可以设置成你等下要绑定的自定义域名，就像obsp一样，如果你想用Codeberg给的域名，就请设置成https://USERNAME.codeberg.page。错误的域名设置将会导致CSS和JavaScript资源加载失败，只能访问到文字内容。

#。。。有一群乌鸦飞过
#。。。有一群乌鸦飞过

deploy: #涉及到使用Hexo自动部署命令的配置
 type: 'git' #我们使用git的方式进行自动部署
 repo: git@codeberg.org:kamiki/obsp.git #Repo的地址，https或者ssh都可以。我的 pages 仓库拿去做别的内容了（欢迎大家访问~），所以给 obsp 创建了一个新仓库。如果你要用Codeberg Pages 并且在 Codeberg 提供的域名根目录 https://USERNAME.codeberg.page 访问的话就应该是git@codeberg.org:USERNAME/pages.git
 branch: main #跟踪远程仓库的分支
 message: updates #commit时的提交信息

啊，配置文件搞定了！不要忘记保存退出哦！

生成静态站点

你可以使用hexo new [layout] xxx来新建一篇文章。

当你指明 layout 是draft/page/post 的时候，hexo 会将生成的 md 文件存放在source目录下对应类型的文件夹中，如果省略 layout 参数，那么默认生成的是 post 。

如果还没想好写什么，没关系，打开 source/_posts，会发现那里面并不是空白的，我们在执行hexo init的时候自动生成了一个 md 文件，它可以作为博客第一篇文章的资源。

执行hexo g，会发现生成了一个public文件夹。执行hexo deploy进行部署，会将这个文件夹中的内容发布到刚才在_config.yml中填写的仓库地址。

等一下……！好像不太对……

发布到Codeberg Pages

第一次用git的小伙伴可能不知道怎么连接远程仓库，~~请善用搜索引擎~~ 和平时连小鸡的方式差不多，用公私钥或者用户名密码都可以。什么你说你没有连过小鸡？~~请善用搜索引擎~~ 执行ssh-keygen -t ed25519 -C "your_email@example.com"，然后你就会在~/.ssh找到公私钥，公钥是那个文件名带 pub 的，私钥是不带的，把公钥内容上传到 Codeberg 设置中，然后再执行hexo deploy即可。

Enjoy！

稍等片刻（Codeberg 正在码头给你整 SSL 证书），即可在https://USERNAME.codeberg.page/查看你的 landscape 主题 Hexo 博客。

绑定自定义域名

把你的域名 CNAME 解析到username.codeberg.page，然后在仓库里新建一个.domains文件，输入你想要的域名example.org，再等一会（Codeberg 正在码头给你整 SSL 证书）即可通过自定义域名访问。

什么你说 root 不能有 CNAME 记录？~~你怎么不托管到能做CNAME拉平的NS提供商~~ 也没问题，A记录解析到217.197.91.145，AAAA记录解析到2001:67c:1401:20f0::1，然后TXT记录username.codeberg.org即可。

主题配置（以本站为例）

本站采用的是 Stellar 主题，感谢 xaoxuu 大佬开发和开源！

因为我比较懒，所以采用了稳定版安装：npm i hexo-theme-stellar 找到_config.yml文件中的theme: landscape改成theme: stellar然后重新运行hexo g和hexo deploy即可。

自定义字体（以本站为例）

本站用的是霞鹜文楷（无衬线体、衬线体）和 PT Mono（等宽）。

新建一个专门给 Stellar 主题用的配置文件_config.stellar.yml，写入以下内容：

TEXT

inject:
 head:
 - <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/lxgw-wenkai-screen-web/style.css" />
 - <link rel="preconnect" href="https://fonts.bunny.net">
 - <link href="https://fonts.bunny.net/css?family=pt-mono:400" rel="stylesheet" />
style:
 font-family:
 logo: 'LXGW WenKai Screen'
 body: 'LXGW WenKai Screen'
 code: 'PT Mono'
 codeblock: 'PT Mono'

注意 Stellar 仓库里的_config.stellar.yml示例使用了单引号内套双引号'"LXGW WenKai Screen",...'，实测这样子无法应用字体，去掉双引号即可。

Giscus 评论区

和 Typecho 不同，Hexo 默认是没有评论区的，而大部分博主还是希望能够听到读者的反馈，那么就有了各种各样的评论插件。Giscus 使用 GitHub 仓库的 Discussions 功能，按照 https://giscus.app/zh-CN 上的指导创建好公开仓库、安装 giscus app、启用 Discussions功能后，把你的用户名/仓库名复制粘贴进去（很奇怪，手动输入会提示无法连接，复制粘贴就可以，这个 bug 可以复现，有人遇到了同样的问题）。

然后在 Stellar 配置文件里写入：

TEXT

comments: 
 giscus: 
 enable: true 
 repo: <YOUR_GITHUB_USERNAME/YOUR_REPO_NAME> 
 repo_id: <YOUR_REPO_ID> 
 category: <YOUR_CATEGORY_NAME> 
 category_id: <YOUR_CATEGORY_ID> 
 mapping: pathname 
 reactions_enabled: 1 
 emit_metadata: 0 
 input_position: bottom 
 lang: en 
 loading: lazy 
 crossorigin: anonymous

重新运行一下hexo g && hexo deploy即可。

本站推出剪贴板服务：Microbin

Mon, 17 Mar 2025 12:13:39 +0000

Observer’s Space推出了一个新的公共Microbin实例，欢迎大家使用。

实例地址：https://bin.obsp.de

您可以通过设置有效期、阅读次数限制和权限来保证数据安全。

有关权限的说明：

公开

该隐私级别允许所有人查找、查看、修改和删除您的上传。

未列出（推荐）

未列出的上传无法被找到，除非有人知道其唯一的随机标识符。如果有人知道此标识符，他们就可以查看、修改和删除上传内容。

只读

使用此隐私设置，除非有人知道上传内容的唯一随机标识符，否则无法找到该上传内容。如果有人知道该标识符，则可以查看内容，但如果不输入上传密码，则无法修改或删除内容。

隐私

使用该隐私设置，除非有人知道上传的唯一随机标识符，否则无法找到上传内容。如果有人知道该标识符，则在未输入上传密码的情况下无法查看、修改或删除该内容。您的上传及其附件都经过加密，因此存储安全。

保密

使用此隐私设置，除非有人知道上传的唯一随机标识符，否则无法找到上传内容。如果有人知道该标识符，那么在未输入上传密码的情况无法查看、修改或删除该内容。您的浏览器会向我们发送一个已经加密的版本，因此未加密的数据和密码根本不会离开您的设备。此选项要求您在访问数据时多次输入密码，但非常安全。

2025.03.12更新

Wed, 12 Mar 2025 09:01:35 +0800

家里云暂时掉线，站长要考试，服务器不能放在房间里=.=

对本站访问没有影响~

Rclone以WebDAV方式挂载Hetzner Storage Box

Mon, 10 Mar 2025 12:12:00 +0800

疑似有点太水了，想不出这个有什么出教程的必要（不是）。

本来想尝试Rclone UI，奈何AppImage版在Arch上根本启动不了，我试着在AUR里找了一下yay rclone-ui，居然没找到……原来AUR也不是万能的，那就继续用命令行的原版Rclone吧。

Hetzner买Storage Box的过程就跳过了。因为hz是PAYG的模式，所以账单一般下个月才会出。

进控制台：https://robot.hetzner.com/storage ，Reset一下根用户密码。然后打开WebDAV、SSH，用WebDAV或SSH工具进去创建一个空的子文件夹，如果没有子文件夹的话是无法创建子账户的。

然后去sub-account创建一个子账户，打开WebDAV和External-access，以便在互联网上访问。

子账户的WebDAV地址是https://uxxxx(换成你的主账户id)-subx(换成你的子账户id).your-storagebox.de，账户是uxxxx-subx，密码是你设置的密码。

Rclone官方一键安装脚本：sudo -v ; curl https://rclone.org/install.sh | sudo bash

按照提示操作选择新建远端，起个名字（以Hetzner为例）选中WebDAV，然后把上面的地址、用户名和密码填进去，剩余部分留空即可。

挂载：rclone mount hetzner: /path/to/mnt

这个时候就会发现Rclone提示这个远端不支持流式传输（streaming），需要加上关于缓存文件的参数。

那么命令就可以修改成rclone mount hetzner: /path/to/mnt --vfs-cache-mode writes

运行命令的时候会发现只能前台运行，如果退出执行命令就会导致停止挂载。

解决办法也很简单，加入后台运行参数即可：rclone mount remote:path /path/to/mount --vfs-cache-mode writes --daemon。

2025.03.09更新

Sun, 09 Mar 2025 17:41:21 +0800

站长在备考，这个月更新得比较少。

准备把从今往后的博文从Typecho镜像到Hexo，Hexo网站托管在Codeberg Pages，暂时还没开发出Hexo的玩法，不过网站已经搭建起来了：https://hexo.obsp.de，欢迎访问（目前里面什么都没有）

Roadmap：买Servarica的大盘鸡，为读者提供Nextcloud免费服务~

CalDAV及CardDAV服务器Radicale V3部署指南+Caddy V2一行反代

Wed, 05 Mar 2025 11:58:00 +0800

Baïkal的部署比较简单，然而由于某种神秘原因，Baïkal的日历在iOS上无法连接，即使我按照同类Github Issue中的解决方案在反代配置中使用了rewrite依然无法战胜，只好用回我的老朋友Radicale。

之前小鸡配置比较低，只跑得起这种超轻量级的服务，尽管现在在小鸡上部署了owncloud和nextcloud，我还是更习惯Radicale的管理界面，就有了今天这篇文章。 Radicale官方的文档写得还是很详细的，可以自行查阅。

前置条件：以下操作在Debian 12 bookworm中使用root用户完成。

安装步骤

安装Python3虚拟环境：

root@debvmde:~# apt install python3-venv

创建并进入radicale虚拟环境：

TEXT

root@debvmde:~$ python3 -m venv radicale
root@debvmde:~$ radicale/bin/pip install pip --upgrade setuptools wheel
root@debvmde:~$ source radicale/bin/activate

这时可以看到root@debvmde:~# 已经变成了(radicale) root@debvmde:~# ，说明我们已经进入虚拟环境，可以pip install了。

运行一下：pip install --upgrade radicale && radicale --version

创建配置文件：mkdir -p .config/radicale && nano .config/radicale/config，根据官方文档的说法：

Radicale tries to load configuration files from /etc/radicale/config and ~/.config/radicale/config. Custom paths can be specified with the --config /path/to/config command line argument or the RADICALE_CONFIG environment variable. Multiple configuration files can be separated by : (resp. ; on Windows). Paths that start with ? are optional.

创建用户名和密码文件.config/radicale/users，可选的加密方式有plain/md5/bcrypt/autodetect，此处选用md5. （当然md5也并不是首选，关于怎么用htpasswd，请自行查阅官方文档）

我们希望选用的用户名和密码分别是user和password，如果采用plain加密，.config/radicale/users内就会存有明文的用户名和密码user:password，这样显然是不太安全的，所以需要以哈希值的形式存储密码。

使用htpasswd md5哈希生成器，把密码加密，得到形如$apr1$j9JJ7hNw$aY8K5tLzVq4hi1XX/CnD70的字符串，我们的密码文件中加入user:$apr1$j9JJ7hNw$aY8K5tLzVq4hi1XX/CnD70一行即可。

打开配置文件~/.config/radicale/config，加入以下内容：

TEXT

[server]
hosts = 0.0.0.0:5232, [::]:5232

[storage]
filesystem_folder=/root/radicale/collections

[auth]
type = htpasswd
htpasswd_filename = /root/.config/radicale/users
htpasswd_encryption = md5

[server]
max_connections = 20
# 100 Megabyte
max_content_length = 100000000
# 30 seconds
timeout = 30

[auth]
# Average delay after failed login attempts in seconds
delay = 1

现在可以启动服务了：运行radicale。

访问<serverip>:5232，输入user和password，看看是否能成功进入。

创建service：nano /etc/systemd/system/radicale.service

加入以下内容：

TEXT

[Unit]
Description=A simple CalDAV (calendar) and CardDAV (contact) server

[Service]
ExecStart=/root/radicale/bin/python /root/radicale/bin/radicale

Restart=on-failure

[Install]
WantedBy=default.target

启动：systemctl enable radicale && systemctl start radicale。

反代

Caddy的配置非常简单：

TEXT

radicale.example.org {
	reverse_proxy localhost:5232
}

使用官方文档中的SHA-512对密码进行哈希时的注意事项

接下来是radicale官方文档的错误：

The secure way The users file can be created and managed with htpasswd:

Create a new htpasswd file with the user “user1” using SHA-512 as hash method

$ htpasswd -5 -c /path/to/users user1 New password: Re-type new password:

Add another user

$ htpasswd -5 /path/to/users user2 New password: Re-type new password: Authentication can be enabled with the following configuration:
TEXT
[auth]
type = htpasswd
htpasswd_filename = /path/to/users
htpasswd_encryption = autodetect #注意看注意看

千万不要！用！autodetect！

是什么方法就写什么方法！比如我用SHA-512，就老老实实写htpasswd_encryption = sha512.

否则你会在journalctl --unit radicale.service收获一串美丽的报错：radicale.service: Failed to determine user credentials: No such process/Failed at step USER spawning /root/radicale/bin/python: No such process。

参考文献：

https://radicale.org/v3.html https://sigmdel.ca/michel/ha/aml912/radicale_en.html https://www.atlantic.net/dedicated-server-hosting/how-to-install-radicale-calendar-caldav-and-carddav-on-ubuntu-20-04/

SearXNG接入Open WebUI显示Error searching的解决方法

Mon, 03 Mar 2025 10:22:00 +0800

可能是由于没开启JSON输出导致的，

在您的/usr/local/searxng-docker/searxng/settings.yml加入如下内容：

TEXT

search:
 formats:
 - html
 - json

OpenWebUI的搜索字符串不是%s，也不是空白，是<query>，例如使用本站SearXNG实例进行搜索，要在联网搜索处配置的URL是https://q.obsp.de/search?q=<query>。

Microsoft Account辅助邮箱验证bug:That doesn't match the alternate email associated with your account.

Tue, 25 Feb 2025 21:56:00 +0800

Bug描述: 格式为xx.abcd@example.org的邮箱是微软账号的辅助邮箱之一。试图验证辅助邮箱地址，输入地址后显示 “That doesn’t match the alternate email associated with your account. The correct email starts with “xx”.

Bug原因: 前端程序员太弱智。

解决方案: 把第三个字符.换成URL编码的%2E即可。

类似问题:

In my case, I only have two letters as an email name. For example, if my alternative email is`ab@xyz.org: Verify your email - We will send a verification code to ab*****@XYZ.org. To verify that this is your email address, enter it below. When I key in ab@xyz.org` , it always shows: That doesn’t match the alternate email associated with your account. The correct email starts with “ab”.

解决方案: 目前无解。

参考文献: Alternate Email not recognized for Verification code

2025.2.20更新

Thu, 20 Feb 2025 20:56:44 +0800

本站邮箱服务neomail.cc的欧洲分站正在筹备中，站长已购入新的域名neomail.nl，预计将使用瑞士托管商Migadu或Infomaniak的服务。

docker自建Bitwarden的社区精简高级版Vaultwarden，并使用Caddy反代

Wed, 19 Feb 2025 20:44:00 +0800

在体验过市面上一圈密码管理器（第三方托管+自建）之后，我还是可耻地选择了商业，选择每个月掏2刀给Proton让它赚=。= 不过我是因为太懒&对密码管理的需求太复杂才做出如此选择的，大部分热爱折腾的mjj还是喜欢Keepass和Vaultwarden，今天就来讲一下小鸡自建Vaultwarden的配置。

启动 Docker 容器

先mk个dir ：mkdir vw && cd vw

docker run比较快，不过我个人觉得docker compose方便一些，nano docker-compose.yaml:

TEXT

services:
 bitwarden:
 image: vaultwarden/server:latest
 container_name: bitwarden
 restart: unless-stopped
 environment:
 - DOMAIN=https://vw.mydomain.org/asuperrandomstring
 - SIGNUPS_ALLOWED=true
 - WEB_VAULT_ENABLED=true
 volumes:
 - ./vw-data:/data
 ports:
 - "8080:80"

记得把域名的A记录加上，vw.mydomain.org指向Vaultwarden服务器的ip。

这里的path/asuperrandomstring可以拿密码管理器生成一个，然后写在纸上或者文本文档里。千万不要只放在你建好的Vaultwarden密码库里，原因你懂的，就像不要给2FA验证器加2FA登录验证一样……

配置`Caddyfile`:

TEXT

vw.mydomain.org {
 route {
 reverse_proxy /asuperrandomstring/* localhost:8080 {
 header_up X-Real-IP {http.request.header.Cf-Connecting-Ip}
 }
}

配置好一起启动：docker compose up -d && systemctl reload caddy

访问https://vw.mydomain.org/asuperrandomstring/，创建账号，导入密码，不再赘述。

创建完所有需要的账号之后，记得关闭访客注册~

关闭访客注册的方式是docker compose down，然后修改docker-compose.yaml中SIGNUPS_ALLOWED的值为false，再docker compose up -d即可。

数据备份

为防止数据丢失，可以用之前提到过的使用Filen CLI定时备份服务器数据备份你的vw-data文件夹~如果这么做，确保你的Filen账号和密码是自己记得的，而不是存储在Vaultwarden保险库里面的，否则一旦服务器上的数据受损，想从Filen取回备份的时候，会把自己反锁在外面。

Keepass多端同步折腾笔记（Linux+Android+iPadOS）

Tue, 18 Feb 2025 09:53:00 +0800

同步方案

密码在Nextcloud上存一份，手机本地存一份，PC本地存一份。

Android

手机本地文件夹用Foldersync和Nextcloud进行双向同步（想要用free and open source software的话，下载rclone的安卓GUI Round Sync或者Termux命令行模拟器直接用rclone吧，我只用过前者，不支持双向同步功能，作者说这个功能实现遇到了困难，搁置了。rclone的本体是支持bisync的，但是我懒得在小屏幕上折腾命令行），设置定时任务，每小时一次。我用的安卓Keepass客户端是KeepassDX。

Linux PC

Linux桌面将Nextcloud文件夹挂载到本地文件目录，双向同步对文件的修改；或者用rclone连接远端，crontab -e定时运行rclone bisync。

客户端+浏览器扩展是KeepassXC。（我用的浏览器是Brave，需要注意KeepassXC不支持Flatpak版的Brave，请用官方脚本/软件源安装）

iOS

iPad用Strongbox，fetch远程的WebDAV文件夹，或者奇密（Fantasy Pass），后者很便宜，不过部分代码是闭源的，且作者不再维护，GitHub仓库上一次更新是7年前。

Strongbox免费版满足大部分需求，并且ui、自动填充2FA和数据库警报都很好用，生成密码的功能也很全面（还可以加盐，但是我不太懂为什么加盐要在密码管理器生成明文密码这一步进行）。

踩坑：用Argon2加密的iOS用户，一定要记得去加密方式里面把内存调到32MB以下，默认好像是64；如果保持默认的话由于iOS对每个应用的内存限制，在使用输入法内嵌自动填充的时候会崩溃。

总结

这套方案唯一的问题就是Nextcloud对数据的处理有时候不太尽如人意，经常因为文件名相同内容不同就报错，但是直接忽略，取最新版就OK了。或者换别的WebDAV/S3提供商，例如Koofr，Hetzner Storage Box，Scaleway 对象存储，Storj等等。（之前同步的时候用过Backblaze B2，我的感想是最好不要用B2，B2的list object操作是计费的，rclone非常吃这个操作，尤其是文件版本多/小文件多的情况，即使在同步命令里加上--fast-list --local-no-check-updated也能把一天中的2500次操作吃光。）

Arch Linux(GNOME)安装Fcitx 5输入法+中州韵Rime+雾凇拼音

Tue, 18 Feb 2025 09:25:00 +0800

以下配置适用于GNOME桌面，KDE和Xfce用户请参考其它文章。

安装Fcitx 5和中州韵Rime：

Fcitx 5用AUR helper装：

yay -S fcitx5 fcitx5-rime fcitx5-configtool fcitx5-gtk fcitx5-qt fcitx5-config-qt

我一直用sudo yay，发现以sudo运行的时候会提示不建议，直接yay即可。

nano一下/etc/environment，加入如下内容

TEXT

XMODIFIERS=@im=@fcitx
QT_IM_MODULE=fcitx
GTK_IM_MODULE=fcitx

安装必要的GNOME组件：

安装Input Method Panel

重启一下，打开Fcitx 5配置，把中州韵Rime添加到键盘里面。

安装雾凇拼音：

yay -S rime-ice-git

改一下Rime的配置：nano /.local/share/fcitx5/rime/default.custom.yaml，写入：

TEXT

patch:
 # 仅使用「雾凇拼音」的默认配置，配置此行即可
 __include: rime_ice_suggestion:/
 # 以下根据自己所需自行定义，仅做参考。
 # 针对对应处方的定制条目，请使用 <recipe>.custom.yaml 中配置，例如 rime_ice.custom.yaml
 __patch:
 key_binder/bindings/+:
 # 开启逗号句号翻页
 - { when: paging, accept: comma, send: Page_Up }
 - { when: has_menu, accept: period, send: Page_Down }

参考文献：https://github.com/iDvel/rime-ice

2025.2.17更新

Mon, 17 Feb 2025 23:15:56 +0800

通过编辑limiter.toml，修复了本站SearXNG实例风控严重，搜索时重定向回主页的问题。

使用Filen CLI定时备份服务器数据

Sun, 16 Feb 2025 20:04:59 +0800

这一篇文章没有docker了，docker方便又无聊，很多服务的部署讲来讲去就那样，Caddy的反代只有一行，更没营养，所以讲点别的吧。

今天的主角是德国的加密云盘filen.io，定价宜人，虽然对于大量存储而言比不上Storj B2 OVH这些便宜的对象存储有竞争力，个人使用也算是便宜大碗该有的都有，不像Proton Drive一样是个挂着加密噱头的半成品。尽管由于加密的特性不支持WebDAV挂载，Filen团队还是别出心裁地开发了一套命令行工具――Filen CLI，让用户可以实现云盘挂载到本地目录的同时，还提供了在本地运行支持WebDAV和S3协议的Filen镜像服务器的功能，用户登录镜像服务器的WebDAV或S3地址，即可轻松挂载Filen云存储到其他设备(具体的操作，等有空了另写一篇)。Filen给免费用户的空间也十分慷慨，初始10 GB，后续可以通过邀请码邀请新用户注册，双方都可以额外获得10 GB，免费用户的空间最高可以达到50GB。有兴趣的朋友可以试一试用我的邀请码注册，即可获得20 GB的免费空间。需要注意的是，Filen的TOS明确禁止一人持有多个免费账户，想要薅羊毛的还是谨慎。

言归正传，接下来我们进入使用场景：Filen账号1个，Linux VPS 1台，VPS上运行着一项服务，数据位于文件夹/path/to/myservice，此时我们希望做到的是：每天凌晨2点自动备份该文件夹中的数据到Filen云端，VPS本地数据覆盖Filen云端数据。

连接服务器，执行命令curl -sL https://filen.io/cli.sh | bash，安装Filen CLI。

安装完成后即可通过filen [options...]与Filen CLI交互。

第一次使用应该会要求输入账号和密码（还有2FA code，如果你设置了的话），并且询问是否保存。因为我们要让filen同步命令每天运行，所以就选择保存，以后需要删除的话可以用filen delete-credentials这条命令删掉。

nano 一个 sync 脚本sync-local-to-cloud.sh：

TEXT

export PATH=$HOME/.filen-cli/bin:$PATH 
#这个很重要，不然会出现command not found的报错
 
SERVICE_DATA_DIR="/path/to/myservice" #需要备份的数据目录
 
REMOTE_FILEN_DIR="/myserverdata/myservice" #远端目录
 
# Sync the folder to Filen
filen sync $SERVICE_DATA_DIR:ltc:$REMOTE_FILEN_DIR
#ltc的意思是local to cloud，本地同步到云端

Filen命令行官方教学：https://docs.filen.io/docs/cli/

然后使用crontab -e设置定时任务：

TEXT

00 2 * * * /root/sync-local-to-cloud.sh >> /root/sync.log 2>&1
#每天2点运行一次备份脚本，并且输出log到指定的文件sync.log

大功告成！

第二天早上起来，记得看看log里是否有成功备份的记录。

开普勒第二定律推导

Sat, 15 Feb 2025 19:50:00 +0800

本站SearXNG实例存在的问题

Fri, 14 Feb 2025 21:19:56 +0800

Check this GitHub issue: https://github.com/searxng/searxng/issues/3191

去谷歌化路漫漫（一）：Proton和电子邮件

Fri, 14 Feb 2025 17:36:00 +0800

这篇文章将会很长，去谷歌化的路程是我对所见种种感受改变，对自己十几年互联网生活反思、改进，有失有得的过程。每一期我都会聊一些产品，以及我个人的体验，不客观不真实，仅供参考。今天先讲去谷歌化中的谷歌：Proton。

2024年底，我开始去谷歌化了。

原因和大多数用户的追求隐私/支持自由软件不同，我只是想要一个简洁的互联网生活。

希望我的邮件客户端不要再讨好我，从大数据中预测这一封放进社交媒体还是收件箱; 希望每次登录账户时输入密码和2步验证代码就能成功登录，不必拿出另一部设备进行一番操作; 希望在使用YouTube/B站时，我能选择自己想要的客户端，而不是把一切都寄托在谷歌/叔叔恩赐一般的优化; 希望我的密码可以跟着我的人走，而不是被绑在Chrome里; 希望讨厌的广告，不要总是霸占搜索引擎的前排; 希望我的账户信息，不会因为我少加了一个密保邮箱和手机号，就面临着随时把自己锁在外面的风险……

当我刷着Reddit，r/deGoogling这个版块出现在眼前，我一下子就明白了它的意思: 是的，这就是我一直想要的!

……吗?

似乎不是。

论坛里的大家，兴致勃勃地讨论着谷歌套件的替代品，让我感到很受鼓舞。在欧美地区去谷歌化堪称“逆天而行”，离开了谷歌的便利工具，许多人甚至感到一夜变成了原始人。作为手足无措的用户中的一员，我开始从101看起。

去谷第一剑，先斩gmail。而热度最高的gmail，以至于谷歌套件的替代品，就是Proton。

Protonmail，这是一个我在2020年就听说的名字。“端到端加密”“尊重隐私”的邮件，它几乎凭借一己之力，将这原本小众的需求成功带进了大众的视野。从前的Proton只有邮件服务，而如今却大有要做成隐私友好的网络服务提供商中的Google的意思：VPN，密码管理器，邮件，云盘，日历，还有24年底面向Visionary用户（一种类似于给Proton进行了风投的顶级订阅用户，这些用户不仅能获得所有产品的最高级权益，还能保证享受以后的所有升级。当然订阅费很贵，并且根据reddit用户回忆，这种订阅只在Proton初创和24年黑五后开始强推Wallet的时间段开放过）进行了加密货币钱包的内测。

然而，这个提供商却让我感到比Google还令人无所适从。

打开它的网站，紫与蓝的配色十分醒目，居中衬线体的标语是“A better internet starts with privacy and freedom（更好的互联网从隐私和自由开始）”，并在首页展示了Proton的各项业务与最新的促销信息。不得不说，Proton的UI进步不小，从2020年初以一把锁为Logo，灰扑扑的朴素模样，到如今大方优雅、细致入微的紫色系平面设计，像是在向互联网昭示这个新兴的企业已经完成了从丑小鸭到白天鹅的蜕变。

作为一个穷鬼，我首先做的就是点开定价一项项察看。在2024年11月，Proton各项服务的定价（根据我的回忆，此处我会找到互联网档案的资料补上）是这样的：各项服务的基础功能免费，各自的会员定价不同。邮件服务Mail Plus是4.99USD/mo，年付八折；第二大业务VPN的Plus是9.99USD/mo，两年付五折；密码管理器Pass Plus是2.99USD/mo，年付价格为1.99USD/mo（Pass与邮箱别名服务SimpleLogin两项业务的会员在早些时候是分开的，分别定价2.99USD/mo。24年底完成了Pass Plus和SimpleLogin Premium的合并，合并后提价至3.99USD/mo，年付七五折）；云盘Drive 200GB的空间需要收取4.99USD/mo，年付八折。

这定价不能算贵，但也不算便宜。在欣赏完这些对隐私大有助益的服务之后，我不禁汗流浃背：这样子一项一项加起来，一个月的花费接近30刀。当然，实际上不需要这么多，因为——

Proton将每一项服务的单价抬高，最终的目的就是吸引用户把目光投向中间高亮的、用紫色框框围起来的选项——Proton Unlimited，月付12.99USD——当然，这不重要——年付9.99USD/mo。此时，刚刚在心中算了一笔账的用户就会发现：哎，这个划算！

不仅如此，Proton在购买页面从未告知客户：当用户购买了一项服务的Plus之后，便不能在同一个Proton账户上叠加其他服务的Plus。也就是说，“我只买Mail Plus和Pass Plus/SimpleLogin就够了”的想法是根本不可能实现的，在一项服务的Plus之上，只有直接购买Proton Unlimited的选项。而且，由于月付与年付的价格差异，Proton吸引客户更多地购买Unlimited的年付套餐。

然而，根据互联网上用户的反馈和我个人的经验来看，这种捆绑定价的策略让顾客并不满意：不少人抱怨Proton涉足云盘、密码管理器的领域，而首推的邮箱服务和VPN却并没有进行多少优化，多而不精。

我也忍不住想，如果去谷歌化的过程就是从一个公司跳到另一个公司，相信它对安全和隐私的承诺，并且每个月掏出9.99刀给它，相信这样就能买到安心，那么为什么不直接相信谷歌呢？

当然，我们有证据说明谷歌对用户的隐私不够尊重，而Proton做得远比谷歌好；但是，这样足够吗？

就拿邮箱来说，Proton为了保证E2EE（端到端加密，只有收信人和发信人能够解密信息），取消了对邮件行业标准IMAP/SMTP的支持，而后又顶不住客户的需求和自己的客户端实在太难用的事实，重新在桌面端加入了Bridge。这种打折腿给根拐的行为两面不讨好，对于真正需要隐私的客户而言，他们大可以去选择OpenPGP加密和Signal聊天软件这些更加成熟且广为接受的产品，而对于普通的客户而言，他们只是想用熟悉方便的客户端收发邮件，都要为此付出一笔月费，而且在移动端，Proton至今没有对第三方邮件客户端的支持。

至于Proton此举对E2EE的实现效果，我只能说：如有。

如果与Proton用户通信的对象位于另一个邮件服务器，那通信对象的邮件提供商一样能够阅读他们之间通信的内容。为了保障同外部联系人的通信也是E2EE，需要提前设置一个密码，对方收到邮件后，需要输入密码才能阅读。问题在于，OpenPGP就在那里，既有Thunderbird和eM Client的原生支持，又有Mailvelope这样的浏览器插件，在电子邮件中实现加密通信早就不是什么新鲜事，Proton此举无异于画蛇添足。Proton的一个主要营销点是总部位于瑞士，然而“瑞士的隐私法律”管辖住的也只有Proton保留与分享你的信息的权力。正如我刚才所说，你的邮件来自互联网各处，发向互联网各处。即使谷歌，或者说以GAFAM为首的数据矿工不再能够收集你收件箱中的信息，但你还是把真实的邮箱地址暴露在各种零售商的mailing list中，那么收集这些公开的信息一样可以拼凑出你的用户画像。

当然，我也有不少Proton的好话要说：除了云盘实在没得夸，邮件也不符合我心中的评价标准，Pass和VPN我还是颇为欣赏的。Pass和SimpleLogin别名互通、会员合并之后，已经成为了我心目中Bitwarden之下第一密码管理器（KeePass论外，从灵活性/自建成本来说它应该是断层第一，但是KeePass的好用程度取决于客户端，用户体验上限高、下限低，参差不齐），开源的客户端、方便的导入与导出、独步天下的别名生成与管理，基础功能如附件、分类模板、密码生成和密码口令生成、2FA代码储存和填写，除了无法自建和云端优先这两个小小缺憾，可称得上是该有的都有，后来居上，大有压1Password一头之势。VPN功能丰富，体验稳定，直连也不会捶胸顿足，IP比较脏，但也是在所难免。

当时的我只是想找一个适合穷鬼、可以用IMAP/SMTP并且看起来不像随时要跑路的提供商，当然，如果不是大公司的产品，我会更乐意。找来找去，目光锁定了mailbox.org和posteo.de，这两家各有优劣，起价都便宜，前者的优势是有域名邮箱支持，后者定价是PAYG的模式，并且用户忘记按时付款只会暂停发信功能，不会暂停收信功能（我说这个不是教唆网友去薅羊毛，只是说假如我被车撞了在医院里躺了半年，不会因为错过缴费而失去这半年里发到我的地址的重要邮件）。后来用了一会，两家我都不太满意，mailbox的网页从我这里加载实在是太慢了，符合对德国网络的刻板印象；posteo是因为最后我还是更想用域名邮箱一点，但是他们家出于隐私保护不希望保存用户的域名信息。

之所以最后还是用上了域名邮箱，是因为频繁地注册各类账号的我很需要一个别名服务，买不起SimpleLogin和Addy.io，琢磨自建的时候突然发现：不对啊，自建肯定需要一个域名，这整个域名都是我的，我还在这里装模作样地enable和disable做什么，直接开个catch-all，遇到垃圾就block，岂不美哉！而且，未来SimpleLogin或其它别名服务的域名可能为他人注册，或者挪作他用，但是只要我一直续费域名，域名就一直属于我，便宜又可靠。

所以我最后靠上的邮箱解决方案是几个主要域名不开catch-all，几个次要域名开catch-all接收垃圾邮件（不发送的话直接用Cloudflare路由），买的是MXRoute家的不按邮箱个数计费只按容量计费的邮件托管服务，一年下来的域名钱和邮箱钱加起来只要15刀，花五分之一的钱享受比Mail Plus+SimpleLogin更自由的服务（这个数字还能腰斩，明年要放生一个.cc域名）。

当然这个时候就有人要问了，有什么坏处吗？如有吧，比如MXRoute的老板不在瑞士，我的域名registrar也不在瑞士，Cloudflare也不在瑞士，但是我是穷鬼，穷鬼是不会追求这个的，反正本站也不在瑞士（本站的主机托管在风景不知道怎么样反正站长没去过的德国纽伦堡）……

说完了服务端，该说客户端了。我没有试过所有风评“值得一试”的客户端，比如Claw Mail，我的体验很浅，仅仅是从Fedora换到Arch的时候试了一下，后来发现还是Thunderbird比较得劲。Thunderbird是一个成熟、面面俱到的开源客户端，赖舒服了就不想走，最大的特色大概是自动发现收发信服务器，安卓端的FairEmail用的也是tb的检索功能。不习惯Thunderbird，想要更简洁一点的Linux桌面用户可以尝试一下Evolution。FairEmail是我心目中的安卓最佳，尽管UI褒贬不一，但是功能肯定是最多的，对于默认不加载外部图像的邮件排版得非常好，一目了然，其他客户端往往都需要加载出图片才能看出邮件的内容。K-9无功无过，被Thunderbird合并后表现更加亮眼。eM Client，还没有试过。最近买了NameCrane的三年套餐，SmarterMail为每个顶级域送3个license，过段时间会试试看。

至于各大邮件厂商自己的应用，网易邮箱大师的桌面端和移动端都一般般，校园邮薅的永久vip去广告版尚可一用，但是Thunderbird和FairEmail珠玉在前，只能说是食之无用，弃之可惜。QQ和foxmail也是一样。Tuta的邮件客户端倒是没有广告，不过搜索功能很垃圾，也不能导入/导出。

未完待续，本期水完邮箱，下期水一下密码管理软件吧。

2025.2.13 更新

Thu, 13 Feb 2025 21:34:00 +0800

取消了访问时出现的Cloudflare的JavaScript质询页面。

本博客主机提供商rarecloud.io正在经历大规模DDoS，攻击者跑了本博客托管VPS 1TB传入流量，让站长草木皆兵，不得不防。

现已将博客迁移到Netcup。

docker compose部署订阅管理软件wallos，并启用telegram机器人通知

Tue, 11 Feb 2025 00:48:00 +0800

话费，域名，邮箱，VPS，密码管理器，云存储，流媒体会员……数字生活的订阅开支无处不在，却难以管理。你是否也有需要的服务到期忘记续费，而不需要的服务不小心自动续费的烦恼? 别担心，已经有开发者推出了解决方案，那就是订阅管理软件Wallos。这是一个可以自部署的开源项目，不仅有多种货币和支付方式，还有各种各样的提醒方式，包括email, discord, pushover, telegram, gotify和webhooks。项目部署支持baremetal和docker，无论你是想高度自定义，还是想简便快捷，都可以做到。

这篇文章聚焦使用docker compose的方式部署Wallos管理订阅，然后使用tg机器人通知来实现提醒。

Wallos的部署

我们先mkdir wallos && cd wallos

编辑一下nano docker-compose.yaml，添加如下内容:

TEXT

services:
 wallos:
 container_name: wallos
 image: bellamy/wallos:latest
 ports:
 - "8282:80/tcp"#左边改成你喜欢的端口
 environment:
 TZ: 'America/Toronto'#改成你所在的时区
 # Volumes store your data between container upgrades
 volumes:
 - './db:/var/www/html/db'
 - './logos:/var/www/html/images/uploads/logos'
 restart: unless-stopped

最后，docker compose up -d，大功告成!

运行docker compose logs -f看看是否正常启动。

解析域名，设置反向代理

把域名wallos.mydomain.org解析到服务器ip地址。

这里用的是Caddy V2，Apache和Nginx用户请自行同理可得。

nano /etc/caddy/Caddyfile

加入以下内容:

TEXT

wallos.mydomain.org {
 reverse_proxy localhost:8282
}

重载一下Caddy: systemctl reload caddy

打开浏览器访问wallos.mydomain.org，看看是否正常。创建管理员账号，设置首选货币等，此处不再赘述。

Telegram机器人绑定

进入Wallos，点击头像，点击[设置]，点击[通知]中的[Telegram]。

打开Telegram，向@BotFather发送/newbot，按照提示操作。

创建完成后，BotFather会发送一条信息:

TEXT

Done! Congratulations on your new bot. You will find it at t.me/<botname›. You can now add a description, about section and profile picture for your bot, see /help for a list of commands. By the way, when you've finished creating your cool bot, ping our Bot Support if you want a better username for it. Just make sure the bot is fully operational before you do this.

Use this token to access the HTTP API:‹yourapi›
Keep your token secure and store it safely, it can be used by anyone to control your bot.

For a description of the Bot API, see this page: https://core.telegram.org/bots/api

把获得的<yourapi>填入Wallos Telegram通知的第一栏。

浏览器访问https://api.telegram.org/bot<yourapi>/getUpdates，回到tg点击t.me/<botname>给你的机器人发条消息，然后浏览器刷新，即可获得一个JSON文件，其中键"id"的值就是你的chat id，把这个值填入Wallos Telegram通知的第二行，勾选启用，点击测试。

如果tg机器人给你发送了消息，说明配置成功运行。接下来只要为订阅设置通知日期，就可以静待Wallos的自动提醒了!

Logseq插件市场无法打开

Mon, 10 Feb 2025 18:16:00 +0800

首先看一下小猫咪在哪个端口运行，一般原版clash和mihomo party是7890，clash verge rev是7897。

把logseq的网络代理改为system 127.0.0.1:<小猫咪端口>

有的人可能到这里就解决问题了。

如果你解决不了，刚好又是Linux的话，可以继续看一下。

我在看obsidian的git插件readme时忽然福至心灵，插件作者对Linux用户说Flatpak is not recommended, because it doesn’t have access to all system files.我突然想到自己的Logseq也是flatpak，于是打开Logseq官网下了一个AppImage当对照组，果然AppImage可以连接插件市场，问题解决了。

docker搭建owncloud和onlyoffice并使用caddy反代，实现在线编辑文档

Mon, 10 Feb 2025 15:05:00 +0800

前置条件：Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz 1 Virtual Core；Debian 12 bookworm；Caddy v2；docker 和 docker compose

owncloud使用docker compose部署，首先创建一个你自己喜欢的目录，等下我们把这个docker容器中的文件映射到这个目录。命令：mkdir whatever/path/to/owncloud && cd whatever/path/to/owncloud

编辑一下dockerfile：nano docker-compose.yml，模板来自官方：

TEXT

 volumes:
 files:
 driver: local
 mysql:
 driver: local
 redis:
 driver: local
 
 services:
 owncloud:
 image: owncloud/server:latest
 container_name: owncloud_server
 restart: always
 ports:
 - 8080:8080 #左边改成你自己喜欢的端口
 depends_on:
 - mariadb
 - redis
 environment:
 - OWNCLOUD_DOMAIN=owncloud.mydomain.org
 - OWNCLOUD_TRUSTED_DOMAINS=owncloud.mydomain.org,my_ip_address 
 #注意，如果要添加多个信任域名/ip，用半角逗号分隔，不要加空格，不要加端口号。
 - OWNCLOUD_DB_TYPE=mysql
 - OWNCLOUD_DB_NAME=owncloud
 - OWNCLOUD_DB_USERNAME=owncloud
 - OWNCLOUD_DB_PASSWORD=owncloud
 - OWNCLOUD_DB_HOST=mariadb
 - OWNCLOUD_ADMIN_USERNAME=admin
 - OWNCLOUD_ADMIN_PASSWORD=Th1sPa$$wordIs$uper$ecret!
 - OWNCLOUD_MYSQL_UTF8MB4=true
 - OWNCLOUD_REDIS_ENABLED=true
 - OWNCLOUD_REDIS_HOST=redis
 healthcheck:
 test: ["CMD", "/usr/bin/healthcheck"]
 interval: 30s
 timeout: 10s
 retries: 5
 volumes:
 - files:/mnt/data
 
 mariadb:
 image: mariadb:10.11 # minimum required ownCloud version is 10.9
 container_name: owncloud_mariadb
 restart: always
 environment:
 - MYSQL_ROOT_PASSWORD=owncloud
 - MYSQL_USER=owncloud
 - MYSQL_PASSWORD=owncloud
 - MYSQL_DATABASE=owncloud
 - MARIADB_AUTO_UPGRADE=1
 command: ["--max-allowed-packet=128M", "--innodb-log-file-size=64M"]
 healthcheck:
 test: ["CMD", "mysqladmin", "ping", "-u", "root", "--password=owncloud"]
 interval: 10s
 timeout: 5s
 retries: 5
 volumes:
 - mysql:/var/lib/mysql
 
 redis:
 image: redis:6
 container_name: owncloud_redis
 restart: always
 command: ["--databases", "1"]
 healthcheck:
 test: ["CMD", "redis-cli", "ping"]
 interval: 10s
 timeout: 5s
 retries: 5
 volumes:
 - redis:/data

然后 docker 启动！ docker compose up -d

接下来就是把域名owncloud.mydomain.org解析到服务器ip地址，（这个时候编辑caddyfile并重启caddy也可以，不过我们装完onlyoffice再一起改）等下的onlyoffice也需要一个域名，所以解析的时候顺便把office.mydomain.org也解析到服务器的ip地址吧。

可以使用docker ps查看owncloud和依赖有没有正常运行，如果不行，看一下docker compose logs -f，排查原因。如果行，登录你刚刚在docker-compose.yml里面设置的owncloud管理员账户，进行基础设置，然后到owncloud的应用市场market里面下载onlyoffice这个应用。

owncloud设置大功告成，可以开始设置onlyoffice了：

我们在你喜欢的端口（比如12345）上面跑一个onlyoffice的docker 容器：

TEXT

docker run -i -t -d -p 12345:80 --restart=always onlyoffice/documentserver

这个时候运行一下docker ps，查看刚刚创建的这个容器id，然后运行：

TEXT

 docker exec <onlyoffice-container-id> /var/www/onlyoffice/documentserver/npm/json -f /etc/onlyoffice/documentserver/local.json '
 - services.CoAuthoring.secret.session.string'

可能就有人要问了：这个命令是干嘛的呢？

运行之后返回的字符串是我们onlyoffice的JWT secret key，等下在owncloud里面设置要用。把这个字符串记下来，下文中我们会用<JWT_secret>指代它。

好了，现在我们来设置Caddy吧。之所以在这一步设置Caddy，是因为onlyoffice（以及collabora online）要求服务端和客户端使用同样的协议，比如同为https或者同为http。我们使用Caddy进行反代，Caddy会自动给域名申请证书，这样owncloud客户端和onlyoffice服务端都是https协议的了。

如果你用的是nginx或者apache，也是一样的，如果需要https，请给两个域名手动申请证书，这里就不详细展开了。

我们编辑一下caddyfile吧：nano /etc/caddy/Caddyfile 加上下面这两行：

TEXT

 owncloud.mydomain.org {
 	reverse_proxy localhost:8080
 }
 
 office.mydomain.org {
 	reverse_proxy localhost:12345
 }

保存并退出，重载一下caddy：systemctl reload caddy

现在通过owncloud.mydomain.org可以以https访问我们的owncloud实例了。进入owncloud设置，左菜单栏下滑到底部选择“额外的”，在这里你可以设置onlyoffice服务器。

我们在ONLYOFFICE Docs地址那里填入office.mydomain.org，在秘钥那里填入<JWT_secret>。

点击保存，大功告成！

尝试在owncloud文件中打开一个.docx结尾的文档，你会看到onlyoffice加载并启动。

好了，结束了！

吐槽一下：

这篇文章是在Logseq上面写的。Logseq也太难用了吧，这个块状排版真的不适合习惯普通段落式的人……尤其是代码块难用得蛋疼，一旦把一个块变为代码块就无法回到文本编辑模式了……

Logseq的多端同步也很糟糕，使用git自动commit让我不得不每分钟看见一次错误信息，而且iOS的git客户端Working Copy也比较贵。目前我的做法是Syncthing 在 Android手机和Linux PC之间同步，38块钱买一个iOS的Syncthing客户端Möbius Sync高级版（当然由于iOS的后台机制，功能是残废的）把iPad也加入同步链。Syncthing没有中心服务器，我又不能保证有一台设备24小时运行且可访问（这个问题在我整了台小主机之后解决了。我要试试用小主机当中心服务器看看是否改善），所以经常在同步后出现文件冲突，非常烦人。

iOS用户需要注意：Logseq只能打开本地文件夹，而且是在Logseq的iOS应用沙盒中的文件夹，这个问题没办法通过挂载云存储解决。要想和其他设备同步，只能在你的同步软件上面下功夫，让同步软件能够访问Logseq的应用沙盒，Möbius Sync如此，Working Copy应该也是如此（没用过）。

tabby使用插件cloud sync settings利用gitlab gist同步设置遇到的问题

Sun, 09 Feb 2025 16:49:00 +0800

我的PC系统是Manjaro Linux，用tabby当ssh工具。

tabby的官方同步需要自己host一个实例，我不太信得过自己的服务器手艺~~99.9%downtime~~，又想要经常备份，巧的是tabby插件市场有一个叫cloud sync settings的插件，可以通过s3/webdav/gist同步设置，于是我就选了gitlab的snippet（gist同步插件上的提示是github或者gitlab，但是据说gitee也行。没试过）

本来用得好好的，每20s同步一次，偶尔会报错，但是大多是网络问题，过一会就自己恢复了。

今天在使用的时候突然持续报错，每次同步都出错，我一看logs：

TEXT

error: Upload settings file from local| \
Exception: Error: Request failed with status code 400

我心想：莫非是access token过期了？

然而登上gitlab一看，我设置的期限是1年，还有11个月才会过期。

我试着rotate了一下，换了新的token，报错继续。

此时我发现test connection的时候是无异常的，报错是在开始尝试上传本地配置的时候出现的。

我试着把gist id留空，让它创建新的snippet，这下没问题了。

过了几分钟，我打开gitlab，看到snippet的编辑时间是just now，说明把配置同步到这个snippet没有问题，只有那个旧的snippet是不能用的。

我把gist id改回旧snippet的，果然还是不行。

这下只好用这个新的snippet了。这个插件的同步都是单向同步，可以选择是云端到本地还是本地到云端，我直接把最新的设置从本地传上去，继续使用。

（不过除了刚configure完那一下的方向可以选择，以后的同步都是本地到云端，这个不能改。也就是说假如计算机A、B都连接了同一个云端文件，A做出的改动传到云端，此时你打开计算机B，是不会看到A做出的改动的。B本地的配置文件会直接覆写云端文件。）

虽然找到了问题所在，但是我不知道原因是什么，等我去提个issue看看吧……

收到的回复：

I am not sure yet about the Gitlab issue with snippet, but as I know that Github limited the requests, I think Gitlab is also did the same thing, you can try to switch to other reliable provider like Dropbox, or S3.

Greetings from obsp.de!

Mon, 20 Jan 2025 09:10:00 +0800