序

最近、流行のためにFediverseサーバー(Mastodon, Pleroma, Akkoma, Misskey, Firefish, GoToSocial, Dolphin, e.t.c.)を建てる人が増えている。

だが、後先を考えずにサーバーを建てるのは愚者のすることだ。 最低限、他者に迷惑をかけないようにしなくてはならない。

この記事はサーバーセキュリティ構成の話を下地にした後編である。 この記事を読むにあたり、サーバーを安全に運用することができるようになっているか、もしくは信頼できるPaaSサービスを利用し、サーバー自体の維持管理はしなくて良いかのどちらかであることを前提する。 ただ、現状しっかりとしたPaaSサービスは存在してないように思われる。

本記事では「サーバー」が区別困難であることから、単に「サーバー」と言った場合はサーバーホストのことを指し、Mastodonなどのことは「サーバーアプリケーション」、Nginxのことは「webサーバー」と呼ぶ。稼働しているMastodon等は「インスタンス」と呼ぶ。

まず、Fediverseサーバーを建てるのは非常に簡単である。 しかし、コマンドをコピペするだけの者、あるいはそれを難しいと感じる者は手を出さないほうが良い。 さもなくば、何かあったらどう対応するのだ。問題が生じたら破棄するのか。

当たり前のようにサーバーメンテナンスは必要なのであり、建てるだけ建てて後は知らないというのは無責任が過ぎる。

第三者に利用可能にする、特に不特定多数に対して開放する場合、非常に困難な問題が降りかかる。 その多くは法的な問題であり、適切な法律知識を身に着けておく必要がある。 これは「十分に」身につけるのは現実的ではない。判例のない要素も多いが、法的に責任を持って運営する自身がないのであれば、弁護士に依頼することを強くおすすめする。 一方、これを機に法律の勉強をするのも悪くないだろう。

いずれにせよどんな動機であれ責任は果たさねばならない。世の中の放つものなのだから当然である。

そして、Fediverseサーバーを建てる上で最も考えなければならないのは後始末である。 後始末ができないのに始めるというのは無責任極まりない。

だが、後始末も責任感を持っていればできるようなものであり、全く難しくはない。 ここからは後始末についてしっかり見ていこう。

後始末

何が起きるか

インスタンスを仕舞う場合、Fediverse中から見ると「宛先が疎通できない」になる。 この状態になると、当該インスタンスに配送しようとするキューが無限にあふれてしまう。 これは多くのサーバーにとって負担になる上に、不整合状態が続くことになる。

もし、これを手動で解消しようとすると、数多くの管理者の手を煩わせることになる。

また、Fediverse中に流れた投稿はその投稿が持っているリンクをすべて失う。 つまり、大量の無効なリンクが発生する。

Fediverse中に流れたそのドメインは一気に「有名になる」ため、そのドメインを放棄し、悪意ある者に買われてしまうと簡単に悪用できる。 これは通常だと相当なPVがなければ発生しない問題だが、Fediverseインスタンスで使った場合非常に容易に発生する。

最もまずいのがドメインの再利用だ。 Fediverse上で投稿やユーザーなどのIDは一意だということが前提だが、同一ドメイン上に建て直してしまうと不整合が起きる。 手動で解消することは困難であり、場合によっては他のインスタンスを巻き添えにして潰してしまう可能性がある。

インスタンスの終了を伝える

インスタンスは他のインスタンスが疎通しなくても、一時的なダウンとみなし、配送キューに維持する。 だから、インスタンスを仕舞う時、もはやこのインスタンスはなくなったということを明確にする必要がある。

その方法は簡単でHTTPステータス410 Goneを返せば良い。 これはNginxの場合

location / {
  return 410;
}

とするだけの話だ。

ただし、これはいくつか考えておかなければならないことがある。

最も大きいのは、「必ず410を到達させなくてはならない」ということだ。 つまり、疎通できるようにドメインを維持し、webサーバーを維持しなければならない。 それもかなりの長期に渡ってである。

加えて、ほとんどのインスタンスはHTTPSで通信してくる。 証明書エラーがある場合、インスタンスはその時点でエラーとして扱うため、410を受け取らない。 このため、証明書を更新し、HTTPSでも適切に410を受け取れる状態を維持しなければならない。

また、410 Goneは「このリソースは消滅した。二度と復活しない」である。 このため、他の目的であっても、同一パス(事実上の同一ドメイン)は二度と再利用できないと思ったほうが良い。 実際は長長期に渡ってサーバーが存在しない状態を経て復活させることは可能だが、年数がかかるそのようなことは実験するのも難しいため、基本的に410 Goneを返したからには完全なる終焉だと考えるべきである。

そして、「二度と使えない」状態になっているにも関わらず、webサーバーを維持し、ドメインを維持し、証明書を維持する責務があるということだ。

なお、他にもサーバー(webサーバー)を持っている場合は、ACMEチャレンジ用の口と、410を返すルートがあればいいだけなので、もともとのサーバーは潰して別のサーバーに統合するようなことは可能である。

Fediverse上のユーザー投稿

インスタンスは基本的には他のインスタンスが410を返した場合、そのインスタンスは復活しないものとみなして配送を諦める。

だが、多くのサーバーアプリケーション実装は、他のインスタンスの投稿を自インスタンスの投稿として複製して保持する。 このため、あるインスタンスが410を返すようになり、そのオリジナルの投稿にはアクセスできない状態になっても、そのユーザーの投稿は他のインスタンスに保存されたままとなる。 それは、無効なリンクを大量に含むものであり、「リモートで表示」などした場合もアクセスできるリソースはない。 これは深刻ではないが、小さくはない問題だ。特に、のちのドメイン問題を引き起こす場合は特に。

410を受け取ったらそのインスタンスに関わる投稿をすべて削除すればその問題は発生しないはずだが、私が知る限りそのような実装になっているサーバーアプリケーションはない。

考えられる策としては、「インスタンスをクローズする前に、全ユーザーを凍結し、一定期間置く」ということがある。

サーバーアプリケーションの実装として、ユーザーをフェッチしたときにユーザーが凍結されていると、自インスタンスから当該ユーザーに関わる情報を削除する、という処理をするものはある。 このときサーバーアプリケーション実装として410を返すようになっていたりするので、単に410を返すだけでもユーザー削除として扱うように将来的にはなっていくかもしれない。 (なぜならば、そうしないとゴミがたまっていくからだ。)

この、「一定期間」がどれくらいかは分からない。

なので、安全な手順としては

1. 全ユーザーを凍結し、一定期間(期間不明)維持する
2. 410 Goneを返すようにし、webサーバー, ドメイン, 証明書を維持する (おそらく年単位)
3. 一切のアクセスがなくなったらサーバーをシャットダウンする

となるだろう。

ちなみに、絵文字リアクションなどは無効なリンクのまま残り、消す方法がない。

ドメインの問題

前述のとおりFediverseに放流したドメインは有名になるほか、そのドメインへのリンクが残り続けるため、Fediverseインスタンスに使われたドメインはかなり積極的に狙われているようだ。 このため、現状は使ったドメインは使わなくなったとしても保持し続けるしかない。

なお、「二度と使えない」状態なのはwebに対してのみで、他のサーバーとして利用したり、あるいはサブドメインを利用することには支障がないため、使い道がないわけではない。

サーバーアプリケーションの管理

アップデート

一部、「最新のアップストリームに追従する」ということを責務のように感じている人がいるようだが、そんなことはない。 別に、維持したままでも良い。

ただし、セキュリティフィックスは取り込まなくてはいけない。 少なくともMisskey, Pleroma, Akkomaはstable release branchを持たないため、セキュリティフィックスを取り込むために最新環境になるという面はある。

なお、私が管理している中では、Misskeyはアップデートでおかしくなることがある。

マイグレーション

アップデートよりは真面目に考えないといけない問題がこちら。

サーバーアプリケーションは基本的に最新環境を前提にしてローリングリリースされる傾向であるため、その追従のためにサーバー環境そのものが古くなってしまう問題が発生する。

もちろん、Archlinuxを使えば苦しまなくて良い問題だが(なんならPostgresqlのマイグレーションツールもある)、DebianやUbuntu Server, SLES, RHELあたりを使っていると発生しやすい問題ではある。

マイグレーションは難しい話ではないが、ちゃんとできるようになっている必要はある。

パージ

不整合になったインスタンスが発生した場合、単に当該インスタンスをブロックするだけでは足りない。

簡単な話としては、全投稿から当該インスタンスのユーザーによるものを削除すれば良い。

SQL文としてはそこまで難しい話ではないが、データベースが大きくなってくると難しそうだ。

メール

メールはものすごく難しい問題であり、本記事では単に「メール機能を有効にせず、登録開放せず、招待制にする」を解法としたい。

公開インスタンスの運営の話はとても本記事で扱えるような範疇の話ではない。

法的問題

自分のインスタンスだと規制する人がいないけれど、それは何やっても良いというよりも、問題になるような行為をしても止めてくれる、守ってくれる人がいないということでもある。

来る時は簡単なことで来るので、ちゃんと規範意識を持ってやったほうが良い。

おまけ: Fediverse PaaSやらないの？

やっても良い、というかMimir Yokohama扱いで既にやってるので、希望があれば問い合わせてくれれば良い。 構成や運用など、細かいオーダーが可能だ。

ただし、危険なサーバーを動かすわけにはいかないので、サーバーに関してはかなり強固に作られ、運営される。 そのため、決して安くはない。

それでも興味がある人は、Mimir Yokohamaに問い合わせてほしい。