お知らせ

現在サイトのリニューアル作業中のため、表示が崩れているページが存在することがあります。

Mastodonのアップグレードメモ

2025/09/15 22:20 ソフトウェア::Mastodon

ハマったので残しておく。

前提条件

  1. GitHubにMastodon本家をForkしたリポジトリがあり、そこをベースに運用している。
  2. git remote -vの状態が以下の通りで、origin/mainが本番運用ブランチ。 
    mastodon        https://github.com/mastodon/mastodon.git (fetch)
mastodon        https://github.com/mastodon/mastodon.git (push)
origin  https://github.com/Lycolia/lycodon.git (fetch)
origin  https://github.com/Lycolia/lycodon.git (push)

やり方

  1. マージブランチを作る 
    git checkout -b merge-latest
  2. 本家を取ってくる 
    git fech mastodon
  3. マージブランチにマージする 
    git merge mastodon/main
  4. セットアップする 
    # swich user
sudo su - mastodon
# 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
  5. 動作確認OKならgit pushしてGitHub上で自分のところのmainにマージする。デフォルトでは本家に向くので注意
  6. もう一度、前述4番のセットアップコマンド一式を流し、問題なければ終わり

トラブルシュート

正常に動いていない場合

ジャーナルを見てエラー原因を特定する。新規要素がらみのパラメーターが出てたらDBが怪しいのでRAILS_ENV=production bundle exec rails db:migrateで直る可能性がある。

sudo journalctl -u mastodon-web -f
コメント（0件）

Dockerを使ってMastodonの開発環境を作る

2025/09/15 16:32 ソフトウェア::Mastodonジャンル::セットアップOS::Linux::Ubuntu

なんか昔のやり方が使えなくなってたので調べたメモ。

確認環境

Env Ver
OS Ubuntu 24.04.3 LTS
Docker version 28.1.1, build 4eba377
Docker Compose v2.35.1
Mastodonのバージョン v4.5.0-alpha.2
Mastodonのコミットハッシュ 06803422da3794538cd9cd5c7ccd61a0694ef921

手順

DEVELOPMENT.md#dockerの手順通りにやると行ける。

docker compose -f .devcontainer/compose.yaml up -d
docker compose -f .devcontainer/compose.yaml exec app bin/setup
docker compose -f .devcontainer/compose.yaml exec app bin/dev

コンテナへのアタッチ方法

# 方法1
docker compose -f .devcontainer/compose.yaml exec app zsh

# 方法2
cd .devcontainer
docker compose exec app zsh

VSCodeがあるならDockerやRemoteほげほげ系の拡張を使い、devcontainer-appにAttach Shellしてもよい。

検証ユーザーの作成

  1. 次のコマンドでユーザーを作る 
    ./bin/tootctl accounts create hoge --email hoge@example.com --confirmed
  2. ユーザーの承認を行い、必要に応じてパスワードを使いやすいものに変更する 
    rails console
user = Account.find_by(username: 'hoge').user
user.approve!
# PW変更ここから
user.password = 'password'
user.skip_confirmation!
# PW変更ここまで
user.save!
quit

フロントエンドのビルドとサーバー起動

bin/rails assets:precompile
bin/dev

トラブルシューティング

localhostではアクセスできるが、マシンのホスト名やhoge.testのようなローカルドメインでアクセスできない

.env.developmentにALTERNATE_DOMAINS=hoge.testの行を追加することで他のドメインでもアクセスできる。

この設定があるとMastodonを別環境で動かしててリモートからドメインアクセスする場合に便利。

ActiveRecord::PendingMigrationErrorなど、ActiveRecord関係のエラーが出る

コンテナの中でrails db:setupを叩くことで解決する。

Unable to load application: NameError: uninitialized constant LetterOpenerWebというエラーが出る

リポジトリルートにあるdocker-compose.ymlを使うと発生するので、.devcontainer/compose.yamlを使う事で解決する。

あとがき

検証用にバニラなMastodon環境が欲しくて作ってみたが昔と変わっていて地味にハマった…。

コメント（0件）

Mastodon改造メモ

2025/08/25 03:13 ソフトウェア::Mastodon

Mastodonの最大アップロードサイズを変更する

確認環境

Env Ver
Mastodon v4.5.0-alpha.2
nginx 1.26.1

手順

  1. Mastodonのapp/models/media_attachment.rbのIMAGE_LIMIT, VIDEO_LIMIT, MAX_VIDEO_MATRIX_LIMIT, MAX_VIDEO_FRAME_RATE, MAX_VIDEO_FRAMES辺りをいい感じに直す
  2. nginxのmastodon用設定を開き、client_max_body_size 100m;をいい感じに直す
  3. mastodonとnginxを再起動する
  4. 適当にデカいファイルをあげて確認する
  5. 確認用ファイルを消したい場合は、public/system/media_attachments/files/にあるので消す

Mastodonの最大投稿文字数を増やす

確認環境

Mastodon v4.5.0-alpha.2

手順

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

注目タブを固定した投稿に変更する

確認環境

Mastodon v4.5.0-alpha.2

やり方

割と力押してやったのでイケていない。

  1. 変更時の差分を参考に改造

  2. 資材のビルドを行い、Webを再起動

    RAILS_ENV=production bundle exec rails assets:clobber
RAILS_ENV=production bundle exec rails assets:precompile

必要に応じてsudo chown -R mastodon /home/mastodonで所有権を戻しておく。

TL周りのCSSをいじる

確認環境

Mastodon v4.5.0-alpha.2

手順

  1. app/javascript/styles/mastodon/components.scssを適当に編集

  2. 資材のビルドを行い、Webを再起動

    RAILS_ENV=production bundle exec rails assets:clobber
RAILS_ENV=production bundle exec rails assets:precompile

必要に応じてsudo chown -R mastodon /home/mastodonで所有権を戻しておく。

コメント（0件）

Mastodonのアップデートやメンテナンスが出来るようにしてみた

2025/08/23 07:42 ソフトウェア::Mastodon

先日、Ubuntu実機IPv6シングルスタック環境にMastodonを入れた時に軽く改造していたが、どうせならGitHubで管理したいよね、するなら他所みたいに本家をフォーク下リポジトリでやりたいねと思ったので、やってみた。

やったこと

  • 本家リポジトリをフォークしたリポジトリで作業できる下地を作成
  • Mastodon v4.4.3からMastodon v4.5.0-alpha.2にアップデート
  • VSCodeのRemoteSSHを利用し、本番環境でのバックエンドとフロントエンドの軽微な改修を行い、普段使っているGit環境でGitHubに署名付きコミット
  • 引用リブログ対応

快適な作業環境を作る

毎回sudo su - mastodonしてコンソールからゴリゴリやるとか苦行でしかないのでVSCodeのRemoteSSHでしばけるようにする。

  1. mastodonグループに自分を入れてVSCodeで直に触れるようにする 
    sudo usermod -aG mastodon $USER
  2. VSCodeを落として再起動してSSHを繋ぎ直す
  3. 普通に編集やコミットが出来るようになっていればOK
  4. コミットするときにCIが走るが本番向け設定では動かないので、--no-verifyを付けてターミナルからコミットする

本家最新と合流する

  1. 本家リポジトリからフォークしたリポジトリを作る
  2. リモートリポジトリを切り替える 
    git remote remove origin
git remote add origin <自分のリポジトリURL>

  3. ビルドする

    # mastodonのホームに環境があるため、ここだけはユーザー切り替えが必要
sudo su - mastodon
# 依存関係の更新
gem update --system
# Ruby本体の更新
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
# この設定がないとエラーが出てbundle installできなかった
export LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2
# Gemのインストール
bundle install
# JSやCSSなどのフロントエンドのビルド
RAILS_ENV=production bundle exec rails assets:clobber
RAILS_ENV=production bundle exec rails assets:precompile

# 再起動、念のためにstop->start
sudo systemctl stop mastodon-{web,sidekiq,streaming}
sudo systemctl start mastodon-{web,sidekiq,streaming}

コードのいじり方

正直よくわかっておらず雰囲気でやっている。

Ruby本体

.rbファイルをいじった後にmastodon-webサービスを再起動で恐らくOK。streaming関係を触ったらそっちの再起動も必要だろう。

フロントエンド

CSSやVue周りのファイルをいじった場合はビルドのために以下のコマンドを流す必要がある。サービスの再起動が必要かどうかまではよくわかっていない。

RAILS_ENV=production bundle exec rails assets:clobber
RAILS_ENV=production bundle exec rails assets:precompile

引用リブログの有効化

こういう奴をできるようにする方法。

.env.productionを開きEXPERIMENTAL_FEATURES=outgoing_quotesを追記。

この手の実験的機能のフラグはenvironment.tsに定義されているものが使えると思われる。カンマ区切りで利用するようだ。

やっておいた方がいいこと

.bashrcや.zshrcなど、mastodonユーザーが使っているシェルの設定に以下の環境変数を足しておく。毎回叩くの面倒なので。

export RAILS_ENV=production
export LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2

トラブルシューティング

「/lib/x86_64-linux-gnu/libjemalloc.so.2 cannot allocate memory in static TLS block」エラーへの対処

以下のエラーが出る場合、export LD_PRELOAD=/lib/x86_64-linux-gnu/libjemalloc.so.2を打ち込んでおくと改善した。

Unfortunately, an unexpected error occurred, and Bundler cannot continue.

First, try this link to see if there are any existing issue reports for this error:
https://github.com/rubygems/rubygems/search?q=%2Flib%2Fx86_64-linux-gnu%2Flibjemalloc.so.2++cannot+allocate+memory+in+static+TLS+block+-+%2Fhome%2Fmastodon%2Flive%2Fvendor%2Fbundle%2Fruby%2F3.4.0%2Fgems%2Fdate-3.4.1%2Flib%2Fdate_core.so&type=Issues

If there aren't any reports for this error yet, please fill in the new issue form located at https://github.com/rubygems/rubygems/issues/new?labels=Bundler&template=bundler-related-issue.md. Make sure to copy and paste the full output of this command under the "What happened instead?" section.

コメント（0件）

Ubuntu実機IPv6シングルスタック環境にMastodonを入れてみた

2025/08/21 13:23 ジャンル::サイト運営ジャンル::自宅サーバーソフトウェア::Mastodon

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

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

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

確認環境

Ubuntu実機AMD64環境

Env Ver
Ubuntu 24.04.3 LTS
nginx 1.26.1
Mastodon v4.4.3
Ruby 3.2.3
ruby-build 20250811
rbenv 1.3.2-10-gd1a19a3

前提条件

事前準備

  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のビルドが通るかまでは試してないので、実際に動くかどうかまでは不明だが、まぁ次回考えればよいだろう。

コメント（0件）