投稿者: manualmaton Page 1 of 281

Zram運用後のメモリ量の推移

昨日運用を開始したzram。その効果を実感できる「単体テスト」にぶち当たりました。

  • 必要に応じて動かし
  • アップデートでメモリを恐ろしく消費する

Growiのアップデートです。

zram導入・運用環境 メモリ推移比較

項目1. 導入直後2. Growiアップデート後3. Growi起動中(安定時)
物理メモリ(使用/Total)2.78 / 5.78 GiB(高負荷)2.9 / 5.8 GiB
物理メモリ(空き/可用)0.42 GiB (Free)-2.9 GiB (Available)
zram展開サイズ (DATA)-1.4 GiB927.6 MiB
zram実占有 (TOTAL)-333.6 MiB258.1 MiB
圧縮率 (zstd)-約4.3倍約5.5倍
ディスクスワップ使用量0.02 GiB0 B0 B
主な状態初期クリーン状態ビルド等のメモリ最大消費時安定稼働・メモリ余裕あり

数値から見る運用の要諦

  • 導入直後はFreeが0.42GiBと心許ない数値でしたが、安定稼働時にはAvailableが2.9GiBまで回復しており、OSが自由に使える「机の広さ」が広くなっています。
  • Growiアップデートという最大の難所においても、Disk Swapを0Bに抑え込めたことが、システム全体のレスポンス維持に直結しています。
  • 安定稼働時に圧縮率が5.5倍まで向上しているのは、メモリ内の重複データやテキストデータが効率よく整理されているzstdの底力を見ました。

ここからのまとめ

「取り敢えず私のサーバには合っている」という形。他、気がついた事項は随時フィードバックしていきます。

UbuntuサーバにZramを導入したときの記録。

概要

筆者が運用しているWebサーバ。興味が向くまま様々なWebアプリを入れているため、メモリが心許ない事態が発生します。
単にスワップを増やすのではなく、Linuxの物理メモリ(RAM)の上に圧縮された専用領域(ブロックデバイス)を作成する、zramを導入します。

  • 通常の構造: RAM <---> Disk (HDD/SSD)
  • zram導入後: RAM [ 通常領域 | zram(圧縮領域) ] <---> Disk

環境

  • Ubuntu 24.04

メモリ環境

free -b | awk '
/Mem:/ {
  mem_total=$2/1024/1024/1024;
  mem_used=$3/1024/1024/1024;
  mem_free=$4/1024/1024/1024;
}
/Swap:/ {
  swap_total=$2/1024/1024/1024;
  swap_used=$3/1024/1024/1024;
  swap_free=$4/1024/1024/1024;
}
END {
  printf "| 項目 | 値 |\n| --- | --- |\n";
  printf "| Mem Total | %.2f GiB |\n", mem_total;
  printf "| Mem Used | %.2f GiB |\n", mem_used;
  printf "| Mem Free | %.2f GiB |\n", mem_free;
  printf "| Swap Total | %.2f GiB |\n", swap_total;
  printf "| Swap Used | %.2f GiB |\n", swap_used;
  printf "| Swap Free | %.2f GiB |\n", swap_free;
}'
項目
Mem Total5.78 GiB
Mem Used2.78 GiB
Mem Free0.42 GiB
Swap Total2.00 GiB
Swap Used0.02 GiB
Swap Free1.98 GiB

Caution! 導入の前に

これは万能薬ではありません。

メモリ上にブロックデバイスを作成しますが、その分、マシンパワーを喰います。

元々のメモリ量が少なければ効果を発揮しません。

例えば1GB未満のWebサーバでの運用は厳に慎むべきです。

破壊的アップデートを伴います。

「スワップをいじることのヤバさ」が知らない方は、この先の文章は読まないでください。(正直、DDoS喰らった時以上に神経を使う作業でした)

フェイズ・ゼロ(政治交渉)の必要性-再掲-

このvpsを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • メモリが心許ない。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、サーバそのものの再起動を伴う

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

当然、設定の大幅変更に関わるので設計書や運用のドキュメント化も待っています。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

さっくりとした手順

以下、フェイズ・ゼロをクリアした(必要ない)方向けです。

  1. カーネルモジュールを追加インストールします。
  2. zramをインストールします。
  3. zramの設定を行います。
  4. zramを有効化します。
  5. zramの内容を確認します。

※筆者の好みでaptitudeを用いています。必要に応じてaptに読み替えてください。

強く推奨:イメージ全体のバックアップ

仮想サーバ、vps等で運用している場合は、イメージ全体をバックアップ(スナップショット)などとしておき、何かあったときにすぐに戻せるようにします。

カーネルモジュールの追加インストール

これが地味にハマりました。

sudo apt install linux-modules-extra-$(uname -r)

これを入れていないと「現在のカーネルにzramモジュールが存在しない、あるいはロードできない」事態が発生します。(発生しました)

zramインストール

sudo aptitude install zram-tools

と、コマンド一発で済む作業です。しかし、コマンド一発で済む作業であるからこそ、チューニングは細心の注意が必要です。

zramの設定

  • 設定ファイルのバックアップ
sudo cp -pi /etc/default/zramswap /path/to/backup/zramswap.$(date +%Y%m%d)
  • 設定ファイルのバックアップ確認
diff -u /path/to/backup/zramswap.$(date +%Y%m%d) /etc/default/zramswap

エラーがなければOKです。diffを逆にしているのは、この後で説明します。

  • ファイルの修正

/etc/default/zramswapを以下のように修正します。自身の環境に合わせます

# 圧縮アルゴリズムの指定
ALGO=zstd
# 物理メモリの半分ほどを指定します
PERCENTAGE=50
# 念のため、ディスクサイズも指定します
SIZE=2048
# 既存スワップ(通常の-2)より高く設定します
PRIORITY=100
  • ファイルの修正確認
diff -u /path/to/backup/zramswap.$(date +%Y%m%d) /etc/default/zramswap
 #ALGO=lz4
+ALGO=zstd

 # Specifies the amount of RAM that should be used for zram
 # based on a percentage the total amount of available memory
 # This takes precedence and overrides SIZE below
 #PERCENT=50
+PERCENTAGE=50

 # Specifies a static amount of RAM that should be used for
 # the ZRAM devices, this is in MiB
 #SIZE=256
+SIZE=2048

 # Specifies the priority for the swap devices, see swapon(2)
 # for more details. Higher number = higher priority
 # This should probably be higher than hdd/ssd swaps.
 #PRIORITY=100
+PRIORITY=100

等と表示されればOKです。そして、ここで、先ほど示したdiffのsrcとdstを逆にした理由です。

  • 逆にする(バックアップからの差分)とすることで
    • 「何を足したか(つまり、現時点での正」が明白になります。
  • 逆にしないと
    • 正しい設定が「引かれている」状態となり、視覚的に危険な状態になります。

zramの有効化

  • zram再起動
sudo systemctl restart zramswap

`

※筆者がハマったのはここです。ここでエラーが発生してカーネルモジュールをインストールする手戻りが発生しました。

  • zramサービス確認
systemctl status zramswap.service 

active(exited)を確認します。(これは、apache/mysqlなどの常駐型サービスと異なり「カーネルにロードしてしまえば後はOK」という状態のためexitedとなっています。

サーバ再起動

sudo reboot

行います。再起動に慎重を要する(クラスタリングなど)はその手順に従ってください。

ここで再起動しない事態が発生したら?

「さぱっと死せい 黄泉路の先陣じゃ 誉れじゃ」

ぐらいの潔さを持ちましょう。(持てなければそもそも筆者はサーバ運用をしていません

潔さがない方のためのイメージ全体のバックアップであり、スナップショットなので。

zramの有効化確認

swapon --show
NAME       TYPE      SIZE USED PRIO
/swapfile  file        2G   0B   -2
/dev/zram0 partition   2G   0B  100

/dev/zram0がリストにあれば、カーネルがスワップとして認識中です。

zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd            2G   4K   59B   20K       4 [SWAP]

で、数字がカウントされればOKです。

WindowsノートのCopilotキーをスクリーンショットに置き換え。

昨今のノートPCに強制的についてくるCopilotキー。

これが不便なので別のものに切り替えます。

試行1:失敗

設定 > Bluetoothとデバイス > キーボード

ショートカットとホットキー

ここで、「キーボードのCopilotキーをカスタマイズする」を行ったところで、選べるものが

  • Copilot
  • Copilot365

しか選べない状況でした。

試行2:成功

そこで試したのはMicrosoft PowerToysです。

これをストアでインストール。インストール後、

Keyboard Managerを選択。

これを有効化後、「ショートカットの再マップ」をクリックします。

ここで選ぶのは、ショートカット(左側)

  • Win (Left)
  • Shit (Left)
  • F23

という、Copilotのショートカット。

割当先を

PrintScreenに変更。

変更後、OKをクリックすることで、Copilotキーがスクリーンショットと、役立つ機能へのショートカットになりました。

ノートPCの装飾。

新調したノートPC、ThinkPad P14s Gen 6 (AMD)。

こちらを、例によってデコレーションしました。

天板

無軌道に貼るのではなく、視線誘導を意識。特に「浮遊せよ(Wingardium Leviosa)」を文字通り浮遊させる位置に置いたのは会心のできです。

パームレスト

こちらは好きな花と推し色で区別。CPUロゴやThinkPadロゴに重ならないように貼り付けました。

追加で

のぞき見防止フィルタも設置。マグネット着脱式ではなかったので、マステで貼り付け。この方が張り直しも用意で飾れるのでより気に入っています。

ポテサラのバリエーション。

こちらのバリエーションが2つほど。

1.カレー風味

なんとなく買ったものの、使い道がなかった(追加の材料が面倒だった)ため持て余していたドライカレーの素。

これを合わせたものがこちら。カレー粉という万能調味料が見事に合わさりました。

2.バターとハム

いつもはツナ缶を入れるところを、「ロースハムブロックが余っていた」として、こちらに差し替え。ツナ缶の油はバターで補いました。

トーストに合わせても最高にマッチです。

Matomo連携時にハマったこと。(連携手順とSSL設定)

概要

オープンソースのWeb解析、

WordPressとMatomoを別々のサーバーで運用し、wp-matomo(現在の名称は「Connect Matomo」)を使用して連携させる手順を整理しました。

この設定により、WordPress側で収集したデータを別サーバーのMatomoへ送信し、WordPressの管理画面内でアクセス統計を確認できるようになります。

環境

Matomo側

  • Ubuntu 24.04
  • Apache 2.4
  • Mod Security v2

WordPress専用サーバ

  • Connect Matomoプラグイン

さっくりとした手順

  1. Matomo サーバでセキュリティトークンを発行します。
  2. WordPressのプラグインを設定します。

1. Matomoサーバー側での準備

まず、データの受け皿となるMatomo側で「接続許可証(トークン)」と「サイトID」を確認します。

  1. Matomoにログインします。
  2. サイトの追加: まだWordPressサイトを登録していない場合は、[管理(歯車アイコン)] > [ウェブサイト] > [管理] から「新しいウェブサイトを追加」でWordPressサイトを登録します。この際表示される 「サイトID」(通常は1, 2…といった数字)をメモしておきます。
  3. Authトークンの発行:
    [管理(歯車アイコン)] > [個人] > [セキュリティ] を開きます。
    ページ下部の 「認証トークン(Auth tokens)」 セクションで「新しいトークンを作成」をクリックします。
    パスワードを入力し、用途(例: WP-Connection)を入力して作成します。
    表示された 長い英数字の文字列(トークン) をコピーして控えておきます。

注意
※注意
トークンは一度しか表示されません。必ずこのタイミングでコピーしてください。

2. WordPress側での設定

次に、WordPressにインストールしたプラグインにMatomoの情報を入力します。

  1. 設定画面を開く: WordPress管理画面の [設定] > [WP-Matomo](または Connect Matomo)を開きます。
  2. 接続設定(Matomoへ接続o)タブ:
  • Matomo モード: 「自己ホスト (HTTP API, デフォルト)」を選択します。
  • Matomo URL: MatomoがインストールされているサーバーのURLを入力します(例: https://analytics.example.com/)。末尾に / を含めてください。
  • 認証トークン: 先ほどMatomo側でコピーしたトークンを貼り付けます。
  1. 変更を保存: 「変更を保存」をクリックします。
  • 接続に成功すると、上部に緑色のメッセージが表示され、「Select site」 ドロップダウンからMatomoに登録したサイト名が選べるようになります。

3. トラッキングの有効化

接続しただけでは計測が始まらない場合があるため、以下の設定を確認します。

  1. トラッキングを有効化タブ をクリックします。
  2. トラッキングコードを追加: 「デフォルトのトラッキング」を選択します。これにより、WordPressの各ページに自動で計測タグが挿入されます。
  3. 変更を保存 をクリックして完了です。

よくあるトラブルと確認事項

別サーバー構成でうまく動かない場合は、以下をチェックしてください。

-URLの正確さ: Matomo URLが httphttps か、またサブディレクトリ(/matomo/ など)にインストールしていないか再確認してください。

  • ファイアウォール: WordPressサーバーからMatomoサーバーへの通信(ポート80または443)が許可されているか確認してください。
  • キャッシュ: WordPress側でキャッシュプラグインを使用している場合、設定反映後に一度キャッシュをクリアしてください。

自分がドハマリしたポイント

接続に失敗し、その接続ログが出てこない事態も発生しました。

その答えは、筆者が設定したapacheの.confファイルに入りました。

SSL設定を、筆者の標準の

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

から、以下の形で修正。

SSLProtocol -ALL +TLSv1.2 +TLSv1.3

これにより通信ができるようになりました。これには以下の理由があります。

1. 通信プロトコルの不一致(ハンドシェイクの失敗)

当初の設定: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 (意訳:TLS 1.3 のみを許可し、それ以外をすべて禁止する)

修正後の設定: SSLProtocol -ALL +TLSv1.2 +TLSv1.3 (意訳:TLS 1.2 と 1.3 の両方を許可する)

WordPressサーバーがMatomo APIにアクセスする際、内部ではPHPの cURL や openssl ライブラリが使用されます。もしWordPress側のOSやライブラリのバージョンが少し古い場合、あるいは最新であってもクライアント側の設定が TLS 1.2 までしか対応していない場合、Matomoサーバーが「TLS 1.3以外は受け付けない」という設定になっていると、共通の通信言語が見つからず、接続が即座に遮断されます。

2. PHP / cURL / OpenSSL の依存関係

WordPress(PHP)が外部サーバーと通信する際、バックグラウンドではシステム標準のOpenSSLライブラリが動いています。

TLS 1.3 を利用するには、OpenSSL 1.1.1以上が必要です。

もしWordPress側のサーバーOSが少し前の世代(例:Ubuntu 18.04やCentOS 7など)であったり、PHPのコンパイル環境が古い場合、TLS 1.3でのハンドシェイクを完遂できず、TLS 1.2での接続を試みようとします。

このとき、Matomo側が -TLSv1.2(1.2禁止)としていると、WordPress側は「接続できるプロトコルがない」と判断し、エラーを出します。

3. 「接続ログが出ない」という現象の理由

Apacheのアクセスログ(access.log)には、HTTPリクエストが成功または失敗した記録が残ります。しかし、SSL/TLSのハンドシェイク(暗号化の交渉)は、HTTPリクエストが送られる前段階で行われます。

TLS 1.2が禁止されている場合: 通信路を確立する前の「挨拶(ハンドシェイク)」の時点でサーバー側が「そのプロトコルは使えません」と接続を切断します。

こういうとき、以下のコマンドが有効です。

openssl s_client -connect analytics.example.com:443 -tls1_2

もし、このコマンドを実行して CONNECTED(00000003) と表示され、その後に証明書の情報がズラッと出てくれば、「インフラ(OS/ネットワーク/Apache)の土台は完璧である」という証明になります。

逆にここでエラーが出るなら、WordPressの設定(プラグイン)をいくらいじっても解決しないということが一瞬で分かります。

そのため、Apacheは「Webサイトへのアクセス」として認識する前に通信が終了してしまい、通常のアクセスログには一行も記録されないという事態が起こった話。

厳格な設定が裏目に出たという話でした。

ModSecurity環境下でのWP-Matomo連携設定

こちらの記事の続き。WebアクセスシステムMatomoをWordpressと連携させ、wp-matomoと連携するときに、Mod_Securityが邪魔をしたので処置を行いました。

環境

Matomo側

  • Ubuntu 24.04
  • Apache 2.4
  • Mod Security v2

WordPress専用サーバ

  • Connect Matomoプラグイン

発生していた問題(症例)

1. Expectヘッダーによるブロック(ID: 920450)

Matomoがデータ送信の準備として送った Expect ヘッダーが、WAFのポリシーによって「制限されたヘッダー」と判定されたログです。(IP/ホストなどはダミーに置き換え)

[Wed Jan 21 20:55:18.015915 2026] [security2:error] [pid 34746:tid 133273950865088] [client 192.0.2.100:56166] [client 192.0.2.100] ModSecurity: Warning. String match within "/content-encoding/ /proxy/ /lock-token/ /content-range/ /if/ /x-http-method-override/ /x-http-method/ /x-method-override/ /x-middleware-subrequest/ /expect/" at TX:header_name_920450_expect. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1187"] [id "920450"] [msg "HTTP header is restricted by policy (/expect/)"] [data "Restricted header detected: /expect/"] [severity "CRITICAL"] [hostname "matomo.example.com"] [uri "/"] [unique_id "aXC-pq-hNmFZwWUY4ipYBAAAAEg"]

2. スコア超過によるアクセス拒否(ID: 949110)

上記の Expect ヘッダー検知により、異常スコアがしきい値(5点)に達したため、通信が遮断(403 Forbidden)されたログです。

[Wed Jan 21 20:55:18.044159 2026] [security2:error] [pid 34746:tid 133273950865088] [client 192.0.2.100:56166] [client 192.0.2.100] ModSecurity: Warning. Operator GE matched 5 at TX:blocking_inbound_anomaly_score. [file "/usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "233"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [hostname "matomo.example.com"] [uri "/"] [unique_id "aXC-pq-hNmFZwWUY4ipYBAAAAEg"]

3. 相関ログ(ID: 980170)

最終的にどのカテゴリの攻撃として判定されたかをまとめた報告ログです。

[Wed Jan 21 20:55:18.307310 2026] [security2:error] [pid 34746:tid 133273950865088] [client 192.0.2.100:56166] [client 192.0.2.100] ModSecurity: Warning. Unconditional match in SecAction. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "98"] [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=0, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=5)"] [hostname "matomo.example.com"] [uri "/index.php"] [unique_id "aXC-pq-hNmFZwWUY4ipYBAAAAEg"]

行った措置:アプリケーション別除外ルールの作成

サーバー全体のセキュリティを下げるのではなく、特定のホスト(Matomoドメイン)に限定して、干渉しているルールのみを無効化します。

設定ファイルの記述例

/etc/modsecurity/rules/request-900-exclusion-rules-before-crs.conf 等に、以下の内容を追記、または作成します。

# ===================================================================
# アプリケーション別除外ルール: Matomo (matomo.example.com)
# ===================================================================

# 1. ターゲットとなるホスト名を指定し、それ以外は処理をスキップ
# ※ホスト名はご自身の環境に合わせて適宜読み替えてください
SecRule HTTP_HOST "@streq matomo.example.com" \
    "id:5001,phase:1,nolog,pass,chain,skipAfter:END_MATOMO_RULES_PRE"

    # 2. 特定されたホストに対し、干渉しているIDのみを無効化(外科手術)
    SecAction "ctl:ruleRemoveById=920450,ctl:ruleRemoveById=932370,ctl:ruleRemoveById=930130"

# スキップ先マーカー
SecMarker END_MATOMO_RULES_PRE

設定のテストと反映

上記、設定を行ったら

  • 構文チェック
sudo apache2ctl configtest

apache 再起動

sudo systemctl restart apache2.service

apache 再起動確認

systemctl status apache2.service

active(running)を確認します。

その後、wordpressのConnect Matomoのページに難度アクセス。

tail -f /var/log/matomo/matomo_error.log

等として(エラーログの場所は自分の環境に合わせます)

上記のログが出なければOKです。

今回の教訓

「最初にDetectionOnlyにしていたから助かった」に尽きます。

apacheの設定で

# Mod_security
<IfModule security2_module>
## 最初は検知モード
SecRuleEngine DetectionOnly
#SecRuleEngine On

と、コメントでオフオンを切り替えられる運用を組み込んでいたため、失敗を回避しました。

とはいえ

どハマりしたのがその、wp-connectとmatomoの連携だったのはまた改めて記します。

Ubuntu 24.04にMatomoをインストール。(PHP-FPM版)

概要

オープンソースの解析システムであるMatomoをインストールしたときのメモです。

  • Google Analysticにお金を払う余裕がない
  • WordPressのアクセス解析Jetpackは重い

ということで運用しました。

以前のメモがPHP8.3(mod-php)のインストールだったので、php-fpm版を改めて書き起こしています。

参考としたURL

  • https://matomo.org/faq/on-premise/matomo-requirements/

注意点

リアルタイムでアクセスする性質上、PVが非常に多いWebサイトではサーバ自体の冗長化構成が必要です。(上記URL参照)

筆者のサイトは10万ページ/月に満たないので、そこそこのスペックで運用できています。

前提

既に以下のシステムがWAN環境に揃っていること。

  • Ubuntu 24.04
  • Apache 2.4
  • mod_ssl
  • mod_rewrite
  • mod_header
  • ※実行ユーザーはwww-dataです。
  • mysql 8.3
  • PHP 8.3 → インストール方法
  • 必須の拡張機能(curl, gd, mbstring, mysql等)が有効になっていること。
  • PHP-FPM → インストール方法
  • ドメインで名前解決できること。
  • ドメインに沿った証明書があること。

さっくりとした手順

  1. MySQLのDBとユーザを作成します。
  2. ディレクトリにmatomoプログラムを配置します。
  3. Apache設定ファイルを作成します。
  4. matomoサイトにログインできることを確認します。
  5. matomo Web画面で初期設定をおこないます。

データベースを作成します。

  • MySQLログイン
sudo mysql -u root -p
  • DB作成
 CREATE DATABASE IF NOT EXISTS matomo CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; 

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

  • DBユーザー、パスワード設定
CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'YOUR_STRONG_PASSWORD';

DBユーザーは自身の環境に合わせます。パスワードはポリシーに沿って強固なものを設定してください。

  • DBユーザーに作成したDBへの権限を付与
GRANT ALL PRIVILEGES ON matomo.* TO 'matomo'@'localhost';
  • MySQLコンソールからログアウト
exit;
  • DB作成確認
mysql -u matomo -p

DB名・ユーザー名は適宜自分が設定したものに読み替えてください。

  • DB確認
SHOW DATABASES;

作成したDBがあることを確認します。

EXIT

MySQLコンソールから抜けます。

matomoプログラムをディレクトリに配置します。

  • 保存用ディレクトリに移動
cd /hoge &&pwd

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

  • プログラムダウンロード
wget https://builds.matomo.org/matomo-latest.zip
  • ZIP展開
unzip matomo-latest.zip
  • ディレクトリの所有者変更
sudo chown -R www-data:www-data matomo

ディレクトリ一式をApache実行ユーザー(www-data)に修正します。

  • プログラム実行権に移動
sudo mv matomo /home/www-data/

自分の環境に合わせます。(筆者環境は/home/www-data/matomo で動かします)

ls -ld /home/www-data/matomo

該当ディレクトリにファイル一式があることを確認します。

Apache設定ファイルを作成します。

【】内を自分の環境に合わせます。
コマンド一式をコピー → 別のエディタにペースト
その後、【】内を自分の環境に修正してコピー
コマンド一式をSSHクライアントに貼り付ける

cat <<- __EOF__ | sudo tee  /etc/apache2/sites-available/matomo.conf > /dev/null
<VirtualHost _default_:80>
ServerName 【設定したドメイン名】
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName 【設定したドメイン名】
    CustomLog 【/var/log/matomo/matomo_access.log combined】
    ErrorLog 【/var/log/matomo/matomo_error.log】
    # アクセスログとエラーログは自分の環境に合わせて設定します。

    DocumentRoot 【/home/www-data/matomo】
     # PHPファイルの処理をFPMに渡す設定
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    # -----------------------
    <Directory 【/home/www-data/matomo】>
    # DcoumentRootとDirectoryは自分の環境に合わせて設定します
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require all granted
    </Directory>

#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
  # SSLを有効化します

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
#TLS1.3に対応していないクライアントがアクセスする場合は以下を用います
#SSLProtocol -ALL +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:/var/run/apache2/ssl_stapling(32768)"
# 2025年5月よりLet's EncryptはSSL Staplingに伴うOCSPを廃止しました。そのため、証明書をLet's Encryptにしている場合は上記2行をコメントアウトし、代わりにこちらを用いてください。
# SSLUseStapling Off

SSLCertificateFile 【/etc/certs/example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/example.com.key】
# 秘密鍵を指定します

# SSLCACertificateFile 【/etc/certs/example.com.CA.crt】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します

    # index.php への転送設定
    DirectoryIndex index.php

#セキュリティヘッダー付与

    Header always set Strict-Transport-Security "max-age=63072000"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"

    # Matomo: 機密情報が含まれるディレクトリへの直接アクセスを禁止
    <DirectoryMatch "/(config|core|lang|tmp|vendor)">
        Require all denied
    </DirectoryMatch>

    # Matomo: .ini や .json といった設定ファイルへの直接アクセスを禁止
    <FilesMatch "\.(ini|json)$">
        Require all denied
    </FilesMatch>

</VirtualHost>
__EOF__
  • ファイル作成確認
ls -l /etc/apache2/sites-available/matomo.conf

ファイルがあることを確認します。

Apache設定を反映します。

  • .conf読み込み
sudo a2ensite matomo.conf
  • 設定確認
sudo apache2ctl configtest

Syntax OKを確認します

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
sudo systemctl status apache2.service
  • ブラウザ表示確認。

ブラウザで

https://【matomoを設定したドメイン名】

にアクセスし、初期画面が出ることを確認します。

初期インストール画面の設定

  1. 初期インストール画面が出たら「次へ」をクリックします。
  2. 全てチェックされていることを確認して「次へ」をクリックします。
◎データベースを設定します。
  • ログイン: MySQLのユーザー(matomo)
  • パスワード: 設定したパスワード
  • データベース名:作成したDB (matomo)

をそれぞれ入力し、「次へ」をクリックします。正常に入力されれば「テーブルを作成されました」と出るので「次へ」をクリックします。

◎スーパーユーザーを設定します。
  • スーパーユーザーログイン:ログインするユーザー名
  • パスワード:ログイン時のパスワード
  • パスワード(再入力)
  • メールアドレス

をそれぞれ入力して「次へ」をクリックします。

◎アクセス解析を行うウェブサイトを設定します。
  • アクセス解析対象のウェブサイトの名前
  • ウェブサイトのURL (このmatomoサイトではなく、アクセス解析を行いたいWebサイト)
  • ウェブサイトのタイムゾーン
  • eコマースか否か

を設定して「次へ」をクリックします。

これらを設定後、トラッキングタグが表示されます。これらを控えて「次へ」をクリックします。

「おめでとうございます!」と表示されればインストールの一連の作業は完了します。

Mod_Securityが検知したOpen Proxy スキャニングログ

2026年1月20日、筆者が管理するサーバにて、典型的な Open Proxy スキャニング(公開プロキシ探索攻撃) を検知しました。
WAF(ModSecurity)が、いかにして「身勝手な中継依頼」を門前払いしたか、実際のログからそのメカニズムを記録します。

1. 検知ログの概要(実録)

以下は、攻撃者が CONNECT メソッドを使用して外部ドメイン(www.baidu.com)へ接続しようとした際のログです。

[Tue Jan 20 05:43:59 2026] [security2:error] [client xx.xx.xx.xx] 
ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. 
[id "911100"] [msg "Method is not allowed by policy"] [data "CONNECT"] [severity "CRITICAL"]
[hostname "www.baidu.com"] [uri "/"]

2. 攻撃の構造解析:何が起きていたのか?

このログから、攻撃者の明確な意図が読み取れます。

A. メソッドの悪用(CONNECT)

通常、Web閲覧(GET/POST)には使われない CONNECT メソッドが使用されています。これは本来、プロキシサーバに対して「外部サーバへのトンネルを作れ」と命じるためのコマンドです。

B. Hostヘッダの偽装

[hostname "www.baidu.com"]

攻撃者は、筆者のサーバに接続していながら、リクエストの宛先に www.baidu.com を指定しています。これは、筆者のサーバを「踏み台(Open Proxy)」にして、中国の検索エンジンにアクセスしようとする試みです。

これは、ほぼ、金盾の影響下にある者が当局の規制を逃れるため、私のvpsを利用しようとしたという背景でしょう。

3. 防御のロジック:なぜ止まったのか

ID 911100 の発動: ModSecurity CRS は、許可リストにないメソッド(CONNECT)を検知した瞬間、問答無用で CRITICAL 判定を下しました。

4. 結果:404ページへの誘導。

また、筆者のapacheのバーチャルサイトの設定もいい動きをしました。

ErrorDocument 403 404.html

としていたため、ModSecurity がアクセスを拒絶した後、Apache は設定された ErrorDocument に従い、403 forbiddenではなく、内部的に 404 not found を返しています。
攻撃者側から見れば、外部へのトンネルが開通するどころか、「そんなページ(機能)は存在しない」 という素っ気ない返答を掴まされて終わったことになります。

5. まとめ

今回の事例は、WAFのポリシーを「必要なものだけを許可し、不要なものは拒否する」状態に保ったことが防御につながった例です。

オレだけが外に出る事を
許可しろォォォ─────ッ

だが!
ウイルスは
許可しないィィィ────ッ

感染した部分は
出る事は
許可しないィィィィィ───ッ!!

というイルーヅォの言葉は割とセキュリティで重要という言葉を以て、本記事を締めくくります。

Linuxのディスク使用状況をMarkdown形式で一発表示するワンライナー

サーバーの構築メモやドキュメント作成時に、「現在のディスク使用状況をサクッとMarkdownの表にしたい」と思ったのがこちらのワンライナーのきっかけ。

通常、df -h などのコマンドを使いますが、結果をブログやGitHubのIssueに貼り付けるには整形の手間がかかります。

今回は、lsblkjq を組み合わせて、実行するだけで綺麗なMarkdownテーブルを出力する魔法のワンライナーをご紹介します。

使用するコマンド

以下のワンライナーを使用しました。

{ echo -e "| デバイスパス | 全サイズ | 使用率 | 空き容量 | マウントポイント |"; echo -e "| --- | --- | --- | --- | --- |"; lsblk -lnpo NAME,SIZE,FSUSE%,FSAVAIL,MOUNTPOINT --json | jq -r '.blockdevices[] | select(.mountpoint != null and (.name | contains("loop") | not)) | "| \(.name) | \(.size) | \(.["fsuse%"] // "0%") | \(.fsavail // "-") | \(.mountpoint) |"'; }

出力結果のイメージ

実行すると、以下のようなMarkdown形式のテキストが得られます。

デバイスパス全サイズ使用率空き容量マウントポイント
/dev/vda1149G24%109.9G/
/dev/vda15106M6%98.2M/boot/efi
/dev/vda16913M13%702.4M/boot

このワンライナーの仕組み

このコマンドは大きく分けて3つのパートで構成されています。

1.ヘッダーの作成

echo -e を使って、Markdownの表の1行目(項目名)と2行目(区切り線)を出力しています。

2. lsblkによるデータ取得(JSON形式)

lsblk コマンドに複数のオプションを渡しています。

  • -l: リスト形式で表示
  • -n: ヘッダーを非表示にする
  • -p: フルデバイスパスを表示(/dev/vda1など)
  • -o ...: 必要な項目(名前、サイズ、使用率、空き容量、マウントポイント)を指定
  • --json: データを扱いやすいJSON形式で出力します。

3. jqによるフィルタリングと整形

JSONデータを jq で加工し、Markdownの行 | ... | ... | の形に変換しています。

  • select(.mountpoint != null): マウントされていないデバイスを除外します。
  • contains("loop") | not: Snapパッケージなどで増えがちな loop デバイス(仮想デバイス)を除外してスッキリさせています。
  • \(.name) | ...: JSONの値をMarkdownのパイプ記号で囲んで出力します。

まとめ

このワンライナーを使えば、サーバー調査の結果をそのままドキュメントに記録できるため、作業効率が大幅にアップします。特にファイルサーバやWebサーバの定点観測に役立つでしょう。

Page 1 of 281

Powered by WordPress & Theme by Anders Norén