Lycolog

今日は遂に運営サイトの大半をさくらのレンタルサーバーから自宅サーバーへ移行することに成功した。

自宅サーバーでの個人サイト運営は中学時代からの夢だったので、悲願が叶ったようでちょっと嬉しい。

• 移行したサイトなど
• やったこと
  • さくらのレンタルサーバから自宅サーバーへファイルを移設し、権限を設定
  • cgi-binフォルダを使っているスクリプトの対策
  • ヘッダーモジュールの有効化
  • さくらのレンタルサーバのMySQLからDBをダンプし、自宅サーバーのMariaDBに取り込み
  • nginxとApache2の設定を追加
  • SSIの有効化
  • アプリケーションのDBの向き先を変更
  • Matomoの設定
  • ドメインの切り替え
• トラブルシューティング
  • cgi-binを含むパスが/usr/lib/にマップされた
  • ダンプ取り込み時にERROR 1273 (HY000) at line 30: Unknown collation: 'utf8mb4_0900_ai_ciが出る
  • MySQLを叩くCGI実行時にException while creating PDO object:SQLSTATE[HY000] [2002] Connection refusedが出る
  • CGI実行時にEnd of script output before headers: hoge.cgi,が出る
  • .htaccess: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration
  • nginx -> Apache2のリバプロ環境でMatomoが無限リダイレクトしたり、エラーログを吐きまくる
  • 504エラーが出たり、やたらめったら凄く重い
• あとがき

移行したサイトなど

次のサイトやサービスを移行した。

• lycolia.info - lycolia.info
  • エントランスページ、LPみたいなもん
• Lycolog - blog.lycolia.info
  • このブログ。このブログは2019年より前のログがないが、実はこのサイトは元からブログとして発祥している。当時はブログという概念はなく、日記サイトだった
• Webツール置き場 - tool.lycolia.info
  • 適当に作った便利ツールを置いている
• ECO-Wiki (lycolia) - eco.lycolia.info
  • 最近一言BBSへの書き込みがないのが気がかりなWiki。実はアクセスは落ちてない
• アクセス解析 Matomo
• TinyTinyRSS

やったこと

さくらのレンタルサーバから自宅サーバーへファイルを移設し、権限を設定

# サイト単位にtarballに固める
tar -cf hoge.tar hoge
# Windows上のRLoginを使って、NASとしてマウントしている自宅サーバーに転送
cp hoge.tar <ホスティングファイル置き場>
tar -xf hoge.tar hoge
# Apacheから見えるように
chown -R www-data:www-data <ホスティングファイル置き場>/hoge
# www-dataに属するユーザーがいじれるように
chmod -R g+rxw <ホスティングファイル置き場>/hoge

cgi-binフォルダを使っているスクリプトの対策

詳細はトラブルシューティングの該当項目参照

ヘッダーモジュールの有効化

使ってるやつがいたので有効化。

sudo a2enmod headers

さくらのレンタルサーバのMySQLからDBをダンプし、自宅サーバーのMariaDBに取り込み

sudo mysql -u <ユーザー名>
CREATE DATABASE <DB名>;
exit
# 照合順序をMariaDB方式に変換
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' ~/hoge.sql
sudo mysql <DB名> < ~/hoge.sql

nginxとApache2の設定を追加

nginx -> Apache2の構成にしているので、これの設定。基本的にレンサバでホスティングしていたものはApacheの上にのせておくと色々と楽だ。.htaccessは神だし、静的ファイルやCGIのホスティングをする場合、Apacheは取り回しがとても良い。

1. /etc/nginx/conf.d/にサイトごとのリバプロの設定を置く。一例としてはこんな感じ

   server {
   listen 443 ssl;
   listen [::]:443 ssl;
   server_name  eco.lycolia.info;
   
   client_max_body_size 100M;
   
   ssl_certificate     /etc/letsencrypt/live/lycolia.info/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/lycolia.info/privkey.pem;
   
   location / {
       proxy_pass http://apache/;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-Proto $scheme;
   }
   }
   

2. /etc/apache2/sites-enabled/にもサイトごとの設定を書く。一例としてはこんな感じ

   <VirtualHost *:8080>
           ServerName eco.lycolia.info
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/path/to
   
           # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
           # error, crit, alert, emerg.
           # It is also possible to configure the loglevel for particular
           # modules, e.g.
           #LogLevel info ssl:warn
   
           ErrorLog ${APACHE_LOG_DIR}/eco-error.log
           CustomLog ${APACHE_LOG_DIR}/eco-access.log combined
   </VirtualHost>
   

このリバプロの設定の意味合いについては過去に書いたnginxからApache2のバーチャルホストにいい感じにリバプロする方法、nginxからApache2へセキュアにリバプロしたときに真のクライアントIPを取得できるようにするを参照。

SSIの有効化

今時SSIを使ってる人なんてまずいないと思うが、令和最新版ということで…。

やり方

1. SSIモジュールを有効化する

   sudo a2enmod include
   

2. /etc/apache2/apache2.confを開き、全域でSSIを有効化。ついでにDirectoryIndexにも入れとく。SSIの設定はDirectoryディレクティブの中でないと効かない

   <Directory /var/www/>
           AllowOverride All
           DirectoryIndex index.php index.cgi index.shtml index.html index.txt
           # Optionsに+Includesの部分を追加する
           Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch +Includes
           AddHandler cgi-script .cgi
           Require all granted
   </Directory>
   

.shtmlの場合にSSIを許可するように管理しているのは恐らく/etc/apache2/mods-enabled/mime.confだと思われる。ここでMIME-TYPEも付与していると思われる。

バーチャルホストやんいやパス単位にしたい場合は適当なDirectoryディレクティブにOptions +Includesを書けば機能する。

余談だがSSIはエントランスページの更新日時を出すのに使っていて、過去に記事のネタにしたこともある。

アプリケーションのDBの向き先を変更

移設したMatomoとTTRSSは共にMySQLを使っていたためMySQLの接続情報を書き換えた。

DBの接続先はlocalhostでなく、127.0.0.1でないと上手くいかなかった。::1も通らなかったため、恐らくIPv6でListenしていないのだと思う。

Matomoの設定

1. 無限リダイレクト抑制のためconfig/config.ini.phpのeneralセクションにassume_secure_protocol = 1を追加する。詳細はトラブルシューティングの該当項目参照
2. gd2以上を入れろと言われるので使っているPHPのバージョンにあったものを入れる

   sudo apt install php8.3-gd
   

3. MySQLのmax_allowed_packetが少なすぎると言われるので/etc/mysql/my.cnfを開きmysqldセクションに設定を足す

   [mysqld]
   + max_allowed_packet=64MB
   

ドメインの切り替え

1. Value-DomainのDNS管理画面を開き、移設したドメインを全て自宅サーバーに向けた
2. 移設前はAレコードとMXレコードのIPが同一だが、今回からAレコードとMXレコードのIPが変わるので分離した。これで合っているのか怪しいが一応メールが届くことは確認している

   +mx mx.lycolia.info. 10
   +a mx 133.167.8.98
   +aaaa mx 2403:3a00:101:13:133:167:8:98
    mx lycolia.info. 10
   -a 133.167.8.98
   -aaaa 2403:3a00:101:13:133:167:8:98
   +aaaa @ 2400:4153:8f01:c800:c14b:3f7a:2b54:353a
   +a @ 133.167.8.98
   

3. 今回移設したドメインを対象にvalue-domain-dns-utilのvd-ddns-v4.plでDDNSを行う設定を追加

トラブルシューティング

cgi-binを含むパスが/usr/lib/にマップされた

例えば/var/www/html/hoge/cgi-bin/mgcount/mgcount.cgiを実行すると/usr/lib/cgi-bin/mgcountを叩こうとしてコケる問題と出会った。

実際に出たログの一例としては以下のような状態だった（IPはマスクしているが他はそのまま）

[Wed Jun 03 21:02:12.751027 2026] [cgid:error] [pid 865047] [client xxxx:xxxx:xxxx:xxxx:xx:xxxx:x:x:x] AH01264: script not found or unable to stat: /usr/lib/cgi-bin/mgcount, referer: https://lycolia.info/index.shtml

これはどうも規定ではcgi-binが入ったパスを/usr/lib/cgi-bin/にバインドする振る舞いがあるらしく、sites-enabled/の設定に次の記述をすることで正しいパスを呼び出すことができるようになった。

<VirtualHost *:8080>
        ServerName hoge.lycolia.info

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/hoge

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/hoge-error.log
        CustomLog ${APACHE_LOG_DIR}/hoge-access.log combined

        # ScriptAliasで既存のバインドを上書きする
        ScriptAlias /cgi-bin/ /var/www/html/hoge/cgi-bin/
</VirtualHost>

ダンプ取り込み時にERROR 1273 (HY000) at line 30: Unknown collation: 'utf8mb4_0900_ai_ciが出る

MySQLとMariaDBで照合順序の名前が違うらしいのでダンプファイルをMariaDB流で置換する。

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' ~/hoge.sql

MySQLを叩くCGI実行時にException while creating PDO object:SQLSTATE[HY000] [2002] Connection refusedが出る

DBに繋がっていないのが原因。ポート番号やIDPWなどに間違いがなく、ローカルDBに繋ぐ場合、DBの接続先をlocalhostでなく、127.0.0.1にすれば直る。

CGI実行時にEnd of script output before headers: hoge.cgi,が出る

これはHeaderを吐く前にエラーが標準出力されているので出るエラーと思われる。昔PHPやってた人にはお馴染みのやつ。

Shebangに書かれているパスにPerlがないのが原因なのでShebangのパスを見てそこにシンボリックリンクを張っておく。

sudo ln -s /usr/bin/perl /usr/local/bin/perl

.htaccess: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration

ヘッダーモジュールを有効化する。

sudo a2enmod headers

nginx -> Apache2のリバプロ環境でMatomoが無限リダイレクトしたり、エラーログを吐きまくる

一般的に内部リバプロはhttpで送るが、これが原因。

Matomoはhttpリクエストをhttpsにリダイレクトするが、リバプロがhttpでリクエストしてくるため無限ループになって発生する。MatomoのGitHubリポジトリのIssueに山ほどある問題。

解消法としては以下の様にconfig/config.ini.phpのGeneralセクションでassume_secure_protocol = 1を設定すればよい。

 [General]
+assume_secure_protocol = 1

504エラーが出たり、やたらめったら凄く重い

アクセスが集中してるときにMatomoがDBエラーを吐いてるとAMD Ryzen 5 8500Gでメモリ32GBのNVMe SSDを積んだマシンですら504が出る程度には重かった。

エラーを潰したら平和になった。

あとがき

2017年から自宅サーバーをマイペースに運用しており、初期はSSHDを立てただけの簡易NASやシンクラ環境として使っていたが、去年からMastodonの運用をはじめ、中学のころの夢だった鯖缶になることができた。そして更に今回、死活監視用に確保しているサイト（未構築）を除き、全てのサイトを自鯖に移行できたので、まさに中学生のころに夢見た、Webサイトを運用する鯖缶になることができ、感激もひとしおだ。

移設作業中は通信トラフィックやディスクI/Oが一気に跳ね上がったりだとか、CPUやメモリも結構頑張っていて、運用しているMastodonがやたら重くなったのが印象的だった。

何せこのブログだけでファイル数15,197の容量13GBもあるのだから無理もない。

あと移設作業中にadiaryのOGPが出なくてなんでだ？と思ったら、HTTPSの判定処理に漏れがあり、HTTPでURLが出ていたので、リバプロのヘッダもみるように改修した。実装上、リバプロしていない場合に子のヘッダが送られてきてもHTTPSになってしまうが、困るのはそんな不正な要求を送った本人なので、特に問題ないだろう。

さて、ここまで来たら次は以前も話に出した、Anubisを導入してWAFを掛けたり、現在日々増強中の監視体制の強化を続けていくなどして、自作サーバーライフを楽しんでいきたいところだ。

振り返ってみたら2025/08/21から今日までの間になんと三回も言及しており、これで四回目らしい。草。

特に意味はないが、過去にあったAnubisへの言及を以下にまとめてみた。

• 2026/05/26 直近でやりたいことリスト
• 2026/05/30 このブログにやってくる海外IPのBOTの挙動を軽く調べた
• 2025/08/21 Ubuntu実機IPv6シングルスタック環境にMastodonを入れてみた

なんと言うか一年くらい塩漬けにしていたプロジェクトが最近はじわじわ進んでいる気がしていて、非常に清々しい。

そういえばadiaryをサーバーモードで動かすと早いという話があるので、そっちも試してみたいところだ。これは最近記事の増加に伴い中々重くなってきているのを感じているからだ。

やりたい事がたくさん湧いてくるのは充実していてとても良い。

OpenWrtのメトリクスやログをUbuntu側のGrafanaで見れるようにするまで。

メトリクスの取得にはPrometheus、ログはLokiを使っている。

• 確認環境
• Prometheusでメトリクスを取得してGrafanaで見れるようにする
• ログをLokiに送る
• 既知の問題
  • 複数行のエラーログがLoki上で別のログになる
• おまけ：Lokiにログを投げる方法
  • LokiのAPIペイロード
  • ペイロードの意味合い
• おまけ：Loki exporter for OpenWRTのエラーログ
• あとがき

確認環境

監視する側

監視される側

Prometheusでメトリクスを取得してGrafanaで見れるようにする

ほぼOpenWRT | Grafana Labsに書いてある通り。

1. 必要なパッケージをインストールする

   opkg update
   opkg install \
      prometheus-node-exporter-lua \
      prometheus-node-exporter-lua-nat_traffic \
      prometheus-node-exporter-lua-netstat \
      prometheus-node-exporter-lua-openwrt \
      prometheus-node-exporter-lua-thermal
   

2. /etc/config/prometheus-node-exporter-luaを以下のように編集する

   config prometheus-node-exporter-lua 'main'
   +         option listen_interface 'lan'
   -         option listen_interface 'loopback'
           option listen_port '9100'
           #option cert '/etc/uhttpd.crt'
           #option key '/etc/uhttpd.key'
   

3. prometheus-collectors/filesystem.luaとprometheus-collectors/meminfo.luaを拾ってきて/usr/lib/lua/prometheus-collectorsに配置する
4. サービスを再起動

   /etc/init.d/prometheus-node-exporter-lua restart
   

5. /etc/prometheus/prometheus.yaml

   - job_name: "OpenWRT"
     static_configs:
       - targets: ['xxxx:xxxx:xxxx:xxxx::1:9100']
   

6. Prometheus再起動

   sudo systemctl restart prometheus.service
   

7. 取れるメトリクスの一覧

   curl 'http://[xxxx:xxxx:xxxx:xxxx::1]:9100/metrics'
   

8. Grafanaのダッシュボードを作成しID: 18153を取り込む
9. WiFi関係使ってないので全消し
10. Used SWAPのQueriesを以下のように書き換えて0除算でエラーが出ないようにする

    (
      (
        (node_memory_SwapTotal_bytes{instance=~"$node:$port",job=~"$job"} - node_memory_SwapFree_bytes{instance=~"$node:$port",job=~"$job"})
        /
        (node_memory_SwapTotal_bytes{instance=~"$node:$port",job=~"$job"} > 0)
      ) * 100
    )
    or
    (node_memory_SwapTotal_bytes{instance=~"$node:$port",job=~"$job"} * 0)
    

細かい部分の整理はまた追々として、いい感じに見れるようになった気がする。

ログをLokiに送る

Loki exporter for OpenWRTが動かないので自作した。

1. OpenWrtのログをLokiに送るやつを拾ってくる
2. インストール方法にある通りにファイルを配置、設定ファイルをいじる
3. Lokiにログが飛んでればOK
   • ログが飛んでいない場合は/tmp/openwrt-loki.errの中身を見てエラーがないか見る

一旦こんな感じで見れるようになった。

既知の問題

複数行のエラーログがLoki上で別のログになる

親子関係を作ってないせい。Claude Opus 4.8には難しいようだったので、そのうち作る。

おまけ：Lokiにログを投げる方法

POST /loki/api/v1/pushを叩けばよい。ペイロードは以下の書式。

LokiのAPIペイロード

{
  "streams": [
    {
      "stream": {
        "label": "value"
      },
      "values": [
          [ "<unix epoch in nanoseconds>", "<log line>", { "hoge": "aaaa", "fuga": "1234" } ],
          [ "<unix epoch in nanoseconds>", "<log line>", { "hoge": "bbbb", "fuga": "2345" } ]
      ]
    }
  ]
}

ペイロードの意味合い

nginxのログはペイロードしか入ってなかったりするがどうやって実現してるのか不明。もしかするとvalues[1]にJSONを突っ込んでるのかもしれない。

おまけ：Loki exporter for OpenWRTのエラーログ

あのシェルスクリプトを読む気が起きなかったので、なぜこうなっているかはわからない。

BOOT=0 /bin/ash /usr/bin/loki_exporter
openwrt-loki-exporter/v1.0.6-0-gd20fb55-20260322-23413663016 started with BOOT=0
/usr/bin/loki_exporter: line 257: malformed ?: operator

あとがき

去年の8月にはやろうとしていたものの、そのままズルズルと長らく放置していたOpenWrtの監視周りだが、このままではいけないということで、一旦は雑に整備した。

大変雑なのでログ周りは機能するかも怪しいし、私以外が使えるようにも作ってない。最低限動くとかそんなレベル。LLMが書いたコードもろくにレビューしていないので、動いている原理さえ不明だ。

幸い全部で300行そこらなのでおいおい読んで理解していきたいとは思う。

基本原理はlogread -fした結果をいい感じに取り込んでLokiにたたきつけているだけのはずだが、この「いい感じ」が難しく、重くなっていると考えている。例えばログの取得漏れや、重複取得などを考慮しないといけないので、なんかそこら辺をいい感じにやってもらうようにLLMに指示したら一気に重くなった。ベースのコードは私が書いていたのだが、全くの別物になってしまった。

しかし去年の8月にしかかって放置している部分はできていないので、またそこは追々やっていきたいところだ。具体的には今回の対応はサーバー側でメトリクスを見る対応なのでネットワークが死ぬと終わってしまう。そこでルーター側でも簡易に見れるのを作ろうという計画がある。

しかしルーター側はスペックがしょぼいので大したことはできないし、ストレージがeMMCなので頻繁な書き込みもできないから、普段はメモリストレージ（/tmp）に置いておき、定期的に永続化のためにeMMCに吐き出すというのをやろうとしている。

そしてeMMCに端に吐き出すのもパフォーマンスと寿命の影響があるのでファイルシステムレベルでの対策をしてやろうみたいなことを考えていたが、尻切れとんぼのままなので、何とかしていきたいところだ。

フレッツ光クロスとフレッツ光ネクスト隼のコスト比較をしてみたの続きのような記事。

結論から言うと、現実的は難しい。金があれば取れる。

フレッツ光クロス x OCNでの対応状況

取り敢えず私はOCNユーザーなので、まずはOCNの対応状況から調べてみることにした。

OCN IPv6インターネット接続｜光回線 | OCNお客さまサポートによると次のようにあり、使えないことが分かった。

（OCN 光 with フレッツ クロス / OCN インターネット 10ギガはPPPoE接続できません。）

またOCNサポートに問い合わせたところ、OCNインターネット10ギガはIPoEのみ対応で、方式はMAP-E、OCNバーチャルコネクトとのことだった。そしてPPPoEは使えず、方式上フルポート使えるIPv4の提供はないと言う話だった。

兵庫県下におけるフレッツ光クロスで従来型IPv4の提供があるISPについて

フレッツ光 対応プロバイダー検索｜NTT西日本公式に一覧があるが、対応しているのはIIJのみ。

IIJ IPv6 FiberAccess/F サービス タイプIPoEであればIPv4アドレスの固定割り当てが取れるそうだが、月額14,000円～ということで、到底支払える値段ではない。

IIJのフレッツ光ネクストはIPv6 IPoE、動的IPv4アドレスの場合は2,200円とのことなので、恐らくフレッツ光クロスにするとIPv4が高くなるのだと思う。

あとがき

今回の調査では、前段に外部のリバースプロキシやそれに類するものを置かず自宅サーバーを運用する場合にIPv4を切る必要が出てくることが判明した。

前回の調査ではフレッツ光クロスにすると年3万円コスト増になることが分かっているため、これと合わせるとクロスに移行する場合、年3万の負担増とIPv4でのサーバーサービスを終了しないとならないことが分かった。

中々悩ましい結果だが、回線が逼迫しているわけではないので、OpenWrtのメトリクスなどをもっとちゃんととって、必要が出たあたりで移行できたらいいなとは思う。今でも偶に不審な速度になることはあるので、それの裏が取れたら移行してもいいだろうとは思った。

最近自鯖を別環境に移行するかどうかについて少し考えている。

現在はUbuntuで運用しており、記憶が確かならUbuntu 16.04 LTSから24.04 LTSまで使ってきているが、幾つかの問題を感じている。別にクリティカルでも何でもないので、やる必要性も薄い。

移行方法についてもやや難しく、UbuntuはNVMe SSD上で動いているため、本来なら別にNVMe SSDを買ってきてそこに試験的に移行先を作り、移行が環境した時点でUbuntuのNVMe SSDと物理的にすり替えたいところだが、SSDが高騰している関係でこの手が使えず、やるとしたら空いているSATA SSDに環境を入れて、運用が軌道に乗りそうならUbuntuを消し飛ばすしかなくなる。つまり戻せないか、戻す場合はUbuntuの入っているNVMe SSDをddでどっかにバックアップしてやる必要がある。凄いめんどい。

ひとまず、以下に移行したくなった好ましくない理由と、移行先について書いていく。

• Ubuntuの好ましくないところ
  • Ubuntuの商業主義が気に食わない
  • Snapが気に食わない
  • 動作が不安定
  • 26でのinit.d切り捨て発表
• Ubuntuの好ましいところ
  • 広く普及しておりノウハウが豊富
  • メジャーアップデートが容易
  • 特に何もしなくても大抵のハードウェアが動く
• 現在検討している移行先
  • Debian
    • 得られそうな利点
    • 懸念点
      • 通信速度が異常に遅かった
      • 移行しても旨味があまりなさそう
  • Proxmox
    • 懸念点
      • スペック的に運用できるか怪しい
      • 運用がだるそう
      • 監視がだるそう
• 通信速度の比較
  • Ubuntu 24.04.4 LTS
  • Debian 13.5.0のLive installer上での計測
  • Proxmox VE 9.2-1
• あとがき

Ubuntuの好ましくないところ

ここに書いていることはほとんど運用面では関係ない吝嗇である。端的に言えばCanonicalの姿勢が嫌いなのである。

Ubuntuの商業主義が気に食わない

自鯖はLinuxのDesktop環境の検証も兼ねているのでUbuntu Desktopを導入しているが、何かあるとCanoninalの製品に誘導されたり、過去にはMSアカウントとの連携をお勧めしてくる画面とも出会った記憶がある。こういうところがどうも好きになれない。

私はCanonicalに金を払う気がないし、LinuxをMSアカウントや、その他何かしらのアカウントと連携させたいとも思っていない。スタンドアロンこそが正義だ。

いやまぁ、Edgeのアカウントは連携するけどさ。

Snapが気に食わない

Snapに対する私の理解としてはSnapdというデーモンの上で動くアプリケーションという感じだ。

コンテナ化されたアプリケーションがDocker見たいなやつの上で動いている。なんかリソース食いそうだしキモイ。ネイティブアプリケーションはバイナリでそのまま動いてほしい。

噂ではFirefoxはaptでインストールしてもSnapdの上で動くらしい。これはWikipediaにも載ってるほど有名な話だ。何故snapdを使ってないのにそうなるのか？キモすぎる。

私は仮想化に対しては余り良いイメージがない。何故なら仮想環境分のオーバーヘッドを含み、無駄にストレージやメモリを食うこと、ホスト環境とゲスト環境の差異により問題が発生した時の特定が困難なことがある。

明示的に触れるDockerやVMならまだしもSnapdは一般向けで普通カスタマイズしない気もするし、そもそもカスタマイズが必要になるとしたらバカバカしい。なんでFirefox動かすのにそんな設定しないといけないのか？

動作が不安定

インストール直後にapt upgradeを叩くとリポジトリが死んでることがある。これは非常に嫌だ。

なんで公式でキッティングされてるリポジトリが死んでるのか？本当に営利企業がやってるのか？と思う。

他にもノートPCに入れてると蓋を閉じて開きなおしたときにキーボード入力が効かなくなり、一切何も操作できなくなることもあった。これは大分困る。

基本的にUbuntuのDesktop環境は不安定で、よくフリーズやクラッシュすると思う。それでもUbuntu 8.04 LTS辺りのころよりは安定したとは思うが…。

26でのinit.d切り捨て発表

init.dを捨てろという話なのだが、移行がだるい。

Ubuntuの好ましいところ

一方で、Ubuntuにもいいところはある。

広く普及しておりノウハウが豊富

人気のディストリのため、情報が多いのは強みかもしれない。

パッケージリポジトリも多く、基本的にUbuntu対応は多いと思う。

メジャーアップデートが容易

コマンド一個叩けばアップデートできるのは便利だ。設定の移行も手伝ってくれる。

特に何もしなくても大抵のハードウェアが動く

5種類くらいのデバイスに突っ込んだり、NICを増設したり、色々してきたが、今のところドライバを入れるとか何か対応したことはない。楽である。

現在検討している移行先

取り敢えずそんなこんなで移行先を探すことにした。

Debian

人生で最も最初に触ったディストリ。保守的で質実剛健という話を聞くやつ。

得られそうな利点

• Canonicalの商業主義から解放される
• Ubuntuより安定している可能性がある
  • Debianは徹底的なテストを経てリリースされているそうなので

懸念点

通信速度が異常に遅かった

懸念点としては何故か通信速度が異常に遅かった点だ。Live installerでiperf3で計測したところ、なんか異常に遅かった。これでは使い物にならない。原因は調べていないがNICは10000Mbpsでリンクアップしていたので、NICより手前で何かが起きていた可能性がある。

以下はDebian 13.5.0のLive installer上で計測した値だ。

Windows -> Debian

Debian -> Windows

移行しても旨味があまりなさそう

手間がかかるだけでCanonicalの開放以外のメリットがなさそう。

移行の手間としても全ての手順をマニュアルに書き出すかAnsibleのような構成管理ツールでやる必要があり、非常に面倒そうである。

Proxmox

仮想環境をたくさん作ってその中でアプリケーションを運用するやつ。コンテナ単位でのバックアップも取れるなど便利そうだ。

この環境に移行する場合、移行が楽というのが最大のメリットだ。一度適当な環境に仮構築しモジュールごとに移行し、移行完了したらLXCのバックアップを取り、Ubuntu環境を潰し、Proxmoxに入れ替え、バックアップを復旧して移行すればリスクも手間も最低限で済む。

またDebianで発生したNICの極端な通信速度劣化についてもProxmoxでは確認できなかった。但しUbuntuよりは遅く見えた。

懸念点

スペック的に運用できるか怪しい

例えばコンテナ単位でのリソース管理はその一つだ。例えばコンテナごとにCPUやメモリ、ストレージを割り当てるとすると、特定のコンテナが跳ねたときにリミットにかかって動作が劣化するが、ネイティブで動かしていればCPUやメモリ、ストレージは共有なので、なんかいい感じにしてくれる。限界突破しない限りOOMは起きないし、私のサーバースペックであれば普通起きない。

しかしコンテナ化して1コンテナCPU2コア、メモリ2GBとかしていればしょぼいVPSみたいになって動作が劣化しそうだし、そんな立派なスペックでもなく、現状CPU6コアのメモリ32GBなので、この割り当てだとすぐに枯渇するのは自明である。ブレードサーバーを持ったホームラボ、k8sを使った運用のようにクラスタ化された環境なら、これはうまくいきそうだが、しょっぱいスペックのマシン一台で成り立つかどうかは怪しい。

Opus 4.8は成り立つというが、この分野ではLLMの言うことを真に受けたくはない。そもそもLLMの出力なんか何言ってるかわからないけど動くからいいか！で採用するものでしかないと思っている。

運用がだるそう

例えば10個くらいLXCを上げているとして、コンテナのイメージをアップデートしますとかなると全部上げていかないといけないだろうから、これは面倒そうだ。

他にもLXC1とLXC2, LXC4に対して作業する場合、それぞれのLXCにSSHDと鍵を入れる必要があり、無駄なオーバーヘッドが出る。つまりLXCを増やし、そこの中に入る場合は台数分のSSHDが多重起動し、その数分の鍵が必要だ。まぁこれについては最悪一個にしてもいいが…。切り替えについてもnginxでリバプロしてハブを作れば上手くいくかもしれないが、そもそもそれが出来るかよくわかっていない。軽くググった感じはできるらしいが、そもそもスイッチする時どうなるのか見当もつかない。/lxc1/path/toみたいな形式になるのだろうか？

そう考えるだけで運用がだるそうである。

pct setを使えばうまくいく可能性が示唆されているが、どうやらこの方法は前述のように根本にパスを追加して、そこから分けていく考えのようだ。ユーザーやグループとかどうなるんだこれ…？Proxmox側でID揃えてくれるのかな？

あとホストのアップデートもだるそうな気がしている。

監視がだるそう

動作パフォーマンスを取ろうにもホストとゲストのどっちのCPUやメモリの使用率を取るかは悩みである。ホストには空きがあるが、ゲストには空きがなければ広げた方がいいかもしれないし、この辺りについては考えがまとまっていない。

通信速度の比較

Ubuntu 24.04.4 LTS

Windows -> Ubuntu

Ubuntu -> Windows

Debian 13.5.0のLive installer上での計測

以下の計測値は全てクライアント側で取得したもの。Windows側にCwndが出ているので表が逆かもしれない（Proxmoxではクライアント側にCwndが出ていたため）

Windows -> Debian

Debian -> Windows

Proxmox VE 9.2-1

以下の計測値は全てWindows上で取得したもので、Proxmox->Windows側はProxmox側のログの値ではない（転記が面倒だったためWindows側の値を取っている）

Windows -> Proxmox

Proxmox -> Windows

Proxmox側（クライアント）にはCwndが出ていたが、Windows側（サーバー）の値を取っているため、その情報が欠落している。

あとがき

Proxmoxで運用の支障がなければ環境分離の観点から移行できるとよさそうだが、メンテナンスのだるさを考えた時にどうかというのでぐるぐるしている。

かといって今のUbuntuを拡張すればするほど移行が手間になってくるので、悩ましい。しかし単一ホストで全部運用するのは間違いなく楽だしなぁ…。

取り敢えずDebianに移行する旨味は余りなさそうだし、これはしなくていいかと思った。

Proxmoxはやってみないとわからない部分もあるのでUbuntu環境のバックアップを入念に取ったうえでやるかもしれないが、問題はUbuntuをバックアップするストレージをどうするか…。

そもそも現時点でやる意義も怪しいので、今はやらない方に倒し、必要が出たときにやるのも一つではある。やりたくなった時にはそれはもう地獄が待っているかもしれないが、それ以前に私はやりたいことが無数にあるのだ。

今回は検証ができたという意味では一つ成果だと思うし、一旦ここで留めておこう。