自宅サーバー on 或る阿呆の記

セルフホストしたアプリをマシン移行する汎用的な仕組みについて考える

Mon, 31 Aug 2026 00:00:00 +0900

現在VPS上で、仮想通貨の自作トレードアプリを稼働しています。これは元々自宅サーバでやっていたのですけれど、引越しのときに数日から下手すると10日以上のダウンが見込まれたので、その間に相場の急変があったらたまらないということで、VPSに移行しました。

アプリケーションを動作させるマシンを移行したい

で、ようやく環境も落ち着いてきたので、いつまでもグローバル空間に置く必要はないし、自宅サーバに戻そうと考えています。もちろん手順を踏めばすぐできるんですけれど、ここで、少し汎用的に考えられないか、と思いました。セルフホスト勢にとってマシン移行は常に生じる汎用的な悩みです。

実際、このサイトはWordPressをセルフホストしているのですが、VPS,ConoHaの大規模障害（永遠にこする）や引越し前後において頻繁に引越しをしています。それはやはり面倒くささがあったわけです。

個人的には、マシンの移行はもっと気軽にやりたい、という思いがあります。それはもしもの役にも立つでしょう。何をやるべきで、何をやらないのか、自動化できる部分はなにか、自動しない部分はなにか、そういうことを汎用的に考えたい、と思いました。

中継地点を介した移行

考えたところ、基本的には以下のような中継地点を挟むものになると思います。

graph LR
mA(移行元)
mB(移行先)
st(中継地点)
repo(リポジトリ)
mA -->|push| st
st -.->|pull| mB
repo -.->|pull| mB

この絵がすべてです。

なんでダイレクトに送らないのかと言うと、移行元から移行先にダイレクトにpushできる権限があるとは限らない、からです。これは完全に自宅サーバしか使わない！というならダイレクトでいいかもしれませんが、実際には自宅が使えなくなることはあります（今回の場合）し、アプリケーションによっては自宅サーバはやめたほうがよいものもあります。

なので、移行元からpushできて、移行先がpullできる、そういう中継地点を用意するのが汎用的です。この中継地点の役割は、アクセス制御と一時的なストレージ、ただそれだけです。グローバルなアクセスが必要ならS3のようなクラウドサービスでもいいですし、VPSでもいいでしょう。移行元も移行先も同一ネットワークなら、わざわざ外に出す必要はなく、両者がSSHで通信できるサーバならなんでもいい。

具体的な作業自体は、アプリケーションごとに個別で判断します。この切り分けによって、搬出と搬入のタイミングをずらせるとか、データの整理が明確になるといった副次的な効能もあります。

ここで重要なことは、何を引越して何を引っ越さないのかを明確に切り分けることです。具体的には、以下の3つに分かれると思います。

リポジトリから引き継ぐ
- ソースコードや設定ファイルのテンプレートなど
ファイルの移行で引き継ぐ
- エクスポートしたファイルやデータストアやアプリケーションログなど
引き継がない
- OS/インフラの差分に基づく設定ファイルなど

それぞれ何が対象となるかはアプリケーションごとに変わるでしょう。すべてのパターンを考えて統一的にやろうとしないことです。また、引き継げない部分がある以上全自動の夢も捨てるのが筋です。変に自動的に翻訳するみたいなことするのはトラブルの元です。セルフホストでそこまでする必要があることは皆無ですし、もしやる場合は差分が出なくなるように環境から選定すべきでしょうね。

そのうえで手順は以下のように言えるでしょう。

移行元と移行先で、リポジトリから引き継ぐものをアップデート
移行元をstopして、中継地点に搬出
移行先に、中継地点から搬入
データのインポート、差分の編集
移行先で動作開始

自前で開発したものか、あるいは他人が開発したものを使わせてもらっているか、色々あると思いますが、この手順に集約できるかと思われます。

この方法は基本的にダウンタイムが生じます。工夫次第で発生させないのも可能かと思いますが、セルフホストでそこまで頑張る意味は薄いんじゃないでしょうか。

とはいえダウンタイムは短いほうがよいので、短くするなら差分の編集は搬出前にやると良いのですけれど、個人的には搬入後に揃ってからのほうがいいかと思います。搬入のどさくさで差分が上書きされるリスクや、また何かしら動かさないと編集できないとかもありえるので…。

データのインポートはファイルシステムレベルなのか、アプリケーションレベルで実行したほうがいいのか、これもアプリケーションによるでしょうねぇ…。まぁ、都度判断ですね。

まとめ

ここまでの流れをやや詳細に図示すると以下になります。

flowchart TB
subgraph Repo["コード管理"]
Code["ソースコード / 設定テンプレート"]
end
subgraph Relay["中継地点"]
ExportData["エクスポートデータ / DBダンプ / アプリログ"]
end
subgraph Source["移行元"]
SrcApp["アプリ停止"]
SrcData["データ抽出・ダンプ"]
SrcEnv["【破棄】OS・インフラ固有設定"]
end
subgraph Target["移行先（自宅サーバなど）"]
TgtEnv["【新規作成】OS・インフラ固有設定の編集"]
TgtApp["アプリ起動・動作検証"]
TgtData["データインポート"]
end
%% コードの流れ
Code -->|Pull| Source
Code -->|Pull| Target
%% データと状態の流れ
SrcApp --> SrcData
SrcData -->|Push / アップロード| Relay
Relay -->|Pull / ダウンロード| TgtData
TgtData --> TgtEnv
TgtEnv --> TgtApp
%% スタイル
classDef storage fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
classDef nodeBox fill:#f5f5f5,stroke:#616161,stroke-width:1px;
class Repo,Relay storage;
class Source,Target nodeBox;

やることは、事前準備として「リポジトリからpullするもの、中継地点で飛ばすもの、直接編集するもの」の切り分け。そのうえで5つの手順の具体的な操作の当てはめ。

整理してみると、当たり前といえば当たり前なんですが。あらかじめ分類したものを適合させるだけだと思ったほうが、脳の負荷が多少下がるので…。

とりあえず、トレードアプリから移行するかー。手順を抽象化したところで具体化するのは結局めんどくさいのであった。というより、そういう面倒くささを残したところが肝なのですが…。

<関連記事>

あわせて読みたい

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

/selfhost-webapps-down/

あわせて読みたい

セルフホストのすゝめ

/selfhosted-susume/

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

Mon, 10 Aug 2026 00:00:59 +0900

私的メモ。そりゃそうだ集。症状は様々なので症状から逆引きというより流し読みして心当たりあるやつを思い出す集。構成が複雑になるほど、「端末Aでは症状A’になるが端末Bでは症状B’になる」など発生する。がんばれ。

環境

Linuxが基本。メインはLinux Mint Xfce。

一般

localhost以外からのアクセスを許可してない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

アプリ側でそういう設定になってるので、変更できるか否かという感じ。

ファイアウォールで許可していない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

間抜けなことにこれは本当によくある。

ファイアウォールの設定確認する。ufwの場合のコマンド。

sudo ufw status

空いてなかったら追加。

sudo ufw allow <ポート番号>

セキュリティグループ的なので許可していない

AWSをはじめとするクラウドとかVPSで、そもそもネットワークインタフェースに到達していないケース。許可しよう。

ポートの競合

症状: なんかうまくいったりいかなかったりする

複数のアプリケーション、なんなら同一のアプリケーションでポートが競合している。調べるときのコマンドはこれ。

sudo lsof -i :8080

AdGuardHome(AGH)とかLAN内DNSを使っている場合

LAN内DNSに向いてない

症状: LAN内ドメインだけ名前解決できない

そもそも論としてLAN内DNSに向いてない。ルータでDNSをLAN内のやつ指定するか、あるいは各クライアントでそれぞれ設定するか。

AGH側でDNS書き換え設定を忘れている

症状: LAN内ドメインだけ名前解決できない

稀によくある。設定しよう。

サブドメインの法則決めてワイルドカード使うのが楽ではある（ワイルドカードを使えばサブドメインの証明書発行を知られないというのもある。まぁサブドメイン知られたところで別にLAN内限定公開なら問題ないかもしれないが気持ち悪いので…）。

IPv6が優先されている

症状: 名前解決できない。端末によってはできることもある。

AdGuardHomeで頑張ってIPv6対応するか、ルータで切れるならIPv6切るか、あるいはクライアントでIPv6を切るか。クライアントで切る場合は対応はOSによって異なる。Macは基本的にDNSサーバをIPv4で設定すればいけると思うのだが、Windows/Linuxは明示的にやる必要あり。Androidはアプリ使う必要がある。自分はRethinkDNSを使っている。iOSは持ってないから知らない。

このとおり、OSによって状況が異なるため「端末AではいけるけどBではいけない」ということが起きうる。さらに同じOSでも設定してたりしてなかったりすると、それでも異なる症状になったりする。めんどくさい。

あわせて読みたい

LAN内DNSでIPv6は使わないのでWindowsでIPv6を無効化する

/landnsipv6windowsipv6/

/android-lan-agh-dns/

Caddyを使っている時

AGH + Caddyまで持っていくとだいぶ捗るけど構築は面倒くさい。DNS-01チャレンジを利用しているとエラーパターンが増える。

Caddyfileの設定を忘れている、間違えている

稀によくある。設定しよう。ドメインの前にスペース空いてないとかよくある examp.com{。caddy validateとcaddy fmt --overwriteしよう。Docker版ならサービス名caddyの時

docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

フォーマットは

docker compose exec caddy caddy fmt --overwrite /etc/caddy/Caddyfile

Caddyfileの設定を読み込むのを忘れている

ファイル書き換えただけで。リロードしよう。

caddy reload

Docker版

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

証明書の発行に失敗している

症状: 証明書エラー

自己証明書以外のとき。ログを見て判断。利用しているレジストラに対応したCaddyを使っているか確認。あとAPIの権限を確認。

証明書を発行していない

症状: 証明書エラー

Docker版で docker compose up -dリロード代わりにした場合、証明書が発行されないまま。docker compose downしてから起動し直す。

(Docker利用時) バインドマウントを忘れている

症状: 404エラーがでる

Docker版Caddyを使っている時。ホストマシンのディレクトリをそのまんまfile_serverとか使ってホスティングする場合、バインドマウントしないと当然見えない。

Tailscaleを使っている場合

最近使ってないけど、使っていたときはややこしかった。特にAGH、Caddyと併用するとカオス。

MagicDNSがうまく機能しない

Tailscaleから付与されるIPアドレスを直打ちするほうが無難。

AGHと一緒に使う

TailscaleのDNSをAGHに向けること。

個人的にはこの構成はそもそも管理がとても複雑なのでやめたほうがいいように思う。

<参考>

/splitdns/

Cloudflare Tunnelとか使っている場合

トンネルが落ちている、接続されていない、間違えている

当たり前の見落としをよくする。

トンネルが競合している

症状: 繋がったり繋がらなかったりする

Docker版とネイティブ版両方動かしていたりとか、よくわからないことをすると起きる。

LAN内DNSでIPv6は使わないのでWindowsでIPv6を無効化する

Thu, 30 Jul 2026 00:00:00 +0900

AdGuard Home + Caddyで、LAN内専用のドメインがある。Windowsクライアントでアクセスしようとするが、IPv6で通信してしまったたどり着かない。プロバイダ（楽天ひかり）の関係でルータ側のIPv6は必須。なので、クライアントマシンのほうでIPv6を切る。切ってもインターネット接続はルータ側でIPv6になるので良い。

環境

楽天ひかり（IPv6必須）
ルータ: TP-Link AX5400
- DS-Lite
AGHのあるPC: Linux Mint Xfce 22.3
- AdGuard Home
- Caddy
クライアント
- Windows 11 Home
- 無線LAN

手順

手順 by AI。

Win + R キーを押し、ncpa.cpl と入力してEnter（「ネットワーク接続」が開きます）。
使用しているネットワークアダプター（Wi-Fi またはイーサネット）を右クリックして「プロパティ」を開きます。
リストの中にある 「インターネットプロトコルバージョン 6 (TCP/IPv6)」のチェックを外します。
「OK」を押して画面を閉じます。

ついでに、ルータのほうでDNSをAGHに向けているはずなのだが、まだ名前解決できず。

仕方ないのでTCP/IPv4のプロパティもいじって、DNSをAGHのアドレスに固定した。

これで名前解決できるはず。

以上。

<関連記事>

/linux-mint-xfce-adguard-home-tailscale/

/splitdns/

Trilium Notes (Docker) のマシンを移行する

Sun, 07 Jun 2026 21:21:36 +0900

現在運用しているTrilium Notesについて、Intel Mac mini 2018 + Docker Desktop から Linux Mint Xfce 22.3のサーバマシンに移行する。

環境

Trilium Notesのlatest
移行元
- Intel Mac mini 2018
  - macOS Sonoma 14.6.1
  - Docker Desktop for mac v4.76.0
移行先
- ThinkPad L390
- Linux Mint Xfce 22.3
  - Docker 29.5.2

手順

移行元のマシンで停止する。

docker compose down

docker-compose.ymlでデータディレクトリを確認する。TRILIUM_DATA_DIRがどうなっているか見る。

# Running `docker-compose up` will create/use the "trilium-data" directory in the user home
# Run `TRILIUM_DATA_DIR=/path/of/your/choice docker-compose up` to set a different directory
# To run in the background, use `docker-compose up -d`
services:
 trilium:
 # Optionally, replace `latest` with a version tag like `v0.90.3`
 # Using `latest` may cause unintended updates to the container
 image: triliumnext/trilium:latest
 # Restart the container unless it was stopped by the user
 restart: unless-stopped
 environment:
 - TRILIUM_DATA_DIR=/home/node/trilium-data
 - TZ=Asia/Tokyo
 ports:
 # By default, Trilium will be available at http://localhost:8080
 # It will also be accessible at http://<host-ip>:8080
 # You might want to limit this with something like Docker Networks, reverse proxies, or firewall rules,
 # however be aware that using UFW is known to not work with default Docker installations, see:
 # https://docs.docker.com/engine/network/packet-filtering-firewalls/#docker-and-ufw
 - '8080:8080'
 volumes:
 # Unless TRILIUM_DATA_DIR is set, the data will be stored in the "trilium-data" directory in the home directory.
 # This can also be changed with by replacing the line below with `- /path/of/your/choice:/home/node/trilium-data
 - ${TRILIUM_DATA_DIR:-~/trilium-data}:/home/node/trilium-data
 # - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro

ここでは~/trilium-dataとなっている。ついでにMacで/etc/timezoneがなかったのでコメントアウトされているね。

とりあえずアーカイブ化しよう。

tar -czvf trilium-data-backup.tar.gz ~/trilium-data

こいつを新しいマシンに転送してやる。

scp trilium-data-backup.tar.gz ユーザ@IPアドレス:移行先のパス

新しいマシンで、これを保存先ディレクトリ上に展開する。今回はtrilium-dataにしている。

tar -xzvf trilium-data-backup.tar.gz

保存先ディレクトリに入って、もしデータベースの一時ファイルが存在したら削除する。

rm -f document.db-shm document.db-wal

準備ができたらコンテナの起動。とりあえずフロントで。

docker compose up

エラーなく起動したら、http://IPアドレス:ポートにアクセスする。以前使っていたパスワードでログインできることを確認する。

問題なければOK。Ctrl-cで停止して、改めてバックグラウンドで起動する。

docker compose up -d

これでOK。しばらく動かして、安定していることを確認したら元のコンテナは削除してよい。

<関連記事>

/evernote-notion-trilium-notes/

Dell Latitude 5290は中古PCサーバの母艦としていいかもしれないね、一方クライアントなら意外にも…

Tue, 26 May 2026 00:00:00 +0900

うちには40台くらいジャンクPCがある。特に2018年前後を集めており、定番なのはLenovo ThinkPadとDel Latitudeあたりだ。このへんはまぁ安いといってもジャンクの中では高いのかもしれないのだが、既に送料で底打ちがあるため、バランスを取るならこのへんかなぁ、とは思う。ジャンクでバランスもなにもないが…。

結局Linuxに似合う中古PCはなんなんだい

個人的には、漁っているとFUJITSUのLIFEBOOKやPANASONICのLet’s Noteの古いやつなんかが、むしろ良いのではないか？という気がしている。流通量もそこそこあるし。あのへんはLenovoやDellとは異なる方向にブランドなので、必ずしも安くなっていない…なんなら骨董品レベルのものがやけに高く売られていることもある。あの時代のパーツがほしい人向けなんだろうか…しかしコンシューマのPCでそんなことあるかなぁ。

まぁなんでもいいのだけれど、無難にいくならThinkPadかLatitude、というのはそれはそう、という感じだ。ただ2018年より、ThinkPadの上位モデルであるX280以降はメモリソルダリングという悪に手を染めてしまっているため、それより一つ落ちるはずのL390のほうが、メモリの拡張性高い分使いやすいという逆転現象が起きている。筐体の無骨さもサーバ用途ならばむしろ悪くない。まぁ問題は、L390はThinkPadシリーズの中だとそんなに量が出回っていないということかな…。あと、LANポートがないのもいたいね。

そこでいくと、Dell Latitude 5290は攻守ともに強い感じだ。メモリも換えられるし。ま、ちょっと重いかな。Dellらしい無骨さではある。しかし前述したようにサーバで無骨さは褒め言葉よ。ただ同じ型番で2-in-1タイプもあるらしいが、そちらはオンボードという罠仕様になっている。まぁジャンク漁りをする人の中でも2-in-1を狙うのはさらに数寄者だろうから好きでやっているんだろうが…。

なので、僕はThinkPad L390を母艦にしているけれども、Dell Latitude 5290も実は候補に上がっていた。しかし結局L390になり、Latitude 5290は仕事で使うPCとして供養する流れだ。Core i5-8250Uと8GBという必要十分なスペックに、LANポートがあるのが決めてになったかな。LANポートがあると、それ経由でシングルボードな子機とサクッと接続できるのがよい。SSDは家にあった128GB SATA SSDだがね。m.2 2280フォームファクタのSATAがあるなんて、ジャンク漁るまで知らなかったよ…。

まぁThinkPadだのDellだのも当然のように裏蓋ネジなかったり画面TNでもやってたしCMOS切れてたり通信たまに切れたりバッテリー死んでたりするという点では変わらない。そこは安くどうにかできるならなんとかするし、できるけど高く付くならそういう使い方は諦めるという割り切りが必要だ。

クライアントならちょっと冒険してみて…

さて少し目先を変えて、そんなサーバとかじゃなくて、普通に普段遣いでやりたいんだけど、という向きでは、僕の見た感じだと感触はかなり異なる。

ここで一番重要なのは液晶で、画面は生きててIPSフルHDとバッテリーとキーボードタッチパッドが生きていること、が条件となる。あとためらわないレベルで外観が保たえれていることとか（時々戦争に持っていったの？みたいな可愛そうな筐体がある…）。ここがクリアしていればあとはまぁなんとか。

まぁあるにはあるんだけど、普通に1万超えてくるよねこんなの。高いよ。ジャンクでも2万くらいはある。まともな中古店なら2万後半から3万しててもおかしくない。これからもっと高くなるかもな。

…なんですけど、PANASONICとかLIFEBOOKで捨て値になっているように、バッテリーが死にかけだけどもまだ残っていて、驚くべきことにIPS FHD（ときどきTN FHDがあるので気をつける）、みたいなのが、3000円とか5000円とかで手に入ったりすることもある（送料込み）。もちろんCPUは期待するな。Core i5第4世代でも気にするな。でもバッテリー生きてるならなんでもいいじゃない！たとえ残り39%とかだったとしても！

このへんのはね、まぁさすがに常用はつらいと思うけど、サーバよりも持ち運びたいタイプの特定用途のクライアントPCとして活躍の場があると思ったな。筐体のめっちゃ軽いからね。当時は最先端だったんだろう。

PANASONICの昔のやつとかでもボタン一つでWi-fi切り替えギミックとかほしい人はほしそうなやつあるしね。まだそこまでちゃんといじってなけど、僕はけっこういいと思ったな。

どんどん検証していく

40台くらいジャンク揃えたけど「完璧だ！」みたいなのマジでなくて、「こいつはここがなぁ…」のオンパレードです。今はThinkPad L390を使っていて、これは比較的の文句のないPC…に見せかけて、クリックパッド死んでたりするからねｗあとなんか全体的にもやってる。まぁあんまりメインディスプレイがっつり見ないけどね。

とりあえず今日現時点においては、このサイトはThinkPad L390 Core i5-8265U, 32GB RAMで動いております。RAMだけすごい。普段は3-6GBの利用料なので完全に無駄。でもこれからメインサーバの機能をうつしていったら重くなるかも。

最初の間は消費電力も10Wくらいだったけど、メディア系のサーバを入れ始めたから、いまは15Wくらいにあがってそうだなー…。Jellyfinとかは入れる予定ないんだけど。Immichは入れようかなぁ。家族にAppleやGoogleにお布施しているのがいたら救ってもいいんだが…。

この子がいつでも最後のちからを振り絞れるように、後ろに何台ものジャンクを控えさせておかないとな。そういう態勢を整えて、知見を共有していきたい。

まぁなんにしても、あんまり失敗したくなくて、でもLinuxほしいなぁって雑に思う人はDell Latitude 5290はいいと思うよ（2-in1は避けつつ）。ジャンクなら別途パーツ含めて1万、保証付きの中古ショップなら…25000くらいかなぁ。ジャンク市場もこれからどうなることやら…

Linux Mint Xfce 22.3 + LyrionMusicServer + Squeezelite で音楽生活

Mon, 25 May 2026 00:00:00 +0900

メインサーバになりつつあるLinuxマシンに、チューナレステレビをHDMIでつなぎ、TVに光オーディオ出力でアンプに繋がっている。たいへんややこしい状況だが、どうせなら音楽はこのアンプでききたいものである。

ということで、音楽サーバ構築編。

環境

とてもややこしいけれども以下のような感じだ。

graph TD
subgraph PCA ["PC A (操作端末 / リモコン)"]
Browser["Webブラウザ / App(Material Skin UI)"]
end
subgraph PCB ["PC B (Linux Mint / サーバー兼再生機)"]
direction TB
LMS["Lyrion Music Server(楽曲管理・配信)"]
subgraph AudioOutput ["音声出力プロセス"]
Squeezelite["Squeezelite(再生用クライアント)"]
PipeWire["PipeWire / ALSA(OS音声制御)"]
end
Storage[("音楽ファイル群(HDD/SSD)")]
end
subgraph AudioPath ["中継・出力"]
TV["Mi TV(音声ハブ)"]
Speaker["外部スピーカー"]
end
%% 接続とデータの流れ
Browser -- "① 選曲・操作命令 (Port 9000)" --> LMS
LMS -- "② 音楽ストリーム送信 (Port 3483 / localhost)" --> Squeezelite
Squeezelite -- "③ 音声データ引き渡し (default出力)" --> PipeWire
Storage -. "スキャン (パーミッション確認済)" .-> LMS
%% 物理接続
PipeWire == "④ HDMI出力 (DEV=3)" ==> TV
TV == "⑤ 光デジタル出力" ==> Speaker
%% スタイル設定
style PCB fill:#f5f6f8,stroke:#4f5b66,stroke-width:2px
style LMS fill:#d1e7dd,stroke:#0f5132
style Squeezelite fill:#fff3cd,stroke:#856404
style Browser fill:#cfe2ff,stroke:#084298
style PipeWire fill:#e2d9f3,stroke:#4b2c7e
style TV fill:#eeeeee,stroke:#666

HW/SWは以下。

ThinkPad L390
- 32GB RAM
- Linux Mint Xfce 22.3
- squeezelite v1.9.9-1449
- Lyrion Music Player v9.1.0

インストールと設定

Lyrion Music Server

Getting Started with LMS - Lyrion Music Serverより、ダウンロードリンクを取得。記事を書いた時のリンクだとこれ。

wget "https://downloads.lms-community.org/LyrionMusicServer_v9.1.0/lyrionmusicserver_9.1.0_amd64.deb"
sudo apt install ./lyrionmusicserver_9.1.0_amd64

ステータスを確認する。

sudo systemctl status lyrionmusicserver.service

enabledでactive(running)になっていることを確認する。

ポートを空ける。

sudo ufw allow 9000/tcp

そうしたら http://IPアドレス:9000にGo。右下のNextボタンで、音楽ファイルの場所と、プレイリストを保存する場所を指定することになる。

ここで、ディレクトリのパーミッションは755でないとLMSが読めない。基本的にホームサーバならディレクトリは755でよいはず。外付けディスクとかでパーミッションまとめて変える必要があるときはfindで一気にやってしまう。たとえば/mnt/hddのときは以下の感じ。

find /mnt/hdd -type d -exec chmod 755 {} +

ホームディレクトリは~/.sshとかあるんでまとめてやるとか雑なことはしない。

さらに音楽ファイルの権限も600とかだと読めない。音楽ファイルのあるディレクトリに移動して、パーミッションを変更する。

find . -type f -exec chmod 644 {} +

再スキャンするときは、Web画面で歯車よりServerから再スキャン可能。

とにかく音楽フォルダとプレイリストフォルダのパーミッションは整えてやる必要がある。ちなみにうちの場合は音楽ファイルは外付けのハードディスクドライブで、プレイリストフォルダは内蔵SSDのホームフォルダ内にしている。

Squeezelite

まずポート空けておく。

sudo ufw allow 3483

以下でインストール。

sudo apt install squeezelite

入れたら出力を確認する。

squeezelite -l

なんかいっぱい出てくる。ここでハードウェアを指定して /etc/default/squeezeliteを書き換えていく、ということになっているのだが…。

ただねぇ…僕はここから相当転がされた結果、一つの結果にたどり着いたが、これは一般的ではない、とあらかじめ申し添えておく。

まずapt installしたら勝手にsystemctlで動いているsqueezeliteを殺す。

sudo systemctl stop squeezelite.service

有効化はされてないのでdisableする必要はないが、もしenableしてしまったらdisableもしておく。

そのうえで、~/.config/autostartにスタートアップスクリプトを書いていく。ディレクトリがなかったら最初につくる。

mkdir -p ~/.config/autostart

そしたら設定ファイルを書く。

cat << 'EOF' > ~/.config/autostart/squeezelite-tv.desktop
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=Squeezelite-TV
Comment=Hand-launched success command with delay
Exec=bash -c "sleep 5 && squeezelite -o default -n MiTV"
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false
EOF

Execのところは適当に。-n MiTVは僕がMiTV使ってるからなので。適当にわかりやすい名前にする。

再起動して、LMSで見つかるかどうか試す。見つかればOK。

これは明らかに標準の方法ではないが、これが一番安定した。systemdはクソ。昔から思ってたけど、僕の頭が悪いんだと思っていた。今となっては自信を持って言える。僕の頭が悪かろうがなんだろうが関係なくsystemdはクソ。

systemdはクソ

疲れた。なんだかんだで半日消費した。あとは運用していきたい。

ちなみにフォルダ管理派はフォルダをブラウズするように設定できるが、そのへんの話はMacのときに書いたのでそちらを参照。

/mac-mini-2018-lyrion-music-serverlms-logitech-media-server-squeezelite/

ってかPipeWireって何？とか、基本的なところ理解できてないなぁと思った。systemdはクソ。

コンテナ構築のWordPressサイトを別マシンに移行する

Sun, 24 May 2026 00:00:00 +0900

現在常時稼働サーバがMac・Linuxと無意味に分かれている。Linuxマシンに統一してIntel Mac mini 2018には予備役となってもらうように、少しずつ機能を移行している。今回は自宅サーバのWebサイト。つまりこのサイト。

環境

Mac上で展開していたDocker + WordPressのサイトを、別マシンに移行する。前回の移行時はプラグインを使って復元したのだが、せっかくコンテナでやってるのにそれではかいがないと思い、今回はCLIで実施。

元マシン: Intel Mac mini 2018
- Docker Desktop 4.73.0
移行先マシン: Linux Mint Xfce 22.3
- Docker 29.5.0
GitHub - BretFisher/docker-vackup: Script to easily backup and restore docker volumes · GitHub

vackupコマンドの中身については以下の記事を参照。

あわせて読みたい

DockerのボリュームをCLIでバックアップ・復元する

/docker-volume-cli-backup/

手順

全体は以下。

元マシン：コンテナを停止する
元マシン：ボリュームのエクスポート
元マシン：コンテナを再開する
元マシンからコンテナにボリュームをコピー
移行先：ボリュームをリストア
移行先：コンテナを起動
移行先：localhostにアクセスして復元されていることを確認する
リバースプロキシなどで向け先を移行先に。元サイトは落とす

元マシン：ボリュームのバックアップ

コンテナは持ち運べるとして、問題は永続化ボリュームをコピーすること。ここでは、docker-compose.ymlは以下のようなものとする。変数は.envで定義しているとする。内容は、WordPressとDBそれぞれコンテナたててるよ、それぞれボリュームを指定して使うよ、というもの。

services:
 hp_wordpress:
 image: wordpress:latest
 ports:
 - "ポート番号:80"
 environment:
 WORDPRESS_DB_HOST: データベースコンテナ
 WORDPRESS_DB_USER: ${DB_USER}
 WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
 WORDPRESS_DB_NAME: ${_DB_NAME}
 volumes:
 - hp_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - db

 db:
 image: mariadb:latest
 environment:
 MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
 MYSQL_DATABASE: ${DB_NAME}
 MYSQL_USER: ${DB_USER}
 MYSQL_PASSWORD: ${DB_PASSWORD}
 volumes:
 - db_data:/var/lib/mysql
 restart: always

volumes:
 hp_wordpress_data:
 external: true
 db_data:
 external: true

volumeとして、hp_wordpress_dataとdb_dataを外部で作成したものを使うような設定になっている。

現在のボリュームを確認する。

docker volume ls

ターゲットとなるボリューム名と存在することを確認しておく。

コンテナを停止する。

docker compose stop

以下のコマンドでバックアップ。

mkdir volume-backups
vackup export WPボリューム名 volume-bakcups/WPボリューム名.tar.gz
vackup export DBボリューム名 volume-bakcups/DBボリューム名.tar.gz

ダウンタイムを小さくしたいなら、この時点で元マシンをdocker compose up -dで復帰させる。

転送する。

rsync -avz --progress volume-backups ユーザ@移行先:移行先のパス/

容量大きくて途中でdisconnectされるときは

rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" volume-backups ユーザ@移行先:移行先のパス/

移行先マシン：ボリュームのリストア

作業ディレクトリに移動し、ボリュームを復元する。

vackup import WPボリューム.tar.gz WPボリューム名
vackup import DBボリューム.tar.gz DBボリューム名

これで問題ないはずだが、なぜか自分の環境でよくわからんことになっていたので、ボリュームの中身を確認しておく。以下のように直下にされておらずvakcup-volumeがあるかもしれない。

$ docker run --rm -v ボリューム:/volume alpine ls -lh /volume
total 4K 
drwxr-xr-x 6 999 ping 4.0K May 18 02:53 vackup-volume

vackup-volumeなる親ディレクトリが出来ていて、その下にディレクトリがあるようだ。

この場合は以下のコマンドによりvackup-volume以下を展開する。

docker run --rm -v WPボリューム名:/volume alpine sh -c "mv /volume/vackup-volume/* /volume/ 2>/dev/null || true; mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true; rmdir /volume/vackup-volume"

もう一度ボリュームを確認したら直下に展開されていることがわかる。DBのほうのボリュームも同様に。

これでいけるが、なんかよくわからんことをしている。

後日実行したときは再現しなかったので、なんだかよくわからない。

起動と疎通確認

最後にもう一度docker-compose.ymlを確認し、コンテナを起動する。

docker compose up

エラーとか出ないかを確認するため、最初はフォアグラウンドで。http://localhost:ポートにアクセスし、いつもの画面が表示されることを確認する。インストール画面が出たら初期化されちゃってます。なにか間違えているので最初からやりなおし。やりなおした🥺

問題なければ正式にバックグラウンドで動かす。

docker compose up -d

移行元から移行先に向ける

準備が整ったので、DNSやらリバースプロキシやらいじって、移行元から移行先に向ける。

この時点で移行元を落としていいが、いつ落とすかは考え方による。ダウンタイムを小さくするなら移行元をしばらく残しておいてもいい。しかし、変に残しておいてナイスタイミングでコメントついてしまい、消えてしまうみたいな事故が起きる可能性もあるので、何がいいとも言えない。僕はいらなくなったら落とす。

インフラはAI無能

最初これくらいAIがすぐできるだろうと思ったけど何か色々ハマってしまって、結局手作業で心を込めてやりました。インフラ周りは固有の環境や設定が多すぎるので、汎用的な一般解を出し続けるAIは無能になりがち。

それにしてもこの手の作業をするとき、昔書いた記事を参考にすることがよくあるのだけれど、このサイト自身が対象のとき、失敗するとサイト自体が落ちてしまって閲覧することができないっていう。まぁそれを考えると、ニッチな記事でもnoteに転載していくのは保険としての意味もあるか。釈然としないけど。

今後Linuxマシンは色々なハードウェアを検証していくため、移行作業はスクリプト化してスムーズに検証できる体制を整えたい。

追記：自動化した

けっこう何度も引越ししているので、スクリプトで自動化した。

/wordpressdocker-script/

Core i5-8xxxUをLinuxサーバにしたらメモリより先にCPUが燃え尽きる

Mon, 18 May 2026 00:00:00 +0900

だからメモリ8GBでも気にしなくてｲｲﾝﾀﾞﾖ！

ざっとこんな感じさ。4コアを使い尽くしているよ。でもメモリは3GBだよ。32GB刺しているのにゴミのようだ。

まぁこれは動画をエンコードしているのでそれはそう、ではあるのだけれど、基本的に3GBくらいが普通なんだよね。一番多いときでも7GBくらい。まだ多くの機能をIntel Mac mini 2018をやっているから、それらの機能を全部うつしたら…特にImmichなど重量級なのを移したらもっと使うだろうけれど、それにしても多分CPUのほうが先に音を上げるんじゃないかな？かな？

まぁディストリビューションはLinux Mint Xfceで、最新のUbuntu使ってGNOME使ってとなればこうもいかないと思う。でもそれはOSの本懐じゃないよね。CUIとか言う前にまず軽量GUIを試すべきだ。特にホームサーバにおいて、GUIは非常に有力なのだ。これを利用しないのは非常に勿体ないと思う。

最先端GUI or CUIってーのは極端だ。リッチなクライアントかもしくはクラウドのサーバかってそういう思考になっちゃってんじゃない。でもPCってそうじゃなかったよね。もっといくらでも良い選択肢があるのだし、それを選び扱えてこそじゃなかろうか。

そんなわけで、第8世代の値下がりジャンクをLinuxサーバにしてやろうという賢いユーザはメモリについて8GBで実用上十分くらいでいいんじゃないかな。

ちなみにこんなPCでエンコードしているのは、現在制作中のデジタルコンテンツ管理アプリ、DigitalShelf（仮）の試運転です。試運転といっても自分のデータを扱っているのでゴリゴリ本番なんだけどね。また、これは標準機能ではなくて、ffmpegを使った外部プラグインという立ち位置。外部プラグインなのでソースコードは開示しなくていいって寸法よ。別に開示してもよかったんだけど、なんかもうOSSは開示したらAIでアタックされるという酷い時代になったので、もう何もできないよね。

まぁ僕もAI使ってアプリ作っているわけだが…。激動の時代だけれど、結局shは動いているという事実を大事にして明日を生きよう。