自托管服务 on cyp0633's Blog

我最终还是放弃了自己托管邮箱——转为了 Fastmail

Sun, 01 Oct 2023 22:46:00 +0800

不可否认的是，maddy 是一款非常优秀、令人舒适的邮件服务器软件，关于安装，我写过一篇文章¹。在使用它的接近两年内，除了升级，我完全没有动过它，就连升级时也基本是无痛的。如果谁仍然想要自建一个邮件服务器，我还是会推荐maddy。五美元一月的Vultr托管邮件也十分稳定，25端口也只需要开个工单就能开通，同时Maddy占内存极小，跑点儿其他的也不亏。一切都按预期正常工作着，但还是有一些放弃自己托管的理由：

有时会当成spam，这个得怪收件人信箱，但确实是个普遍问题²；
没有一个好用的webmail，之前用的Rainloop总感觉差那么点意思，而且独立的webmail总要多占一份空间；
担心downtime，所以非常要紧的服务一直都用Gmail ~~（实际上downtime比我梯子挂掉的时间还少）~~ ；
每个月得花 $5，虽然不多，但是也不少（手上其他服务器不给开25端口）；
~~大四闲得慌。~~

Maddy作为部署简单、功能全面的邮件服务器可以说是先行者了，现在也涌现了许多很好的自托管服务，比如 mox 解决了webmail的问题。当然这篇文章写出来不是为了推荐自托管服务的，这个话题可能也不是由我来讨论了。

之所以想到放弃，缘于前两天看到了一个 V 站的帖子，然后看到了最低19美元一年的 Migadu，学生开工单享受半价优惠。这家从文档到服务都非常实诚，只按照使用量（收发量、邮件存储）计费，（几乎）不限制域名和邮箱数量，每个邮箱有自己的收发件箱，ToS里全都是“只有best effort服务，但是真的best effort"，域名数和使用空间等限制都是软限制，稍微超出一点儿也不打紧，甚至还在文档里diss了友商所谓的“加密”³。当然最重要的原因是我可以省下每年60美元的服务器，一年就能省下350块钱。

但Micro套餐内仅有5GB空间和每天20封邮件，虽然都是软限制，可以偶尔超过，但考虑到我博客的评论系统有回复自动发邮件提醒，万一评论区两个人对起线来……如果是Migadu，我可能只能选择90美元一年的Mini套餐了。这两个之间差价有点儿大，于是看向了Fastmail。Standard套餐50美元一年，还是能省下70多块钱；空间和发信量的痛点也都解决了，虽然是统一的信箱但是也不影响使用，也能使用不同的地址进行收发。如果不想用自己的域名了，还可以再添加一些Fastmail提供的后缀结尾的邮箱（甚至有 @fastmail.cn）。

如果抛开套餐用量比较两家的服务，我认为它们走了两条不同的路：Migadu为本就是tech-savvy的用户服务，将尽可能多的技术细节提供给用户，只做最纯粹的电子邮件，推荐的也是开源邮件客户端和开源迁移方案；而Fastmail更多的面向普通用户，可以直接导入Gmail等服务，针对每个IMAP客户端有应用专用密码，甚至连域名都可以在它那里买。

整理一个表格，对比Fastmail和Migadu套餐的区别：

套餐	Fastmail	Migadu
年付价格 (USD)	50	19 (Micro) / 90 (Mini)
每天收/发限制	/	200/20 (Micro) / 1000/100 (Mini)
存储空间	30GB	5GB (Micro) / 30GB (Mini)
多地址/域名处理	单个域名；可添加邮箱地址，共用一个信箱	无限邮箱，无限域名，各有单独信箱
其他服务	日历、联系人、记事本	日历、联系人（beta）

如果Migadu能够以50美元一年以下的价格提供一个存储&发信多一点儿的套餐，我决策时一定会选择它；然而没有，所以还是投奔了Fastmail。

如果只有中国手机号，Fastmail的注册会卡在手机验证码的一关，开工单就能解决；如果使用其他人的referral，也需要在工单里说明，客服会手动加上首年10% 的优惠。Fastmail和Migadu两者应该是都不支持支付宝和微信的，但支持PayPal（中国版支持不明）和Stripe（理论上支持银联卡）。

Fastmail有一个迁移向导，输入原来的IMAP服务器、账户名称和密码，就能把信箱搬过来了，功能倒是很像IMAPSync，只不过在它的服务器上运行。效果不错，迁移也很快，非常舒服。

不得不说，国内的访问体验确实有点慢，远比不上国内的服务 ~~（废话）~~ ，但相对之前自建的速度其实快多了。说真的，只要不被墙就很好了。

尴尬的是，迁过来的消息总共只用了0.1GB；又翻了翻一直以来用的QQ邮箱和Gmail，分别用了146MB和420MB，这么看的话5GB的空间还是长期够用的。又转念一想，我博客这个鸟不拉屎的地方也基本没人发评论，每天20封其实也够用了。意识到这个问题后，再次反思放弃自托管的五个理由，发现只有最后一个最真切。别说了，几年前那股折腾劲儿又上来了。

最后，如果你也想找个邮件托管商，我推荐Migadu的Micro套餐，完全够用；如果你订了Fastmail，可以使用我的 referral 注册，你享受首年10% 优惠，我也可以每月得到约0.5美元的余额。

同步 iCloud （云上贵州）日历

Mon, 10 Jul 2023 21:52:50 +0800

作为一个Android + Apple + Windows用户，寻找跨平台数据同步方案一直是一大难题，日历也不例外。纵观全局，日历同步服务倒也不少，比如Google、Outlook和iCloud等，但Google国内根本连不上，Outlook托微软的尿性也不稳定，我这次又懒得自己部署一个，此时iCloud就成为了一个好选择。

iCloud使用的也是通用的CalDAV协议，然而iCloud并没有一个开放的CalDAV配置指引，甚至连服务器都不给。手动配置也不难，要配置一个CalDAV客户端，一般需要服务器地址、用户名和密码。用户名就是你的iCloud邮箱地址，即xxx@icloud.com。

macOS 上并不支持授权 CalDAV

客户端支持情况

有的日历客户端需要手动配置服务器地址，但有的不用。但除了iOS和macOS系统自带的日历客户端，其他大部分都需要获取App专用密码。

以下是我使用过的几个客户端，以及它们对手动配置服务器地址的需求情况：

iOS、macOS等苹果第一方客户端：当然不需要
MIUI日历：不需要（不含HyperOS）
Windows日历：不需要
Thunderbird：需要*

* 可以使用TbSync插件同步国际版iCloud，但不适用于云上贵州

如下图，需要手动填入“位置”的即为需要获取服务器地址。

Thunderbird 创建新日历

获取密码

众所周知，仅凭Apple ID和其密码当然过不了二步验证，验证码都没地方输。好在可以创建App专用密码。

在 Apple ID 管理页面的下方找到 “App专用密码”，创建一个，然后暂存下来，这个密码之后不会再出现。每个专用密码都等效，所以建议对每个应用使用不同的专用密码。

App 专用密码

获取服务器地址

方法一：分析请求

苹果没有给服务器地址，但网络上有现成的获取方法，如这个。但是已经过去了五年，在云上贵州的环境中又有点不同。长话短说，就是把icloud.com换成icloud.com.cn，然后自己摸索起来应该也不难。

仿照那个教程的获取方法，iCloud云上贵州的CalDAV服务器地址格式为：

text

`1`	`https://<server-id>-caldav.icloud.com.cn/<user-id>/calendars/<calendar-id>/`

其中：

<server-id> 是数字和字母混合的字符串，我的是4位；
<user-id> 是一串数字，我的是11位；
<calendar-id> 是一个用 - 分隔的、全部大写的UUID。

需要注意，一个CalDAV地址对应一个日历，如果有多个日历必须在下面的步骤中重复操作。

现在打开你的iCloud网页版，打开浏览器的开发者选项-网络，然后在日历页面双击任意一个事件，进入详情。

在开发者选项中过滤“XHR”请求，然后找到传输这个事件详细信息的GET请求，例如下图：

找到这个请求URL，它大概是以下格式：

text

https://<server-id>-calendarws.icloud.com.cn/ca/eventdetail/<calendar-id>/<event-id>?clientBuildNumber=<some-random-text>&clientId=<some-random-text>&clientMasteringNumber=<some-random-text>&clientVersion=<some-random-text>&dsid=<user-id>&lang=<some-random-text>&requestID=<some-random-text>&usertz=<some-random-text>

或许你得到的request param会有所不同，但只要能找出你链接中的对应位置，提取出上面提到的三个ID就行了。如果发现提取不出来，请评论。

将上面三个ID填入上面的CalDAV服务器地址中，就可以得到你的CalDAV服务器地址了。

方法二：MIUI日历

更新：HyperOS的日历已经去掉iCloud登录功能。

如果你恰好有一台小米手机，那么可以直接在MIUI日历中添加iCloud日历，MIUI会自动获取服务器地址，也能正确处理云上贵州链接。在日历详细信息页面，你就可以提取出对应的日历地址。

MIUI 日历可以正确提取链接

方法三：工具提取

可以试一下以下的工具（未经验证）：

midnightmonster/icloud-calendar-urls（需要macOS环境）
muhlba91/icloud-caldav-urls

该如何安放你，我的照片

Wed, 11 Jan 2023 00:00:00 +0000

一个自行部署的照片托管解决方案伪横评（真水文）。

使用设备：Celeron N5105（无AVX指令集），16G RAM，512G SSD；Arch Linux，容器环境Podman

个人的需求其实很简单，只是一个相册分类 + 照片时间线预览。要说特殊需求大概就是有大量的HEIC图片，毕竟谁的空间也不是大风刮来的，另外最好能够用类MySQL。要说人还是闲不住，后面实测了Photoprism、Photoview和Immich，所以不知不觉变成真横评了。对于其他服务，可以看这个非常直观的表格。

以下依据为个人2024/06的照片库，约10000张照片，40GB。

Photoprism

photoprism/photoprism

算是比较早的开源相册方案了，基本功能令人安心，但使用略有不便，且设置界面可设置的项较少。

Photoprism 会直接生成标签

数据库支持：MariaDB（MySQL）和SQLite，比较友好。
部署：方式为容器，需要设置大量环境变量作为配置，而不能在网页上直接修改，较为繁琐。
资源占用：不索引时（不含数据库）占用内存42MB左右，索引时约为220MB；数据库中数据65MB，缩略图等数据15GB；容器镜像1.88GB。
文件管理：支持导入和外部资料库，后者不改变原有文件结构；HEIC等格式图片会自动转换为JPEG。
人脸识别：识别不出几个人，水平不大行。
搜索：提前给图片生成标签，可以搜索，也可以自行添加标签。

Photoview

photoview/photoview

官方认可 AUR，好耶！相对来说，手动安装过程是最简单而且符合直觉的。托打包者和开发者的福，在安装AUR后，只需要修改一下配置文件里的MySQL连接参数（或者直接改成SQLite），然后启动systemd服务即可。功能相对来说简单，不过对我来说够用。人脸识别的准确度很一般，但对我来说也是锦上添花的功能。

提示：如果不想或不能改变文件所有权，建议使用文件ACL setfacl -Rdm 命令为photoview用户授予循环继承权限。

用下来几天发现了两个主要的问题，一个是一次导入过多照片的时候会卡住（假完成），阈值大约100张，另一个是HEIC图片的EXIF可能不能正确识别（提了 issue）。自从作者不太积极开发这个项目之后，感觉基本停滞了。

虽然这个占用是真的小，但需要声明的是，索引的时候仍然会消耗较多CPU，除非每次都大半夜索引，否则还是没有想象中那么省性能的。

数据库支持：MySQL或PostgreSQL。
部署：有AUR，有Systemd部署文档，但个人建议直接用容器。
资源占用：索引时250MB，日常10MB；缩略图等数据占用存储4.5GB，数据库20MB，镜像1.38GB。
文件管理：完全尊重外部文件结构，不会改变。但索引有些小bug，见上。
人脸识别：聊胜于无吧，精度不大行。
搜索：基于文件名的搜索，别的都没有。

Immich

immich-app/immich

Immich也是后起之秀了，现在Star比前辈Photoprism还多。它相对来说就比较复杂了，占用资源也多很多，算上数据库下来五个容器（但看起来不久之后会变成 4 个）。但是相对的，可自定义度也高很多，尤其是机器学习的部分。

上述机器学习指的是人脸识别和图像搜索，均可以远程进行，即在性能强的机器上单独运行ML容器，然后通过API通信。这对人脸来说十分方便，因为较大的人脸识别模型占用很大，但对于基于CLIP的图像搜索来说就是另一回事了：不光在索引时需要机器学习模块，搜索时也需要。所幸CLIP搜索的原理为对图片和检索词分别生成向量，然后将两者进行对比，而消耗资源比较多的部分是生成图片向量，所以可以先用较强的远程机器生成图片向量，我NUC上的弱鸡CPU只用来跑检索。还算可以接受。

数据库支持：PostgreSQL+Redis，需同时运行。
部署：似乎十分复杂，个人建议直接用容器。Docker Compose好说，Podman的话会非常麻烦。
资源占用：索引时内存基本上吃完（这是我的NUC头一次吃SWAP），如果使用NVIDIA硬件加速机器学习，还会占用约5-8GB显存（因为我卡只有8GB）；平时内存占用约400+200MB；缩略图等数据占用5.7GB（可使用WEBP，降低了占用），数据库563MB，镜像1.6GB+790MB（若使用CUDA则为4.55GB）。
文件管理：同时支持导入和外部资料库。
人脸识别：用较大模型的时候准确度蛮高的。
搜索：基于CLIP的自然语言搜索，遥遥领先，但缺点见上。也可以根据人脸、设备等条件筛选。

结语

很缺资源的选Photoview，性能足够的选Immich，嫌Photoview还不够强的选Photoprism。

附录：将 Immich 部署为 Podman Pod

来源

默认以rootful方式部署，将文件放在 /etc/containers/systemd 或其子目录下，systemctl daemon reload 后 systemctl start immich-server.service 即可。

不要忘记修改下面的目录映射和环境变量。两个目录映射中，一个是内部存储（由Immich决定文件结构），一个是外部存储（保留用户的文件结构）。

Pod声明 immich.pod

conf

[Pod]
PodName=immich
PublishPort=2283:3001

immich.env

conf

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# Connection secret for postgres. You should change it to a random password.
# The two values should match
DB_PASSWORD=ZWEuFZHcEyuJJoR6
POSTGRES_PASSWORD=ZWEuFZHcEyuJJoR6

# The values below this line do not need to be changed
###################################################################################

DB_HOSTNAME=immich_postgres
DB_USERNAME=postgres
POSTGRES_USER=postgres

DB_DATABASE_NAME=immich
POSTGRES_DB=immich

REDIS_HOSTNAME=immich_redis

IMMICH_MACHINE_LEARNING_URL=http://immich_machine_learning:3003

数据库容器 immich-postgres.container

conf

[Container]
Pod=immich.pod
ContainerName=immich_postgres
EnvironmentFile=immich.env
Image=docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
Volume=pgdata:/var/lib/postgresql/data
HealthCmd=["/usr/bin/pg_isready"]
HealthStartPeriod=30s
HealthInterval=10s
HealthTimeout=5s
HealthRetries=5
Notify=healthy

[Service]
Restart=always

缓存容器 immich-redis.container

conf

[Container]
Pod=immich.pod
ContainerName=immich_redis
Image=docker.io/redis:6.2-alpine@sha256:51d6c56749a4243096327e3fb964a48ed92254357108449cb6e23999c37773c5
HealthCmd=["/usr/local/bin/redis-cli", "ping"]
HealthStartPeriod=30s
HealthInterval=10s
HealthTimeout=5s
HealthRetries=5
Notify=healthy

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

机器学习容器 immich-machine-learning.container（本地，无硬件加速）

conf

[Container]
Pod=immich.pod
ContainerName=immich_machine_learning
EnvironmentFile=immich.env
Environment=HF_ENDPOINT=https://hf-mirror.com
Environment=LOG_LEVEL=debug
Image=ghcr.io/immich-app/immich-machine-learning:release
AutoUpdate=registry
Volume=model-cache:/cache
HealthCmd=["/bin/bash", "-c", "exec 5<>/dev/tcp/127.0.0.1/3003"]
HealthStartPeriod=30s
HealthInterval=10s
HealthTimeout=5s
HealthRetries=5
Notify=healthy

[Service]
Restart=always

机器学习容器 immich-machine-learning.container（远程，CUDA加速）

conf

[Container]
ContainerName=immich_machine_learning
Image=ghcr.io/immich-app/immich-machine-learning:release-cuda
Volume=model-cache:/cache
HealthCmd=["/bin/bash", "-c", "exec 5<>/dev/tcp/127.0.0.1/3003"]
HealthStartPeriod=30s
AutoUpdate=registry
PublishPort=3003:3003
HealthInterval=10s
HealthTimeout=5s
HealthRetries=5
Notify=healthy
Environment=LOG_LEVEL=debug
Environment=HF_ENDPOINT=https://hf-mirror.com
AddDevice=nvidia.com/gpu=all

[Service]
Restart=always

微服务（如索引等）容器 immich-microservices.container（带有Intel QSV支持）

conf

[Unit]
Requires=immich-redis.service immich-database.service
After=immich-redis.service immich-database.service

[Container]
Pod=immich.pod
ContainerName=immich_microservices
EnvironmentFile=immich.env
Exec=start.sh microservices
Image=ghcr.io/immich-app/immich-server:release
Volume=/path/to/internal/storage:/usr/src/app/upload:z
Volume=/etc/localtime:/etc/localtime:ro
Volume=/path/to/external/storage:/usr/src/app/external:z
HealthCmd=["/bin/bash", "-c", "exec 5<>/dev/tcp/127.0.0.1/3002"]
HealthStartPeriod=30s
AddDevice=/dev/dri
HealthInterval=10s
HealthTimeout=5s
HealthRetries=5
Notify=healthy

[Service]
Restart=always

主服务容器 immich-server.container

conf

[Unit]
Requires=immich-redis.service immich-database.service immich-microservices.service
After=immich-redis.service immich-database.service immich-microservices.service

[Container]
Pod=immich.pod
ContainerName=immich_server
EnvironmentFile=immich.env
Exec=start.sh immich
Image=ghcr.io/immich-app/immich-server:release
AutoUpdate=registry
Volume=/path/to/internal/storage:/usr/src/app/upload:z
Volume=/etc/localtime:/etc/localtime:ro
Volume=/path/to/external/storage:/usr/src/app/external:z
HealthCmd=["/bin/bash", "-c", "exec 5<>/dev/tcp/127.0.0.1/3001"]
HealthStartPeriod=30s
HealthInterval=10s
HealthTimeout=30s
HealthRetries=10
Notify=healthy

[Service]
Restart=always

[Install]
WantedBy=default.target

网络上的其他讨论可见 Reddit 帖 1、Reddit 帖 2

Cloudreve：属于你的网盘

Sun, 08 Aug 2021 00:00:00 +0000

无论是搭建在互联网的服务器上、本地，还是局域网的其他设备上，Cloudreve 都能提供出色的云服务。对于个人，它存点资料完全够用；而对于组织，它也有账号管理系统，可以满足多人使用的需求。我是将它作为个人云使用的，除上面所说之外，它还有许多感知强烈的优点：

上传下载不限速，具体视服务器和客户机而定
文件实时在线预览 / 编辑 / 压缩
连接到其他存储服务，如Microsoft OneDrive、亚马逊S3等，当然也可以存在服务器端
Material Design网页界面，多平台、深色模式及PWA支持
支持文件分享，可选直链分享
WebDAV
配合aria2实现离线下载

相比官方原版OneDrive，它的网页端可以自由访问；而相比百度云，它就只有容量不占优了。

以下皆以amd64架构的Ubuntu 20.04为例。

部署

在服务器中合适的位置用 chmod 新建一个目录，然后下载 Releases 页面对应架构的软件包，解压即可。

对于负载不大的情况，可以直接使用Cloudreve自带的反代服务器，无需重新设置。

直接执行 ./cloudreve 即可使其前台运行，后台运行可以使用nohup。第一次运行建议截个图，内含管理员账号密码，用它登录进去之后可以在管理后台进行改名改密码等操作。

SSL

如果你想使用Cloudreve的OneDrive同步，你还需要HTTPS访问，而这需要一个SSL证书和一个域名。域名可以自己买，而这里主要解决SSL的问题。这里推荐使用Certbot来完成这个过程，它使用了Let’s Encrypt的服务。可以参考这篇文档的方法。简单来说，就是：

使用 sudo snap install certbot 安装certbot
运行 sudo certbot certonly --standalone（如果80端口没被占用）
依次输入你的邮箱和域名
记下证书路径和私钥路径
编辑Cloudreve文件夹下的conf.ini，加入以下内容：

ini

[SSL]
Listen = :xxx ; 将 xxx 替换为 HTTPS 访问该网站用的端口号，如 https://abc.com:xxx，推荐使用 443
CertPath = /etc/letsencrypt/live/abc.com/fullchain.pem ;abc.com 替换为你的域名
KeyPath = /etc/letsencrypt/live/abc.com/privkey.pem ; 同上

如果你已经在运行Cloudreve，先执行 killall cloudreve 再重新启动。

上传速度演示，受网速限制

到现在就可以使用服务器本地的硬盘空间作为一个网盘了。操作非常简单，我想我没必要再说了。但对于OneDrive，我觉得还得再提一句。

连接OneDrive

许多云主机的空间很小，装不下几个大文件，这时可以连接到OneDrive，支持个人用户或者企业 / 学校用户，以及各种Microsoft 365套餐。

在下载大文件的时候，主机直接连接微软服务器。

就是这么快……

在管理后台的”存储策略 “点击添加，然后按步骤操作。如果你用的不是公司 / 学校Microsoft账户，注册应用程序时需要选择” 任何组织目录…… 及个人Microsoft账户 “，后面才可以验证，否则会出现” 无法使用个人帐户在此登录，请改用工作或学校帐户“的错误。

添加完成之后，还需要在” 用户组 “设置里选择特定用户组使用的使用的存储策略，才能使用其他平台的存储空间。

OneDrive代理加速

可以参考这篇文章，Cloudreve的OneDrive反代原理是一样的。不过，如果你使用的是OneDrive个人版，获取到的下载链接类似于 https://public.bn.files.1drv.com，也是可以的，不必强求 SharePoint链接。

反代

我使用的是Nginx反代，所以当然以它为例。核心部分就是照着官方文档的配置，在Nginx的某个server中加入以下的location。

json

location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://127.0.0.1:5212;
    # 如果您要使用本地存储策略，请将下一行注释符删除，并更改大小为理论最大文件尺寸
    # client_max_body_size 20000m;
}

需要注意的是，Cloudreve目前（指3.3.2和3.4.0-beta1）并不能够使用二级目录反代，如设置 location ^~ /cloud，因为Cloudreve会在调用静态资源的时候访问不带二级目录的内容，即使 “站点URL” 中已添加二级目录也是这样。所以，我更推荐使用在Nginx里新建一个server，将另一个二级域名的根目录直接指向Cloudreve。只需设定不同的 server_name，Nginx就可以根据不同的二级域名来访问不同的服务，即使设定的listen端口相同。

参考文献

又水一篇，开心