2026/06/25(木)自宅サーバーの一部がダウンしたが監視を入れていてよかった話

仕事を終えて自分のサイトを見ると一部がダウンしており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氏の起票である。

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

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

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

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

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

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

meta-externalagentのアクセス推移

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

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

経緯とか

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

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

あとがき

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

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

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

2026/06/25(木)フライパンが壊れたので買いなおしたら快適になった

投稿日:

シンクの縁にフライパンを載せてたら取っ手を下にして落下し、取っ手が壊れてしまったので買い替えたら快適になった話。

買い替えたやつ

ニトリのIH・ガス火 超軽量フライパン 20cm(KY067)というやつを買った。たぶん前買ったやつの後継商品。

まず新品なのでピカピカで、二枚目の写真はサバを二回焼いて洗った後だが、全く黒くなっていない。汚れもすぐ落ち非常に快適だ。

前のフライパンは汚れが落ちづらくなっており、表面も黒ずんでいたので、寿命を知らせてくれるために壊れてくれたのかもしれない。

しかしフライパンを買い替えるたびにIHはいらないなと思うのだが、IH用とガス火用を分けて生産するとコストがかかるので仕方がないのだろう、と思ったらガス火 超軽量フライパン 20cm(KY066)という、表面仕様やサイズ感がほとんど同じものがあるようなので、こっちに買い替えようかなとか思った。

こちらの方が底面の表面積が広く、火の通りが良さそうだ。

ニトリのこのフライパンのいいところは20cmを名乗っているのにコーナンで売っている20cmのフライパンや、ニトリで売ってる他の20cmのフライパンより大きく見えることだ。実際22cm用のフライパンの二がハマる謎のサイズだし、ニトリで売ってる他のフライパンに間口を重ねてもデカい。

22cmの浅型フライパンなんて探してもそうそう存在しないので、中々都合のいいサイズである。

同日夜追記

ガス火 超軽量フライパン 20cm(KY066)を見てきたが、一回り小さかったので、これを買うのはやめることにした。

あとがき

このフライパンは確か8年ほど前に買い替えたものだと思うので、十分働いてくれた。ニトリで買って持ち帰ってる途中にアスファルトに落として傷を入れてしまい、すぐ買いなおしたのを今でも覚えている。

前述でガス火用のフライパンもあるとの情報を得たが、前回行ったとき見つけられなかったし、どこにあるのだろうとフロアマップを見たら、どうやらIHと全然違うところにあるようで気づけなかったようだ。残業した後に閉店前30分前に滑り込んだので、あまり探す余裕がなかったかもしれない。

しかし今年はモニタが壊れたり、イヤーパッドが壊れたり、スマホを買い替えたりで、買い替えが多い年だ。

モニタの買い替えについて過去記事を探したら書いてなさそうだったので、これについてもまた書きたいと思う。年初にモニタが壊れたのは中々盛大な出来事だった…。

2026/06/24(水)ForgejoでWebUIからのコミットに署名させる

投稿日:

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から気軽に治せる。

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

2026/06/24(水)Xperia 1 VIIIのZEROSHOCKとSpigenのRUGGED ARMORを両方買ったので比べてみた

Xperia 1 VIIIを買った話ではケースはZEROSHOCKがいいかなーと思ってZEROSHOCKを買ったのだが、MagSafe対応で磁器があると舞奈カードの読み取りなどで都合が悪く、ついでにZEROSHOCKは重くかさばるため、SpigenのRUGGED ARMORも買ってみようというので結局両方買ったやつ。

ZEROSHOCKの方が早く出ていたためSpigenのRUGGED ARMORが届くまでの一週間はZEROSHOCKを使っていた。

ZEROSHOCKとRUGGED ARMORの比較写真

表面(スマホはめるとこ)

写真撮影の都合でややこしいが左がSpigenのRUGGED ARMOR、右がZEROSHOCKだ。

大きな違いとしてはZEROSHOCKの方が大きく、特に四隅のバンパーがゴツく、いかにも保護してくれる感じだ。多分よほどのことがなければ角が壊れることはないだろう。ZEROSHOCKには内側にハニカム構造があるため地面にバシーン!と落としてしまったときにもダメージは少ないと思われる。しかもカメラの段差分の分厚さがあるからなおさらだ。

とはいえ、四隅に関してはRUGGED ARMORにもエアポケットがあるため、最低限の保護はある。

また地味な部分だが、ZEROSHOCKは電源ボタンの表側に梁が入っており、表側から指を滑らせて電源ボタンにアクセスしづらいのに対し、RUGGED ARMORはそう言ったものがなく素直にアクセスできる。

裏面

裏返してみたところ。

ZEROSHOCKはカメラの段差を極限までなくしているがRUGGED ARMORは段差が目立つ。

またカメラの保護に関してはレンズ外周スレスレまで保護しているZEROSHOCKの方が優位だ。恐らくレンズの穴ピンポイントにアスファルトの突起が刺さらない限り、舗装路に落としてもレンズが守られるだろう。

一方でRUGGED ARMORは外周に出っ張りがあるため、ZEROSHOCKと比較した場合にやや脆弱に見える。しかし出っ張りが高めなので意外と平気かもしれない。またSONYのロゴが見えるため、美観的が良いのがいいところだ。

電源ボタンに関してみてみるとZEROSHOCKは裏側に梁がなく、このケースは裏側から電源ボタンにアクセスさせる設計なのが伺える。RUGGED ARMORは表裏どっちからでも電源ボタンにアクセスできる。

表面加工についてはZEROSHOCKはゴムっぽくて滑りづらい、RUGGED ARMORはザラザラしていて滑りづらい感じだ。手で持った時の感触はZEROSHOCKも悪くないのだが、RUGGED ARMORの触り心地はXperia 1 VIII本来の表面に近く、ケースを付けているのに、まるで付けていないような感覚があり、これは非常に良いと感じた。

またRUGGED ARMORのストラップホールは千切れやすいという評判があるため、ストラップホールを使う場合は、明らかに分厚くて頑丈そうなZEROSHOCKの方が耐久性がある可能性がある。

下側

下側から見たところ。

ZEROSHOCKは厚みがあり、コネクタが挿しづらい。またコネクタの穴がRUGGED ARMORに比べて小さかった。

RUGGED ARMORはUSB Type-Cとその横のスピーカー分の切り欠きがあるが、ZEROSHOCKはUSB Type-Cとスピーカーで穴が分かれている関係でこうなっている。

スピーカーから音を出す場合、余計なものが少ないRUGGED ARMORの方が音はクリアだろう。

上側

上側から見たところ。この写真だけ左側がZEROSHOCK、右側がRUGGED ARMORになっている。

ZEROSHOCKはイヤホンジャックの開口部を大きく取りすぎて、余りにも縁を捕捉しすぎて手前側の縁が容易く千切れやすそうになっている。

RUGGED ARMORの方は特にそんなことがない。

またカメラ部分の段差はZEROSHOCKにはほとんどなく気にならないが、RUGGED ARMORはやや気になる。なれれば気にならないとは思うが、音ゲーを机の上でやる場合は向かないだろう。

操作感

ZEROSHOCKはその分厚さゆえに、シャッターボタンを押すのに力が必要で、すぐにカメラを起動したいときに空振りすることがしばしばあった。逆に言えばボタンの保護は堅牢といえるだろう。とはいえ、スマホは表裏面か角から落ちるものなのでボタンを強打するシーンは余り思いつかないが…。

RUGGED ARMORはボタンが非常に押しやすく、シャッターボタンはもちろん、ボリュームボタンを押すのも快適だ。電源ボタンへのアクセスもいい。

着脱のしやすさではZEROSHOCKの方が遥かに良く、RUGGED ARMORは装着や脱着がし辛かったが、逆に言えばRUGGED ARMORはミチミチなので隙間にゴミとかが入りづらく、ケースが何かの弾みで脱落する可能性も低いと感じた。今回のは過去に使ったRUGGED ARMORの中でも最強クラスにミチミチだと思う。

あとがき

RUGGED ARMORはMagSafeがないのでマイナカードを押し付けても磁気ストライプが壊れないのが最大の利点である。

最近では少なくなったとはいえ磁気ストライプや磁器硬券と一緒に入れる場合、MagSafeがあると支障になるので、そういった心配をしなくていいのは非常にいいところだ。

ZEROSHOCKはサイズ的に胸ポケットに入り、実用面では問題なかったが、過度に大きすぎた部分もある。とはいえ、個人的に最大の欠点はMagSafeである。

ただ磁力が弱いのか、家電店でMagSafe対応充電器に貼り付けてもずり落ちたので、内蔵の磁石がどれだけ役に立つのかは謎だった。

結果として私はZEROSHOCKには戻らず、これまで通りRUGGED ARMORを使うことにした。

しかしなぜ今回RUGGED ARMORは出るのが遅かったのだろうか…。少なくともAmazonに出てきたときは発売日以降だったように思うし、商品が出ても配送日もかなり先だった。今でこそ即日配送になっているが私が買ったときは6/20が最短だった。この時は配送時期に一ヶ月近いブレがあったと思う。

ZEROSHOCKを買うことにして一旦キャンセルしたものの、やはり買い直したときは最短が後ろに倒れ、やはり一ヶ月近いブレがあった。注文後は結果として6/23が配送日になった。まぁ二度目の注文のときはXperia 1 VIII発売キャンペーンとか言うので値引きが入ってタイプ安くなっていたので結果としては良かった気もするが…。

こういうのがあるとXperiaへの対応がおざなりになりそうで今後が心配だ…。ただ表面加工は素晴らしいの一言だし、ひょっとしたら製品のクオリティを高めていたとかなのかも知れない。或いは日本市場が見捨てられているのか…。

まぁもし、RUGGED ARMORが対応しない時になったら、きっとその時はZEROSHOCKが生きるのかもしれない。いやまぁ、その時にZEROSHOCKがXperiaへの対応を続けていてくれたらの話ではあるが…。

2026/06/23(火)MSYS2のGitを高速化する

投稿日:

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

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

確認環境

Env Ver
MSYS2 msys2-x86_64-20260322

手順

  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プロンプトを廃止

参考リンク

あとがき

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

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

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

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

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