我鳗鱼 也是一只自由泳的小鸟 @[email protected]

还是记录一下昨天到现在发生的事吧，In case 其他站长像我一样无知且大胆，遇到类似困难状况可以参考。

事情起源于近期 utopia.cool 升级了 mastodon 版本（4.1.2 --> 4.1.3）。
4.1.3 版本修复了一些安全缺陷，其中包括禁用 ImageMagick 的较低版本（<6.9.7-7）。
而我站的服务器是 Ubuntu 18.04 版本，从官方apt源能获取到的最新 ImageMagick 也不满足此要求。所以我们的图像处理相关功能都出错了。（ImageMagick 问题详见官方的介绍：https://github.com/mastodon/mastodon/issues/25776 ）

此时有几种解决方案，在18.04上自行编译一版 ImageMagick 也许可行。但为了避免未来有更多组件出现没有官方源更新的问题（Ubuntu 18.04 已经停止维护），我选择了升级 Ubuntu 到 20.04。

OK，噩梦开始了。

尽管我事先做了周密的备份，系统升级过程依然艰辛。
Ubuntu 升级前，要求所有可用的 apt 更新都已执行。所以我被迫执行了一次全局的软件更新——这导致 elasticsearch 升级到了插件无法支持的版本。所以本站的全局搜索功能挂了。（我后来通过手动降级 elasticsearch 解决了它）
然后，升级系统的过程把 PostgreSQL 从大版本 10 升级到了 12。系统升级完成后，PostgreSQL 要求执行数据集群迁移10 --> 12。
这个迁移是必须做的，psql 12 不保证能在 10 的数据库上正常工作。我借助 chatGPT 的帮助尝试执行迁移。却完全被这东西的编码格式困住了。无论把编码设置成什么，要么报错说跟旧版数据库编码不符，要么报错说缺乏支持 LATIN1 的编码。等于说新版跟旧版分别对一些方面进行了限制，而同时满足两边条件才能成功执行 pg_upgradecluster。最后我选择了放弃，直接把10版本的数据库 dump 出来，再用12来 pg_restore。也就是备份-->恢复这条路径。OK，这条路是走得通的。（虽然遇到一些问题，后面补充）

好，我们假设数据库的大问题已经解决了。当我尝试重新构建 Mastodon，发现整个 bundle 的依赖关系都坏掉了。由于此前安装的 bundler 没有按照 Ubuntu 的方式进行包管理，所以它没有被系统升级过程管理起来——系统的其他组件升级了，bundler没有。此时 bundle 执行任何命令都会报错，大部分是依赖错误、试图调用系统内某个动态链接库失败。
行吧，为了解决这个问题（和潜在的其他问题），我们需要按照官方教程从头安装 yarn 和 Ruby 和 Bundler，并把它们配置为正确的版本。

如果你像我一样愚蠢，安装新版时没有清理掉旧版残留的依赖包，问题就更大条啦，你会在执行 bundle exec rails assets:precompile 的时候被异常信息淹没。这是因为 bundle 并不会主动检查它此前下载的依赖包的完整性和正确性，而那些在旧系统内构建的包是无法在新系统内工作的。
如果你明确知道出问题的包是哪个，可以这样卸载它再重新安装：
bundle exec gem uninstall ffi
bundle exec gem install ffi
并且我尝试让 bundler 重新编译所有的依赖，来修复任何没被发现的问题：
bundle check
bundle pristine

假设上面提到的问题都解决了，你正确地构建出 mastodon，还是需要额外处理数据库的一些细节：
首先，你执行上面提到的任何数据库操作时都有必要确保 mastodon 相关的几个服务已经停止。否则数据不一致问题会困扰你。
其次，前面升级 PostgreSQL 时，它在原先的端口 5432 保留运行了旧集群 10 main，而你使用的新集群 12 main 可能工作在 5433 端口。你需要重新配置 mastodon 的 .env.production，修改里面的数据库端口，才能指向新集群。
另外，如果你像我一样选择导出、导入的路径来实现数据迁移，那这个过程中可能没有正确地给 mastodon 用户分配数据库权限。请在导出前确认好它所需的权限，并在导入后把缺失的加回来。当然，如果你选的是 dump_all，可能权限配置也一起导出了，根据自己情况处理。
然后，在导入数据库到 12 main 时，实际上报了几个错，是关于 unique index 的，某些索引在建立时发现了重复的 key，导致建立失败了。这个问题不会中断导入，所以你的数据暂时是完整的。但是缺少索引会影响之后的数据查询效率，需要想办法解决。
我到现在还不知道有没有解决这个问题，我试了这些命令：
tootctl maintenance fix-duplicates
reindexdb --all
站点恢复运行之后我发现访问起来还是相当的慢，研究了一番，发现每个用户的 timeline 都是在后台临时构建。按我理解，这个 timeline 应该是事先准备好的，所以我又找到了这个命令：
tootctl feeds build
它基于现有的数据，重新预构建了每个用户的 timeline。

其他杂七杂八的小问题还很多，但最有风险并且难懂的就是上面这些。
结论就是任何人要新建 mastodon 站点的话务必使用 docker 版本。
并且不推荐0基础运营公开站点，为太多人的数据负责，却又草率行事，后果真的可能很糟糕。

虽然 mastodon 的文档已经算是很完善的了，但还是引我走向了一个又一个的大坑。
对我来说倒是终于深刻理解了，为什么生产环境能不动就不动。不出问题还好，像昨天晚上，升级进行到一半，bug多到什么服务都起不起来的时候，我真的是已经想提桶跑路了。

如果男性真的不清楚什么是对女性性骚扰的边界……请在要对女性做接下来的动作、身体接触，说话之前请先多问问可以吗……？请多问问“如果我做xxx的话你会不会不舒服？”，“我在这种情况下可以说xxx吗？会不会让你觉得讨厌？”，“我可以碰你的（e.g. 肩膀）吗？”，“请问你愿意让我拍一张照吗？”……诸如此类。如果过去几十年来真不懂、没有人教过的话，你可以问，你可以现学。这不会让你显得很笨、很没面子、失去男性气概，而是可以让你起码看起来很谨慎、有分寸、看起来能尊重人。如果你觉得这样的你会像一条“舔狗”，或者什么都不想付出就得到来自异性的性与爱的话……你真的好可怜，不知道什么是爱，也不知道什么是尊重。被嫌厌是你最好的归宿呢。