【Mastodon】v4.4.0-beta.2+glitch 導入失敗とその後

LIBERA TOKYO

　今日は東京都議会議員選挙の投票日ですが、私は昨日期日前投票を済ませているため、今日は家でのんびりしております。

　とはいえ、昨日発生したトラブルのため、危うく今日はのんびりできなくなるところでした。

　昨日私は、自分自身が運営する、リベラル（自由主義者）向けMastodonコミュニティ「LIBERA TOKYO」において、Mastodon本体の更新を目的とするメンテナンスをおこなっておりました。

　ところが、紆余曲折の末、いったんは更新できたかと思いきや、正常動作せず、焦ることとなってしまいました。

　結論から申し上げますと、昨日夜中、日付が変わる直前のタイミングで、ギリギリ正常動作できるようにしました。

　しかしそこまでの道のりは、自分にとっては長く険しいものでした。

　そのときの顛末を、後学のために、メモに残しておきます。

　とは言いましても、基本的には、「info.LIBERA.tokyo」で既に述べていることの焼き直しとなります。下記の記事も併せてご覧いただきたいと思います。

今回メンテナンスに成功しなかった理由

　Mastodonが依存する複数のモジュールにおいて、「Mastodon v4.4.0-beta.2+glitch」を動作させるのに最低限必要なバージョンを導入することができなかったことによるものです。

　なお、「LIBERA TOKYO」は、「さくらのVPS」上に構築した「Ubuntu 22.04」の環境に、「Mastodon Glitch Edition」という、Mastodonのフォークで稼働しています。

　このエディションはMastodonのmainブランチを追随していて、本家Mastodonのアルファ版やベータ版、RC（リリース候補）版が適用されることがあるため、素の安定版Mastodonよりも導入やメンテナンスに手間が掛かります。

　今回の更新作業では、先述の通り複数の依存モジュールのバージョン不足が理由で成功せず、一見成功したと思っても正常動作をしないというトラブルに見舞われました。

　そのうちの少なくともひとつに於いて、サーバOSが「Ubuntu 24.04」であることが事実上必須条件となっているものがあるのですが、自分はそれに気づいていなかったのと、気づいたあとも、ここでOSのバージョンまで上げるとかえって傷口を広げかねないという懸念から、「Ubuntu 22.04」のまま無理矢理メンテナンスを強行してしまいました。

　具体的には、次のモジュールのバージョンを手動で上げる必要がありました。

Ruby

　毎回毎回更新作業の鬼門となるRuby。今回も見事に私を苦しめてくれました。

　これまでは古いバージョンのRubyをだましだまし使っていたのですが、どうやらそれも通用しなくなってきましたので、諦めて更新しました。

　それにしても、毎回毎回やり方を忘れるくせにメモを取らない自分の悪い癖、どうにかならないものか…。

　なお、今回は主にこちらの記事を参考とさせていただきました。

　一応、公式ドキュメントにもRuby導入方法が書いてありますので、最悪の場合そこを参照すればよいのですが…。

libvips

　Mastodonで画像処理をおこなうとき、従来は「ImageMagick」というモジュールを使用していましたが、このモジュールのサポートが廃止され、代わりに導入されたのが「libvips」です。

　実は私はこれまでこのモジュールについて全く意識していなかったのですが、今回「Mastodon v4.4.0-beta.2+glitch」を導入するに当たり、これのバージョンが足りないために更新する必要がありました。

　ところが、「Ubuntu 22.04」の環境ではこのモジュールの最新版を自動的に導入できません。

　とりあえず今回は、こちらの記事を参考に無理矢理「Ubuntu 22.04」環境に「libvips 8.16.0」を導入しました。

　しかし、いずれちゃんとOSそのものも更新しないとだめですね。土日がどっちも暇になるタイミングで、OSそのものを更新したいところです。ただ、「LIBERA TOKYO」が扱うテーマの関係上、参議院議員選挙の時期は避けたいな…。

Redis

　とりあえず、Rubyとlibvipsをどうにかして、手順の中の「assets:precompile」でコンパイルエラーとなったところを指示通りに直し、ようやくMastodon本体の更新に成功したかと思いきや、タイムラインの動きがありません。

　外部サーバからの読み込みが全くおこなわれていないように見えます。

　管理画面では、Sidekiqのプロセスが無いから設定を見直せと言われてしまいました。

　しばらく、Sidekiq周りを見ようとしていたのですが、プロセスをいじるような設定画面などありません。

　ログを確認したところ、Sidekiqが依存するRedisのバージョンが足りないことによるものとわかったのですが、なぜかそこにたどり着くまでに数時間を要してしまいました…。

　なお、作業時に直接参照した記事ではありませんが、下記の記事が（バージョンは違うが）自分が陥った現象に酷似していますので、参考までに。

　なお、単にSidekiqを動かすだけならばRedisのメジャーバージョンまで上げる必要は無かったのですが、後々面倒を避けたいため（ぉぃ）、今回自分は一気にメジャーバージョンを2も上げて、Redis 8.0.2を導入しました。

今回に限らず毎度毎度メンテナンスのたびに悩まされるもの

　今回は主に上述の通りモジュールのバージョン不足が複数重なったことによってメンテナンスに成功せず、再始動に時間が掛かったのですが、それに限らず、メンテナンスのたびに毎回悩まされるものもありますので、一応書いておきます。

Glitch独自の「フレーバー」とそこで用いるSCSS

　「Mastodon Glitch Edition」では、本家Mastodon](https://joinmastodon.org/ja “Mastodon – 分散型ソーシャルネットワーク”)には実装されていないいくつかの機能が拡張されているのですが、それにより、Web画面の見た目にも手が加えられています。

　Glitchの機能を最大限に活かすためには、Glitch独自の「フレーバー」を導入する必要があります。これは本家の「サイトテーマ」を置き換えるもので、フレーバーのカスタマイズもGlitchの魅力のひとつだったりします。

　ところが、前回および今回のメンテナンス時に、「フレーバー」の仕様が微妙に変わったようで、それ以前の状態に戻すことができなくなってしまいました。

　これについても、いずれ時間ができたときにでもちゃんと見直したいと思うのですが、その前にまずはSCSSの仕様の理解が先ですね…。

#2025年 #2025年6月 #2025年6月22日 #Mastodon #マストドン #SNS #分散型SNS #Fediverse #LiberaTokyo #政治 #自由主義 #リベラル #Ubuntu #Ruby #libvips #Redis #Sidekiq