对习近平个人生死的含蓄批评 @[email protected]

@sauricat 谁运营确实挺重要的，特别是这种社区项目

鉴于 m.cmx.im 经营状况发生的一系列变化，本账号故从 @MtFwiki 迁移至 @[email protected] 望周知

嘎站 评选大会：谁是你心中的 ？

有没有人做一个“联邦宇宙土皇帝”的表情？想搞个长毛象vip认证标志挂一挂（不是

@creator_rights 哈哈我来加深这个鱿鱼改花刀笑话。这个笑话是从我开始的，在我之前没有人戏谑过他们连鱿鱼改刀都搬运，目的就是想测试一下到底他们是不是有号在豆瓣和毛象对特定几个用户持续盯梢，他们做出针对这个只出现了十来次的笑话的回应，证实了这点。也就是说，对方是非常清楚我们所有人都对精选系反馈“赶紧删除停止侵权”的，鱿鱼改刀笑话的传播时间与诉求相重叠，你们不会只看到这个只流传在以我为圆心的几个人之间的破梗而看不到更频繁的删除诉求的。我下的饵，你们咬了，就这样。

@creator_rights 这下连社会公正也不推动了真就承认自己是content farm了呗...

fuck google’s new UI，现在联想关键词和同关键词不同搜索内容（图片、视频etc）视觉上无法区分了

还是记录一下昨天到现在发生的事吧，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多到什么服务都起不起来的时候，我真的是已经想提桶跑路了。

@ultrer 首先，长毛象上的投票显然不能和民主投票画等号，投票嘟文也从未表明投票结果会决定嘟站是否封禁Threads，也不存在所谓的“代表全站”一说。屏蔽Threads是管理员们作出的判断。
其次，nexus666 这位用户曾因多次在嘟站发表违反站规的言论（至于为何违规请看他的个人简介），在警告无效后已被封禁。封禁之后，他通过创建多个小号并发送私信和邮件的方式，对我们进行了多次骚扰，至今仍在坚持不懈对我们进行攻击。请知悉。