Lycolog

仕事を終えて自分のサイトを見ると一部がダウンしておりGrafanaを見てみたらディスク使用率が100%になっていた。Mastodonがダウン、Grafanaも不安定な状態だった。

Prometheusのsyslog集めが強すぎてストレージパンクしたかな？と思ってPrometheusを止めてみたが効果はなかった。

ディスク占有しているやつを探す

ひとまずディスクを占有している主を突き止めるため、ディレクトリ単位の容量を出して突き止めることにした。犯人はForgejoだった。

犯人探しに使った軌跡

sudo du -xh --max-depth=1 /
sudo du -xh --max-depth=1 /var
sudo du -xh --max-depth=1 /var/lib
sudo du -xh --max-depth=1 /var/lib/forgejo
sudo du -xh --max-depth=1 /var/lib/forgejo/data
sudo du -xh --max-depth=1 /var/lib/forgejo/data/repo-archive

一次対応としてForgejoへの外部アクセスを遮断

取り敢えずForgejoが攻撃されてると面倒だなと思い、nginxの設定を書き換えてForgejoへの外部接続を拒否した。

次にrepo-archiveはキャッシュらしいのでForgejoの管理画面から消すことにした。すると即座にディスクは空き、全てが元に戻った。

犯人捜し

一旦サーバーは安定状態になったので犯人を捜すことにした。

まずはForgejoのログを見たのだが役に立たなかったので、次に私はGrafanaのLokiからnginxのログを引くことにした。

そしてLokiからnginxのログを見たらすぐに分かった。meta-externalagent、つまり悪名高いFacebookのクローラーだった。過去にこのブログにやってくる海外IPのBOTの挙動を軽く調べたでも出したが、こいつはやたらアクセスしてくる。

しかし何故Facebookのクローラーがなぜ…？と思ったがURLを見てすぐわかった。アーカイブにアクセスしているのだ。

もしかしたらForgejoはアーカイブURLにアクセスされるとその都度.zipや.tar.gzを生成しているのかもしれないと思って調べたらその通りだった。そんなクソみたいな仕様ある…？と思ったが、アーカイブを作るなら他に方法はない。

ForgejoはGitHubと違ってパス単位に作れるため、パスが多いリポジトリほど大量に作れるし、過去のバージョンを参照されたら事実上ほとんど無限に生成できる。そりゃパンクする。

Forgejoはどう思っているのか？

こんなのほとんど脆弱性である。しかもディスククォーターを設定したところでどうにもならない。ダウンロードできなくなって詰むだけだ。定期的にクリアしてもいいがSSDの寿命が縮んでしまう。

そこでForgejoの人たちはどう思っているのか調べてみたら案の定課題が起票されていた。最後の奴に至ってはメインコントリビューターの一人と思われるGusted氏の起票である。

• bug: Forgejo is spam-creating repository archives, and cannot create requested archives
• feat: add quota for repo-archive
• problem: no traffic policing that keeps Forgejo available

結局どうすることにしたか

リポジトリの中身をzipで落としたい需要というのはどうしても出てくるし、それは仕方がない。しかし世代ごとパスごとに作ってしまうとなると、その数は無数になりすぎてしまう。

そしてダウンロードさせる以上どこかにデータを置く必要はある。仮に定期的に消すとしてもストレージの消耗は避けられない。

結論としてForgejoは撤去し、成果物は配布ページを作ってそこでzip配信するのが無難だなと思った。

簡単なコードについてはゴミ箱みたいな場所を作ってそこに転がしておくのもいいだろう。

明らかに利用者がいるValueDomainの奴とかもあるので、ひとまず土曜日にページを作って配信しようと思った。

meta-externalagentのアクセス推移

全部で何アクセス化までは見れていないが万単位でアクセスされてそうなので無茶苦茶だなと思った。

metaは最早攻撃者にも近いと思う。

経緯とか

18時頃にメトリクスが切れているのは多分書き込めなくて一時的に死んだからと思われる。再開できた理由は不明。この時点でネットワークトラフィックも死んでおりまともにアクセスできない状態だったと思われる。

19時半頃に手当を開始したが、FacebookのクローラーはForgejoを遮断するまでダウンロード不能（statできずにエラーを吐いていた）になったURLにひたすらアクセスしていた。

あとがき

今回の障害はいい勉強になった。

ディスク容量の急増という障害があることと、単にログとメトリクスを集めているだけでも解ることがあることが知れた。

勿論、閾値を設定した上での発報や、毎回クエリを叩かなくていいダッシュボードがあればよりよいと思うが、単に監視装置を置いているだけでもこうやって知ることができるのだなというので、いい経験になった。

GitHubではWebUIからPRのマージやファイル編集をしたときにコミットに署名がつくが、これをForgejoでもやる方法。

確認環境

• Forgejo 15.0.3

やり方

基本は公式にあるInstance Commit Signingの通り。

1. 署名用のSSH鍵を作る

   ssh-keygen -t ED25519 -f forgejo
   ssh-keygen -y -f forgejo > forgejo.pub
   sudo mv forgejo* /etc/forgejo
   sudo chown git:git /etc/forgejo/forgejo
   sudo chown git:git /etc/forgejo/forgejo.pub
   

2. /etc/forgejo/app.iniに設定を足す

   [repository.signing]
   FORMAT = ssh
   SIGNING_KEY = /etc/forgejo/forgejo.pub
   SIGNING_NAME = "Example Git Instance"
   SIGNING_EMAIL = "noreply@git.example.com"
   INITIAL_COMMIT = pubkey
   WIKI = pubkey
   CRUD_ACTIONS = pubkey
   MERGES = pubkey
   

3. Forgejoを再起動する

   sudo systemctl restart forgejo.service
   

結果

対応前	対応後

コミットに署名がつき、自分のアイコンが出るようになった。

但しGitHubとは違い、Forgejoが署名したことが分かる見た目になっている。

実はGitHubでもWebUIからの修正にはGitHubの鍵で署名が行われているのだが、GitHubではUI上その区別がない。Forgejo はその区別があるため、より明確な表示になったといえる。

あとがき

コミット履歴のアイコンにForgejoがいるのが気に食わなかったので、自分のアイコンで上書きできてよかった。これで履歴の気味悪さを忘れてWebUIから気軽に治せる。

署名なしコミットは文字やアイコンが大きく、行も広くなるため、表示がしっくりこなかったので丁度よくなった。

MSYS2のGitって遅いよな～とつぶやいていたら公式から早くする方法があるよと紹介されたので、その時にやったこと。

この手順は私個人の環境に深く紐づいている。

確認環境

手順

1. 起動スクリプトを直す

    @echo off
   -set MSYSTEM=MSYS
   +set MSYSTEM=UCRT64
    set MSYS2_PATH_TYPE=inherit
    set CHERE_INVOKING=1
    C:\env\msys64\usr\bin\zsh.exe -l %*
   

2. パッケージのアップグレードを行う

   pacman -Syu
   

3. もっかいやる

   pacman -Syu
   

4. 既存のgitを消す

   pacman -S git
   

5. UCRT用のgitを入れる

   pacman -S mingw-w64-ucrt-x86_64-git
   

6. MSYS2用のGitプロンプトを廃止
   • MSYS2ではWindowsのGitを使用しており、プロンプトを出すためだけにMSYS2のGitを使っていたが、これをやめた

参考リンク

• Native Git Now Available in MSYS2
  • 倍速くらいになると書かれている

あとがき

Windows側に入ってるGit for windowsも消していい気がしてきた。まぁそもそもGit作業は今のところUbuntu実機で行っている関係もあり、滅多に使わないのだが…。ただVSCodeでパスフレーズ付きのカギを扱うときにはあった方が良さそうだし、コミット用にはあった方が良さそうな気もする。

しかし過去情報の断面を残したいがために、出来るだけ過去記事の状態を保っているが、MECEでなくなりすぎていて大変なので、そろそろWiki的な何かを作った方がいい気がしてきた。

絶対に次にフルセットアップするときにこの状態に戻せない気がしている。

ところでMSYS2公式から助言をもらえたのはFediverseをやっていたお陰な気がするので、これはとても良い出来事だったと思う。

実行環境的にMSYSはCygwinでUCRT64はWindowsネイティブで速そうなので実行環境はMSYSTEMよりUCRT64のがいいのかなとか思った。

PHP-FPMとかの設定がvhostに散らばってて一元化したかったけど/etc/nginx/nginx.confにlocationディレクティブを書くと構造上エラーになるため、再利用可能なモジュールと切り出し各vhostの設定から呼び出して解決したログ。

確認環境

• nginx/1.26.1

やり方の一例

PHP-FPMを設定する例

1. /etc/nginx/snippetsに適当な名前で.confを作る
   • 例：/etc/nginx/snippets/php-fpm.conf
2. 作ったファイルに設定を書く

   location ~ ^.+\.php$ {
     fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
     fastcgi_index index.php;
     include fastcgi_params;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     fastcgi_param HTTPS on;
     fastcgi_param SERVER_PORT 443;
   }
   

3. 読み込みたいvhostの.confから参照する

   server {
     listen [::]:443 ssl;
     server_name hoge.example.com;
   
     # ワイルドカード証明の設定も外出ししておくと共通化できて便利
     include snippets/cert.conf;
   
     client_max_body_size 100M;
   
     root /var/www/hoge;
     index index.php;
   
     location / {
       index index.php;
       try_files $uri $uri/ =404;
     }
   
     include snippets/php-fpm.conf;
   
   }
   

UIが余りにも好みではなかったので戻した時のログ。

結論から言うと簡単に戻せた。

• 確認環境
• 手順
• あとがき
  • 切り戻した動機
  • UIが嫌なのにバージョンを上げた理由
  • どうにかして元に戻そうとした夢の跡
• あとがきのあとがき

確認環境

• バイナリから起動しているMastodon
• Mastodon本番環境をGitで管理している

手順

1. DBのロールバックを行う。34世代前に戻すと4.5.4になる

   RAILS_ENV=production bundle exec rails db:rollback STEP=34
   

2. 4.5.4時点までgit revertする
   • 参考ログ
3. Mastodonのアップグレードと同じ方法でコマンドを叩いてゆく

   sudo su - mastodon
   # Rubyのアップデート用
   cd ~/.rbenv/plugins/ruby-build
   git pull
   cd ~/live
   RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
   # install
   bundle install
   yarn install
   # DBがアカンことがあるので叩いておく
   RAILS_ENV=production bundle exec rails db:migrate
   # いつものリビルド
   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   exit
   # 再起動
   sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming
   

4. 動いてれば終わり

あとがき

切り戻した動機

v4.5.4	v4.6.0

4.5系から4.6系でUIが大幅に変わること自体は知っていたが、UIの変更が余りにも多く、個人で元に戻せるレベルではなかったため切り戻しすることにした。

app/javascriptやpackage.json, yarn.lock, config/viteを戻してもバックエンドと結びついてるやつがいるようで上手くいかなかった。

以下、v4.6.0で気に入らなかった部分の一例。端的に言うと目が痛いし、ダサい。

フォロー・フォロワー一覧にある「フォローされています」が余りにもデカく、ダサすぎる。

また二枚目にある便利メニューが消えた。私はこの便利ボタンを頻繁に使用しているため非常に困った。このボタンそのものは簡単に復活させられた。

日本語翻訳がまた消えた。翻訳が消えるのはMastodonにはよくあることだが毎回翻訳キーを調べて書き換えるのが嫌になった。ここ以外にも未翻訳部分はある。

ユーザーハンドルのポップアップが変わった。前の方が良かった。説明が薄いし、Copy handleのボタンも直感的でないと思う。あと翻訳してほしい。

左に寄りすぎたタブと、直感的でなく操作に手数がかかるフィルタUI。返信を表示は今までタブとしてあったのに、4.6.0では「投稿とブースト」プルダウンをクリックし、トグルボタンを切り替えないといけない。これはとても直感的でないと思うし、そこまでして操作したくない。

自己紹介編集画面が縦長になりすぎた。自己紹介の編集画面が空白まみれになり縦長になりスクロールが必要になったうえ、更に個別の項目に編集ボタンがあり、編集しづらい。なんで初期状態で編集可能にしないのか…。

自己紹介の補足情報が一行に複数入って気持ち悪い。

自己紹介で絵文字が出ない、要素が変に改行されたりトリムされている。

ハッシュタグのコントラスト比が高く目が痛い。

スクロールバーが太くなった。スタイリッシュさが消えた。

テキスト入力欄にフォーカスが入ると枠が出るようになった。光りすぎてて目が痛い。

未読チェックが左側に出るようになった。右側に出てくれた方が押しやすい。スクショ貼るのが面倒なので以降スクショなし。

タイムラインのメニュー展開ボタンが左側に出るようになった、右側にｒｙ。

非ログインユーザーの表示が標準ではライトテーマになっており、見た目を調整するには両方のテーマを直すか、ライトテーマを消し去るしかなく、UIの保守コストが増大した。（厳密にはブラウザのテーマによって変わる）

UIが嫌なのにバージョンを上げた理由

実はこうなることは事前にある程度知っていたのだが、Wrapstodonが使いたかったからバージョンを上げたところがある。

しかし全く容認できないUIだったため切り戻すことにした。

どうにかして元に戻そうとした夢の跡

4.5系のUIを部分的に復活させた #4で、vibe codingを利用して直そうとしたものの、破綻が酷く、結局半分くらい自分で書いたが、結局変更箇所が多すぎてどうにもならなかった。

あとがきのあとがき

取り敢えずDBを壊さず、ロールバックもせず綺麗に戻せてよかった。