検索条件

から
検索タグ ネットワーク::IPv6
指定期間 2025年の記事
タグで絞り込み OS(1) OS::Linux(1) OS::Linux::Ubuntu(1) Webサービス(1) Webサービス::Value-Domain(1) ジャンル(6) ジャンル::ガジェット(1) ジャンル::サイト運営(2) ジャンル::自宅サーバー(5) ソフトウェア(4) ソフトウェア::Mastodon(1) ソフトウェア::OpenWrt(3) ネットワーク::IPv4(1) ネットワーク::OCNバーチャルコネクト(2) 技術(1) 技術::監視(1) 言語(1) 言語::PHP(1)
日付で絞り込み 3月(1) 8月(5) 9月(1) 10月(1) 11月(1)
全9件 (1/2ページ)

2025/11/12(水)PHPでIPv6によるアクセスから国情報を取得する

投稿日：

日本国内からのアクセスを識別するときに、IPv4の頃はリモートホスト名が/\.jp$/であるかや、nifty.comみたいな例外を個別で見てやる程度で何とかなっていたが、IPv6は逆引きができないので、それをどうにか解決する方法。

確認環境

Env Ver
PHP 8.3.8
geoip2/geoip2 3.2.0

やり方

  1. ComposerでGeoIp2を入れる 
    php composer.phar require geoip2/geoip2
  2. dbipからIP to City Lite databaseのMMDBを落としてくる。
    https://download.db-ip.com/free/dbip-city-lite-2025-11.mmdb.gzのURL形式なのでYYYYとMMのとこをいじっても落とせる。

  3. こんな感じにコードを書く

    <?php
require 'vendor/autoload.php';
use GeoIp2\Database\Reader;

// 落としてきたMMDBを指定
$cityDbReader = new Reader('dbip-city-lite-2025-11.mmdb');

// IPを渡すと結果が取れる
$record = $cityDbReader->city('2403:6200:8860:e103:a4b2:ff66:9e68:6436');

print($record->country->isoCode . "\n"); // 'US'
print($record->country->name . "\n"); // 'United States'
print($record->country->names['zh-CN'] . "\n"); // '美国'

print($record->mostSpecificSubdivision->name . "\n"); // 'Minnesota'
print($record->mostSpecificSubdivision->isoCode . "\n"); // 'MN'

print($record->city->name . "\n"); // 'Minneapolis'

print($record->postal->code . "\n"); // '55455'

print($record->location->latitude . "\n"); // 44.9733
print($record->location->longitude . "\n"); // -93.2323

print($record->traits->network . "\n"); // '128.101.101.101/32'

参考

あとがき

国情報を利用してアクセスを弾く必要があったので雑に調べて導入したが、dbipの無料DBは正確性が低いので、個人の小規模利用向けだと思う。

エンタープライズ用途などで制度が必要な場合は有料DBの契約を検討したほうがいいだろう。

しかしGeoIp2はPHPのマニュアルにあるからPHPに組み込みで存在してるのかと思ったら、まさかのComposerで驚いた。PHPも変わったなぁ…とかしみじみ。

でも昔からPearはあったような気もするし、今更か…？

コメント（0件）

2025/10/23(木)IPv6アクセス比率集計結果

投稿日：

Google Analyticsを廃止してMatomoを導入してから集めていたIPv6のアクセス比率を集計した結果をメモしておく。

集計期間は2025/08/17～2025/10/21。

サイト IPv6ビジット IPv4ビジット
lycolia.info 56 (55.0%) 77 (45.0%)
ブログ (blog.lycolia.info) 2,018 (43.4%) 2,644 (56.7%)
ECO-Wiki (eco.lycolia.info/wiki) 7,946 (40.5%) 11,291 (59.4%)
ツールサイト (tool.lycolia.info) 13 (65.0%) 7 (35.0%)
合計 10,033 (41.7%) 14,019 (58.2%)

以上の結果からIPv6は約四割、v4は約六割ということが分かった。また最もアクセスがあるのはECO-Wikiで、ツールサイトにはほぼアクセスがないことも明確になった。まぁツールは私が使えればいいので仕方ないね。

lycolia.infoは突出してIPv6のアクセスが多いが、実数が少なすぎるので余りアテにならない。ただ恐らく、リンク元の特性的に、ITオタク周りのアクセスが多いことが想定されるため、この結果はある程度妥当かもしれない。ツールサイトもそういう人が興味を持って踏んでるのだとしたら納得だ。ブログも技術記事がある関係で比率が高い可能性がある。

逆にECO-Wikiは比較的一般向けのサイトなので比率が少なくなっていると思った。

あとがき

まだまだIPv4の環境は多く、IPv6シングルスタックへの移行はやや戸惑うレベルだ。GitHubのWebhookもIPv4だったりするので、しばらくはデュアルスタックで運用していくのが無難だろう。

現状さくらのレンタルサーバー上にある資源を自宅サーバーにフル移行する場合、DNS側の制約でマルチドメインのDDNSが面倒な問題があるため、専用のスクリプトを作る必要が出てきそうだ。

これは契約しているDNSサーバーのDDNSが1回に1レコードしか更新できず、レートリミットが60秒に1回という面倒な仕様なため、ドメインが複数あると厄介なのだ。現状Mastodonだけが自宅サーバーにある状態なのでどうにかなっているが、どうにかして対処しないといけない。

契約しているDNSサーバーにはDDNS API以外にも、DNSレコードを全部書き換えられるAPIがあり、こちらは1回に複数レコードを触れるため、比較的レートリミットを気にする必要がなくなる。なので、これを使って自力で書き換えるスクリプトを組めばDDNS APIのレートリミットは無視できるようになる。まぁ、こっちのAPIはレートリミットが緩いので何度でも叩けるのだが、バルク編集できるAPIを何度も叩く意味もないので…。

これとは関係なく、将来的には自宅サーバー側に権威DNSを立てて、レジストラのDNSサーバー側にはNSレコードだけというのもやってみたさがある。この場合、ドメインの追加や削除で一々レジストラの管理画面にアクセスする頻度が減らせ、管理が楽になるメリットがありそうだし、レジストラのDNSでは実現できないことが出来るようになる可能性もあるだろうから面白いかもしれない。

コメント（0件）

2025/09/09(火)WindowsとUbuntuでIPv6のGUAを拾う方法

投稿日：

確認環境

NICはともに一つのみ。

  • Windows 11 Pro 24H2
  • Ubuntu 24.04.3 LTS

Windows

NICのIPv6アドレス(GUA)を取得する

コントロールパネルから取得
  1. コントロールパネル→ネットワークと共有センターを開く
  2. イーサネット→詳細を開く
  3. IPv6アドレスと書かれているのがGUA
コマンドプロンプトで取得

ipconfigを叩き、「IPv6 アドレス」と書かれているものがGUA

Powershellで取得
(ipconfig | Select-String -Pattern "IPv6 アドレス(?: .)+: (.+)").Matches.Groups[1].Value

Ubuntu

# perl版
ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'

# awk版
ip -6 addr | grep 'global dynamic' | awk '{ split($2, a, "/"); print a[1] }'
コメント（0件）

2025/08/22(金)OCNバーチャルコネクト環境でIPoE・PPPoE併用のIPv4、IPv6デュアルスタックでサーバーを公開する

更新日：
投稿日：

この記事はフレッツ光ネクストを対象としたものです。フレッツ光クロスには当てはまらないので注意してください。

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

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

確認環境

環境 内容
ISP OCN光
ISP契約 OCN 光 with フレッツ マンション・スーパーハイスピード 隼・プラン1・西日本
ISP接続方式 OCNバーチャルコネクト(IPoE, MAP-E)
RouterOS OpenWrt 24.10.0
ServerOS Ubuntu 24.04.3 LTS
HTTPD nginx 1.26.1
ドメインレジストラ Value Domain

今回の要件

やり方

サーバー側の準備

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はあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。

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

2026-05-23追記：この状態で安定運用しているがv4側が疎通しない相手については諦めた

OpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作ったのもあり、IPv4が変わったときも自動で切り替えることでダウンタイムを減らす運用ができたので、今のところ不満はない。

ただFediverseで繋がらないところは繋がらないので諦めることにした。

コメント（0件）

2025/08/21(木)Ubuntu実機IPv6シングルスタック環境に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 [::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側のポートが変えられる。Environment="BIND=[::1]"とすることでIPv6で待ち受けられる
  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件）