2024年末に注文したものが、1年の時を経て到着です。

DesignCOCOによる「1/4」スケールフィギュア。
ライザのフィギュアをあまたお迎えすれど、このサイズは初。箱の時点で圧倒的なスケール感です。

全身像はこちら。これがどれほどの大きさかは


1/7や1/6でも「1/12に見える」ぐらいですから相当です。


プロポーションも抜群。浮き輪の素材も本物という念の入れよう。

収納する場所があってよかったという形です。
2024年末に注文したものが、1年の時を経て到着です。

DesignCOCOによる「1/4」スケールフィギュア。
ライザのフィギュアをあまたお迎えすれど、このサイズは初。箱の時点で圧倒的なスケール感です。

全身像はこちら。これがどれほどの大きさかは


1/7や1/6でも「1/12に見える」ぐらいですから相当です。


プロポーションも抜群。浮き輪の素材も本物という念の入れよう。

収納する場所があってよかったという形です。
ローカルサーバに設置されているNextcloudを利用するためのデスクトップクライアント。
自動更新するはずが、以下のメッセージが出て

「再起動してアップデート」をクリックしても同じエラーが発生。
これの対処のメモです。
参考手順(というよりもリリース)
タスクバーから「Nextcloudを終了」でアプリを終了します。

Nextcloud クライアント公式に飛びます。
v4.0.6以降をダウンロードして、インストーラーを実行します。
インストール終了後、上記エラーが出ないことを確認します。
昨日運用を開始したzram。その効果を実感できる「単体テスト」にぶち当たりました。
Growiのアップデートです。
| 項目 | 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 GiB | 927.6 MiB |
| zram実占有 (TOTAL) | - | 333.6 MiB | 258.1 MiB |
| 圧縮率 (zstd) | - | 約4.3倍 | 約5.5倍 |
| ディスクスワップ使用量 | 0.02 GiB | 0 B | 0 B |
| 主な状態 | 初期クリーン状態 | ビルド等のメモリ最大消費時 | 安定稼働・メモリ余裕あり |
「取り敢えず私のサーバには合っている」という形。他、気がついた事項は随時フィードバックしていきます。
筆者が運用しているWebサーバ。興味が向くまま様々なWebアプリを入れているため、メモリが心許ない事態が発生します。
単にスワップを増やすのではなく、Linuxの物理メモリ(RAM)の上に圧縮された専用領域(ブロックデバイス)を作成する、zramを導入します。
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 Total | 5.78 GiB |
| Mem Used | 2.78 GiB |
| Mem Free | 0.42 GiB |
| Swap Total | 2.00 GiB |
| Swap Used | 0.02 GiB |
| Swap Free | 1.98 GiB |
メモリ上にブロックデバイスを作成しますが、その分、マシンパワーを喰います。
例えば1GB未満のWebサーバでの運用は厳に慎むべきです。
「スワップをいじることのヤバさ」が知らない方は、この先の文章は読まないでください。(正直、DDoS喰らった時以上に神経を使う作業でした)
このvpsを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。
など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。
当然、設定の大幅変更に関わるので設計書や運用のドキュメント化も待っています。
※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。
以下、フェイズ・ゼロをクリアした(必要ない)方向けです。
※筆者の好みでaptitudeを用いています。必要に応じてaptに読み替えてください。
仮想サーバ、vps等で運用している場合は、イメージ全体をバックアップ(スナップショット)などとしておき、何かあったときにすぐに戻せるようにします。
これが地味にハマりました。
sudo apt install linux-modules-extra-$(uname -r)
これを入れていないと「現在のカーネルにzramモジュールが存在しない、あるいはロードできない」事態が発生します。(発生しました)
sudo aptitude install zram-tools
と、コマンド一発で済む作業です。しかし、コマンド一発で済む作業であるからこそ、チューニングは細心の注意が必要です。
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を逆にした理由です。
sudo systemctl restart zramswap
`
※筆者がハマったのはここです。ここでエラーが発生してカーネルモジュールをインストールする手戻りが発生しました。
systemctl status zramswap.service
active(exited)を確認します。(これは、apache/mysqlなどの常駐型サービスと異なり「カーネルにロードしてしまえば後はOK」という状態のためexitedとなっています。
sudo reboot
行います。再起動に慎重を要する(クラスタリングなど)はその手順に従ってください。
ここで再起動しない事態が発生したら?
「さぱっと死せい 黄泉路の先陣じゃ 誉れじゃ」
ぐらいの潔さを持ちましょう。(持てなければそもそも筆者はサーバ運用をしていません
潔さがない方のためのイメージ全体のバックアップであり、スナップショットなので。
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です。
昨今のノートPCに強制的についてくるCopilotキー。

これが不便なので別のものに切り替えます。
設定 > Bluetoothとデバイス > キーボード
ショートカットとホットキー

ここで、「キーボードのCopilotキーをカスタマイズする」を行ったところで、選べるものが
しか選べない状況でした。
そこで試したのはMicrosoft PowerToysです。

これをストアでインストール。インストール後、
Keyboard Managerを選択。

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

ここで選ぶのは、ショートカット(左側)
という、Copilotのショートカット。
割当先を
PrintScreenに変更。

変更後、OKをクリックすることで、Copilotキーがスクリーンショットと、役立つ機能へのショートカットになりました。
新調したノートPC、ThinkPad P14s Gen 6 (AMD)。
こちらを、例によってデコレーションしました。

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

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

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

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

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

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

トーストに合わせても最高にマッチです。
オープンソースのWeb解析、
WordPressとMatomoを別々のサーバーで運用し、wp-matomo(現在の名称は「Connect Matomo」)を使用して連携させる手順を整理しました。
この設定により、WordPress側で収集したデータを別サーバーのMatomoへ送信し、WordPressの管理画面内でアクセス統計を確認できるようになります。
まず、データの受け皿となるMatomo側で「接続許可証(トークン)」と「サイトID」を確認します。
注意
※注意
トークンは一度しか表示されません。必ずこのタイミングでコピーしてください。
次に、WordPressにインストールしたプラグインにMatomoの情報を入力します。
https://analytics.example.com/)。末尾に / を含めてください。接続しただけでは計測が始まらない場合があるため、以下の設定を確認します。
別サーバー構成でうまく動かない場合は、以下をチェックしてください。
-URLの正確さ: Matomo URLが http か https か、またサブディレクトリ(/matomo/ など)にインストールしていないか再確認してください。
接続に失敗し、その接続ログが出てこない事態も発生しました。
その答えは、筆者が設定したapacheの.confファイルに入りました。
SSL設定を、筆者の標準の
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
から、以下の形で修正。
SSLProtocol -ALL +TLSv1.2 +TLSv1.3
これにより通信ができるようになりました。これには以下の理由があります。
当初の設定: 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以外は受け付けない」という設定になっていると、共通の通信言語が見つからず、接続が即座に遮断されます。
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側は「接続できるプロトコルがない」と判断し、エラーを出します。
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サイトへのアクセス」として認識する前に通信が終了してしまい、通常のアクセスログには一行も記録されないという事態が起こった話。
厳格な設定が裏目に出たという話でした。
こちらの記事の続き。WebアクセスシステムMatomoをWordpressと連携させ、wp-matomoと連携するときに、Mod_Securityが邪魔をしたので処置を行いました。
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"]
上記の 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"]
最終的にどのカテゴリの攻撃として判定されたかをまとめた報告ログです。
[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の連携だったのはまた改めて記します。
オープンソースの解析システムであるMatomoをインストールしたときのメモです。
ということで運用しました。
以前のメモがPHP8.3(mod-php)のインストールだったので、php-fpm版を改めて書き起こしています。
リアルタイムでアクセスする性質上、PVが非常に多いWebサイトではサーバ自体の冗長化構成が必要です。(上記URL参照)
筆者のサイトは10万ページ/月に満たないので、そこそこのスペックで運用できています。
既に以下のシステムがWAN環境に揃っていること。
www-dataです。sudo mysql -u root -p
CREATE DATABASE IF NOT EXISTS matomo CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
DB名は自分の環境に合わせます。
CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'YOUR_STRONG_PASSWORD';
DBユーザーは自身の環境に合わせます。パスワードはポリシーに沿って強固なものを設定してください。
GRANT ALL PRIVILEGES ON matomo.* TO 'matomo'@'localhost';
exit;
mysql -u matomo -p
DB名・ユーザー名は適宜自分が設定したものに読み替えてください。
SHOW DATABASES;
作成したDBがあることを確認します。
EXIT
MySQLコンソールから抜けます。
cd /hoge &&pwd
自分の環境に合わせます。
wget https://builds.matomo.org/matomo-latest.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
該当ディレクトリにファイル一式があることを確認します。
【】内を自分の環境に合わせます。
コマンド一式をコピー → 別のエディタにペースト
その後、【】内を自分の環境に修正してコピー
コマンド一式を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
ファイルがあることを確認します。
sudo a2ensite matomo.conf
sudo apache2ctl configtest
Syntax OKを確認します
sudo systemctl restart apache2.service
sudo systemctl status apache2.service
ブラウザで
にアクセスし、初期画面が出ることを確認します。
をそれぞれ入力し、「次へ」をクリックします。正常に入力されれば「テーブルを作成されました」と出るので「次へ」をクリックします。
をそれぞれ入力して「次へ」をクリックします。
を設定して「次へ」をクリックします。
これらを設定後、トラッキングタグが表示されます。これらを控えて「次へ」をクリックします。
「おめでとうございます!」と表示されればインストールの一連の作業は完了します。
Powered by WordPress & Theme by Anders Norén