写了一个通过Docker搭建长毛象的指南。目前网络搜索到的指南都存在着过时、冗余的问题,官方又没有给出docker文档,于是在 @star 大佬的帮助(手把手带路)下写出了这样一篇。

pullopen.github.io/2020/10/19/

对新手而言,docker优点在于搭建、维护和升级都相对简单,升级速度快不需要precompile,乱搞(……)也不怕把系统弄坏,直接重启就能恢复。缺点就在于魔改起来会比较麻烦,需要一些进阶操作。当然通过一些方法,可以在维持魔改不变的情况下享受docker的安全,如何操作我会在以后的文章中详细说明。
希望能给大家带来帮助!

#长毛象建站 #长毛象中文使用指南

:blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky:

Markdown 和 HTML 来啦

:blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky::blobcatrainbow_shaky:
rhabarberbarbara.bar/@barbara/
如果只是想 copy paste 的话并不难实现,毕竟本站长也是完全是 copy paste 了 glitch-soc 里的文件,用的是 ruby 的 Redcarpet,它会把 markdown 翻译成 html,在 gemfile 里加一下就好。其他要改的文件就是 app/lib/formatter.rb 和 lib/sanitize_ext/sanitize_config.rb,我这边没有设置按钮选择是否纯文本,全都默认成 markdown/html 了,所以把原代码里的 status.content_type == 'text/markdown' 之类的都删了。
这些做完之后其实 html 格式的文本就已经可以传到网站上了,然而 app/javascript/styles/mastodon/reset.scss 这个奇怪的文件硬是把大部分格式都 reset 了,所以我挑了几个眼熟的比如 b q h123456 删掉了,大家也可以自己看着办,此外我还给 ordered list,unordered list,blockquote 加上了大家比较熟悉的格式。
这次涉及的 commit 全都在这里, 改好之后需要 bundle install && yarn install, 然后 RAILS_ENV=production bundle exec rails assets:precompile,最后

systemctl restart mastodon-sidekiq
systemctl reload mastodon-web

就好啦。
已经测试和 mstdn.social 站可以互相看见,其他的不清楚,欢迎告知。不支持的网站看着应该是纯文本,但貌似可以看到超链接。请直接戳链接看效果。
#建站日志

显示全部对话

#长毛象运维
昨天我发现本实例(mastodon.sbpk.fr)与联邦宇宙部分站点通信出现问题,包括dragon-fly.club和mastodon.social,表现为本站能够获取外站的公开信息,但是需要身份验证的请求无法完成。查询Sidekiq日志后发现大量401错误,与上述现象符合。后在mastodon.social上注册帐号,并在上面搜索自己的帐号(@wsb),提示503错误:无法验证远端的SSL证书。

我使用SSL Labs检测自己的SSL配置,发现并没有问题。一开始怀疑是外站不支持SNI,配置好无SNI情况下的SSL设置,但并未解决问题。后来意识到可能是本站服务器只支持TLS 1.3,版本过新导致错误,启用TLS 1.2后通信问题解决。怀疑问题由外站使用的SSL库版本较旧,不支持TLS 1.3导致。

【关于bgme.me实例刚才下线的说明】

刚才为了解决与 2to2.xyz 实例的通迅问题,变更Mastodon的配置。
然后重启服务,发现 mastodon-web 服务无法启动,报错:warning: already initialized constant Net::ProtocRetryError

通过关键词搜索,找到如下两个 issue:
github.com/mastodon/mastodon/i
github.com/ruby/net-imap/issue
经阅读,发现这个问题更新ruby版本之后依赖有关。而且所有的“Docker”用户也受到这个问题的影响。
官方的建议是:直接升级到主线版本。

尝试升级至主线版本,编译静态文件时出错,提示:/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/ffi-1.15.3/lib/ffi/library.rb:112: [BUG] Segmentation fault at 0x000│00000000ed028
经搜索发现这个issue:
github.com/mastodon/mastodon/i
阅读完整个issue,大致了解到这是ruby自身的bug,升级到 Debian 11 Bullseye 便会触发。要想彻底解决掉这个bug,需要上游修复。
按照里因的建议,完全重新安装ruby以及mastodon,临时设置 LD_PRELOAD=libjemalloc.so 环境变量解决了此问题。

总而言之:
v3.4.1 这个版本已经不太稳定,如果现在新安装 Mastodon 的话,建议直接安装主线版本。
此外,如果你的实例打算升级系统版本,要特别小心。

#实例维护


发现跨站轴的更新频率有点不对劲,才意识到moew的中继( mastodon-relay.moew.science )挂了。

中继对于没有开 Secure Mode 的中小型实例来说是一种公共基础设施的存在。有条件的话应该多加几个,这样更能增加联邦的健壮性。moew已经是最大中文中继了,如果这个顶得住,那再加几个应该也没问题。

值得站长留意的是,中继挂了在管理后台是没有显示的,添加中继也不是一劳永逸的。有些中继在故障恢复后,需要禁用+启用才能重新出现在订阅列表中。比如之前 relay.mastodon.funneko-relay.com 都出过这种问题。

顺便一提,如果同域名站点重建也会连不上中继。例如nya中继 ( relay.nya.one )里本站的那些个“签名未认证”的记录,就是曾经试图从头重建实例造成的。

其实关于是否要鼓励小白建站也有争议的,一方认为估计没有防御能力的小白建站会导致个人的风险增大,另一方则认为只有多多建站才能分散风险,因为墙也是需要成本的。
从目前来看,针对活吧的墙也仅仅是最低等级的DNS污染,所以我个人可能更倾向后者?


我觉得实例的多样性是重要的,应该鼓励更多的人,特别是身处国外的人建站(国外身份也更容易薅羊毛)。

运维技术不应该成为过高的心理门槛,可以在实践的过程中慢慢积累。

当然,还是有些事情是一开始就要留意的:
1. 保护好站长自己的隐私,尽量与自己的其他数字身份做彻底的分割,消除与真实身份关联的蛛丝马迹;
2. 考虑网站被刷量攻击的风险,隐藏好敏感信息,预演最坏的情况做好预案;
3. 开放注册要负责任,要把用户规模控制在与自己运维能力相符的程度。建议先自己折腾半年以上再开放注册,以免激情建站的劲头消散。

@flyover

```
SMTP_SERVER=smtp.yandex.com
SMTP_PORT=587
SMTP_LOGIN=邮箱帐号地址
SMTP_PASSWORD=此处密码要在账户中心单独生成
```

除了这四行之外的和 smtp 有关的设定暂时全删掉试一下。

这几天的攻击分析下来,验证了两个重要的经验:
1.不要暴露源站IP地址
2.不要暴露对象存储桶名

第2点之前讲过了,再多说说第1点。

如果源站IP暴露,遭到4层的洪水攻击,很容易导致源站瘫痪、进黑洞。一旦如此,源站就失联了,想套CDN都来不及。
黑洞的情况不仅会出现在比较高质量的线路,普通线路+支持高防的商家有时候也会顶不住。

保护源站的常见思路是套CDN。但很多人之所以不这样做,就是看中当前源站的线路质量远比CDN好。这时其实可以把“源站”和“加速”两个功能拆分。“源站”选择高配+普通线路,“加速”选择低配+优质线路。对外只暴露“加速”机和CDN的访问。

顺便一提,这种方案的源站比较适合放在北美。不光是因为服务器的性能、带宽比较便宜,还因为很多CDN服务大陆的节点就在北美。

几种泄露源站IP的途径

1.历史DNS记录
2.子域名直接暴露
x.threatbook.cn/
dnsdb.io/
site.ip138.com/
searchdns.netcraft.com/

3.IP扫描+证书泄露
search.censys.io/
fofa.so/
(可以直接访问https://源站IP,看看有没有把域名证书漏出来)

看了下 SeaweedFS 的文档,发现整体架构分为 master、volume、filer 三类节点:

Volume 节点负责存储数据,大量小文件会整合成多个大volume存储,并以此为单位进行冗余。index可以存在内存,也可以存在LevelDB以节省内存

Master 控制所有的文件系统节点,可以是奇数个。

Filer 负责建立文件系统到用户路径的关系,支持fuse挂载、WebDAV、s3、HDFS等。路径和metadata信息可以存储在各类主流数据库。

在数据安全方面:

Filer 支持把数据加密后放在 Volume 落盘,密钥存放在 filer 的metadata数据库中。

Filer 支持同时运行多个副本。支持把目录和数据备份上云。

节点之间的通信支持 http REST 和 gRPC。其中 gRPC 支持双向TLS。

给各位毛象站长update一下迁移到AWS S3后的费用,第一个月因为迁移花了钱账单比较高,有24.91USD,这个月还没完,但是看billing已经有5+了,估计最后是7USD左右。

本实例活跃人口300左右,加入了中继所以拉取fedi图片也比较多,有每周定时任务清理Fedi老图片。

换AWS S3做媒体库整个实例的开销就涨了一点,但是服务质量确实好,这一个半月图片服务稳如山快如电!

欢迎有趣的中文实例加入 Relay: mastodon-relay.moew.science (此条在我服务器被撑爆掉之前有效)

⚠️ 站长注意

部分对象存储在接收到错误的路径时,返回的信息中会带有桶名或者endpoint的名称。

Mastodon 要设置 elastic search 中文优化是不是必须修改源文件?

如果是 docker 部署的是不是自己维护一个镜像比较方便?

关于 sidekiq 线程数 

如果你自建实例的话,选择适当的 sidekiq 线程数是很重要的。
大体上来说就是根据机器性能尽可能选择较大的 sidekiq 线程数。长毛象主线默认 sidekiq 线程数为25,如果你实例的vps是 DigitalOcean 5$ 每月的廉价机器,将 sidekiq 线程数设为25 ,可能会导致机器负载过高,尤其是在转码时。这时你可以适当调低 sidekiq 线程数。
sidekiq 线程数的下限以实例不会出现 sidekiq 任务堆积为原则。如果你将 sidekiq 线程数调高至您的 vps 所能承受的极限,但 sidekiq 队列中仍存在任务堆积的情况,这就提示您需要更换性能更强的机器了。

如何判断实例 sidekiq 任务是否堆积,对于实例管理员而言,可以直接打开 sidekiq 管理页面,然后查看 queues 选项卡中任务堆积情况。
对于实例所在用户而言,可以能过向其他实例发嘟来间接测量所在实例任务堆积情况。
对于其他实例用户而言,可以通过发出关注到实际成功关注两个操作之间的时间差来间接测量。比如说:你关注某实例一未锁嘟用户,你在你的实例点击关注之后(你所在实例不存在 sidekiq 任务堆积问题),由于Mastodon的关注机制,虽然在你的实例上查看该用户会提示你已经关注,但此时可能并没关注上,这时你可以尝试将该用户添加至列表,你会发现添加时会返回404状态码,无法将该用户添加至列表。你可以通过反复尝试添加至列表操作,来以此确认实际成功关注该用户的时间。点击关注按钮到成功关注,这两个操作之间的时间差间接反映了远程实例的sidekiq队列堆积情况以及sidekiq线程数。
#长毛象中文使用指南 #长毛象运维

@[email protected]
我个人不推荐使用 tootctl statuses remove 命令。

首先,嘟文并不会占用太大的磁盘空间,就比如说本站,从来没有执行过 tootctl statuses remove 命令,建站也1年多了,statuses所占据的空间也才3G多。tootctl statuses remove 命令真的节省不了多少空间。
第二,移除不相关嘟文极大劣化了用户体验。具体表现就是,本站用户查看任何一个无关注的外站用户,都将加载不出来她的嘟文,主页一片空白。对于通过中继相互联通的各个中文实例来说,tootctl statuses remove 命令对于用户体验的影响真的很糟糕。
第三,长毛象执行tootctl statuses remove 命令时,会进行大量查询,并创建一系列临时表,这将消耗大量CPU与内存。如果你本来就是5美元每月的小鸡,执行这样的操作无疑会给你的服务器本来就很高的负载雪上加霜。

综合上述三条理由,我强烈不建议运行 tootctl statuses remove 命令。
#长毛象管理 #长毛象运维

做站长的确实有必要推演一下,如果遭遇了刷量攻击,自己的钱包会面临多大的风险。

这个风险主要在两个环节,一个是服务器的流量,一个是对象存储的流量。

服务器方面,最好选择不限流量或者限制很宽的服务器。即便如此也要了解一下,万一超了会发生什么。安装一个服务器监控程序有助于及时发现问题。超流量报警、断网应该能找到现成的方案,WAF也有不少是开源的。

对象存储方面,大厂在出方向一般是收费的。媒体在传递给用户之前,最好套一层缓存。这个缓存可以是大流量服务器上的nginx,也可以是CDN。缓存要防范被击穿的可能(比如查询字段)。如果使用CDN,可以多多关注WAF功能以便不时之需。懒得搞也可以选出方向免费的对象存储提供商,但他们的稳定性可能稍差。此外,要尽量避免暴露存储桶名。

当然我也不是这方面的专家,有缺漏欢迎补充。

显示更早内容
长毛象 · 壹头

长毛象是开源的微博客程序,这里没有玄学的审查和限流。本站采用原版程序,开启全文搜索(收藏)。积极治理公共时间轴,但基本不屏蔽外站。支持多账户登录,对注册和使用有要求。