セルフホストのすゝめ on 或る阿呆の記

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

/ai-cyber-attack/

AIでソフトウェアの作成は楽になったが、結局最後は泥臭い

/aisoftware/

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

Sat, 24 Oct 2026 00:00:00 +0900

定期的にくる全裸待機イベントがPHPに襲来。

PHPに「緊急」レベルの脆弱性2件修正版を日本時間21日深夜に公開へ、事前準備を呼び掛け - ITmedia NEWS

全裸で待て！

とにかく地球がヤバい

技術的な詳細が不明なのは仕方無いですが、「とにかくやべぇからPHPユーザは全員23時全裸な！」ということで、こういうことがあると、WordPressユーザとしては限界みを感じます。特に昨今はAIのせいでサイバー攻撃が激化していることもあり、それは自動ですから、場末の当サイトも常にアタックを受けていることを思うと、対策しないわけにもいきません。

そんでまぁ、当日こられた方は珍しくサイトに赤帯出ているのを見たかもしれません。

で、23時前からしばらく落としました。

それでまぁしばらくは、X上でも様々な人が話題にしていて、少し本当にお祭りのような気分になりテンションも上がりました。

著名ITサービス相次いで緊急メンテへコドモン、シャドバ、BASE、さくらのレンタルサーバなど「PHP」脆弱性に起因か（1/2 ページ） - ITmedia NEWS

当サイトはDocker版のため、大元のPHPの更新から降ってくるまでけっこう時間がかかりました。一人ポチポチと下記コマンドでDocker版の更新はまだかなぁと確認していました。

curl -s "https://hub.docker.com/v2/repositories/library/wordpress/tags/latest" | grep -o '"last_updated":"[^"]*"'

これの結果が2026-10-21T14:00より後になったらOKなのですが、結局"last_updated":"2026-10-21T17:50:57.852281Z"を確認できたのは夜中の3時くらいだったかな。お、と思ってイメージ更新して、バージョンを確認します。

$ docker run --rm wordpress:latest php -v
PHP 8.3.36 (cli) (built: Oct 21 2026 15:57:18) (NTS)

OK、ということでサイト復活。この頃になると大方みんな対策が終わっており、Docker版を話題にしている人はほとんどおらず、なにしてるんだろうなぁという気分になっていました。

せっかく頑張ったので青帯で頑張りましたの告知を誰に向けたわけでもなくしています。複数サイトやってるので対策は複数やったのですが、このサイトでしか帯は出していません。所詮個人サイト、告知というより祭り参加表明だったので…。場末でも一応今も技術系のサイトのつもりだしね。

実際の所脅威はどれくらいだったの？

終わってみると、かねてより考えてはやめていた脱WordPress計画も現実味を帯びてきます。今回のようなことが今後もけっこうありそうだな、とまず思えました。地味にNode.jsも騒がれていましたしね（「「Node.js」にセキュリティ更新～10件の脆弱性を修正、「eMudhra」の侵害にも対応 - 窓の杜」）。

しかし実際のところ、今回の脅威（後にphp2shellとされる）が本当にどれほどの被害をもたらすものだったのかは謎です。真の影響力について実はちょっと疑っています。CVSSスコア9.2とか数字ばかり独り歩きし、対策しなければサービスにあらずみたいな空気が醸成されても、本当のところどうだったのかはわからないわけでしょう。試みがあったということ自体は既に「PHP「緊急」脆弱性悪用の試み、数百万件に CloudflareのCEOが報告 - ITmedia NEWS」のようにニュースになっていますけれど、ではそれでどうかなったのか…。

この手のものは、何か起きていた時にはもう遅いのだとか、未来の危機を予言した預言者が迫害されるとか、まぁそんな話になるわけですが、しかし今回については、PHPサイトの有名どころとしてアンサイクロペディアがノーガード戦法だったらしいので、今後このサイトがどうなるのかでわかるかもしれません。

UnNews:PHPに史上最悪級の穴、世界が予防停止する中アンサイクロペディアだけ止められる人がおらず平常運転。 - アンサイクロペディア

サイト内でもネタにされています。しかしまだやってたんですね。元気そうでなにより。

ま、だからといって事前に脅威を告知されればやらないわけにはいかないんですが…今回の脅威はOpenAIが検知したとのことでしたけれど、世界中が一斉に全裸待機するほどのものだったのかな…とは少し思います。個人的には見えている脅威はそりゃ対応すべきだと思うんですが、祭り状態になるのも何か違和があります。

今後こんな感じでAIにより新たな脆弱性発見！深刻度9.3…9.4…100だーーーー！全裸で待て！とか毎日のように言われることになったら、みんなどこまでついていくんだろう。どうせ侵入されても詫びメール一本で済ます癖に…（余計なこと）。今回総理大臣までツイートしていましたが、総理のツイートは脆弱性の報告で埋まるんでしょうか。

怪しいもんです。対応した中の人はこれが技術的に必要なことだという思いで対応されたかもしれませんが、組織の観点では、やるべきことはやりましたというポージング、免責の観点でコストを払っているように思われます。でなければ、事前対応は熱心なのに、いざ本当にインシデントが起きたら詫びメール1本で済ませようとする態度は説明がつきません…。ま、情報漏洩のエース・タイムズカーはPHPではなかったようですが（永遠に言い続ける）。

クラウドなら安心伝説

まぁそうはいっても、現実上のセキュリティリスクは確かに上がっているのでしょう。求められるセキュリティパッチの適用であるとか、対策なんかは、これから目に見えて高まっていくのかなぁ、という感じはしています。

これについて、中小まして個人が防ぎ切るのはもう無理だ、クラウドに任せよう！みたいな論調も最近はちらほら見かけるのですが、大手クラウドなら信用できるのか？と思います。実際、最近俺たちのGMOがやられました。

「お名前.com デスクトップクラウド」不正プログラム設置で全プラン停止 FX用VPS、2万6739サーバに影響か - ITmedia NEWS

これは記事だと実際どこまで基盤に侵入されたのかわからないんですが、不正にプログラム設置されてるんですよね。少なくともそこにおいては実行権限まで取られている中で、本当にGMOの言う通り情報閲覧があるかも程度の被害なのかな…僕がユーザだったらちょっと信じられないですけどね。まぁ実際被害者は滅茶苦茶可哀想ですよ、FX自動取引の基盤でしょう。つらすぎる（実感）。

……とか書いて予約投稿していたんですが、Xを見ていたら次の展開が。

https://x.com/yutoriineet/status/2113264833307267254?s=20

口座破綻させられているのあまりにも悲惨で可哀想過ぎる。ご愁傷さまです……。これマジで洒落にならない金額の被害が出ているのでは。やっぱり情報閲覧程度じゃなかったのか。攻撃されたといえば企業は被害者だが、本当の被害者は企業を信じて情報を預けたのに漏洩されたユーザで、企業はその被害を隠蔽と過小申告するモチベがあるから信じられない。報道する側も企業側の言うことをそのまんま垂れ流すだけじゃダメだし、見る側ももっと疑う必要がある。……と言い始めるとちょっと話が完全に逸れるので、本件滅茶苦茶興味深いけどここまでにしておいて…。

まぁこういう投資にかかるサービスで、クラウドを銘打ったサービスで、GMOがやられた、というのはこれは重たいんじゃないでしょうか（GMOだけど）。いや、ここでいうクラウドとはAWS/GCP/Azure/OCIとかそのへんのことを言うのだ、AWSにあらずんばクラウドにあらずみたいなことは言えるかもしれないし、実際信用レベルでいえばまだかなり差があるのはそうなんですけれど、しかしAWSだから大丈夫だ、は原理原則の話をするならやはりあり得ず、それは技術的判断というより信仰というべきではないでしょうか。

一方でAWSがやられたらもう仕方ない、は現実的な妥協点として言えるかもしれません。もしかしたらそういう気持ちは業界としてあるのかなぁという気もするし、正直私も組織のエンジニアの立場ならそう言ってしまう気はします。ただ一人の場末の管理者として考えた時、それはすごく納得できません。

まぁこれは信条なので並行線なんですけれど、ただ個々人がそれぞれ自分の城で守るのは合理の観点でも無謀とは言えません。まず分散されることによって、攻撃側は攻撃成功時の報酬が下がるため、モチベーションが著しく低下します。多くの小規模サービス・サイトで標的型攻撃の的になる可能性はかなり下がるでしょう。また、自分ところでの対策はネットワーク層、物理層などあらゆるところで対策が打てるため、本当に必要な保護を必要なだけやることができます。極端なことを言えば最終奥義物理遮断も可能です。

一方で大手サービスは高い壁があるものの、その壁を超えられると全員巻き添えでとんでもない被害になりますし、またその時出来ることは非常に限られています。

まぁイメージとしては高い壁に囲まれたデカくて整った街にレンタルオフィスを構えるか、孤島に手作りの拠点を構えるのかという違いになるわけですけれど、AIがあろうがなかろうが、リスクのトレードオフの本質が変わらない以上、どちらが間違っているとも言えないんじゃないでしょうか。少なくとも私は討ち死にするならせめて自分の居場所で死にたい。

まぁそうは言っても、自動攻撃も今後激しくなっていくことは予想され、無駄にアタックサーフェスが多いことから、WordPressはちょっと限界を感じています。そろそろ10年ぶりくらいのサイト大改造に着手する時がきたのだろうか…。

<関連記事>

/timescar/

タイムズカーと焼肉きんぐの個人情報漏洩における深刻さのベクトルの違い

/timescar-yakinikuking/

セキュリティリスク再考 KADOKAWAの情報漏洩レベルでも特損36億円らしい

/securityrisk/

LoPiQ v1.18.10 を公開。Windows対応、切り抜き、Exif、AI生成パラメータ確認など

Mon, 19 Oct 2026 00:00:00 +0900

Webブラウザで画像の閲覧・処理するセルフホストのWebアプリ、LoPiQをv1.18.10に更新しました。

主な更新内容

詳細はリリースノート - LoPiQをご参照ください。

Windowsに対応

今回よりWindowsに対応しました。Windows 11 Homeで動作確認しております。未署名のため、警告画面の「詳細情報」から実行する必要があります。インストール方法はインストール - LoPiQのとおりです。

LoPiQは画像を閲覧するだけではなく、フォーマット変換などのスクリプトの実行や、ブログなどの素材編集用の簡易的な編集が可能です。

トリミングと余白の機能を追加

編集モードでトリミング（切り抜き）ができるようになりました。

また、一覧モードで使える余白追加の機能を標準アクションに追加しました。

これにより、必要な部分だけを切り抜いたうえで、サムネイル用などに余白をつめてアスペクト比の補正をする等ができるようになりました。

Exif、AI生成パラメータの確認

画像プレビュー中に i キーを押すと詳細パネルが表示されます。カメラの機種や撮影設定、GPS位置情報を確認できるほか、AI生成画像のプロンプトやモデル名・シード値を自動で整理表示し、ワンクリックでコピーできます。

他

そのほか下記のような対応をしています。

AI相談用のプロバイダでDeepSeek対応
Linux向けアップデータの安定性向上

今後の開発方針

今後、ファイラとしての活用のため画像以外のファイル形式についても閲覧と簡易的な編集およびコマンド実行をできるようにする予定です。

LoPiQはAIプログラミングで開発しています。今後も継続的にアップデートしてまいりますので、LoPiQをよろしくお願いします。

WordPress が Web サーバーにアクセスする必要があります。次に進むには FTP の認証情報を入力してください（大嘘）

Sun, 04 Oct 2026 00:00:00 +0900

早くWordPressを更新しろ！間に合わなくなっても知らんぞーーー！！って脅してくるから更新しようとしたら

要求されたアクションを実行するには、WordPress が Web サーバーにアクセスする必要があります。次に進むには FTP の認証情報を入力してください。認証情報が思い出せない場合は、ホスティング担当者に問い合わせてください。

などと意味不明な供述をしてきたときの対応。多分DockerでWordPress使っている時によく出てくる、と思われる。大昔ネイティブで運用していた頃には見たことなかった気がする。

次に進むには FTP の認証情報を入力してください。（大嘘）だし、そもそもホスティング担当者（私）なので、例によって全然違う対応をする必要があります。

環境

Docker版だよ。

Linux Mint Xfce 22.3
Docker version 29.8.1, build 4a63305
- WordPress 7.1 -> 7.12

原因

Webサーバドキュメントルートの/var/www/htmlの権限問題が発生していると思われます。なんで発生しているのかは知らん。なぜなの？

コンテナ内でのパーミッション修復手順

docker-compose.ymlのあるところに移動して、とりあえずコンテナに入ります。

docker compose exec wordpress bash

違ったらdocker compose psでSERVICE列を確認します。

/var/www/htmlにいる状態から始まります。で、ls -ldすると所有権がrootになっていました。

以下のコマンドを実行してWebサーバーの実行ユーザーに所有権を戻します。

chown -R www-data:www-data /var/www/html

実行後、Web画面から再度更新を実行して、通ればOK。

エラーメッセージは永遠に

どうでもいいんですけど、IT関係のエラーメッセージの不親切さは永遠なんでしょうかね。あまりにも意味不明過ぎて逆に検索適応性が高いという謎の事象も発生。AI革命だのAIでもう知識労働は不要だのAIで人類絶滅だのなんかセンセーショナルな記事ばかり出てきますが、結局わからないのはAIツールの吐き出す謎のエラーメッセージ、そして何よりエラーの原因であったりします。

GoogleのAIコーディングツール、Antigravityでよく見るエラーメッセージ

あの日見たエラーメッセージがなんだったのか僕たちは永遠に知らない…。

LoPiQ v.1.16.10 の公開

Thu, 24 Sep 2026 00:00:00 +0900

LoPiQをv.1.15.4からv1.16.10に更新しました。リリースノート - LoPiQより詳細を確認できます。

LoPiQはセルフホストできる画像ファイラです。画像を確認しながら、削除、回転、WebP変換などスクリプト操作を実行することを主たる目的にしています。

今回、大きな設計の変更があります。すべてのアクションはシェルスクリプトというのがLoPiQの方針でしたが、現実の利便性を考えたときに、標準的な操作はビルトインで用意するほうが便利であると判断しました。そのため、今回から削除や回転のような標準的アクションについて、アプリケーション側で実装したビルトインコマンドを用意します。

また、アクションは有効/無効を切り替えられるようにし、ユーザが必要なアクションのみをUIに表示するようにします。

これに合わせて、設定画面は専用ページを用意するようにしました。

今回の改修でOSの機能を使ったゴミ箱削除なども実装が可能になりました。また、Go言語を使っているため、Windowsでの実行も期待できるため、次回以降でWindows対応を目指します。

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

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/

PC内にある画像を閲覧しながら、スクリプト処理や削除処理を実行できるセルフホストのWebアプリケーション『LoPiQ』を公開しました

Sat, 29 Aug 2026 00:00:00 +0900

セルフホストの画像閲覧・管理用Webアプリケーション『LoPiQ（ローピック）』 を公開しました。

LoPiQ

LoPiQはLocal, Picture, Quickを謳った、PC内にある大量の画像を、いつでもどこでも、PCのみならずスマホやタブレットからでも、閲覧・整理することを目的にしたセルフホストのWebアプリケーションです。写真を多く撮影する人、画像や素材集めをしている人、またAIイラストを利用している人など、大量の画像を見ながら定型的な処理をする人に向いています。

Linux(Debian/Ubuntu/Mint系)およびMac用のみを公開していますが、Windows版についても公開を検討しています。

LoPiQの特徴

LoPiQの大きな特徴は2つあります。

1つは、サーバを必要とするWebアプリケーションであることです。これは、PC内にある画像ファイルについて、PCのみならず、ネットワーク内のスマートフォンやタブレット端末から操作することを目的としています。また、PC自体が処理を実行することで、PCの持つスペックを最大限発揮できます。

もう1つは、スクリプトによるカスタムアクションを自分で定義できることです。これによって、たとえば画像をWebPにコンバートする、白色化・グレースケールにする、任意のフォルダに移動する、オンライン・ストレージにアップロードするといったことを、画像を見ながらテンポよく実行することができます。コマンドは任意のキーボードショットに割り当てられ、全画面でプレビューしながら、画像ごとにアクションを振り分けられます。

なおカスタムアクションでは定義しづらいコマンドとして、ダウンロードボタンと、クリップボードに画像をコピーするボタンはビルトインで備わっています。それ以外のコマンドはすべてカスタムすることになります。

このように、ユーザが責任を持ってコマンドを作成・管理することで、マシンの力をフルに発揮して、最大の効率を達成することを目的としています。

これらの特徴から、むしろコマンド実行のできるファイラのような印象を抱かれた方もいらっしゃるかもしれません。まさに、ビューアというより、本質的にはファイラに近い性質を持っています。エンジニア向けに言うと、本アプリは「Linux/Macのコマンドライン環境をWeb UIでラップしてスマホからも叩けるようにした作業自動化・効率化のためのスクリプト実行基盤」と言えます。

AIと相談しながら自分専用のコマンドを生成

コマンドについては、Linux/Macについてはシェルスクリプトを利用します。したがって、シェルスクリプトについて一定の知識と調べられることが前提となり、敷居が高く感じられるかもしれません。

以前までならそうだったでしょうが、現在はAIを利用することで、非常に簡単にコマンドをつくることができるようになりました。シェルスクリプトは長年使われてきた汎用的な知識であり、仕様についても固まっているため、商用AIの無料枠でも非常に高い精度での返答が期待できます。

本アプリケーションはOpenAIのAPIに対応しており、API Keyを持っていれば、アプリケーション内で、マニュアルに即した形でのAI相談が可能です。たとえば、 「画像を90度回転するボタンを作りたい」とアプリケーション内でAIに相談するだけで、設定すべき内容が即座にかえってきます。そのまま登録まで可能です。

ただし、新しいコマンドの実行については、まず検証し、意図しない破壊的な処理が行われないことを、丁寧に確認してください。その危険性についてもAIは教えてくれますが、大切なデータにかかることですので、バックアップのうえでの検証が非常に重要です。

AI対応については、今後の更新でより拡張していく予定です。

インストールと実行

配布サイトより、インストーラを実行します。

LoPiQ

実行すると、ブラウザの http://localhost:13180 よりアクセスできるようになります。localhostではなくIPアドレスを指定することで、LAN内の他PCやスマホ・タブレットからもアクセス可能です（環境によっては別途ポート開放が必要です）。望まないアクセスについては、パスワードを設定して保護することができます。

Linux版はsystemdの管理で常駐し次回から自動で起動します。また、今後のアップデートはWeb UI上から可能です。一方でMac版は自動起動の設定はありません。また、アップデートについては通知のみとなり、手動で実行する必要があります。詳細は配布サイトのガイドをご参照ください。

Windows版は現在準備中です。Windows版については、私が普段このアプリケーションをMac/Linux上で使っているため、検証しきれておらず、今回の公開は見送りとなりました。

開発のAI利用について

本アプリケーションはほとんどAIを利用して開発しました。元々の開発は2年以上前まで遡り、当時はツールも熟れておらず、コードも見ていましたが、現在はツールが発達し、コーディングエージェントの性能が飛躍的に変わったことを受けて、私の開発スタイルも大きく変わりました。現在は専ら設計とテストのみ自分でやり、コーディングは全部AIです。

現在メインのツールはGoogleのAntigravityで、モデルはGemini 3.x FlashおよびClaude Opus 4.6です。Googleが良いというわけではありませんが、セールで安かったので利用しています。個人開発としては十分だと思います。

今後の更新について

LoPiQは私が日常的に利用しているアプリケーションを、多くの人が使えるように公開向けに手直ししたものです。既存のビューアやファイラでは、機能やパフォーマンス、安定性で満足がいかず、自分で作り始めました。なんだかんだで2年以上使っています。したがって、自分自身がまず最大の顧客ですから、今後も継続的に開発を続けていきます。

コマンドについては、AIに相談できるとはいえ中々難しい面があるように思われますので、今後プラグイン化し、公開サイトからよくあるコマンドをダウンロードして適用できるような形を考えています。

そもそも対象ファイルを画像に限定する意味ももはや薄れている気もするのですが、対象を広げてしまうと考えることも増えるため、元々のユースケースから、画像ファイルのみ対象としているものの、今後全ファイルを対象とする可能性はあります。

もしバグなどありましたら、サイトのどこかにコメントするか、管理人の連絡先メールアドレスまでご連絡ください。

【脱Google？】Google抜きで古のアクセスカウンタを設置できる、そうAIならね

Fri, 28 Aug 2026 00:00:00 +0900

アクセス解析といえばみんな大好き過ぎて涙目で泡吹いているGA4ことGoogle Analyticsなんですが、当サイトはマイブームだった脱Googleの流れで利用をやめました。まぁこれに関しては脱Googleというより、純粋に使いづらかったからやめた面もあります。GA4は個人サイトのアクセス解析としてはあまりにも重すぎて意味不明、最初からGA4だったら誰も使わなかったんじゃないのこれ、と思います。

Umamiの導入

それから当サイトではWordPressのプラグインのお世話になっていたんですけれど、最近、セルフホストできるUmamiを導入しました。

セルフホストしたUmamiでWordPressサイトのアクセス解析

/umami-wordpress/

これでWordPressプラグインに頼らず、またWordPress以外のあらゆるサイトについて一括してアクセス解析ができるようになりました。有り難いことです。

UmamiはAPIを利用できるので、サイト内の記事のアクセスランキングなどもつくれます。ま、WordPressで実現しようと思ったらカスタムフィールドとかいじる必要あると思いますが…当サイトはもともと別に独自実装で入れていたものがあるので、それを流用することでランキング生成のバックエンドもサクッとUmamiベースに置換できました。

アクセスカウンタをもう一度

作業中、もしかして古のアクセスカウンタを設置できるのかなぁ、とふと思いました。アクセスカウンタって古代文明の名残みたいな感じかもしれませんが、というか若い人はもしかすると存在を知らないかもしれませんが、昔の個人サイトはたいていあったものです。

アクセスカウンタが消えたのは、需要が消えたから、ではないと思います。実際、PVランキング自体はけっこう色々なサイトで今でもありますよね。というかWordPressでもアクセス解析プラグインはたくさんあります。

だったらアクセスカウンタもあっていいじゃない、と思うわけですが、アクセス解析で覇権を取ったGoogle AnalyticsのAPIを追従しながら頑張って設置するにはちょっと情熱が必要になります。API権限の管理問題で、どうしても煩雑になりますよね。まぁ少なくとも、私は今までやる気にはならなかったですねぇ。

AIが一晩でやってくれました

しかし今は、今までとは違う。セルフホストの環境が完全に整っており、さらにAIがある。このセットによって、今までならば「できるだろうけどめんどくさいなー」ということで半年の放置不可避だったものが、爆速でそれらしいものが出来上がる。

ということで、GeminiにUmamiのAPIをつかったアクセスカウンタのジェネレータを作ってもらいました。

若干の調整は発生しましたが、ジェバンニも真っ青の凄まじいスピードでつくってくれました。これは嬉しい。HTMLの埋め込みタグ一つでアクセスカウンタが設置できます。

そして当サイトに古のアクセスカウンタがのっかりました。

ふふふ。00年代感。

これは既に作っていたサイト管理用Webアプリを土台にして作ったのですが、機能的には独立しているので、切り離せば誰でも使える形になります。なので気が向いたら分離しようかな…と思ったりもしますが、これの場合、通常一番の障壁はどっちかっていうとUmamiをセルフホストすることでしょうね(^_^;)

まぁUmamiも結構な頻度で更新しているようなのですが、バージョン固定できますし、Googleの気分に振り回されず、自分のやりたい解析ができて、解析結果もAI使えば存分に利用可能、というのは、これはかなり魅力的ではないでしょうか。

AI使ってなんだかんだと喧しい世の中ですが、そんな派手なことしなくても、確かに自分にとって役立つものができるので、そういうことを人にも勧めていきたいですねぇ。

<関連記事>

セルフホストしたUmamiでWordPressサイトのアクセス解析

Fri, 21 Aug 2026 00:00:00 +0900

Google Analytics代替として候補にあがる、セルフホストのアクセス解析ソフトUmamiを使っていく。

GitHub - umami-software/umami: Umami is a privacy-first analytics platform. Traffic, campaigns, behavior, conversions, and revenue in one place — no cookies, no tracking, self-hosted or in the cloud. · GitHub

なお公式サイトはisドメインなんだけれど、なぜか弾かれる。Cloudflare経由で接続するといけるのでおまかんっぽいんだがアイスランドに嫌われるようなことしたっけ？

まぁそれはいいとして、今回インストールでは「How to Install Umami Analytics on Docker (2026 Guide)」の記事を参考にさせていただきました、っていうか正直うちの記事よりこの記事のほうが詳しいからこっち見たほうがいいよｗ

じゃあなんで書くのかというと、記事は消えるから……。10年以上もブログやっていると「この記事が詳しいです！」で雑に案内だけ貼ったリンクが消える消える。まぁ微妙に情報補足と雑なWordPress案内も追加したので…。

環境

Umami@3.2.0
自宅サーバ
- ThinkPad L390, Core i5-8265U, 32GB RAM
Linux Mint Xfce 22.3
- docker 29.7.2
Cloudflare Tunnel

インストールと最初の設定

`docker-compose.yml`

以下でランダムな文字列を作る

openssl rand -hex 32

文字列はコピーしておく。

.envを作成する。以下のAPP_SECRETにさっきのランダム文字列を入れる。パスワードは適当に入れる。

POSTGRES_USER=umami
POSTGRES_PASSWORD=your-secure-password
POSTGRES_DB=umami
APP_SECRET=run-openssl-rand-hex-32-to-generate
DISABLE_TELEMETRY=1

docker-compose.ymlを編集。元記事からimageのURLだけ差し替えた（エラー出たので）。ポート番号は変えたかったら変える。バージョン固定したかったらする。ちなみにvつかないらしい（v3.2.0ではなく3.2.0）。

services:
 umami:
 image: umamisoftware/umami:postgresql-latest
 ports:
 - "3000:3000"
 environment:
 DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@umami-db:5432/${POSTGRES_DB}
 APP_SECRET: ${APP_SECRET}
 DISABLE_TELEMETRY: ${DISABLE_TELEMETRY:-1}
 depends_on:
 umami-db:
 condition: service_healthy
 init: true
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
 interval: 5s
 timeout: 5s
 retries: 5

 umami-db:
 image: postgres:15-alpine
 environment:
 POSTGRES_DB: ${POSTGRES_DB}
 POSTGRES_USER: ${POSTGRES_USER}
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 TZ: UTC
 volumes:
 - ./umami-db-data:/var/lib/postgresql/data
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

ここで、参考記事によると、Cloudflare Tunnelを使っている場合、Umamiから見ると全部CloudflareのIPを取ってしまうので、docker-compose.ymlのenvironmentに以下を追記せよとのことであった。

CLIENT_IP_HEADER: cf-connecting-ip

VPSとかで直接公開してCaddyをリバースプロキシにしている場合はヘッダの付与よしなにしているから不要なはず。

準備が出来たら、docker compose upでエラーが出ないことを確認する。いけたらdocker compose up -dでバックグラウンド起動。

最初の設定

http://<IPアドレス>:<ポート>にアクセスして、ユーザ名adminとパスワードumamiでログイン。

当然危ないので、管理者設定からパスワードを変更する。ユーザ名も変更できる。

言語設定も日本語あり。

ネットワーク設定

トラッキングデータの送信はクライアントマシンから行うため、グローバルに公開する必要あり。

全体の流れは以下 by AI。

sequenceDiagram
autonumber
actor Client as クライアント
participant WP as WPサーバー(ブログサイト)
participant Umami as Umamiサーバー(セルフホスト)
Note over Client, Umami: 1. ブログページの読み込み
Client->>WP: ① ページリクエスト (アクセス)
WP-->>Client: ② HTML返却 (Umamiのscriptタグを含む)
Note over Client, Umami: 2. アクセス解析データの送信 (クライアント直接)
Client->>Umami: ③ script.jsの読み込みリクエスト
Umami-->>Client: ④ script.jsの返却
Client->>Umami: ⑤ 閲覧データ(PV等)を直接送信 [要グローバル公開]

うちの場合は例によってCloudflare Tunnelで開通している。

ここでサブドメインだが、参考記事によるとanalyticsとか使うと広告ブロッカーに遮断される率が上がるらしい。参考記事ではstatsやmetricsやtrackなどにせよと言われている。

WordPressサイトの解析

別にWordPressサイトじゃなくてもやることは同じ。

トラッキングコードの取得

サイドバーの「Webサイト」より、管理したいドメインを追加する。

追加したら、Editを開くと以下のようなトラッキングコードが取得できる。

<script 
 defer 
 src="https://your-umami-domain.com/script.js" 
 data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
</script>

基本はこれを<head>タグに貼り付けること。

タグの貼り付け

プラグイン「Integrate Umami」があるが、<head>タグに貼り付けるだけなのでプラグイン使う必要はないかなと思う。

うちはテーマとしてSwellを使っているので、「外観」「カスタマイズ」「高度な設定」から「headタグ終了直前に出力するコード」にコードを貼り付け。

自分だけ除外とかするなら functions.phpでログインユーザにはトラッキングコードを出さないとかしないといけないかなと思う。

実測で確認

しばらくダッシュボードを見てきちんと動いているか確認する。

まぁなんか動いてそう。使い方についてはおいおい見ていこうと思う。

以上。ちなみに最初AIに聞いて作業していたんだが、古いバージョンの情報に惑わされて完全に無能だった。

エアコンとローカルAIサーバで電気代がとんでもないことに

Wed, 19 Aug 2026 00:00:00 +0900

さすがに一人暮らしでこれは反省した。

引越したばかりだからなのか、計算された日付がちょっと長くて、32日分くらい計測されている、というのはあるのだけれど、それにしても469kWhとは。1日あたり15kWhくらい使っている計算になるね。

まぁまずエアコンの電気代がエグいのはある。1日中つけっぱなしなので、これだけで5kWhにはなってそう。もっとかな。

あとはサーバやね。一番はStable DiffusionのためのローカルAIサーバかな…。ただこれはMaxでも確か300kWくらいで最大出力出しっぱなしということはないはずなんだけれどなぁ。頻度によるけど、1日で4-5kWhくらい使ってるかもなぁ。

他にセルフホスト系。サーバはノートPCなんで、前に測った感じだと消費電力は多分せいぜい15Wといったところだと思うんだけれど、意外でもなく重いのがハードディスク4台のせたガチャベイと思われる。これは1度ちゃんと測定しないといけないと思っているが…多分ならすと平均30Wくらいかなぁ。なのでまぁ、合計すると1kWh/日超えそうだよね。

あとは冷蔵庫とかなんとか色々使ったら5kWhくらいになるでしょう。するとまぁたしかに、5+5+1+5=16なので外出日とかでならすと15kWh/日になる、というのはそうだなぁ。なんか見てみると日によっては20kWh超えているときもあって酷い。去年でもここまでひどくはなかったので、さすがにもうちょっとどうにかしたい。

しかしそれにしても、エアコンについては環境的な要因もかなり大きいわけで、エアコンが新聞紙より高い消費税率10%で、しかも謎の再エネ賦課金とか課して起きながらさらにそれにも税金かけるっていうの、本当に意味不明だなぁと思う。新聞は露骨に政治的な配慮を求めておきながら、昨今の食品消費税減税については減税するなと発狂しているんだから腐ってる。

まぁ何を言っても詮無いことなので、とりあえずエアコンとAIはちょっと控えよう。

AndroidでLAN内DNS(AdGuard Home)にIPv4アドレスでアクセスする

Tue, 11 Aug 2026 00:00:00 +0900

うちのプロバイダは楽天ひかりなのだが、楽天ひかりはIPv6必須となっている。で、LAN内DNSとしてAGHを利用しているのだが、最近のOSだとIPv6が優先されてLAN内ドメインの名前解決がうまくいかない。多分ルータとAGHでそれぞれIPv6の設定をきちんとやればうまくいくのだろうけれど1ミリもやる気が起きない。

なのでクライアント側でWi-fiネットワークの設定からIPv6を切っているのだが、PCはそれでよくてもスマホで詰まった。IPv6切れない。どうしてそういうことするの…。

環境

ルータ: TP-Link AX5400
サーバ: Linux Mint Xfce 22.3
- DNS: AdGuard Home(AGH)
- リバースプロキシ: Caddy
Android 15 (Pixel 7)
- RethinkDNS
- MacroDroid

やりたいことは、Android側でDNSをIPv4でAGH入れたサーバに向ける。

標準のDNSサーバ指定じゃいかんのか？

Androidには一応静的IPでDNSサーバを指定する機能もある。一見これでおしまいに見えるが、実際にはIPv4のサーバアドレスしか指定できないうえに、IPv6は切れないし、IPv6で名前解決失敗したらIPv4で試すとかするわけでもない、中途半端な無能。

なので標準の機能では無理。

RethinkDNSで強制する

RethinkDNSをダウンロード＆インストールする。

タブバーから「構成」を選択
「DNS」を選択
「その他のDNS」
「DNS 53」
＋ボタンで追加してチェックを入れる

IPアドレスとポート番号だけ記述。ポートは普通は53

最初の画面に戻って「開始」

これでLAN内ドメインの名前解決できるか試す。いけたらOK。

MacroDroidでネットワークを検知してOn/Off

これだけだとネットワークから離脱したり入ったりするたびにRethinkDNS起動してOn/Offしないといけないめんどくさい。

なのでマクロアプリを入れて自動化。ここではMacroDroidをインストール＆ダウンロード

まず開始のトリガを作る。

+でマクロの追加
トリガー

+を長押し
「Wi-fi状態の変化」
「ネットワークに接続時」より指定

アクション

「アプリ」「アプリを起動」より「RethinkDNS」を選択
「待機」で検索「1秒」
「機器の操作や動作」「UI画面操作」より「クリック」で「テキスト」の「開始」

これでネットワークに参加したとき、自動で開始したらOK。

同様に停止のマクロも作成。

+でマクロの追加
トリガー

+を長押し
「Wi-fi状態の変化」
「ネットワークに切断時」より指定

アクション

「アプリ」「アプリを起動」より「RethinkDNS」を選択
「待機」で検索「1秒」
「機器の操作や動作」「UI画面操作」より「クリック」で「テキスト」の「停止」

ネットワークから離脱したときに自動で停止したらOK。

なにもかも違ってますか

なにか間違っているような気がして仕方ないが、とりあえずこれで運用している。起動しながら移動していれば問題ないのだが、画面OFFにしたまま移動すると動いてない感じ。まぁでも他にやりようもなく。自分は割と外に出るときはスマホいじりながら出るので…。

以上。

セルフホストした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/

ConoHaのVPSまた落ちたか

Tue, 30 Jun 2026 01:20:58 +0900

つい先日の6/26にConoHaから障害メールがきていた。僕は障害を確認していないのだが、どうやら3月の大規模障害でさんざっぱら叩かれたのを反省したらしい。

6/25 23:16に発生とあるにも関わらず、最初の障害報が6/26 3:00であるし、復旧報も自分のサーバが対象かどうかを自分で調べさせるというストロングスタイルではあるものの、メールを送るようになっただけマシになった。

しかしそうはいっても、障害起きすぎじゃないの、とはやはり思う。今現在、家にネット回線がきていないネット難民化しているため、このブログを含めた常時稼働のアプリケーションをConoHa VPSにうつしているため、不安になる。頼む、僕が使っている間だけは落ちてくれるな…。

落ちた☺️

朝アクセスしようとしたその瞬間にまさに落ちたと思うわ。マジかよと思ったけど、だいたい15分くらいで復旧したかな。復旧したと信じたい。

朝でかつ比較的短い時間ではあったものの、X見ると僕以外にも何人かまた落ちてる？とツイしていたので、多分障害だったのだろう。というか僕のXアカウント、ConoHa VPSの死活監視botになってるわ。落ちるたびにSNSで騒いでるうえ、スクショあげたり記事にしたりまでしているので、ConoHaの中の人にマークされている気もする。とりあえずその後メールはきてないので、ConoHa的にはこれは障害ではなさそう。

まぁこういう感じなので、ConoHaはもう全然おすすめできるVPSではなくなってしまったね。昔はこんなに不安定じゃなかったんだけどね。。。

ConoHa VPS落ちすぎ問題

/conoha-vps-down/

WordPress(Docker)をコンテナとボリュームごと別マシンに移行するスクリプト

Sun, 14 Jun 2026 15:37:33 +0900

以下の記事の自動化スクリプト。

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

/container-wp/

やることとやらないこと

やること
- 移行元からボリュームをバックアップして、移行先で復元する
やらないこと
- 移行後のルーティング

スクリプトでやっていることについて図示する。バックアップ中はダウンタイムとなるので注意。

flowchart TD
subgraph Local["ローカルマシン (移行元)"]
direction TB
A[YAMLからボリューム一覧を取得] --> B[移行対象のボリュームを選択]
B --> C[元マシンのコンテナ停止]
C --> D[選択ボリュームのバックアップvackup export]
D --> E[元マシンのコンテナ再開ダウンタイム短縮]
E --> F[設定ファイル一式とバックアップを転送rsync]
end
subgraph Remote["リモートマシン (移行先) SSH経由で自動実行"]
direction TB
G[作業ディレクトリに移動]
H[ボリュームのリストアvackup import]
I[ネスト構造の解消vackup-volumeを直下へ移動]
J[移行先コンテナ起動docker compose up -d]
K[リモートの一時バックアップ削除]
end
F -->|ネットワーク転送| G
G --> H
H -.各ボリュームごとにループ.-> I
I --> J
J --> K
subgraph Local_Cleanup["ローカルマシン (完了後)"]
L[ローカルの一時バックアップ削除]
end
K -->|処理完了| L

準備

移行元から移行先に、sshで転送できるようにしておく。
- 移行元はLAN内のマシンで、移行先はVPSとする。
移行元と移行先にdockerとdocker composeとvackupを入れる。

vackupについては以下。

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

/docker-volume-cli-backup/

また、移行元のディレクトリ構成を以下のようにする。

.
├── site1
│   ├── custom-php.ini
│   └── docker-compose.yml
├── site2
│   ├── ads.txt
│   ├── custom-php.ini
│   └── docker-compose.yml
└── migrate-wp.sh

上記のディレクトリ構成で、migrate-wp.shを実行すると、転送先のマシンにコンテナの設定とボリュームごともってく。ディレクトリごともっていくので、見えていないが.envも含む。

スクリプトと実行

スクリプトは以下。AIが書いた。

#!/bin/bash

# エラー発生時にスクリプトを終了
set -e

# 引数のチェック
if [ "$#" -ne 3 ]; then
 echo "Usage: $0 <dir_name> <user@ip> <remote_base_path>"
 echo "Example: $0 site1 user@192.168.1.50 /home/user/wordpress"
 exit 1
fi

DIR_NAME=$1
REMOTE_TARGET=$2
REMOTE_BASE_PATH=$3

LOCAL_DIR="./$DIR_NAME"
REMOTE_DIR="$REMOTE_BASE_PATH/$DIR_NAME"

# ローカルディレクトリの存在確認
if [ ! -d "$LOCAL_DIR" ]; then
 echo "Error: Local directory '$LOCAL_DIR' does not exist."
 exit 1
fi

echo "=== 1. ボリューム名の取得 ==="
cd "$LOCAL_DIR"

# docker compose config を使ってボリューム名一覧を取得
VOLUMES=$(docker compose config --volumes)

if [ -z "$VOLUMES" ]; then
 echo "Error: No volumes found in docker compose config for $DIR_NAME."
 exit 1
fi

echo "対象ボリューム:"
echo "$VOLUMES"

echo "=== 2. 元マシンのコンテナ停止 ==="
docker compose stop

echo "=== 3. ボリュームのバックアップ (vackup) ==="
mkdir -p volume-backups
for vol in $VOLUMES; do
 echo "Exporting volume: $vol"
 vackup export "$vol" "volume-backups/$vol.tar.gz"
done

echo "=== 4. 元マシンのコンテナ再開 (ダウンタイム短縮) ==="
docker compose up -d

echo "=== 5. 移行先へのファイル転送 (設定ファイル一式 + バックアップ) ==="
cd ..

# 移行先にターゲットディレクトリを作成
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "mkdir -p ${REMOTE_DIR}"

# フォルダごとリモートへ同期
rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" \
 "$DIR_NAME/" "${REMOTE_TARGET}:${REMOTE_DIR}/"

echo "=== 6. 移行先でのボリュームリストアと起動 ==="

# 変数内の改行をスペースに変換する
VOLUMES_ONELINE=$(echo "${VOLUMES}" | tr '\n' ' ')

REMOTE_SCRIPT=$(cat << EOF
cd "${REMOTE_DIR}"

for vol in ${VOLUMES_ONELINE}; do
 echo "----------------------------------------"
 echo "Processing volume on remote: \$vol"
 
 # リストアを実行
 vackup import "volume-backups/\$vol.tar.gz" "\$vol"
 
 # vackup-volume のネスト構造を修正
 echo "Fixing nested directory structure for \$vol..."
 docker run --rm -v "\$vol":/volume alpine sh -c "
 if [ -d /volume/vackup-volume ]; then
 mv /volume/vackup-volume/* /volume/ 2>/dev/null || true
 mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true
 rmdir /volume/vackup-volume 2>/dev/null || true
 fi
 "
done

echo "----------------------------------------"
echo "Starting containers on remote host..."
docker compose up -d
EOF
)

# 移行先マシンでリストア処理を実行
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "${REMOTE_SCRIPT}"

echo "=== 7. ローカルの一時バックアップを削除 ==="
rm -rf "$DIR_NAME/volume-backups"

echo "=== 移行プロセスが完了しました ==="

使い方は以下。

./migrate-wp.sh site1 VPSのユーザ@VPSのIPアドレス /home/VPSのユーザ/wordpress

これを実行すると、移行先に~/wordpress/site1ができる。すでにコンテナの実行までされている。

なので、あとはDNSなどを操作して移行元から移行先に向けるとか、ルーティングで必要なことをやれば移行完了。

以上。

Growi (Docker) をコンテナごと別マシンに引っ越す

Sat, 13 Jun 2026 13:10:29 +0900

環境

移行元
- Intel Mac mini 2018
- Docker Desktop
- Growi 7.x
移行先
- Linux Mint Xfce 22.3
- Docker 29.2.1
- Growi 7.x

基本的な手順

手順はWordPressのコンテナ移行とほぼ一緒なので、下記記事を参考にすること（雑）

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

/container-wp/

全体の流れと微妙な差分を下記にメモ。

移行元でコンテナを停止してボリュームをバックアップし、移行先にアーカイブを送信
移行先でボリュームを復元

ここでElasticsearchの書き込み権限がなかったりするので修正する

移行先のdocker-compose.ymlでボリューム名を指定する
docker compose upしてブラウザで動作確認

の流れ。ボリューム名の定義と、権限の修正あたりが若干の追加要素となる。

ボリューム名は通常はフォルダ名にデフォ名つくような感じだろう。たとえばgrowiフォルダでは以下のようになっているだろう。

local growi_es_data
local growi_growi_data
local growi_mongo_configdb
local growi_mongo_db

これらについて、docker-compose.ymlでes_dataやgrowi_dataとなっているところをそれぞれ修正する。そしてexternalをtrueにする。ここらへんは上記WordPress記事のymlを見て参考に。

docker compose upで様子を見るが、もしかするとElasticsearchでエラーが出てしまうかもしれない。これはElasticsearchコンテナの権限問題であるため、以下のコマンドで修正する。

docker run --rm -v <ボリューム名、たとえばgrowi_es_data>:/mnt alpine chown -R 1000:1000 /mnt

雑だが、以上。

Docker版WordPressの更新でFTPの認証情報を求められた時

Thu, 11 Jun 2026 10:19:31 +0900

環境

Linux Mint Xfce 22.3
Docker 29.5.3
WordPress 6.9.4 -> 7.0

症状

WebブラウザでWordPressを更新しようとしたら、以下のようにFTPの接続情報を求められた。

原因と対応

Webサーバのユーザがwww-dataになっていないと考えられる。確認する。

docker compose excc <wordpress> /bin/bash

ターミナルに入って、/var/www/htmlのパーミッションを見てみる。

root@:/var/www# ls -l
total 4
drwxr-xr-x 5 root root 4096 May 18 03:05 html

oh…。

ログアウトして修正する。

docker compose exec <wordpress> chown -R www-data:www-data /var/www/html

この後、WebブラウザよりWordPressで更新を実行すると、更新できるようになる。

以上。

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は動いているという事実を大事にして明日を生きよう。

Tailscaleを消すならOSごとになりそう

Thu, 14 May 2026 00:00:00 +0900

Tailscaleについて、以下の記事が非常に参考になった。

Tailscaleやめたい - まいの雑記帳

「Tailscaleはネットワークの知識がない人が使うもの」という書き出しのため、使っている身からすると少々むむむとなりつつ、その後の記述を見ると、実務で相当苦労されたのだろうと察せられた。全体的に以下のようなふるまいがあるようだ。

リソースを過度に占有し他ソフトウェアと競合する
RFCにも従わない独自仕様
設定変更できない
ユーザのiptablesの設定を上書きする（これが一番ひどい）

Tailscaleはかなり強権的かつ、相手に譲らない、また設定変更の余地がない、という特徴があるのはわかった。まぁ昨今ソフトウェアの挙動としては珍しくないかもしれない。他ソフトウェアとのリソース争い・主導権争いについては、まぁユーザからすると妖怪大戦争に巻き込まれた感じではあるものの、設定の変更ができないのはどうにもならない感じ。また、当然求められる慣習に反する独自仕様については確かにそこは合わせてくれと思う。まぁ俺がRFCだといわんばかりの態度はあちらの人にはよくあることかもしれない…。

記事主が一番腹を立てていたiptablesの書き換えは深刻で、この部分は明確にユーザの主権の侵害であるから、その怒りは正当なものであると感じられた。

ただ僕の環境について思った時、大きな影響はなさそうだ、というのもある。とはいえMagicDNSはオフにしたいと思った。これに起因するトラブルは割とありそうなので。

一番強権的だなぁと思うiptables関連はどうにもならなそうである。というかファイルを書き換えるような挙動は、Tailscaleをアンインストールした場合にどこまで綺麗になるのか、不安に思われた。強権的な振る舞いをするソフトウェアの思考として、立つ鳥跡を濁さずという言葉はない気がする。

どっかのタイミングでアンインストールしようかなと思っていたんだけれど、その際はOSごと再インストールしたほうがよさそうね(^_^;)

とはいえ、なんだかんだで当面は使い続ける気がする。自分の用途の場合、お外で使うプロトコルは正直HTTPSでだいたい済んでしまうので、Tailscaleはオーバーではある。実際AGHやCaddy絡ませてスプリットDNSやるときに明らかに複雑になってしまう。いらない複雑性だなとは思っている。とはいえ外部接続をCloudflare TunnelやVPS + frpにしてしまうと、インターネット前提になってしまうために認証やらなんやら考えることが増えるのはそう。まぁでもそのほうが、外から繋げたいのか外では繋げなくてもいいのか、明示的になるからいいかもしれない。

全部をTailscaleのネットワークに入れるのもなんだかなぁという気持ちはあったので、やっぱりどこかで重い腰あげて、脱Tailscaleはしようかなぁ。

その後本当に脱Tailscaleしましたが、結局OS再インストールまではしていません。まぁ所詮ホームサーバなので、実害はないかなぁと…。まぁそうでなくても、OS再インストールはどうせ定期的に起きるイベントですので、まぁ。

AIプログラミング開発日誌6：セルフホストしているアプリを管理するアプリをセルフホストしている

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

色々とFOSSやら自作アプリやらをセルフホストしていたら、どのマシンに何を入れたかよくわからなくなってきて、管理アプリケーションの必要性を感じた。そこで、セルフホストしているアプリを管理するアプリをAIで作成しセルフホストしている。

Antigravityで作った感

なんかいつのまにか41のアプリケーションをセルフホストしていたらしい。というか常時稼働サーバが6台あるのもなかなか意味不明な状況である。ちなみにサーバじゃないので登録してないマシンもある😇エネショートしたらしぬ。

もともとはスプレッドシートで管理していたのを、Antigravityに読み込ませて適当にアプリ化した。なのでまだ機能的には台帳程度だ。逆に言うと、台帳程度のアプリケーションなら誰でも秒で作れる。非エンジニアはスプレッドシートからはじめて、それをAIに読み込ませてアプリ化するところから始めるといいかもしれないね。

ただ台帳じゃアプリの甲斐がない。というかそれならたいていの場合はスプレッドシートでいい。まぁテーブルの構造じゃなくてツリー構造のデータなら、スプレッドシートでは扱いづらいから、単に台帳でも価値あるかもしれないけど、やっぱりアプリならなんかしらアクションがないとね。

具体的には、ここからリバースプロキシの設定ファイル（Caddyfile）を書き出したり、デプロイ・ホスティングやバックアップなど総合的に管理していきたいと思っている。また、その後は、複数のマシンをローテーションで使いまわして、様々な機材を検証する体制を整えたいね。なにしろうちには40台くらいPCがあるので。アプリ1個割り当てられて草。そんでとにかく検証の記録をつけていこう。検証なんて実践以外ないし。実際に使ってみて使えるか、それがすべて。マシンの検証記録なども追加していきたいな。

本当にやりたいことはPCの采配であり、その歴史を記録することなんだろうね。アプリを作っていると、自分のやりたかったことが見えてくる気がしている。実際、41のアプリケーションのうち10ちょっとが自作なのだけれど、全部ちゃんと使っているかというと微妙。でも半分くらいは使っていて、使い続けられているものには傾向があるように思われる。

なんとなく、僕がよく使うのは管理系が多いようだ。今回作り始めたセルフホスト管理アプリもそうだけれど。管理されるの嫌いな癖に管理するのは好きなのか。いや、人を管理するのは好きじゃないんだけど、モノを管理するのは好きなんだね。コレクター的な気質があるんだろうな。モノがたしかにそこにあった痕跡を残したいとか、そういう欲求があるのかもしれない。僕みたいなのが小金持つと、個人で博物館とか作ったりするんだろうねぇ。

一時期はなんだか今まで自分のやってきたことが何もかも無意味に思えてナーバスになっていたのだけれど、最近は初心にかえり、とりあえず自分がほしいモノを作っていこうと思っている。AIでソフトウェアエンジニアの多くが不要になり、巷では誰も使わないサービスやアプリが乱立する昨今だけれど、不思議と僕が欲しいものだけがない。お陰様で僕にもやることが残っている。まぁ世情も荒れているし、いつまでそんな贅沢ができるかはわからないけど、当分はいいだろう。

Linux Mint Xfce 22.3 を WebDAVサーバにする

Thu, 07 May 2026 00:00:00 +0900

音楽ファイルのストリーミングでWebDAVを利用していた。これまではNASで構築していたのだけれど、Linuxサーバ移行の流れで自分でサーバ組むことにした。

環境

Linux Mint Xfce 22.3
- ThinkPad L390
docker 29.4.1
BytemarkHosting/docker-webdav

apache生で入れると融通きかなくなりそうなので、docker使うよ。

docker-compose.yml

services:
 webdav:
 image: bytemark/webdav
 container_name: webdav_server
 restart: always
 ports:
 - "${WEBDAV_PORT}:80"
 environment:
 - AUTH_USER=${WEBDAV_USER}
 - AUTH_PASSWORD=${WEBDAV_PASSWORD}
 volumes:
 - "${HOST_DATA_PATH}:/var/lib/dav/data"
 # 環境変数からユーザーIDを指定して権限問題を回避
 user: "${PUID}:${PGID}"

これの変更部分は .envで以下。

# WebDAV 認証情報
WEBDAV_USER=user1
WEBDAV_PASSWORD=your_secure_password

# 接続ポート
WEBDAV_PORT=8080

# ホスト側のデータ保存先 (外付けHDDのパスなど)
HOST_DATA_PATH=/mnt/external_hdd/webdav_data

動作確認

そしたらupで動作確認。

docker compose up

特にエラーが出なかったら、ファイラを起動する。パス部分をクリックして dav://localhost:ポートとしてやると、ユーザ名とパスワードが求められるので、入力した情報を記述。

ブラウザで開けたらOK。そしたらバックグラウンドで動かす。

docker compose up -d

（おまけ）証明書発行してCloudBeatsでストリーミング再生

CloudBeatsは音楽再生のAndroidアプリ。これでWebDAV選択してストリーミングできる。ただCloudBeatsはHTTPS必須。なのでなんらかの手段で証明書発行が必要。

多分一番楽なのは、Cloudflare Tunnelでつなぐ。常にインターネット接続になってしまうが、まぁ音楽ファイルの再生くらいならそんなに気にもならないのでは。

次に楽なのはTailscale。Tailscaleで発行されるドメイン*.ts.netを使ってアクセス。

普通の独自ドメインやインターネット接続前提を頑張るなら、Caddy(リバースプロキシ) + AdGuardHome(LAN内DNS)でスプリットDNS。Tailscaleネットワークでも独自ドメインでやりたいならこれ。この設定はけっこう頑張る。

/android-cloudbeats-qnap-nas-cloudflareで外でnasの音楽をストリーミングオフ/

メモ大事

Geminiの提案が意味不明かつ、bytemark/webdavのdocker-compose.ymlも完全に妄想を出してきて時間を無駄にした。というか、以前にブックマーク同期のfloccusで既にWebDAVサーバたててたの完全に忘れていた。最初から自分の書いた記事を参照すべきだった。

/floccus-webdav/

本格的にLinuxサーバを使い始めた

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

長いことIntel Mac mini 2018をメインの自宅サーバとしてきたが、今メインサーバの座をLinuxを入れたThinkPad L390にうつしつつある。ThinkPad L390は2018年頃のモデルなので、Mac miniと同世代だ。実際CPUもCore i5-8265Uと第8世代だしね。

NASを潰した

既存のサーバも動いている中で、なにをもって本格的にというかの定義は難しい。

とりあえず、家にあったNASの電源を落として、データをそっくりうつし、いくつかのアプリをセルフホストで常用している。また、LAN内DNSやリバースプロキシも入れた。コイツを落とすと家の中のネットが落ちる。ついでにDNS-01チャレンジでLAN内なのに証明書更新などもしている（これは正直馬鹿らしいと思ったがブラウザがそれを要求するので仕方がない）。常時稼働が前提となっている。自作アプリのホスティング先にもなっている。

なのでまぁ、本格的に運用している、といってもよいのではなかろうか。

また、サーバの仕事のみならず、YouTubeの垂れ流しなんかもしている。これは4Kディスプレイに繋げる格好だ。まぁ例によって音一つ出すのにもハードウェア周りの調整は必要になったが、今のところ解決不能な問題には直面していない。

Linux Mint Xfce 22.3を導入

ディストリビューションはLinux Mint Xfce 22.3にした。Ubuntuじゃないの、と思われるだろうか。しかし今のUbuntuは重かろう。昔のマシンを復活させるには向かないのではないか。また、今のGNOMEやWaylandをあまり好きになれなくて、xfceを使いたいというのもあった。また、試した時はZorin OSからLiteが消えてしまっていたので、そこそこメジャーどころでLinux Mint Xfceとなった感じ。今はLiteも復活しているので、折を見て試したい。

そもそもサーバにGUIがいるのか？と思われるかもしれないが、ホームサーバとしてはGUIはあったほうが断然よい。というか、普通にYouTube流すとか動画流すとかやるよ。仕事じゃないんだから。それにGUIは便利なもので、スペックがカツカツとか画面がないとかならともかく、普段遣いではあったほうが便利なものだ。

それに、実際使ってみるとXfceは非常に軽量で、4GB RAMでもほとんど困らないと思う。まぁ8GBくらいはあったほうが用途は広がるけどね。かなり多くのことが、4GBでもさばけるよ。

ま、そう言いつつ32GB RAMをぶっ刺したのだが…しかしマジで8GBを越えたことがない。まぁこれから色々入れていったら超えるだろうが、実用上は16GBあればまず十分ではないのかな…。多分それ以上使うような用途になると、CPUのほうがボトルネックになる気がする。

HWはThinkPad L390

なにしろジャンク、2018年のLenovo ThinkPad L390で、CPUはCore i5-8265Uとなっている。

第8世代はラップトップにとっては大きな節目だ。というのも、ここからようやくIntelが舐めプをやめて4コアCPUをラップトップに搭載し始めたので…。それもこれもRyzenのおかげやで。サーバマシンはなんだかんでスペックも重要なので、個人的にはN100のミニPCよりもこの世代のジャンクを漁ったほうがいいと思っている。

なによりラップトップは画面、キーボード、そしてバッテリー（！）が全部盛りの人類の叡智。まぁバッテリーはしばしば切れているのだが、割と80%くらい残っているのもよくあるし、そこは運かな。個人的にはバランスよくできていると思うので、サーバマシンとしての活路を見出すべくジャンクPCを仕入れていたら気づいたら30台越えてしまい、検証がまったく追いついていないので、さすがに今はこれ以上の購入を控えている(^_^;)

で、特にThinkpad L390をメインサーバマシンとして選んだのは、トータルのバランスが良かったからだ。裏蓋開ければCMOS電池までアクセスできるなどメンテナンス性が良い。なによりメモリが換装できる。

当たり前のようだが、そうでもない。この時代は主にAppleのせいだと思うが、メモリをソルダリングするという悪習が流行っていた。なので、X280は上位モデルのはずだが、やや地雷みがある。LANポートやら機能を削ることがイケてるとされた、2010年代のまやかしが極致だった時代。

なので、CPUは2コアになるが、サーバとしてはThinkPadならX270とか一つ前のマシンのほうが良い、という考えも一理ある。X270はメモリ換えられるしLANポートあるし従来の電源ポートとUSB PDの両方に対応しているし筐体もペラペラしていないなど、良いところがある。

まぁでもやっぱりCPU2コアかー、と思ったところでThinkPad L390ですよ。こちらは第8世代Core i5とメモリ換装の両方を備えたThinkPadということで、今更になってLinuxサーバ母体としての妙味が生まれているように思われる。ただ無線チップがIntelとRealtekでガチャらしい。無事Intelだったが。まぁでもこれは500円くらいでフリマでも手に入る。

まぁとはいえ、ThinkPad X280でも(Core i5で8GB RAM以上なら)別に悪くないし、DELLのLatitudeもあるし、流通量がそんなに多くない印象のL390は別に狙って買うモデルでもない。

温故知新

個人的には10年くらい前に、パーソナルなコンピュータとしてのPCはHWもSWもほぼほぼ完成したと思っている。使えないのはHWが悪いのではなく、だいたいWindowsや無駄飯ぐらいのソフトウェアが悪い。

なので、あの時代のジャンクを漁り、そこにLinuxやFOSS、また自作アプリをのせてやりたいことをやるのは、本当は使えるはずの計算資源を有効に使う、意義あることだと思っている。

なかなか普通の人には手が出ない領域であることも確かだが、AIのせいでAI PCが高くなるというグローバルコメディが展開され、資源危機が囁かれる中で今日も元気に生成AIのインプ稼ぎが大流行という狂った時代の中で、見直される道筋もあるのではなかろうか、などと思いつつ、ボチボチと今後のことを考えている。

<関連記事>

Linux Mint Xfceを入れてからやること

/linux-mint-xfce/

Linux PCとHDMI接続したディスプレイでチラつきの対応

/linux-pc-hdmi-display-flicker/

自宅内のアプリに、同一のドメインで、LAN内とインターネットの外からの両方に対応する（スプリットDNS）構成編

Wed, 29 Apr 2026 00:00:00 +0900

なんのこっちゃという感じだが、自宅サーバのWebサイトに対してドメインでアクセスしてしまうと、LAN内になるのにインターネット経由になってしまう。それはなんだか阿呆みたいなので、LAN内からはLANでつなげたい。

つまりこういうことです。

graph TD
subgraph "インターネット (外からの道)"
A["スマホ (4G/5G)"] --> B["Cloudflare (中継)"]
B --> C["トンネル (暗号化)"]
end
subgraph "家の中 (LAN内の道)"
D["PC / スマホ (Wi-Fi)"] --> E["AdGuard Home (近道の案内板)"]
end
C --> F["Caddy (玄関口)"]
E -->|"近道 (爆速)"| F
F --> G["WordPress / 自分のアプリ"]
style E fill:#f96,stroke:#333,stroke-width:2px
style F fill:#f9f,stroke:#333,stroke-width:2px
style G fill:#bbf,stroke:#333,stroke-width:2px

同じドメインで、LANとインターネットで別々のルートにする。LAN内ではLAN内DNSを使って名前解決する、ってことだね。これによって、LAN内のアプリにhttps://app.example.comでインターネットを使わずにアクセスできるようになる。

IPアドレス直打ちやTailscaleのMagicDNSとかじゃあかんのか？という向きもあると思うが、WordPressなどはサイトドメインにリダイレクトする仕様があったりするためそうもいかないし、そもそもLANとインターネットで２つのブックマークを作るというのは、なんだかつらいものがある。

ということで、色々頑張った結果、なんかLinux Mint Xfce + Caddy(+Cloudflare) + Tailscale + AdguardHome という構成になって1日かかってしまったんだが、正直ここまで頑張らなくてももっとシンプルにやれる。

構成

基本の構成

順番に考えていこう。外からの通信はみんな大好きCloudflare Tunnel から直通でOK。問題は、LAN内だね。

まずは、LAN内DNSを作って、ルータでそこに向ける。これにAdGuard Homeを使う。AdGuardHomeで特定のドメインを、リバースプロキシのCaddyに向ける。考え方の基本はこれだけ。

graph TD
subgraph "インターネット (外からの道)"
User_Ext["ユーザー"]
Tunnel["Cloudflare Tunnel(cloudflared)"]
end
subgraph "LAN内 (秘密の近道)"
User_Int["自分 (Wi-Fi)"]
AGH["AdGuard Home(案内板: DNS書き換え)"]
Caddy["Caddy(玄関: HTTPSプロキシ)"]
end
subgraph "アプリ群"
App["WordPress / AIアプリ 等"]
end
%% 外のルート (Caddyをバイパス)
User_Ext --> Tunnel
Tunnel -->|"直接ポートを指定"| App
%% 内のルート (Caddyを経由)
User_Int -.->|"① 案内を聞く"| AGH
AGH -.->|"② CaddyのIPを回答"| User_Int
User_Int -->|"③ HTTPSでアクセス"| Caddy
Caddy -->|"④ アプリへ転送"| App
style AGH fill:#f96,stroke:#333
style Caddy fill:#f9f,stroke:#333
style Tunnel fill:#fff,stroke:#333
style App fill:#bbf,stroke:#333

これが基本なので、単にスプリットDNSしたいだけならこれでよい。というか、個人的にはこれで十分だと思う。なんかAIにのせられてゴチャゴチャとやってしまったが、正直それで思ったのは「いらねぇ」だった。

ここから、ちゃんとした証明書の発行と、仮想ネットワークを混ぜるとたいへんになる。色々と肉付けをしていくと複雑になる。

証明書（諸悪の根源）

ちゃんとした証明書というのは、つまりオレオレ証明書ではないということだ。これがあることで、ブラウザからは完全なるお許しを得られるので、なんかマルウェアサイト扱いされたり安全ではない云々などの小言を挟まれてイライラすることはなくなる。

証明書の発行をCaddyは本来サラッとこれをやってくれるのだが、今回はLAN内であるために、必要な80/443を使えない。

ここで、Cloudflareを利用すれば、API使ってゾーン編集して一時的にTXTレコードを作るなどして、証明書の発行ができるプラグインを活用する（DNS-01チャレンジ）。これによって、LAN内であるにも関わらずオレオレではない証明書ができるので、これにはブラウザもニッコリ。警告が消えるよ！やったね、Googleさん。

と、ブラウザはニッコリなのだが僕はかなりイライラしている。やっていることはほとんど形式的で実際的な意味はない。ついでにCloudflareに依存してしまっている…いやこれは別のプロバイダ用のプラグインもあるので、置き換えはできるんだけど。できるけどなんでこんな大掛かりなことに。

まぁ、とりあえずここまでを図示しよう。

graph TD
subgraph Internet ["インターネット (外からの道)"]
User_Ext["ユーザー"]
Tunnel["Cloudflare Tunnel(cloudflared)"]
end
subgraph LAN ["LAN内 (秘密の近道)"]
User_Int["自分 (Wi-Fi)"]
AGH["AdGuard Home(DNS書き換え)"]
Caddy["Caddy(証明書管理 & プロキシ)"]
end
subgraph Cloudflare_Control ["Cloudflare管理下 (DNS-01)"]
CF_API["Cloudflare API"]
DNS_Rec["TXTレコード (一時的な合言葉)"]
end
subgraph CA ["証明書発行機関 (Let's Encrypt等)"]
Verify["レコードの正当性検証"]
end
subgraph App_Server ["アプリ"]
App["WordPress / 各種アプリ"]
end
%% 外のルート
User_Ext --> Tunnel
Tunnel -->|"直接ポートを指定"| App
%% 内のルート
User_Int -.->|"① ドメインのIPを問い合わせ"| AGH
AGH -.->|"② CaddyのLAN内IPを回答"| User_Int
User_Int -->|"③ HTTPSアクセス (警告なし)"| Caddy
Caddy -->|"④ アプリへ転送"| App
%% 証明書発行 (DNS-01) のプロセス
Caddy |"⑤ APIトークンで認証"| CF_API
CF_API -- "⑥ 証明用のレコードを設置" --> DNS_Rec
DNS_Rec -. "⑦ 外部から合言葉を確認" .-> Verify
Verify -- "⑧ 証明書を発行" --> Caddy
style AGH fill:#f96,stroke:#333
style Caddy fill:#f9f,stroke:#333
style Tunnel fill:#fff,stroke:#333
style App fill:#bbf,stroke:#333
style CF_API fill:#9cf,stroke:#333

2010年代以降、インターネットは同じことをどれだけ複雑にやれるか選手権が全世界で開催されたため、その煽りを受けた格好だ。

単に複雑なだけではなく、これはむしろ脆弱になっていないかと思う。Cloudflare（等のプロバイダ）に依存するために、攻撃対象が純粋に増えている。何してるんだ俺は。俺が俺の作ったアプリを俺のLAN内で使うのに、Cloudflareという第三者をとおすほうがセキュアであるというのはどういう理屈なんだ？そんなに俺は俺が信用できないのか？どうなんだ俺？

俺ではなく今のインターネットの問題である。というか根本的にLAN内で完結することのはずなのに、少なくとも証明書の更新時にインターネット接続が必要になっており、オフラインになると維持できない仕組みだ。まぁさすがに前提条件を考えるとインターネットの維持まで疑っても仕方ないかもしれないが、しかし必要もなくインターネットの外に出ることのどこがセキュリティだというのか。

まぁ一応、なにかあったら仕組みを止めれば良いので、最低限のラインは超えていて依存とは言い切れない、くらいに考えてはいるが、いったいマジで何をやっているんだという気持ちが強い。そもそもCloudflare Tunnel使っとるやないかいと言われそうだが、これは単に玄関で、いざとなればVPS + frpなどで即座に別の玄関に変えることは可能（後述するTailscaleがあればそれも使える）だし、実際似たようなことを以前のConoHa大規模障害時にやったこともあるので、依存ではないと考えている。だがAPIを使った証明書発行と更新というのはなぁ…。

ちなみにSSL証明書を発行するタイミングで、透明性のためにドメインを作られたことが公になってしまうため、即座に攻撃対象となるらしい。セキュリティ……？

Tailscaleの追加

ここまででもかなり嫌になるが、なんか別の用途があったりしてTailscaleなど使っていると、構成はさらに複雑になる。TailscaleのDNSをAdGuard Homeに向ける必要があるからだ。また、MagicDNSを使えるのはよいのだが、それゆえのハマり要素もある。

結果、最終的に以下の構図になる。インターネット経由の経路と、Tialscaleのネットワーク経由でAdGuard HomeとCaddyを使う経路ができるわけだ。

graph TD
subgraph Internet ["1. インターネット (外からの道)"]
User_Ext["ユーザー"]
Tunnel["Cloudflare Tunnel(cloudflared)"]
end
subgraph Tailscale_Mesh ["2. Tailscale Mesh (仮想ネットワーク)"]
direction TB
TS_DNS["Tailscale DNS / MagicDNS(Nameserver: AdGuard IP)"]
User_Int["自分 (PC/スマホ)Tailscale ON"]
end
subgraph Linux_Server ["3. Linux Server (cimon)"]
direction TB
AGH["AdGuard Home(DNS書き換え実行)"]
subgraph Docker ["Docker"]
Caddy["Caddy(HTTPSプロキシ / 証明書管理)"]
end
end
subgraph Mac_Mini ["4. 別マシン (mac-mini)"]
App_Remote["WordPress / AIアプリ"]
end
subgraph Cloudflare_CA ["5. Cloudflare & CA"]
CF_API["Cloudflare API"]
LE["Let's Encrypt"]
end
%% 外のルート
User_Ext --> Tunnel
Tunnel -->|"直接ポート指定"| App_Remote
%% 内のDNSフロー
User_Int -.->|"① DNS問い合わせ"| TS_DNS
TS_DNS -.->|"② 名前解決を丸投げ"| AGH
AGH -.->|"③ CaddyのIPを回答"| User_Int
%% 内の通信フロー
User_Int -->|"④ HTTPSアクセス"| Caddy
%% Caddyからの転送 (MagicDNS vs IP)
Caddy -->|"⑤ Proxy via MagicDNS"| App_Remote
Caddy -.->|"⑤ Proxy via Local IP(自分自身のループバック回避)"| AGH
%% 証明書取得 (DNS-01)
Caddy |"⑥ TXTレコード操作"| CF_API
CF_API |"⑦ 検証"| LE
style AGH fill:#f96,stroke:#333,stroke-width:2px
style Caddy fill:#f9f,stroke:#333,stroke-width:2px
style TS_DNS fill:#9cf,stroke:#333,stroke-width:1px
style Tunnel fill:#fff,stroke:#333,stroke-width:1px

これにより以下の3つの経路が並立している。

インターネット経路
Tailscale経路
LAN内IP直打ち経路

正直どうかと思う。

しかし、先の証明書と違い、こちらのTailscaleは仮想ネットワークの構築という明確な役割があるため、別用途で必須となっているのであれば、これはやらざるを得ない。

所感：そもそもやるべきか？

ここまで少しずつ段階を書いたのは、納得できる範囲でやるべきだからだ。全部盛りでやってしまうと、どっかぶっ壊れたときにどうしていいかわからなくなる。そもそも、本質的に必要のないことはやるべきではない。

まぁしゃあないので毒を喰らわば皿までで、第三者に自宅の経路を保証してもらうという謎の苦行まではするとして、個人的にはAdGuard Home + Caddyでいいと思う。ブラウザの警告も気にしないならDNS-01チャレンジもいらん。でもここまできたら全部やってもいんじゃね感。普通につかえるとストレスフリーなのはまぁそう。

が、これと別にTailscaleを導入している場合、考えるところが増える。Tailscaleが入ると、そこで名前解決があるので、*.ts.netでいいなら、実はAGHはいらない。ただ今回は外からのドメインを使うという要件があるため、AGH + Tailscale + Caddyというカオスになるのだが…。

そもそもスプリットDNSなんてやらないほうがよかった説も有力である。IPアドレス直打ちはしんどくね問題はあるが、それだけならMagicDNS使ったっていいし。警告なんて知らねぇっていってもいいし。気分の問題の側面が大きい。まぁWordPressのようにサイトドメインの概念があると、ドメインは固定になってしまうため、、同一ドメインで別経路を取るのは価値があるのだが、そこまでして…とも思える。

じゃあなぜお前はやったのか？AIに相談してたらなんかこうなってしまった。AIというやつはそうなるんだ。ベストプラクティスのツギハギをして、本来必要だったものから遠ざかっていく。途中で「絶対こんなのは必要ない」と思ったが、エラーが出ているのは腹立たしいので最後までやってしまった。

自宅サーバってレベルじゃねぇぞ、などという気もしつつ、この記事は、どこが分岐点だったのか？をまとめたものに近い。そういう意味じゃよく理解できたと言えるかもしれないが、疲れた…。AIが過剰に重視してしまう指標と、無視しがちな指標が存在するんだね。それらの指標は、現実上の重要性とたいてい一致しない。これは 「AI」を「社会」や「組織」に置き換えても成り立つんだな。

まぁでも、僕の性格を考えるとどうせそのうち手を付けた気はする。ブラウザの警告うぜぇとなって、しかしTailscaleのドメインに依存するやり方はいやだろうし、結局スプリットDNS構成になったんじゃないかなぁ…。じゃあいいのか…。と、ここまで書いただけでなんかもうお腹いっぱいなので今回は構成のみ。具体的な手順は次の記事で。

<関連記事>

/vps-caddy-wordpress-cft/

/yaranakuteiikotobakarishiteiru/

やらなくていいことばかりしている

Linux Mint Xfceで外付けハードディスクをマウント

Sun, 26 Apr 2026 00:00:00 +0900

やること

Linux PC, Linux Mint Xfce 22.3をサーバとしている。これにロジテックのガチャベイ経由で外付けハードディスクを常時マウントしたい。

基本的には /etc/fstabを編集するいつものあれなのだが、GUIで進めていく。

環境

Lenovo ThinkPad L390
- Core i5-8265U
- 32GB RAM
Linux Mint Xfce 22.3
ロジテックガチャベイ LHR-4BNHEU3
- WD 2TB HDD
- TOSHIBA 2TB HDD
USB 3.1接続

手順

最初にマウントポイントを作っておく。たとえば/mnt/hdd1とか。

sudo mkdir /mnt/hdd1

ディスクツールを起動する。GUIだが

ディスクが確認できる。

各ディスクで歯車があるので、それをクリックして「マウントオプションを編集」を選択する。

ユーザーセッションのデフォルトをOFFにする
「システム起動時にマウントする」にチェックを入れる
マウントポイントのパスを指定する (ここでは /mnt/hdd1）

OKする。

再起動して、マウントポイントにマウントされていることを確認する。確認したら、パーミッションを修正する。

sudo chown $USER:$USER /mnt/hdd1

適当にファイルを作成できることを確認する。

ちなみに/etc/fstabをcatすると設定されていることが確認できる。

以上。

<関連記事>

Linux Mint Xfceを入れてからやること

/linux-mint-xfce/

Linux Mint Xfce + AdGuard Home (+Tailscale) を構成する

Thu, 23 Apr 2026 00:00:00 +0900

今回はLinuxサーバにAdGuard HomeでLAN内DNSをたてる手順のメモ。ついでにTailscaleを使っている場合はもう一手間かかるのでそれも書く。

環境

Linux Mint Xfce 22.3
- ThinkPad L390
AdGuardHome
ついでにTailscale

Tailscaleを利用している場合は設定がちょっと増えるのでおまけ。

AdGuardHome

53番問題がややこしいのでLinuxでやるのが望ましいのかなと思った。ネットワークを直接使うようなものなので、Dockerよりネイティブでやるほうがいいかなとも思う。

ポート53を開ける

まずLinux Mint Xfceというか、Ubuntu系列だと、53番はすでに使われているかと思う。以下のsystemd-resolveはUbuntuの機能であるらしい。

$ sudo lsof -i :53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 589 systemd-resolve 14u IPv4 8130 0t0 UDP _localdnsstub:domain 
systemd-r 589 systemd-resolve 15u IPv4 8131 0t0 TCP _localdnsstub:domain (LISTEN)
systemd-r 589 systemd-resolve 16u IPv4 8132 0t0 UDP _localdnsproxy:domain 
systemd-r 589 systemd-resolve 17u IPv4 8133 0t0 TCP _localdnsproxy:domain (LISTEN)

FAQ（よくあるご質問） | AdGuard DNS Knowledge Base

こいつを殺す必要がある。殺す手順はドキュメントのとおりなのだが

sudo mkdir -p /etc/systemd/resolved.conf.d

そんで/etc/systemd/resolved.conf.d/adguardhome.confを作成する。で、作成したファイルに以下を記述する。

[Resolve]
DNS=127.0.0.1
DNSStubListener=no

以下を実行。

sudo mv /etc/resolv.conf /etc/resolv.conf.backup
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

sudo systemctl reload-or-restart systemd-resolved

これでもう一度53番を見たら何もないはず。

インストール

Getting started | AdGuard DNS Knowledge Baseに従う。

ポート53を開けていれば、問題なく進むはず。

ルータの設定だけ、DNSサーバをLinuxマシンのIPにする。ここで、ルータ側でMACアドレスでIPアドレス決め打ちの設定をするとよい。このへんの設定はルータによるので割愛。

ファイアウォール

他PCからアクセスするのにポートを開ける。

# DNS問い合わせを受け付けるために必須（UDP/TCP両方）
sudo ufw allow 53

# Web管理画面にアクセスするために必要
sudo ufw allow 80/tcp

# 設定変更を反映
sudo ufw reload

80はAdGuardのダッシュボード。

確認

LAN内のPCから以下を実行して結果を見る。

nslookup doubleclick.net サーバのIPアドレス

これは広告配信ドメインなので、これが無効化されるはず。以下のような結果になる。

Server:		サーバのIP
Address:	サーバのIP#53

Non-authoritative answer:
Name:	doubleclick.net
Address: 0.0.0.0

(optional) ダッシュボードのポートを変更する

ダッシュボードがポート80という特等席を使ってしまっている。多分他にもっと大事なのに譲ったほうが良い。僕の場合はCaddy使うので変更が必要。

/opt/AdGuardHome/AdGuardHome.yamlを編集する。

http:
 address: 0.0.0.0:80 # ここを 適当なポート に変更

再起動する。

sudo systemctl restart AdGuardHome

ufwも設定。

sudo ufw allow ポート番号

他端末からブラウザで http://IPアドレス:ポート番号でダッシュボードを開けたらOK。

ああ…次はTailscaleだ…

Tailscale

Tailscaleを使っている場合、Tailscale側でもDNSの設定をする必要がある。そのままだとnslookupの実行結果は以下のようになるはずだ。

> nslookup doubleclick.net
Server:		100.100.100.100
Address:	100.100.100.100#53

Non-authoritative answer:
Name:	doubleclick.net
Address: 142.251.23.100
Name:	doubleclick.net
Address: 142.251.23.102
Name:	doubleclick.net
Address: 142.251.23.138
Name:	doubleclick.net
Address: 142.251.23.139
Name:	doubleclick.net
Address: 142.251.23.113
Name:	doubleclick.net
Address: 142.251.23.101

TailscaleのDNSが使われてしまう。なので、LocalにたてたAdGuard Homeに向ける設定が必要。

TailscaleのWebコンソールにログインして、AdGuardHomeをインストールしたLinux PCのTailscaleのPrivate IPを調べる。

で、それをTailscaleのDNS設定より、メモしたIPアドレスをnameserverとして利用するように設定する。

Add nameserverの「Custom…」よりIPアドレスを入れて、Override DNS serversをONにする。

これで、以下のようになるはずだ。

> nslookup doubleclick.net
Server:		100.100.100.100
Address:	100.100.100.100#53

Non-authoritative answer:
Name:	doubleclick.net
Address: 0.0.0.0

AdGuard Home側の設定

外からつなげる場合、AGHのDNS書き換えを192.168.x.xではなく、TailscaleのIPアドレスにしないといけない。

Androidの場合の設定

Androidの場合、Tailscaleアプリを入れてもConnectedでDNSに到達しないと怒られたりする。以下より、プライベートDNSをOFFにする。

Android: 設定＞ネットワークとインターネット＞ プライベートDNS

所感

なんだかんだで手こずった。

ちなみに僕はこの後Caddyを入れて、同一ドメインでLAN内と外からで同じアプリにログインできるようにする予定。

<関連記事>

Linux Mint Xfceを入れてからやること

/linux-mint-xfce/

/thinkpad-l390-linux-mint-22-3-xfce/

GeminiもChatGPTも阿呆過ぎるのでチャットはローカルLLMで良いとなっている

Tue, 21 Apr 2026 00:00:00 +0900

特にGeminiが顕著なのだが、推論のリソースをケチっているのか出力設計がタコなのかその両方なのか知らないが、とにかく出力が深刻に愚かであると思う。応答速度だけは確かに早くなったが、その出力がゴミなので使う気になれない。いやまぁ料理の相談くらいならできるし、検索エンジンの代わりにはなるのだが、それ以上にならない。

対話はまったくする気にならない。Geminiはキーワードを拾って妄想を繰り広げているような感じで、2,3もチャットを往復すると本当にひどい。最初の話題で出たキーワードを永遠にこすり続けられるのには辟易とする。ChatGPTはなんだか壁の向こうにいる弁護団に向かっていかに自分の出力が法的に問題ないかをアピールしているような感じだ。

これは主観だが、僕はAIについては各々が主観で語るしかないと思っている。一応ベンチマークはあるものの、AIの性能を測るというベンチに信を置いていない。というのも、AIの性能は人間のように定義が難しいからだ。人間の能力の定量化について成功したという人は少ないと思うが、AIについても同じことが言える。何を持って良いとするのか、誰にもわからない。

別にAIが特別なわけでもない。音楽にも物語にも絵画にもベンチマークは存在しない。あってもそれは本質的に価値を反映しない。取引時価はあってもそれは価値ではない。ゴッホの絵はゴッホが死んでから自律的に成長して評価されたのではない。同じ話だ。質は本質的に量で語れない。

まぁでもこれだけだとあんまりなので、事実として、僕は課金しているGeminiではなく、自宅のRyzen AI Max+395で動かしているローカルLLMとチャットするようになった、ということは書いておこう。

Qwen3.5-27BのQ4で、検閲回避とされているモデルだ。犯罪やNSFWの話もできるとされている。犯罪の話はしていないが、NSFWについてはプロンプトの相談をしてみたら本当に出力された。おっぱいの単語に過剰反応してポリシー違反にするChatGPTとは雲泥の差である。気兼ねなく話せるのは非常に良いことだ。

応答速度は3tokens/s程度でかなり遅いのだけれど、使えないほどではない。ブログでも書いている間に返答はくる。個人的には速度はあまり重視していない。むしろ多少ゆっくりのほうがよい。こちらも考えをまとめないといけない。

とはいえ、プログラミングにおいては現状ローカルLLMよりも明確に良いため、そのために課金は続ける…続けるというか、昨年末のGoogleのAI Proの半額セールで年間契約してしまったよね。だからAntigravityは使っている。まぁここ1,2か月の改悪はひどいものだが、一応まだ使えないほどではない。まぁ現時点でこれだから、果たして今年が終わる頃にどうなっているのかは恐ろしさもあるが…。今の国際情勢などもかなり不透明さを増している。今とはまったく違う状況になっているかもしれない…。

一方で、ローカルLLMはとりあえず変わらない。昨日できたことが今日できるという一番嬉しい当たり前という品質がここにある。当たり前が一番難しい。当たり前は当たり前じゃないんだな。今のところはコイツが希望だ。最後の希望かもしれない。なんとか使いこなしていきたい。

<関連記事>

/ryzen-ai-max-395-128gb-ram/

自宅サーバーは現実枠

Sat, 18 Apr 2026 00:00:00 +0900

クラウド全盛のこのご時世だが、このブログは現在自宅サーバで稼働している。つい先日まではConoHaのVPS上で稼働していたのだが、一週間で3度の大規模障害という国内VPSとしては未曾有のやらかしをしてくれたために、さすがに耐えきれず急遽自宅サーバに退避させた。

ConoHa VPS落ちすぎ問題

/conoha-vps-down/

その後の対応もナシのつぶてであったため、不信感はピークまで高まり、現在も自宅サーバのままでいる。元々GMOのサポートに期待していたわけではないが、それも許容範囲の安定性があったからヨシとしていたのであって、一週間で数日不安定のVPSなら自宅サーバのほうがマシである。そんなものに金を払う理由はまったくない。

…といっても既に3年契約であと1年4か月くらい残っているんだけどね…それでも戻る気にはまったくなれないね。

実際、自宅サーバのほうが快適だ。通信帯域はJ:COMのうんこ上り回線であるものの、所詮流行らないサイトであるし問題ない。むしろ、サーバのスペック上昇のほうが随所に効いているかんじで、パフォーマンスはむしろよくなったと思う。特に記事を編集していると恩恵を感じられる。

それでもまぁ自宅サーバで定期的に再起動なるなどはあるために、安定性の観点でVPSにしていたんだけれどその安定性でVPS大敗北ということになったので、VPSにする理由がほとんどなくなってしまった。

とはいえ自宅回線でNAT越えは色々とハードルが高いので、そこは俺たちのCloudflare Tunnelに結局お世話になっている。まぁCloudflareも去年から連続して大規模障害を起こしてくれて、特にメール一つもなく、カッコつけたポストモーテムを出しただけであったから、使いたくはなかったのだけれど、この際仕方がない。

なに、Cloudflare Tunnelが落ちたら、そのときはCaddyとTailscaleを入れっぱなしのConoHaに向ければいいんだ。さすがに同時に落ちるということはあるまい…ないよね……？それだったら多分僕んちのブレーカー落ちる可能性のほうが高いかなと思うわ。

まぁでも、個人レベルでこんな風に複数のエンドポイントを玄関として自由に切り替えられる状態になった、という点に関しては、よくなったのではなかろうか。実際このサイトも、障害が長引くのに嫌気がさしたからとはいえ、だいたい1,2時間もあればVPSから自宅サーバに退避して復旧完了したんだけど、これはまぁすごいことだと思う。

10年前にそんな芸当を個人がやるのは非常に難しくて、それで僕はこんな記事を書いていた。

これは2015年当時、使っていた小型サーバーが逝ってしまったのを契機に、専用のNASを買うようになったときの心境について綴ったものだ。さらにWebサイトならばVPSがあるしなぁ、ということも書いている。ここには明確に、オンプレや自宅サーバについて、もうそんな時代じゃなくなった、という心境をありのまま書いていた。確かにあの時、時代が変わったことを感じていた。

あれから10年！また、時代た変わった。自宅サーバーはもはや浪漫枠ではない。自由、プライバシー、データ主権、そしてハイパフォーマンスでセキュアでしかも使いやすく、しかも激安という現実の選択肢として再浮上している。

この理由は大きくわけて、以下の4つがある。

トンネル技術によってネットワークの設定・運用が劇的に楽なったこと
仮想化技術でポータビリティが向上したこと
省電力でサーバとして十分なスペックをもったハイパフォーマンスなPCが溢れていること
AIという期待のルーキーの参入

特に4つめが重要であると思う。AIは以下の4つの仕事をしてくれる。

自宅サーバのアーキテクチャの相談、やっていはいけないことのアラート
あまり知られていないFOSSを探し出したり、そのアーキテクチャや使い方を、自分のレベルにあわせて解説してくれる
困ったらトラブルシューティングを手伝ってくれる（これは役立たずのことも多い）
そもそも自分でも作れる

「こういうサービスない？」でAI「こういうOSSがありますよ！」はマジで助かる。しかも全てを試す時間もないなかで、こういうアーキテクチャ、ユースケースを考えている、まで言うと「そんならこれは！」と提案してくれる。正直そのまま使うことはあまりないんだけれど、それでも参考になる。

アーキテクチャに限らず技術的な相談はやや注意で、少なくともAIのいっていることを鵜呑みにしてはならない。AIが何を言っているのか理解できて、疑問があれば即座に突っ込める力量は必要。インフラ周りではAIの無能さは相当なものになるので。それでも使える。逆に言えば無能ポイントを抑え込んで使えばかなり助けになる。

お陰様で、うちには今30超えるサーバー用アプリケーションが起動中だ。

このオフィスソフト自体、セルフホストしたNextcloud上のWebアプリで稼働している。つまりやろうと想えば複数人で編集なども可能だが当然のようにこのネットワークには僕しかいないでそんなことにはならない。一応複数PCを使った一人人生ゲームのようなものすごく暇な時にやるような遊びはできなくもない。

まぁでもこんな風にスプレッドシートで管理していると、アクション要素も出てくる。で、作った一例が最近始めている備蓄防災のリストだ。

これによって、各在庫のリストスマホで写メとって記録し、何があって何がないかは備蓄一覧を見てじっくり考えられる。ついでに買い物履歴を登楼することで、ある商品の価格の推移を見てインフレが進んでいるかを判断することもできる。しかも爆速だ。何しろLAN内前提である（検索だけでもグローバル公開するアーキテクチャは考えている）。これはまさに僕がやりたいことを体現するために作ったもので、市販のSaaSにはないだろう。

ま、どうしても新しいことをやりたいならAIに読み込ませれば「何が足りないのではないか？」とか言わせることもできるかもしれないね。なにしろデータベースでパスタがどれくらいあって賞味期限は…とか、鯖缶は…とかわかるのだから。まぁ正直何を言われるかは見当つくし、自分で判断することだから、どうでもいいが…。

あ、今ある缶詰の有効な使い方とかアピールできたら面白さあったりするかな。いや、贅肉か…。こんなふうにAIがあると色々やってみたいことが思い浮かぶんだけど、まぁ基本罠なので、愚直にただ自分のやりたいことを解剖して作るに限る。

AIによって開発速度が100倍になっているため、望むアプリはガンガン作れる。そしてそのアプリは自宅に置くのが一番良い。インターネットが必要かは慎重に考えて決めるんだね。それだけやりたいことに合わせた最小の認証なら存外楽なもんだ。自分が使うだけなら、Tailscaleで自分用のネットワークを構築するのがてっとり早い。軽めのWeb公開なら.envにハッシュ化したパスワードを置くだけでもまぁ使い物になるだろう。

自宅サーバーは忘れていたコンピュータの楽しさを一寸思い出せてくれる。だが楽しいだけではなく、極めて機能的だ。クラウドと違っていらないものはあまりないけど、いるものは全部ある。サーバーは面白い。こんな面白いものは、雲の上より自分の部屋に置くべきだ。

<関連記事>

/antigravity-app/

サービス品質保証制度 (SLA)｜VPSならConoHa

【Linux PC再生計画】用途ごとのスペック

/linux-pc-3/

ConoHa VPS落ちすぎ問題

Sat, 28 Mar 2026 00:00:00 +0900

3/30にまた落ちくさっていたので、自宅サーバに移らざるを得ない（移った）

当サイトはConoHa VPS上に構築しているのだが、なんだかまた落ちていた。この前も長いこと落ちていたので、またかって感じ。

直前アナウンスの緊急メンテナンス、からの障害

お知らせ見ると、こう。

　開始日時　：　2026年03月26日(木) 11時30分
終了日時　：　2026年03月26日(木) 18時00分

当日に「緊急メンテナンス」の一言で済ませていい長さじゃないんだよなぁ。もう障害だろこんなん。ってかメールくらいしてくれ。Cloudflareもそうだけどなんでメールしないの？メール知らないの？

ちなみに前日にも障害起きていた。

だからメール出してくれ。なんで見に行かないといけないんだよ。

ちなみにアカウント設定見るとメールの設定はあるんだが

ニュース配信で「受け取る」ってやってるけど、どうでもいい情報やアンケート依頼はメールしてくるが障害情報は一切送ってこない。なんなの？

さらにお知らせ一覧見てるとかなり酷い一覧。

マルウェアでも配布したの？

スタートアップスクリプトの脆弱性報告で埋め尽くされている。まぁインストールするソフトウェア側の問題だ、という見方もあるんだが、個人的にはスタートアップスクリプトの提供という考え方自体に問題があるのだと思う。あとカテゴリニュースってなってるけど、まったく配信されてなかったぞ。

イライラしつつ待っていたら、緊急メンテナンスから正式に障害に格上げ。その後復旧まで丸一日経過した。

もちろんメールなし。サイト内告知とXでの報告のみ。障害メール送ったら死ぬんか？

ハリボテのSLA

さてこの連日の大規模障害、当然SLAに反していると思われるだろう。以下に条件がある。

まず適用条件がひどい。

SLA適用申請書(PDF)に必要事項を記入し、当社お客様センターまでメールまたはFAXでお送りください。SLA適用申請は障害発生月の翌月の末日までに完了する必要があります。

自分で申請しろってさ。しかもメールで。そして適用の対象外が以下。

以下の場合においては適用の対象外となります。

・当社が事前に計画し告知した、もしくは緊急で行ったメンテナンス ・お客様が用意したソフトウェアに起因する場合・サービス提供者、利用者でない第三者の作為による場合・付加機能に関するもの（コントロールパネルなど）・障害の発生時刻及び継続した時間をお客様において証明できない場合 ・サービスそのものの仕様の場合（プラン変更時のマイグレーション中、HA機能など）・当社がサービス利用規約に反していると判断した場合・準備期間内のサービスや無料で提供されているサービス・当社が制御不可能な要因（自然災害、暴動、テロ、戦争、政府機関の行為など）・その他当社がサービスの中断と判断した場合

当日に緊急メンテナンス扱いしたのはそういうわけかと腑に落ちるよね。さらにこちら側で落ちたことを証明しないといけないらしいのだが、今回はその落ち方自体がかなり不安定のため、難しさがある。たとえばこういうツイートをされている方がいた。

ConoHa VPSの障害継続中。中途半端に稼働している事で死活監視に引っ掛からずに不具合だすケースが発生して痛い目見た😢 再現テストしづらいケースにより、別の対応が必要な事が判ったので参考にはなったが。。。

— https://x.com/shobu_umemura/status/2037340436394828094?s=20

死活監視に引っかからない落ち方、となるわけだがこの場合は証明できてないねって言うんだろうか。

ただでさえこっちとしては端金返されたところでしょうもないという気持ちなのに、そのうえで1円でも返したくないという強い意志を感じて辟易とする。

こんなハリボテのSLA、ないほうがマシじゃないの。

契約解除を思案中

まぁなんだな、スタートアップスクリプトだのOpenClawだのMCPだのキラキラしたことしてないで、サーバ屋として当たり前のことをちゃんとやってほしい。VPSに安定性以外のこと求めてない。逆に言えば、安定して動いてさえいれば契約やめようかとか思わないのに。っていうか連絡しようよ本当に。自分とこの掲示板に張り出すだけじゃなくて。顧客を馬鹿にしている。

さすがにちょっと考え始めるよな。なんで金払って生殺与奪の権を握られないといけないんだ。自分の基盤が落ちてるなら仕方ないけど、金払った基盤が落ちて何もできず、そして相手はメール一つ出さず知らん顔っていうんじゃ、いくらなんでも屈辱的だ。こういう不誠実を続けてきたから業界全体でSaaS is deadとか言われてるんだろう。SaaSの機能非機能を内製化するのはたいへんだぞとかそういう問題じゃない。責任の問題だ。いやConoHa VPSはSaaSじゃないけどね。

メールサーバをVPSに移す予定を考えていたが、もはやそれどころではない。というか、今までこのサイトでは何度かConoHaをVPSの候補として勧めていたので、そのことで申し訳ない気持ちにすらなっている。実際に4人くらいかな、契約までいった人がいたようなので…。

しかし僕も3年まとめ買いしているんだぜ。障害の真っ最中に「私のリンクから契約すればクーポンもらえます！」ってPRツイートしているエアプ野郎がXでにはいたけど、それとは違う。まだ契約もあと1年半くらい残っていてため息だよ。どうするかねこれ…。

まぁ現実的にすぐ移行というわけにもいかないんだなぁ。なかなか厳しい。特にメールはConoHaのアプリケーションサーバでやっちゃってたけど、今回影響受けていないが、もう心情的に僕のほうこそ1円も払いたくないみたいな気持ちになっちゃってるよね。

いずれにせよ時間はかかっても、移行はしたい。半年から1年くらいかけて、マジで自宅サーバに全部寄せていこうと思う。

<関連記事>

Cloudflareの違和感：サイバー攻撃じゃないからなんなのか

/cloudflare-cyber-attack/

ConoHa VPSで512MBメモリが使えるOS11種類の、初期状態におけるメモリ使用量の比較

Thu, 19 Mar 2026 00:00:00 +0900

ConoHaのクーポンの有効期限が切れそうだった。後学のために、使えるOSの初期状態を調べておこうと思った。

調べた日: 2026-03-09

目的

ConoHa VPSで512MBプランが使えるVPSにおいて、初期状態におけるメモリの利用料を調べる。初期状態になにが入っているのかなどは調べていない。あくまで参考値。と言いつつBSD系列ではfreecolorを入れている。

個人的には、最終的にCaddy, Tailscale, Postfix だけ入れたいと思っている。つまりゲートウェイ、土管、郵便受け。

Linux系

CPUは一緒。そりゃそうか。

[root@vm-9c2cca81-82:~# lscpu | grep -E "Model name|CPU MHz|Core"
Model name: Intel Xeon Processor (Icelake)
BIOS Model name: pc-i440fx-6.2 CPU @ 2.0GHz
Core(s) per socket: 1

あと初回起動はなにか不安定だったので、起動中になってから一回再起動してからログインしている。

あとはメモリだけみてく。

CentOS Stream10

[root@vm-4ca08a09-c8 ~]# free -h
 total used free shared buff/cache available
Mem: 449Mi 147Mi 181Mi 6.5Mi 139Mi 302Mi
Swap: 2.0Gi 0B 2.0Gi

Debian 12.05

[root@vm-9c2cca81-82:~# free -h
 total used free shared buff/cache available
Mem: 455Mi 230Mi 6.3Mi 464Ki 239Mi 224Mi
Swap: 2.0Gi 12Mi 2.0Gi

思ったより重い。

Rocky Linux 10.0

[root@... ~]# free -h
 total used free shared buff/cache available
Mem: 449Mi 131Mi 118Mi 2.0Mi 212Mi 317Mi
Swap: 2.0Gi 31Mi 2.0Gi

AlmaLinux 10.0

[root@... ~]# free -h
 total used free shared buff/cache available
Mem: 449Mi 144Mi 185Mi 3.5Mi 135Mi 305Mi
Swap: 2.0Gi 0B 2.0Gi

Oracle Linux 10.0

Oracleは当然オラクルか。ディストリビューション出してたんやね。

[root@... ~]# free -h
 total used free shared buff/cache available
Mem: 451Mi 147Mi 135Mi 3.5Mi 183Mi 303Mi
Swap: 2.0Gi 0B 2.0Gi

Miracle Linux 9.2

これ知らなかった。国内企業のサイバートラスト社がやっているRHELクローンらしい。

[root@... ~]# free -h
 total used free shared buff/cache available
Mem: 444Mi 122Mi 198Mi 2.0Mi 138Mi 322Mi
Swap: 2.0Gi 0B 2.0Gi

お…スペック的には一番軽量、という結果になっている。9.2だからってのもあるんだろうか。

OpenSUSE 16.0

RHでもDebianでもないLinux。OpenSUSE動かすの初めて。

[root@... ~]# free -h
 total used free shared buff/cache available
Mem: 458Mi 140Mi 161Mi 712Ki 169Mi 317Mi
Swap: 2.0Gi 0B 2.0Gi

値的にはRocky Linux 10.0に近い感じだ。

Arch Linux 20241011

さすがというかなんというか。

[root@localhost ~]# free -h
 total used free shared buff/cache available
Mem: 458Mi 81Mi 295Mi 588Ki 94Mi 377Mi
Swap: 2.0Gi 0B 2.0Gi

BSD系

freeがないのでtopを見る。

AIが無能。

FreeBSD 14.0UFS

俺たちのFreeBSD。使うの15年ぶりくらい。もう何もわからん。正直軽量VPSの限定的な使い方ならアリかも、とは思っている。

last pid: 1169; load averages: 1.51, 0.52, 0.20 up 0+00:00:39 00:25:12
20 processes: 1 running, 19 sleeping
CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 12M Active, 1148K Inact, 52M Wired, 22M Buf, 399M Free
Swap: 1536M Total, 1536M Free

Free 399MiBつよい。

参考までに、freeがないのでfreeっぽいやつを入れてみる。

pkg update
pkg install freecolor

この状態でfreecolor -m -oでどうなるか？

total used free shared buffers cached
Mem: 465 97 368 0 0 0
Swap: 1536 0 1536

なるほど。30MiBほど消費した？

NetBSD 9.3

16 processes: 1 running, 15 sleeping
Mem: 11M Active, 448K Inact, 51M Wired, 22M Buf, 402M Free
Swap: 1536M Total, 1536M Free

Free 402MiB。つよい。freecolor入れられなかった。

OpenBSD 7.4

topを見る。

Memory: Real: 8720K/275M act/tot Free: 196M Cache: 94M Swap: 21M/2054M

8720KiBが実際に使っているRAMで、275MiBはプロセスが将来使うかもしれない値として予約している総量らしい。なのでこれを計算には入れない。Freeの196MiBとCache94MiBが使える容量になり、残りはカーネル占有とのこと。

メモリ使用料の比較表

あくまで初期値の比較であって、実際に必要なソフトウェアを入れればそりゃ数値は変わるわけだから、参考までに。Geminiに表にさせた。

OS名	使用中 (Used)	空き (Available)	合計 (Total)	算出のロジック / 備考
OpenBSD 7.4	8.5 MiB	290 MiB	(488 MiB)	Real actを使用量。Free+Cacheを空き。カーネル占有分が最大
NetBSD 9.3	62 MiB	424 MiB	486 MiB	Active + Wiredを使用量。Free + Bufを空き
FreeBSD 14.0	64 MiB	421 MiB	486 MiB	Active + Wiredを使用量。Free + Bufを空き
Arch Linux	81 MiB	377 MiB	458 MiB	`free -h` の値をそのまま採用。Linux勢で圧倒的最軽量
Miracle Linux 9.2	122 MiB	322 MiB	444 MiB	RHELクローン系で最軽量。9系であることも影響か
Rocky Linux 10.0	131 MiB	317 MiB	449 MiB	10系RHELクローンの基準的な数値
OpenSUSE 16.0	140 MiB	317 MiB	458 MiB	Rockyと同等の実効空き容量
AlmaLinux 10.0	144 MiB	305 MiB	449 MiB
Oracle Linux 10.0	147 MiB	303 MiB	451 MiB
CentOS Stream 10	147 MiB	302 MiB	449 MiB
Debian 12.05	230 MiB	224 MiB	455 MiB	今回の比較対象で最も重量級

所感

Debian使おうかと思っていたんだけれど、ちょっと考えようかな。ArchLinuxを1ヶ月くらい試してみようかなぁ。いや、あえてFreeBSDを試してみようか。

BSD系は、この記事レベルですらAIが無能化するのを目の当たりにした。情報アクセスの観点でBSD系のしんどさはあるなぁと思った。まぁFreeBSDくらいはやってみてもいいかもしれないが。

ってか改めて思うが、ConoHaのWeb UIダッシュボードはかなり使いづらい。裏で人が動いてんのか？ってくらい遅いし、使用中だろうがなんだろうが容赦なくログアウトさせられて操作が止まったように見えるのなんとかなりませんかねぇ…。

追記：ConoHaの非推奨

2026-03-25から03-27に至る障害とその対応において呆れ果てました。さすがにもうConoHaはすすめられませんし、私も移行を考えています。

Evernote/Notion代替: Trilium NotesでインストールからWeb Clipまで

Tue, 17 Mar 2026 00:00:00 +0900

今回取り上げるのは、ずっと記事書こうと思っていて放置していたメモアプリのTrilium Notes。割と使いたい人が多いかもしれないやつだと思う。

Trilium Notesとは。Evernote/Notion代替になるか

Trilium NotesはEvernoteとかNotion代替として出てくる、セルフホストできるFOSS。サイトはここ「Trilium Notes」。使い勝手は昔のEvernoteに近い気がする。昔のNotion並に軽いEvernote。伝統的な階層型管理なのはNotion的かな。

Evernoteは最初全部フラットにしようとして失敗したと思う。ここらへん、スマホではじめで階層型はもう古い！みたいなトレンドがあったような気がする。結果としては、階層型ディレクトリだけが最強だった。

リッチな機能はないし、ユーザも一人専用だけれど、ノートアプリとして欲しいものは全部揃っている。 いらない機能でわかりづらいUIと遅いパフォーマンス、崩れるレイアウトのために課金しなくてはいけない日々とはさよなら。

とはいえNotionはノートアプリというよりもはやデータベースアプリになっているので、Notionの機能をゴリゴリ使っているならそりゃ厳しい。

あと、もしかするとObsidianとどっち使うか考えている人もいるかもしれないが、どちらが良いかはObisidian vs Evernote（Notion）と考え方はほぼ同じになるかなと思う。Obsidianはクライアントベース、ファイルベース、Markdown至上主義な考え方になるし、Trilium Notesはサーバベース、独自データベース、Markdownは基本だけどWYSYWIGにありがちなちょっとキモイ挙動もあるよみたいな感じ。

FOSSの文脈だと、サーバ必須なのとファイルではなく独自データベースのメリデメ（高機能だがサポートの継続が不安）をどう捉えるかになるかと思う。

環境

サーバ
- Intel Mac mini 2018
- Docker Desktop for Mac
Web Clipperを試したブラウザ
- Vivaldi

インストール

インストール自体はいつものようにDocker一発なので取り立てていうところはない。docker使えれば使える。

以下のうち、ポート番号とデータベースを保存するディレクトリだけ編集。

# 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'
 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:-~/保存したいディレクトリ}:/home/node/trilium-data
 # - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro

timezoneのところお麺とアウトしているのはMacで当該ファイルがなかったからかな。

バックアップはこの設定ファイルとディレクトリをまるごとコピーしたらOK。

基本的な使い方

ノートを書いて階層管理する使い勝手。なんかもう本当にシンプルなので、これも特に言うことがない。画面見りゃわかる。わかれ。

こんな感じで僕は「缶詰」や「酒」の管理とかに使っている。タスク管理にも使おうとしていたが、最近は一周回ってアナログ管理になってきたので、これはあまり使えていない。あと確定申告とかその時々のタスクにも使ってるね。

Web Clipperの使い方

結局やりたいのはこれだと思うが、Web Clipperがある。「Trilium Web Clipper」でブラウザに対応した拡張機能をインストール。

ブラウザから、Trilium Web Clipperのオプションを開く。

Trilium server instanceの設定から、http://IP address:portとパスワードを入力する。パスワードは実際に保存されるわけではなくて、一度ログインしてトークンを発行しているみたいだ。実際、SettingsのETAPIを見るとトークンが作られていることがわかる。

これで使えるようになっている。どっか適当なページで挙動を確認する。Gigazine開いたら最初の記事だった「iCloudの無料枠がいつまで経っても5GBから増えないことを確認できる「Is iCloud’s free tier still 5GB？」 - GIGAZINE」をやってみよう。

ブラウザの拡張機能のアイコンをクリックすると選択肢が出てくる。

「Save whole page」を選択すると、Journalにクリップされる。

スクショも保存できる。しかし、表示されている画面分だけなので使い勝手は微妙な気がする。一部分のクリップはSNSとかヤフコメとか見ているときに捗るかもしれない。

検索するとノートがヒットする。ここらへんどれくらい管理するかは人それぞれ。

所感

AI時代になってアプリ開発が劇的に楽になったため、自分用のノート・メモアプリはもう自作したほうがいいんじゃないの？と思うこともある今日この頃だけれど、そうはいってもやはりそれにはスキルも時間も必要。

最初からほしいところがそろっていて、かつWeb Clipperが用意されているのは非常に強力なので、ノート系アプリがほしい人にとっては第一候補になると思う。

本アプリはSQLiteを使って独自データベース設計になっているが、AIでいろいろやりたい観点からは、ファイルベースのほうがいいという意見もあるかもしれない。が、正直そんなやらせることある？という気が個人的にはしている。AIにやらせたい特定のユースケースがあるならば、そのためにアプリを作った方がいいと思う。

メモアプリってのはもっとこう、散逸で適当なもんで、人間にも整理しきれないのが本質ではなかろうか。人間に整理できないもんはAIにも無理。AIならなんかすげぇナレッジ出すらしいじゃんとか夢見たくなるのはわかるが、夢だと思う。

また、継続性の観点から独自データベース設計はややネックにはなるかもしれない。しかし、この手のメモアプリはいろいろ貼りたくなるもので、Obsidian使ったところでどうせ大変になる。画像みたいなバイナリがあると、そのバイナリのパスの管理なども出てくるから、ファイルベースだから大丈夫！とも言えない。パス失って探せないファイルはないのと同じ。ファイルベースも結局ディレクトリ構造どうしているのかわからないと管理できない。

ってかもしサポートが途絶えたなら、それこそAI使ってデータベースから必要な抽出をすればいいと思うんよな。

そんなわけで、個人的にはノートアプリのセルフホストFOSSとしておススメできるかなと思います。

【MinIO】LAN内のセルフホストしたサーバのバックアップの構成を考えている

Wed, 11 Mar 2026 00:00:00 +0900

やりたいこと

最近はFOSSのセルフホストできるアプリケーションサーバはもちろん、AIプログラミングによって自分用のアプリケーションが無数に出来上がっている。稼働中のアプリケーションの数は20-30くらいあるような気がする。また、複数マシンに散らばっているし、できれば今後Linux PCの検証も兼ねて、激しくサーバの移動などもさせていきたい。

そうすると、バックアップ・復元が悩ましい。現在は各マシン・各アプリケーションで個別のバックアップスクリプトやバックアップのワーカを走らせており、なにがなんだかわからなくなってきた。一元化する必要がある。

アーキテクチャ案

全体像

Geminiと「違うそうじゃないこのわからずや」などと相談しつつ、下図のような構成を考えている。

graph TD
subgraph AppServer [アプリケーションサーバ]
direction TB
App[アプリケーション本体]
State[(状態 / SQLite / ファイル)]
subgraph WorkerProcess [バックアップワーカー]
Export[1. エクスポート実行]
Pack[2. アーカイブ化]
Push[3. S3 PUT 転送]
end
App State
Export -.-> State
Export --> Pack
Pack --> Push
end
subgraph Network [LAN / ネットワーク]
Protocol{S3互換プロトコル / HTTPS}
end
subgraph BackupServer [バックアップサーバ]
direction TB
MinIO[MinIO / S3 API]
subgraph FileSystem [物理ストレージ]
BucketA[App-A用バケット]
BucketB[App-B用バケット]
Versioning[世代管理 / バージョニング]
end
MinIO --> BucketA
MinIO --> BucketB
BucketA --- Versioning
end
Push --> Protocol
Protocol --> MinIO

バックアップサーバにはMinIOでS3互換のオブジェクトストレージをたてる。アプリケーションサーバには、バックアップ用のワーカを走らせて、そこからS3互換APIでアプリケーション名を添えて必要なアーカイブPUTする。バックアップサーバはアプリケーション名で分類して保存する。

アーキテクチャの要点

考え方をGeminiにまとめさせた。

アプリケーションの責務: バックアップワーカーは「何が復元に必要なデータか」を熟知しており、自らアーカイブを作成する。バックアップサーバの内部パス（/mnt/sda1/...など）は知る必要がなく、自身の「バケット名」という抽象化された名前だけを知っている。
バックアップサーバの責務: MinIOが受け皿となり、届いたファイルをバケットごとに整理する。ファイルシステム上の物理的な配置や、古いファイルのローテーション（ライフサイクル設定）は、サーバ側のポリシーとして一元管理する。
疎結合な関係: 転送は標準的なS3 APIで行われるため、将来的にアプリケーションを別のホストに移動したり、バックアップサーバの構成を変更したりしても、エンドポイントと認証情報を書き換えるだけで運用が継続できる。

Push型の考え方

大まかにわけて、考え方としてアプリケーションから動くPush型と、バックアップサーバが見に行くPull型があるかなと思う。綺麗にやるならPullかもしれないんだが（AIからはそれを提案された）、現実は汚いので管理が面倒くさいことになると思われた。

アプリケーションには固有の特徴があるものだ。その差分を吸収しようとすれば結局たいへんになる。そもそもバックアップできてなくて困るのはそのアプリケーションなのだから、Import/Exportは基本的にアプリケーションの仕事であるべきだと思う。

ただその保存場所として、よく知られたやり方の倉庫があってほしい。FTPやrsyncだとパスの指定のような倉庫の中身をアプリケーションサーバが知らなくてはいけなくなり、しんどい。ということで、S3互換APIを使えるMinIOを間に挟むのが良いだろう、という感じ。

愚直にアーカイブする理由

この構成だとResticみたいなバックアップツールを使って圧縮したり差分・増分を転送したりするということが考えられるのだが（Geminiにも勧められた）、それはやめた。まぁ使ったことがないので学習コストがかかるというのもあるのだが、原理的な面として、アプリケーションの個別の対応や復元を考えるとややこしくなりそうに思えた。

それに対して、純粋にファイルベースのバックアップならば最悪どうなってもなんとかはなるし、何よりもわかりやすい。通常はネックになる通信帯域もLAN内だから気にしなくていいし、ストレージも家のHDDを使えばいいんだから課金の心配もなく全然余裕がある。

なので、愚直にやるほうがいいかなと思った。セルフホストだからこそできるリッチ構成かもしれない。

所感

まぁやるのはこれからなんだが、頭の中ではうまくいきそうな目途は立っている。アプリケーションサーバとバックアップサーバのそれぞれの仕事と知っていることについて責務を分けたこと、できるだけファイルベースを貫いたことがポイントになる。

ただまぁ、僕が作っているアプリケーションにはAIで大量のデータが生成されるようなものもあるのだが、それについては別で考えたほうがいいかもしれない。アプリケーション自体のデータベースはあまり肥大化しないような設計が求められる。

Mac mini 2018 + Lyrion Music Server(LMS, Logitech Media Server) + Squeezeliteで音楽ライフ

Mon, 09 Mar 2026 00:00:00 +0900

うちはメインデスクトップから一線を退いたIntel Mac mini 2018がホームサーバの中心として鎮座しており、そこからXiaomiのMi TV経由でアンプにも繋がっている。なので、音楽の再生は基本的にこの子でやりたい。ただしその操作は手元のPCにあるやつでやりたい。

何がよかろうとかとGeminiに色々と相談し、結果 LMS + Squeezelite になった。

構成

全体の構成はこのような感じだ。ポイントは、起点となるPC Aから、PC B経由でMi TV、そして最終的にSonyのスピーカー（友人からもらった）に接続することだね。

graph TD
subgraph PCA ["PC A (操作端末 / リモコン)"]
Browser["Webブラウザ / App(Material Skin UI)"]
end
subgraph PCB ["PC B (Mac mini 2018 / サーバー兼再生機)"]
direction TB
LMS["Logitech Media Server(楽曲管理・配信)"]
subgraph AudioOutput ["音声出力プロセス"]
Squeezelite["Squeezelite(再生用クライアント)"]
CoreAudio["macOS Core Audio(OS音声制御)"]
end
Storage[("音楽ファイル群(HDD/SSD)")]
end
subgraph AudioPath ["中継・出力"]
TV["Mi TV(音声ハブ)"]
Speaker["外部スピーカー"]
end
%% 接続とデータの流れ
Browser -- "① 選曲・操作命令 (Port 9000)" --> LMS
LMS -- "② 音楽ストリーム送信 (localhost)" --> Squeezelite
Squeezelite -- "③ 音声信号受け渡し" --> CoreAudio
Storage -. "スキャン" .-> LMS
%% 物理接続
CoreAudio == "④ HDMI/音声出力" ==> TV
TV == "⑤ 光デジタル出力" ==> Speaker
%% スタイル設定
style PCB fill:#f9f9f9,stroke:#333,stroke-width:2px
style LMS fill:#d1e7dd,stroke:#0f5132
style Squeezelite fill:#fff3cd,stroke:#856404
style Browser fill:#cfe2ff,stroke:#084298
style TV fill:#eeeeee,stroke:#666

このめんどくさい絵をサクッと起こしてくれるのはAIの良いところだ。

インストール

Lyrion Music Server

「Getting Started with LMS - Lyrion Music Server」よりダウンロードしてインストール。開発元云々は「プライバシーとセキュリティ」から黙らせるいつもの儀式。

画面右下にNextボタンがあるので、そっから「ローカルフォルダ（曲をスキャンするフォルダ）」とプレイリストを保存するフォルダをそれぞれ指定する。外付けSSDもちゃんと指定できてよかった。

しばらく待つといい感じになる。

時間がかかるので、その間にSqueezeliteの設定にうつる。

Squeezelite

「Squeezelite - Lyrion Music Server」のリンクにあるSourceforgeのバイナリを使う。Intel Macの場合ffmpeg版と無印があるがffmpegで一番新しいやつを使う。ダウンロードした.dmgを実行し、アプリケーションフォルダにコピーする。例によってセキュリティ元云々言ってきて鬱陶しいが「プライバシーとセキュリティ」から黙らせるいつもの儀式。ジョブズ亡き後のこの儀式いつまで続くんだろう。

インストールできたのかどうかよくわからない感じだが、以下のコマンドを実行する。

/Applications/Squeezelite.app/Contents/MacOS/squeezelite -l

これでOutput devicesが出てきたらOK。うちの場合はこんな感じ。

Output devices:
 0 - Mi TV [Core Audio]
 1 - Mac miniのスピーカー [Core Audio]
 2 - Microsoft Teams Audio [Core Audio]
 3 - Splashtop Remote Sound [Core Audio]

Mac mini ->|HDMI| Mi TV ->|光デジタル| -> スピーカーの経路で、デフォルトMi TVにしている。とりあえず接続はOK。

いい感じになる。

Squeezeliteの常駐化

毎回起動するのもつらいので、バックグラウンド常駐化。

nano ~/Library/LaunchAgents/com.user.squeezelite.plist

編集内容は以下。-o以下のデバイス名は、

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.user.squeezelite</string>
 <key>ProgramArguments</key>
 <array>
 <string>/Applications/Squeezelite.app/Contents/MacOS/squeezelite</string>
 <string>-n</string>
 <string>任意のプレイヤー名</string>
 <string>-o</string>
 <string>デバイス名</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>

</dict>
</plist>

/tmp以下は再起動で消えるので、ログを保存したい場合はホームフォルダ以下のパスにしとけってさ。

ロードする。

launchctl load ~/Library/LaunchAgents/com.user.squeezelite.plist

Squeezeliteが落ちたとき

おまかんの気がするが、スーパーよく落ちる。とりあえず応急処置としては以下のコマンドで復活する。

nohup /Applications/Squeezelite.app/Contents/MacOS/squeezelite -n "任意のプレイヤー名" -o "アウトプットデバイスの名前" -s 127.0.0.1 > /dev/null 2>&1 &

アウトプットデバイスの名前は-lで出したやつをそのまま使う。たとえばうちの環境だと以下になる。

nohup /Applications/Squeezelite.app/Contents/MacOS/squeezelite -n "MacMini-Player" -o "Mi TV" -s 127.0.0.1 > /dev/null 2>&1 &

基本的にはlaunchdが救うはずなんだが、うちの環境だとMi TVの電源ダウンとかでなんかエラー出ているのかなぁ。ログ指定したけどなんも出てなかった。

これは現状未解決で、強行的に監視入れるかどうか悩んでいる。

音楽フォルダベースでの管理

僕はライブラリ管理せずにフォルダベースでやっているので、LMSではInterfaceの設定から以下のように「Categories」の歯車より「音楽フォルダーをブラウズする」にチェックを入れる。

この変更により「My music」に「音楽フォルダーをブラウズする」が追加される。

所感

ホームサーバ化が進んでよかった。

ただ現在、音楽ファイルが散らばってしまっている問題がある。というのも、外部接続用途のメディアサーバは別にたてているんだよねぇ。うーん。それというのも、ホームサーバとして鎮座しているMac mini 2018がmacOSで、ストレージ容量が512GBしかないのだけれど、かといって外部ストレージの接続も不安定、またそもそもSMB接続がうんこなど、のNASになりきれない制約による。「Logitech Media Server 最新版 – Plumtown」のようにTS-233にLMSを入れている方もいて、なるほどと思ったが、しかしネットワーク経由になってしまうし、なんだかなぁ。

Mac miniを完全にLinux化できれば諸々の問題も解決するんだろうか。うちのジャンクPC艦隊の中には立派に役割を果たせそうなのもある。しかし純粋に性能が高いのはこの子だし、メインデスクトップのM2 Pro Mac miniとユニバーサルコントロールにより標準機能で繋がれるという強みもあるので、当面はもうちょっとこの構成で運用を考えていこう。

脱Dropbox再考: そもそも同期は必要か

Wed, 04 Mar 2026 00:00:00 +0900

この前Dropboxのプレミアム会員の権利が終わった。2020年から6年続けていたらしい。2020年に31,680円で3年分まとめ買いしたのと、2023年にAmazonで29,800円で購入していた。今はもうこの価格で出ることはないだろう。なので6万円ほど（月額約860円）だが、最後の1年はほとんど使っていなかったので、あながち得したともいえない。長期割引の罠にはまってしまった感じはする。正直なきゃないでよかった。

ただ、Dropbox自体は嫌いなサービスではない。むしろ個人的には好きですらあった。最近アカウントBANの騒ぎがあったのを見た時はちょっと悲しかったけど、全体的には良いサービスだと思う。

Linuxでも使えるし、Macでは文字コード正規化問題のようなニッチだがクリティカルなところも対応していたし、スクリーンショット横取りなんかは気が利いていたし、カメラアップロードも便利だし、アプリの使い勝手もまぁ悪くないし、復元機能などはかなり強力で何度か助けられたし、なにより同期という単純ながら難しい課題の精度を着実に上げていた。

Dropboxほどの機能はOSSやNASでは恐らくだいぶ厳しくて、僕はQNAPのNASについてきたQSyncという同期アプリを今は使っているが、正直安定性はDropboxに及ぶべくもない。大量のファイルについて読み書きすると平然と取りこぼすので、あまり信用できない感じだ。OSSではNextcloudやSeafileもあるが、あまりマジメに試していないものの、運用者の記事を調べるとやはり苦労していそうな感じがある。

そこへいくと、業務として同期が必要なのであれば、Dropboxは安心して高いなりの仕事は任せられるのはそうだと思う。本当に必要ならね。

個人や中小規模において、同期に毎月1,500円払えるかと言われると、それはちょっとどうかな。正直900円くらいでも、よく払っていたなぁと思う。結局どこまでも経費だからねぇ。正直ほとんどオーバースペックと思われる。たいてい、少しの工夫でどうにかなりそうなんだよなぁ。

そして厳しくなるばかりのアカウントBANリスク。バックアップがわりになるというが、自宅が火災にあってデータ消失するリスクより、謎のアカウントBANでデータ消失するリスクのほうが現実的に高いだろうさ。ちょっと厳しいよなこれは。

考えてみると、本当に同期が必要なシチュエーションってもはやあまりないんだよなぁ。結局やりたいことは、コンピュータAでやった操作を、コンピュータBで続きができる、ファイルが分裂しないっていうことだと思う。これについて、アプローチとしてはクライアントサーバ型と、すべてのPCにばら撒く分散型があるわけだが、分散が適切な状況ってのはあまりない感じだ。ただDropboxが手軽だったら使っていた。

その手軽さは、ファイルという実体を直接操作できるところが大きい。しかし最近は、ファイルを直接操作することはあまりなくて、アプリケーション経由であることが多くなった。セルフホストが手軽になったことや、AIによってちょっとした自分用ツールをサクッと作れるようになったことが大きい。

そうすると、僕が「そもそも同期する必要あるか？」と疑問に思うようになったのは、ここ数年のAIの隆盛と、セルフホスト・自宅サーバに再び傾倒し始めたことが影響しているかもしれない。

Dropboxをはじめとしたクラウドサービスは、アカウントBANに象徴されるように、なんつーか健全な商売にしか使えないというか、自分のプライバシーを預けるにはあまりにも危なっかしい相手になってしまったし、ここらへんが転換期なのかもしれない。

<関連記事>

DropboxでアカウントBANされた人がいるらしい

/dropbox-ban/

VPS + Caddy + WordPress を構成するさようならCloudflare Tunnel

Mon, 02 Mar 2026 00:00:00 +0900

脱Cloudflare Tunnel計画で、VPSで入れているCloudflareをCaddyに置き換えようとしている。

前提

/caddy-reverse-proxy/

構成

構成はこんな感じ。なんか最近AIが秒で書いてくれて地味に助かる。

graph TD
subgraph Internet[インターネット]
User((ユーザー))
end
subgraph VPS[Ubuntu VPS]
direction TB
subgraph CaddyServer[Caddy / ポート: 80, 443]
Caddy[Caddy]
end
subgraph DockerNetwork[Docker ネットワーク]
WP[WordPress Container]
end
end
%% 通信の流れ
User -- HTTPS:443 --> Caddy
Caddy -- reverse_proxylocalhost:内部ポート --> WP
%% 役割の説明
style Caddy fill:#f9f,stroke:#333,stroke-width:2px
style WP fill:#0073aa,stroke:#fff,stroke-width:2px,color:#fff
style VPS fill:#f5f5f5,stroke:#333,stroke-dasharray: 5 5
note1[SSL証明書の自動管理圧縮: encode zstd gzip] -.-> Caddy

ConoHa VPS 2GB RAM
Ubuntu 24.04.3
caddy v2.10.2

DNSの設定

ダウンタイムとかどうでもいいので、しれっと既存のレコードを削除して新たにAレコード追加する。

dig 独自ドメイン
dig 独自ドメイン @8.8.8.8

次の設定をしながら反映されるのを待つ……とか思ってたら秒で反映されてびっくりした。

Caddyの設定

独自ドメイン {
 reverse_proxy localhost:ポート

 # 圧縮
 encode zstd gzip

 log {
 output file /var/log/caddy/独自ドメイン.access.log
 }
}

フォーマットする。

sudo caddy fmt --overwrite /etc/caddy/Caddyfile

検証する。ログファイルの権限がcaddyのみなのでsudoつける。

sudo caddy validate --config /etc/caddy/Caddyfile

実行する。

sudo systemctl reload caddy

ログ見る。

sudo journalctl -u caddy -f

いつ見ても覚えづらいsystemd系統のコマンド。

ログファイルのパーミッションに注意

ログファイルは基本的にcaddyの権限となるのだが、エラーが出ていたらだいたいrootユーザになってしまっている。ユーザをなおせば大丈夫

sudo chown caddy:caddy /var/log/caddy/ログファイル

（やってない）ヘッダ偽装しろという指示もあり

最初Geminiに聞いたときは、リバースプロキシするなら以下のようにヘッダかけと言われた。

独自ドメイン {
 # ログを出力（トラブルシューティングに便利）
 log {
 output file /var/log/caddy/独自ドメイン.access.log
 }

 # WordPressへのリバースプロキシ
 reverse_proxy localhost:ポート {
 # WordPressが正しいURLを生成するために必要なヘッダー
 header_up Host {host}
 header_up X-Real-IP {remote_host}
 header_up X-Forwarded-For {remote_host}
 header_up X-Forwarded-Proto {scheme}
 }

 # セキュリティ向上のための圧縮
 encode gzip
}

しかし今までCloudflare Tunnelでこんな設定してなかったけどなぁと思い、設定せずにやったところ、普通に動く。しかしGeminiは「いやheader_up Host {host}だけでも書きなよ」とのことだが、しかし動いているしなぁと思った。

Claudeに聞いたところ、「Caddyのreverse_proxyディレクティブは、何も指定しなくても以下のヘッダーを自動的に設定します」とのことだった。

X-Forwarded-For: クライアントのIPアドレス
X-Forwarded-Proto: スキーム（http/https）
X-Forwarded-Host: オリジナルのHostヘッダー

これらは標準的なリバースプロキシのヘッダーで、Caddyが「気を利かせて」自動設定している、のだとさ。

Hostヘッダーに関しては、Caddyはデフォルトでプロキシ先（バックエンド）のアドレスに設定するので、Geminiの言う通りこれは設定しないとlocalhost:ポート番号に渡されるらしい。が、これについてはWordPress側の設定でURLを定義しているので、Hostヘッダに関係なくURL生成されているんだろうね、とのこと。

なので、マルチサイト構成とかで複数ドメイン使う場合や、なんかプラグインとかで参照する必要があるならちゃんと設定した方がいいよ、でも動いているならシンプルなままでもいなじゃない、とのことだった。納得した。

所感

結局非常にシンプルな設定に落ち着いた。

半額セールで安かったからGemini使っているんだが、ChatGPTとClaudeに比べるとあまり品質はよくない気がする。ただ前にChatGPTと比べていた時には、「ChatGPTよりGeminiの無料枠のほうがマシでは」とすら思ったので、トピックによるのか、それともシードガチャなのか。

まぁよくわからんが、実際のところ確かに複数のAIに聞く、というのは経験的にはアリな気はしている。いつまでこの爆大なコストが使えるのかわからんがね。

Jitsi Meet(ネイティブ) から Caddy + Jitsi Meet(コンテナ)の構成に移行

Thu, 19 Feb 2026 00:00:00 +0900

CaddyをVPSに入れようと思ったが、443が既にJitsi Meetで使われていることに気づいた。ネイティブにインストールしており、内部的にはnginxが使われているはずだが、このままだとCaddyとバッティングしてしまう。

ということで、構成を練り直さないとなぁ、としこしこやりなおすことにした。

全体の構成

元々の環境

ConoHa VPS, Ubuntu 24.04.3, 2GB RAM
- 1.5GBくらい常に使っている頑張り屋
Jitsi Meet バージョン失念
docker 29.2.1

全体の構成は以下のようになる見込みだ。Geminiが10秒で描いた。

graph LR
subgraph "Public Internet"
Client[Client Browser]
end
subgraph "VPS Host"
Caddy(Caddy Server)
subgraph "Docker Bridge Network (172.18.0.x)"
Web[Container: Web]
Prosody[Container: Prosody]
Jicofo[Container: Jicofo]
JVB[Container: JVB]
end
end
Client -- "Port 443" --> Caddy
Caddy -- "Port 8000 (Internal)" --> Web
Web -- "XMPP" --> Prosody
Jicofo -- "Control" --> Prosody
JVB -- "Signaling" --> Prosody
Client -- "Port 10000/UDP (Direct)" --> JVB
style Caddy fill:#f9f
style Web fill:#bbf
style JVB fill:#dfd

各役割についてもGeminiが10秒で書いた。

Caddy (Reverse Proxy)
- SSL/TLS終端: Let’s Encrypt等の証明書管理をすべて引き受けます。
- ルーティング: 特定のドメインへのリクエストをJitsiのWebコンテナ（通常はポート8443や8080）へ転送します。
Jitsi Web (Nginx)
- 静的ファイルの配信: Jitsi MeetのJavaScriptクライアントをブラウザに渡します。
- 内部プロキシ: ブラウザからのAPIリクエストや外部通信（BOSH/WebSocket）を内部のProsodyへ中継します。
Jitsi Videobridge (JVB)
- メディア通信: 映像・音声データをリアルタイムに中継します。
- 注意点: この通信はオーバーヘッドを避けるため、通常はCaddyを通さず、UDP 10000番ポートでクライアントと直接通信します。ここが疎通しないと「自分は映るが相手が映らない」という現象が起きます。
Prosody & Jicofo
- シグナリング: 会議室の作成、ユーザーの入室管理、誰がどの映像を見るかといった「制御信号」を処理します。ユーザーが直接意識することはありません。

手順

最悪もう一回パスワード発行したらいいでしょの精神はもちつつ、できればそのまま移行する。

JitsiMeet: 今の設定ファイルの確認

設定を見返すためにコピーしておく。

/etc/prosody/prosody/conf.d/独自ドメイン.cfg.lua: 認証とかの設定。ゲストありとかそういうの
- authenticationで認証方式を確認する。今回は internal_hashedだった。
- VirtualHostに geust.ドメインがある。ここでauthenticationがanonymousになっている。
/var/lib/prosody/ドメイン/accounts/: 作成したアカウントのdatファイルがある。.がURLエンコードの%2eになっている。
/etc/jitsi/meet/ドメイン-config.js: 主催者はパスワード必須でOKしたらみんな入れる、みたいな設定

Jitsi Meetの停止

とりあえず停止。

sudo systemctl stop nginx jitsi-videobridge2 jicofo prosody

ポート解放の確認。

sudo ss -tulpn | grep -E ':80|:443'

Caddyのインストール

インストールコマンド。

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

その後の動作確認は以前の記事を参照。

Caddyfileの作成

/etc/caddy/Caddyfileを以下のようにする。

ドメイン名 {
 # 後のステップで立てるDocker版Jitsiへ転送
 reverse_proxy localhost:8000
}

設定の反映。

sudo systemctl reload caddy

Jitsiパッケージの削除

もう後戻りできない。

「Self-Hosting Guide - Debian/Ubuntu server | Jitsi Meet」

sudo apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2
sudo apt autoremove

これの削除だが、後になってnginxやapacheなどがゾンビのように蘇ってきてCaddyと443を奪い合うなどあった。僕の手順にミスがあったのか……複数回実行してきっちり削除できていることを確認したほうがいいかも。ってか最初AIにきいたんだけど普通に嘘コマンド教えられたので、まぁこのへんの作業はやっぱりちゃんとドキュメントあたらんとどうにもならんね。

この状態でポートがcaddyになっているかを確認。

sudo ss -tulpn | grep -E ':80|:443'

結果

udp UNCONN 0 0 *:443 *:* users:(("caddy",pid=91842,fd=10)) 
tcp LISTEN 0 4096 *:80 *:* users:(("caddy",pid=91842,fd=11)) 
tcp LISTEN 0 4096 *:443 *:* users:(("caddy",pid=91842,fd=4))

良さそう。

ちなみにこの時点で1.4-1.5GBくらい使っていたRAMが1.27GBくらいに。もうちょっと減るかと思ったけど……。

Docker版Jitsiのインストール

# 作業ディレクトリ（任意）に移動
cd ~
git clone https://github.com/jitsi/docker-jitsi-meet
cd docker-jitsi-meet

# 設定の雛形をコピー
cp env.example .env

.envを編集しよう。編集ポイント

# ドメイン名
PUBLIC_URL=https://meet.wobias.com

# Caddyから受けるためのポート（ホスト側の80/443はCaddyが使っているため、ずらす）
HTTP_PORT=8080
HTTPS_PORT=8443

# 証明書はCaddyが管理するので、Jitsi内蔵のLet's Encryptはオフ
ENABLE_LETSENCRYPT=0

# ホスト認証を有効
ENABLE_AUTH=1
AUTH_TYPE=internal

# ゲスト（URLのみ）を許可
ENABLE_GUESTS=1

# 例: 1.2.3.4 の部分を実際のVPSのIPに書き換える
JVB_ADVERTISE_IPS=あなたのVPSのグローバルIP

以下でコンポーネント間の通信パスワードが .env にいくらしい。

./gen-passwords.sh

うまくいきますように……。

docker compose up -d

ブラウザで https://ドメイン名でJitsi MeetのUIが開けたら万歳。

アカウントの追加

なんかドメインはどうあれ、内部的には meet.jitsi らしい。

docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua register ユーザー名 meet.jitsi パスワード

動作確認

あとはみんなで入ったりなんだりしてOKだったらOK。sudo rebootも試した方がいいと思う。

参考記事

Docker版Jitsi Meetのインストール手順 | 稲葉サーバーデザイン

証明書発行 + リバースプロキシ Caddy を試す curl https://localhost とかいう哲学

Tue, 17 Feb 2026 00:00:00 +0900

そろそろ脱Cloudflare Tunnel計画を実行するかと重い腰をあげ、証明書発行 + リバースプロキシという顧客が本当に必要だったものみたいなセットを提供してくれるCaddyを試すことにした。

ConoHa VPSのまっさらな環境から立ち上げる。

構築手順

1GB, 2コアの時間課金
Ubuntu 24.04.3アプデ
セキュリティグループでIPv4v6-SSHとIPv4v6-Webを追加。
- rootかつSSH鍵認証だけど、すぐ作ってすぐ壊すのでとりあえずヨシ

インストール

いつもの。

sudo apt update
sudo apt upgrade
sudo apt install emacs # 呪い

公式のインストールはネイティブとコンテナがある。やることを考えるとコンテナ使うとややこしいかなぁと思ったので、Ubuntuパッケージをそのまま使う。

Install — Caddy Documentation

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

そのまんまsystemdにサービス登録されるので、動作確認。

curl localhost:2019/config

レスポンス。

<a href="/config/">Moved Permanently</a>.

デフォルトで2019番つかうらしい。以下で停止。

caddy stop # 停止
caddy start # 再開. bgで起動する。テスト用

ここで、systemd使ってるのにcaddy runとかすると二重起動しておかしくなるっぽい。

チュートリアル

いけたら「Getting Started — Caddy Documentation」でざっと概念を学ぶ。以下復習用（by Gemini）。というかもしかするとこのAIまとめをざっと読んでからGetting Started読んだほうがわかりやすいか。

1. Caddyの本質：すべてはAPIである

Caddyの最も重要な概念は、「設定ファイルはAPIを叩くための手段に過ぎない」という点です。

Admin API: デフォルトで localhost:2019 で待機しています。
Under the hood: caddy run で設定ファイルを読み込むとき、内部的にはその内容をAPI経由で自分自身に POST しています。
ゼロダウンタイム: API経由で設定をロードするため、サーバーを再起動（Stop/Start）することなく設定を瞬時に切り替えられます。

2. JSON vs Caddyfile：使い分けの基準

Caddyには2つの顔があります。

特徴	JSON (Native)	Caddyfile (Adapter)
役割	フル機能。	人間が読み書きするための「皮」。
生成	プログラムやスクリプトから生成しやすい。	手動での管理に最適。
変換	そのまま実行。	`caddy adapt` でJSONに変換されてから実行。
柔軟性	全機能にアクセス可能。	一部の高度な設定は書けないことがある。

Tip: 複雑なことをしたくなったら caddy adapt --config Caddyfile --pretty を実行して、自分のCaddyfileがどんなJSONに化けているか確認するのが上達の近道です。

3. 実行コマンドの使い分け

コマンド一つで挙動が変わるため、用途に合わせて使い分けます。

caddy run :
フォアグラウンドで実行（画面がロックされる）。
本番環境（Systemdなど）で推奨。 ログが追いやすく、プロセスの生存確認が容易なため。
caddy start :
バックグラウンドで実行。
ローカルでのちょっとしたテストに便利。止める時は caddy stop が必要。
caddy reload :
Caddyfileを書き換えた後、ダウンタイムなしで設定を反映させる。

4. ワークフローの選択（APIかCLIか）

チュートリアルでは両方紹介されていますが、混乱を避けるためどちらかに寄せるのが一般的です。

Caddyfile + CLI: * 一般的なWebサーバーとしての運用。設定ファイルをGitで管理し、caddy reload するスタイル。
JSON + API: * SaaSの基盤など、動的にサイトやドメインを追加・削除したい場合。外部プログラムからHTTPリクエストで設定を流し込むスタイル。

5. 重要なエンドポイント

APIを直接触る際に覚えておくと便利なパスです。

GET /config/: 現在適用されている設定をJSONで確認。
POST /load: 新しい設定（JSON）を流し込む。
POST /stop: サーバーを停止させる。

これらはすべて localhost:2019 を介して行われます。

ローカルHTTPSを試す

試すと言うかデフォルトでlocalhostだと自動で自己証明書でHTTPS使えるようだ。すごい。楽。「Caddyfile Quick-start — Caddy Documentation」よりCaddyfileを編集。

localhost

respond "Hello, world!"

いったん caddy stopしてcaddy startする。

curl https://localhost

https://localhostわろた。この無意味さ完全に現代って感じ。

「俺と俺の会話は暗号化されているので安全です」
「なるほど、その暗号化は誰がやるのか？」
「俺です」
「なるほど、それが正しいと誰が証明するのか？」
「俺です」

このイノベーションの虚無さはおいといて、実務的には普通に助かる。

なおテストサーバなのでroot権限でやっているが、ウェルノウンポートなので、普通ユーザなら sudo -E caddy startするかlocalhost:2080とか1024以上のポートにしようね、とのことだった。

複数サイトあるときはブロック{}使う。

localhost {
	respond "Hello, world!"
}

localhost:2016 {
	respond "Goodbye, world!"
}

フォーマットできてないと怒られる。

caddy fmt --overwrite

でなおる。

ひととおりわかったので、実ドメインで試す。

独自ドメインで検証

DNSの設定

ここまでのとおりなのだが、まずDNSのほうでAレコードをVPSに向ける。AAAAレコードも設定すれば証明書やってくれる模様だが、とりあえずIPv4でやる。

まっさらならいいが、既に値があるなら反映まで時間がかかると思われ、最初にやるのがよい。設定したら頃合いを見て以下を実行する。

dig 独自ドメイン
dig 独自ドメイン @8.8.8.8

8.8.8.8はGoogle Public DNS。両方でIPアドレスがきちんと向いていれば、まぁ大丈夫だろう。

セキュリティグループ

ConoHaの設定になるわけだが、セキュリティグループでWebを開けていることを確認する。

ファイアウォール

80/443を開ける。Let’s Encryptのチャレンジで80必須。

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 確認
sudo ufw status

Status: active

To Action From
-- ------ ----
OpenSSH ALLOW Anywhere 
80/tcp ALLOW Anywhere 
443/tcp ALLOW Anywhere 
OpenSSH (v6) ALLOW Anywhere (v6) 
80/tcp (v6) ALLOW Anywhere (v6) 
443/tcp (v6) ALLOW Anywhere (v6)

Caddyfileの編集

Caddyfileを以下のようにする。

独自ドメイン

respond "hello!"

編集したら caddy reloadするか、caddy stopとcaddy start。

curl https://独自ドメイン

helloされたらとりあえずOK。

設定ファイル

もうちょっとちゃんとやる。とりあえずテスト用のHTMLを作成する。

sudo mkdir -p /var/www/html
echo "<h1>Hello from 独自ドメイン (HTTPS)</h1>" | sudo tee /var/www/html/index.html

caddyをネイティブでインストールしたら、systemdで有効化されているわけだが、Caddyfileのパスは /etc/caddy/Caddyfileとなっている。ここで、さっき作ったのを見に行くようにする。

独自ドメイン {
 root * /var/www/html
 
 # 静的ファイルを返す設定
 file_server
}

Aiがテスト用の記述をしてくれました。

systemctl restart caddyするなりrebootするなりして、設定した独自ドメインにブラウザでアクセスして、表示されることを確認する。

起きたトラブル

接続するたびに結果が変わる -> 二重起動

lsof -i :ポートで確認したら競合していた。systemdで動いているのと caddy runで動いているのが別々であったと思われる。rebootしたらなおった。

ブラウザ「このサイトへの接続は保護されていません」

証明書ミスをやらかすと、ブラウザにキャッシュが残って言われる。シークレットウィンドウ開いて確認したらOK。

所感

とても楽だった。curl https://localhostは何か哲学的な感じがした。現代の闇。

要領はわかったので、是非このブログのあるVPSにも導入して脱Cloudflare Tunnelといきたいところだが、めんどくさいことにJitsi Meetをインストールしており、そちらのWeb UIが80/443ポートを使ってしまっているため、その対処をしたうえで移行しないといけない。ちょっと今日はもういいや。

まぁ何はともあれ、これとTailscaleを組み合わせることで、VPSと自宅サーバをVPN接続することもできるし、非常にめでたい。

<関連記事>

How to swap Ctrl and Caps Lock keys in Linux | Opensource.com

TailscaleでVPSと自宅サーバを繋ぐ

/tailscale-vps/

Linux Mint Xfceを入れてからやること

Thu, 12 Feb 2026 00:00:00 +0900

LinuxでPC再生計画を実行中。とりあえず家が旧式のThinkPadで埋もれつつある。

Linux Mint Xfceを導入したときの設定メモ。なんか変更あったら随時入れていく。

環境

試したのは以下。

ThinkPad X250
- Core i3-5010U
ThinkPad X260
ThinkPad X270
- Core i5-7300U
ThinkPad X280
- Core i3-7020U
- Core i5-8250U
ThinkPad L390
Dell Latitude 3570
- Core i3-6100U
Dell Latitude 5290
- Core i5-8250U
Dell Latitude 5300
- Core i5-8265U
FUJITSU LIFEBOOK A574/H
- Core i5-4300M
FUJITSU FMVWD2028
- Core i5-8265U
TSUKUMO eX.computer Notebook PC N1501K
- Core i5-6200U

2026年には産廃とされるスペックでも、Linux Mint Xfceだと普通に動きます。

常用に影響があるのはむしろTNパネルかIPSパネルかといったところ。慣れればこんなもんかと思うでしょうけれど、IPSなやつと見比べた途端に「我々は虐げられていたのか！」みたいな気分になります。まぁでも慣れるとTNでもそんなもんかねという感じです。

忘れがちな操作

ワークスペースの移動

Ctrl + Alt + 矢印

ターミナルでコピペ

Shiftを入れる。Ctrl + Shift + Vで貼り付け。

設定

マウスとタッチパッド

スクロールを逆向きにする（好み）
ポインター速度を調整する

日本語入力

「設定マネージャー」から「入力方法」→「日本語」を確認する。手順が書いてあるのでそのとおりにやる。

画面の指示通りにやるだけ。最終的にFcitx + Mozcになる。

一点、Fcitxの設定画面で、入力メソッドの設定なのだが、「キーボード - 日本語（不明）」の下に「Mozc（日本語）」となっている場合、キーボード - 日本語は削除する。

マイナスボタンから消せる。

CtrlとCaps Lockをスワップする

XfceだとGUIでやれる方法が見つからなかったよ。なので以下を参考にさせていだきました。

まずテスト。

/usr/bin/setxkbmap -option "ctrl:swapcaps"

こいつを実行して、Caps LockでCtrlになるかを確認する。

うまくいくことを確認したら、~/.profileに上記コマンドを追記する。

再起動して、ログイン後も設定が保持されていることを確認する。

ハードウェア

マイクとかスピーカーとか音声周り

なんかマイクとか動作しないことがある。音声系のトラブルは下記記事の知識が使えることが多い。

/thinkpad-x280-linux-mint-xfce-28-3-vivaldi-mic/

/thinkpad-l390-linux-mint-xfce-22-3-hdmi/

HDMI接続でチラつきの発生

Linux PCとHDMI接続したディスプレイでチラつきの対応

/linux-pc-hdmi-display-flicker/

一通りのソフトウェアを入れる

完全にただの好み。

.debを落として入れる

Vivaldi
- パネルの位置を右にする
- 検索エンジンはGoogleにする。すまんな
  - DuckDuckGoはうちのサイトを表示しないから…

端末から入れる

tlp, tlp-rdw
- サーバ利用なら75-80%で充電するように設定するのがよい（後述）
emacs
- みんな大好き
wine-installer
- winetricks
  - winetricks cjkfonts

ブラウザ拡張

Bitwarden
FormatLink
Floccus

サーバ向け設定

24時間稼働常設サーバにするときの設定。クライアントとして使うならほぼいらない。

静的IPアドレス

IPアドレスを固定する。ルータ側で固定してもいい。

充電を80%で止める

据え置きサーバー用途ならば、充電を80%までにして少しでも長生きさせたい。

sudo apt update
sudo apt install tlp tlp-rdw

設定ファイルの編集。

sudo nano /etc/tlp.conf

以下を探してコメントアウトする。

# バッテリーの充電開始しきい値（75%以下になったら充電開始）
START_CHARGE_THRESH_BAT0=75

# バッテリーの充電終了しきい値（80%に達したら充電停止）
STOP_CHARGE_THRESH_BAT0=80

再起動と確認。

sudo tlp start
sudo tlp-stat -b

スリープの無効化

サーバー用途だとスリープは邪魔。

とりあえず設定で「電源管理」からあらゆる設定を「しない」にしつつ、AC接続において管理をGUIでさせない。余計なことばかりしやがって。

そのうえでCUIでスリープ殺す。

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

もとに戻す時。

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

ファイアウォール有効化とポート開放

サーバ用途なのでファイアウォール有効化。

sudo ufw enable

55555番を開ける時は以下。

sudo ufw allow 55555

確認コマンド

sudo ufw status numbered

OpenSSH Server

SSHはいるだろう。

sudo apt update
sudo apt install openssh-server

起動と有効化。

sudo systemctl start ssh
sudo systemctl enable ssh
sudo systemctl status ssh

ファイアウォールの設定。

sudo ufw allow ssh
sudo ufw enable

IPアドレスの確認。

ip addr show

接続の確認。クライアントPCの公開鍵をサーバPCの ~/.ssh/authorized_keysに追加。パーミッションは600。

ssh ユーザ名@サーバのIPアドレス

一応、SSHの設定について。

SSHで鍵認証を用いて、パスワードなしでログインする方法

/20462465-2/

所感

ハードウェアごとの所感は別途記事にしたいと思いますが、思っていたよりもかなり快適に使えます。ディスプレイだけつらいところがありますが、サブマシンとしては十分な感じがします。ブラウザでタブいっぱい開かなければ普通に使えるんじゃないでしょうか。

ジャンクを漁って自分でやれる人なら、数千円で環境作れると思います。とはいえ普段遣いを考えるなら、あと1万円追加してIPS + 8GB RAMをおすすめしますけどね。RAMは換装できるモデルなら良いと思います。

個人的にはEmacsキーバインドを入れたいのですが、どちらかというと他人様に使ってもらえる設定を追求中なので、あまりニッチすぎる設定は後回し。

<関連記事>

【Linux PC再生計画】中古PCも触ってみるといろいろだ

/linux-pc-2/

ThinkPad X260 Core i3-6100 4GB RAM で Linux Mint 22.3 Xfce を動かす

Wed, 11 Feb 2026 00:00:00 +0900

Linux PC量産計画で、今回はけっこう古めの筐体、ThinkPad X260について見ていく。なお試したOSはいつものようにLinux Mint 22.3 Xfce Edition。

スペック

X260は2016年1月に発売された、主にSkylake世代（第6世代Core iシリーズ）の時期のやつで、スペックは例によってAI記事「ThinkPad X260のスペックを整理」に詳細をまとめさせた。今回使った筐体のスペックはこれ。

CPU: Core i3-6100U, 2.3GHz, 2コア4スレッド
RAM: DDR4 4GB
SSD: SATA 128GB
LCD: TN, HD
Webカメラあり
バッテリー: 死亡

3000円で買った安定のクソスペ。SSDは抜かれてたので自分で入れた。バッテリー死んでて辛い。液晶は普通。

インタフェースはけっこう充実している。

USB 3.0 x 3（うち1つはPowered USB）
HDMI
Mini DisplayPort
RJ-45（有線LAN）
SDカードリーダー（4-in-1）
マイク/ヘッドホン・コンボ・ジャック
ドッキングコネクター（底面）

RJ-45、HDMI、USB 3.0と欲しいところが揃っている。Mini DisplayPort懐かしい。SDカード入るのは地味に良いかもね。

使い勝手

とりあえずこの記事はX260で書いている。使えるといえば使えるが、しんどいといえばしんどいような感じだ。

メモリはスワップがあるけれど、それよりもCPUの負荷が常にまぁまぁある。普通にネットをしてるだけでこれなので、動画とか見るとしんどいかもしれない。

と思ったが、一応YouTubeを流しながら編集する、程度は問題なくできる。

CPU、メモリともにちょっと負荷あがるね。まぁでも特にもたつくような感じはないかな。ブラウザでタブめっちゃ開けば開いただけメモリの使用量は増えていく。

負荷云々よりも、液晶がTNなのが厳しいのはしゃーない。一番いい感じで見える角度があるので、それを探し当ててそこで見るのがよい。あまり便が良い感じではないが、姿勢は良くなるかもしれない。一応世の中にはThinkPadで換装できるFHDのLCDなどアリエクなどに売っていたりするが、普通にジャンク本体より高いので使う気になれない。

バッテリーが死んでるのはこのジャンク特有の問題ではあるが、やはりずっと繋げっぱなしの制約があるのは悲しいところだ。少し残っているだけでも、取り回しの便は全然違うし、なによりサーバ用途ではUPS代わりになっていいのだけどね…。

キーボードの打鍵感は、これは好みになるが、個人的にはかなり良いと思った。ペチペチ。赤ポチは好きな人は好きなんだろうが僕は慣れない。ちゃんと動いて入る。タッチパッドも問題なく動く。まぁ僕はトラックボールマウスを外付けで使ってしまうわけだが…。地味にこのへんの外部入力が問題ないのは良いよね。Webカメラもちゃんと動いてました。

全体的には、これでも十分という人はそれなりにいる気もした。やはりディスプレイが一番のネックかなと思うんだけれど、据え付けで使う分には外部出力という手もあるので、案外困らないかもしれない。

サーバとしては

サーバの検証はなにをするかまだちょっと決められていない。ほとんどの用途には足ると思うけれど、Immichのような重量級は推奨要件を満たせていないので微妙だろうなぁ。インストールはできるし、快適さを求めなければまぁ動くとは思う。

とりあえずWordPressを入れて試したが、当然ながらこれは問題なく動く。そりゃ２GB RAMのVPSでも3台動かせているのだからそりゃそうだな。

少し重ためなものとして、Growiを入れてみる。GrowiはMongoDBとElasticsearchがあるので、そこそこヘビーだ。

メモリの使用量がさすがに増えるけど、3GB未満。

ま、VPSだと思ったら4GB RAMなんて豪華だし、ネイティブで完全にリソースを使えるのだから、そりゃ強いよね。ちょっと何かあったらこうして画面を確認することができるんだしさ。

Cloudflare Tunnelで手軽に外部公開もできるし、通信帯域や可用性を気にしないなら、これで十分だなぁ。VPS1年契約するよりいいかもしれないね。

ただこのPCについていえば、バッテリーが死んでるのは残念だ。バッテリーが少しでも生きていれば、停電などでも生き延びることができるので、可用性に大いに寄与するはずだ。まぁバッテリーも買えば互換品もあるんだけどさ。高いしなぁ。

まぁバッテリー死んでるなら爆発しなくていいんじゃないの、というポジティブに考えられなくもない。

所感

GUI含めてちゃんと動いてくれるが、Webブラウザでなんでもやろうとするとつらい場面は出てくるはず。

個人的にはこのスペックならやはりサーバ用途がいいなと思う。たいていの用途には十分さ。

DropboxでアカウントBANされた人がいるらしい

Fri, 30 Jan 2026 00:00:00 +0900

オンラインストレージ・サービスで垢BANされた人の話は定期的に流れてきますが、今回はDropboxのようです。

Dropboxのアカウントが規約違反により突然BANされて博士課程の研究データの一部や趣味の写真などが取り出せなくなった…問い合わせメールも全て無視されている - Togetter

垢BANによって、博士課程のデータや趣味データの一部が取り出せない自体になっているようです。問い合わせは無視されているとこのこと。これはたいへん。

Dropbox、お前もか

いつものことではありますが、第一印象としては「Dropboxか」ではありました。垢BANというのは極めて重大なペナルティで（実行する当事者にその自覚がないようですが）、ビッグテックが片手間でやっているGoogle DriveやOneDriveではちょくちょくきくものの、オンライン・ストレージがコアビジネスで、それ一本でやってきたDropboxではあまり聞いたことがなかったからです。

まぁまったく初めて聞いたということはなく、以前に調べたときも、Dropboxで垢BANされた人の話は見つけることができました。その人もデータが取りだせなくて困っていました。結局解決されたのかどうか、記憶になく、保存しておけばよかったと思います。記事は一期一会（なのでこうして記事にしている）。

一発BANが企業の合理

なぜこうもカジュアルにデータを凍結するのか、ユーザからは不可解ですが、企業側からすると、これがもっともコストが低いと判断されているのでしょう。

いちいち警告すれば、本当に悪意あるユーザが相手だったときに手の内を明かすことになります。また、担当者をつけるのはコストです。アルゴリズムで判断したら悪即斬、これがもっとも合理的、ということですね。ユーザからすれば横暴かつ不合理でしかありませんが。

スレッド内にもあったとおり、本来であれば日本国憲法に規定された財産権(第29条)の侵害にあたると考えられます。しかし相手は米国の企業であり、デジタールデータであり、また利用規約に同意したという建前があります。実態を考慮すると、法律は善意のユーザの味方になっていません。完全に、大きなもの、企業の味方になっています。法治国家（笑）

対策: クラウド最小権限

根本的な対策は存在しません。

個人的には「クラウドを使う金でNASを買え」と言いたいところですが、それだとあんまりなので、「利用を最小限にとどめる」くらいにしておきましょうか。具体的には、以下の徹底です。

インターネットを介した同期が必要なファイルのみ
ローカルのバックアップとして位置付ける
必要なデバイスにのみインストールする

多分これだったら無料枠で十分です。有料顧客になって機能をフル活用するほうが危険性が高いというバグみたいな仕様だから仕方ないですね。

オンライン同期を使わせたがってきますが、邪悪な企業にデータの本体を差し出す愚行をしてはいけません。

企業はユーザのことなんか考えていません。利益しか見てません。

データの保存は基本に忠実に

それではデータのバックアップはどうしたらいいのかという問題があるわけですが、大事なデータは3-2-1バックアップを実践しましょう。

3-2-1バックアップは、一言で言えば3つのコピーを2つ以上の媒体で、1つは遠隔地に、です。元データはSSD、バックアップはNASまたは外付けHD、そして1つは遠隔地に持っていく、という形になります。遠隔地について、クラウドサービスを使ってもいいですが、こういう事件があるのですから、私としては実家など信頼できるところに、暗号化のうえで置かせてもらう、のが一番良いのではないかと思います。

これは前時代的に思えるかもしれませんが、謎の基準でアカウントBANされる現時代よりはいいでしょう？未来時代はきっともっとひどいですよ。

重要なことは基本です。基本は変わりません。ITの世界は進化が早いなどと言われますが、あんなもんはマーケティングのポジショントークですよ。

ルールの源を考える：我々は力を行使できない

最後に、規約について。スレッドで、投稿者の方は「規約違反だからBANは仕方ない」と物分かりよく考えられています。

「規約に違反したのは仕方ないからアカウントの復帰は諦めてるけど、それとは別にデータには財産権があるからダウンロードリンクを発行してほしい」とメールを送っても返信なし。選択的同期でローカル端末から消えてて救出できないデータが大量にあるんですが、なんとかなりませんか

— https://x.com/fukusanity/status/2016445862315213287?s=20

規約は確かに強力な建前です。しかし一方で、財産権というより強力な建前が通用しない現実にも直面されたことと思います。メールを送っても音信不通であったとのことです。ではどうしたらいいのでしょうか？アメリカの企業に日本国憲法に基づいて法的措置をすれば？いやまさか。

しかし今回、SNSで大いに取り上げられ、トレンドにもなったことで、騒ぎが大きくなったためか、この投稿にDropboxからリプライがついていました。データを救済できる道筋がついたのかもしれません。

これは我々に、ルールとは何かを強く考えさせます。折しも、アメリカがトランプ大統領のもとに国際法なにそれおいしいの言わんばかりの蛮行で、しかし着実に成果を出し、また誰も実質的に文句が言えていない、という状況が思い出されます。これでは、ルールとは弱いものだけが守り、強いものだけが守らなくて良い特権にさえ見えてきます。

これについて、私はルールには裏付けがある、と考えております。そのもっともわかりやすい裏付けが暴力です。これは別に特殊な考え方ではないでしょう。私は専門ではありませんが、社会契約論とか好きな人たちはだいたい国家の暴力の独占についてそういうことを言うんじゃないですか。

しかし、何も直接的な暴力だけではありません。つまり、 「筋の通らないことをするならこちらにも考えがある」という何かができるのか、ということにあります。たとえば商売であるならば、「そんな不義理をするなら、君との取引はこれまでだ」というのは力の行使になり得ます。ですが、DropboxをはじめSaaSに対し、月額1000円ばかりのユーザが取引停止をちらつかせたところでなんの抑止力にもならないことは明らかです。

では、法的措置。これも通常あるべきですが、現実的に市民の手に負えません。特に今回は外資が相手です。

ここで、SNSが最後の武器となります。「Dropboxにこんな仕打ちを受けた」というツイートがSNSの世界でトレンドになるほど広まるのは、これは企業にとって確かに困るわけです。ツイートをバズらせて初めてようやく、企業が話し合いの土俵に立ちます。バズらないと絶対にいじめ（暴力）を調査しない学校と一緒です。今をときめくIT企業も役所と一緒なんです。

いったいぜんたい、こんなことでいいのかと義憤に駆られますが、現実はこうなっております。

私としては、この力の非対称性を考えると、今一度「所有すること」の意味について市民一人一人が考え直すべきときがきたと思います。

結論：セルフホストがすべてを解決する

<関連>

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

/data-self-hosting/

ConoHa の VPS 2GB RAM でやっていること

Sun, 25 Jan 2026 00:00:00 +0900

メモがてら、現在VPSで私がやっていることについてまとめます。2GB RAMでこれくらいできるんだな、という参考にもなるかとは思います。vCPUは3コア、SSDは100GB割り当てられています。

構成

書いてみて、Jitsi MeetとWebサイトしか置いてないことに気づきました。このサイトで紹介しているセルフホスト系アプリは、だいたい自宅サーバです。

graph TD
proto(プロトタイプアプリ)
subgraph コンテナ2
cf_w(Cloudflare Tunnel B)
end
jitsi(Jitsi Meet)
cf(Cloudflare Tunnel A)
subgraph コンテナ
wp1(WordPress 1)
wp2(WordPress 2)
wp3(WordPress 3)
db(MariaDB)
end
cf --> wp1
cf --> wp2
cf --> wp3
wp1 -.-> db
wp2 -.-> db
wp3 -.-> db

これだけのアプリですが、そこそこ重いのが揃っているので、RAMはけっこうかつかつです。1GB RAMだと無理でしょうね。1.5GBくらい常に消費しているし、スワップも発生しています。

Cloudflare Tunnel

2つのCloudflareアカウントで管理されたドメインがあるため、なんかコンテナ経由とネイティブにインストールしたものの2種類あるというわけのわからんことになっています(^_^;)

普通はネイティブに入れるだけでいいと思います。

Jitsi Meet

Jitsi MeetはZoomとかビデオチャットアプリのオルタナティブですね。多人数のビデオチャットを無制限にできるので、これは非常に有用だと思います。VPSのおすすめ用途の一つです。3人くらいでちょくちょく使っていますが、安定性はそれなりですかね。なんかたまに挙動不審なことがあります。だいたいVPSを再起動するとなおります。初期設定はちょっと手こずるかもしれません。

まぁ最近はZoom使っちゃいけない令が出てチャットアプリ迷子になっている人もいるかと思いますが、そういう時にも自前でたてるという手段があるのは良いことです。仕事でも使えます。

ただインストール難度はそこそこあるので、サーバ初心者が最初に挑戦するやつではないなぁとも思います。コンテナを使った管理よりもネイティブのほうが良いと思います。

と思っていましたが、結局コンテナ使うようになりました。Caddy使うのに443とられるわけにいかなかったのです。

/jitsi-meet-docker-caddy/

WordPressサイト3つ

AIにきくとそりゃちょっとキツイんじゃないの？と言われそうなのがWordPressのサイト3つを常駐させていることです。全然いけます。まぁアクセスが少ないからでもあります。悲しい。昔はもうちょっとよかったんですけどね。まぁでも昔のアクセス数でも全然捌けただろうな。

データベースは3サイトで共有しています。できれば分離したいですけど、さすがにMariaDB 3つは厳しいだろうなぁと思います。

また、外部公開は直接外に出すのではなく、Cloudflare Tunnelを利用しています。これは複数サイトの証明書管理がめっちゃだるいからです。昔Certbotを自動起動していたとき、なぜか一つのサイトだけ自動更新に毎回失敗して証明書が切れるという現象が起きて悩まされたりしていました……。

たまになんかのアプリをビルドする

時々試験目的で、アプリケーションをビルドしてテスト公開に使っていたりします。ただ前述のとおり既にRAMはカツカツで、この状態でビルドするとフツーに落ちるので、swapを2GBから6GBとか10GBに拡張してビルドを実行します。

VPSで向いてること: 安定した通信と高い可用性

私は10以上のアプリケーションをセルフホストで運用していますが、だいたい自宅サーバで運用しています。多くの場合、スペックが重要だからです。本当は全部自宅サーバでやりたい。

VPSに切り出しているのは、固定IP、セキュリティ、安定した通信基盤、可用性が求められるものに限っています。つまり不特定多数に向けたWebサービス（サイトを含む）ですね。まぁ一言で言えば安定したDMZって感じかと思います。

まぁ入り口さえVPSなら、あとは可用性だけが問題なので、うち程度ならWebサイトは自宅サーバでもいいんじゃないの？という気もしています。今のところ問題なく運用できているので、別にVPSでいいかと思って置きっぱなしにしていますが、今後別のアプリケーションを優先して入れ替えることはあるかもです。

あと3-2-1バックアップのクラウド保存としてのバックアップ用途もあるのですが、ストレージ系は値段が高いので個人的にはオススメはしません。ハードディスク暗号化して、実家に置かせてもらうとか、信頼できる人同士で置き場提供しあうとかのほうがいいんでないですかね……。

今後の拡張予定

今後VPSでやりたいと思っているものです。これらはWebサイトよりも優先順位が高いので、もし負荷の限界が見られたらWebサイトを自宅サーバに引っ越す可能性あります。どうせアクセス少ないし🥺

自宅サーバと繋がるゲートウェイ: リバースプロキシ + 証明書管理 + VPN

現在色々なところでCloudflare Tunnelを使っているところを置き換える予定です。具体的にはリバースプロキシをおいて、VPNで自宅サーバと繋げる感じを想定しています。ドメイン証明書の発行もします。構成は既に考えていますが、めんどくさいです。

一般的にはCloudflare Tunnelで十分なのであんまりおすすめしません。私がやろうと思っているのは、思想信条というめんどくさい理由によります。いつかCloudflareの大規模障害で一緒に沈んだ大規模サービスを煽り倒そう。

アクセスをVPN経由にしたいとかNASを外で見たいとか、そういう外部公開前提のプライベート目的なら有用だと思います。私はそのへんのユースケースはあまり関心ないのですが、そのうちやってみるかも。

メール: Postfix

現在アプリケーションサーバとして契約しているメールサーバについて、Postfixを置いて代替させるつもりです。メールサーバー605円/月もするので……。それだったらPostfixで最低限の機能をもたせたうえで、重い処理は自宅サーバでやる、みたいな合わせ技をやりたいわけです。

セルフホストで自宅サーバ派でもVPSは有用

AIのせいでAI PCが高すぎて買えないとかいうグローバルレベルのギャグが展開されている昨今、PCの基本が問われていると思います。しかし、PCのスペックは10年前レベルでもはや十分過ぎる程度で、いらないことをいると思わされ続けてきた10年だったと個人的には思っております。実際2GB RAMでもこれだけのことができるわけです。ここに自宅に眠るマシンを組み合わせれば、その可能性は無限大。

まぁだからといってAIのせいでPC高騰というのは絶許という気持ちは変わらないんですけれど、そうは言っても世情には逆らえません。今あるものを使い切る思想が重要かと思います。

そのうえで、自宅サーバでは難しいところ、つまり安定した電源と通信、余裕のある帯域幅、プライベートなLANと隔絶された環境を手軽に実現するするものとして、VPSは非常に有用です。どこぞのサブスクに金払うなら、VPSを借りるほうが有意義だと思います。

でもConoHaは勧めない

ここまで書いといてなんだが、先日ConoHaがやらかした大規模障害とその対応に呆れ果てたので、勧めません。

ConoHa VPS落ちすぎ問題

/conoha-vps-down/

いつか光回線と業務用ルータで完全独立したい。

<関連記事>

自宅サーバは死なず。

セルフホストでブックマーク同期：Floccus + WebDAV(bytemark/webdav)

Sat, 24 Jan 2026 00:00:00 +0900

ブックマークを複数ブラウザで同期したい。LAN内のみで良い（一手間加えればWANもいけると思うけど）。

EverSyncを使っていたのだけれど、Braveをアップデートしたら挙動不審になったのをきっかけにセルフホストに移行することにしました。別にブックマークなんて結局リンク集なのでそんな大した秘匿情報ではないので、別にクラウドでもよかったんですが、まぁせっかくなので。

できるだけシンプルなものとして、「Cross-browser bookmarks syncing - Floccus bookmarks sync」をWebDAV構成で使うことにしました。

構成

簡単に構成。

graph TD
subgraph WebDAV Server
bookmark(bookmarks.xbel)
end
subgraph Mac
browA(Browser A)
end
subgraph Windows
browB(Browser B)
end
browA |Floccus| bookmark
browB |Floccus| bookmark

Floccusはブックマーク同期のみをするソフトウェア
- 通信はいくつかの手段がある。一番楽なのはGoogle Drive。
- ここではシンプルかつ自立性を重視して安心と伝統のWebDAV
2つめ以降のブラウザで、同じプロファイルを用いるには、手動でプロファイルのインポート、エクスポートをする

NextcloudとかLinkwardenを基盤にすることもできるようなのですが、依存を減らしたかったのでWebDAVにしました。Nextcloud基盤一応あるんですけれど、重量級なのであんまり色々やりたくない感じ。

Floccusのバージョンは5.8.3で、Firefox、Chromeなど対応しています。

インストール

WebDAVサーバの準備

「bytemark/webdav - Docker Image」を使わせていただきました。

services:
 webdav:
 image: bytemark/webdav
 container_name: floccus-webdav
 restart: unless-stopped
 ports:
 - "ポート:80"
 environment:
 - USERNAME=ユーザ名
 - PASSWORD=パスワード
 volumes:
 # 相対パスに変更することで、今いるディレクトリの data フォルダに固定されます
 - ./floccus-data:/var/lib/dav

ポート、ユーザ名、パスワード、あとブックマークを保存する場所を指定します。上記はカレントディレクトリのfloccus-dataディレクトリになっていますが、適当に。

同期ファイルとして、最小限のXMLファイルbookmarks.xbelをコンテナ内の/var/lib/dav/data内に置いておきます。

# コンテナ内のファイルに最小限の XML 構造を書き込む
docker exec floccus-webdav sh -c 'echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?><xbel version=\"1.0\"></xbel>" > /var/lib/dav/data/bookmarks.xbel'

# 念のため所有権を再設定
docker exec floccus-webdav chown www-data:www-data /var/lib/dav/data/bookmarks.xbel

最初のブラウザにfloccus導入

「Guides and How tos - Floccus bookmarks sync」がドキュメント。ここから使っているブラウザの拡張機能を導入します。

インストールしたら、最初のプロファイルを作成します。

WebDAV URL: http://WebDAVサーバのIPアドレス:ポート
- LAN内なのでhttps接続は不要としました
ユーザ、パスワード: docker-compose.ymlと合わせる
パスフレーズ: 空欄（暗号化しない場合）

次は同期ファイルのパスとかを指定します。

次の設定は同期の手法で、同期タイミングや方向性の設定ですが、基本的にはデフォルトでいいと思います。

ただ入れ子プロファイルだけOFFにしました。私には必要ない機能だと思ったからです。この機能の意味はGemini曰く以下です。

例えば、以下のような2つの同期設定（プロファイル）を作りたいとします。

プロファイルA（全体用） : 「ブックマークバー」全体を、自分専用のWebDAVサーバーに同期する。

プロファイルB（共有用） : 「ブックマークバー」の中にある**「仕事」フォルダだけ**を、チームの共有サーバーに同期する。

このとき、「仕事」フォルダは、プロファイルAの管理下でもあり、プロファイルBの管理下でもあるという重複状態になります。

つまりチームやプロジェクトで一部分だけ共有とかしたい時に使う機能です。私はシングルユーザで、特に複雑なコントロールをする予定はないので、オフにしました。どうしてもこの手の同期系ソフトウェアは運用していると何かとトラブルが発生しがちなので、不要な機能はオフにしたほうがよかろうと思いました。

そういう意味では、もっとも確実なのはアップロードもダウンロードも完全手動にすることでしょうし、実際EverSyncではそうしていたのですが、とりあえず当面は双方向でやっていきたいと思います。

2つめのブラウザ以降: インポート + 設定が必要

まず出口みたいなアイコンからプロファイルをエクスポートします。

2つ目のブラウザで拡張機能を導入後、エクスポートしたプロファイルをインポートしたらOKです。インポート後、下矢印アイコンでダウンロードしたら同期されます。

一点注意ですが、同期のタイミングが初期設定では定義されていませんでした。なので「設定」から「変更ベースの同期」と「時間ベースの同期」をそれぞれONにします。その後はWebDAV経由で同期されます。

Chromium系とFirefox系の同期

Vivaldiで保存したブックマーク、そのまんまインポートしてBraveでは使えたんですが、Firefoxだとフォルダの指定が必要でした🤔

設定からフォルダーの関連付けでブックマークツールバーを選んでやることで、解決しました。

バックアップ

docker-compose.yml自身と、バインドマウントの設定を記述してますが、そのディレクトリを圧縮してコピーしたらOKです。

自分はバックアップスクリプトで定期実行しています。スクリプトはdocker-compose.ymlをAIに見せたらサクッと書いてくれると思います。そういうのは得意なAI。

所感

dockerでWebDAVサーバをたてたのは地味に初めてで、Geminiに聞いてすぐできるかと思いきや、だいぶ間違えたことを言われて転がされました。インフラ絡むと不得意なAI。地味に時間がかかっている。ま、だから記事にも意味があるんですけどね。

性質上、ブックマーク同期はインターネット公開にする必要性は特に感じていません。なのでLAN内限定です。外で使う時にブックマークを激しく変更しないと思いますし、また常に同期用の通信が走るのも邪魔です。もしやるならば、簡単なのは例によってCloudflare Tunnelでしょう。

とりあえずしばらく運用してみようと思います。うまくいくようならEverSyncはいらないですね。

TailscaleでVPSと自宅サーバを繋ぐ

Mon, 19 Jan 2026 00:00:00 +0900

最終的にはサービスのインターネット公開までするつもりだが、その前段階として。

構成

VPS
- Ubuntu 24.04
自宅サーバ
- macOS 14.8.1

graph TD
subgraph VPS
dev2(Ubuntu)
end
subgraph Home
nat(NAT)
subgraph LAN
dev1(Mac)
end
end
tail(TailScale Control Server)
dev2 ---|VPN| nat --- dev1
dev1 -.- tail
dev2 -.- tail

NAT越えの表現が微妙な気がしつつ、登場人物の理解のために。

要はVPNなんですけれど、各デバイスのグローバルIPやポート、公開鍵など管理のためにTailscaleのコントロールサーバが必要になります。つまりサインアップ必須。しかも認証基盤他所に依存してますね。しゃあなしなのでGitHubアカウント使いました。普段のデータ通信は端末間ですが、最初の疎通や、グローバルIPの変更などがあると、管理サーバが必要になるようです。

管理サーバを完全に廃したい場合は、「Headscale」というOSSがあるようですが、今回は試しません。

インストール

バイナリで配布されているので、そのまんま使います。実行後はサインインします。

VPS(Ubuntu)ではCLIなので以下。

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

テスト

Mac側でテスト用のWebサーバ。

echo "<h1>Hello from Home Server (macOS) via Tailscale</h1>" > index.html
# Pythonで一時的に8080ポートを開く
python3 -m http.server 8080

VPS側で疎通確認。

curl http://[ホームサーバのTailscale-IP]:8080

表示されたらOK。

MagicDNS

Tailscaleで割り当てられるIPアドレスは基本的にはスタティックと考えて良いようですが、覚えづらいし、端末の入れ替えなどあるかもしれないし、必ず固定というわけでもない、とか考えると、名前があったほうがよさそうです。

MagicDNSを使うこと絵、IPアドレスではなく名前を指定することができます。

MagicDNS · テールスケールドキュメント

自動翻訳そのまま。

マシン名の割り当てと編集 MagicDNS はデバイスのデバイスを自動的に使用しますマシン名 DNS エントリの一部として。デバイスの名前を変更すると、MagicDNS エントリが自動的に変更されます。

デバイスを参照するために使用する特定の名前がある場合は、マシン名を編集しますデバイスの。

どうやらマシン名がそのまま使えるようです。

curl http://[マシン名]:8080

疎通確認。

ダッシュボードからマシン名を変えることで、任意の名前にできます。

次回はCaddyでリバースプロキシ

想像より随分でした。次は証明書発行までの機能をもつWebサーバCaddyと組み合わせて、Webサイトの外部公開を試みます。

セルフホストを広めたい

Tue, 13 Jan 2026 00:00:00 +0900

10年くらい前に、自宅サーバはもうおしまい、みたいな記事を書きました。あの時はそれが正直な気持ちであったのだけれど、その10年後、自宅サーバをまたやり、あまつさえ隙あらばビッグテック批判記事書きまくってるとは、当時の僕には想像できなかっただろうなぁ。まったく生産的ではない。そもそも生産的な人はブログなんかしません（クソでか主語） 。まぁ、あれから時代も僕も変わったのだよ。

さて、自宅サーバですが、最近はセルフホストと言われることが多いかと思います。これはVPSなんかも含むし、別にホームユースにも限らないのですが、その本質は自宅サーバの精神と同質と思います。いずれにせよ時代に逆行しているので、ビジネスとしては選択されづらいはずで、Redditなんか見てると基本的にはホームユースで好事家が集まっている感じがします。

とても盛り上がっていて、英語ネイティブじゃない自分が恨めしくなります。私が英語をスラスラ読み書きしたいと思うのは、もっぱらRedditであの輪の中に入りたいと思うためで、これはアニメを見て日本語覚える外人の気持ちに近いのかもしれません。匿名掲示板初心者のごとく、今はひたすらROMっております。

そんな感じでセルフホストの情報をちまちま仕入れて試していると、なんだか大昔にフリーソフトを喜んで使っていた頃を思い出して懐かしいですね。というか、こういうソフト作ればいいんじゃないか、と思っては「もうすでにゴージャスなのあるやん」を繰り返しており、つらさもあります。

まぁ使って運用するだけでもけっこう知識はいるものですし、またいろいろ使っていくうちに、誰もやっていない、あるいは自分にしか見えていないところが見えてくるかもしれない、という気持ちでいろいろと試しております。

実際、自分でも確かに何かと苦労するところはあるので、思うほど簡単ではないのかもしれません。セルフホストのアプリを使えば、実際ほとんどのサブスクは不要だとわかり、非常に手軽でかつ費用対効果の高いものですが、帰省の際にPCが好きな姉に勧めてみたのですが、かなり嫌な顔をされました。これを簡単と思うのは、前提となる知識が全然違うからだというようなことを言われました。

そうかもしれません。

それでも、セルフホストは本来あるべきだったソフトウェア文化の本当の進歩に思えます。各家庭で自分でサーバを運営し、自分の責任でもってデータを扱い、自分の責任でもって運営する。これは時流からするととんでもない、ということになるのかもしれません。なんでもかんでもプロにお任せ、が現代的には正しいとされます。これはソフトウェアに限りません。

しかし、たいていのことは案外自分でもできます。たいていのことが難しいのは、あらゆるケースであらゆる人に向けて常に一定以上の品質を保証しようとするからであって、自分（たち）だけが必要な範囲で必要な時だけ必要なことができればいいし、間違えてもつらいの自分、という状況であれば、求められる非機能は格段に落ちます。それこそ手が届く範囲までに。

そんなことをされては困るのが資本主義の論理です。資本主義はGDPとなるような取引を発生させてなんぼですので、自己完結されては困るのです。なので、いらない機能をいるように思わせたり、セキュリティの危機を針小棒大に取り上げて脅しをかけるなどして、ユーザの脳を停止させ、依存させ、不必要な機能を売りつける商売が流行っています。

そうして我々は、いつしか巨大企業に貢ぐばかりで、巨大企業の押しつけがましいサービスを享受する一方、ただ自分のやりたいことだけができない、そんな状態が続いているように思われます。

セルフホストは確かにあらゆる手間がかかりますが、多くの場合費用はほとんどかかりませんし、いらないサービスがないかわりに、ほしい機能を手にすることができます。なんとかこの素晴らしい文化を、広められないものかなぁと思っています。

TimeTagger - Tag your time, get the insight

セルフホストのタグ管理系トラッカーアプリ『TimeTagger』個人ユースなら完璧

Mon, 12 Jan 2026 00:00:00 +0900

Togglを使っていたのですが、あまり使い勝手がよくありませんでした。それで自分で作ろうかと思っていたのですけれど、なんだかすでにセルフホストでありました。

リポジトリはこちら「GitHub - almarklein/timetagger: Tag your time, get the insight」。

Introductionを読んだ時、あまりにも僕が想像していたものとほぼ同じ仕様で、本当に驚きました。完全に同じようなニーズに基づいていたのだと思います。以下はGeminiによる和訳です。

TimeTaggerは、ローカル環境またはサーバー上で動作させることができる、Webベースの時間追跡（タイムトラッキング）ソリューションです。個人やフリーランスの方々を対象としており、以下のような特徴を備えています。

インタラクティブなタイムラインを中心とした、直感的なユーザーインターフェース（UI）。

プロジェクト単位ではなく、タグを使用することによる軽快な操作感。

PDFおよびCSV形式でのレポート作成。

日次、週次、月次の目標設定。

統合されたポモドーロ・メソッド（実験的機能）。

レスポンシブ対応：小さな画面から大きな画面まで、快適に動作します。

デバイス間での同期。

特に「プロジェクト」ではなく「タグ」を使うという発想が、本当に個人の発想であると思います。完全に同じことを考えておりました。ポモドーロについては私は物理的なタイマーを利用していますが、しかしソフトウェア的に連携したいという人もいるでしょう。

インストール

私の環境

Intel Mac mini 2018
macOS 14.8.1
Docker Desktop for Mac 4.55.0

インストール方法は、pipを使ったものとdockerを使ったものがあるようです。また、docker-compose.ymlはroot版とnonroot版があります。常用予定なのでdocker版を使います。LAN内運用ですし、トラブルも少なそうなroot版をここでは見ます。セルフホストについては「How to self-host your time tracker with Docker」に記事があります。

# Example docker-compose file for TimeTagger that uses the published
# Docker image in the default root variant.
# Shows all options settable via the environment.
#
# !! Make sure to apply your own credentials !!
# !! You can use e.g. https://timetagger.app/cred to generate them !!
# !! In docker-compose characters '$' should be escaped as '$$' !!
# !! If you use a .env file, use single quotes instead of escaping !!

services:
 timetagger:
 image: ghcr.io/almarklein/timetagger
 ports:
 - "80:80"
 volumes:
 - ./_timetagger:/root/_timetagger
 environment:
 - TIMETAGGER_BIND=0.0.0.0:80
 - TIMETAGGER_DATADIR=/root/_timetagger
 - TIMETAGGER_LOG_LEVEL=info
 - TIMETAGGER_CREDENTIALS=test:$$2a$$08$$0CD1NFiIbancwWsu3se1v.RNR/b7YeZd71yg3cZ/3whGlyU6Iny5i # test:test

変更点は以下になるかと思います。

ポート
バインドマウントするディレクトリ
クレデンシャル

一点加えるならrestart: unless-stoppedになるでしょうか。

クレデンシャルですが、「https://timetagger.app/cred」でユーザ名とパスワードをフォームに入力すると、コピペ用のハッシュ化されたものが作れます。docker-compose.yml向けは3つ目の$をエスケープしたやつになります。

そしたらhttp://IPアドレス:ポートにアクセスしてログイン。記事には「ログインパスワードはそのまんま送ってるんでhttpsを強く推奨」とあるが、うーんそのうちw

まぁLAN内なので。LAN内で通信傍受されている場合、なんかもうタイムトラッカーアプリのログインパスワードとかそれどころではない大変なことになっているので……。

適当に動かす

とりあえずトラックしてみる。

ほーん。タグは自分で#つけて書くらしい。

PDFでレポート出力。

うん。やりたいことだいたい全部できますね。個人で使う分にはこれぐらいでいいんだよという感じがします。

バックアップ

docker-compose.ymlで指定したマウント先に、jwtとSQLiteのデータベースファイルがあるだけです。なので、docker用ファイルとディレクトリをコピーするだけでバックアップ完了です。良いですね。

所感

あまりにも想像していたものそのもので、驚いてしまいました。一点異なるのは、私は複数のタスクを同時に登録できるようなものを考えていたことなのですが、こうしてみると余分な機能に思えました。

素晴らしいことだなぁと有り難く思う反面、なんかもう全部OSSであるやんけ僕何したらええねんというお気持ちもあります。

ひとまず使っていきたいと思います。

<その他セルフホスト関係の記事>

The Free Software Media System | Jellyfin

セルフホストのすゝめ（工事中）

/selfhosted-susume/

Google Photoの代替Immichをセルフホストで試す

Mon, 05 Jan 2026 00:00:00 +0900

写真管理にあまりこだわりがなかったので後回しにしていたが、なんとなく思い立ってセルフホストのフォト管理アプリImmichをインストールした。Google Photoの代替としても有名。これで子供とのお風呂写真をあげても絶対に垢BANされないね。独身だけど。

使い始めたばかりなので、肌感はこれからになるけれど、とりあえず楽だった（小並感）。docker compose一発でとてもよかった。

こんな感じ

インストールするとこんな感じ。

完全にGoogle Photoで笑った。なのでまぁそのまんま操作できるかと思われる。ストレージ容量がなんかバグってる。鍵付きフォルダー設定できる。外部公開用のドメインも設定から別途設定できる。

アップロードしたファイルの実体は、.envで設定するUPLOAD_LOCATIONにあるのだが（初期設定は ./library）ランダムっぽい数字で深い階層になる。なのでDB_DATA_LOCATIONも合わせてバックアップする必要がある。

インストール

ドキュメントにあるとおりでまったくハマるところがなかったため、書くことがないのだが、とりあえずドキュメント「Quick start | Immich」

.envを編集するだけだね。強いて言えば、macOSで外部ストレージをマウント先にするとエラー出た。まぁそうか。

バックアップとリストア

インストールはすぐできるが、問題はバックアップとリストア手順のほうかと思う。これのドキュメントは「Backup and Restore | Immich」にある。3-2-1戦略については汎用知識なのでAIに書かせた「バックアップ戦略 3-2-1ルール」を参照。

バックアップ

バックアップすべきものは大きく分けて

docker-compose.ymlと.env
データの実体 (UPLOAD_LOCATION)
データベース（自動）

となる。このうち、データベースは初期設定で自動的に吐き出されるようになっているはずだ。管理設定から確認することができる。

で、これの行先は UPLOAD_LOCATION/backupsなので、結果的には UPLOAD_LOCATIONのフォルダをそのまんまコピーすればよい設計だ。

リストア

リストアについては、まっさらな状態を最初につくる。新しいマシンなら何もしなくていいし、既に残滓があるならば一度 docker compose down -vでボリュームを削除する。以下手順をAIにまとめさせた。

バックアップファイルが /path/to/backup/dump.sql.gz にあると仮定した手順です。

事前準備: コンテナの設定ファイルとファイル（写真データ）を戻す

docker-compose.ymlと.envを配置します。

バックアップしておいた UPLOAD_LOCATION のフォルダを、docker-compose.yml で指定しているパスに配置し直しておきます。

ステップ1：既存のコンテナ環境をクリーンにする

まず、既存のコンテナとDBボリュームを完全に削除します。

docker compose down -v

ステップ2：コンテナを準備してDBだけ起動する

サーバー（app）が動き出す前にDBにデータを流し込む必要があるため、個別に操作します。

docker compose pull # 最新イメージを取得
docker compose create # コンテナを作成（起動はしない）
docker start immich_postgres # DBコンテナだけを起動
sleep 10 # DBが完全に立ち上がるまで10秒ほど待機

ステップ3：バックアップデータを流し込む（重要）

ここが一番複雑なコマンドです。解凍しながら、DBのパス設定を書き換えつつ、コンテナ内のPostgreSQLに流し込みます。

gunzip --stdout "/path/to/backup/dump.sql.gz" \
| sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
| docker exec -i immich_postgres psql --dbname=postgres --username=postgres

※--username=postgres の部分は、.envで変更している場合はその名前に変えてください。
※sed を挟んでいるのは、Immichのリストア時に発生しやすい検索パスの不整合（テーブルが見つからないエラー）を防ぐためです。

ステップ4：すべてのサービスを起動する

DBのリストアが終わったら、残りのコンテナをすべて起動します。

docker compose up -d

所感

割と重めのセルフホストなので、基本的にはLAN内にあるPCでの公開になるのではなかろうか。http接続前提だったし、実際そういう人向けなのだと思う。インターネット使っちゃうと通信費用も馬鹿にならないしね。とはいえ外部公開用URL設定などもあるし、本当にGoogle Photoみたいな使い方もまぁできるだろう。

個人的には基本的にはLAN内でよく、まぁせいぜい帰省とかで人に見せたいと思った時に、一時的にCloudflare Tunnelなりなんなりで公開する、くらいかなぁ（このCloudflaret Tunnel依存しているのも、できるだけ早くやめたいところだ）。

現在ディレクトリで管理していた写真画像を、Immich管理にしていいかどうかは悩ましい。ディレクトリはディレクトリで検索のしやすさがあるのも事実なんよね。

とはいえ雑に撮影した写真とかにいちいち名前つけるのもなんだかなぁ、というのも事実なので、やはり用途でわけるのがいいのかもしれない。

Jellyfinでメディアサーバ、セルフホスト最初の一歩に一番いいかも

Tue, 30 Dec 2025 00:00:00 +0900

Jellyfinの名前は知っていたが、特にメディアサーバを持ちたい欲求が最近はなかったので後回しにしていた。しかし、最近YouTubeを開くのもウンザリするようになっており、もう手持ちの動画をループ再生するので良いのではないか……という気持ちになった。

それでJellyfinをインストールしたのだけれど、配布されたバイナリを実行するだけで、かなり拍子抜けしてしまった。

環境

以下で試した。

M2 Pro Mac mini
GMKtec EVO-X2
- Windows 11 Home

Jellyfinはメディアサーバ

Jellyfinは端的にいうとメディアサーバになると思うが、特徴としては以下がある。

Win/Macでバイナリ配布なので秒でインストールできる
- むしろWin/MacではDockerよりバイナリ使ってくれやと公式ドキュメントにあった
ユーザ管理がある（家族でそれぞれ個別に使える、権限設定あり）
UIがYouTubeっぽくて比較的リッチ
ファイルはディレクトリベースの管理 + ライブラリ管理
- メタデータを同一ディレクトリに保存することで可搬性も上がる

個人的なポイントはディレクトリベースであるところだ。ディレクトリ管理最強伝説を思い知らされただけの20年だった。独自管理はダメだ。今どんなに華々しく見えるあのサービスも、絶対終わるか有料化・高騰する。俺の寿命のほうがサービスより長い。

とはいえアプリケーションというのは独自の機能があるからこそであって、その管理にはやはり固有のフォーマットが必要なのも事実である。そんなわけでメタデータからは逃れられないのだけれど、そのメタデータをどう扱うのかがアプリケーションの肝と言える。

Jellyfinの場合、ファイルと同一の場所にメタデータを置くこともできるようなので、そういうことをすればマシン入れ替えなんかの移行も比較的スムーズかもしれない。

インストールの運用の所感：セルフホスト最初の一歩になる？

インストールについては公式サイトからバイナリ落として実行しましたおしまい、なので本当になにもいうことがない。

導入後はWebブラウザでアクセスし、ライブラリを追加すればよい。設定周りはメタデータの運用含めどうするか、ちょっとこの後やりながら最適解を考えていきたい。

一点、シャッフル再生や連続再生をしようとするとエラーが出た。

すべてのフォルダの起きるわけではなくて、なんだかファイルとフォルダが入り混じっているとか、ファイルの量が多いフォルダで起きている気がする。300以上の動画ファイルがあったものを分割すると、シャッフル再生できるようになったので。ちゃんと階層つくるのが重要になるかな。

他のも試したい

メディアサーバは色々あるので、他のも試していきたい。当面はフォルダの整理を進めつつ、ある程度わかってきたら「stashapp/stash: An organizer for your porn, written in Go. Documentation: https://docs.stashapp.cc」とかも試したい。

脱Gmailの道も一件から：1日1件アカウント変更

Sun, 28 Dec 2025 00:00:00 +0900

少し前にConoHaのアプリケーションサーバでメールサーバを契約し、独自ドメインのメールアドレスを取得した。存外勝手が良かったので、そのまま常用している。ただ毎月605円->年間7,260円というのはまぁまぁの出費なので、自宅サーバかVPSにしたい気はする。

今は脱Gmailを続けている。現実にはアカウントを終わらせること自体は厳しいと思うのだけれど、メールについては利用を少しずつ独自ドメインのメールに移している。

@gmail.comに届くメルマガを減らしていく

脱Gmailは技術的には何も難しいことではなく、気合と根性と覚悟の世界になる。

具体的には、受信メールのうちgmail.com宛に届くものについて、その原因を一つ一つ潰していく感じだ。この作業は地味で泥臭く、また時間がかかる。したがって、この作業は年単位で向き合っていくものになる。

自分はルーティンとして「1日1個はGmail登録を独自ドメインメールアドレスに変更」をだいぶ長いこと繰り返している。おかげでgmail宛のメールアドレスは随分と減ってきた。というかみてみると、アカウントを取ったことすら忘れているものも多く、けっこうな数の退会手続きをした。

また、「このメルマガ正直ちゃんと読んだことねぇよ」みたいなのも多くあり、それらの配信停止もした。メルマガに配信停止の表示を差し込むのは法的義務がある（特電法と特商法によるらしい）ようなので、手続きへの誘導自体は確かにあるのだが、手続きの煩雑さはサービスによる。クリック一つで停止できるものもあれば、ログインを要求するもの、さらにそのログインにデバイスによる本人確認を要求するもの、さらに退会手続きが異様に煩雑でリンク先がマニュアルページと最低なものなど、人生いろいろメルマガも色々。

AIに整理できるか？

メールの整理は定期的にすべきことだなと思った。もしかするとそんなめんどくさいことはAIにおまかせ！みたいな方向に社会は持っていきたいのかもしれないが、自分が何に登録したのかは、多分自分自身が把握するべきことだ。

とはいえ、メールの履歴から登録しているメルマガの一覧とそれぞれの直近10件みたいなまとめは自動で作ってくれると助かるよなぁ、と思ったりはする。しかしそういうサービスは難しいだろう。理由はビジネスと権限、そしてなによりコストの問題になる。

まずビジネスの観点では、資本主義社会は1通でも多くのメルマガをぶっ飛ばしたいのであって、解除させたいのではない。解除のサポートをしてほしい企業はないし、かといってユーザもそれに金を払うかといえば微妙だ。

次に権限の観点で、さまざまなサーバでされているメールを整理する権限は、実はかなり強力で、クライアントと同然の権限、あるいはすべてのメールを閲覧する権限を与える必要がある。これは既存のいわゆるSaaS的なサービスではだいぶ厳しいだろう。

では既存のメールクライアントアプリの機能としては？これは技術的には筋が良い。現在そういう機能は聞かないが、方向性的にはあり。しかしここで問題になるのは、おそらくすべてのメールをLLMに食わせるコストになる。

APIをある程度使えばわかるが、LLMのコストは存外高い。かといってローカルLLMでやるにも、日本語認知ならやはり120Bとか70Bくらいのパラメータが欲しくなるし、そうするとそれなりのAI PCが必要になってしまう。まぁ僕はそういうことができるPCを持っているので、考えてみると暇つぶしに頑張ってみてもよかったかもしれない。

いつかは自宅サーバ？

書きながら、LLMにメールの整理をさせるのはけっこう良いなぁと思えてきた。自前のアカウントならメールの取得も割合楽にできるし、時間があったらやってみようか。

あと当面はConoHaのアプリケーションサーバを使っているものの、どうせ24時間サーバを動かしているので、自宅サーバにしたい気持ちもある。ただメールの受信となると安定性にまだ自信がない。まぁ2026年の目標かなぁ。

以下、ConoHaの話題でいつも貼るクーポン広告。過去3人くらい登録してくれた人がいる。

お友達紹介

こっから飛んで使い始めてもらったら1000円分のクーポンがもらえる（このとも～友達紹介～｜レンタルサーバーならConoHa）。そして定常的に使ったら僕に2000円分のクーポンが入る。クーポンが入るとなんか色々遊んで適当にレビューするかもしれない。

<関連記事>

/conoha-mail-server/

趣味としての脱Googleその4 Gmail編:「技術的には可能です」……けど

/googlegmail/

脱Dropboxを進めている

Mon, 01 Dec 2025 00:00:00 +0900

随分前に3年契約していたDropboxの契約がそろそろ切れるため、本格的に移行の準備をしている。

移行の理由としては、サブスクの高額さ、不要なインターネット通信、自分のデータを監視される不気味さなどが嫌になったから。Dropbox自体は、他のSaaSと比べると今なお良心的で頑張ってるサービスだとは思っているけどね。まぁ僕はもういいよ。実家に帰らせていただきます。

ここまでにやったことを軽くまとめる。

ファイル同期

ファイルの同期どうするの問題。まずファイル同期については、Dropbox最強伝説には違いなくて、同じ精度で扱えるとは考えないほうがよいのではないか。

QNAP NAS + QSync

特定のハードウェアに思い切り依存しているわけだが、前から持っていたので使っている感じだ。別に商用が嫌なのではなくサブスクが嫌なので、ハードウェアに付属するソフトウェアは個人的にアリだと思っている。

ただまぁ、Dropboxのような精度で同期ができるわけではない。というかDropboxの精度が異常なのだと思う。なのであくまでも「同期できたら便利だよね」というフォルダを狙って使うほうがいいだろう。

LAN内DropboxとはいかないQsyncの使いどころ

/dropbox-qsync/

あちこちに散らばっているフォルダを選択できるのは地味に気に入っている。

Nextcloud

オフィスソフトをWebアプリとして使いたかったので、Collabora Onlineの基盤として以前構築した。ファイル同期もそりゃできる。

/nextcloud-on-mac-collabora-online-web/

ただ構築の手間はけっこうあるし、重いソフトではあるので、常用したい感じではない。Webアプリとしてのオフィスソフトの使い勝手も思ったほどよくなかったので、結局ローカルでいいんじゃないですかとなってしまった。

せっかく構築したので運用はしているものの、QSyncがメインになっており、こちらは本格的に使っているわけではないので、同期の精度なんかはまだよくわかっていない。

Seafile

単にファイル同期したいだけという向きでは、Nextcloudは重たいので、Seafileあたり良いのかなぁと思っていたが、調べるとけっこう苦労されている先人の軌跡など見るにつけ、あんまりやろうという気になっていない（「NextCloudを廃止してSeafileを採用 - Chienomi」）。

まぁNextcloudがあんまりよくないな、ってなったら試してみる感じかなぁ。

Webブラウザから見る

Dropboxの地味に大事な機能として、Webブラウザベースのアクセスがある。

File Browser

名前がまんま過ぎてThe Band的な意気を感じつつ、軽量かつ簡単に構築できて、便利なので、気に入っている。下記記事を書いてから使っているが、特に今のところ不便はない。

WebベースのファイラFile Browserを試す：こういうのでいいんだよ

/web-file-browser/

Nextcloud

Nextcloudを構築するなら、Webブラウザからの操作も可能、というかファイル同期よりこれが一番安定するのはそう。まぁ一番わかりやすく置き換えるならNextcloudなんだろうね。

お外で聴ける音楽サーバ、メディアサーバ

外でスマホから自宅の音楽データをストリーミングで流したい。

WebDAV

WebDAVサーバをたてて、対応しているクライアントアプリを使う。

自分はサーバはQNAPの機能を使い、スマホのクライアントアプリはCloudBeatsを使っている。CloudBeatsはファイルベース管理にストリーミングとダウンロードの機能があって使いやすい。NAT越えはCloudflare Tunnel使っている。気が向いたらVPSで自分でトンネル作るかも。

/android-cloudbeats-qnap-nas-cloudflareで外でnasの音楽をストリーミングオフ/

Nextcloud

Nextcloudもアプリ側で対応していることが多い。

Jellyfin

音楽というよりメディアサーバなわけだが、Cloudflare TunnelなどでNAT越えすれば楽。一番楽かも。

スマホの写真やスクショをPCに転送する

個人的なユースケースとして、スマホやタブレットの写真をPCに転送する、は地味にDropboxの有用な活用ポイントだった。Webベースでアップロードしても別にいいんだが、もうちょっとサクッとPCに転送したいと思った。

KDE Connect

起動して「ファイルを転送する」ですぐ転送できてよい。

Dropbox的な文脈とは関係ないが、PCからスマホ、またはスマホからPCを操作できて便利である。

/kde-connect-lan-android-pc/

Immich

単純なバックアップ用途では多分一番便利。

Google Photo代替的な写真管理ソフトなので、ファイルベースの管理には向いていないものの、実際のところこちらのほうが多くの人のユースケースには合っている気がする。

所感: NASでもいいか

なんかこうして記述していると、けっこうNASを使っているなと思った。まぁもちろん自前で構築することもそりゃできるんだが、面倒くさい。別に僕は金を払いたくないのではなく、サブスクや不要なインターネット通信、自分のデータを監視されるのが嫌なので、NASを買うのに金を払う分には別に、という感じ。いざとなればNextcloud使えるのはわかったし。

まぁ余っているPCをLinuxサーバとして使いたい、という向きなら頑張ればいいだろうが、そうでないなら、NASはそれなりにいいもんなんじゃないか。

[itemlink post_id=“15811”]

GMKtec EVO-X2 + Open WebUI + LM Studio + gpt-oss-120b の手順と雑感

Fri, 21 Nov 2025 00:00:00 +0900

30万円で買ったGMKtec EVO-X2をフル活用するべく、色々といじっている。チャット機能はやはりほしいのでいじる。

環境と構成

ホストマシン
- Intel Mac mini 2018
  - Docker Desktop for Mac 4.51.0
  - Open WebUI
サーバ
- GMKtec EVO-X2
  - Ryzen AI Max+ 395
  - 128GB
  - Windows 11
  - LM Studio 0.3.30
    - gpt-oss-120b

ホストマシンはM2 Pro Mac mini + OrbStackでもやった。

LM Studioはインストールして、モデルを入れているものとする。

ざっくり構成

graph LR
subgraph Mac
subgraph OrbStack
web(Open WebUI)
end
end
subgraph EVO-X2
subgraph LM Studio
gpt(gpt-oss-120b)
end
end
user(User)
user --> web
web --> gpt

ざっくり手順

LM Studio入れてAPI使えるようにする

公式サイトからインストールするだけ。APIサーバは左側のタブの2番目。

IPアドレスとかも表示される。ポート番号は1234。以下で確認する。

curl http://IP:1234/v1/models

EVO-X2 VRAMを64GB -> 96GBにする

一応。

/windows-11-init/

割り当てについてはLM Studioで確認できる。

AMDのソフトウェアからも変更できそうに見えるが、なんぼやっても変更されなかった。結局BIOSだよ。ESC押しまくってBIOSに入ったら、それっぽい項目を探す。それっぽいところに潜っていくと「UMA Frame Buffer Size」という名前のやつがあるから、それ。

Open WebUI のインストール

以下の docker-compose.ymlを作る。ポートは好きなの開ける。

version: '3.8'

services:
 open-webui:
 image: ghcr.io/open-webui/open-webui:main
 container_name: open-webui
 restart: always
 ports:
 - "8080:8080"
 volumes:
 - open-webui:/app/backend/data

# 永続化のためのボリューム定義
volumes:
 open-webui:
 # Dockerにボリュームを管理させるデフォルト設定

http://IPアドレス:ポートにアクセスすると、最初に管理者ユーザを作成することになる。

Open WebUI から LM Studioを繋げる

ユーザアイコンから管理者パネルを開いて、「接続」タブ。

接続タイプ: ローカル
URL: http://LM StudioあるマシンのIPアドレス:1234/v1
認証: なし
Provider TYpe: OpenAI

そしたらチャットで選択できるようになる。

なんか適当に話す。

gpt-oss-120bとの会話の雑感

とりあえず日本語で話す限りは阿呆だなぁと思う。絶妙に話が通じなくて、あまり話す気がしない。GPT-3.5の時はどうだったかなぁ。英語だともうちょっとマシなんだろうか。

Geminiの無料枠は非常に大きいという現状、正直宗教的な理由以外でわざわざgpt-oss-120bを使ってチャットする理由はちょっと思い当たらない。

ツールとかと連携させるなら、使い所あるのかな？うーん。

企業の都合で勝手に変えられない、というのは大きいかも。いくらチューニングしてもアプデで滅茶苦茶になるこんな世の中じゃ。

また、インターネットから隔絶された環境でもけっこうな知にアクセスができる、というのは非常に大きいのではないか、と思われる。いつまでもあると思うなインターネット。真面目な話、ネットに繋がせてもらえない環境は実在するので、そういうところにあると神になると思われる……が、そんなところで30万円するEVO-X2を導入できんか。つらいなぁ。

LAN内のGiteaをCloudflare Tunnel経由で公開する

Tue, 11 Nov 2025 00:00:00 +0900

LAN内でええやんと思っていたのだが、色々と面倒臭くなったので、結局外部公開する。例によってCloudflare Tunnel経由で……。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

構成

graph TD
cfi(Cloudflare)
cfi --> cf
subgraph LAN
cf(Cloudflare Tunnel)
gitea(Gitea)
end
cf -->|プライベートIP| gitea

Giteaから見るとリバースプロキシを噛ませたような感じになる。

手順

サインアップの禁止

Gitea on Macのサインアップ（登録）を禁止する

/gitea-on-mac-signup/

既存リポジトリを最新に反映する

remoteと差分があると面倒くさくなるので、できるだけ最新を反映しておく。

Web画面の設定

Cloudflare TunnelでWebの外部公開用のサブドメインを作成する。

app.iniの[server]より以下となるようにする。

項目	値	説明
`PROTOCOL`	`http`	CloudflareがHTTPSを終端
`HTTP_ADDR`（または`DOMAIN`）	`127.0.0.1`	Giteaが実際に待ち受けるアドレス
`HTTP_PORT`	`3000`	内部ポート（自由）
`ROOT_URL`	`https://git.example.com/`	外部公開URL

https経由ではこれでできる。

（やるなら）sshの設定

sshを使う場合、Cloudflareでssh用の別口のサブドメインを作成し、ssh over httpsでアクセスする。Web用の設定と併せて以下のような感じになる。

[server]
PROTOCOL = http
DOMAIN = 127.0.0.1
HTTP_PORT = Web用ポート
ROOT_URL = https://Web用ドメイン
DISABLE_SSH = false
START_SSH_SERVER = true
SSH_DOMAIN = SSH用ドメイン
SSH_PORT = 22
LFS_START_SERVER = true
LFS_JWT_SECRET = hoge
OFFLINE_MODE = false

サーバーは再起動する。

クライアント側でover httpsをとなるように ~/.ssh/configに以下を入れる。

Host SSH用ドメイン
 ProxyCommand cloudflared access ssh --hostname %h
 User SSHユーザ名

既存のリポジトリでremote変更

現在の設定の確認。

git remove -v

これを置き換える。Web画面からリポジトリを見て、ssh用のcloneコマンドから以下のように置き換え。

git remote set-url origin SSHユーザ名@SSHドメイン:user/repo.git

動作確認。

git fetch origin
git push origin main

リモートにコミットがあってマージするなら git pull --rebase origin master、強制的に上書きするときはgit push -f。

RSSフィードの音声を垂れ流したいが、良いものが見つからないので

Sat, 08 Nov 2025 00:00:00 +0900

あらゆることが出来るのに、やりたいことだけピンポイントが出来ない気がして仕方が無い昨今、関心のある、あるいはあるべきニュースを流し聞き、流し見したいという基本的なニーズは案外満たされない。これに近いのはテレビのニュースかもしれないが、テレビで報道される内容は偏っている……あるいは、偏ってなさすぎており、遠くの強盗事件がわかる一方で、今興味のあるミニPCのセール情報は流れてこない。YouTubeのニュース系ライブも同様（ついでにライブとは名ばかりでループするし、かえって不便）。

個人的に指定した情報源を巡回するものとして、RSSは今なお有効、というかRSSくらいしかないのが実情だ。このためにRSSリーダーを使うことになるが、RSSリーダーは当然RSSを読むものなので、目と手を奪われる。複数端末で使う時は同期の問題も生じる。また、世情のためか、Pro版と称して高い高いサブスクプランに入れさせたがる。

そこで、RSSを音声で垂れ流しできると、それなりの体験になるのではないかと思った。こんなアプリたくさんありそうだ、と思ったのだけれど、調べて見るとそうでもない……というかそういえば、RSSリーダアプリ自体が絶滅危惧種に指定されつつある昨今だったかもしれない。

「RSSを音声で聴きたいという話」のようなのを見ると、音声で聞きたいというニーズのためだけにアプリを作ることになったようなので、スキマだったりするんだろうか。インストールしてみたところ、シンプルで良いアプリだと思ったが、自分の元々あるフィードを登録するような感じではない。というかプレミアムが$15/月でサブスクであるため、対象外になる。

RSSリーダというのは、データ収集・解析と、それを表示して読む・読んだものをマークする、と分かれるわけだが、これを同期しようとしたときに、どうしても中央サーバが必要になり、SaaS的にやろうとするならこれの負荷がしんどい、という実情はわかる。とはいえサブスクならInoreader ProでTTSを使うかな……。

結局のところ、ないんだね、僕がほしいものは。これというのも、サーバの問題がまずあるからだ。サーバの運用負荷を考えると、無料はありえない。わかる。じゃあ、サーバを自分でたてればいいじゃないか、となる。「GitHub - tt-rss/tt-rss: A free, flexible, open-source, web-based news feed (RSS/Atom/other) reader and aggregator.」を今度試してみるか、と思ったが、すると今度はリーダをどうしよう問題が勃発するんだね。これも作るしかないんだろうね。

っていうか、Tiny Tiny RSSの人、止めるみたいね（「Tiny Tiny RSS to shut down as developer ends project entirely by November 1st, 2025 | AlternativeTo」）……やっぱりOSSってたいへんなんだな。

「FreshRSS, a free, self-hostable feeds aggregator」あたりも候補か。APIが使えればなんでもよい。あるいはLAN内なら自作もあるような気はする。

ということで次のセルフホストはRSSサーバ、さようならFeedly、までいけるかどうかはわからない。

Nextcloud on Mac + Collabora OnlineでWebアプリのオフィスをセルフホストで

Tue, 04 Nov 2025 00:00:00 +0900

AIブラウザの台頭で、Webアプリの価値が高まったなぁと思い、オフィスソフトのWebアプリ化が重要に思えてきた。MS Officeは使いたくなかったので、OSSでODFを扱えるCollabora Onlineを使うことにした。するとNextcloudが必要だと言われた。そうかと思ってインストールしようとしたら、NextcloudはDocker DesktopではなくOrbStackが必要だと言われた。

それぞれ苦労したのだが、最後のCollabora Onlineのインストールと接続が一番苦労した……しかしもう後には引けない……。

前提

OrbStack + Nextcloudを前回までの記事で導入済みの前提。

LAN内でMac + Nextcloudを構築する

/lan-mac-nextcloud/

オフィスを動かせるようにする

前回記事の環境と組み合わせる。余計なものは入れない。インストール後の前提。

とりあえずトップページにいく。右上のアイコンから「アプリ」で「アプリバンドル」より、Collabora OnlineとNextcloud Officeを有効にする。

有効化はけっこう時間がかかる。設定いじるとレイアウトが崩れがち。崩れたらコンテナ再起動してCmd + Shift + R。

外部で独立してサーバたてることもできるんだが、Macの都合上ネットワーク問題がけっこうめんどくさいので、ビルトインのほうがいいと思う。ってか、最初独立させてやろうと思ったが、色々苦労してうまくいかず、結局ここに至ったので、大人しくビルトインのほうがいいと思う。

こちらの方が「【Office不要？】NextcloudにCollabora Online入れてみた | 世界Linux新聞」で比較されています。

そして、苦労して入れたが、日本語が表示されない。悲しい。

以下で日本語フォント入れる。

docker exec -u root nextcloud-docker-app-1 bash -lc '
 apt-get update &&
 apt-get install -y fonts-noto-cjk fonts-ipafont-gothic fonts-ipafont-mincho &&
 fc-cache -fv
'

docker compose restart app

表示される。

所感：AIに振り回された感もある

つらかった。久しぶりになんかサーバ周りで格闘した。10回はインストールしなおしたんじゃないだろうか……。

ここまでしてできることは所詮オフィスのWebアプリ。これは確かに流行らない。というか構築はまだいいけれど、今後運用始まったらどうなるのか……。

ただ、AIに振り回されたような気もするなぁ。無茶なポートの開け方を前提にしてきたり、存在しないバージョン番号を指定してきたり、複数OSの情報をごちゃ混ぜにして出してきたり（というかLinuxの情報が強くききすぎているのだと思う）。何回ちゃぶ台返したか。

まぁなんか、疲れた……。

LAN内でMac + Nextcloudを構築する

Mon, 03 Nov 2025 00:00:00 +0900

やりたいことはCollabora Onlineの利用なんだけれど、そのための基盤としてNextcloudが必要だったので。Collabora Onlineを使いたい人はあまりいない気もするので、この記事はNextcloudまでで独立。Collabora Online構築すること前提の設定になっている。

環境

M2 Pro Mac mini
- macOS Sonoma 14.7.7
OrbStack 2.0.4

LAN 内運用が基本。AIO(All in One)は証明書発行とか色々あってむしろやりづらいので、イチから作ったほうがよし。

公式によると、Docker DesktopではなくOrbStack推奨とのことだった。OrbStackの入れ方は以下の記事。

Docker Desktop for Mac → Orbstackへ移行する

/docker-desktop-orbstack/

サーバインストール手順

ディレクトリつくる。

mkdir ~/nextcloud-docker
cd ~/nextcloud-docker

docker-compose.ymlつくる。DBはポスグレ。パスワード変える。ポートは初期設定だと8080なんだが、使いたくなかったので21180にしている。

nextcloudとDBのバージョンは固定している。最初latestでやったのだが、なにかぶっ壊れていて画像の閲覧すら失敗する始末だった。固定したほうがいいと思う。

services:
 db:
 image: postgres:15.8
 restart: always
 environment:
 POSTGRES_USER: nextcloud
 POSTGRES_PASSWORD: パスワード # <----------変更
 POSTGRES_DB: nextcloud
 volumes:
 - db_data:/var/lib/postgresql/data

 app:
 image: nextcloud:28-fpm
 restart: always
 volumes:
 - nextcloud_data:/var/www/html
 depends_on:
 - db

 web:
 image: nginx:stable
 restart: always
 ports:
 - "21180:80" # <-----------変更
 volumes:
 - nextcloud_data:/var/www/html:ro
 - ./nginx.conf:/etc/nginx/conf.d/default.conf
 depends_on:
 - app

volumes:
 db_data:
 nextcloud_data:

リバースプロキシするnginx.confをつくる。

server {
 listen 80;
 server_name localhost;

 root /var/www/html;
 index index.php;

 client_max_body_size 512M;
 fastcgi_buffers 16 16k;
 fastcgi_buffer_size 32k;

 location / {
 try_files $uri $uri/ /index.php$is_args$args;

 proxy_set_header Host $host;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Real-IP $remote_addr;
 }

 location ~ \.php(?:$|/) {
 fastcgi_split_path_info ^(.+\.php)(/.+)$;
 include fastcgi_params;
 fastcgi_pass app:9000;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_param PATH_INFO $fastcgi_path_info;
 fastcgi_intercept_errors on;
 fastcgi_request_buffering off;
 fastcgi_read_timeout 300;

 fastcgi_param HTTPS off;
 fastcgi_param HTTP_X_FORWARDED_PROTO $scheme;
 fastcgi_param HTTP_X_FORWARDED_HOST $host;
 fastcgi_param HTTP_X_FORWARDED_SERVER $host;
 }

 location ~* \.(?:css|js|woff2?|svg|gif|map)$ {
 try_files $uri /index.php$request_uri;
 add_header Cache-Control "public, max-age=15778463";
 access_log off;
 }

 gzip on;
 gzip_vary on;
 gzip_comp_level 4;
 gzip_types text/plain text/css application/javascript application/json image/svg+xml application/xml+rss;

 location ~ /\.ht {
 deny all;
 }
}

実行。

docker compose up -d

http://localhost:21180で初期セットアップ画面にアクセスできる。管理者ユーザ名とパスワードは適当に決めつつ、データベースの設定をPostgresにしつつ、設定ファイルとあわせる。

項目	値
データベースユーザー	`nextcloud`
データベースパスワード	変更したパスワード
データベース名	`nextcloud`
データベースホスト	`db`

次、推奨アプリはスキップする。

ダッシュボードが表示されたらサーバは準備完了。

動作確認

とりあえずファイルからpngとかpdfのviewerが機能することを確認する。

この時点ではdocxとかはまだ使えない。

IPアドレスでアクセスできるようにする

このままだとlocalhostからしかアクセスできないので。設定ファイルを書き換える。

docker compose exec -u www-data app php occ config:system:set trusted_domains 1 --value=IPアドレス

コンテナは再起動する。

docker compose down
docker compose up -d

(ミスった時) クリーンインストール

けっこう何度か再インストールすることになってしまった。全削除。

docker compose down -v

止めてるやつ全部消していいならprune -aしたらスッキリ（自己責任）

docker system prune -a

クライアント側

クライアント側は「Download and install Nextcloud」よりアプリをダウンロードしてインストール。

実行すると、サーバのIPアドレスについて聞かれるので、ここまでに設定したIPアドレス:ポート番号を入力すると、ログイン&許可を求められるので、ログインして許可すればOK。同期フォルダを選択すれば、後はDropbox感覚でいける。

所感

色々とハマった。最初All in Oneパッケージでやろうと思ったが、余計なことしすぎていて、LAN内で必要なことだけしたい自分にはむしろ設定がしんどかった。AIにもかなり嘘をつかれた……いったい昔より楽になったのかわからない。昔だったら検索したらドンピシャな記事が出てきたもんだけどな……。あと証明書とかいうバカバカしい問題に取り組まなくて済んだわけだし。

とりあえず1日が消えた。ここまで苦労してやる意味があるのかと思った。まぁ苦労したのは次の記事でやるCollabora Onlineを設定があったからではあるんだが……。

Gitea on Macのサインアップ（登録）を禁止する

Wed, 29 Oct 2025 13:05:37 +0900

大した内容ではない。GiteaをずっとLAN内で運用していたが、やはりそれだと不便なので外部公開の必要を感じた。とはいえお一人様なのでサインアップはさせたくない。ので、設定するだけ。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

手順

まず現状を確認する。右上に登録がある。

これを殺す。とりあえずサービスを止める。

brew services stop gitea

app.iniを書き換える。brew servicesを使っている場合はps axでわかるとおり以下となる。

58271 ?? S 0:00.75 /opt/homebrew/opt/gitea/bin/gitea web --work-path /opt/homebrew/var/gitea

そんなわけで以下を編集する。

emacs /opt/homebrew/var/gitea/custom/conf/app.ini

そうしたら[service]セクションより以下の項目を操作する。

[service]
DISABLE_REGISTRATION = true

いけたらサービス再起動。

brew services start gitea

Web画面を確認する。

右上から「登録」が消えていることを確認。これでOK。

脱クラウドとは何か

Mon, 27 Oct 2025 00:00:00 +0900

最近、サイトのビッグテーマとして、脱クラウドを掲げセルフホスト的な記事を書いていこうかなと思っている。ってか脱SaaSというほうがいいかもしれんね。

なんにせよ、そもそも脱クラウドとは何か？という問題があるかなぁ、とは思った。たとえば僕はガンガンCloudflare Tunnelを使っているし、またそれを前提とした構成を書いていくことになるのだが、脱クラウドなのにCloudflare Tunnelは使っていいの？という疑問は浮かぶように思われた。

これについての回答は、Cloudflare Tunnelの仕事は本質的に置き換え可能だから問題ない、となる。Cloudflare Tunnelは色々やっているが、その本質的なコアはNAT越えとTLS終端だと思う。特にセルフホスト的な見方だとそうなる。これらはいずれも面倒くさいだけで、できないものではない。面倒くさいだけで。まぁ本当にしんどい。しんどかったので自宅サーバはおしまいみたいなこと考えていた。

脱クラウドとは、Webサービスを使わないことではないし、インターネットの外に出て行かないことではない。重要なことは、選択肢を奪われないことだ。つまり、置き換えられないものをできるだけ使わない、といえる。置き換えが難しいのは、たとえばデータや人間関係（信頼関係）を中央集権サーバに預けるようなものだ。その手のクラウドサービスは、データと人間関係を人質を取られているような感じなのでできれば避けたい。ビジネスロジックを預けるのも危険度は上がる。ロジックは頑張ればなんとかなると思うけど。データと人間関係については、リセットの覚悟が必要になるね。

表にすると、以下のようにまとめられる。

軸	依存の種類	判定
データ	ストレージ・メタデータ・履歴を預けているか	危険
関係	ID・アカウント・フォロー構造を預けているか	超危険
ロジック	ビジネスルール・自動化・運用を預けているか	注意
経路	通信や転送の経路を借りているだけか	安全寄り

Cloudflare Tunnelのコアは経路に相当する。なので、別に問題ない、という判断。本格的に機能を使い始めるとロジックも預けちゃうと思うけどね。そうしたら依存度は上がるね。

まぁでも、別に依存すること自体をああだこうだ言う気はないんだ。それぞれ事情があるだろうし。僕も使ってるし依存している——というより気づかない間に依存していた——サービスなんていっぱいあるし。そもそもDNSに依存してるし。経路は安全寄りといったけど、DNSだけは別……というかDNSはその本質が関係なんだよねぇ。

いずれにせよ、何かしら依存しないとWebは成り立たないのはそう。っていうか普通に使っていると相当依存するよね。だからこそ脱クラウドとか言い始めているわけで、クラウド依存していなければそもそも脱する必要がない。

逆説的に、脱クラウドとはクラウド依存患者であることの告白である。そして何故依存したのか？という個人的な問いなしに脱クラウドはありえない。そこには必ず何かを求めた経緯があるはずだ。それと向き合って、現実を見て、過去を振り返り、未来を考えて、何を求めたのか、求めたものは得られたのか、得られていないのか、まだ求めているのか、これからも求めるのか、そもそも本当に求めていたのか、そういう問いかけは必ずいる。

ゼロイチじゃないので、何をどうするのか、都度自分の判断になる。ああしろこうしろという気はまったくないし、逆に言われる気もない。各自勝手にやるがいい。あるいは、勝手にやれるべきだ。まぁそんな感じだよ。

<関連記事>

セルフホストDify のナレッジにAPIでドキュメントを追加する

Thu, 23 Oct 2025 00:00:00 +0900

確かにDify色々いじれるのは便利。

環境

以下を実行済みとし、環境も同一。

セルフホストでDify + ローカルLLM + RAG

/dify-local-llm-rag/

手順

環境変数の設定

以下を環境変数として設定する。ナレッジのドキュメントを選択すると、左下に「サービスAPI」があるので、そこを見るとURIがわかる。シークレットキーを発行することもできる。

DIFY_API_BASE: http://ベースURL:ポート/v1
DIFY_DATASET_ID: ドキュメントを選択したURLの datasets/{ID} のIDの部分
DIFY_KNOWLEDGE_API_KEY

1個ずつアップロードするスクリプト

まずアップロード用のスクリプト。これは1つだけアップロードする。この手の糞コードは全部AIになった。チャンク識別子はデフォルトの\n\nとなる。

#!/usr/bin/env python3
import argparse
import os
import json
import requests
from pathlib import Path

# --- 設定 ---
API_BASE = os.environ.get("DIFY_API_BASE")
DATASET_ID = os.environ.get("DIFY_DATASET_ID")
API_KEY = os.environ.get("DIFY_KNOWLEDGE_API_KEY")

def upload_md(md_path: str):
 if not API_KEY:
 raise RuntimeError("環境変数 DIFY_KNOWLEDGE_API_KEY が設定されてない。")

 endpoint = f"{API_BASE}/datasets/{DATASET_ID}/document/create-by-file"
 headers = {"Authorization": f"Bearer {API_KEY}"}

 data = {
 "indexing_technique": "high_quality",
 "process_rule": {"mode": "automatic"}
 }

 with open(md_path, "rb") as f:
 files = {
 "data": (None, json.dumps(data), "text/plain"),
 "file": (Path(md_path).name, f)
 }
 resp = requests.post(endpoint, headers=headers, files=files, timeout=120)

 if resp.status_code == 200:
 print(f"OK: {md_path}")
 else:
 print(f"NG: {md_path} ({resp.status_code}) -> {resp.text}")

if __name__ == "__main__":
 parser = argparse.ArgumentParser(description="Upload one .md file to Dify Knowledge Base")
 parser.add_argument("file", help="Path to markdown file")
 args = parser.parse_args()

 upload_md(args.file)

実行する。

python upload_md.py file.md

md_filesディレクトリにあるmdファイルを全部やる場合はシェルスクリプトで以下。

find .md_files/ "*.md" -exec python upload_md.py {} \;

5-10KBのアイテムを1600ほど（合計10MB弱）だったけど、けっこうすぐに利用可能になったね。

チャンク識別子を変える

process_ruleのmodeをcustomにする。たとえば、以下はMarkdownの##をチャンク識別子とした時のもの。

#!/usr/bin/env python3
import argparse
import os
import json
import requests
from pathlib import Path

# --- 設定 ---
API_BASE = os.environ.get("DIFY_API_BASE")
DATASET_ID = os.environ.get("DIFY_DATASET_ID")
API_KEY = os.environ.get("DIFY_KNOWLEDGE_API_KEY")

def build_process_rule(separator_regex: str | None) -> dict:
 if not separator_regex:
 return {"mode": "automatic"}

 return {
 "mode": "custom",
 "rules": {
 "pre_processing_rules": [],
 "segmentation": {
 "separator": separator_regex,
 "max_tokens": 600,
 "chunk_overlap": 80,
 }
 }
 }

def upload_md(md_path: str, separator_regex: str | None):
 if not API_KEY:
 raise RuntimeError("環境変数 DIFY_KNOWLEDGE_API_KEY が設定されてない。")

 endpoint = f"{API_BASE}/datasets/{DATASET_ID}/document/create-by-file"
 headers = {"Authorization": f"Bearer {API_KEY}"}

 data = {
 "indexing_technique": "high_quality",
 "process_rule": build_process_rule(separator_regex)
 }

 with open(md_path, "rb") as f:
 files = {
 "data": (None, json.dumps(data), "application/json"),
 "file": (Path(md_path).name, f)
 }
 resp = requests.post(endpoint, headers=headers, files=files, timeout=120)

 if resp.status_code == 200:
 print(f"OK: {md_path}")
 else:
 print(f"NG: {md_path} ({resp.status_code}) -> {resp.text}")

if __name__ == "__main__":
 parser = argparse.ArgumentParser(description="Upload one .md file to Dify Knowledge Base")
 parser.add_argument("file", help="Path to markdown file")
 parser.add_argument(
 "--chunk-separator",
 help=r"Regex for chunking (e.g. '(?m)^##\s+' or '(?m)^(##|###)\s+'). Empty string to use automatic chunking."
 )
 args = parser.parse_args()

 default_regex = r"(?m)^(##|###)\s+"
 separator = args.chunk_separator if args.chunk_separator is not None else default_regex
 if separator == "":
 separator = None

 upload_md(args.file, separator)

セルフホストでDify + ローカルLLM + RAG

Wed, 22 Oct 2025 00:00:00 +0900

今さらRAGやる。サクッと試すならDifyかなということで、またローカルLLMとローカルデータベースにこだわりを見せてやる。

環境

M2 Pro Mac mini
- 12コアCPU、19コアGPU
- RAM 32GB
- macOS Sonoma 14.7.7
LLM
- ollama 0.12.5
  - deepseek-r1:14b
  - deepseek-r1:32b

ollamaは使っていること前提。

ollamaを別マシンで動かす場合、Macの場合は以下を実行する。(Integrate Local Models Deployed by Ollama - Dify Docs)

# M2 Pro Mac mini側でターミナル実行
launchctl setenv OLLAMA_HOST "0.0.0.0"

手順

インストール

git clone https://github.com/langgenius/dify.git
cd dify/docker

環境変数を設定する。

# 新しいキーを生成
openssl rand -base64 42

# envを編集する
cp .env.example .env
emacs .env

# 生成された値を.envファイルの以下の行に設定
SECRET_KEY=<生成された値をここに貼り付け>

# ポート変更する場合: デフォルトは80
EXPOSE_NGINX_PORT=好きなポートにする

Difyの起動。

docker compose up -d
docker compose ps

すべてのサービスがrunningになっていればOK。

セットアップからollama連携

ブラウザで以下にアクセス

http://localhost:設定したポート/install

（デフォで0.0.0.0で待ち受けるのでIPアドレスでもよい）

アカウントとか作成。

ollamaのほうも準備する。モデルは好きな物を使えばいいがたとえば以下。

# LLMモデル
ollama pull deepseek-r1:14b

# 埋め込みモデル（RAG用）
ollama pull nomic-embed-text

Dify側でOllamaを設定する。

Difyにログイン
右上のアイコン → 設定
モデルプロバイダー
Ollama を選択
接続情報を入力（下図）

Mac/Windows (Docker Desktop):

http://host.docker.internal:11434

他マシンで開放している場合はIPアドレス

Linux:

http://172.17.0.1:11434

モデル名を入力（例: deepseek-r1:14b）
保存

埋め込みモデルも同様に設定する。

動作確認(LLM)

スタジオより新しく作成
チャットフロー選択
hi

返事がきたらOK。

動作確認(RAG)

「ナレッジ」より新しくナレッジを追加する。どうするかなと思ったけど、とりあえず下記の記事をナレッジにする。

/android-pc-ssh/

コイツをMarkdownにして登録する。

登録してからしばらく待つことになる。

待ったら使える。

整ったら、再びスタジオよりチャットを新規作成。

ブロックから「知識探索」を追加して、開始とLLMの間に置く。知識探索ブロックにさっき作ったナレッジを設定。LLMに繋いで、LLMで知識探索の結果を使うように「コンテクスト」と「プロンプト」の設定をする。

そしたらプレビューより「Androidでssh使いたい」と聞いてみる。頑張れ……！Mac miniがんばれ……！

頑張った。Mac mini頑張った。結果は微妙だけど一応ちゃんと使っている感ある。

内容的には、独自ドメインについて記述したconfigの設定すっ飛ばしているため、意味不明な回答となっている。意味不明だが、一応ナレッジを使っている、ということは言える。

所感

とりあえず動くことはわかった。ここから先はノウハウの世界になる。チャンクの粒度はどうするのか、そもそも元の文章に手を入れる必要があるんじゃないのか、どのナレッジを使うか選択するエージェントが必要なのか……。

……原理的には結局フレーム問題のような気がする。このナレッジのこの部分を使うべきだとわかればそりゃできるだろうが……。完全なFAQデータベースがあり、1つのFAQを引っ張ってくるだけなら、多分いけるんだろうけれど。

しかし先ず問題は、その整然とされたナレッジは誰がどうやって用意するのか。次の問題は、本当にユーザが求めているのはそのナレッジなのか。多くの場合、ユーザは自分の本当のQをわかっていない。

うーん、不毛な感じがあるが……まぁもうちょっといじるしかないか。

ConoHaのメールサーバ（アプリケーションサーバ）をやってみたが簡単過ぎて言うことがない

Wed, 24 Sep 2025 00:00:00 +0900

うちのブログはConoHaのVPS上に構築しており、特に不満もないので、折に触れてConoHaの宣伝をしている。で、うちのサイトから契約して使ってみた人もいたようで、有り難いことにクーポンをもらった。

もらったからには何かしら試して報告しないとなぁと思ったものの、既にVPSは契約しているしどうしたもんかな、と思ったところで、前々から気になっていたアプリケーションサーバのメールサーバを試してみることにした。

なんか引っかかるかなと思ったのだけれど、契約して30分で普通にGmailと送受信できて拍子抜けしている。言うことがない。

契約から設定

言うことがない、ではあまりにもなんなので、もう少し何か言うことにする。

契約

まず契約の仕方はコンソール画面から、サーバー追加でメールサーバを選ぶ。以上。

スナック菓子感覚で契約

起動したら、コンソールからメールサーバを選んで設定していく。手順は「メールサーバーで独自ドメインを使う｜ConoHa VPSサポート」にあるけどさらっと書く。

「ドメインリスト」で+ドメインして、持っているドメインを追加する。

追加したらその下の「メールアドレスリスト」でほしいメールアドレスを追加する。

DNSの設定

で、早速使っていきたいところだが、ここでMX/DKIM/SPF/DMARCの設定をDNSでしないといけない。MXはともかくDKIM/SPF/DMARCはなんぞ、という人もいると思われるが、これが何かについては下記の記事を参照。やらないと迷惑メール扱いになる可能性が上がってしまうのでやろう。個人的にはあんまり意味ないと思っているがこれも時代なので仕方が無い。

独自ドメインでメールするために、DKIM/SPF/DMARCのお勉強

/dkim-spf-dmarc/

作成したメールアドレスを開くと、DNS情報としてDKIMとSPFの情報があるので、それぞれホストと値をコピペして、各々が管理しているレジストラないしリセラーのところで編集作業。特に指定はない。ConoHaのDNSサービスを使わなくて良い。僕はCloudflareに隷従している。

MX: 「サーバー情報」に載ってるやつを記載。優先度は10でいんじゃない
DKIM: メールアドレスを選択して載ってるv=DKIM1うんたらみたいなやつ
SPF: 同上。v=SPF1みたいなの
DMARC: 名前は「_dmarc 」で値は「“v=DMARC1; p=none”」（小声）
- ちゃんとやるなら、ちゃんとやる

特にハマるところはないと思うんだが、既にレコード登録されている場合は削除が必要。設定した覚えなくても、各地を転々としていると設定されていることもある。実際、今回いじった時、以前レンサバ使っていた時に設定されたのか、MXとSPFのレコードが既に登録してあった。そういうこともある。

メールクライアントで試す

コンソール画面よりメールアドレスを選択すると、接続先サーバでPOP、SMTP、IMAPのメールサーバのドメインが載っている。ので、アカウントとパスワード情報を持ち寄って設定。ポート番号とかの設定は「メールサーバーで独自ドメインを使う｜ConoHa VPSサポート」の下部にあるけど、たいていのクライアントでは自動でいけるんじゃないか。Macのメール.appとVivaldiで試したが、どちらもつつがなく認識された。

送受信のテストはもちろんGmail。コイツがいけたらだいたいいけるだろう。いきなり送信もなんなので受信から。受信できたら送信して返す。送信を確認できたら動作確認完了。

所感：楽には違いない

ということで一通り完了です。契約してから30分くらいで送受信できてビックリした。っていうかDNSの反映も随分と早くなったものだね。確かに楽には違いない。楽ではあるが、600円/月と言われるとちょっと躊躇う。年間7,200円だからなぁ。

まぁせっかくなのでもうちょっと使ってみるかね。ってか結局長期運用しないと実態はわからないからなぁ。これだけじゃただのやってみた記事だし。まか今回はとりあえずサクッとやってみれたということで。

折を見てプログラムから送信くらいはするか。ブログドメインhack-le.comでメルマガでもやったろうか。誰も登録しない。

最後にいつものクーポン広告だが、以下のリンクです。

お友達紹介

Slack/Teams代替？セルフホストできるチャットサービス Campfire を軽く試す

Mon, 22 Sep 2025 00:00:00 +0900

Redditで何か話題になってたので。OnceのCampfireはざっくり言うならSlackやTeamsのようなチャットツールと言うと多分通りがよいと思われる。OSSで、自分でサーバたてられるのが特徴。現実的にはRuby on Railsの会社っていうのが一番の気もしつつ。

チャットできるやつちょっとほしいなと思っていたので、軽くローカルで試した。ほんとに軽く。。。メッセージの送受信とbotだけ。。。

環境

M2 Pro Mac mini
macOS Sonoma 14.7.7
Docker Desktop 4.43.2

インストール（最小限）

とりあえず「basecamp/once-campfire」からcloneする。その後、本当に最小限、ローカルで動作を確認することだけを目的にした起動。

# クローン
git clone https://github.com/basecamp/once-campfire.git
cd once-campfire

# 秘密鍵を生成
export SECRET_KEY_BASE=$(openssl rand -hex 64)

# ビルド
docker build -t campfire .

# 実行（SSL無効でローカルテスト）
docker run \
 --publish 3000:80 \
 --volume campfire-storage:/rails/storage \
 --env SECRET_KEY_BASE=$SECRET_KEY_BASE \
 --env DISABLE_SSL=true \
 campfire

SSL切ってるし通知も切ってる。とにかく動作を見たかった。

動作確認

最初、管理者の設定となる。例によってポート3000にアクセスし、名前、メールアドレス、パスワードを入力してログイン。

開くといきなりチャットルームになる。これは全員参加。適当に話すと適当にチャットできる。

新しい人を参加させるには、参加者が招待URLを送る方式。これは管理者じゃなくてもできるようだ。なので、参加URLを知っている人なら誰でも参加できる模様。招待URLはいつでも更新可能。

ただし、参加後に閲覧できるルームは管理者が制御する。逆に言うと、ルームごとのアカウント制御を管理者が適切にする方式っぽいね。

参加したあとはまんまSlack。

全員自分。そしてbot。悲しい。

botは設定画面の、右上にあるロボットっぽいアイコンから設定することが可能。

Webhook URLはレスポンスほしい時の投げ先なので、投稿するだけなら空でよし。設定するとcurlのサンプルがあるので、実行するとtestロボットが投稿。つまりこれもURL知ってるとできる感じだね。なんかあったらURL変えたらええやろのスタンスか。

こんな感じ。

所感

ということでマジでインストールしてちょっといじっただけなので、これからちょいちょいと触っていきたい。

所感としては、なんというか、本当にシンプルなんだけれど、それ以上に人を信頼してるシステムだなぁと思った。さすがというべきなのか。

管理人がルームごとに参加者の制御と適宜なんかあったらURL変更する運用かな。URL知っていれば参加できるけどルームへの参加は許可がいるし、なんかしたらBANされてURLも変えられるし、それでええやん、って感じ。参加者に一定の信頼を置いた、管理者による人治主義のシステムと思った。

検索すると使った人の記事より先にコードを読みたがっている人の記事が出てくるようなアプリではあるんだが、コードの行数が少ないと驚かれていたけれど、言語の表現力や技術だけでなく、設計思想の根幹にユーザへの信頼もあるんでなかろうか。

まぁ人は確かに間違える生き物なんだけど、その間違いを「許せない！！責任を取れ！！！」みたいに許容できなくなったり、まして「人間は悪意を持った犯罪者だ！！！」みたいに一切信用しないと、システムはどんどん複雑になるよね。逆に言うと、人間に信頼し、間違いを許容すればシステムはシンプルになる。とはいえ事故はあるので、それを防ぐガードレールはあったほうがいいんじゃないってのはそうだと思うし、塩梅ではあるんだけれど。

とりあえず、いじっていこうかな。チャットボットちょっとほしかったんだ。

レンサバのWordPressサイトを、既にWordPressコンテナを持っているVPSにデータベース共有で移行する

Mon, 15 Sep 2025 00:00:00 +0900

自分でタイトル見直して笑った。これやりたい人日本に何人いるんだろう。

なお、レンサバはカラフルボックス。カラフルボックスで管理しているWordPressのサイトを、VPSに移行する。ただし、VPSには既にWordPressのコンテナをたてている。WordPressのマルチサイトはめんどくさいが、データベースをいっぱいつくるのはRAM的に嫌なので、DBは共有する。そういうニッチな手順。

個人サイトの移行であんまり真面目にやってないので、サイトはダウンする。ダウンタイムは許容する。

前提と構成

今回のやること

現在、VPSでサイトAとサイトBを管理している（Docker管理）。VPSではCloudflare Tunnel経由でサイト公開している
サイトAとサイトBは同じDBを共有している
レンサバのカラフルボックスで管理しているサイトCを、VPSでサイトA、Bと一緒に管理したい
データベースは共有する
DNSは、リセラーとしてムームードメインで管理している
- ムームードメインにはなんのこだわりもない。むしろ嫌な思い出すらある。完全に惰性

つまり現在の構成は以下だ。

graph TD
mumu(ムームードメイン)
cff(Cloudflare)
mumu --> cff
cff --> cf
subgraph VPS
wp1(サイトA)
wp2(サイトB)
db(データベース)
cf(Cloudflare Tunnel)
end
cf --> wp1
cf --> wp2
wp1 -.-> db
wp2 -.-> db
mumu -->cldns
subgraph カラフルボックス
cldns(ドメイン管理)
wp3(サイトC)
end
cldns --> wp3

これが以下のようになる。

graph TD
mumu(ムームードメイン)
cff(Cloudflare)
mumu --> cff
cff --> cf
subgraph VPS
wp1(サイトA)
wp2(サイトB)
wp3(サイトC)
db(データベース)
cf(Cloudflare Tunnel)
end
cf --> wp1
cf --> wp2
cf --> wp3
wp1 -.-> db
wp2 -.-> db
wp3 -.-> db

この絵を見て「？？？」となるなら、多分この記事はあまり役に立たない。しかしそもそもレンサバ使っている人がこんなことをするのか謎ではある。

この記事で説明しないこと

この記事には前提知識がある。以下のことはわかっている前提とする。

カラフルボックス、ムームードメインなどリセラー、レジストラの設定
Cloudflare Tunnelの設定
WordPressのバックアップ、復元の詳細手順
- ローカルで練習することを強く推奨する
NSの向け先を変える意味
dockerの基本

この記事の内容は個人サイトとして最悪の事態を招く可能性があるので、わからないならやらないほうがいい。

LLMあたりに聞いてね。まぁこんなニッチな手順やる人はだいたいわかっている気はするが……。

バックアップ & 古いサイトかどうか判別できるマーカを残す

まずは当然ながらバックアップ。バックアップのやり方は好きにすればいいが、個人的には UpdraftPlus を使っている。バックアップデータはDropboxに置いている。正直無料で使うのは申し訳ないくらいなんだが、買い切りモデルがないし、無料プランで十分なんだよなぁという。

で、バックアップした後、「サイト引っ越し作業中です」みたいなマーカを残しておく。これによって、サイト引っ越し後、「マーカがあったら古いサイトを見ている、なかったら新しいサイトを見ている」と判別できる。

VPS側の準備

ダウンタイムはなんだかんだで短くしたいので、VPS側の下準備。

設定の確認

とりあえず docker-compose.ymlを確認する。以下はすでにサイト1,2があるとする。ポート番号は10880,10881とする。

services:
 # サイト1: メインサイト
 site1_wordpress:
 image: wordpress:latest
 ports:
 - "10880:80"
 environment:
 WORDPRESS_DB_HOST: wp_db
 WORDPRESS_DB_USER: ${SITE1_DB_USER}
 WORDPRESS_DB_PASSWORD: ${SITE1_DB_PASSWORD}
 WORDPRESS_DB_NAME: ${SITE1_DB_NAME}
 volumes:
 - site1_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - wp_db

 # サイト2: サブサイト
 site2_wordpress:
 image: wordpress:latest
 ports:
 - "10881:80"
 environment:
 WORDPRESS_DB_HOST: wp_db
 WORDPRESS_DB_USER: ${SITE2_DB_USER}
 WORDPRESS_DB_PASSWORD: ${SITE2_DB_PASSWORD}
 WORDPRESS_DB_NAME: ${SITE2_DB_NAME}
 volumes:
 - site2_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - wp_db

 # 共有データベース
 wp_db:
 image: mariadb:latest
 environment:
 MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
 volumes:
 - wp_db_data:/var/lib/mysql
 restart: always

 # Cloudflareトンネル
 cloudflared_main:
 image: cloudflare/cloudflared:latest
 network_mode: "host"
 command: tunnel --no-autoupdate run --token ${CLOUDFLARED_TUNNEL_TOKEN_MAIN}
 restart: always

volumes:
 site1_wordpress_data:
 site2_wordpress_data:
 wp_db_data:

.envは以下とする。

# MariaDBルートパスワード
MYSQL_ROOT_PASSWORD=your_secure_root_password_here

# サイト1のデータベース設定
SITE1_DB_USER=site1_user
SITE1_DB_PASSWORD=your_secure_password_1
SITE1_DB_NAME=site1_db

# サイト2のデータベース設定
SITE2_DB_USER=site2_user
SITE2_DB_PASSWORD=your_secure_password_2
SITE2_DB_NAME=site2_db

# Cloudflareトンネルトークン（メインドメイン用）
CLOUDFLARED_TUNNEL_TOKEN_MAIN=your_cloudflare_tunnel_token_here

DBでユーザとテーブルの作成

データベース共有するので、ユーザとテーブルを手動で追加する。

コンテナに入る

docker ps # コンテナ名を調べる
docker exec -it コンテナ名 mariadb -u root -p

パスワード聞かれるので答えて入る。

以下設定とその反映。

CREATE DATABASE データベース名;
CREATE USER 'ユーザ'@'%' IDENTIFIED BY 'パスワードをここに入力';
GRANT ALL PRIVILEGES ON データベース名.* TO 'ユーザ'@'%';
FLUSH PRIVILEGES;

SHOW DATABASES;
SELECT User, Host FROM mysql.user WHERE User = 'ユーザ';

EXIT;

ここでユーザとデータベース名とパスワードはひかえる。そして .env に追記する。

docker-compose.yml に設定を追加する。新サイトのポート番号は10882とする。

services:
 # サイト1: メインサイト
 site1_wordpress:
 image: wordpress:latest
 ports:
 - "10880:80"
 environment:
 WORDPRESS_DB_HOST: wp_db
 WORDPRESS_DB_USER: ${SITE1_DB_USER}
 WORDPRESS_DB_PASSWORD: ${SITE1_DB_PASSWORD}
 WORDPRESS_DB_NAME: ${SITE1_DB_NAME}
 volumes:
 - site1_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - wp_db

 # サイト2: サブサイト
 site2_wordpress:
 image: wordpress:latest
 ports:
 - "10881:80"
 environment:
 WORDPRESS_DB_HOST: wp_db
 WORDPRESS_DB_USER: ${SITE2_DB_USER}
 WORDPRESS_DB_PASSWORD: ${SITE2_DB_PASSWORD}
 WORDPRESS_DB_NAME: ${SITE2_DB_NAME}
 volumes:
 - site2_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - wp_db

 # サイト3: 追加サイト
 site3_wordpress:
 image: wordpress:latest
 ports:
 - "10882:80"
 environment:
 WORDPRESS_DB_HOST: wp_db
 WORDPRESS_DB_USER: ${SITE3_DB_USER}
 WORDPRESS_DB_PASSWORD: ${SITE3_DB_PASSWORD}
 WORDPRESS_DB_NAME: ${SITE3_DB_NAME}
 volumes:
 - site3_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - wp_db

 # 共有データベース
 wp_db:
 image: mariadb:latest
 environment:
 MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
 volumes:
 - wp_db_data:/var/lib/mysql
 restart: always

 # Cloudflareトンネル（メインドメイン用）
 cloudflared_main:
 image: cloudflare/cloudflared:latest
 network_mode: "host"
 command: tunnel --no-autoupdate run --token ${CLOUDFLARED_TUNNEL_TOKEN_MAIN}
 restart: always

volumes:
 site1_wordpress_data:
 site2_wordpress_data:
 site3_wordpress_data: # 追加
 wp_db_data:

そして .envは以下のようになる。

# MariaDBルートパスワード
MYSQL_ROOT_PASSWORD=your_secure_root_password_here

# サイト1のデータベース設定
SITE1_DB_USER=site1_user
SITE1_DB_PASSWORD=your_secure_password_1
SITE1_DB_NAME=site1_db

# サイト2のデータベース設定
SITE2_DB_USER=site2_user
SITE2_DB_PASSWORD=your_secure_password_2
SITE2_DB_NAME=site2_db

# サイト3のデータベース設定 (追加分)
SITE3_DB_USER=site3_user
SITE3_DB_PASSWORD=your_secure_password_3
SITE3_DB_NAME=site3_db

# Cloudflareトンネルトークン（メインドメイン用）
CLOUDFLARED_TUNNEL_TOKEN_MAIN=your_cloudflare_tunnel_token_here

そしてここまでの動作を確認するためコンテナ起動。

docker compose up -d

既にあるサイトにアクセスして、問題なく動作していることを確認。

なんとかしてWordPressの初期設定をする

localhostなら問題ないが、VPS上にあるとそのまま直にはいけない。まぁやり方は色々あると思うんだが、ここでは既存のCloudflareで管理するドメインより、一時作業のサブドメインを払い出して、トンネル経由で初期画面を設定する。さすがに管理者ユーザとパスワードだけは設定しないといけないからね。

終わったら、「設定」からWordPressアドレスとサイトアドレスを、本来のドメインに変更する。これによって本来のドメインにぶっ飛ばされるため、移行管理画面には入れない。

Cloudflareの準備

オンボードの追加

アカウントホームより、オンボードを追加する。現在のDNSをスキャンする。Aレコードとかは多分いらないので削除する。このへんは適切にやる。

NSの設定（ダウンタイム発生）

さてここからはダウンタイム発生となるが、NSの向け先を変更する。これによって、当然ながらサイトはめっちゃ不安定になる。ってかまぁ、落ちているのが正常、という状態。

設定はレジストラまたはリセラー次第となる。僕はムームードメインを惰性で使っているが、ドメイン一覧からドメインを選択すると、ネームサーバを取得できるようになる。

この設定をした段階で、サイトが新サイトと旧サイトの両方が参照されるようになる。

CloudflareがNS向いたことを確認次第、トンネルを掘れるようになる。NSの設定後、トイレにいって戻ってきたらもう認識していた。はやい。Zero TrsutよりCloudflare Tunnelのパブリックホストで急いで設定。

新サイトで復元

新サイトにアクセスする。このとき、ゲストプロファイルなどを使うと、新サイトが参照されやすい。新サイトにアクセスしたら急いで復元。復元後は、元サイトにつけたマーカの有無で、旧サイトか新サイトのどちらを参照しているかが今後はわかる。

うまくいけば数分くらいのダウンタイムで済む。

以上。

ムームードメインの思い出

ところでムームードメインの嫌な思い出はこれ。

/serverholdxyz/

ただこれは、ムームードメインよりも.xyzのレジストリ側の責任が大きいとは思う。

この時に、DNSってインターネットの根幹なんだなと思った。インターネットは脆いよ。

Homebrew環境におけるGiteaのエクスポート：brew services start giteaとgitea webの違いがわかる男

Fri, 12 Sep 2025 00:00:00 +0900

なんか色々躓いたので、復元は後日にして、今回はエクスポートについてのみ。なんか色々ハマった。

具体的には、最初に gitea web で動かして、その後 brew services start giteaのほうがいいやんけと思ってそっちにしたんだが、その後バックアップ手順を確認しようと gitea dumpしたら、なぜか最初に gitea web で作ったほうがバックアップされる。よく見たら実行プログラムのパスが違っており、それによって読み込まれる設定ファイルが違ったと思われる。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

giteaが分裂した。

公式: Backup and Restore | Gitea Documentation

公式にあるとおり、エクスポートはコマンドが用意されており、 gitea dump -c /path/to/app.iniに尽きる。ただここで問題は、 gitea のパスとコンフィグファイルのパスである。

たとえばコイツを見てくれ。コイツをどう思う？

> ps aux | grep -i gitea
user 19745 0.7 0.5 412867040 168992 ?? S 7:38PM 0:00.56 /opt/homebrew/opt/gitea/bin/gitea web --work-path /opt/homebrew/var/gitea

> which gitea
/opt/homebrew/bin/gitea

すごく……パスが違います……。

giteaコマンドは /opt/homebrew/bin/giteaなんだが、brewで起動する giteaは /opt/homebrew/opt/gitea/bin/giteaという。

ただ、こいつらはバイナリとしては同じ臭い。

> ls -la /opt/homebrew/bin/gitea 
/opt/homebrew/bin/gitea@ -> ../Cellar/gitea/1.24.5/bin/gitea
> ls -li /opt/homebrew/Cellar/gitea/1.24.5/bin/gitea
251898619 -r-xr-xr-x 1 user admin 107386178 Aug 14 01:34 

> ls -la /opt/homebrew/opt/gitea/bin/gitea
/opt/homebrew/opt/gitea/bin/gitea*
> ls -li /opt/homebrew/opt/gitea/bin/gitea
251898619 -r-xr-xr-x 1 user admin 107386178 Aug 14 01:34 /opt/homebrew/opt/gitea/bin/gitea*

なので、実行プログラムのパスで、読み込まれる暗黙のコンフィグパスが異なったものと思われる。brewで起動した方は、–work-pathを指定しているね。ここにコンフィグファイルもある。

パスの違いがわかる男

ということで、work-pathも踏まえて、dumpのコマンドは以下となる。停止できるなら停止したほうが安全だね。

brew services stop gitea
gitea dump -c /opt/homebrew/var/gitea/custom/conf/app.ini
brew services start gitea

ファイル名に日付けを入れるなら

gitea dump -c /opt/homebrew/var/gitea/custom/conf/app.ini -f gitea-backup-$(date +%Y%m%d-%H%M%S).zip

こいつをunzipすると以下のような感じだ。

gitea-backup-YYYYMMDD-HHMMSS.zip
├── app.ini # 設定ファイル
├── data/ # アプリケーションデータ
│ ├── attachments/ # 添付ファイル
│ ├── avatars/ # アバター画像
│ ├── gitea.db # データベースファイル
│ └── ...
├── repos/ # Gitリポジトリ
│ └── user/repo.git/ # 実際のGitリポジトリ
└── gitea-db.sql # データベースダンプ

このうち、app.iniは違うマシンでやるときにはゴチャゴチャと手動調整しないといけなくなると思う。ネットワーク環境とか、リポジトリのパスとか、環境によって変わるはずなので。特にMacからLinux……とかやるとね。

所感

サクッとできるだろうと思ったら思いのほか躓いた。LLMは永遠に存在しないパスを教えてくれるので10倍疲れた。インフラ周りになると途端に無能になるLLMさんェ……。それでもいるだけマシだろうと言われたらそうかもしれないんだが、昔は検索したら同じようなところで躓いた人の記事が出たもんだけどなぁと思ってしまう。

まぁ今回は brew services あんまり使ったことなかったから、それでちょっとハマったよね。自分でplist作ったら問題なかったんだろうけど。

今回はMacかつHomebrew経由特有の問題があったので、Dockerコンテナなら環境の共通化は多少できると思う。けど、ネットワーク環境とかはやっぱり違うだろうし、 app.iniは同一マシンでの復元以外は基本的に編集しないといけないんじゃないかな。となると、編集項目が1箇所でも5箇所でも、編集しないといけない時点で大して変わらないし、Docker使うと docker-compose.ymlの管理もあるから、どっちがいいかはちょっとわかんないね。

疲れたので、復元はまた後日。

<関連記事>

脱GitHubに向けて：Giteaを試し始める on Mac

/github-gitea-1/

WebベースのファイラFile Browserを試す：こういうのでいいんだよ

Thu, 04 Sep 2025 23:42:10 +0900

File Browser

Webベースで使えるファイルブラウザ、その名もFile Browserを試している。名前すごい。これは本当にその名の通りで、Web上からファイル操作ができるものだ。Webベースなので、タブレットやスマホからPCのファイルにアクセスできるのが良いところ。

すべてのメディアに専用アプリはいらないので

たとえば自分の場合は、さっと音楽ファイルを聞きたいときなんかに使うことがある。

こんな感じでPC上にあるすべての音楽ファイルに慣れたディレクトリ構成でアクセスできる。他にもちょっと「あの写真見たい」とか「あそこにドキュメントおいてたな」みたいな時に使う。

それらはまぁ専用アプリにはより高度な機能のビューアやエディタがあるわけだが、すべてのデバイスにすべてのメディアについて専用アプリを入れているわけじゃないし、そもそも常にそんな大仰なことをしたいわけでもない。俺はただファイルの中身を見たいだけなんだ。

また、場合によっては、他のPCで操作したドキュメントを置きたいとかもある。そんな時にも使える。いちいちDropboxだのでインターネットを経由する必要はないし（DropboxはLAN内同期もあるけど）SMBでボリュームマウントとかもしたくないんだ。

なので、このアプリはまさにこういうのでいいんだよ、という感じだ。

Macでのインストールと自動起動

環境

M2 Pro Mac mini
macOS 14.7.7

インストールはバイナリが色々あるので、OSごとにそれ用のやつを使えばいいと思うが、Macの場合はHomebrewになる（別に使いたければDocker使えばいいけど、ホームユースでその意義はない気がする）。

brew tap filebrowser/tap
brew install filebrowser

実際に起動する時のコマンドは以下となる。

filebrowser -r /path/to/your/files

アプリの性質上、ログイン時に起動したいんだがなぁ、ということもあるだろう。そういう場合は例によってLaunchAgentsを使うことになる。 ~/Library/LaunchAgentsに適当な一意のファイル名（なんでもいいけど homebrew.mxcl.filebrowser.plistとかそんな感じで）にして、下記のようにする。

以下のうち、ポート番号と<ユーザ名>と<パス>のところを、やりたいようにする。ここではポート番号は13000にしているが、空いているところを適当に。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>homebrew.mxcl.filebrowser</string>
 <key>ProgramArguments</key>
 <array>
 <string>/opt/homebrew/bin/filebrowser</string>
 <string>-a</string>
 <string>0.0.0.0</string>
 <string>-p</string>
 <string>13000</string>
 <string>-r</string>
 <string>/Users/<ユーザ名>/<ブラウジングしたいしたいパス></string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>
 <key>WorkingDirectory</key>
 <string>/Users/<ユーザ名></string>
 <key>StandardOutPath</key>
 <string>/tmp/filebrowser.log</string>
 <key>StandardErrorPath</key>
 <string>/tmp/filebrowser.error.log</string>
</dict>
</plist>

できたらloadする。

launchctl load ~/Library/LaunchAgents/<作ったplistのファイル名>

やったら http://<サーバのIPアドレス>:<ポート>にアクセスして確認する……のだが、この時、管理ユーザadminの初期パスワードがランダムで発行されてんだよね。なので、plistファイルにあるとおり標準出力パスの /tmp/filebrowser.logからランダム生成されたパスワードをコピペする。

そしたら admin & パスワードでログインできる。パスワードは変更しておく。

あとは見たら使えるやろファイラだし。

所感

なんか本当に「こういうのでいいんだよ、こういうので」って感じ。Cloudflare Tunnelとか組み合わせればインターネット経由でもまぁやれるし、用途次第ではDropboxとかGoogle Driveの代わりにもなるんじゃないかな。

脱GitHubに向けて：Giteaを試し始める on Mac

Wed, 03 Sep 2025 17:22:19 +0900

最近のMSはまたMSになってきたので、GitHubもいつどうなるかわからない、ということで、コード管理をセルフホストにしていきたい。

環境とインストール

ひとまず手元のMacで動かす

M2 Pro Mac mini
Intel Mac mini 2018
macOS 14.7.7
gitea 1.24.5 via Homebrew

インストールは「Installation | Gitea Documentation」色々あるわけだが、楽なのでbrew install。もしVPSでやるときは、Linuxなのでまた考える。でも別に家のMac miniでいい気もしている。Dockerは特に使う必要性を感じなかったので使わない。データベースでSQLite以外使うならコンテナでまとめてやったほうがいいかなと思う。今回はデータベースもSQLiteでファイル管理するつもりだし、無駄にオーバーヘッド作る必要もないかなって。

（2025-09-11）この記事を書いた時はDockerいらんかなと思ったんだけれど、バックアップ/復元まで考えたときに、パスなど環境の差分がけっこうしんどい感じだった。Dockerのほうがその点は吸収できそうだが、ただ結局IPアドレスやポート番号など、差分はやはりあるし、docker-compose.ymlの管理もあるので、どちらが良いかは一概には言えないかなぁという感じ。

公式: Gitea Official Website

セットアップ

インストールしたら brew services start gitea で開始する。これはつまりgitea webをしてそれ用のplistも作って登録する感じなんだが、わざわざ自分で頑張る意味もないので、Homebrew勢は黙ってstart gitea。

そしたら、 http://<サーバのIPアドレス>:3000 にWebブラウザでアクセスして初期設定をする。

データベースはSQLite3にする。ファイルで管理したいから。
- Homebrewだとファイルパスの初期設定は /opt/homebrew/bin/data/gitea.db になるようだ
リポジトリのルートパス（リモートリポジトリのデータの実体）、LFSファイルパス（Large File Storage……でかいファイルは別におくようだ）はひとまず初期値で続行
サーバードメインはLAN内の固定したプライベートIPアドレスを割り当て
HTTPポートは3000使いたくないので変更
内部でしか使わないのでベースURLはサーバードメインとポートそのまま
オプション眺めたが、ひとまず初期値で続行

新しいURLで入り直すと、初期画面がある。

右上の登録から最初のユーザを登録する。これが管理者になる。

試す

リポジトリの作成とpull/push

とりあえずリポジトリを適当に作って試す。まずWeb画面上でリポジトリを作成する。宗教上の理由によりブランチ名をmain->masterにし、それ以外は初期値でGo。リポジトリはできた。

クローンする。

git clone http://<サーバアドレス>:<ポート>/<リポジトリ名>

cloneは可能。移動してpushまで試す。

(master)> touch hoge
(master)> git add hoge
(master)> git commit -m "first commit"
(master)> git push

user名とパスワードを求められるが、入力すればとおる。ふむ。

いったん作ったディレクトリを削除して、次にssh経由を試す。

ssh鍵

ssh鍵くらいは登録しておく。ここでは既存の公開鍵 id_rsa.pub を使う。

右上のプロフィールアイコンから「設定」
左メニューの「SSH/GPGキー」
SSHの「キーを追加」で id_rsa.pub の中身を登録

そしたら git clone ssh://ほげほげ でクローンする（適当）。入って適当にファイル作ってaddしてpushできるかを確認。特にパスワードを求められずに登録できたらOK。

その後気づいたのだが、Giteaはsshについてだいぶトリッキーなことをしているようで、~/.ssh/authorized_keysにcommandを記述している。で、リモートログインの時に支障をきたす。また、アンインストール時にはここの部分を削除しないといけない。

少しずつ試していく

ということで、今回はさらっと最低限のssh経由のpush/pullをやっただけだが、一応これだけでもローカル内にあるちょっとしたプロジェクトの管理には使える格好だ。とはいえ実際のバックアップ・復元手順なども確認する必要もあるし、GitHub Actionsみたいなことをしたくなったらどうなるんだろう、とかわからないことも多いので、これから少しずつ試していきたい。

Android + CloudBeats + QNAP NAS + Cloudflareで外でNASの音楽をストリーミング&オフライン再生する

Mon, 01 Sep 2025 10:46:57 +0900

Androidスマホでお外でNASの音楽聴きたいなぁ、スマホのストレージはゴミだしmicroSDも挿せないからストリーミングしたいなぁ……という記事。

最初に言うとCloudBeatsは複数のクラウド接続とオフライン再生は有料アプリなので（非サブスク）、多少金は払うが、まぁでもNASやストレージの代金に比べたら誤差だし、なによりDropboxせいぜい1.5か月分くらいなので。

外で開くので独自ドメイン使う。外からの接続にはCloudflare Tunnel使う。このへんのネットワーク構成は好きにすればだけど

環境

QNAP NAS TS-233
- FW: QTS 5.2.6.3195
- CPU: Quad-core ARM Cortex-A55 Processor @ 2.0GHz
- RAM: 2GB
Androidスマホ Pixel 7 128GB
- OS: Android 16
- アプリ: CloudBeats 2.60.03
独自ドメイン
- Cloudflare管理
- Cloudflare Tunnel利用

NASはQNAPのエントリーレベルのやつだけど、WebDAVやる限りは別に問題ないね。

構成を図示すると以下。

graph LR
subgraph Internet
android(Android)
cloudflare(Cloudflare)
end
subgraph Home
nas(NAS)
pc(PC)
end
android --> cloudflare
cloudflare -->|Cloudflare Tunnel| pc
pc -->|webDAV| nas

踏み台となっているPCは常時稼働サーバ前提ではある。少なくともお外に出ている時に起動しているもの。うちはMac miniがそれにあたる。

/dockerコンテナサーバー機として余生を生きるintel-mac-mini-2018/

AndroidアプリはCloudBeatsを使っているけれど、WebDAV扱える音楽アプリなら別になんでもいいと思う。僕は「オフライン再生 + ストリーミング再生 + クラウド接続」でこれに行き着いたが、他にいいのがあるなら別にそれはそれで。

費用についていえば、NASとスマホは既にある前提なら、CloudBeatsの有料オプションが1500円、ドメイン管理代が年間1500-2000円くらいかな。CloudBeatsの有料オプションは、オフライン再生と複数クラウドサービスを利用したい時用なので、厳密にはなくてもいいんだが……サブスクじゃないんだし買えばいいと思う。

経緯

設計意図とかの経緯については下記記事。一言で言えば脱Dropboxだね。

脱Dropbox：NASの音楽ファイルをストリーミングで再生する試み

/dropboxnas-streaming-music/

QNAPの設定

NASのWebアプリにログインして、コントロールパネルを開こう。基本的に権限設定周りのことをする。

WebDAVを有効化する

まず有効化する。

「コントロールパネル」→「ネットワークとファイル差ビス」→「Win/Mac/NFS/WebDAV」

そしたらWebDAVタブがあるので、「WebDAVを有効にする」と、「WebDAV権限」にチェック。ポートは占有ポート番号使っていいと思うよ。

WebDAV用の共有フォルダを作成する

別に既存のフォルダでもいいかもしれないが、なんかあった時のためと整理のために、それ用のフォルダ作っていいかなと思う。そしたら最悪クラックされたとしても、WebDAV経由ではそのフォルダしか触れないように。

WebDAV用のユーザを作成する

まぁこれも必須じゃないんだけれど、上記と一緒。ファイル管理自体は普段の管理用ユーザだとなんかあったときの被害が広がる恐れもあるので、WebDAVアクセス用ユーザは作っておいたほうがよいかと。どうせ一手間なんだし。

ということでWebDAV用ユーザを作成する。言うまでもないが、外からのアクセスに使うものなので、適当なPWにしないように。WebDAV用ユーザは次の「権限の編集」でWebDAVの読み取り権限のみ付与する。

権限の編集をする

QNAP曰く、下記のように権限設定が必要らしい。

WebDAV用の権限を与える。QNAPにおいては、「ユーザーとグループの権限」と、「WebDAVのアクセス」が分かれている。ファイル管理は「ユーザーとグループの権限」において、ファイル管理をしたいユーザで「R/W」を設定し、WebDAVアクセスについては作成したユーザに「読み取り専用」の権限を付与する。

こうすることで、お外からはWebDAV専用ユーザで、WebDAV専用フォルダを読み取りのみできる、という状態になるため、クラックされても安心では別にないんだが、被害は抑えられる。

Cloudflareの設定

LAN内で動作確認したいところなんだが、CloudBeatsはhttp通信だとどうもクラウド接続に失敗するっぽい。このためだけに自己証明書だのなんだのも阿呆みたいだし、しゃーないので、ぶっつけでCloudflare側の設定をする。

やることは、独自ドメインを経由してLAN内NASにアクセスできるようにすること。

ってことでNASにアクセスするPCにCloudflareを導入。Cloudflare Tunnelの設定については下記記事の「Cloudflareでトンネル作成」の部分を参照。ただし、ここでは http://<NASのIPアドレス>:5000 とする。冷静に考えると一般的にはここが一番の難所の気がしなくもないが、それだけに説明もめんどくさい。雑ですまない。

/calibre-cloudflare-tunnel/

CloudBeatsでWebDAV使ってサインイン

CloudBeatsの「クラウドサービスを追加」からwebDAVを選び（なぜwだけ小文字なのか）、以下の情報を追加する。

https://<独自ドメイン>/<作成したフォルダ名>
user: 作成したユーザID
pw: 作成したユーザPW

そしたらアクセスできるようになるので、適当に音楽ファイルを置いて動作確認する。

(おまけ) ファイル管理はFreeFileSync

音楽ファイルの管理方法だが、これは好きにすればいい……んだけれど、個人的には「ローカルで構成しているフォルダ構成をそのままFreeFileSyncでFTP転送」としている。

/mac-windows-freefilesync/

これは良いソフトウェアなので寄付してDonation Editionにしたらいいと思う。寄付すると並列でファイル転送できるようになる。寄付額はこちらで決められる。

ちなみにQNAPのNASでFTPを扱うには、QuFTP Serviceなるアプリをインストールする必要がある。まぁインストールしたらそのまんま使える。

使い勝手

全然悪くない。ただファイル一覧が多すぎると表示に時間がかかる感じなので、一覧が多くなりすぎないようにしたほうがいいね。

でもそれくらいかな。音楽ファイルをフォルダ単位で整理していると、数年くらい忘れていた「音楽を管理する」という感覚が得られる。そうか、僕はこれがやりたかったんだなぁと、今さらながら思い出した。

いったいどうして、好きな音楽を雲の上に置くのがクールだなんて、意味不明なトレンドに乗ってしまったのだろうなぁ。まぁ、今となっては取り戻せることではない。これからまた、好きな音楽を聴いていこう。

[itemlink post_id=“15811”]

脱Dropbox：NASの音楽ファイルをストリーミングで再生する試み

Sat, 30 Aug 2025 21:49:44 +0900

やろう、やろう、と思いながら、面倒臭くてずっとやらなかったNASの音楽ファイルをAndroidからストリーミング再生する環境をやっと構築した。ちょっと軽くランニングしてきた感じでは、十分使えているのではないかな、と思う。これでDropboxを使う大きな理由の一つをなくすことができたね。

はまりどころもあったので、そのうちにハウツー記事にしたいと思うが、今回はとりあえず所感をつらつらと。

ちょっとマニアックな構成

構成自体はちょっとマニアックな感じになってしまったかなと思う。

graph LR
subgraph Internet
android(Android)
cloudflare(Cloudflare)
end
subgraph Home
nas(NAS)
pc(PC)
end
android --> cloudflare
cloudflare -->|Cloudflare Tunnel| pc
pc -->|webDAV| nas

この時点で特に技術系ではない一般ユーザにはオススメできない構成になってしまっているのはまぁそう。といっても別に何かコード書くわけじゃないし、頑張ればできると思うけど。

元々、構成的にはそりゃ出来るだろう、とは思っていたものの、WebDAV使えてストリーミングとオフライン両方できるAndroidアプリあるのかな、とか、NASでWebDAVの設定どうするのかな、とか個別に調べないといけないことも多くて、なかなか進まなかった。あと家の回線がJ:COMなので、クソザコ上り回線で大丈夫かなぁと思ったのもある。

まーでも、多少手こずったけれど、とりあえずうまくいったかなぁ、という感じ。ただフォルダがたくさんあると一覧表示に時間かかるようで、これはスペックというよりネットワークの問題の気がする。このへんはもうちょっと整理がいるかな。

AndroidアプリはCloudBeatsを使った。有料オプションは1500円くらいだったかな。オプションは複数のクラウド接続とオフライン再生に必要だった。妥当な料金じゃないかな。サブスクじゃないなら全然いいよ。だいたいNASとストレージの代金からすれば誤差みたいなもんだし。NASはQNAPのTS-233。ドメインは元々取得していてCloudflareで管理している自分用ドメインを流用した。

[itemlink post_id=“15811”]

世界線の修正作業

まぁもうちょっとしばらく使い混んで使い勝手は調べる必要があるかな。フォルダも整理しなおさないといけない。iTunes時代の名残で、全アーティストのフォルダがフラットに並んでしまっているんだよね。それで阿呆みたいに長いリストになってるからさ。

ああiTunes、今にして思うと、僕にソフトウェアの進歩について強い疑念を抱かせた最初のアプリケーションだったかもしれない。毎度毎度、強権的な仕様変更に振り回され、頼んでもない新機能を見せつけられ、その癖出来たことが出来なくなり、そしてファイルが壊される。途中Apple Musicなんて契約しようもんならもう最悪なことになる。なった。

冷静に考えると、自前のライブラリを知らないサーバに置く必要はないし、ストレージが足りないならmicroSDを使えばいいし、microSDも挿せないならNASからストリーミングもあるし、別にプレイヤーを買ってもよかった。今でもiPodモドキはたくさん売ってるし。でもあの時は、なんかこれが未来なんかな、という気にさせられていたよね。実際このブログでもApple MusicとかiTunesで検索したら色々出てくるよ。懐かしい。

結果的には、間違えた世界線だったんだなと思う。こうしてフォルダの再整理に勤しまねばならないのがもうね。っていうか消失している曲とかもあるんだよな。MOTHERっていうゲームのアレンジサントラでやけに凝ったのがあったんだけど、マニアックかつオムニバスでアーティストが分散しているのもあって、なんか気がついたら曲が何曲か見当たらない。一番気に入っていた曲は幸い（？）残っていたので、買い直すのもなんだかなぁ、みたいになってる。やれやれだなぁ。

[itemlink post_id=“18951”]

まぁ今からでも少しずつなおしていくさ。

Dropboxに恨みはない

一応言うと、僕はDropboxに対しては案外と好印象だったりする。実際最近このブログではクラウドについて腐していることが多いが、その中でもDropboxに対して悪口めいたことは言ったことはないんじゃないかな。Dropboxは便利だし、非常にマニアックな文字コード問題の対応、Linux対応などもあって、かゆいところに手が届くサービスだと思う。価格も決して高すぎるとは思わない。安いとも思わないけど。

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

/data-self-hosting/

いつだったか不本意なアカウントBAN事件について書かれた個人の記事を見て「Dropboxもあるかー」と思ったことはある。しかし、少なくとも僕はこれまでアレゲなファイルも置いてきたが特にBANされたことはなく、またされたところで別に大して困らないので、使い続けている。まぁ、三年契約しちゃって、契約期間がまだあるからさ。

まーでも、次の契約更新はないかな。別にDropboxに恨みはないけれど、クラウド、サブスクはもう嫌だっていう気持ちのほうが強い。僕自身はこの流れから脱せられているわけではないけれど、せめてプライベートではまず離れたいところだね。

バックアップは結局NASと外付けHDっていう

Wed, 18 Jun 2025 11:55:11 +0900

データは命。命を大事に。デジタルデータは壊れやすいが、しかし複製することができる。

したがって、我々はつねにバックアップについて実践的かつ継続的にしなければならない。何かがあってからでは遅い。事故は起きる。

クラウドは信用しない

まず大前提、クラウドは信用しない。Dropboxの有料会員が言うことではないかもしらんが、同期サービスは同期が便利なのであって、バックアップとして使ってはいけないと思う。災害リスクを考えると良いという意見もあるが、どう考えても未曾有の大災害リスクよりもサービス側の勝手なアカウントBANややらかしのほうが現実的なリスク。まぁ僕自身は今までクラウドサービスに勝手なBANなどをされたことは幸運なことに未だないが、それはこれからもないことを意味しない。

したがって、クラウドサービスは同期やファイル共有の機能が便利だから使うのであって、データという命を預けてよい場所ではない。バックアップ先の一つとしてする分にはよいが、少なくとも唯一のバックアップ先にすべきではない。

NASと外付けHD

そうすると、結局伝統的な外付けHD、あるいはNASという結論になる。楽なのは明らかにNASだ。しかしNASの場合、ネットワークがボトルネックになる。特にMacを使っている場合、なんか知らんが色々と遅い。あとよく切れる。これは以前から色々とやっているんだが、あまりうまくいっていない。一応下記記事のようなことはしているが、それでも遅い。

MacとReadyNAS 104の通信速度が遅い時の対処法(SMB)

/rnas104smbup/

とはいえ、バックアップに時間がかかるからなんだ？という考えもある。あるのだが、実際に1日たってもバックアップが終わってない風景など見ると、なんだかなぁという気になる。

速度の面では、やはり有線の外付けHDが最強ではあるものの、セットアップが面倒臭い。

また、運用上の問題として、複数PCで同期して使いたいファイルなどもある。こればかりは外付けHD運用ではどうにもならない。やはり中央サーバ的なものが必要になってくる。Dropboxで収まるならばよいのだが、自分は今Dropboxの役割を縮小させようとしているため、ちょっと厳しい。NASは同期の役割も担えるので、こちらにシフトしていきたい。

まぁ色々考えると、やはりNASにこまめにバックアップしつつ、たまに外付けHDにもバックアップする、というのがとりあえずの結論になる。NAS重いなぁと思いつつ。

ちなみに持っているのはQNAPのTS-233で、スペック的に色々キツイのかもしれない。

[itemlink post_id=“15811”]

でもキツイなりに、あまり無理させなければ（2TBのフォルダを同期とか）それなりに動いてくれるからなぁ。

Nextcloudを使うのは？

少し話が変わってくるが、複数端末の同期問題については、わざわざNASを使わずともメインデスクトップ(M2 Pro Mac mini)にNextcloudをインストールするということも考えられる。というか実際これは良い手に思える。思えるものの、少し面倒臭い。個別の事情だが、現在外部ストレージを起動ディスクにしているのだけれど、そのうち内蔵ディスクを起動ディスクに戻そうと思っているため、現時点において母艦めいたことをすると、二度手間になる。また、内蔵ディスクを起動ディスクにした場合、外部ストレージの接続は保証されなくなるため、Nextcloudのサーバとするには安定性の面でやや心許ない。

このようなことを考えると、スペック低いとはいえ、一応ハードウェアとしてのNASもあるし、何も自前で頑張らなくてもいいかな……というのが現時点の結論だ。

しかし、NASのスペックがあまりにもつらすぎる、と思ったら、メインデスクトップであるMac miniあるいは別の常時稼働計デスクトップマシンのNextcloudサーバ計画を実行することになるかもしれない。ハイエンドのNASを買うお金はないのでな……。

レンサバからVPSに帰ってきた

Sat, 24 May 2025 16:35:02 +0900

このブログは12年……今年で13年の歴史があり、当初のLivedoorの無料ブログからインフラレベルで幾重の変遷を経て今に至るのだが、先日レンサバからVPSに帰ってきた。おおう、懐かしのConoHa VPSよ。このはちゃんのイラストはいらんから安くしてくれんかね……。とりあえずサービス維持調整費とかいう欺瞞は本当に早くやめてください。これ始まって2年以上たつけど、真面目な話なにかの法律に引っかからないんだろうか。

まぁそれでも3年分の契約で7割引きは十分お安い。VRAMは2GB。4GB欲しい。2GBの金で4GBほしい！！！！

当サイトのインフラの歴史

当サイトのインフラは以下のように変遷している。

2012年：Livedoor無料ブログ
2016年
- 独自ドメインの取得
- ConoHaのVPSに移行、WordPress構築
- https対応
2017年
- PHP 5.4 -> 7.1
2020年
- PHP 7.1 -> 7.4
2022年
- PHP 7.4 -> 8.1
2023年
- ConoHaのVPSからレンタルサーバーのカラフルボックスに移行
2025年
- ConoHaのVPSに帰ってきた

インフラの移行は面倒臭いしリスキーなのでそうあることではないのだが、こうしてみると2016年が大きな転機だったようだ。その後は基本的にせいぜいPHPのバージョンをあげる程度のことしかしていない。DBのバージョンはあげてなかった気がする。

httpsは本当にいらなかった

まぁやっぱり面倒臭かったのはhttps対応かなと思う。当時も「本当に必要かこれ」と思っていたけれど、今にして思うと本当に必要なかった。うちのサイトに暗号化しないといけない情報は特にないです。

とはいえ、やらないとブラウザの覇権を握ったGoogleから抹殺されてしまうために渋々従わざるを得なかったのだが、当時はGoogleが個人サイトそのものを抹殺するとはまだ思っていなかった。僕がGoogle嫌いなのは、Webサイトを運営していてGoogleの態度が変わっていくのを目の当たりにし、またジャイアントスイングされ続けてきたからだろう

Google検索しているだけだったら、「最近の検索クソだな」とは思っても、嫌いにまではならなかったと思う。実際プロダクトはウンコでもプロダクトの基礎となる部分では今なお大きな存在感を放っているし、エンジニア仲間の友人は今でもGoogle信者を自称している。実際色々な仕事をしているのはそうだ。しかし今の僕には、Googleがいなければ他の誰かが似たようなことをしていただろう、という風に感じられてしまう。少なくとも、僕がWebサイトを構築し運用することに関しては特に問題がなかっただろうし、もしかすると今よりも良い世界線だったかもしれない。

Googleの影響力よ

意図したわけではないのだが、何故かまたGoogleの愚痴になってしまった。色々な切り口がある中で、いつも最初にくるのはこれなんだが、逆説的にそれだけGoogleの影響力が大きかったということなんだろうなぁ。個人的にはGoogleはGAFAで最初に陥落するとすら思っているけれど、昨今のAI事情の中でどうなるか次第だ。

ちなみに僕は散々愚痴っといてなんだが、今はAIチャットボットとしてはGeminiに課金している。これについてはGeminiがいいというよりOpenAIが自滅し続けているだけという感覚だ。

/chatgpt-yoisho/

GeminiはChatGPTほどごますりしてこないので、Geminiを使っている。あと馴れ馴れしくないからさ……。

いつかローカルLLMがまともに使えるようになったら、なんとかそうしたい。現状はまだちょっと厳しい……。

https楽になったし、検索ももう気にならない

さて、Googleの愚痴が本題ではなく、VPSに戻したことが本題なんだが、愚痴っていたらそれなりの文字数になってしまった。

しかしここまでの話でも言えることはあって、少なくとも以下の点はレンサバからVPSへの移行という面倒くさい作業をする背中を押した。

Cloudflareのおかげでhttps対応が楽になった
どうせもう検索ヒットは死んでるので、ダウンタイムの発生や移行ミスで検索順位が落ちるとかまったく気にしなくなった
botウザい

https対応が楽になったというのは、まぁCloudflare Tunnelだなぁ。まぁLet’s Encryptのおかげで個人でも対応はできるんだけど、面倒くさいし定期的に証明書再発行ミスってサイトがマルウェア扱いされるみたいなことはよく起きる。っていうかあの作業がまず面倒臭いんだが、そういう無意味な構築・運用をしなくてよいっていうのは実際的にも精神的に楽だね。

そしてまぁ、移行はなんかミスると長時間のダウンタイムとかに繋がりかねず、そうすると検索順位が大きく落ちるなどのペナルティも発生しうるだけれど、既にジェノサイドされている個人サイトとしてはもはやどうでもいい。まぁと言いつつも当サイトのアクセスにおいて検索エンジン経由が多いのはそうなんだが、多いといったところでしれているし、そもそも検索で情報が見つからなくて困るのは検索している人であって僕ではない。

まぁこれを言うとサイト運営の意義とは何かという話なんだけれど、実際なんなんだろうと思いながらサイトを続けている。なんなんだろうね。ただ現状に納得いっていないことは確かだ。検索からすべて弾かれてももはや知ったことではないと思う。

そんなことより今はbotがウザい。たまにアクセス伸びてんなと思ったらだいたいフィルタリングしきれていないbotだよ。昔はまぁそれも大して気にならなかった、というのも検索エンジンなどに機械的に評価されようというならある程度のbotも仕方ない、という気持ちがあった。

しかし今となってはもうそんな気持ちもない。僕は何のためにブログを書いているのか、サイト運営を続けているのか、もはや僕自身にもわからない。昔は利他と自己満足のないまぜのようなものと解釈していた。その気持ちは今もある。

ブログを続ける理由

/cross/

一方で、もはや自己も利他も薄っぺらく思えることも確かだ。しかしでは何かと言われるとわからない。だが少なくともGoogleの検索エンジンのためではないし、ましてbotのためではない。

レンサバだと対応が限られるが、VPS上なら対応の幅が広がるし、そもそもCloudflareの対応が有能である。やはりサイトは自由でなくては。

サイトは続くよ多分どこまでも

そんなわけでまぁ、とりあえず2年ぶりのConoHaのVPSに帰ってきた。どういう形態になってもサイト自体は続けられることはありがたいと思う。本当はWordPressやDockerの話をしようかと考えていたんだがまったくしていない。まぁこれはまた別の機会に。

ConoHaはまぁGMOなんでGMOだけれど、とりあえず国内で安く使えるし、なんだかんだでいいと思うよ。

お友達紹介

お友達紹介コードを貼っておしまい。こっから飛んで使い始めてもらったら1000円分のクーポンがもらえるはず（このとも～友達紹介～｜レンタルサーバーならConoHa）。そして定常的に使ったら僕に2000円分のクーポンが入る。クーポンのためにブログを続ける人生だった。

しかし今まで数百回クリックされているはずだが実際に使うとこまでいったのは1人だけである。もはやVPS流行らないのか。

/yaranakuteiikotobakarishiteiru/

やらなくていいことばかりしている

サーバーも会社も学校も、いつでも逃げ出せることが大事

/escape/

Mac mini 2018 で Docker Desktop のCPU利用率が100%に張り付くので対症療法で誤魔化している

Thu, 24 Apr 2025 21:52:55 +0900

うちのMac mini 2018は実質コンテナサーバと化しているのだが、最近やけに五月蠅い。Docker Desktopがずっと暴走している。対症療法はあるが、解決できていない。しばらく様子を見て、ダメそうならOrbstackへの移行も考える（それでおさまればだが、恐らくDocker Desktopに起因しているので……）。

とりあえず、対症療法のメモ。

（追記：その後、バックアッププログラムを走らせるとCPUが暴走することがわかった。おおう……）

（さらに追記 2025-05-02：Docker Desktopが4.41.0になったら解消したかも）

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

/docker-volume-cli-backup/

環境

Intel Mac mini 2018
- macOS 14.6.1
Docker Desktop 4.40.0
- コンテナはいっぱい起動してるが、、、

症状

Mac miniが五月蠅い。

静音性だけが取り柄なのにどうしたことだろうとアクティビティモニタを見たら、Docker DesktopとおぼしきタスクがCPU利用率100%になっている。「そんなに」と思ってダッシュボードを見ると、特にコンテナのCPU利用率は高くない。しかしアクティビティモニタでは明らかにDockerが100%を使い続けている……。

「めんどくせぇ再起動しよう」と思い、Docker Desktopを再起動した。CPU利用率が200%になった。

どういうことやねんと思い、もっかいDocker Desktop再起動かける。すると、今度は終了後の起動が永遠に終わらない。おおぅ……。Mac自体を再起動したらとりあえずDocker Desktopは再び起動したが、やはりCPU利用率は100%。はぁ……。

対症療法

あれこれした結果、以下の手順でしばらく収まった。

「設定」で以下をオフにする
- Start Docker Desktop when you sign in to your computer
- Open Docker Dashboard when Docker Desktop starts
コンテナを全部落とす
Docker Desktopを「終了」する（再起動ではなく）
Docker Desktopを起動する
コンテナを全部起動する

ただしばらくすると再発する感じ。

ひとまず様子見

コンテナが悪さしているとも思えない。おまかんの気もする。今のMac mini 2018は購入から6年以上第一線でほぼほぼ24時間起動し続けており、メインデスクトップを退いてからもホームサーバとしてずっと働いている。なんか色々溜まっているのかもしれない。再起動すると起動までに何分かかかるし。

とはいえDocker Desktopに起因する問題っぽいし、もうしばらく様子を見て症状が治らないようなら、一縷の望みをかけてOrbstackあたり試してみようかと思う。

M2 Pro Mac mini を購入して1年5か月経過：静かに革命

Tue, 08 Apr 2025 03:03:42 +0900

Intel Mac mini 2018からM2 Pro Mac miniに買い換えて1年5か月が経過した。M3は悲しい感じでM2大勝利だったが、M4で飛躍的な進化を遂げたので、結果論だともう少し待てばよかったのにこの愚か者、という感じではあるけれど、そうは言ってもあの時どうにも欲しいという情動があったのは事実だし、また1年早く多くのことを楽しめたのだからやはり買ってよかったのだと思え思うしかない思って。

体験は満足度が高い

まぁM4が強すぎるのでぐぬぬとなっているのは事実なんだけれど、正直M2 Proでほとんど不満がない。これは最大限の賛辞だと思ってよい。まぁLLMを使う上ではM4 Proだったらもうちょっと使い物になるかもと思える応答速度だったりしたのかなぁと思ったりなんだりもするけれど、結局普段使いはChatGPTやCodyなんだし、ローカルLLMに全振りするにはまだまだ時期が早い。

というわけで、全体的にMac mini 2018からすべてがパワーアップした一方、特に不便になったこともない。あったかもしれないけど思い浮かばない。この不便がない、というのはとても素晴らしいことで、実際のところ、普段使いにおいて重要なことはいかに不満が少ないかだ。

一般的なレビューでは、この新商品はアレができるコレができるということを言いたがるものだが、現実的に本当に手に馴染むかは何ができるかよりも何ができないかのほうがきいてくる。まぁもちろん何ができるかも重要ではあるので、そういう意味ではレビューも有り難いし、実際僕も買う前にはよく見るのだが、しかし最終的に本当に自分にとって良いかは機能ではない。

僕は長期的な使い勝手こそ本質だと思っているので、思い出したようにプロダクトの所感についてあーだこーだと書いている。別に開封の儀を腐すつもりはないのだが、しかしプロダクトの良さはインパルスではなく積分であるはずで、振り返って初めて、良かったなぁとか、あんまりだったとか、そういう感慨がわいてくるものだ。

それで僕はこうして、「特に不便がない」とわざわざ書き、そしてそれ以外特に言うことがない。この言うことの無さにじんわりとプロダクトとしての良さを実感するばかりだ。

懐かしのセルフホスティング（自宅サーバ）

まぁこれでは記事としてあんまりな気がするので、一点良かったなと思うことを書くと、セルフホスティングの良さを再び経験できていることだ。まぁつまり自宅サーバなんだが、VPSでやっているサーバもあるので、全部含めてセルフホスティング。

ただしここでセルフホスティングしているのは主に買い換える前までメインデスクトップにしていたMac mini 2018だ。M2 Pro Mac miniを買った後、まだ動くMac mini 2018を見て、コイツどうしてくれようか、まだまだ使えるし、売って端金にするのも尺だなぁと思って、コンテナサーバにしてみるかと思って使ったところ、これがなかなか具合がよい。ちょっと試してみたいソフトウェアをスナック菓子感覚で楽しめる。なんなら常用しているサーバも数多い。

もちろんM2 Pro Mac miniでも問題なくできるのだが、コンテナはけっこう何かと重たいし、またできるだけ常時稼働させたいものだから、常用していると再起動も億劫になってしまうので、物理的にメインデスクトップと切り分けできたのはよかったと思う。メインデスクトップであるM2 Pro Mac miniを開発サーバとして、いけるなと思ったらMac mini 2018にデプロイするということも可能だ。まぁそこまでちゃんとやってるのはあんまりないけど。

このブログも今はレンサバでやっているのだけれど、またセルフホスティングに戻したいと思う。まぁこのブログは一時期よりアクセスが大幅に減ったとはいえ、それでもだいたい常に何人かは来訪してもらえているので、帯域や安定性を考えると、さすがに自宅サーバよりはVPSかなとは思うけど。

M2 Pro Mac miniが変えた生活

M2 Pro Mac miniあんま関係ないやんと思われたかもしれないが、M2 Pro Mac miniを買わなければ、ここまでセルフホスティングを積極的に試していなかったであろうということに注目されたい。つまり、M2 Pro Mac miniは我が家のシステムを変えたのだ。こんなに素晴らしいことが他にあるだろうか。

つまり、良いプロダクトとは、まず不満がないことで、あまりにも不満がないために何も言うことがなく、気がつくと月日が過ぎており、思い返してその良さを積分でじんわりと感じられるものだ。そしてさらに振り返れば、生活そのものが実は変わっていた。そういうものであり、僕にとってM2 Pro Mac miniはまさに良いプロダクトだったのである。

これで明らかなように、M4まで待つ必要はなかったというのが論理的帰結であり、それはそれとしてM4 Pro Mac mini欲しい。

<関連記事>

M2 Pro Mac Miniをポチった

/m3-mac-m2-pro-mac-mini/

M2 Pro Mac mini (2022)

/m2-pro-mac-mini/

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

Sun, 09 Mar 2025 13:13:11 +0900

クラウドという言葉が定着してもう10年以上経過する。僕はバズワードに過ぎないと思っていたのだが、思いのほか概念として定着したようだ。クラウドとはとどのつまり「他社にデータを預けても良い仕組み」そして「それをクールだとする社会的な思い込み」の総称だ。

本来、データを預けるのは多くの人にとって受け入れがたい仕組みである。データとは財産であり、その財産を他人に預けるなど正気の沙汰ではない。

狂気の沙汰を正気の沙汰に

実際、自分の財を第三者に預けるなど、本来的には狂気の沙汰だと思われるが、その狂気を正気ということにする商売はある。金融業なんかその典型だろう。狂気の沙汰を正気の沙汰とするために、彼らはありもしない信用を唱え、勝手なことはしませんよと言うわけだが、僕らがそれを信用するのは、彼らが信頼に足る人物・組織だからではなく、彼らが勝手にやりづらい制度が社会的にあり、また彼らも彼らで一応実績を積み上げてきた、という現実による。

その意味で、クラウドサービスは金融業と近い面がある。彼らもまた、データという顧客の財を預かるサービスだ。そのサービスが使われるほどに、彼らもまた儲かる。まぁ金融業よりは不動産業に近いかもしれない。その性質のために、最近はGAFAの基盤上でサービスを展開する事業者をデジタル小作人などと呼ぶ人もいる。

個人的には、デジタル小作人のような見方はかなり一面的な見方だと思うが、しかし本質的に金融業や不動産業と近い側面があることは事実だ。

つまり、クラウドサービスというのはその本質に、財を預けても良いという信用があり、それをベースにしたみかじめ商売である。

その警戒されるべき本質を、クラウドというぼんやりした流行語によって見えづらくしている。いまや、クラウドを理解しないものは遅れているという社会的な空気さえ醸成されている。クラウドは、ビジネスのうえで非常に便利な言葉だった。だから定着したのだと思う。

クラウドサービスもまた本質は狂気

クラウドサービスはその本質に財を預ける狂気がある。まぁこれはいささか極端な議論かもしれない。クラウドサービスにも色々あって、コンテナの実行基盤やAWS LambdaのようなFaaSは、財を預けているという感覚は薄いだろう。実際、実行基盤として利用している、その利用料を払っている、というのはユーザとしての素直な感覚である。しかしそれでもやはり、本質としてプログラムという財を預ける信用なくしてできないことは確かだ。

Dropboxのようなオンライン・ストレージサービスはクラウドの中でも特に財を預けるという感覚が強いものもある。オンライン・ストレージサービスはクラウドの先駆けとも言えるもので、クラウドという言葉流行る前に出来たモノだから、いまでもオンライン・ストレージサービスと言われる。しかしその本質はクラウドに包括されるものだ。

オンライン・ストレージサービスは信用できない、という言説は昔からあった。実際僕の考えも錯綜している、当ブログを「Dropbox」で検索すれば、NASを主体にしたり、Dropboxを主体にしたりと、あれこれ試行錯誤していることがわかる。

Dropbox Plus + 外付けSSD でNASいらずに挑戦中

まぁなんだかんだでDropbox Plusの有料会員は続けているという事実から、僕はDropboxを信用していると考えられる。実際、Dropboxを使い始めてからかれこれ15年たっていると思うが、特に問題が起きたことはない。

しかしそれも、今の契約が終わるまでで、次の契約更新はしないつもりだ。まぁまだあと1年くらい残っているのだが、今その準備を進めているところで、既に大方のデータをバックアップとしてNASに引っ越している。あと数ヶ月かけて少しずつDropboxの依存度を下げていくつもりである。

理由として、Dropboxというよりクラウドサービス全体に対する個人的な信用の低下や、サービス全体の肥大化、また、代替手段の技術の向上がある。

手元の運用が楽になった

信用の低下といっても、元から大して信用していたわけではない。オンライン・ストレージサービスの場合は、昔からプラットフォーマー側の基準による勝手な垢バン問題があった。子供とのお風呂写真が、欧米諸国の勝手な倫理基準で児童ポルノ扱いされBANされた、という話は実際に聞く。独身である僕は特に子供の裸写真のようなものは持っていないが、あちらの勝手な基準で勝手に垢バンされる、というリスクは常に警戒してきた。そのために、僕はDropboxと使いながらもずっと外付けハードディスクなどにデータの退避を怠ることはなかった。

だったら何故Dropboxを使っているのかと言えば、純粋に便利だからである。オンライン・ストレージサービスとはただデータを雲の上に預けるだけではない。雲の上に預けたデータを、様々なアプリケーションで連携できるところに、クラウドの妙味がある。たとえばDropboxにある音楽データをストリーミング再生するアプリなどは、身近な応用例だろう。

同じ事をオンプレでやろうとしたら、昔はだいぶ苦労したものだ。サーバーの構築とメンテ、そしてインターネット公開のためのネットワーク環境の構築、セキュリティ設定。なので、僕は現実的な選択肢として、Dropboxのようなサービスを利用してきた。

しかし、今はこれがだいぶ楽にできる。サーバについては、なんといってもコンテナが大きい。コンテナの良いところは、環境のスクラップ&ビルドが滅茶苦茶楽なところだ。設定をコードで書けるのもよい。Linuxマシンを用意して、何かあったらOSの再インストールから……なんてやらなてくいい。そしてネットワークについては、Cloudflareの存在が大きい。特にCloudflare Tunnelは、ネットワーク公開を楽かつセキュアにできる現実的な選択肢だ。

まぁ結局DockerやCloudflareに依存していると言えばそれはそのとおりで、特にCloudflareについてはデータ監視のリスクもあるが、しかし同様のことができるサービスはあるわけだし、なにより財を預けているわけではないから、依存度としてクラウドサービスの比ではない。重要なことは、依存しないことだ。依存しないとは、データという人質を取られないことである。

依存度を下げた運用は昔から可能ではあったけれど、労力を含むコストが大きかった。今、それがかなり現実的なレベルにまで下がっている（といっても非IT技術者には厳しいとは思う）。むしろ、自分の使い方に合わせてソフトウェアを組み合わせることができるという点では、お仕着せのサービスよりもよほど使いやすい。

地震雷火事よりも親父（プラットフォーマー）のリスクが大きい

運用について非常に楽になったのはそうだとして、もう一つ問題がある。それは、オンプレ環境が破壊されたらどうするのか問題だ。これはバックアップを取ればいいじゃないかという程度の話ではなく、自宅が火事になったり、あるいは大災害に巻き込まれたらどうするのか、というレベルの話だ。

これについては、どうしようもない。まぁデータくらいなら、遠方の家族の家にたまにハードディスクをおかせてもらえば、すべてがゼロになるという事態は防げるかもしれない。まぁ可能なら、遠隔地にNASをおいてネットワーク越しにバックアップなりできればいいと思う。

しかしそんなことをするなら、クラウドサービスを使えばいいじゃないかという話になるだろう。実際僕もその観点から、クラウドサービスの利用について肯定的だったし、今も業務においては使う。ってか最近個人開発で公開したWebアプリもフツーにAWSのDynamoDBにデータ保存してる。認証はCognito使ってる。

が、プライベートではなるべく避けたい、という感じだ。その理由は簡単で、災害でデータがぶっ壊れるリスクよりも、プラットフォーマーの謎の振る舞いでデータが破壊されたりアクセスできなくなったりするリスクの方が大きいと思うからだ。

プライベートの使い方って非常に広範で、それこそ家族の思い出から個人的ポルノ大全まで色々あり、しかもそのデータは自分の人生が続く限り保持されてほしいものだ。これは通常のサービスよりも実は要件が厳しい。サービスは特定の目的でしか使われないし、なによりサービスの寿命と自分の寿命では、だいたいサービスの寿命のほうが短い。

だから特定のサービスならば、クラウド利用はリスクとベネフィットを天秤にかければ、利用する、という選択は多くの場合正しいと思う。まぁコストに見合えばだが。

しかしプライベートの場合、クラウドはいかにも危なっかしい。確かに地震雷火事には強いだろうが、親父ことプラットフォーマーの気まぐれが怖い。地震雷火事よりも、親父のほうがよほど身近な脅威であり、しかもその親父はアースクエイク・サンダー・ファイアー一通り使える。こんな怖い親父がいるか。

雲の上の頑固親父にデータを預けられない

ということで、現実的に手元の運用コストが下がったことと、雲の上の頑固親父の横暴が酷くなる一方の昨今、とてもそんな親父に僕の大事なデータを預けられねぇなぁという気持ちが強くなっている。

実際、プライベートでは脱クラウドを進めている。まぁさすがに2025年にオンプレはどうなのって話もあるが、その場合でも、最近はVPSのバランスの良さを再評価している。コストも値頃だし、スペックの範囲で好き勝手できるし。コンテナ使えるアプリなら移植性も高いし。そもそもクラウドサービス使わなきゃいけないほど非機能が求められる状況ってあんまりないんだよな、僕の場合、というのもあるが。

そんなわけで、気がつくとMac mini 2018はコンテナサーバとしてなんか常に十数個のサーバが立ち上がっている。まぁめんどくさいこともあるけれど、そういえばサーバって楽しかったぁ、なんてことも思う。こんな楽しいものは、雲の上より自分の部屋にあったほうがよい。そんな360度回ったことを思う今日この頃だ。

Notion代替ツールAFFiNEをセルフホスティングでやろうとしたら結構つらかった

Wed, 06 Nov 2024 08:21:23 +0900

AFFiNEはあまりメジャーではないと思うが、Notion + Miroに相当する機能を持ったナレッジツールである。Notion代替を謳うものとしては他にAppFlowyなんかもあるが（これもあまり有名ではない）、Miroの機能まであるのが珍しく、また面白いと思う。

で、なんといっても面白いのは「セルフホスティングできる」ところだ。特にライセンス費用などもなく、コストを抑えつつ面倒くさいデータプライバシー問題にも対応できる。個人ならほとんどのSaaSで御法度となっているR18なデータの管理だってできよう。

ということで、これは良いと思ってしばらく試していたのだが、やってみるとまぁまぁつらく、またキャッチアップもたいへんそうで、結論としては「現時点では様子見」になった。

ChatGPTにまとめさせた記事の要旨

このブログ記事は、ナレッジ管理ツール「AFFiNE」の評価とセルフホスティング体験についてまとめた内容です。以下に主なポイントを記載します。

AFFiNEの特徴:

NotionやMiroに似た機能を持ち、ナレッジ管理やドキュメント作成、タスク管理ができる。
特徴的なのはセルフホスティング対応であり、データプライバシーを保ちつつ、無料で使用できる点。

使用感と利便性:

初期の操作感は良好で、画面描画もスムーズ。
ドキュメント管理はフラットで階層構造を後から追加でき、ドラフト作成がしやすい。
カンバン機能でタスク管理ができ、日記機能も備えている。

課題と限界:

Miro代替として期待していた「Edgeless」機能に開発向けの用途には限界がある。
Mermaid記法に非対応である点が大きな欠点。
データベース機能が未実装で、カンバンも簡易的。
アカウント管理がGraphQLでの手動操作を要するなど、セルフホスティングの管理が煩雑。

セルフホスティングへの疑念:

「AFFiNE Cloud」との関連が不明瞭で、セルフホスティングに制限がある点に不安を感じる。
ドキュメントが不足しており、仕様変更の頻度が高いため、追従が難しい。

結論:

現時点では、クリティカルな機能不足やセルフホスティングの継続性に不安があるため、本格的な使用は見送るべきと判断。
ただし、個人利用やサブツールとしては十分に価値があるため、軽い用途には適している。

全体的に、AFFiNEは一人用のナレッジツールとしては面白いが、複数人での利用や管理面では改善が必要とされています。

操作感は良い

AFFiNEの第一印象はポジティブだった。最初の画面からしてインパクトがあったが、「おお、マジでMiroやん」と思ったな。

もちろん普通のドキュメントも作れる（当たり前）。これがなかなか良く考えられており、ドキュメント自体はフラットに作られていくのだが、それをWikiのように階層的に管理する感じだ。何が良いかというと、ベースがフラットに積み上げていく形なので「ドラフト」を作りやすい。最初に「このドキュメントはどこに置こう」と考えなくて良い。ドラフトのまま放置してもいいし、ある程度書き上げてから階層構造の中に組み込んでもいい。これは実際やってみると、なかなか良い体験だった。

無理矢理Notion的に言うと、グローバルなデータベースが最初からあって、そこから任意のドキュメントを階層的に管理したり、またタグでまとめたりできるような感じだろうか。

また、自動で作られるその日の日記ドキュメントも、けっこう勝手がいい。もちろんNotionでも似たようなことは実現できるが、最初から備わっているだけでだいぶ気楽なものだなと思った。

機能的にも、タスク管理でカンバンが使えるなど、必要そうなことは一通り揃っている感じだった。Notionほど多機能ではないけれど、その分わかりやすいと思ったし、必要十分じゃないかこれは、と思ったな。

そしてなんといっても、パフォーマンスが非常によかった。とにかく画面の描画が早い。うちのクソ雑魚ネット上り回線でもそうだから、ローカルストレージをうまく利用しているのだと思われる。

また、セルフホスティングもけっこう簡単で、docker compose一発でサーバがたったし、さらに最初の管理画面で「サインアップ機能の無効化」などもあったのが素晴らしかった。これはちょっと前にAppFlowyを試した時、サインアップの無効化があまり推奨されておらず、そうするとWeb画面に到達するもっと前のところでアクセス制御が必要ということになり、それは正しいっちゃ正しいんだが「めんどくせぇ」と思わされたところだったので、本当によかった。

で、僕は非常に気を良くして、友人とやっているプロジェクトの管理でナレッジツールはGrowi（OSSでセルフホスティングできるWikiツール）よりこれを使おうぜと持ちかけたくらいだ。

実際に運用するとつらみがあった

しかしいざしばらく使って見ると、「む……」と思うことが多く、最終的に「ちょっと現時点では使えないなぁ」という結論になってしまった。具体的に何があったのかを書いていく。

Miro代替としては機能が不足している

まず期待のMiroの機能であるEdgelessだが、これは使って見るとちょっと機能が不足していると思われた。特に僕らは開発系なのだけれど、その向きではかなりつらい。マインドマップと簡単なシステム図くらいしか作れそうにない。

クラス図ならば頑張ればそれっぽいのは書けるかもしれないが、ER図のあの変な矢印みたいなのは到底できそうにない。友人はMiroでそういったドキュメントを作るので「ちょっとこれじゃ使えないなぁ」と評価されてしまった。

Mermaid記法が使えない

そこで「Mermaid記法で書けばいいじゃないか」と言えればよかったのだが（納得するかどうかは別として）、残念なことにMermaid記法に対応していない。これは僕にとって大きなマイナスだ。グラフについてはEdgelessがあるじゃないかということなのだろうが、機能が足りないうえに、僕からすると「ページの中に図をしれっと挿入したいんだよ」と思うことも多々ある。Mermaid記法の非対応は僕にとって「がーんだな」であった。

カンバン、というかデータベースが貧弱（というよりない）

カンバンでタスク管理ができるぞ、というのはすごいことだと思ったが、実際に使って見ると、 「表をカンバンっぽくしたもの」という感じだった。機能としてはかなりプアである。Notionのような使い勝手を想像してはいけない。

まぁこれはつまり、データベース機能がない、という風に言えばよいかもしれない。なんかこれは開発者の人が「今注力してる」みたいなことを言っていたので（TwitterでAFFiNEについて呟いていたらなんか補足されて話しかけられた）、そのうち実装されるのかもしれないのだが、少なくとも今のKanbanはかなりプアだと認識すべき。

まぁ要件次第では使えないことはないと思うし、むしろ人によっては「こういうのでいいんだよ」と思うかもしれない。機能がプアとは、裏を返せばそれだけシンプルだということでもある。

管理がつらい、いちいちGraphQLやDB操作を求められる

管理面では、セルフホスティング向けの管理機能がほぼほぼ不足しているのがつらい。アカウントを増やすだけでGraphQLを叩かないといけなかった。これはかなりつらい。

しかも実際に使って見るとAuthエラーが出たりなんだりするうえ、それについてドキュメントがあるわけでもなく、いったいどうすればいいんだろうとGraphQLのスキーマを見て悩む。仕様も頻繁に変わっているようで、GitHubのIssueには戸惑っている人も多くいた。

たとえば以前はsignUpとして「How to create a new account on self-hosted affine · Issue #5957 · toeverything/AFFiNE」のIssueが解決策となっていたが、これがいつのまにか使えなくなり、「Can’t create users via GraphQL requests · Issue #7105 · toeverything/AFFiNE」「[urgent] GraphQL command for signUp is removed in current version stable · Issue #7106 · toeverything/AFFiNE」など複数のIssueで「signUpできないんだけど」とイシューがたった。これについては「その機能は消した。GraphQLのスキーマを見てね」とのみ。（ちなみに僕もGraphQLのスキーマを見てやってみたんだが401エラーになってしまった。認証が必要なのはわかるがどうやればいいのかわからず、もういいやとなった……）

この分だと、頑張って対応してもまたすぐ仕様が変わってキャッチアップ大変そう。

また、せっかくのセルフホスティングだというのに、なぜか「アカウント数」「ワークスペースの容量」に制限がかかっている。これについては、DBを直接操作することで解除できるらしい（「Self-hosted not unrestricted · Issue #6641 · toeverything/AFFiNE」）のだが、「え？」という感じだ。

セルフホスティングをどうしたいのかよくわからない

全体として、「セルフホスティングをどうしたいのかわからない」という不安がある。実際セルフホスティングであるにも関わらずAFFiNE Cloudという名前が使われており、これについて「おいCloudってなんだ、まさかAFFiNE社のサーバを経由するのか？そうじゃないならAFFiNE Cloudなんて言わないでくれよ」と不安を訴えるユーザもいる。「Self-hosted shouldn’t say “Affine Cloud” · Issue #7097 · toeverything/AFFiNE」がそのイシューだが、最終的に「Outline（セルフホスティングできるWikiツール）」を試してみようで終わっていた。

Discussionsにもスレッドがあるのだが「toeverything/AFFiNE · Discussions · GitHub」どうもあまり活発ではなさそうだ。

このサービスはOSSでセルフホスティングできることがウリの一つなのだけれど、サービスのビジネスモデルとしてはSaaSモデルで、セルフホスティングユーザはサービス側からすると1円にもならない。なのでまぁ塩対応なのは仕方ないとは思うし、セルフホスティングしようという人にそこまで懇切丁寧にサポートする必要もないのだけれど、それにしてもドキュメントなさすぎやろと思うし、また機能面で不足しているところが多く、「いったいどこまで本気なんだ」と思ってしまう。

結論：様子見

以上より、「いくつかのクリティカルな機能不足とセルフホスティングへの姿勢に対する不安」から、「現状ではちょっと真面目に使いづらい。様子見」という結論になった。

しかしながら操作感自体はかなり良く、また一人でおうちナレッジツールとして使う分にはけっこう良いのではなかろうか。ただセルフホスティングの継続性についてはちょっと色々疑問符もあるので、あくまでお遊びないしサブとしての利用に留めるのがよさそう、というのが正直な感想だ。

次はOutline使ってみるかなぁ。

Dockerコンテナサーバー機として余生を生きるIntel Mac mini 2018

Thu, 19 Sep 2024 11:46:31 +0900

衝動買いに近い形でM2 Pro Mac miniを買ってしまってからぼちぼち10か月くらいたつが（はやい）、それまで使っていたIntel Mac mini 2018でも不便があったわけではなかった。というか使えば今も十分使えると思う。

なんだけれど、まぁ買ってしまったので仕方ないね。そしてIntel Mac mini 2018はどうしようかなと思っていたのだが、なんだかんだでDockerのコンテナサーバとして余生を過ごしている。余生というかバリバリ現役感がある。

このスペックのVPSは借りられない

Mac mini 2018をサーバとして使うと何が良いかといえば、CPU 6コア、32GB RAM（家に64GB RAMもあるので交換可能……めんどくさいからしてない笑）、500GBストレージ、さらにUSBありというVPSでは非常に厳しい機能を実現できることだね。まぁもちろん停電で落ちるし、なによりJ:COMのうちのネットワーク帯域はうんちっちなので、まともなサーバ環境とは言い難いけれど、別にそんなまともなサーバ環境が必要なものばかりでもないしさ。NASなんて外からのアクセスたまにできたらいい程度だし。以前だとインターネット公開は何かと面倒だったけれど、最近はCloudflare Tunnelとかいう神サービスもあるので、お手軽に自分専用のサーバをたてられるようになった。

カジュアルにElasticsearchなどスペックが必要なサーバをやれるのはとても良いよ。おかげで重ための開発中Webアプリを気軽にホスティングして試せるし（localhostじゃイヤだい）、出来合いのツールだとGrowiとかWordPressとかスナック菓子感覚でたてられて楽しい。全文検索API作りたいなぁ、クラウドだとたっかいから二の足踏んでたけどセルフホスティングならやってもいいね。Grafanaも個人でやれる。AIもグラボで動かせるやつなら電気代の範囲でできる。ネットワーク環境が光回線ならMisskeyサーバたててもいいなぁ。なんだかんだでサーバは楽しいよ。

以前（9年ほど前……）自宅サーバは浪漫枠なんて記事を書いたけれど、再び自宅サーバの時代がきたのだ。

まぁさすがに全体公開を想定したWebサイトはVPS借りたほうがいいと思うけど。なんかあったらプロバイダに怒られそうだしさ。怒られた。

/dropbox-jcom/

まぁこれはサーバじゃ無くてDropbox経由のバックアップで怒られたんだけどね（J:COMのしょっぱい上り回線でパブリックに向けた何かをしようとはそもそも思わない）。J:COMは上り回線30GB/日までらしいよー。

光回線だったらそこまで神経質にならないでいいと思うけど、基本的には「通信帯域はあんまりいらないんだけど、スペック・物理的な拡張性がいる」みたいなのが向いてるね。まぁ全体公開用のWebサーバは大人しくVPSにしとこ。

静かで小さい

ただMacである必要はないどころか、むしろDockerメインならMacじゃないほうがよくねと言われると「ぐぬぬ」ではある。でもそうだなぁ、Mac miniほど小型で静音性の高いデスクトップPCとなると中々ないんじゃないかな。実際Mac miniのいいところって静音性だと思うし。時々熱くてうるさいけどね。熱いのはいつもか。かれこれ5年以上使ってるけど、よくもってるな。僕の愛が伝わっている（なんか言ってる）。

HWとは別にSWとしてmacOSのいいところと言われると……画面共有できるのは地味に便利かな……。TimeMachineはもはや使わないし。

まぁ……総合的に見たらLinuxのほうがいいのはそりゃそう。でもま……ありものを有効に使おうぜってことだから。コイツは去年までうちのメインデスクトップとして頑張ってたんだからよぉ、これでいいんだよ。

バリバリ現役

ということで余生と書いたけど、実はバリバリ現役なんだよ。壊れたら困るなーって思うもの。多分壊れたら、しばらくはメインデスクトップに環境移すとしても（それがすぐできるのも素晴らしいよね）、なんか自作PC組むか中古のPC買うと思う。うーん、それは困るな、出費がかさむ。

あと10年もってくれ頼むよー。

Growiのファイルアップロード先をS3に設定

Tue, 17 Sep 2024 16:56:22 +0900

「アプリ設定 | GROWI Docs」にあるとおりなんだけれど、何故か毎回引っかかってしまうのでメモする。

環境

docker-composeで作ったもので確認
- ホストOS: macOS 14, IntelとAppleSilicon両方確認
Growi v7.0.x

やること

graph LR
user(ユーザ)
growi(Growi)
s3(S3)
growi -.->|アップロード| s3
s3 -->|アクセス許可| growi -->|ファイル| user

Growiを通じてS3上のファイルをやりとりできるようにするための、Growi-S3間の権限設定をそれぞれすることになる。

AWS側
- 保存するバケットを作成する（今回はap-northeast-1）
  - バケットのパブリックブロックの設定を変更する
- バケットにアクセスするためのIAMポリシーをアタッチしたIAMユーザを作成する
  - IAMユーザの認証キーを作成する
Growi側
- docker-compose.ymlで S3_OBJECT_ACL=privateの設定をする
- アプリ設定で認証の設定をする

手順

AWS: バケットの作成

東京リージョンでバケットを作成する。

バケットのブロックパブリックアクセスのうち、「新しいアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする」のみオフにする（下図）。作成時に設定できるが、作成後にも「アクセス許可」タブより設定変更可能。

AWS: IAMの作成

作成したバケットにアクセスするためのIAMポリシーを作成する。ポリシーは以下。

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "s3:PutObject",
 "s3:PutObjectAcl",
 "s3:GetObject"
 ],
 "Resource": [
 "arn:aws:s3:::<作成したバケット名>/*"
 ]
 }
 ]
}

IAMユーザを作成し、作成したポリシーをアタッチする。

IAMユーザの認証キーを作成して保存する。

Growi: docker-compose.yml の編集

docker-compose.yml に環境変数として S3_OBJECT_ACL=private を追加。

version: '3'

services:
 app:
 build:
 context: .
 dockerfile: ./Dockerfile
 ports:
 - 127.0.0.1:13000:3000 # localhost only by default
 links:
 - mongo:mongo
 - elasticsearch:elasticsearch
 depends_on:
 - mongo
 - elasticsearch
 environment:
 - MONGO_URI=mongodb://mongo:27017/growi
 - ELASTICSEARCH_URI=http://elasticsearch:9200/growi
 - PASSWORD_SEED=changeme
 - S3_OBJECT_ACL=private # ---------------ここに追加-------------------
 # - FILE_UPLOAD=mongodb # activate this line if you use MongoDB GridFS rather than AWS
 # - FILE_UPLOAD=local

コンテナを再起動する。

Growi: アプリの設定

管理者画面の「アプリ設定」より「ファイルアップロード設定」で、ファイルアップロード方法としてAWS(S3)を選択し、リージョン、バケット名、キーの設定をして更新する。

所感

マニュアルに書いてあるんだけど、いつも何かを忘れて謎に引っかかるので、メモした。だいたいdocker-compose.ymlの編集を忘れる模様。

Growi便利だよね。

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

Mon, 09 Sep 2024 09:55:54 +0900

最近色々セルフホスティングでコンテナ動かしているため、バックアップの必要が出てきた。ので、その内容と実際の手順についてメモする。

ボリュームのバックアップは何をやるのか

まずDockerのボリュームのバックアップとはつまり何をすることなのかについて。これは公式の「Back Up and Share Docker Volumes with This Extension | Docker」を読むとよいのだが、つまりは以下のスニペットに帰結する。

`docker run --rm \ -v "$VOLUME_NAME":/backup-volume \ -v "$(pwd)":/backup \ busybox \ tar -zcvf /backup/my-backup.tar.gz /backup-volume`

このコードの詳細な解説はChatGPTに譲るが、まぁ要はバックアップを作るためのコンテナを作成し、ホストマシンにデータをコピーしている形だ。復元はこれの逆をやると良い。DBなんかは通常dumpのユーティリティがあるが、記事によればDockerの場合はこれでまるごとコピーするほうが良いとのことだ。

ChatGPTによるコードの解説

このコマンドは、Dockerを使って簡単にバックアップを作成するための手順です。以下に各部分の解説を行います。

docker run --rm :

docker run は Docker コンテナを実行するコマンドです。--rm は、コンテナが終了した後にそのコンテナを自動的に削除するオプションです。これにより、バックアップが完了した時点で不要なコンテナが残らないようになります。

-v "$VOLUME_NAME":/backup-volume :

-v オプションは、ホストマシンとコンテナ間でボリュームをマウントするためのものです。$VOLUME_NAME はバックアップしたい Docker ボリュームの名前を指します。これがコンテナ内の /backup-volume ディレクトリにマウントされます。

-v "$(pwd)":/backup :

こちらも -v オプションですが、ホストマシンの現在の作業ディレクトリ（$(pwd) で取得される）をコンテナ内の /backup ディレクトリにマウントしています。このディレクトリにバックアップファイルを保存します。

busybox :

これは Docker イメージの名前です。busybox は非常に軽量な Linux ベースのイメージで、基本的なユーティリティ（tar など）を含んでいます。このコンテナが一時的に起動され、バックアップ処理を実行します。

tar -zcvf /backup/my-backup.tar.gz /backup-volume :

tar コマンドで圧縮ファイル（.tar.gz）を作成しています。
- -z: gzip 形式で圧縮するオプション。
- -c: 新しいアーカイブを作成するオプション。
- -v: 詳細な出力（アーカイブ中のファイル名を表示する）。
- -f /backup/my-backup.tar.gz: 出力するファイル名を指定しています。この場合は、/backup/my-backup.tar.gz という名前で圧縮ファイルが作成されます。
- /backup-volume: アーカイブ対象のディレクトリで、マウントされたボリュームです。

まとめ:
このコマンドは、指定した Docker ボリューム（$VOLUME_NAME）を tar コマンドで圧縮し、現在のディレクトリに my-backup.tar.gz という名前のバックアップファイルを保存します。

これを実行するものとして、v4.29.0以降のDocker Desktopでは拡張機能として公式で提供されている（「Volumes Backup & Share - Docker Extension | Docker Hub」）。上の記事によれば、この拡張機能はボリュームをアタッチしているコンテナを調べて一時停止し、再起動するところまで含めてやっているようだ。

黒塗りしてるのは開発中のアプリ名が出ちゃってるvolume 気にするな

便利な拡張機能だが、もうすぐdeprecatedになる見込みで、どうやらこの機能は近日中に公式で提供されるものらしい。その際、手動バックアップは普通に使えるが、スケジューリングはサブスクプラン専用機能になる模様（Explore Volumes | Docker Docs）。

CLIで無料でやりたい

バックアップはスケジューリングしてやりたいし、お金はないし、そもそもVPSとかDocker Desktopない環境でも使いたい。ということで、フツーにスクリプト書くかなと思った。

やっていることは単純なので、全部自分で書いてもよかったが、上記記事の中でも紹介されている「https://github.com/BretFisher/docker-vackup」がシンプルなシェルスクリプトでそのまま使えて便利そうだったので、これを使うことにした。

インストール手順はREADME.md見ればよいが一応書いておく。LinuxとMacならそのまんま。

`sudo curl -sSL https://raw.githubusercontent.com/BretFisher/docker-vackup/main/vackup -o /usr/local/bin/vackup && sudo chmod +x /usr/local/bin/vackup`

このスクリプトは特にコンテナの停止などしていないようなので、ユースケースから必要なら停止する処理を入れたスクリプト書くべし。

vackupを使ったバックアップと復元

いざという時に使えるように、練習する。

テスト用コンテナのセットアップ

テスト用のDockerネットワークを作成

`docker network create test-network`

MySQLコンテナを起動し、データを保存するためのVolumeを作成

`docker run -d --name mysql-test \ --network test-network \ -e MYSQL_ROOT_PASSWORD=rootpassword \ -e MYSQL_DATABASE=testdb \ -v mysql-data:/var/lib/mysql \ mysql:latest`

データの投入

MySQLコンテナに接続

`docker exec -it mysql-test mysql -uroot -prootpassword`

データベース内にテーブルを作成し、データを挿入。SELECTクエリの結果に、バックアップ時に挿入したデータ (id = 1, data = ‘backup test’) が表示されることを確認する。

`USE testdb; CREATE TABLE test_table (id INT, data VARCHAR(100)); INSERT INTO test_table (id, data) VALUES (1, 'backup test'); SELECT * FROM test_table`

バックアップの実行

`vackup export mysql-data mysql-data.tar.gz`

コンテナとボリュームの削除

`docker stop mysql-test docker rm mysql-test docker volume rm mysql-data`

コンテナを再作成

`docker run -d --name mysql-test \ --network test-network \ -e MYSQL_ROOT_PASSWORD=rootpassword \ -e MYSQL_DATABASE=testdb \ -v mysql-data:/var/lib/mysql \ mysql:latest`

MySQLコンテナに接続

`docker exec -it mysql-test mysql -uroot -prootpassword`

データが空であることを確認する。

`USE testdb; SELECT * FROM test_table`

復元

コンテナの停止。

`docker stop mysql-test`

ボリュームの復元

`vackup import mysql-test.tar.gz mysql-test`

MySQLコンテナを起動して接続

`docker start mysql-test docker exec -it mysql-test mysql -uroot -prootpassword`

データの確認。

`USE testdb; SELECT * FROM test_table`

SELECTクエリの結果に、バックアップ時に挿入したデータ (id = 1, data = ‘backup test’) が表示されることを確認する。

復元OK。

以上。

ConoHaのVPSを作成し、ssh用のユーザでログインまで

Fri, 09 Aug 2024 17:03:53 +0900

なんか昔を思い出す感じの入門的な雑記記事。もうVPSなんか流行らないと思って去年解約したんだが、なんやかんやあってまたいじりたくなってきた。いっときはもう全部サーバレスでいいんじゃないのみたいな感じにもなっていたが、最近いろいろ思うところあり、遅ればせながら真面目にコンテナ使っていろいろやろうとしている。そうすると、24時間稼働するコンテナ用のマシンを、家の環境以外のもうちょっとまともなところで欲しくて、まぁRAM 2GBならちょっとしたコンテナは動くでしょう、ということでVPSを借りることにした。

それでまぁ、なんだかんだで安いし、俺たちのGMOグループのConoHaを再び契約したのだった。

VPSの作成

まぁVPSの作成はダッシュボードから言われるままにサーバーを追加すればいいだけであり、特に何も言うことはないのだが、いくつか「ん？」となったところもあったのでメモ。

イメージの選択

何にしようかなと思ったが、別に今更新しいディストリビューションを試したいという気持ちもあまりなかったので、Ubuntu 24.04のイメージを入れた。CentOS Streamは憚られた。Rocky Linuxとか興味ないでもなかったが、Dockerについてさほど知見があるわけでもないし、Ubuntuのほうが情報量が多かろうと思った。アプリケーションとしてDocker用のイメージもあったのだが、KASUGAIはともかくDockerは自分でインストールしたほうが後々の運用も考えると良さそうに思えたので、特に利用せず、素のUbuntuにした。

rootパスワードは忘れるとめんどくさいので忘れずメモ。Bitwardenのセキュアメモでしている。

鍵とセキュリティグループ

SSHの鍵については最初に登録できるようだ。この時、セキュリティグループをIPv4v6-SSHにするなどして、22番ポートを空けておくと、スムーズに使える（ポート番号を変えるならその限りではない）。自分はセキュリティグループの存在に気づかず、defaultにして作成したため、「入れないんだが？？？」としばらく右往左往した。いつの間にこんなAWSみたいな機構ができたんだろう。まぁ便利だと思うけどさ。

鍵を作成する場合は忘れずにダウンロードしておく。ダウンロードした鍵は ~/.ssh 以下に置き、パーミッションを忘れずに400にしておく。

rootログイン

まぁ別にこれも取り立てて言うほどのことはないのだが、いくつか「ん？」となったところもあったので。

コンソールでログイン

いつのまにかWeb画面からコンソールでログインできるようになっていた。

SSHしなくてもログインできる手段があるのは心強い。ConoHaも進歩しているのだなぁと思ったのもつかの間、いじってみたところキーボードが全然きかなくて「クソぁ！」と思ったが、モードをVNCからシリアルに切り替えると、スムーズに動くようになった。VNCが全然使えなかったのは、Macだからとかあるのだろうか。

SSHでログイン

sshでのログイン方法については、普通通りなので特に言うことはない。一応当サイトでは10年以上前の若かりし頃に書いたなんか雑な記事がある。

SSHで鍵認証を用いて、パスワードなしでログインする方法

/20462465-2/

一応おさえるべきところは書いてあるように思う。多分。

秘密鍵を保持するディレクトリ（たいてい ~/.ssh ）のパーミッションは700
クライアント側は秘密鍵を400でもつ
サーバ側は公開鍵をauthorized_keysに登録する。パーミッションは600

ConoHaのダッシュボードからIPアドレスを確認し、以下のコマンド。

ssh -i 秘密鍵のパス root@IPアドレス

入れないときはセキュリティグループを確認して、IN TCP 22番ポートが空いているか確認する。

ユーザの作成とか

まぁいろいろ。

操作用のユーザを作成する

とりあえずrootログインはあんまりなので、sudo権限もったユーザは作っておくことにする。プロンプトなしはrootだと思え（雑）。

adduser ユーザ名
usermod -aG sudo ユーザ名
# ユーザ名でlogin
su - ユーザ名

$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh
$ cd ~/.ssh
$ touch authorized_keys
$ chmod 600 authorized_keys
# 使いたい公開鍵を追加
$ nano authorized_keys

authorized_keysに、公開鍵を追記する。ここらへんの操作の意味の詳述は上記の10年以上前の記事にだいたい書いてたはず。

以下を確認する。

作成したユーザでsshログインできる
sudoでコマンド実行できる

まぁそのほか、rootのsshログインを禁止するとか、ポート番号を変更するとかは、やりたければやりたいようにすればいいかなと思う。

sshのrootログインを禁止

まぁrootログイン禁止くらいはやっておくことにする。

# 編集
$ sudo nano /etc/ssh/sshd_config

# Ctrl-w で permitrootlogin を検索
# yesをnoにする
PermitRootLogin no

# Ctrl-o で保存する

$ sudo systemctl restart ssh

この後、rootでログインできなくなったことを確認する。

なんかミスって誰もログインできなくなったら、Webのコンソールから修正すべし。

所感

最近サーバいじりしていなかったので、なんだか懐かしかった。サーバスペックの限界まで使い倒したい。

Calibreで特定の本棚を公開するだけのコンテンツサーバをコンテナ化

Thu, 16 May 2024 01:34:55 +0900

pdfとかpptの資料管理としてCalibreを使っていて、コンテンツサーバを起動することでWebブラウザから本棚にアクセスできる。で、これを使って資料を共有すると便利だなと思ったのだが、普通にやるとプライベートの電子書籍を管理している本棚まで全部丸見えになってしまって困る。calibre-serverをCLIで起動すると特定の本棚のみ公開することも可能だが、calibre-serverは複数起動できないため、フツーにGUIアプリケーションとしてつかっているCalibreとは別に独立して動かす必要がある。

ということで、コンテンツサーバをやるだけのインスタンスをDockerで作る記事。

環境

本記事は以下の環境で確認しました。

M2 Pro Mac mini
macOS 14.4.1
Docker Desktop 4.29.0
Calibre 7.10

図にするほどでもないが、以下のような構成になる。

graph LR
calibre(Calibre GUI)
docker(Calibre Docker)
ebooks(公開したいライブラリ)
calibre --> ebooks
docker --> ebooks

手順

プロジェクトディレクトリは ~/ebooks-server とする。config と docker-compose.yml を用意するよ。

.
├── config/
└── docker-compose.yml

Calibreの設定ファイルの準備

Calibreの設定ファイルを準備する。Calibreの元ソースからコピってくるのが楽。どこにあるかはChatGPTさん曰く以下。

Macの場合： ~/Library/Preferences/calibre
Windowsの場合： %appdata%\calibre
Linuxの場合： ~/.config/calibre

僕が確認したのはMacだけ。Macでしか使ってないので。Macの場合は以下のようにコピーするとよい。

mkdir config
cp -r ~/Library/Preferences/calibre/* config/

docker-compose.ymlの作成

ファイルは以下。

services:
 calibre:
 image: linuxserver/calibre
 container_name: calibre-server
 ports:
 - 8081:8081
 volumes:
 - 設定ファイルのパス:/config
 - 共有したいライブラリのパス:/books
 command: /usr/bin/calibre-server --port 8081 /books
 restart: unless-stopped

設定ファイルのパスは上で作った configです。ライブラリのパスは共有したいライブラリのフォルダをそのまま指定。ポートはなんとなくデフォルトの8080からずらして8081にしたけど別になんでもいい。ホストマシン側の公開ポートは空いていればなんでもいい。

docker compose up -dで起動。停止したい時は docker compose down。

動作確認

http://localhost:8081 にアクセスして確認。共有したい本棚だけ見えたらOK。

本棚に更新があった時はめんどくさいけどコンテナ再起動する運用。ここはなんかもうちょっとどうにかしたい気もする。

複数の本棚

いっぱい増やせばいいよ。

services:
 calibre-1:
 image: linuxserver/calibre
 container_name: calibre-server-1
 ports:
 - 8081:8081
 volumes:
 - 設定ファイルのパス:/config
 - 共有したいライブラリのパス-1:/books # 公開したいパス
 command: /usr/bin/calibre-server --port 8081 /books
 restart: unless-stopped

 calibre-2: # 名前を変える
 image: linuxserver/calibre
 container_name: calibre-server-2 # ここも買える
 ports:
 - 8082:8081 # ポート被らないようにする
 volumes:
 - 設定ファイルのパス:/config
 - 共有したいライブラリのパス:/books # 公開したいパス
 command: /usr/bin/calibre-server --port 8081 /books
 restart: unless-stopped

http://localhost:8081とhttp://localhost:8082でそれぞれ公開した本棚にアクセスできればOK。

応用: インターネットに公開

以下の記事と組み合わせることで、簡単にログイン認証を入れてネット公開できる。

/calibre-cloudflare-tunnel/

Calibreにもユーザアカウント管理機能あって、それ使えばパスワード保護もできるんだけれど、Calibreの設定もネットワークの設定も何かとつらいので、このCloudflare使ったやり方のほうがいいかなと思う。

以上。

Calibreの本棚(コンテンツサーバ)に外部からアクセスする環境を整えるメモ(Cloudflare Tunnel利用)

Tue, 14 May 2024 10:40:37 +0900

Calibreのコンテンツサーバ機能はとても便利だ。Webブラウザから蔵書を検索できるのは利便性が高い。できればインターネット上からアクセスできると、外で本をダウンロードできるし、また本屋で「これ積んでるっけ？」と悩まなくて済む（読め）。

ということで、Calibreの本棚（コンテンツサーバ）をインターネット上に公開しつつ、自分以外はアクセスできない状態にしたい。前提条件として、Cloudflareでドメイン管理していること（Cloudflareのサービスを利用するので）。

Calibreの機能としてはユーザアカウントを管理してパスワード保護したうえで外部公開、みたいなのがドキュメントにあるのだけれど（calibre コンテンツサーバー — calibre 7.10.0 ドキュメント）、Cloudflare使うほうが簡単かつ安全かなと思う。

前提と環境

前提

Cloudflareでドメインを管理している
- ネームサーバもCloudflare

ホストマシンはMacを使うが、WindowsでもLinuxでもできるはず。以下の環境。

M2 Pro Mac mini 2023
macOS 14.4.1
cloudflared 2024.4.1 (built 2024-04-22T22:16:50Z)
Calibre 7.10

Cloudflare Tunnelを利用する。これは使うと簡単にNAT越えっぽいことができる。構成的には以下のような感じになる。

graph LR
client(Client)
cf(Cloudflare)
subgraph Mac
calibre(Calibre)
cloudflared(cloudflared)
end
client -->|books.example.com| cf
cf -->|tunnel| cloudflared
cloudflared -->|http://localhost:8080| calibre

つまり books.example.com にアクセスすることで、localhostのコンテンツサーバにアクセスできるようにする。これだけ見ると全世界に本棚公開やんけとなるが、素晴らしいことにGUIで設定ポチポチするだけで、メールアドレスによる認証ができる。

Cloudflareのサービスをめっちゃ使うので、Cloudflareでドメイン管理していることが前提条件となる。

手順のメモ

UIとかどうせ変わりそうだから、かなり雑に手順。まぁだいたいわかるでしょくらいの感じで。

Calibreでコンテンツサーバを起動する

まぁまずは言わずもがなだけれど、Calibreで「接続/共有」よりコンテンツサーバを起動する。デフォルトだとlocalhostの8080だろう。

Cloudflareでトンネル作成する

Cloudflareのコンパネにログイン
Zero Trustを起動してNetworksのTunnelsよりトンネルを作成する
流れに沿って設定していく。トンネル名はなんかわかりやすいヤツを適当に。ホストマシンに cloudflared をインストールしてトンネル開通

Macの場合はhomebrewでインストールのうえ、 /Library/LaunchDaemons/com.cloudflare.cloudflared.plist にplistファイルが作成される
- エラーログは /Library/Logs/com.cloudflare.cloudflared.err.log に出るのでなんかおかしかったら見るとよい
- デーモンの起動や停止は launchctl start(stop) com.cloudflare.cloudflared で。
疎通したらダッシュボードにその旨が出るので確認

Public Hostnameからpublic hostnameを追加する。サブドメイン適当に決める

ここで決めたサブドメインはDNSのレコードにCNAMEで登録される
疎通先を http://localhost:8080 にする

これで設定したドメインにアクセスするとCalibreのコンテンツサーバにアクセスできるようになる。

Accessで認証入れる

このままだと全世界に自分の本棚が公開されてしまい、著作権法上も大きな問題であるし、自分の尊厳も問題になると思われるため（本棚による）認証を入れる。

Zero TrustよりAccess -> ApplicationsよりApplicationを追加
Self-hosted
名前はなんかわかりやすいやつにする。ドメインは上で設定したドメインにしてNext
ポリシーの名前はなんか適当に決める
Configure Rulesはメールアドレスにして、許可するメールアドレスを指定してNext

IPアドレスの指定とかもできる

CORSとかCookieの設定ができるが特に何もせずAdd an application

必要があればやる

これで当該ドメインにアクセスするとメールアドレスの認証が求められる。メールアドレスを入力すると、6桁の一時パスが送られるのでそれを使ってログイン。とても便利。

応用: Dockerでコンテンツサーバを別のインスタンスで起動する

Dockerでコンテンツサーバのコンテナを作ることにより、自動的にサーバ起動させるとか、特定の本棚のみ公開するとかも可能だ。なんでわざわざDockerを使うかというと、calibre-serverのインスタンスは同時に複数起動できないためだ。なのでコンテンツサーバ専用のコンテナを作成する感じ。

これによってGUIのCalibreの起動状況を確認しなくてよくなったり、pdfなどの資料の共有をしたり、共有時にプライベートのあらやだ奥さんみたいな本が間違って目に入るような事故を起こさずにすんだりなど、けっこう便利に使えるのだが、書き始めるとそれだけで記事になってしまうため割愛。気が向いたら記事にする。

（追記）記事にした。

Calibreで特定の本棚を公開するだけのコンテンツサーバをコンテナ化

/calibre-docker/

所感: 自宅サーバ復活の予感

10年くらい前に自宅サーバは浪漫枠みたいな記事を書いた。

/45948138-2 2015年の記事だと……

しかし、Cloudflare TunnelとDockerのおかげで、一時は浪漫枠になったかと思われた自宅サーバに復活の機運を感じる。今までネットワークの設定とかインフラのメンテナンスがめんどくさすぎ問題のために、自宅サーバなんかもうやってられませんわという感じだったのだが、Cloudflare Tunnelで極めて楽にネットワークが構築できるようになり、さらにDockerを使えばソフト面の構築・運用も楽々。

まぁもちろん可用性の確保とかスケーラビリティとか考え出すと自宅サーバはキツいのだが、逆に言うとそこらへん適当でいいなら自宅サーバで全然OK。

で、こういう大量のデータを扱うコンテンツサーバは自宅サーバ向きの一つ。さらに言うと、最近のクラウドは検閲めいたことも平気でやるので、プライベートなデータを置いておくには不安で仕方ない。垢BAN気にしなくていいのは精神的にだいぶ楽。あと最近はAIが出てきたのもある。グラボも回したりベクトルデータ扱えるElasticsearchみたいなリッチなサーバもほしくなるが、このへんはクラウドでやると余裕で破産できるので、オンプレミスにも価値が出てきた。

そんなわけで、自宅サーバもアリなんじゃないかと思うようになってきた今日この頃である。

参考記事

ありがとうございました。

LAN内DropboxとはいかないQsyncの使いどころ

Thu, 23 Nov 2023 15:52:24 +0900

Dropboxの有料会員なのに、QNAPのNAS、TS-233をポチってNASに移行できないかを試行錯誤している。QNAPはいくつかの便利なソフトウェアを提供しており、そのうちの一つがQsyncだ。これはNASとクライアントマシン間で同期フォルダを作成するもので、まぁ一言で言えば自前のDropboxをLAN内に作成するようなものと言える。

Qsyncは便利なソフトウェアなんだが、やはり同期というのは難しいようで、「Dropboxはすげぇんだなぁ」という再認識することもある。DropboxのヘビーユーザがQsyncに置き換えるのは厳しいと思う。一方でQsyncにも使いどころは確かにある。

Qsyncを使っていて起きたこと

Qsyncの機能を使い始めて1,2ヶ月程度だが、「TBクラスのフォルダの同期」「大量削除」「大量リネーム」「既にファイルがあるフォルダ同士で同期」など色々やったので、一通りのことは経験出来たのではなかろうかと思う。

これで起きたことは、「同期漏れ」「ゾンビのように復活する削除ファイル」「大量に生まれた重複ファイル」「クライアントアプリが（中途半端に）落ちる」である。

同期漏れとは、たとえば 「同期されなければいけないファイルが永遠に同期されない」現象である。しかしクライアントでは「すべて同期済み」になっている。なんでそうなるのかはよくわからない。常に起きるわけではない。サブフォルダ内のファイルであれば、ファイルのあるフォルダごと削除してもう一回作り直すなどすれば同期されると思う。いずれにせよ、そのままにしておくと端末間で同期フォルダの中身が違う状態が続く。

また、 「あれ？消したファイルが復活してる🤔」ということがある。これはファイルのリネームなどでも「リネーム前のファイルが残っている」などが事象として発生した。多くはダウンロードしてすぐのファイルを操作した時なので、まぁ事情はわかる。とはいえDropboxではこういうことはほとんど起きないことでもある。

「クライアントアプリが（中途半端に）落ちていた」ということも頻発した。中途半端にというのは、フォルダの同期が完全に止まったわけではなくて、サーバ→クライアントのダウンロードはできているのに、クライアント→サーバのアップロードだけ止まっているような状態だった。

そのため気づきづらく、ツールバーにQsyncのアイコンがないことで「あれ、止まってる？」と思って気づいて再起動をかけるのだが、そうすると、落ちていた間にクライアント側で削除したファイルなどが大量復活することになる。この落ちる現象は、作業量に比例しているように思う。大量のファイルを頻繁に追加・削除・移動を繰り返していると起きやすいような。Mac上で起きたが、Windowsでも起きるのかどうかは（試していないので）わからない。

また、ファイルの重複判定もけっこうつらいところがあって、たとえばファイルがあるフォルダ同士で同期をかけるとカオスなことになるため、やめたほうがよい。たとえバックアップツールなどでバックアップしたフォルダであってもやめたほうがよい。最初の同期は、時間がかかっても片方のフォルダを空にしておくほうが無難だろう。

普通にしていても、「両方保管する」にしてしまうと知らない間にduplicateなファイルが出来ているので、NASかクライアントか、どちらかを真とする設定にしておいたほうが良い。ちなみに僕はクライアントを真としている（NAS側を直接操作することはない運用）。

問題は、こうした意図しない同期について、必ずしもユーザが気づけないことだ。たとえば階層の深いところで人知れず起きていた場合、それに気づくのは難しい。また、フォルダ構成が複雑であるほど期待しない挙動も多かったように感じている。

結論としては、 「階層の深いたフォルダの同期」や「頻繁に削除・リネームを実行するフォルダ」では使わないことにした。つまり、Dropboxのようにまるまる2TBの同期フォルダ、という使い方はしない。

Qsyncの使いどころ

それではQsyncは使えないのかというとそんなことはなくて、実際僕は便利に使っている。前述の不安定要素を加味したうえで、「端末間でファイルをやりとりしたい」フォルダをピンポイントで同期すれば、なかなかうまくワークする。特にDropboxフォルダの下という制約がないことによって、部分的にはDropbox超えの使い勝手の良さがある。

具体的には、たとえば「ダウンロード」フォルダだ。ノートPCでダウンロードしたものをデスクトップPCでも開けるのはけっこう便利だ。今まではこれを実現するために、Dropboxフォルダの直下にわざわざDownloadsフォルダを作っていたのだが、Qsyncによってシステムのダウンロードフォルダをそのまま同期フォルダとして指定できるようになり、便利になった。

こういった一時保管場所的なものだけではなく、アプリケーションの設定ファイルや素材置き場など、「頻繁ではないがたまに追加があって、変更があった時にはすぐにデバイス間で同期されてほしい」みたいなフォルダでも使っている。これも、Dropboxフォルダの下という制約がないのでやりやすくなった。

rsyncじゃダメなんですか

そうしてピンポイントに同期フォルダを作成すると、残りのフォルダについては、必ずしも常に同期されていてほしいわけではないことに気づいた。ほとんどのフォルダは、1日に1回程度の同期でも十分だ。つまり、定期的にrsyncを動かすだけで十分だった。

Macとrsyncについては文字コードの正規化問題でかつては苦労させられたものだが、そんなことも今は昔だ。そのへんの話は下記の記事でも触れている。

QNAPのNASを使ったバックアップとファイル同期

/qnap-nas/

上記の記事でも触れているが、WindowsだったらFreeFileSync: Open Source File Synchronization & Backup Softwareが使いやすいかなと思う。

Dropboxは有能だが

こうして使って見ると、何も考えずに快適に全ファイル同期できていたDropboxは本当にすごいなと思う。思えば昔はduplicateとかもよくあったが、最近はあまり見なくなった気がする。地味な進化を続けているのかなぁ。Macの文字コード正規化問題についてはDropboxは手当てしてくれていたし、痒いところに手が届く。

Dropboxの2TBの同期フォルダは、非常に強烈かつ優秀な機能であり、これをセールであれば3年契約月額1000円相当というのは、十分に価値があるものだと個人的には思う。

2TB以上の容量を求めると個人ではつらい感じもあるが、これは前述のとおり、「常に同期されていてほしいフォルダは実はそんなに多くない」ものである。ただまぁ、Dropbox下にファイルがなければならないという制約は、ソフトリンクを駆使してもまぁまぁ厳しいかもしれない。それだったらピンポイントに同期フォルダを作ることができるQsyncのほうが良かったりもするのかも。

Qsyncは使える

まぁそんなわけで、NASについての記事なのにひたすらDropboxを褒め称えてしまっているのだが、そうは言ってもNASのほうが長期的にはコストが低いのは確かだし、また何よりも、 「クラウドにデータが上がらない」というのは、実際けっこう精神的な開放感があることに気づいた。最近はどこのプラットフォームもビッグブラザーめいてきているからねぇ……。LAN内で完結させたほうがいいこともある。

まぁLAN内Dropboxだぜー、というわけにはいかないものの、自宅内に複数台のデバイスがあるユーザにとってはQsyncは十分使いどころのあるソフトウェアだと思った。というか、使っている。

ちなみにmyQNAPcloudのサービスを使えば楽にクラウド化できると思うが、まぁまぁ高いし（myQNAPcloud Storage）そもそもそれだったらDropbox使えばええやんと思う（5TBとか10TBやりたいなら価値あるかも）。自宅にVPNサーバとかたてたらいけるのかな。まぁ、外で同期したいと思うことが最近はないので、そこまで頑張る気もないや。

QNAPのNASを使ったバックアップとファイル同期

Sun, 05 Nov 2023 04:55:56 +0900

最近DropboxからNASに移行しようとしている。具体的にはQNAPのTS-233を購入し、あれこれと運用方法を試行錯誤している。

Dropboxから少しずつNASに移行中

/dropbox-nas/

NASに期待する機能

僕のNASに求める機能は以下である。

デバイス間でのフォルダ同期
データのバックアップ
メディアサーバ

デバイス間でのフォルダ同期: Qsync

デバイス間でのフォルダ同期とデータのバックアップを一挙に解決するものとして、Qsyncが期待された。これは同期フォルダを作成して常にNASとクライアントのデータを一致させるものだ。まぁ一言で言うと自分専用のDropboxを作る機能といえる。

しかしこの同期というやつはやはり難しいもののようで、いざ運用してみるとなかなかうまくいかない。特にファイルが消えないようにするためか、移動や削除、ファイル名の変更をしていると、「消えているべきファイル」がゾンビのように復活する。まぁ安全面に倒すとそうなるのはわかるが、Dropboxの静かな有能さが際立つ結果となった。

まぁでも、これはそうなるかなという気はしていた。テラバイトクラスの巨大なデータフォルダを監視するようなものではあるまい。もしこれをやりたいのであれば、これを専業でずっとやってきたDropboxを大人しく使うのが良いと思う。

また、MacだとQsync クライアントがしばしば落ちている。ただこの落ちるというのも中途半端で、たとえば別デバイスで保存されたファイルの同期はされるのだが、Mac側での削除処理などがサーバに伝わっておらず、「あれ？クライアントアプリ落ちてるな」と思って再起動させると、落ちていた間に削除したファイルが次々と復活するなどかなり鬱陶しいことになる。

以上を踏まえたうえで、要所要所「ここは同期する価値がある」というフォルダについて適用するのが良い運用法だろう。Dropboxのように脳死でまるっと全部同期フォルダにしてしまう、などはやらないほうが無難だ。しかし、Dropboxと違って、色々な場所に散在するフォルダを同期フォルダにできるのはQsyncの強みといえよう。

データのバックアップ: rsync最強伝説もう正規化問題はないんだ……

NASの本懐というべきか、データのバックアップもNASに求められる重要な機能だ。Qsyncはバックアップツールに使うのはやめたほうがよさそうということがわかったので、何かいいツールを探す必要があった。真っ先に思うのはrsyncなのだけれど、今更rsyncとか使いたくないなぁと思い、FreeFIleSync（Download the Latest Version - FreeFileSync）というソフトを使ってみたりした。これはWindows用とMac用がそれぞれあり、けっこううまいこと使えた。

うまいこと使えたのだが、毎度起動するのが面倒である。ってかこれだったらrsync使うほうが楽なのでは？WindowsでWSL経由したら面倒だけれど、Macならフツーにターミナルから実行できる。

rsyncなら慣れてるし、何よりも我々を悩ませてきたUnicode正規化問題はAPFSになってから概ね片付いている。というか多分僕がなんとなくrsync使いたくないなぁと思っていたの正規化のトラウマのせいだと思う。傷深すぎんよ。

戦いの歴史貼っとく。

/30878779-2/ 2013-08-21

/46001270-2/ 2015-11-15

/gdrive-mac-win/ 2017-11-28

しかし今記事を読み返すと、SMBでマウントしてるのにssh使ってrsyncしてたりするの謎だなぁ。SMBのマウントが不安定で勝手に切れてたりしたからだろうか。

まぁなんでもいい、すべては終わったこと……。我々を悩ませた悪魔はもういない。存分にrsyncしていいんだ……。

ということで、結局rsyncに落ち着いている。WindowsだったらFreeFileSyncを使うほうが楽かも。

なおTimeMachineについてまったく書いていないが、過去色々と痛い目を見たので、ネットワーク越しでは使わない。NASじゃなくて、ローカルにケーブル接続して使うならいいと思う。でもそれはそれで面倒だし、システムごと復元したいことって実はそうないので、rsyncによるデータバックアップのほうが汎用性も高くて良いと思っている。

あとはまぁ、災害とかで全データ消失しちゃうリスクか。Dropboxだとこれの心配がないんだよなー。しかしそんな災害やら火事やら、データよりもっと心配すべきものがあるだろという話ではある。

メディアサーバ: 検討中

最後にメディアサーバとしての役割だが、これはまだ検討中。

LAN内ではMacがメディアサーバとして役割を担っている。Mac mini常につけっぱなしだからね。コレは別にこのままでもいいかなぁという感じ。Macのほうがスペック的にも高いのだし。

インターネット経由だと、今はDropboxにアップロードしている音楽ファイルをストリーミングとかしているんだが、これをできないかなぁと思っている。QNAPのソフトウェアにこれができそうなのもあるので、もうちょっとちゃんと検討したい。

Dropboxは便利だけれど、自宅NASには自由さがある

色々やっていて思ったのは、Dropbox便利だなぁということだ。専門的な知識がなくても、ここまでにあげた機能はすべてカバーできる。ソースネクストから買える3年契約だったら定期的にセールしていて年間1万くらいだし、それくらいの価値はあるよなと思う。容量が2TBなのがつらいってことくらいか。あと円安で今後はどうなるかわからないな。

まぁでも、やっぱりNASには自由さがある。クラウド業者にデータを覗かれる心配がないし。GoogleとかMicrosoftとかで、家族の風呂写真あげてるだけでアカウントBANされたみたいな話聞くと、おいおい何してくれてんだビッグブラザーって思う。ここらへんは同じように悩んでいる人がたくさんいる（参考: 機能的で検閲のないクラウドストレージ、ゼロ説 | 点と接線。）。

クラウド事業者がユーザのファイルをスキャンして、挙げ句「お前のデータはポリシー違反だ」として削除あまつさえBANするのは、ド直球の検閲だ。そんなビッグブラザーの運営サービス気持ち悪くて選ばれるわけないから、片手間にオンラインストレージサービスやってるGoogleやMicrosoftの傲慢がそうさせているんだろう。経済合理的にはそんな検閲して1ミリの得もないと思うが、GoogleにせよMicrosoftにせよ、なんかアレゲな連中にコア部分を乗っ取られている感あるなぁ。

しかし、専業のDropboxはそんなことでユーザが離れたら死活問題なので、しないんじゃないかな、多分。スキャンはしているらしいけど（クラウド検閲問題について）、実際にBANされたって人は聞かない。少なくとも僕は今まで無事です。調べても、Googleブラザーがバンバンしている検閲問題で一緒に名前が挙げられているという感じで、少なくともエロやらのせいでDropboxから永久追放されたという話は聞かない。サービス内容が地味でキラキラしてないし金も有り余っているわけではないため、アレゲな連中にまだ乗っ取られてないんじゃないか説。まぁこれは勝手な邪推だけど。

まーでも、今後はどうなるかわからんし、僕はこの機にアレなファイルは全部NASに移行した。別にアレなファイルじゃなくても、データがネットに流れないってのは、存外開放感があるものなんだな、と思った。ま、NASも悪くないな。Dropboxの契約2年くらい残ってるけど。

[![QNAP TS-233](https://m.media-amazon.com/images/W/MEDIAX_849526-T1/images/I/51SfanPiqSL._AC_SL1500_.jpg) ### QNAP TS-233](https://www.amazon.co.jp/dp/B09MZBK7C8?&linkCode=ll1&tag=hackle12-22&linkId=b19cb9b8c22a410729bc6a604f03b285&language=ja_JP&ref_=as_li_ss_tl)
<!-- アフィリエイト開示文 -->

このリンクを通じて購入すると、管理人にアフィリエイト収入が入ります。記事が役に立ったらクリックしてもらえると嬉しいです。

Dropboxから少しずつNASに移行中

Sat, 30 Sep 2023 22:45:52 +0900

最近の記事で、DropboxのためにMac mini 2018で外部ストレージを起動ディスクにしたんだみたいなことを書いた。が、実は7月にしれっとNASを買っており、それを使ってDropboxから移行しようと画策している。Dropbox自体は便利で良いサービスなのだけれど、macOSの新仕様のために、やたらと使いづらくなる未来が見えているためだ。Appleの方針は揺るがないだろうし、iCloud並に使いづらくされてしまう可能性もある。また、Dropbox側のものとしては、iPad ProでDropboxのアプリを使うとやたら落ちるという現象も残念であった（とはいえこれはクリティカルではない）。

ということで、Dropboxのライセンスはあと2年半近く残っている状況でなんだかもったいない気もしつつ、NASへの移行を少しずつ進めている。

NASを買った

購入したNASはQNAPのTS-233だ。だいぶ前に、「NASは1ベイで十分」みたいな記事を書いたのに、結局2ベイNASを買った。

家庭用なら1ベイNASで十分だ

/nas-1bay/

なんでかというと、1ベイNASはスペックが低いからだ。NASは気をつけないと、未だにメモリ512MBとか1GBのモデルが平然と売られているのだが、1ベイNASはまさにそんな感じ。しかも別に安くない。まぁ考えてみると、メーカー的には1ベイだろうが2ベイだろうが構成は大して変わらず、別に1ベイだから安くできるということもないのかもしれない。

大きさ的にも2ベイのサイズのほうが何かと余裕があるだろうし、コスト的にも2ベイNASがちょうどよかろうという感じだった。それにまぁ、また趣味的にRAID組みたいと思うことがあるかもしれないし。

で、このTS-233は値段がそれなりに熟れていてかつ、メモリも2GBだったので、Amazonのセールに合わせてポチった。

QSyncの実力

QNAPが出しているソフトウェアの中に、QSyncというものがある。これはNASとPCの間に同期フォルダを作るもので、まぁいってしまえば自前でDropboxを作るようなものである。こういったソフトウェアを使うためにも、メモリは2GBほしかった。

これを使うと、下記のような構成が実現できる。

graph BT
nas(NAS)
mac(Mac mini 2018)
win(Windows Desktop)
win_n(Windows Laptop)
mac nas
win nas
win_n nas

考え方としては、NASは端末間のデータをやりとりするための中継地点であり、バックアップでもある。

情報がそんなにたくさんあるわけではないので、パフォーマンスや安定性は未知数。これはもう使ってみるしかないかな。僕はけっこう激しくファイルの追加・削除を繰り返す作業をすることもあるし、複数のPCで同じファイルを扱うこともあるし、特にMacはファイルシステムのせいで濁音問題がややこしいとかもあるが、大丈夫だろうかと心配がある。

ざっと使ってみた感じだと、ファイルの増減が緩やかならまず問題はなさそう。パフォーマンスも思ったより速い。Dropboxと遜色ないか、ちょっと上かも。また、ドライブをまたいで同期フォルダを設定できるなど、Dropboxにはない柔軟性は嬉しい。

一方で、同期中に大量のファイルの削除や更新をすると（数万ファイル、数十GBくらい）、ちょっと挙動が怪しい感じがする。同期が詰まる感じというか。削除したファイルが復活したり。また、TBクラスのフォルダを同期したときにちゃんと動くかちょっと不安。まーでも、同期の初動はちょっと注視しないといけなかったとしても、運用までいったら基本的には問題ないんじゃないかな？と思っている。

MacからのSMB接続はやっぱり遅い

MacからのSMBによる接続はやっぱり遅い。まぁこれはもう諦めている。一応対応はあるんだけれど、これをしてもやっぱり遅いんだ。