タグ: Linux Page 1 of 41

Growiを7.5.7→8.0.0へアップデートしたときの作業メモ

概要

筆者にとっての必須エディタ、Growi。そのv8.0.0が出たので、以下の要件に基づきアップデートを行いました。

リリース情報

実施日: 2026年7月29日
対象環境: Ubuntu 24.04 (非Docker環境 / systemd運用)
その他要件:

itemversion
OSUbuntu 24.04
GROWI7.5.7
node.js24.14.1
npm11.13.0
pnpm11.1.1

必要要件の確認

GROWIの最新リリースにおける変更点(ES7の完全廃止、jemalloc対応、メモリ最適化、ESM移行)に対する自環境の適合状況を確認。

Elasticsearchバージョン確認

ES8/ES9のみに対応しているため、以下を確認。

curl -X GET "http://localhost:9200/" |grep number

9.4.4となっていたので、要件を満たすことは確認しました。

OSメモリ最適化モジュールの確認

ldconfig -p | grep jemalloc

libjemalloc.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/libjemalloc.so.2と出たのでモジュールも確認済みです。

ここまでやれば、覚悟を決めてアップデートを行います。

さっくりとしているが面倒な手順

  1. Growi実行スクリプトの修正を行います。
  2. 修正結果が反映されたことを確認します。
  3. 関連サービスの停止を行います。
  4. (推奨)mongodbをまるごとバックアップしておきます。
  5. Growiのアップデートを行います。
  6. アップデートの確認を行います。

Growi実行スクリプトの修正

※筆者は

systemdに登録したサービス起動プログラムがGrowiのルートディレクトリ/home/www-data/growi配下にあるgrowi-start.shを参照して各種環境をキックしています。

※ご自身の環境に合わせ修正を行ってください※

  • 修正前ファイル
#!/bin/bash

# nvmのdefaultエイリアスが指すディレクトリを動的に取得してPATHに追加
# これにより、nvm installでバージョンを上げてもこのスクリプトの書き換えが不要になります
DEFAULT_NODE_VER=$(cat "$NVM_DIR/alias/default")
export PATH="$NVM_DIR/versions/node/$DEFAULT_NODE_VER/bin:$PATH"
GROWI_DIR="/home/www-data/growi"

cd $GROWI_DIR

# 環境変数の設定
export NODE_ENV=production
export AUDIT_LOG_ENABLED=true
export FORCE_WIKI_MODE=private
export MONGO_URI=mongodb://localhost:27017/growi
export ELASTICSEARCH_URI=http://localhost:9200/growi
export REDIS_URI=redis://localhost:6379
export PASSWORD_SEED=(設定済みのパスワード)

# npm run app:server を使用する(npmが内部で正しいパスを見つけてくれます)
# execを使うことでsystemdとの親和性を維持します
exec npm run app:server

このファイルを修正していきますが:バックアップを確実に行います。

  • ファイルバックアップ
sudo cp -pi /home/www-data/growi/growi-start.sh /path/to/backup/directory/growi-start.sh.$(date +%Y%m%d)
  • ファイルバックアップ確認
diff -u /path/to/backup/directory/growi-start.sh.$(date +%Y%m%d) /home/www-data/growi/growi-start.sh

エラー(差分)がなければ両者ともファイルがあり、バックアップが取れています。

バックアップ後、/home/www-data/growi/growi-start.shの編集を行います。(自分の環境に合わせます)

主な変更内容
  • JEMALLOC の有効化: export JEMALLOC_ENABLED=true を追加
  • LD_PRELOAD の明示: export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 を追加
  • MongoDB 接続プールの最適化: MONGO_URI?maxPoolSize=10 パラメータを付与

具体的には以下のような差分が取れていればOKです。

diff -u /path/to/backup/directory/growi-start.sh.$(date +%Y%m%d) /home/www-data/growi/growi-start.sh
# 環境変数の設定
 export NODE_ENV=production
+export JEMALLOC_ENABLED=true
+export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
 export AUDIT_LOG_ENABLED=true
 export FORCE_WIKI_MODE=private
-export MONGO_URI=mongodb://localhost:27017/growi
+export MONGO_URI=mongodb://localhost:27017/growi?maxPoolSize=10
 export ELASTICSEARCH_URI=http://localhost:9200/growi
 export REDIS_URI=redis://localhost:6379

設定ファイルの修正確認

  • Growiサービスの再起動
sudo systemctl restart growi.service

指定した環境変数および jemalloc ライブラリが GROWI プロセス(Node.js)へ正常にロードされていることを確認しました。

  • プロセスの環境変数確認:
    JEMALLOC_ENABLED=true および LD_PRELOAD が正常に適用されていることを確認。
  • メモリマップ / ファイルハンドラ確認:
    lsof および /proc/{PID}/maps コマンドにより、libjemalloc.so.2 が Node.js プロセスに読み込まれていることを確認。

メンテナンスモード有効化

  1. Growiに管理者権限でログインします。
  2. 管理トップ>アプリ設定に進み、「メンテナンスモードを開始する」をクリックします。
  3. トップページに戻り「メンテナンスモード」が表示されていることを確認します。

バックアップ

以下をバックアップします。

  • mongodbの格納データ
cat /etc/mongod.conf |grep dbPath

として、ここのディレクトリ一式を控えます。(筆者環境 /home/mongodb)

このディレクトリを任意の方法でバックアップします。

  • Growiの添付ファイル一式が納められているディレクトリ(ファイルアップロード先をlocalにしている場合のみ)
/growi/root/directory/apps/app/public

(筆者環境 /home/www-data/growi/apps/app/public)ここも念のためバックアップします。

※ 添付ファイルのアップロード先をAWSやAzureなどにしている場合は不要です

  • vpsや仮想ゲストの場合はシステム全体:推奨

スナップショット機能などでシステム全体をバックアップした方が確実で安心です。

ElasticsearchとGrowiの停止

  • Elasticsearchサービス停止
sudo systemctl stop elasticsearch.service
  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status elasticsearch.service growi.service | grep Active

inactive(dead)を確認します。

作業前バックアップ

  • データディレクトリを丸ごとコピー (-aオプションでパーミッションを維持)
sudo cp -a /var/lib/elasticsearch/ /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)

自分の環境に合わせます。

  • バックアップ確認
sudo ls -l /path/to/backup/dir/elastic_bk.$(date +%Y%m%d)

バックアップした内容があることを確認します。(※管理者権限でないとこのディレクトリを見ることはできません)

growiディレクトリに移動します

cd /home/www-data/growi && pwd

自分の環境に合わせます。(筆者環境/home/www-data/growi)

リリースタグを確認します。

  • リリースタグ取得
sudo git fetch --tags
  • リリースタグ確認
sudo git tag -l

スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。

チェックアウトとインストールを行います。

  • 変更を一時的に退避
sudo git stash
  • チェックアウト
sudo git checkout 【バージョン】

リリースタグは再確認しましょう。今回は 2026/07/28にリリースされたv8.0.0を選択しました。

  • pnpm install
sudo pnpm i

※これができるのは、筆者のgrowi実行環境がrootだからです。このパーミッション設定は確実に確認しましょう。

  • ビルド
NODE_OPTIONS="--max-old-space-size=4096" sudo pnpm run app:build

→ ビルド時のメモリ大量使用を抑えるため上限を抑えています。余談ですが、ここは神に祈る作業です。

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス開始確認
systemctl status elasticsearch.service growi.service | grep Active

active(running)を確認します。

メンテナンスモード無効化

  1. Growiに管理者権限でログインします。
  2. 管理トップ>アプリ設定に進み、「メンテナンスモードを終了する」をクリックします。
  3. トップページに戻り「メンテナンスモード」が表示されていないことを確認します。

バージョンアップを確認します。

  1. 画面下部にあるバージョンがチェックアウトしたバージョン(v8.0.0)であることを確認します。
  2. 各種機能(ページ閲覧や編集)などが正常に行えるかを確認します。

追加モジュールが動いていることを確認します。

  • 一時的に特権ユーザー昇格

※一般権限で見られないため

sudo su -
  • モジュール追加確認
 pgrep -f "node.*growi" | xargs -I {} lsof -p {} 2>/dev/null | grep jemalloc
  • 実行例
MainThrea 479521 root  mem       REG  253,1    830656    15385 /usr/lib/x86_64-linux-gnu/libjemalloc.so.2

バージョンアップ後の作業

必要に応じてバックアップしたファイル一式やスナップショットを削除します。

ネットワーク設定移行作業ログ(Wi-Fiから有線LANへの固定IP引き継ぎ)

設定の後始末

中古のLet's noteを「試しにNextcloudのフロントエンドやDNS(AdGuard Home)」にしていたものの、いよいよもって本格的に稼働させることにします。

ネットワーク環境の確認情報

  • 対象機器:
    • Ubuntu 26.04 Desktopノート
  • 有線LAN (NIC)
    • : enp0sxx(NetworkManager接続名: netplan-enp0s31f6
  • 無線LAN (Wi-Fi)
    • : wlp1s0(NetworkManager接続名: Wi-Fi
  • デフォルトゲートウェイ:
    • 192.168.x.1
  • サブネットマスク:
    • /24 (255.255.255.0)

問題と解決

直面した問題

デスクトップ画面で有線LANと無線LANを同時に切り替えようとしたのですが、
無線側がまだ 引き継ぎたいIPアドレスを掴んでいたため、有線側で同じIPを有効化しようとした際にアドレスの重複・競合が発生し、以下のエラーで有効化に失敗しました。

エラー: 接続のアクティベーションに失敗: IP 設定を確保できませんでした (利用可能なアドレスがない、タイムアウトなど)

これに対処していきます。ここからはターミナルやSSH接続です。

解決策

  1. 無線接続を先にダウンさせ、旧IPアドレスを解放します。
  2. 無線のIPv4設定を自動(DHCP)に変更・初期化する。
  3. 有線LAN側に静的IP(192.168.11.16)とゲートウェイ・DNSを設定する。
  4. 有線LAN接続を有効化する。

実行した復旧手順(コマンド)

SSH切断による作業中断を防ぐため、以下のコマンドを一括で実行しました。

sudo nmcli connection down "Wi-Fi" && \
sudo nmcli connection modify "Wi-Fi" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns "" && \
sudo nmcli connection modify "netplan-enp0s31f6" ipv4.method manual ipv4.addresses 192.168.x.x/24 ipv4.gateway 192.168.x.1 ipv4.dns "192.168.x.1" && \
sudo nmcli connection up "netplan-enp0s31f6"

それぞれのステップで何が起きているのか、順番に詳しく解説します。

Step 1: 無線LANの切断

sudo nmcli connection down "Wi-Fi"
  • やっていること:
    • 現在有効になっているWi-Fi接続(Wi-Fi)を即座に無効化(切断)します。
  • 目的:
    • これから有線側に設定しようとしているIPアドレス(192.168.x.x)をWi-Fi側から完全に解放し、IPアドレスの重複(衝突)を防ぐために行っています。

Step 2: 無線LAN設定の初期化 (DHCP化)

sudo nmcli connection modify "Wi-Fi" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
  • やっていること:
    • Wi-Fi接続の設定情報を変更します。
  • ipv4.method auto:
    • IPアドレスの取得方法を「自動(DHCP)」に変更
  • ipv4.addresses "":
    • 以前割り当てていた固定IPアドレスの登録を削除
  • ipv4.gateway "":
    • 設定されていたゲートウェイ情報を削除
  • ipv4.dns "":
    • 設定されていたDNSサーバー情報を削除
  • 目的: 今後Wi-Fiを単体で使うことがあっても、固定IPではなく自動でIPを取得(DHCP)するように設定をリセットしています。

Step 3: 有線LANへの固定IP・ネットワーク情報の設定

sudo nmcli connection modify "netplan-enp0s31f6" ipv4.method manual ipv4.addresses 192.168.x.x/24 ipv4.gateway 192.168.x.1 ipv4.dns "192.168.x.1"
  • やっていること: 有線LAN(netplan-enp0s31f6)に新しいネットワーク情報を書き込みます。
  • ipv4.method manual: IP設定を「手動(固定IP)」に変更
  • ipv4.addresses 192.168.x.x/24: サーバー用の固定IPアドレスとサブネットマスクをセット
  • ipv4.gateway 192.168.x.1: デフォルトゲートウェイ(ルーター)を指定
  • ipv4.dns "192.168.x.1": 名前解決用のDNSサーバー(ルーター)を指定
  • 目的: サーバー機能(NextcloudやAdGuard等)を引き継ぐための固定IP環境を有線側に割り当てます。

Step 4: 有線LANの有効化(新設定の反映)

sudo nmcli connection up "netplan-enp0s31f6"
  • やっていること:
    • Step 3で書き換えた設定を使って、有線LAN接続を起動(アクティベート)します。
  • 目的:
    • 設定を反映させて通信を開始します。この瞬間に有線側のIPアドレスが 192.168.x.x に変更されるため、旧IPで繋がっていたSSH接続はここで途切れ、新しいIPでの接続が解禁されます。

なぜこれを「1行(ワンライナー)」でやったのか?

SSH接続中にネットワーク設定を変更すると、Wi-Fiを切断した時点(Step 1)でターミナルの操作ができなくなってしまいます。

命令を && で繋いで1行で送信しておくことで、SSHが切れてしまってもUbuntu内部でStep 4まで自動的に突っ走って完了させてくれるという技術的な工夫(SSH切断対策)でした。

最終確認結果

  1. IPアドレス・インターフェース状態の確認 (ip a)
  • 有線 (enp0s31f6): inet 192.168.x.x/24 (正常に固定IP割り当て完了)
  • 無線 (wlp1s0): state DOWN (競合解消)
  1. 疎通確認
  • 有線LANのIP宛て(192.168.x.x)へのSSH再接続: 成功
  • 外向き通信テスト (ping -c 3 google.com): 成功

なんとなくで設定していた宿題に取り組むことが出来ました。

BookStackのヘッダーロゴを高解像度化する

BookStackでは「アプリケーションロゴ」を設定できますが、そのままではアップロードした画像が高さ86pxへリサイズされてしまいます。

そのため、CSSでロゴを大きく表示すると画像がぼやけてしまいます。そもそも86pxは昨今のモダンなCMSにあるまじき解像度ではあるので、手を入れます。

そこでファイル本体を少し修正し、高解像度のロゴ画像をそのまま利用できるようにしました。

環境

  • BookStack
    • v26.05.1
  • Apache
    • 2.4
  • PHP
    • 8.3-fpm
  • Ubuntu
    • 24.04

最初に試したこと

BookStackに管理者権限でログインし、管理>カスタマイズに遷移。

カスタムheadタグで

<style>
.logo-image {
    height: 128px !important;
    width: auto !important;
}
</style>

のような指定はできるものの、超ローレぞ加工され、表示がぼやけます。そこで、要素を調べると、保存された画像自体が86×86になっていました。

この原因を調べます。

調査

インストールされているUbuntuサーバで

cd /path/to/BookStack/directory && pwd

として(筆者環境/home/www-data/Bookstack)BookStackのホームディレクトリに移動。

file public/uploads/images/system/20xx-xx/xxxx.jpg

で、該当のファイルを調べます。

JPEG image data
86x86

つまり、CSSではなくアップロード時に画像が縮小されていました。

分かった原因

いかにCSSで指定してもだめな原因はプログラムそのものにあります。なので、その上流の「ファイルのアップロードを司るファイル」にメスを入れます。

それを司るファイルをチャットAIとともに調査。

BookStackのルートディレクトリからたどれる

app/Settings/AppSettingsStore.php

にそれがありました。

protected function updateAppLogo(Request $request): void
{
    if ($request->hasFile('app_logo')) {
        $logoFile = $request->file('app_logo');
        $this->destroyExistingSettingImage('app-logo');

        $image = $this->imageRepo->saveNew(
            $logoFile,
            'system',
            0,
            null,
            86
        );

        setting()->put('app-logo', $image->url);
    }
}
null,
86

が指定されているため、高さ86pxへリサイズされた画像が保存されます。

ここまで分かれば、後は修正開始です。

さっくりとした手順

  1. サーバ上で該当するファイルを修正します。
  2. 念のためサービスの再起動を行います。
  3. カスタムheadタグを修正します。
  4. 改めてファイルをアップロードします。

ファイルのバックアップ

  • BookStackのルートディレクトリに移動
cd /path/to/BookStack/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/Bookstack)

  • 該当ファイルのバックアップ
sudo cp -pi app/Settings/AppSettingsStore.php /path/to/backup/AppSettingsStore.php.$(date +%Y%m%d)

※注意点※

  • プログラム根幹をいじります。つまり、何かあったら直したやつの責任です。バックアップは確実に取ります。
  • 更に、Gitなどでアップデートした場合、確実にこれはMasterから上書きされます。「ここを直す」というのは履歴管理を厳に行いましょう。
  • 該当ファイルのバックアップ確認
diff -u /path/to/backup/AppSettingsStore.php.$(date +%Y%m%d) app/Settings/AppSettingsStore.php 

任意のバックアップディレクトリを指定します。

エラーがないことを確認します。人間「バックアップはやってる」と思いながらもバイアスや手なりでスキップしがちです。この段階でそのミスやバイアスを潰します。

なぜdiffを使うのかは、ls -lで両ファイルを比べるより確実だからと言うのと、後述する修正確認でも使うからです。

該当ファイルの修正

app/Settings/AppSettingsStore.phpファイルを、リサイズを行わないよう変更します。(要管理者権限)

具体的には以下の差分になるように。

- $image = $this->imageRepo->saveNew($logoFile, 'system', 0, null, 86);
+ $image = $this->imageRepo->saveNew($logoFile, 'system', 0, null, null);
  • 修正後のバックアップ確認
diff -u /path/to/backup/AppSettingsStore.php.$(date +%Y%m%d) app/Settings/AppSettingsStore.php 

ここで、なぜdiffを逆にする意味が生まれます。逆にしないと直したところが-、元が+で表示されます。これは視覚的にも感覚的にもよろしくありません。「え? 正しい修正をしたのに消されるの?」となりがちです。

設定反映

sudo -u www-data php artisan optimize:clear

でキャッシュをクリアします。

(推奨)PHP/Apacheを再起動

PHP-FPMなら

sudo systemctl restart php8.3-fpm

Mod-PHP環境なら

sudo systemctl restart apache2

で、実行環境を再起動します。

改めてカスタムヘッダの調整

BookStackに管理者権限でログインし、管理>カスタマイズに遷移。

カスタムheadタグで

<style>
.logo-image {
    height: 128px !important;
    width: auto !important;
}
</style>

のように設定し、(或いは設定されていることを確認し)、保存をクリック。

要してあるロゴをアップロード

管理>カスタマイズ

から、ファイルをアップロードします。

  • ロゴをさらに大きく表示したい場合

BookStack標準ではヘッダー高さが少し窮屈なので、必要に応じてヘッダーも調整します。

header {
    min-height: 72px;
}

.logo-image {
    height: 64px !important;
}

設定反映確認

ここから先はBookStackに戻り、高解像度でロゴが表示されれば設定はOKです。

設定ファイルの所属元を探すコマンド

Ubuntuサーバ設定時、時々迷ってしまう

「どのファイルがどのパッケージに属しているか?」

問題。その道しるべになり得るコマンドのメモです。

先に言ってしまえば

dpkg -S コマンドを使うのが一番手っ取り早くて確実です。apt パッケージ管理システムの実体は、バックエンドで dpkg を使っているため、このコマンドがそのまま使えます。

基本的な使い方は以下の通りです。

dpkg -S /パス/to/ファイル名

具体的な使い方とテクニック

1. 基本:絶対パスで指定する

調べたいファイルの絶対パスがわかっている場合は、そのまま指定します。

dpkg -S /etc/logrotate.d/apache2

出力例:

apache2: /etc/logrotate.d/apache2

コロン(:)の左側に表示されている apache2 がパッケージ名です。

2. 応用:ファイル名だけで検索する

絶対パスが思い出せない場合は、ファイル名の一部だけでも検索できます。

dpkg -S logrotate.d/apache2

注意点: ファイル名だけで検索すると、その文字列にマッチするすべてのパッケージとファイルパスが一覧で出力されます。そのため、できるだけ具体的なパスを指定した方がノイズが少なくなります。

3. まだインストールしていないファイルの場合

「まだシステムに入れていないけれど、/etc/xxxx という設定ファイルを入れるには、どのパッケージをインストールすればいいか?」を知りたい場合は、apt-file というツールが便利です。

まずツールをインストールしてデータベースを更新します。(筆者の好みでaptitudeを用いています)

sudo aptitude install apt-file

コマンドインストール後、DBをアップデート。

sudo apt-file update

その後、以下のように検索します。

apt-file search /etc/logrotate.d/apache2

これを使えば、手元の環境にないファイルでも、どのパッケージに含まれているかを一発で特定できます。

なんかの都合で設定ファイルの名前を変えてしまったときに役立ちます。(やらかしました)

Linuxエディタ「nano早見表」

論争があるのは知っていますが、それでも、これを紹介する理由があります。

「複数行の選択を可能に出来た」

という今更ながらの感動があったので。

ファイル操作

操作キー
保存Ctrl + O
Enterで保存確定Enter
終了Ctrl + X

カーソル移動

操作キー
上・下・左・右矢印キー
行頭へ移動Ctrl + A
行末へ移動Ctrl + E
1ページ上Ctrl + Y
1ページ下Ctrl + V

検索・置換

操作キー
検索Ctrl + W
次を検索Alt + W
置換Ctrl + \

コピー・切り取り・貼り付け

1行だけ操作

操作キー
行を切り取り(削除)Ctrl + K
貼り付けCtrl + U

複数行を操作

  1. 選択開始位置へ移動
  2. EscA(または Ctrl + ^)でマーク開始
  3. カーソルを移動して範囲選択
  4. 以下を実行
操作キー
選択範囲を切り取り(削除)Ctrl + K
選択範囲をコピーAlt + 6
貼り付けCtrl + U

Undo / Redo

操作キー
元に戻すAlt + U
やり直しAlt + E

その他便利なコマンド

操作キー
ヘルプCtrl + G
カーソル位置表示Ctrl + C
指定行へジャンプCtrl + _
コマンド一覧表示Ctrl + G

Linux端末でよく使うキー

^ = Ctrl

M- = Alt(Metaキー)

Altキーが効かない端末では、

Esc を押して離し、その後キーを押す

例:

  • EscA = Alt + A
  • EscU = Alt + U
  • Esc6 = Alt + 6

よく使う操作の流れ

複数行を削除

Esc → A
↓で範囲選択
Ctrl + K

複数行をコピー

Esc → A
↓で範囲選択
Alt + 6
Ctrl + U

検索・置換

Ctrl + W
検索文字入力
Enter

Ctrl + \
検索文字
Enter
置換文字
Enter

教材価値の高いログ:なぜ攻撃者は最初にWordPressを探すのか

筆者に限らず、Webサーバを運用すると必ずと言っていいほど見かけるアクセスがあります。

GET /wp-login.php
GET /wp-admin/
GET /wp-config.php
GET /config.php
GET /.env

言わずと知れたWordpress/laravel管理画面のURLやDB情報などが飛び交う重要ファイル。

「うちはWordPressじゃないんだけど?」

と思う人も多いでしょう。実際、筆者のVPSもWordPressを詰んでいません。(公開しているWordpressは専用サービスを借りています)

それでも毎日のように飛んできます。では、攻撃者は何を考えて「見たらアクセスするのが礼儀」レベルでアクセスしてきているのでしょうか。

インターネットは「総当たり」の世界

多くの人は、「誰かが自分のサイトを狙っている」と考えがちです。

しかし実際には逆です。攻撃者は運営元をまず見ません。彼らが見ているのは

「世界中に存在する何千万台ものWebサーバ」

です。ですから

WordPress
Laravel
Node.js
Next.js
Joomla
Drupal

といった利用者が非常に多い技術から順番に試します。

WordPressが最優先になる理由

WordPressは世界中のWebサイトのかなりの割合を占めています。つまり、攻撃者は

「WordPressだけ狙う」

だけでも膨大な成果が期待できます。さらに

  • 古いプラグイン
  • 更新されていないテーマ
  • 初期設定のままの管理画面

なども珍しくありません。攻撃者から見ると、WordPressは「狙う価値が非常に高い標的」です。

そして、Wordpressは

/wp-config.php
/wp-config-sample.php
/wp-login.php

など、「アキレス腱となるファイル」がほぼ決まっているという「やりやすい」材料です。

実際のログ

以下は実際に筆者のサーバへ届いたログを、IPアドレスやホスト名をダミー化したものです。

なぜ、この手の攻撃者情報を晒さないかというと「テロリストに名前を与える必要はない」という哲学と、「誰がやったかは問題ではない。私が興味があるのは何をしたかである」という考えです。

[Mon Jul 06 01:06:34.509624 2026] [security2:error] [pid 111111:tid 222222222222222] [client 192.0.2.1:40372] [client 192.0.2.1] ModSecurity: Warning. Matched phrase "config.php" at REQUEST_FILENAME. [file "/usr/share/modsecurity-crs/coreruleset/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "150"] [id "930130"] [msg "Restricted File Access Attempt"] [data "Matched Data: config.php found within REQUEST_FILENAME: /config.php"] [severity "CRITICAL"] [ver "OWASP_CRS/4.28.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/ATTACK-LFI"] [tag "capec/1000/255/153/126"] [hostname "example.com"] [uri "/config.php"] [unique_id "DUMMY_UNIQUE_ID_000001AAAAA"]
[Mon Jul 06 01:06:34.510601 2026] [security2:error] [pid 111111:tid 222222222222222] [client 192.0.2.1:40372] [client 192.0.2.1] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:blocking_inbound_anomaly_score. [file "/usr/share/modsecurity-crs/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "233"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [ver "OWASP_CRS/4.28.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"] [hostname "example.com"] [uri "/config.php"] [unique_id "DUMMY_UNIQUE_ID_000001AAAAA"]
[Mon Jul 06 01:06:34.511256 2026] [security2:error] [pid 111111:tid 222222222222222] [client 192.0.2.1:40372] [client 192.0.2.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-980-CORRELATION.conf"] [line "119"] [id "980170"] [msg "Anomaly Scores: (Inbound Scores: blocking=5, detection=5, per_pl=5-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0, RFI=0, LFI=5, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=5)"] [ver "OWASP_CRS/4.28.0"] [tag "reporting"] [tag "OWASP_CRS"] [hostname "example.com"] [uri "/__jailhouse_lock/topgear.html"] [unique_id "DUMMY_UNIQUE_ID_000001AAAAA"]
[Mon Jul 06 01:06:40.426322 2026] [security2:error] [pid 333333:tid 444444444444444] [client 192.0.2.1:35882] [client 192.0.2.1] ModSecurity: Warning. Matched phrase "wp-config-" at REQUEST_FILENAME. [file "/usr/share/modsecurity-crs/coreruleset/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "150"] [id "930130"] [msg "Restricted File Access Attempt"] [data "Matched Data: wp-config- found within REQUEST_FILENAME: /wp-config-sample.php"] [severity "CRITICAL"] [ver "OWASP_CRS/4.28.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/ATTACK-LFI"] [tag "capec/1000/255/153/126"] [hostname "example.com"] [uri "/wp-config-sample.php"] [unique_id "DUMMY_UNIQUE_ID_000002BBBBB"]
[Mon Jul 06 01:06:40.427672 2026] [security2:error] [pid 333333:tid 444444444444444] [client 192.0.2.1:35882] [client 192.0.2.1] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:blocking_inbound_anomaly_score. [file "/usr/share/modsecurity-crs/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "233"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [ver "OWASP_CRS/4.28.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"] [hostname "example.com"] [uri "/wp-config-sample.php"] [unique_id "DUMMY_UNIQUE_ID_000002BBBBB"]
[Mon Jul 06 01:06:40.428290 2026] [security2:error] [pid 333333:tid 444444444444444] [client 192.0.2.1:35882] [client 192.0.2.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-980-CORRELATION.conf"] [line "119"] [id "980170"] [msg "Anomaly Scores: (Inbound Scores: blocking=5, detection=5, per_pl=5-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0, RFI=0, LFI=5, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=5)"] [ver "OWASP_CRS/4.28.0"] [tag "reporting"] [tag "OWASP_CRS"] [hostname "example.com"] [uri "/__jailhouse_lock/topgear.html"] [unique_id "DUMMY_UNIQUE_ID_000002BBBBB"]

要約するとこんな形です。

[client 192.0.2.1]
GET /config.php

REQUEST-930
Restricted File Access Attempt

↓

REQUEST-949
Inbound Anomaly Score Exceeded

↓

HTTP 403

数秒後、

GET /wp-config-sample.php

REQUEST-930
Restricted File Access Attempt

↓

REQUEST-949
Inbound Anomaly Score Exceeded

↓

HTTP 403

となりました。

このログから読み取れること

筆者がこのログに着目したのは

config.php
↓

wp-config-sample.php

という順番です。これは、

  1. 「PHPかな?」
  2. 「WordPressかな?」

という判定ルーチンそのもの。人間ならこの順番にはなりません。典型的な自動スキャナです。

さらに注目したい点

以前紹介した、ModSecurityのカスタム設定。

HostヘッダーがIPアドレスなら遮断

Hostヘッダーが存在しなければ遮断

というカスタムルール。今回は一切反応しませんでした。

つまり攻撃者は

  • DNSで名前解決
  • 正しいHostヘッダーを付与
  • 普通のHTTPリクエスト

を組み立てています。IPアドレスへ適当に投げるだけのBOTより一段階上です。

そのためにModSecurityは通常の検査を実施し、

REQUEST-930
↓
REQUEST-949
↓
403

という流れで処理しています。

筆者が「教材」と述べた面白い理由

このログには、

OWASP CRSの典型的な動きがそのまま残っています。

CRS:930
危険なリクエストを検知
↓
CRS:949
異常スコアが閾値を超えた
↓
処理:403アクセス拒否

つまり、「ModSecurityがどのように判断して遮断するのか」を学ぶ教材として非常に分かりやすいログです。

そして一番重要なこと

今回の攻撃は、筆者個人を狙ったものではありません。世界中のWordPressサイトを探す途中で、たまたま筆者のLAMPサーバへ届いただけです。(何せ、動いているのは全く別のCMSです)

しかし、その「たまたま」からでも学べることはたくさんあります。

ログには、

  • 攻撃者が何を探しているのか
  • どんな順番で調べるのか
  • WAFがどこで判断したのか

がすべて残っています。

サーバ管理者にとってログは「嫌なもの」ではなく、攻撃者の思考を無料で教えてくれる教材です。

Jailhouse Lockシステム技術スタック解説:mod_rewriteによるクローラー誘導作戦。

こちらの記事では、最速のナイフであるmod_aliasと、強力な拳銃であるmod_rewriteの特徴、そして「速度と役割のトレードオフ」についてお話ししました。

ここからは、筆者が実際に運用している atelier.reisalin.com の設定ファイルを元に、この2つの武器をどのように組み合わせ、悪意あるボットや過剰なクローラーを迎撃しているのか。その具体的な防衛システム、名付けて「Jailhouse Lock(ジェイルハウスロック)」の核となるmod_rewriteモジュールについてお話しします。

mod_rewriteとは?

mod_rewriteは、リクエストされたURLをファイルシステム上の特定の場所にマッピング(転送・代替)したり、別のURLへリダイレクトしたりするための、Apacheの拡張モジュールです。(そのため、多くのディストリビューションではインストールと同時に機能が有効化されていないことが多数あります。)

Ubuntu系であれば

sudo a2enmod rewrite
sudo systemctl restart apache2.service

で有効化されます。

再掲:mod_alias との違い

どちらも「URLを操作する」という意味では同じですが、そのアプローチと内部処理の複雑さに大きな違いがあります。

項目mod_aliasmod_rewrite
コンセプト単純なマッピングとリダイレクト強力なURLカスタマイズと書き換え
判定基準単純な前方一致(接頭辞マッチ)正規表現、Cookie、環境変数、時間など
処理速度非常に高速(軽量)やや低速(ルール毎に正規表現エンジンが動く)
設定の難易度簡単(初心者向け)複雑(記述ミスで無限ループが起きやすい)
主な用途フォルダの共通化、単純なサイト引っ越し綺麗に整形されたURL(Smart URL)の実現、複雑な条件分岐

最大の違い:正規表現と条件分岐の有無

mod_aliasは、URLの「先頭が一致しているか」という単純な比較しか行いません。

一方、mod_rewriteは「リクエストがGoogle Chromeから来たら」「平日の昼間なら」「Cookieに特定の文字が含まれていたら」といった、高度な条件分岐(RewriteCond)や、正規表現を使った自由自在なURLの作り替え(RewriteRule)が可能です。

筆者の設定内容抜粋

まずは、実際に稼働している設定の抜粋をご覧ください。

<VirtualHost *:80>
    ServerName atelier.reisalin.com
    RewriteEngine On
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName atelier.reisalin.com

    # ----- ログの選別と抑制 -----
    SetEnvIf Remote_Addr "192.0.2.1" dontlog
    SetEnvIfNoCase User-Agent "Googlebot" dontlog
    SetEnvIfNoCase User-Agent "GoogleOther" dontlog

    # ModSecurity等、WAFで捕獲したエラーはログを肥大化させない
    SetEnvIf MSC_RULE_ID "4009" dontlog
    CustomLog /var/log/apache2/atelier_access.log combined env=!dontlog

    DocumentRoot /home/www-data/atelier/public

    # --------------------------------------------------
    # 第一層:【mod_alias】によるハニーポットへの一撃転送
    # --------------------------------------------------
    <IfModule mod_alias.c>
        # 監獄(Jailhouse)となる隔離ディレクトリを定義
        Alias /__jailhouse_lock /home/www-data/nepenthes

        # 存在しないはずの脆弱性パスへのアクセスを最速でトラップへ
        Alias /wp-login.php   /home/www-data/nepenthes/login.html
        Alias /wp-admin       /home/www-data/nepenthes/login.html
        Alias /.git           /home/www-data/nepenthes/git.html
        Alias /assets-archive /home/www-data/nepenthes/login.html

        <Directory /home/www-data/nepenthes>
            Options -Indexes
            AllowOverride None
            Require all granted
        </Directory>
    </IfModule>

    # --------------------------------------------------
    # 第二層:【mod_rewrite】による動的・精密迎撃
    # --------------------------------------------------
    <Directory /home/www-data/atelier/public>
        Options -MultiViews
        AllowOverride All
        Require all granted

        <IfModule mod_rewrite.c>
            RewriteEngine On

            # 【迎撃フェーズ1】悪質botフラグが立っている通信の隔離
            RewriteCond %{ENV:bad_bot} =1
            RewriteCond %{REQUEST_URI} !^/__jailhouse_lock/
            RewriteRule ^.*$ /__jailhouse_lock/topgear.html [L,E=dontlog:1]

            # 【迎撃フェーズ2】特定の重いコンテンツを狙った過剰クローラー対策
            SetEnvIf Request_URI "^/projects/zettel" is_zettel

            # 大量のカンマ区切り(%2C)や、極端に長い(150文字以上)悪意あるクエリを検知
            SetEnvIf Query_String "tag=.*(%2[cC]|,|%e3%80%81).*(%2[cC]|,|%e3%80%81).*(%2[cC]|,|%e3%80%81)" bad_tag_stacking
            SetEnvIf Query_String "tag=.{150,}" bad_tag_stacking

            # 特定ページ、かつ異常クエリというパズルが揃った瞬間に500エラーで即撃破
            RewriteCond %{ENV:is_zettel} 1
            RewriteCond %{ENV:bad_tag_stacking} 1
            RewriteRule ^ - [E=dontlog:1,R=500,L]
        </IfModule>
    </Directory>
</VirtualHost>

防衛ストーリー:ナイフで受け流し、拳銃で仕留める

この「Jailhouse Lock」システムは、先の記事で述べたmod_alias(ナイフ)とmod_rewrite(拳銃)の特性をコンビネーションとして昇華させたものです。

この言葉は大好きなので何度でも再掲しますが:『MASTERキートン』のプロフェッサーの言葉。

「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
 だが、拳銃はデリケートな道具だ。
 弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
 その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」

これはナイフの方が有利という単純な比較論ではなく、

「この距離ではナイフが有用」だが、「ある程度のアクションや破壊力が必要な場合は拳銃が必要なるケース」というお話と筆者は捉えています。

第一層(mod_alias):無差別スキャンを「無駄なく」いなす

サイトがWordPressで作られていようがいまいが、botは機械的に /wp-login.php/.git を探して叩いてきます。これらはURLの文字列そのものが標的であるため、複雑な条件分岐は不要です。

ここで登場するのがナイフの速度を持つ mod_alias です。

        # 監獄(Jailhouse)となる隔離ディレクトリを定義
        Alias /__jailhouse_lock /home/www-data/nepenthes

        # 存在しないはずの脆弱性パスへのアクセスを最速でトラップへ
        Alias /wp-login.php   /home/www-data/nepenthes/login.html
        Alias /wp-admin       /home/www-data/nepenthes/login.html

この部分。ボット、クローラー、悪意ある攻撃者が挨拶代わりに上記のサイトへのURLに一致した瞬間に、メインアプリケーション(PHPなど)を一切起動させることなく、最速でハニーポット(ダミーのHTML空間 nepenthes)へと受け流します。サーバーのリソースを1ミリも無駄にしない、ナイフならではの「一動作(ワンアクション)」の防御です。

第二層(mod_rewrite):パズルを解き明かし「精密に」射抜く

しかし、中には特定のコンテンツ(例:負荷の重い検索機能など)に対して、URLの引数(クエリ)を巧妙に変えながら何度もクロールしてくる、たちの悪いボットがいます。

URLの文字しか見られない mod_alias では、URLの後ろに付く ?tag=xxx の中身まで検知することはできません。ここで拳銃である mod_rewrite を引き抜きます。

RewriteCond %{ENV:is_zettel} 1
RewriteCond %{ENV:bad_tag_stacking} 1
RewriteRule ^ - [E=dontlog:1,R=500,L]

「特定のコンテンツへのアクセスである(is_zettel)」
「かつ、タグの指定が異常に長い、または大量に詰め込まれている(bad_tag_stacking)」

この複数の条件が上から順にカチリと噛み合った瞬間、mod_rewrite は狙い違わず [R=500,L] という弾丸を放ち、リクエストを強制終了させます。同時に [E=dontlog:1] フラグを立てることで、ボットの嫌がらせによる「ログファイルの肥大化(ディスク容量の圧迫)」という二次災害まで綺麗に防いでみせるのです。

なぜ nginx ではなく、Apache なのか?

近代的なWebサーバーとしてnginxが台頭する中、なぜ筆者がApacheを用いる理由は以下の通り。

Apacheの持つ「上から下に流れる手続き型の思考」が、このような防衛ロジックを組む際に圧倒的に人間にとって直感的だからです。

もし、これと同じ「AかつBの条件を満たした時だけ、500エラーで弾いてログを消す」という処理をnginxで実装しようとすると、事情が変わってきます。nginxには条件を連鎖させる RewriteCond のような仕組みがなく、また if 文の挙動が非常にデリケート(通称:If is Evil)であるため、以下のような不格好な「変数ハック」を強いられます。

例えば、これと同等の機能をnginxでやろうとすると

# nginxで複数の動的条件を重ねる場合の苦肉の策
set $block_trigger "";
if ($is_zettel) { set $block_trigger "Y"; }
if ($bad_tag_stacking) { set $block_trigger "${block_trigger}Y"; }
if ($block_trigger = "YY") {
    return 500;
}

かなりifの入れ子構造が面倒になります。それに対し、Apacheは「この条件を満たし、さらにこの条件も満たしたら、このルールを適用して終了!」と、設計思想をそのまま設定にぶち込む強みがあります。

結び:適材適所の美学

強力な道具は、それ単体で振り回しても真価を発揮しません。

  • 固定の攻撃パスは、システムに最も負荷をかけない mod_alias で門前払いする。
  • 動的なパラメータや環境変数が絡む高度な迎撃は、mod_rewrite の柔軟性を活かしてピンポイントで処理する。

速度のナイフと、射程の拳銃。

この2つのモジュールを「適切なコンテキスト」で併用することで、設定ファイルそのものである程度の防御は出来るというお話です。

余談ではありますが:mod_rewriteは強力ですが、設定を一行誤れば自分自身が500エラーの被害者になります。

「『いい鉄砲は打ち手を選ぶ』ってことわざ知ってるか?
威力のある鉄砲は その分扱いも難しく危険
だから未熟者が使うと打ち手の方がケガをするってことさ」

という『ONE OUTS』で渡久地が言った言葉を持って、本記事を締めくくります。

BookStackにMermaid Viewerを導入する手順

ある種悲願でもあった、「BookStackにmermaid.jsを描画させる」が叶いました。

環境

  • BookStack v26.05.1
  • Apache 2.4
    • 実行ユーザーはwww-data
  • PHP-FPM 8.3
  • MySQL 8
  • Ubuntu 24.04

さっくりとした手順

  1. BookStackのルートディレクトリに移動します。
  2. Mermaid Viewerモジュールをインストールします。
  3. .envの編集をします(ハマった点)
  4. 設定を反映させます。
  5. 動作の確認を行います。

BookStackのルートディレクトリへ移動

cd /home/www-data/BookStack

筆者環境です。お使いの環境に応じてパスは変更してください

Mermaid Viewerモジュールをインストール

sudo -u www-data php artisan bookstack:install-module https://www.bookstackapp.com/hack-modules/mermaid-viewer.zip

途中で

Are you sure you trust this source?

と聞かれるのでyesで返答します。テーマが無い場合は

No active theme folder found...

と表示されるので同様にyesで返答します。

すると

themes/custom/

ディレクトリが作成され、

themes/custom/modules/mermaid-viewer/

ディレクトリへモジュールがインストールされます。

.env にテーマを設定(重要)

ここが今回ハマったポイントです。

.env を編集します。(要管理者/bookstack実行ユーザー権限)

APP_THEME=custom

を追加します。

これを設定しないと、themes/custom以下のディレクトリはは一切読み込まれません。


設定反映

php artisan optimize:clear

または

php artisan cache:clear
php artisan config:clear
php artisan view:clear

でキャッシュをクリアします。

(推奨)PHP/Apacheを再起動

PHP-FPMなら

sudo systemctl restart php8.3-fpm

Mod-PHP環境なら

sudo systemctl restart apache2

で、実行環境を再起動します。

設定反映確認

BookStackにログインして、設定反映されていることを確認します。

エディタの形式をMarkdownなら

```mermaid
flowchart TD
    A --> B
    B --> C
```
flowchart TD A --> B B --> C

保存後、閲覧画面でMermaid図としてレンダリングされます。

※ 編集画面の右ペインには表示されないのでご注意ください。

補足

インストール後のディレクトリは概ね以下のようになります。

BookStack/
└── themes/
    └── custom/
        └── modules/
            └── mermaid-viewer/

今回のポイント

実は一番重要なのはこのメッセージでした。

You will need to set APP_THEME=custom in your BookStack env configuration to enable this theme!

初回インストール時に表示されるのですが、見落としやすい一文です。

筆者も最初は「インストールは成功しているのに表示されない」という状況から別の原因を疑いましたが、このメッセージと APP_THEME の未設定を確認したことで、原因を特定できました。

Apacheモジュール「mod_alias」解説。

筆者がWebサイトの防衛に、そして過剰にクロールをするボットを他の場所へとご案内するために用いているmod_aliasのご紹介です。

というのも、筆者がこれから述べる対クローラー迎撃システム「Jailhouse Lock」には、このモジュールが必要だからです。

1. mod_aliasとは何か?

mod_aliasは、リクエストされたURLをファイルシステム上の特定の場所にマッピング(転送・代替)したり、別のURLへリダイレクトしたりするための、Apacheの標準モジュールです。(そのため、多くのディストリビューションではインストールと同時に機能が有効化されています)

主な役割は以下の2つです。

  • エイリアス(別名)の設定:
    • ドキュメントルート(公開ディレクトリ)の外側にあるフォルダを、あたかも内側にあるかのようにURLに紐付けます。
  • 単純なリダイレクト:
    • 特定のURLに来たアクセスを、別のURL(別ドメインなど)へ転送します。

代表的なディレクティブ

  • Alias /images /var/www/shared/images (URLの/imagesを特定のフォルダに対応付ける)
  • Redirect permanent /old.html http://example.com/new.html (永続的な301リダイレクト)

2. mod_rewrite との違い

どちらも「URLを操作する」という意味では同じですが、そのアプローチと内部処理の複雑さに大きな違いがあります。

項目mod_aliasmod_rewrite
コンセプト単純なマッピングとリダイレクト強力なURLカスタマイズと書き換え
判定基準単純な前方一致(接頭辞マッチ)正規表現、Cookie、環境変数、時間など
処理速度非常に高速(軽量)やや低速(ルール毎に正規表現エンジンが動く)
設定の難易度簡単(初心者向け)複雑(記述ミスで無限ループが起きやすい)
主な用途フォルダの共通化、単純なサイト引っ越し綺麗に整形されたURL(Smart URL)の実現、複雑な条件分岐

最大の違い:正規表現と条件分岐の有無

mod_aliasは、URLの「先頭が一致しているか」という単純な比較しか行いません。

一方、mod_rewriteは「リクエストがGoogle Chromeから来たら」「平日の昼間なら」「Cookieに特定の文字が含まれていたら」といった、高度な条件分岐(RewriteCond)や、正規表現を使った自由自在なURLの作り替え(RewriteRule)が可能です。

3. mod_aliasが「優れているパターン」

「mod_rewriteがあれば、mod_aliasはいらないのでは?」と思われがちですが、Apache公式も「単純なタスクであれば、mod_rewriteではなくmod_aliasを使うべき」と推奨しています。

mod_aliasを選ぶべき(優れている)具体的なパターンは以下の3つです。

① サーバーのパフォーマンス(速度)を最優先したいとき

mod_rewriteは、リクエストが来るたびに複雑な正規表現エンジンを動かすため、CPUリソースを消費します。

大規模サイトやアクセスが集中する環境で、単なるURLの転送やフォルダの紐付けを行う場合、mod_aliasの方が圧倒的に処理が軽く、サーバーの負荷を抑えられます。

② ドメイン全体の引っ越しや、単純なURL変更(リダイレクト)

サイトのリニューアルで、古いページから新しいページへ1対1で転送したい場合や、古いドメインから新ドメインへ丸ごと転送したい場合は、mod_aliasの Redirect で十分対応できます。

  • サイト全体を新ドメインへリダイレクト(mod_alias)
Redirect permanent / https://new-example.com/

これをmod_rewriteで書くと記述が複雑になり、設定ミスのリスク(無限ループなど)が高まります。

③ 複数サイトで画像やアセット用のフォルダを安全に共有したいとき

例えば、サーバー内の /var/www/common_assets/ というフォルダを、複数のWebサイトで /assets というURLで共通利用したい場合です。

  • 安全かつ高速に共通フォルダをマッピング(mod_alias)
Alias /assets /var/www/common_assets

mod_aliasは設定がシンプルなため、ヒューマンエラーによるセキュリティホールの発生(意図しないシステムファイルの公開など)を防ぎやすいというメリットもあります。

それぞれのイメージ

1. mod_alias のシーケンス(単純・高速)

URLの書き換えは行わず、リクエストされたURLの先頭(接頭辞)だけをチェックして、即座にファイルパスへマッピングするか、リダイレクトを返すシンプルな流れです。

sequenceDiagram autonumber participant Client as クライアント (ブラウザ) participant Core as Apache コア (リクエスト受付) participant Alias as mod_alias participant FS as ファイルシステム Client->>Core: HTTPリクエスト (例: /images/logo.png) Core->>Alias: URLの評価を依頼 Note over Alias: URLの先頭(接頭辞)が<br>設定と一致するか単純比較 Alias-->>Core: マッピング先を返却<br>(例: /var/www/shared/images/logo.png) Core->>FS: 指定されたパスのファイルを読み込み FS-->>Core: ファイルデータ Core-->>Client: HTTP 200 OK (レスポンス返却)

2. mod_rewrite のシーケンス(複雑・高機能)

リクエスト受付後、内部でループ(再エントリー)が発生する可能性や、条件判定(RewriteCond)のステップが挟まるため、柔軟ですが処理の工程が多くなります。

sequenceDiagram autonumber participant Client as クライアント (ブラウザ) participant Core as Apache コア (リクエスト受付) participant Rewrite as mod_rewrite participant FS as ファイルシステム Client->>Core: HTTPリクエスト (例: /user/profile) rect rgb(240, 245, 255) Note over Core, Rewrite: [書き換えループの開始] Core->>Rewrite: URLの評価を依頼 Note over Rewrite: 1. 正規表現でURLパターンをマッチング Note over Rewrite: 2. RewriteCondの条件をチェック<br>(Cookie、ブラウザ、環境変数など) Rewrite->>Rewrite: 3. URLの書き換え処理を実行<br>(例: /index.php?mod=user&act=profile) Rewrite-->>Core: 書き換え後の内部URLを返却 end Core->>Core: 内部リダイレクト(新しいURLで再処理) Core->>FS: 最終的なスクリプトやファイルを呼び出し FS-->>Core: 実行結果・データ Core-->>Client: HTTP 200 OK (レスポンス返却)
  • mod_alias(図1):
    • 判定が「前方一致のみ」の一方通行であるため、ステップ数が少なく、非常に高速に処理が終わります。
  • mod_rewrite(図2):
    • 条件チェックのフェーズ(薄い青枠の部分)が多く、さらに書き換えたURLでApache内部で「もう一度リクエストを処理し直す(内部リダイレクト)」という挙動が発生するため、機能性と引き換えに処理が重くなる構造が見て取れます。

まとめ:使い分けの基準

それぞれの使い分けです。

  1. まずは mod_alias で実現できないか考える。(単なる転送、単なるフォルダの紐付けなど)
  2. 「クエリストリング(?id=123など)を判定したい」「特定のブラウザだけ除外したい」「正規表現でURLを激しく書き換えたい」といった複雑な要件が出てきたとき初めて mod_rewrite を導入する。

どちらが優れているか、否かという問題ではなく、これは速度の問題です。

漫画『MASTERキートン』に以下のやりとりがあります。

「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
 だが、拳銃はデリケートな道具だ。
 弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
 その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」

これは「至近距離でのナイフの有用性」を示したものであり、実際にその通りだという説得力があるものです。(調査結果はこの記事です

つまり、mod_alias は「できることが少ないから速い」のではなく、「役割を絞っているから速い」のです。

mod_aliasはナイフの速度。mod_rewriteは拳銃のような強力さがあります。「適切な距離感」でこれらのツールの利用、併用を行いましょうというお話しです。

自宅サーバーに導入したAdGuard Homeを家庭内ルーターに適用する手順とハマったところ。

前回の設定で、AdGuard Homeの常時SSL化とリバースプロキシ環境が整いました。今回は、AdGuardを「自分の部屋のネットワーク全体」に適用していく手順をまとめます。

設定時のハマりどころと失敗談も含めています。

宅内環境

前提として:

家族に迷惑をかけずに自宅サーバーとクライアントをいじるため、私の環境では以下のような二重ルーター構成(インナーネットワーク)を取っています。

[ONU] ──> [家族用メインルーター] ──> [スイッチ]
                                          │
    ┌─────────────────────────────────────┘
    ▼(ここからが自分の環境)
[自室内ルーター] ──(DHCPでAdGuardのIPを配布)──> [自室内端末群]
     │
     └─> [Ubuntuサーバー(DNSを兼ねたAdGuard Home稼働)]

この構成であれば、万が一自分の部屋の設定をトチっても、家族のネット環境には1ミリも影響を与えません。

自室内ルーターの設定手順

この、自室環境のスマホやPCが自動的にAdGuard Home(例: 192.168.1.6)を向くように、ルーターの設定を変更します。

1. ルーターの管理画面を開く

ブラウザに自室内ルーターのIPアドレス(192.168.1.1 など)を入力し、ログインします。

2. LAN側(DHCPサーバー)の設定画面を開く

「詳細設定」や「LAN設定」の中にある 「DHCPサーバー設定」 の項目を探します。

【注意】ここで絶対にやってはいけない罠

ルーターの「WAN側(インターネット接続設定)」のDNSを変更してはいけません。ここを変えると、ルーター自体の挙動がおかしくなることがあります。変更するのは必ず 「LAN側」 です。

3. 配布するDNSサーバーのIPアドレスを固定する

通常は「ルーターのIPアドレスを通知する」になっている部分を、手動設定(カスタム)に変更します。

  • プライマリDNS(DNSサーバー1): 192.168.1.6 (UbuntuサーバーのIP)
  • セカンダリDNS(DNSサーバー2): あえて空欄(またはプライマリと同じIP)

セカンダリDNSのジレンマ

「AdGuardが死んだら困るから」とセカンダリDNSに外のDNS(8.8.8.8 など)を入れておきたくなりますが、これにはジレンマがあります。

OSや端末によっては、プライマリが生きているにもかかわらず、気まぐれにセカンダリのDNSばかりを使って通信を行う仕様があります。ここに外のDNSを書くと、広告ブロックをすり抜けてしまう端末が多発します。

AdGuardによって広告を100%仕留めるなら「空欄」か「AdGuardのIP一本足打法」にするのが鉄則です。

4. クライアント(端末)側での設定

ルーターの設定を変更(またはサーバーを物理復旧)した後は、スマホやPCに新しいDNS情報を強制的に覚え込ませる必要があります。

  • マホ(iPhone / Android)の場合
    • 一度Wi-Fiを「オフ」にしてから再度「オン」にするか、機内モードのON/OFFを行ってください。
  • PC(Windows)の場合
    • コマンドプロンプトを開き、いつものおまじないを実行してDNSキャッシュを完全に吹き飛ばします。
ipconfig /flushdns
ipconfig /renew

DNSを兼ねたことによる自爆

設定が完了し、問題なく運用できていたのに、突然「ローカルNWには繋がっているのに、なぜかインターネットに一切繋がらない」という謎の障害が発生しました。

原因を探ったところ、信じられないほど単純で致命的な物理トラップでした。

サーバーにしていたノートPCの電源アダプターが、いつの間にか外れてバッテリー切れで電源断発生。

先述の通り、広告のすり抜けを防ぐためにルーターのセカンダリDNSは空欄(またはAdGuardのIPのみ)にしています。そのため、サーバー(ノートPC)の電源が落ちてAdGuardもろともサービスダウンすると、部屋の中のスマホやPCは「DNS不在」状態になります。

「通信(ローカル回線)はアクティブなのに、Webサイトの名前解決が一切できないため、結果としてインターネットに完全に繋がらなくなる」というワンミス即死を喰らいました。

対策と教訓

  • ノートPCをサーバーにする場合は、ACアダプターが容易に抜けない位置に配置すること。(電源管理は企業では鉄則ですが家庭はそのあたりが甘かったです)
  • また、上述した家族用のNWから切り離していたことが幸いしました。でなければ、突然ネット閲覧ができなくなる、スマートTVでネトフリやYouTubeに繋がらなくなる事態が発生したでしょう。

「間違えても自分だけが泣けばいい」環境を持っておくのは改めて幸いでした。

Page 1 of 41

Powered by WordPress & Theme by Anders Norén