Cloudflare on 或る阿呆の記

Ubuntu 24.04 で cloudflaredのアンインストール

Wed, 18 Feb 2026 10:49:54 +0900

なんか公式ドキュメント見て見つからなかったのでメモ。Claude生成だがまぁあってそう。

環境

Ubuntu 24.04.3
cloudflaredはパッケージでインストール

とりあえず停止。

sudo systemctl stop cloudflared
sudo systemctl disable cloudflared

パッケージでインストールした場合は以下。

# パッケージをアンインストール
sudo apt remove cloudflared

# 設定ファイルも含めて完全削除
sudo apt purge cloudflared

# 不要な依存関係を削除
sudo apt autoremove

# サービスファイルを削除
sudo rm /etc/systemd/system/cloudflared.service

# Drop-In設定ディレクトリも削除
sudo rm -rf /etc/systemd/system/cloudflared.service.d

# systemdをリロード
sudo systemctl daemon-reload

確認コマンド

# cloudflaredが残っていないか確認
which cloudflared

# プロセスが残っていないか確認
ps aux | grep cloudflared

# サービスの状態確認
systemctl status cloudflared

以上。

Cloudflareはなぜインターネットにご迷惑をおかけできたのか

Sun, 11 Jan 2026 00:00:00 +0900

いまさら擦るのもなんですが、昨年(2025年)末にあったCloudflareの大規模障害について、思うことがあります。

一度目の障害

まず最初に11月18日の大規模障害があり、これは多くの衝撃を界隈に与えました。当時のITmediaのトップニュースはCloudflare一色でした。侵食されている。

印象的だったのは、なぜかAdobe民が悲鳴をあげていたことです。聞くところによると、なんだか起動するたびに毎度オンラインのライセンス認証が必要な仕様らしく、その門番がCloudflareだったようなんですね。

本質的にオフラインの作業なのにと、多くの人が嘆いていましたが、原因に気づけているだけましだったのではないでしょうか。原因すらわからず、多くの不要な作業をして、さらにそのミスで取り返しのつかない消失など憂き目にあった人もいたかもしれません。

この障害について、Cloudflareは即座にポストモーテムを出しました（「2025年11月18日のCloudflareの障害」）。それが非常に迅速であったこと、また障害自体はあるものだいう理解で、SNSを見る限り界隈はどちらかというと対応がはやい、さすがだ、と称賛のようなムードがあったと記憶しています。またポストモーテムにあった「インターネットに多大なるご迷惑をおかけしましたことを深くお詫び申し上げます」というぽエティックな文言について、「カッコいい」と無邪気にツイートするエンジニアを見かけました。

一方私は、このサイトにCloudflare Tunnelを使っていたもので思いっきり影響を受けており、特に障害を責め立てる気はないものの、障害を起こしてカッコいい、とは思えませんでした。ついでにいえば、ご迷惑をかけたのはインターネットではなく私だと思うが、私のところにメールが来ていない、とあまり愉快ではない気持ちがありました。

二度目の障害

インターネットにご迷惑かけてからほんの二週間後の12月5日、Cloudflareは再び大規模障害を起こしました（「2025年12月5日のCloudflareの障害」）。この時は「またかよ」という気持ちで、あまり界隈のムードも観察していませんでしたが、どうだったんでしょうね。さすがに二度目は白けていたでしょうか。

こうなると、根本的な構造に対する批判の声もあがります（「ヴィタリック・ブテリン、CloudflareとAWS障害受けDAppsによる分散化インフラを提唱」）。

なぜご迷惑があったか

さて、この件についてお思うことはいろいろありますが、まずなぜ私のサイトが落ちたのかを私の視点から問い直せば、それた端的に「Cloudflare Tunnelを使っていたから」になります。なぜ使っていたのかといえば、CDN的な機能がほしいというより、証明書やルーティングが楽にできるからです。あとなんかDDoSみたいなことがあってもCloudflareが前段で受けるしなぁとかいう意識もあるかとは思います。

まぁこのサイトは個人でやっているものなのでその程度の理由ですけれど、ビジネスユースでも利用の本質は大して変わらないんじゃないでしょうか。ちょっと腐しましたがCloudflareは便利なサービスを提供していると思います。結局私も便利だから使っていたのですね。

そうして皆が便利だからと合理的に判断して使った結果、Cloudflare自体がインターネット全体の単一障害…になっている、というのはちょっと笑えないし、これこそがあるべきではないことに思えます。もっといえば、一民間企業のCloudflareがインターネット全体にご迷惑をおかけできること自体がおかしい。少なくともおかしいと思わなければならないでしょう。たとえそれが一人ひとりの選択の結果であったとしても、その結果がこれならば、全体として素直に間違えていたと考えるべきだと思います。

しかし、今それを社会的に合理とする根拠がありません。多くの組織人は自分のサービスについてまでは責任を持ちますが、インターネットに責任は持ちませんし、持てません。それはCloudflareも同様です。Cloudflareが責任を持てるのは自社のインフラまでであって、それはインターネットではありませんし、あるべきでもありません。

したがって、少し言葉遊びになりますが、全員が合理的にふるまうと合理的に壊れるならば、誰かが不合理にふるまうことが、全員にとって合理的、だと言えます。その不合理が搾取や強制のためであれば救われませんが、それが偶然や信条であれば、問題はありません。むしろ、今まで我々はずっとそうしてきたのだと思います。個人の合理が全体の不合理であるように、個人の不合理が全体の合理となる。そういうこともあります。

なのでとりあえず私は、手間暇かけて、Cloudflare Tunnelよりも性能が低い終端とトンネルを、自サイト向けに作っていこうかと思います。

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

Sat, 22 Nov 2025 00:00:00 +0900

先日はCloudflare大爆発でインターネットが壊れ、CloudflareのCDN使っている当サイトも落ちたんですわ。ちょうどいいタイミングで来てくれた方すみません。まぁ、察し……だったかもしれませんが。

Cloudflare使っているのは端的に言うとTLS終端が面倒くさいからなんだけど、そういう人けっこう多いんじゃないかな。つくづくhttpsは無駄どころか害悪というか、ボディブローのようにWeb全体にダメージを与えている……実質強制しよったGoogleさんェ……。

しかしこうして障害が起きたときに無力なの見ると、やっぱりめんどくさがらずにちゃんとやるべきか……。ぐぬー。Cloudflare使う方が可用性は高いとかじゃないんだ、俺のサイトが落ちて、俺がそれに気づいているのに、俺が何もできない、それは俺のサイトと言えるのかって、そういう話なんだ。うむー……ちょっと考えます。

で、この件についてCloudflareから全然詫びメールこねぇなと思いつつ、Gigazineで記事になっているのを読んだ。

Cloudflareが大規模障害の原因を発表、XやChatGPTなどインターネット全体に影響を及ぼした障害はサイバー攻撃ではなくシステムの問題 - GIGAZINE

Cloudflareによると、障害の原因はシステムの不備であってサイバー攻撃ではないとのこと。Cloudflareは「今回の障害は直接的にも間接的にもサイバー攻撃や悪意ある活動によって引き起こされたものではありません」と述べ、他者からのシステム侵入を強く否定しています。

読んだ時、だからなんだと思ったよ。サイバー攻撃だろうとシステムの問題だろうと、起きたことが変わるわけじゃない。もちろん原因追及自体は重要なことだけれど、殊更にシステム侵入ではないと強調されても、知らんがなと思う。

この「銀行強盗を撃退できない銀行は許されないが、銀行員のミスで大規模やらかしはしゃーなし」のような奇妙な空気感は、IT業界全体としてあるように思われる。しゃーなしは言い過ぎにしても、「サイバー攻撃ではない」と強く否定するのは、実際的な影響の問題というより、そちらのほうが沽券に関わる、と考えているからじゃないか。

しかしユーザからすれば、サイバー攻撃なのかシステムのやらかしなのかは関係がない。システムダウンさせるのが悪意のある攻撃者なのか、悪意はないけど内部の無邪気な阿呆なのか、前者ではないと強調する意義はよくわからない。これからも無邪気な阿呆がダウンさせ続けたり情報漏洩させるなら、何も安心できないと思う。

システムのやらかしなら情報流出が起きないわけではなく、実際「違うユーザの情報が表示される」というマークシートがズレたみたいなやらかしは稀によくある。最近だとChatGPTのやらかしとかあった（「ChatGPTで個人情報漏えい OpenAIが原因と対策を説明 - ITmedia NEWS」）。

システムは机上の論理的存在ではなく、現実に動くモノだ。価値が生まれるのは設計された時ではなく運用された時で、設計と運用は一体となっている。しかしながら、技術屋というのは設計に寄りがちな人種が多いらしい。確かにまぁ、設計のほうがより技術らしいというか、頭のいい感じにはなるんだがね。

外部からの攻撃ではないんだと言いたがるのは、設計の問題ではないんだとつまり言いたいのかもしれない。技術力の敗北ではないのだと。

だが原因がどこにあろうと、起きたことは大規模障害。結局、運用の敗北もまた技術の敗北だ。

別にそれ自体が悪いってんじゃない。実際、100%防ぐことは不可能だ。それはそうだ。ただ、なんで僕は僕のサイトが落ちてるのに何もできないんだとか、全然詫びメールこねぇなぁとか、普段は「はやくアップデートしろ！攻撃されても知らんぞー！！」とアップデートを脅迫的にせっつくのに、現実には何をしたところで勝手にやらかすやんとか、そういうことは思うよ。

なんというか、対等じゃないし、こっちに目が向いてないな、ということはひしひし感じる。ブログにポストポーテム「2025年11月18日のCloudflareの障害」あがってるから読んだんだけどさ。

Cloudflareチーム全体を代表し、本日インターネットに多大なるご迷惑をおかけしましたことを深くお詫び申し上げます。

君らが迷惑かけたのはインターネットじゃなくて俺だよ。君らにとってはインターネットなんだろうけれど、俺にとってはたった一つのサイトなんさ。知ったこっちゃなかろうが。いや、一応ちゃんと前段で「お客様」にも詫びてるんだけどさ。まぁ、それだけの責任を感じているというレトリックなのはわかるよ。そうなんだろう。実は俺もたった一つのサイトってのは嘘だからな。けっこうサイトやってんのさ。CF使ってないサイトは落ちなかった。レトリックだよ。しかしそれにしても、メールこねぇな。

理念を見て人を見ない時代。そういう違和感がずっとある。

<関連記事>

あわせて読みたい

Google様の言いつけに従って、https化の準備をしなくてはならない

/https63/

あわせて読みたい

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

/yaranakuteiikotobakarishiteiru/

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。

脱クラウドとは何か

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は成り立たないのはそう。っていうか普通に使っていると相当依存するよね。だからこそ脱クラウドとか言い始めているわけで、クラウド依存していなければそもそも脱する必要がない。

逆説的に、脱クラウドとはクラウド依存患者であることの告白である。そして何故依存したのか？という個人的な問いなしに脱クラウドはありえない。そこには必ず何かを求めた経緯があるはずだ。それと向き合って、現実を見て、過去を振り返り、未来を考えて、何を求めたのか、求めたものは得られたのか、得られていないのか、まだ求めているのか、これからも求めるのか、そもそも本当に求めていたのか、そういう問いかけは必ずいる。

ゼロイチじゃないので、何をどうするのか、都度自分の判断になる。ああしろこうしろという気はまったくないし、逆に言われる気もない。各自勝手にやるがいい。あるいは、勝手にやれるべきだ。まぁそんな感じだよ。

<関連記事>

あわせて読みたい

自宅サーバーは浪漫枠

/45948138-2/

外出先からAndroidタブレットで自宅PCにSSHでログインしてターミナルによる開発生活

Tue, 14 Oct 2025 00:00:00 +0900

やりたいことは表題のとおり。なんかこう、省エネで外から開発するのに最低限必要な、でも普段使いのブランジングとかには困らなくて、かさばらなくて……そういうのないかなぁMabは高いしなぁ、とか思っていたところ、タブレット良いのでは？という風に思われた。

まぁ現実的には色々と制約があるのだが、とりあえず最低限のことはできそう。

環境および前提

Android
- Lenovo Yoga Tab Plus
  - SoC: Snapdragon 8 Gen 3
- システムバージョン 17.0.12.046
- Android 15
ホストマシン
- M2 Pro Mac mini
- macOS 14.7.7
インフラ
- Cloudflare Tunnelを使う
  - またかよ
    - 便利だからつい……
  - つまり独自ドメイン必須

今回いれたやつ

Termux

JuiceSSHなどが有名らしいんだが、使って見ると見た目はモダンだけど逆にわかりづらかった。Termuxのほうがターミナル民にとっては親しみやすいのではないかと思うがどうか。無料だし。

ただ、マルチユーザでやると、Termuxはプライマリユーザでないと使えないという制約があった……。

LAN内での接続

まずLAN内でやる準備。ホストマシン側は既に受け入れ準備できているものとする。

Androidの設定

まずTermuxをインストール。そしたら鍵認証の準備。pkgはaptのラッパーらしい。

pkg install openssh
ssh-keygen -t ed25519  # 鍵ペア生成 rsa でも別に

なんらかの手段でホストマシンに鍵を送る。自分はAndroidストレージへのアクセスを許可をして、鍵をコピーし、さらにDropbox経由で転送するというよくわからない手順をした。

termux-setup-storage  # Androidストレージへアクセス許可
# 公開鍵をMacに転送して設定

あとお好みでtmuxなど入れておくと良い。

pkg install tmux
pkg install emacs

ホストマシン

authorized_keysに公開鍵を追加する。

再びAndroid

ログイン実験。

ssh hogetaro@ホストマシンのIP

入れたらOK。

インターネットからの接続

LANがOKなら次はいよいよネットから。

Cloudflare Tunnel

例によってZero Trustから、ホストマシンのポート22に向けて送る設定をする。

ホストマシン

cloudflaredも入れて、受け入れ準備できているものとする、といったものの、一応鍵認証のみ、パスワード認証を受け付けない、程度のことは確認しておく。

Android

pkg install cloudflared

SSH over HTTPSとなるので、以下のように設定する。

# ~/.ssh/config に設定
Host 独自ドメイン
 ProxyCommand cloudflared access ssh --hostname %h
 User ユーザ名

そしたら以下で入れるかを確認する。

ssh 独自ドメイン

入れたらOK。

所感、課題など

とりあえずこれでターミナルライフを送れるようになる。そしてLenovo Yoga Tab PlusのPCモードはなかなか便利であるため、けっこう快適……に思うのだが、やはり日本語入力変換という壁が立ちはだかる。日本語使わなければいいという豪の者もいるかもしれないが、普通にClaude Codeに日本語で相談しているんでさすがに。ファイル名日本語のものだってあるわけなのだし。

また、僕の場合はHHKB US配列という制約があるため、キーの数は少ないしでなかなか苦戦している。Braveでは日本語入力できるのだが、どういうわけかtmuxではできない……操作が競合している可能性とかあるかもしれない（Ctrl + Spaceで切り替えだったので）。このへんまだ調査が必要だけれど、とりあえず別途かなぁ。

なんかもうMacBook買えばよいのではないか？という気持ちになりつつも、今あるものは使わないとの精神。

[itemlink post_id=“17028”]

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でメルマガでもやったろうか。誰も登録しない。

最後にいつものクーポン広告だが、以下のリンクです。

お友達紹介

こっから飛んで使い始めてもらったら1000円分のクーポンがもらえる（このとも～友達紹介～｜レンタルサーバーならConoHa）。そして定常的に使ったら僕に2000円分のクーポンが入る。クーポンが入るとなんか色々遊んで適当にレビューするかもしれない。

レンサバの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ってインターネットの根幹なんだなと思った。インターネットは脆いよ。

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に恨みはないけれど、クラウド、サブスクはもう嫌だっていう気持ちのほうが強い。僕自身はこの流れから脱せられているわけではないけれど、せめてプライベートではまず離れたいところだね。

レンサバから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/

WPFormsでGmailのフリーアドレス経由で独自ドメインをfromにしてメール送信する

Fri, 02 Aug 2024 14:31:05 +0900

なんかすごい長ったらしいけど、要は受信専用で使っていた独自ドメインのメールアドレスについて、WPFormsのSMTP機能でメール送信したくなり、Gmailのエイリアス機能を使って、Gmailアカウント経由でぶっ飛ばす、ということ。昨今の事情を考えるといつまで使えるのかわからないんだけれど、少なくとも今は使えるみたいなのでメモ。

前提

独自ドメインで、メール受信としてCloudflareのEメールルーティング→Gmailに飛ばしている。受信専用ならこれでいいやと思っていたが、WordPressの投稿フォームプラグイン、WPFormsを使って、Fromを独自ドメインのメールアドレスとなるように、メールを送信したい。フツーなら、投稿フォーム用のメールアドレスでSMTP認証で送信したらいいわけだが、受信専用なのでそうもいかない。

ということで、Gmailのフリーアドレスのアカウントを経由して飛ばす。以下のような感じ。

graph LR
sender(WPForms)
gmail(gmail.com)
receiver(フォーム投稿者)
sender --> gmail
gmail -->|hoge.comとして内容確認メール送る| receiver

やり方

基本的には、gmail.comのアドレスを使って、独自ドメインのメールアドレスで送信するやり方を、WPFormsに適用する、という方法になる。そのやり方については下記の記事が非常に参考になりました。

Cloudflare とGmail で独自ドメインのメールを無料で送受信する方法【Cloudflare Email Routing】 #cloudflare - Qiita

詳細は記事に参照として、送信側の設定としては、下記の操作をする。

Gmailのアカウントでアプリパスワードを設定する(既に非推奨だがキニシナイ)
Gmailにアドレスを追加する

設定の「すべての設定を表示」
「アカウントとインポート」タブ
「他のメールアドレスを追加」
独自ドメインのメールアドレス + エイリアスとして扱いますにチェック
SMTPサーバの設定
- SMTPサーバ: smtp.gmail.com
- ユーザ名: ログインアカウントのメールアドレス
- パスワード: アプリパスワード

この設定後、同じようにSMTPを使ったメール送信をすると、追加した独自ドメインのメールアドレスで送信できることが確認できる。

WPFormsにおいても、SMTP認証を使って、上記のSMTPサーバの設定をすることで、送信することが確認できた。しかしながら、設定画面でSPF/DMARCの設定できてないよとWarningがでる。でるが今は送れるので、いったんよしとする。

注意

メーラのSMTP設定でも同様にすることで、メールクライアントからメール飛ばすことも可能。しかし昨今の情勢を考えると、永続的に使えるとは思わないほうがよさそう。

アプリパスワードがdeprecated扱いでいつなくなってもおかしくない
DKIM/SPF/DMARC周りが厳しくなっている昨今、いつまでもちゃんと届くか不安

なのでまぁ、一時的な措置としては本記事の内容でも良いと思うが、今後もずっと安定してSMTP使ってメール送りたいなら、やっぱりまぁちゃんとしておいたほうが安全かなぁと思う。さすがに自分でメールサーバたてる気合いは普通ないことを考えると、ConoHaのメールサーバを借りたり、あるいはZoho Mailあたり使うほうが良いかな。

あわせて読みたい

格安メールを求めて、Zohomailを使い始めてみる

/zohomail/

Amazon SES + Cloudflare Email Routing + Gmailで安上がりな独自ドメインのメール送受信

Fri, 17 May 2024 19:01:27 +0900

Webサービスとかやると、ドメインごとにメールの送受信どうするかな問題が生じる。これの構成は無数に考えられるので、何が最適解かは状況によるだろうが、とりあえず「始めたばかりだしとにかく安上がりでさらっと済ませたい」という要求をかなえるため、送信はAmazon SES、受信はCloudflareのEmail Routing + Gmail(個人用)という構成を組んだ。今のところは問題なさげに動いている。

前提として、ドメインはCloudflareで管理する。

（追記 2024-05-19）この構成だと設定した独自ドメイン同士のメールでエラーが発生した。設定次第でなおせるんだろうか……

全体の構成

全体の構成を図示しておく。

「自分」と「誰かさん」の間でメールを送受信する。送信経路を実線、受信経路を破線とする。

graph TD
jibun(自分)
dareka(誰かさん)
ses(Amazon SES)
jibun -->|送信: SMTP| ses --> recv --> dareka
ses ---|情報登録| dns
recv ---|参照する| dns
cf(Cloudflare)
gmail(Gmail)
dareka -.-> cf -.->|Email Routing| gmail -.->|受信| jibun

普通にメールサービス使えばいいじゃないか説は有力というかそうすべきなんだろうなぁと思いつつ、そうは言ってもメールサービスは固定費もそこそこかかるし、システム的なメール配信まで考えるとAmazon SESは使えておきたいと思った。SES部分はResendとかでもいい。というかResendで似たようなことをやっている人がいた。

Cloudflare + Gmail + Resendで無料法人メールアドレスを作る

構成一緒だね。皆考えることは同じなのか……。

受信経路

まず先に受信から始める。構成部分は以下。

graph TD
jibun(自分)
dareka(誰かさん)
cf(Cloudflare)
gmail(Gmail)
dareka -.-> cf -.->|Email Routing| gmail -.->|受信| jibun

これはCloudflareのEmail RoutingとGmailを利用する。まぁつまり、CloudflareのEmail Routingの機能でメールをGmailに飛ばすというものだ。機能については公式ページは以下。

Email Routing | アドレス作成とメール転送が簡単に | Cloudflare

無料で使える。よい。

Gmailについては転送先のアドレスとして使えれば良いので別にGmailでなくても良い。良いのだが、メールサービスによってはうまくいかない可能性もあるだろう（送信のところでこれについては触れる）。

さて、この受信についてはやることはあまり多くない。Cloudflareのダッシュボードでドメインを選択し、Email Routingを始め、アドレスと転送先のアドレスを指定するだけでよい。簡単過ぎてビビる。

送信経路

送信のほうは受信と違ってやや手間がかかる。メール送信については運用する側も考えることが多い。

DKIM/SPF/DMARCを知る

具体的にはDKIM/SPF/DMARCの仕組みを定性的に理解していなくてはいけない。これについては下記に記事を書いたので詳細については参考にされたい。

/dkim-spf-dmarc ややこしい

ざっくり言うと、DKIMはメールが改竄されてないことを保証する仕組み、SPFは送信者が信頼できることを保証する仕組み、DMARCはDKIMとSPFをどれくらい厳格に適用し、NGだったらどう対応するのかとかを標準化したポリシーである。で、このためには送信側と受信側の両方できっちり対応している必要がある。

先の受信経路のところで、Gmailじゃなくてもいいけどちゃんと動くかはわからん、と書いたのは、メールサービスがどれくらいちゃんと対応しているかわからんからだ。今回のように転送が入るとややこしくなると思うので、サービスによってはどうなるかわからん。またGmailを使っていても送信側次第では転送落ちるとかありそうな気もする。わからん。怖い。怖いけどとりあえず今のところは使えている。

SESの設定

さて、以上を踏まえたうえで、送信経路について改めて見てみよう。

graph TD
jibun(自分)
dareka(誰かさん)
ses(Amazon SES)
recv(受信側のサーバ)
dns(DNSサーバ)
jibun -->|送信: SMTP| ses --> recv --> dareka
ses -.->|情報登録| dns
recv -.->|参照する| dns

ポイントはDNSサーバである。DNSサーバに情報登録とあるが、これは何かと言うと、先に述べたDKIM/SPF/DMARCの対応である。DKIM/SPF/DMARCに必要な情報はDNSのレコードに登録するのである。登録する情報の意味については先にあげた記事を参照。

実務的には、SESに「これ登録しろ」と言われるまま、Cloudflareのダッシュボードよりレコード登録をすればいい。具体的な操作は、どうせいつか変わる操作よりも、多少面倒でもDKIM/SPF/DMARCはなんなのかをちゃんと理解するのが一番の近道だと思う。理解すれば何をどうすればいいかはわかる。

SESではDKIM対応がドメイン検証も兼ねているようだ。送信元の登録はSPF対応である。また、DMARCについても書かれているのをそのまま使えばいい。一点注意として、MXレコードの数字は優先順位である（まぁそのまんま値に入れようとしたら怒られるので察しはつくと思うが）。

登録できれば、とりあえずまずAPIで送信確認するとよい。メーラ使うにはSMTPの設定が必要なので、まずAPIで送信確認するほうが楽。SESは最初サンドボックス環境だが、サンドボックスでは認証したメールアドレスしか使えないことに注意。なので、先に受信側の対応をしたわけだ。

なおメールのサンプルコードは以下（By ChatGPT）。

import boto3
from botocore.exceptions import ClientError

# SESクライアントの作成
ses_client = boto3.client('ses', region_name='ap-northeast-1') # ご使用のリージョンに合わせて変更してください

# メールのパラメータ
sender = "sender@example.com" # 送信者のメールアドレス
recipient = "recipient@example.com" # 受信者のメールアドレス
subject = "Hello from Amazon SES"
body_text = "Hello,\r\nThis is a test email sent by Amazon SES using Boto3."

try:
 # Send Email
 response = ses_client.send_email(
 Source=sender,
 Destination={'ToAddresses': [recipient]},
 Message={
 'Subject': {'Data': subject},
 'Body': {'Text': {'Data': body_text}}
 }
 )
 print("Email sent! Message ID:", response['MessageId'])
except ClientError as e:
 print("An error occurred:", e.response['Error']['Message'])

boto3をインストールしているPCなら、送受信のメールアドレスだけ変えればそのまんま使える。こういうサンプルコード一瞬で出力してくれるだけでも有り難い。

送信できたら、次はSMTPで送れるかを確認する。SESのコンソールにSMTP設定があるのでそこから言われるままにやる……だとアレなんだが、俺たちのクラスメソッドさんに良い記事があるのでそれを参考にどうぞ。

Amazon SES に SMTP認証設定を追加してメールクライアントから SMTPサーバとして利用してみた | DevelopersIO

設定方法はメーラによる。SMTPサーバのみ設定したアカウントを作成する必要があり（受信側がエラー出る）、やや特殊な設定となる。とりあえずMacの標準メールアプリでは設定できた。OutlookはPOPとかでやろうとしてもサインインできないと言われて登録できなかった。あんまり本意気でOutlook使ってないのでわからんが、イマドキのOutlookだとできないのかもしれない。Thunderbirdはできるんじゃないかな多分。

運用

書くほどでもないが。

注意点として、SMTPのパスワード再発行はできない。したがって、パスワード紛失時はユーザの作り直しになる（つまり削除と登録）。

登録

Cloudflare

転送先の宛先の追加
Routingで宛先に送るアカウントの追加

SMTP認証情報の追加（IAMユーザができる）

削除

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みたいなリッチなサーバもほしくなるが、このへんはクラウドでやると余裕で破産できるので、オンプレミスにも価値が出てきた。

そんなわけで、自宅サーバもアリなんじゃないかと思うようになってきた今日この頃である。

参考記事

ありがとうございました。