Lycolog

luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。

• 確認環境
• セットアップ
• Collectdのプラグイン設定
• Collectdのプラグイン
  • collectd-mod-cpu：CPU使用率
  • collectd-mod-interface：ネットワーク転送量
  • collectd-mod-load：負荷(Load Average)
  • collectd-mod-memory
  • collectd-mod-thermal
  • collectd-mod-uptime
  • collectd-mod-rrdtool
• トラブルシューティング
  • Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される
• 参考

確認環境

セットアップ

1. LuCIを開く
2. System→Software
3. luci-app-statisticsを入れる
4. 画面リロード
5. Statics→Graphからグラフが見れることを確認

この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。

• collectd-mod-cpu
• collectd-mod-interface
• collectd-mod-load
• collectd-mod-memory
• collectd-mod-thermal
• collectd-mod-uptime
• collectd-mod-rrdtool

Collectdのプラグイン設定

/etc/collectd.confをいじると変更できる。

基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。

<Plugin hoge>
        Foo true
        Bar 1
        Baz "fuga"
</Plugin>

Collectdのプラグイン

collectd-mod-cpu：CPU使用率

collectd-mod-cpu

設定はデフォルトのままで良さそう。

collectd-mod-interface：ネットワーク転送量

collectd-mod-interface

Network→Interfaces→Deviceにあるものが見れる。

br-lanとMAP-E、PPPoEが見たいので以下のようにした。

LoadPlugin interface
<Plugin interface>
        Interface "br-lan"
        Interface "map-wanmap"
        Interface "pppoe-wanppp"
</Plugin>

collectd-mod-load：負荷(Load Average)

• collectd-mod-load

uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。

Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。

設定項目がない。

collectd-mod-memory

• collectd-mod-memory

メモリの使用量を取れる。

設定はデフォルトのままで良さそう。

collectd-mod-thermal

• collectd-mod-thermal

デバイスの温度を取れる。

R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。

collectd-mod-uptime

公式にマニュアルはなさそうだが、起動時間を見れる。

LoadPlugin uptime

collectd-mod-rrdtool

• collectd-mod-rrdtool

collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。

ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。（/tmp/はオンメモリストレージ）

トラブルシューティング

Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される

上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。

例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。

上図の状態になると、下図のように不要なグラフが表示されなくなる。

但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

参考

• [OpenWrt Wiki] Performance and logging

Amazonや公式サイトにある情報が本当に正しいとは限らないので実地検分。

• やり方
• 調査ログ
  • CPU
  • メモリ
  • NIC(RJ45)
  • NIC(SPF+)
  • ストレージ(eMMC)
• まとめ

やり方

# これでCPUの情報が取れる
cat /proc/cpuinfo

# これでメモリの情報が取れる
opkg install dmidecode
dmidecode -t 17

# これでCPU, NICの情報が取れる
opkg install hwinfo
hwinfo

# これでeMMCのベンダ情報が取れる
cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid

調査ログ

CPU

cat /proc/cpuinfoの結果から取得した情報。

model name : Intel(R) Celeron(R) N5105 @ 2.00GHz

メモリ

dmidecode -t 17の結果から取得した情報。

MicronのLPDDR4でDDR4-3200相当であるとわかる。

Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 2

Memory Device
Array Handle: 0x003A
Size: 4 GB
Form Factor: Row Of Chips
Locator: Controller0-ChannelA
Type: LPDDR4
Speed: 3200 MT/s
Manufacturer: Micron Technology

NIC(RJ45)

hwinfoの結果から取得した情報。

pci 0x125cはI226-VなのでIntel Ethernet controller I226-V

Hardware Class: network
Model: "Intel Ethernet controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x125c
SubVendor: pci 0x8086 "Intel Corporation"
SubDevice: pci 0x0000
Revision: 0x04
Driver: "igc"
Driver Modules: "igc"
Device File: eth2

NIC(SPF+)

以前分解したときのラベルと、hwinfoの結果から取得した以下の情報と突き合わせるとMellanox ConnectX-3 En10*2 Gigabit Ethernet CX341Aであることが分かる。

Hardware Class: network
Model: "Mellanox MT27500 Family [ConnectX-3]"
Vendor: pci 0x15b3 "Mellanox Technologies"
Device: pci 0x1003 "MT27500 Family [ConnectX-3]"
SubVendor: pci 0x15b3 "Mellanox Technologies"
SubDevice: pci 0x0113
Driver: "mlx4_core"
Driver Modules: "mlx4_core"
Device File: eth3

ストレージ(eMMC)

以下の結果から、name: SCA128, manfid: 0x0000dfであることから、メーカー不詳のSCA128という製品であることが分かる。ググってもメーカー情報は不明だった。

cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid

まとめ

公式サイト？の情報やAmazonの情報と比べると微妙に差異があり、また、書いてない情報も取れたので調べてよかったなと思った。

前回2024/01/25に更新したサーバー機（サブマシン）だったが、今回サーバーとして運用することになったのと、将来的に10GbEを導入した時の投資としてネットワークスペックを上げるなどを目的とし、更新を実施した。

• 更新前後の構成
• 主な更新理由
• 開封の儀
  • マザボ
  • CPU
  • CPUクーラー
• 組み立て後
• あとがき

更新前後の構成

POST時にメモリエラーが出るので近日中にメモリは交換予定だ。幸い相性保険に入っていたので追加費用は出ない見込み。

主な更新理由

• マザボ更新によるNICの高速化
  • 1Gbpsを2.5Gbpsに上げることにより将来の高速化に備える
  • メインマシンが2.5GbpsなのでLAN内速度の向上
• SocketAM5への移行
  • 今後新たにCPUを買うときに発生するコストの痛みを余裕のある今のうちに吸収
• DDR5への移行
  • もうDDR4とかオワコンですしお寿司…

開封の儀

買ったもの。全部神戸市内で購入。というかメインマシン更新時と同じくソフマップで買ってきた。ここにしかITXマザーがなさそうだったのが理由だ。

メモリがやけにゲーミングだが、他が売り切れていたので仕方がなくこれにした。

この時はまだCPUクーラーが適合しないとは夢にも思っていなかった。何故ならAM4とAM5はCPUブラケットに互換性があるとされていたからだ。

マザボ

箱の中身。WiFiのアンテナや、温度センサ、M2SSDネジ、ケーブルバンド、SATAケーブル辺りがあった。写真には写っていないがASRockのデカいシールも入っていた。

表面。CPUソケットの主張が激しい。

AM5からはLGAに変わっているためマザボ側にトゲが生えている。ピン折れリスクの観点からPGAの方が好きだったので残念だ。

とはいえ、PGAは面積当たりのピン数の制約が強いのでスペックアップのためには仕方ないだろう。面積当たりのピン数はLGAの方が有利だろうし。

裏面。裏面NVMeスロットが復活していた。これはA320M-ITXにはあったけどA520M-ITX/acではなくなっていた要素だ。

恐らくNVMeスロットを2つにする上で仕方がなかったのだろう。確かASUSも裏面に実装していたと思う。

CPUバックプレートを差し込もうとしたところ、なんと入らなかった。寸法は同じだったが穴のサイズが合っていなかった。

更に言うとバックプレートが剥がせなくなっていた。マザーボードに完全に貼り付けてあった。

側面。2.5Gの文字がまぶしい。今回最大の目的はこれである。

CPU

右が今回買った方で、左が今まで使ってた方。なんか見た目がかっこよくなっていた。

PGAからLGAに変わった関係で背が低くなっている。ソケットアサイン用の窪みが出来た関係もあると思うが、接点の密度は左程増えていないようにも見える。むしろ減っていても不思議がない。

CPUクーラー

まさか手持ちのが使えないとは思ってなかったので、組み立て作業はこれが届くまで一時停止する。

こちらは入手困難であったため、Amazonで調達した。17時ごろに見たら翌朝配送と書かれており、私はこの時、映画を見るスケジュールで埋まっていて当日中に手に入れる手立てがなかったからだ。

翌日12時半に到着して、無事パーツを組むことが出来るようになった。エアフローをサイドフロー型向けに最適化しておきたいので、このパーツは外せなかった。なんか微妙な奴ならソフマップにもあったのだが、微妙なのは使いたくなかった。こういうものには納得が必要だ。

付属品はファンとヒートシンクにIntel用のバックパネルとリテンションキット、CPUグリス、マニュアルなどだった。

AMDのバックパネルがないのが気になったが、そのまま挿すことが出来た。これは賢いなぁと思ったが、メーカーごとに自由なバックプレートを作れないのは差別化要素を失わさせる要因にもなるため、Intelの方が多様性に資するなとは思った。

ファンの新旧比較。左が新しい方、右が古い方。新しい方が風量があり、やや五月蠅かった。古い方は風量がやや少ない代わりに静かだった。

ヒートシンクの新旧比較。銀色が古い方、黒色が新しい方。

違いとしては、まず色が違うほか、台座のヒートシンクが小さくなっているのと、台座の高さも減っていた。

また、若干ヒートシンクの角が削れており、これはドライバーでネジを占めるときのクリアランスとして便利だった。以前はヒートシンクが削れていたのでイマイチだった。

グリスはCoolerMasterのコーポレートカラーだったが、なんかキモいので拭き取って忘れることにした。実際にはNoctuaのグリスを塗った。

組み立て後

中身。ヒートシンク付きのごついゲーミングメモリが目立つが、以前と比べ黒くなった。大体CPUクーラーのせい。

外観。ぶっちゃけ変わる要素がないので、ほぼ変わっていない。変化としてはシールが増えているところだ。しかし今回はRADEONのシールがなかったので、Ryzenのシールのみとなり、シールの枚数が奇数になってしまった。

左から右にシールを増やしているが、Athlonのシールがあるマシンもそうそうなさそうなので、結構独特な存在だと思っている。

あとがき

今回の更新作業は予期せぬトラブルで自宅サーバーが予想外長時間止まってしまった。本来は16時開始17時終了でサーバーを再開する予定が、CPUクーラー手配の関係などで翌日15時まで、ずれ込んでしまった。まぁ、こういうのも、また自宅サーバーの醍醐味だろうという気はするので、特に気にしてはいないし、むしろ停止中にメンテ画面に切り替えるためのDNS変更スクリプトとかは作っておいた方がいいだろうなという気付きを得られたりもした。

ひとまず本質的なスペックとしてはさして上がっていないと思われるが、拡張性で言えばマザボのスペックが最新鋭になり、ストレージスロットがやや増えているのもあり、将来的な拡張には耐えてくれるだろうし、この規模の更新は当面しなくて済むだろう。このベーススペックで5年、あるいはそれ以上持つことを期待したいところだ。

ただ、このマザーボードを使ってCPU(Ryzen 7 9800X3D)が壊れたとか、不具合系の話もまことしやかに聞くのでやや心配だが、そこは見守っていきたい。

OCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことを派生させて更にIPv4にも対応させるプラン。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けないが、PPPoEを使って取得したIPv4であれば開けるので、これとIPoE側のIPv6の併用でデュアルスタックでWell-known portsの開放を行い、サーバーを運用できるようにするのが目的だ。

• 確認環境
• 今回の要件
• やり方
  • サーバー側の準備
  • PPPoEインターフェースの作成
  • ファイアーウォールの作成
  • サーバーだけをPPPoEのIPv4通信の対象にする
  • NATを設定する
  • 疎通確認
  • IP変動対策にDDNSを設定する
• トラブルシュート
  • curlで「Connection refused」や「接続が拒絶されました」と出る
  • 同一LANにぶら下がっている端末でDNS解決に失敗する
• 雑感：かなり苦しい

確認環境

今回の要件

• OCNバーチャルコネクト環境でIPv6サーバーを公開した時にやったことに追加でIPv4も開通させる
• IPv4はPPPoEで取得できるものを使う
• サーバーマシン以外の端末に影響を与えない

やり方

サーバー側の準備

ufwではv4にも穴が開いている状態とする

1. nginxの設定を開きIPv4向けにlisten 443 ssl;を追記して保存する
2. nginxを再起動する

PPPoEインターフェースの作成

1. SSHでOpenWrtに入る
2. /etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存

   #
   # reserved values
   #
   128     prelocal
   255     local
   254     main
   253     default
   300     pppoe
   0       unspec
   #
   # local
   #
   #1      inr.ruhep
   

3. 反映する
   • service network restart
4. LuCIに入る
5. Network→Interfacesを開く
6. Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
   

   

7. General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
   

   

8. Advanced Settingsタブを開き、Use DNS servers advertised by peerのチェックを外し、Use gateway metricを10、Override IPv4 routing tableをpppoe (300)にする
   

   

9. Saveボタンを押して保存する
10. wanインターフェースのEditを押す
11. Advanced Settingsタブを開き、Use gateway metricを1にする
12. Saveボタンを押して保存する

ファイアーウォールの作成

1. 引き続きLuCI上で作業する
2. Network→Firewallを開く
3. ZonesのAddボタンを押す
4. Nameをwan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する
   

   

5. lan⇒wanのゾーン設定のEditボタンを押す
6. Allow forward to destination zones:にwan_pppoeを追加し、保存する
   

   

7. Network→Interfacesを開く
8. wanpppインターフェースのEditボタンを押す
9. Firewall Settingsタブを開き、Create / Assign firewall-zoneにwan_pppoeが設定されていることを確認する。設定されていなかったら設定する
   

   

サーバーだけをPPPoEのIPv4通信の対象にする

1. 引き続きLuCI上で作業する
2. Network→Routingを開き、IPv4 Rulesタブを開く
3. General SettingsタブのIncoming interfaceをlanに、SourceをサーバーのIPにする（例：192.168.1.5/32）
   

   

4. Advanced Settingsタブを開く
5. Tableにpppoe (300)を設定し、保存する
   

   

NATを設定する

1. 引き続きLuCI上で作業する
2. Network→Firewallを開き、Port Forwardsタブを開く
3. Addボタンを押す
4. Nameに適当な名前を付け、Restrict to address familyをIPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する
   

   

5. 最後にこれまでの内容をSave & Applyする

疎通確認

1. Network→Interfacesを開き、wanpppのIPv4を拾う
2. ドメインレジストラの設定でAレコードにこれを登録
3. 適当な外部サーバーからcurlを投げて中身が返ってきたらOK

   curl -4 -v https://example.com
   

IP変動対策にDDNSを設定する

/etc/hotplug.d/ifaceに40-pppoeというファイルを755で作り、以下の内容を記述する。

#!/bin/sh

[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wanppp ] || exit 0

vdpw=ここにDDNS更新用のパスワード
pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
logger -t "DDNS - PPPoE IP" $pppoeaddr
# hoge.example.comに対して更新リクエストを飛ばす例
logger -t "DDNS - DOMAIN: hoge" $(wget -O - "https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=example.com&p=$vdpw$&h=hoge&i=$pppoeaddr")

# When making requests for multiple domains, wait 60 seconds between each request

このスクリプトはhotplugイベントが発生したときにファイルパス順に呼ばれるスクリプトらしい。

ひとまずデバイスでなく、インターフェイスが起動したときで、かつインターフェース名がwanpppの時に実行されるように組んである。

注意点として、このエンドポイントはレートリミットがシビアで、60秒以内に送ると503を返してくるようなので、複数回投げる場合はsleep 61とかして間隔をあけると良さそうだ。数が増えてきたらバリュードメインAPIのDNS設定APIを利用した方が早いだろう。

ただしこのAPIはTTLの制御に難があり、処理方法によっては3600秒に固定される罠が潜んでいるので注意が必要だ。

トラブルシュート

curlで「Connection refused」や「接続が拒絶されました」と出る

• /var/log/ufw.logにログがあればufwで穴をあける（まずこれはない）
• ファイアーウォールかルーティングかNATの設定のどこかがおかしいので見直す。

同一LANにぶら下がっている端末でDNS解決に失敗する

PPPoEインターフェース（wanppp）の設定を開き、Advanced SettingsからUse DNS servers advertised by peerのチェックを外すと直る。

雑感：かなり苦しい

IPv4, v6のデュアルスタックに出来たのはいいが、幾つかの端末で繋いだところIPv4側に流れるケースがあった。メインのv6でなく、オプションのv4に行くという状況はやや残念だ。

構成的にもマルチセッションという微妙な形態で、v4とv6でインターフェースが二系統あり、セキュリティもNATとFWがあり、なかなか複雑な状態になってしまった。

Mastodonにおいてはv4IPのインスタンス（兵庫丼）との疎通はTLレベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。

Misskey.ioからは疎通できず、こちらからはユーザープロフィールまではアクセスできるがフォローを押しても音沙汰がない。

結論としてはリッチなアプリケーション通信を伴う用途において、この方式は向かない気がした。恐れくこれはルーターより外側がIPoEとPPPoEで別系統になっている関係で、通信が混乱して上手くいかないパターンがあるのではないかと感じている。

DDNSも制約が厳しいし、Value DomainのAPIはあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。

まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。

7月31日に立てたMastodon作成ロードマップの最後である、自宅サーバーでMastodonをセルフホスティングするのを達成したので、そのログをここに記す。

Ubuntu実機AMD64環境でDockerを使わず、IPv6シングルスタックで構成している。

自宅サーバーを使ってIPv6シングルスタックで通信を待ち受ける方法はOCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことの方に書いている。

• 確認環境
• 前提条件
• 事前準備
• 依存関係のインストールとセットアップ
• Mastodon本体のセットアップ
• なんやかんやの末に立ち上がったMastodonインスタンス
• トラブルシューティング
  • Mastdonのlistenしているポートを変更する
  • Mastodonのエラーページが表示される・Rubyがないとか出るなどセットアップ時のエラー全般
  • 投稿可能な文字数を増やす
    • app/validators/status_length_validator.rb
    • app/javascript/mastodon/features/compose/containers/compose_form_container.js
    • 備考
  • フォローできるが、フォロー一覧にもTLにも出てこないユーザーが出る
  • 「制限に達しました1:35:00 以降に再度実行してください。」とエラーが出る
  • Prometheusでメトリクスを取得する
  • 【未解決】プロフィールを更新すると更新前の状態にぶり返したり、更新後の状態になったりして安定しない
• Dockerを使わなかった理由
• 実際に導入して驚いた部分
  • 簡単な監視ツールがある
  • Webベースの管理画面がある
  • 死ぬほど早い
• 今後やっていきたい部分
• あとがき：OSグローバルのRubyを消してみた

確認環境

Ubuntu実機AMD64環境

前提条件

• 既にnginxを運用しており、IPv6シングルスタックで公開できている
• certbotを使ったLet's EncryptでのTLS証明書発行が可能

事前準備

1. 公開用のドメインを検討し、生み出す
2. Value Domainのコンパネから生み出したドメインをAAAAレコードで登録
3. 拙作の@lycolia/value-domain-dns-cert-registerを使ってTLS証明書を発行

依存関係のインストールとセットアップ

1. 以下のコマンドを流す

   sudo apt update
   
   sudo apt install -y \
       imagemagick ffmpeg libvips-tools libpq-dev libxml2-dev libxslt1-dev file git-core \
       g++ libprotobuf-dev protobuf-compiler pkg-config gcc autoconf \
       bison build-essential libssl-dev libyaml-dev libreadline6-dev \
       zlib1g-dev libncurses5-dev libffi-dev libgdbm-dev \
       nginx redis-server redis-tools postgresql \
       certbot python3-certbot-nginx libidn11-dev libicu-dev libjemalloc-dev \
   
   # 最新版を入れないとうまくいかない
   wget https://github.com/rbenv/ruby-build/archive/refs/tags/v20250811.tar.gz
   tar -xzf v20250811.tar.gz
   sudo PREFIX=/usr/local ./ruby-build-20250811/install.sh
   rm v20250811.tar.gz
   rm -Rf ruby-build-20250811
   
   # aptではサポート切れの化石が入るのとnvmで入れたのは自分しか使えないので新しいのをグローバルに入れる
   curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
   sudo bash nodesource_setup.sh
   apt install -y nodejs
   rm nodesource_setup.sh
   corepack enable
   
   # メンテナンスでめっちゃ使うのでサービスユーザーにはせず、ログイン可能なユーザーとして作る
   adduser --disabled-password mastodon
   

2. /etc/redis/redis.confを開きrequirepassのコメントを外し、パスワードを設定

3. sudo service redis restart

4. sudo -u postgres psqlでポスグレに入り、ユーザーを作る。ポスグレは不慣れで同時にPW設定する方法が判らなかったので別建てで設定している

   CREATE USER mastodon CREATEDB;
   ALTER ROLE mastodon WITH PASSWORD 'パスワード';
   \q
   

Mastodon本体のセットアップ

実際にはかなり行ったり来たりしてるので一部の手順には誤りが含まれている可能性がある。

1. mastodonユーザーにスイッチしてインストール作業を続行

   # Mastodon本体の導入
   sudo su - mastodon
   git clone https://github.com/mastodon/mastodon.git live
   # 超重要、cd忘れててもなんかそれっぽく進むが、以後すべて破綻する
   cd live
   git checkout $(git tag -l | grep '^v[0-9.]*$' | sort -V | tail -n 1)
   
   git clone https://github.com/rbenv/rbenv.git ~/.rbenv
   
   echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
   echo 'eval "$(rbenv init -)"' >> ~/.bashrc
   exec bash
   
   # 動かないやつなのでコメントアウト
   # 依存関係のインストールとセットアップでやった内容をこっちでやってもいいかもしれない
   # git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build
   
   # ここでエラーが出たら何かが間違っているのでやり直し
   RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
   
   # bundleがないとか、rubyのバージョンが存在しないとかエラーが出たら何かが間違っているのでやり直し
   bundle config deployment 'true'
   bundle config without 'development test'
   bundle install -j$(getconf _NPROCESSORS_ONLN)
   yarn install
   
   # 色々尋ねられるので適当に進める
   RAILS_ENV=production bin/rails mastodon:setup
   

2. デーモン周りの設定をする

   # 静的ファイルをnginxに見させるために権限を設定
   sudo chmod o+x /home/mastodon
   
   # デーモンの登録と起動
   sudo cp /home/mastodon/live/dist/mastodon-*.service /etc/systemd/system/
   sudo systemctl daemon-reload
   sudo systemctl enable --now mastodon-web mastodon-sidekiq mastodon-streaming
   sudo service mastodon-web start
   sudo service mastodon-sidekiq start
   sudo service mastodon-streaming start
   

3. nginxの設定を書く

   map $http_upgrade $connection_upgrade {
   default upgrade;
   ''      close;
   }
   
   upstream backend {
       server 127.0.0.1:3000 fail_timeout=0;
   }
   
   upstream streaming {
       # Instruct nginx to send connections to the server with the least number of connections
       # to ensure load is distributed evenly.
       least_conn;
   
       server 127.0.0.1:4000 fail_timeout=0;
       # Uncomment these lines for load-balancing multiple instances of streaming for scaling,
       # this assumes your running the streaming server on ports 4000, 4001, and 4002:
       # server 127.0.0.1:4001 fail_timeout=0;
       # server 127.0.0.1:4002 fail_timeout=0;
   }
   
   proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHE:10m inactive=7d max_size=1g;
   
   server {
       listen [::]:443 ssl http2;
       server_name  <ドメイン>;
   
       ssl_certificate     /etc/letsencrypt/live/<証明書のパス>/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/<証明書のパス>/privkey.pem;
   
       ssl_protocols TLSv1.2 TLSv1.3;
   
       # You can use https://ssl-config.mozilla.org/ to generate your cipher set.
       # We recommend their "Intermediate" level.
       ssl_ciphers CDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA38:DHE-RSA-CHACHA20-POLY1305;
   
       ssl_prefer_server_ciphers on;
       ssl_session_cache shared:SSL:10m;
       ssl_session_tickets off;
   
       keepalive_timeout    70;
       sendfile             on;
       client_max_body_size 99m;
   
       root /home/mastodon/live/public;
   
       gzip on;
       gzip_disable "msie6";
       gzip_vary on;
       gzip_proxied any;
       gzip_comp_level 6;
       gzip_buffers 16 8k;
       gzip_http_version 1.1;
       gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript image/svg+xml image/x-icon;
       gzip_static on;
   
       location / {
           try_files $uri @proxy;
       }
   
       # If Docker is used for deployment and Rails serves static files,
       # then needed must replace line `try_files $uri =404;` with `try_files $uri @proxy;`.
       location = /sw.js {
           add_header Cache-Control "public, max-age=604800, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/assets/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/avatars/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/emoji/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/headers/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/packs/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/shortcuts/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/sounds/ {
           add_header Cache-Control "public, max-age=2419200, must-revalidate";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           try_files $uri =404;
       }
   
       location ~ ^/system/ {
           add_header Cache-Control "public, max-age=2419200, immutable";
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
           add_header X-Content-Type-Options nosniff;
           add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
           try_files $uri =404;
       }
   
       location ^~ /api/v1/streaming {
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_set_header Proxy "";
   
           proxy_pass http://streaming;
           proxy_buffering off;
           proxy_redirect off;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection $connection_upgrade;
   
           add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
   
           tcp_nodelay on;
       }
   
       location @proxy {
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_set_header Proxy "";
           proxy_pass_header Server;
   
           proxy_pass http://backend;
           proxy_buffering on;
           proxy_redirect off;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection $connection_upgrade;
   
           proxy_cache CACHE;
           proxy_cache_valid 200 7d;
           proxy_cache_valid 410 24h;
           proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
           add_header X-Cached $upstream_cache_status;
   
           tcp_nodelay on;
       }
   
       error_page 404 500 501 502 503 504 /500.html;
   }
   

なんやかんやの末に立ち上がったMastodonインスタンス

なんやかんやあり色々苦戦したが、無事立ち上がってくれて何よりだった。

立ち上がった直後。

そして現在。こうやって動いているのを見ると感慨深い。

実は中学生のころから自宅サーバーを立てるという夢を持っており、こうやって実際に公開できたことは感慨深い。実際のところ、実験用の小規模サーバーや、SHOUTcastサーバーだとか、シンクライアント用のSSHサーバーみたいなのは作った経験があり、いずれも外に出していたのでサーバーを作った経験が全くない、というわけではないのだが、監視環境を整えたり、IPv4が実用困難な環境で、IPv6に挑戦してみたりと、ここまで本格的にやったことはなかったのもあり、個人的には結構達成感がある。

トラブルシューティング

Mastdonのlistenしているポートを変更する

3000番はGrafanaをはじめ、様々なNode.js系のポートと干渉するため変えておく。

1. /etc/systemd/system/mastodon-web.serviceのEnvironment="PORT=3000"を変えることでWeb側のポートが変えられる
2. /etc/systemd/system/mastodon-streaming.serviceのWants=mastodon-streaming@4000.serviceの4000の部分を変えることで、Streaming側のポートも変えられる
3. サービスを再起動する

   sudo systemctl daemon-reload
   sudo service mastodon-web restart
   sudo service mastodon-streaming restart
   

4. nginxの設定も対応する箇所を変える
5. nginxを再起動する

   sudo service nginx restart
   

Mastodonのエラーページが表示される・Rubyがないとか出るなどセットアップ時のエラー全般

基本的にどこかの手順が間違ってるのでしつこくやり直すことで改善する。

投稿可能な文字数を増やす

以下の内容で修正すると増やせる。

app/validators/status_length_validator.rb

 class StatusLengthValidator < ActiveModel::Validator
-  MAX_CHARS = 500
+  MAX_CHARS = 50000

app/javascript/mastodon/features/compose/containers/compose_form_container.js

正直このファイルは直さなくても動くし、直しても、ほぼ意味がなさそうなので、直す必要はないかもしれない。

-  maxChars: state.getIn(['server', 'server', 'configuration', 'statuses', 'max_characters'], 500),
+  maxChars: state.getIn(['server', 'server', 'configuration', 'statuses', 'max_characters'], 50000),

備考

変更直後は投稿画面の初期表示に500と出ていて、数文字打つと50000文字に変化する状態だったが、一日くらい経過すると初期値が50000に変わっていたのでキャッシュか何かが悪さをしていた可能性がある。

フォローできるが、フォロー一覧にもTLにも出てこないユーザーが出る

IPv6と疎通してないところは仕方がないね。AAAAレコード持ちでcurl -6 -v https://example.comしても疎通する場所でも起きることがあるが原因は不明。

兵庫丼でも偶に遭遇してたので、そういうものだと割り切るしかない。IPv4滅ぶべし、慈悲はない。

「制限に達しました1:35:00 以降に再度実行してください。」とエラーが出る

APIのレートリミットにかかっているせいっぽい。5分間に300リクエストまでと、かなり渋い。信用するIPを指定することで回避可能らしい。

.env.productionを開き、前述の資料に書かれている信頼できるIPを列挙した後に、自分のIPv6プレフィクス（aaaa:bbbb:cccc:dddd::/64を自分のプレフィクスに置き換え）を追加し、再起動しておいた。これで緩和されると良いのだが、出先では使えないと思うのでどうするか…。

TRUSTED_PROXY_IP=127.0.0.1/8,::1/128,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,fc00::/7,aaaa:bbbb:cccc:dddd::/64

ドキュメントを読む限り、アカウントIDで縛る処理がどこかにあるようなので、自分のIDを除外できれば出先でも起きなくなり、更に良さそうだが、やり方はよくわからなかった。

調べた限りconfig/initializers/rack_attack.rbの中でやっているようなので、暇なときに見てみたいとは思う。

Prometheusでメトリクスを取得する

Mastodonは標準でPrometheusに対応しているので、Exporterの有効化設定を見ながら設定していく。

まず.env.productionを開き、以下の二行を追記し、再起動する。これによってMastodonWebのExporterが有効化され、ローカルホストで動くようになるようだ。Streamingの方は設定せずとも、元から有効になっている模様。

MASTODON_PROMETHEUS_EXPORTER_ENABLED=true
MASTODON_PROMETHEUS_EXPORTER_LOCAL=true

再起動したらcurl http://localhost:{Streamingのポート番号}/metricsとcurl http://localhost:9394/metricsで動いていることを確認。

次にPrometheusのscrape_configsに以下を追記し、Prometheusを再起動する。

  - job_name: 'mastodon-web'
    static_configs:
      - targets: ['localhost:9394']

  - job_name: 'mastodon-streaming'
    static_configs:
      - targets: ['localhost:5001']

Prometheusの管理画面を開き、Target healthに出て動いていればOK。

【未解決】プロフィールを更新すると更新前の状態にぶり返したり、更新後の状態になったりして安定しない

大まかには、このような感じ。再現したりしなかったりでいい感じの動画が撮れなかった…。

キャッシュ周りで何かの問題が起きている可能性があるが原因はよくわかっていない。3分も待てば改善するので一旦気にしないことにした。

Dockerを使わなかった理由

Dockerがあれば一瞬で立ち上がって便利といえば便利なのだが、Ubuntuのネイティブ環境にPrometheusとGrafanaをIPv6スタックで導入した時に、DockerとIPv6の相性が余りにも悪すぎたのが最大の要因。

後はまぁ変なレイヤー隔ててない方が管理楽だし、リソースも抑えられるかなとか。

実際に導入して驚いた部分

簡単な監視ツールがある

Mastodon自体に監視の仕組みがあること。Sidekiqという名前自体はよく聞くので知っていたが、今まではなんとなくジョブ管理システムだと思っていた。これはTLで見かけていた管理人の人たちがトラブルが起きた時にジョブを殺したりしているのを見かけたためだ。

とはいえ、公式サイトの説明にはRuby's fastest job systemとあるので、あながち認識としては間違ってなかったようだ。ジョブ管理システムのついでにメトリクスとかも見れる機能があるのかもしれない。

Webベースの管理画面がある

環境変数周りの設定項目が多く、コンソールから設定を操作するイメージが強く、コンソールベースなのかと思っていたが実際にはWebベースのGUI管理コンソールもあり、中々便利だ。管理面の操作や、サーバー本体への影響がない簡単な設定はここで出来るだろう。

死ぬほど早い

アップロードが爆速だったり、画面遷移もかなり早い。家で繋ぐ分にはLAN環境だから早いのかと思っていたが、外から5Gで繋いでも早い。

今のところ大したアクセスや負荷もなく、リソースがしこたま余ってるお陰かもしれない。あとは単純に手前にCDNがないとか、VPSといった共有資源とかと比べた時のスペックの差だろうか？

スペックは結構ある方だと思う。具体的にはCPUはAMD Ryzen 5 5600G、メモリはDDR4 32GB、SSDもCrucial P1 CT500P1SSD8JPでNVMeといった感じで、そんなハチャメチャに高スペックというわけではないが、よくある？安い中古ノートPCを流用したサーバーと比べたら充実している。

今後やっていきたい部分

主に監視周りの強化をしていきたい。現在のロードマップは以下のような感じだ。

• Grafanaでnginxのダッシュボードを整備
• Lokiの導入
• GrafanaからMastodonのメトリクスを見れるように
• OpenWrt本体でメトリクスをとれるようにしたい
  • 本体が死ぬとテレメトリ取れないので鯖側のPrometheusだと役不足
  • 問題はストレージどうするか…
  • 寿命の関係でeMMCには書けないからNVMe拡張するのか
• OpenWrtのメトリクスを鯖側でも取れるようにする（いるかこれ？
• 外部ステータスページの用意
• 簡単な外形監視の導入？（やるならさくらに乗せる）

まず、Grafanaをセットアップしたもののnginxのダッシュボードが空っぽなので作っていく必要がある。

次にLokiを入れてログ監視もできた方がいい。個別のログファイルを見るのは割とつらい。

Grafanaで統合管理できると便利なのでMastodonのメトリクスも取れると良いので、これもやっていきたい。

他にも今回のセットアップ中にOpenWrtがOutOfMemoryで落ちるケースがあり、原因不明のネットワーク切断が多発したため、こちらのメトリクス収集も必要だ。ネットワーク自体が死ぬと中身が見れないため、基本的に本体側で、収集して見れるようにしたい。今でも簡単なものは入れているが情報量が少なく、役不足だ。

ストレージ寿命の問題もありeMMCにログを吐くとストレージの寿命がマッハになる恐れがあるため、メモリ管理や追加でストレージを用意するなど、手法についても検討する必要がある。

OpenWrtのメトリクスを鯖側でも取れるようにするのはオプションプランだが、これは別にどうでもいい気はする。平時は統合的に見れて便利かもしれない。

あとは外部環境にステータスページを配置したいと考えている。実用性があるかどうかは謎だが、あるとそれっぽいから。ツールとしてはCachetを採用し、さくらのレンタルサーバー側で運用する予定だ。

簡単な外形監視の導入についても、Cachetで担える可能性がある。

監視面以外ではセルフホスティング方式のWAFであるAnubisに興味があり、これも入れていきたいと考えている。

更に中長期では、現在運用しているlycolia.info配下の全サイトを自宅サーバーへ移行し、メールサーバーやネームサーバーなど、現在あるWebサイトの一切を移行する野望も抱いている。

とにかくやることが沢山あるので、当面は暇になることはなさそうで、充実した生活を送れそうだ。

あとがき：OSグローバルのRubyを消してみた

本来手順になく、私の勘違いで追加して作業してしまっていたOSグローバルのRubyを消しても動くのか試してみた。

# 通常ユーザー作業
ls -la /usr/local/bin | grep ruby
rm /usr/local/bin/ruby-build
sudo rm -Rf /usr/local/bin/ruby-build
ls -la /usr/local/share
sudo rm -Rf /usr/local/share/ruby-build
sudo rm -Rf /usr/local/share/man/man1/ruby-build*
ruby -v
sudo apt remove ruby
sudo su - mastodon

# mastodonユーザー作業
mkdir -p "$(rbenv root)"/plugins/ruby-build
cp ruby-build-20250811/. "$(rbenv root)"/plugins/ruby-build
ls -la "$(rbenv root)"/plugins/ruby-build
cd live
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
ruby -v
exit

# 通常ユーザー作業
sudo service mastodon-web restart
sudo service mastodon-sidekiq restart
sudo service mastodon-streaming restart

一旦ここまでは上手くいったので、上の方にある手順よりこっちでやった方がいいかもしれない。Mastodonのビルドが通るかまでは試してないので、実際に動くかどうかまでは不明だが、まぁ次回考えればよいだろう。