タグ: Linux Page 1 of 28

Ubuntu 24.04にMatomoをインストール

概要

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

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

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

以前のメモがUbuntu 20.04のインストールだったので、こちらを改めて書き起こしています。

参考としたURL

注意点

リアルタイムでアクセスする性質上、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等)が有効になっていること。
  • ドメインで名前解決できること。
  • ドメインに沿った証明書があること。

さっくりとした手順

  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 WITH mysql_native_password BY 'YOUR_STRONG_PASSWORD';

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

  • DBユーザーに作成したDBへの権限を付与
GRANT ALL PRIVILEGES ON matomo.* TO 'matomo'@'localhost';
  • 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】
    <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】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します

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

    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コマースか否か

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

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

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

Ubuntu24.04にGrowi2.7.8をインストール。(2025年7月版)

何度か書いているGrowiのインストール(Docker不使用)。

手順を色々見直して2025年7月版としました。

概要

Growi v7.2.8のインストールメモです。

MongoDBの関係もあり、インストールするCPUを選びます。

環境

  • Ubuntu 24.04
  • Apache 2.4

の基本的な設定が済んだという状況です。

前提

  • 名前解決できるドメインが用意されている。
  • そのドメインに応じた証明書が用意されている。

さっくりとはならない手順

  1. 必要なパッケージをインストールします。
  2. nvmをインストールします。
    • nvm経由でnode,npm,pnpmをインストールします。
  3. Redis-serverをインストールします。
  4. Javaをインストールします。
  5. ElasticSearch 8をインストールします。
    • ElasticSearchの設定変更を行います。
    • ElasticSearchのプラグインをインストールします。
    • ElasticSearchの設定変更を反映します。
  6. MongoDBをインストールします。
    • MongoDBのデータ格納先を変更します。(オプション)
    • MongoDBの設定変更を反映します。(オプション)
  7. Growiのインストールを行います。
    • pnpmを用いてインストールします。
    • アプリのビルドを行います。
  8. 自動起動のスクリプトを作成します。
  9. Apacheのリバースプロキシの設定を行います。
  10. ブラウザで初期インストールを行います。

手順

筆者の好みでaptitudeを用いています。適宜、aptに読み替えてください。

必要なパッケージのインストールを行います。

  • git, buildツールなど
sudo aptitude install build-essential git git-lfs apt-transport-https

v7.1系で`git-lfsを入れないとgit-cloneでビルドが行えなかったので、その名残です。

nvmインストール

  • root昇格

※growiをroot権限で実行するため

sudo su -
  • nvmインストールスクリプトの実行
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  • nvm環境の有効化と確認
export NVM_DIR="$HOME/.nvm" 
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" 

一度セッションを切り、再度sudoを行いました。

nvm --version

0.39.7と表示されることを確認。

(まだrootです)

  • nvm経由でNode.jsをインストール

npm@11.4.0と互換性があるNode.jsをインストールします。

nvm install v20.19.2
  • Node.jsバージョンの使用とデフォルト設定
nvm use v20.19.2
nvm alias default v20.19.2
  • Node.jsバージョン確認
node -v

v20.19.2を確認

npm -v

10.7.0を確認

  • npmのインストール
npm install -g npm@11.4.0
  • npmバージョン確認
npm -v

11.4.0を確認

  • pnpmインストール
npm install -g pnpm
  • pnpmバージョン確認
pnpm -v

10.11.0を確認

  • rootから抜ける
exit

redis-serverをインストールします。

  • インストール
sudo  aptitude install redis-server
  • 起動確認
systemctl status redis-server

active(running)を確認します。

  • 自動起動有効化
sudo systemctl enable redis-server

Javaをインストールします。

  • インストール
sudo aptitude install openjdk-17-jdk

Elasticsearchをインストールします。

  • gpg追加
sudo wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
  • レポジトリ追加
sudo echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
  • パッケージのアップグレード
sudo aptitude update
  • ElasticSearchインストール
sudo aptitude install elasticsearch

※この後、デフォルトパスワードが表示されますが、控えておく程度にしましょう。

JVM設定変更
  • バックアップディレクトリ作成
sudo mkdir /etc/elasticsearch/old

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

  • 設定ファイルバックアップ
sudo cp -pi /etc/elasticsearch/jvm.options /etc/elasticsearch/old/jvm.options.$(date +%Y%m%d)
  • 設定ファイル書き換え
echo -e "-Xms256m\n-Xmx256m" | sudo tee -a /etc/elasticsearch/jvm.options
  • 書き換え確認
sudo diff -u /etc/elasticsearch/old/jvm.options.$(date +%Y%m%d) /etc/elasticsearch/jvm.options
  • 差分
+-Xms256m
+-Xmx256m
ElasticSearchの設定変更

※この作業も管理者権限で実行します。

  • root昇格
sudo su -
  • 設定ファイルバックアップ
cp -pi /etc/elasticsearch/elasticsearch.yml /path/to/backup/elasticsearch.yml.$(date +%Y%m%d)

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

  • ファイル書き換え
sed -i -e 's/xpack.security.enabled: true/xpack.security.enabled: false/' \
       -e '/xpack.security.http.ssl:/{n; s/  enabled: true/  enabled: false/}' \
       -e '/xpack.security.transport.ssl:/{n; s/  enabled: true/  enabled: false/}' /etc/elasticsearch/elasticsearch.yml
  • 差分確認
diff -u /path/to/backup/elasticsearch.yml.$(date +%Y%m%d) /etc/elasticsearch/elasticsearch.yml
  • 差分
 # Enable security features
-xpack.security.enabled: true
+xpack.security.enabled: false

 xpack.security.enrollment.enabled: true

 # Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
 xpack.security.http.ssl:
-  enabled: true
+  enabled: false
   keystore.path: certs/http.p12

 # Enable encryption and mutual authentication between cluster nodes
 xpack.security.transport.ssl:
-  enabled: true
+  enabled: false
  • rootから抜ける
exit
ElasticSearchのプラグインを追加
  • analysis-kuromoji インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
  • analysis-isu インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
自動起動設定反映
  • 起動
sudo systemctl start elasticsearch
  • 起動確認
systemctl status elasticsearch

active(running)を確認します。

  • 自動起動有効化
sudo systemctl enable elasticsearch

MongoDBインストール

レポジトリ追加

  • 必要パッケージインストール
sudo aptitude install gnupg
  • gpg追加
curl -fsSL https://www.mongodb.org/static/pgp/server-6.0.asc | \
   sudo gpg -o /usr/share/keyrings/mongodb-server-6.0.gpg \
   --dearmor
  • レポジトリ追加
echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list
MongoDBインストール
  • パッケージのアップグレード
sudo aptitude update
  • MongoDBインストール
sudo aptitude install mongodb-org
保存先変更(オプション)

MongoDBの格納先を、冗長化構成されているパーティションにするため対応しました。

本設定の要注意点

MongoDBは、その性質上、頻繁にファイルの書き換えを行います。そのため、ブロックストレージのような「データ削除ポリシー」が明記されているネットワークストレージに、保存パーティションを指定してはいけません。(筆者はそれで痛い目に遭いました)

本設定が必要な場合は、同じサーバ上の、SSDで行いましょう。

  • 格納ディレクトリ作成
sudo mkdir /home/mongodb

保存先を変えたいところにします

  • 所有者変更
sudo chown -R mongodb:mongodb /home/mongodb
  • 所有者変更確認
ls -ld /home/mongodb
  • 設定ファイルのバックアップ取得
sudo cp -pi /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)

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

  • バックアップ確認
sudo diff -u /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)

バックアップが保存されたか、差分がないことで確認します。

  • ファイル書き換え
sudo sed -i 's/dbPath: \/var\/lib\/mongodb/dbPath: \/home\/mongodb/' /etc/mongod.conf
  • 差分確認
sudo diff -u /path/to/backup/mongod.conf.$(date +%Y%m%d) /etc/mongodb.conf
  • 差分
-  dbPath: /var/lib/mongodb
+  dbPath: /home/mongodb
自動起動有効
  • mongodサービス起動
sudo systemctl start mongod
  • サービス起動確認
systemctl status mongod

active (running)を確認します

  • 自動起動有効化
sudo systemctl enable mongod

Growiインストール

  • git clone
sudo git clone https://github.com/weseek/growi /home/www-data/growi

※任意のディレクトリを指定します。

  • ディレクトリ移動
cd /home/www-data/growi && pwd

先ほどcloneしたディレクトリです。

  • チェックアウト
sudo git checkout -b v7.2.8 refs/tags/v7.2.8

2025/06/30時点での最新リリースです

  • pnpmによるインストール
sudo pnpm install

CPUのスペックによっては相当な時間がかかります。

  • ビルド
sudo npm run app:build
必要であればlfs pull
  • lfs pull
sudo git lfs pull

→ v6.1で必要なコマンドでした。v7でビルドできない場合に試してください。

やはり時間がかかります。

自動起動スクリプトの作成

  • systemd作成
cat <<- __EOF__ | sudo tee -a /etc/systemd/system/growi.service
[Unit]
Description = growi
After=network-online.target mongod.service
After=network.target elasticsearch.service
ConditionPathExists=【/home/www-data/growi】

[Service]
ExecStart=【/home/www-data/growi/】growi-start.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target
__EOF__

※【】内を、git cloneしたディレクトリにします。

  • Growiインストールディレクトリに作成
  • 教義・信仰に沿ったエディタで作成します。
  • ファイル名:growi-start.sh
  • growiを配置したディレクトリ内に作成します。
#!/bin/bash

# NVM environmentをロード (NVM_DIRを直接指定)
export NVM_DIR="/root/.nvm" # $HOMEの代わりに直接パスを指定
if [ -s "$NVM_DIR/nvm.sh" ]; then
  \. "$NVM_DIR/nvm.sh"  # nvmをロード
  # 次の行でスクリプト実行時のnodeとnpmのバージョンをログに出力
  echo "NVM for GROWI startup script loaded. Using Node version: $(node -v), npm version: $(npm -v)" > /tmp/growi_nvm_load.log
else
  # NVMが見つからない場合もログに出力
  echo "NVM_DIR ($NVM_DIR) not found or nvm.sh not found for GROWI startup script." > /tmp/growi_nvm_load.log
fi

cd 【/home/www-data/growi】
NODE_ENV=production \
AUDIT_LOG_ENABLED=true \
FORCE_WIKI_MODE=private \
MONGO_URI=mongodb://localhost:27017/growi \
ELASTICSEARCH_URI=http://localhost:9200/growi \
REDIS_URI=redis://localhost:6379 \
PASSWORD_SEED=[任意の文字列] \
npm run app:server

[任意の文字列]は推測されないような英数字+記号を指定します。

  • 権限変更
sudo chmod +x /home/www-data/growi/growi-start.sh
  • systemd設定反映
sudo systemctl daemon-reload
  • growi有効化
sudo systemctl start growi.service
  • growi有効化確認
systemctl status growi.service

active(running)を確認

  • 自動起動有効化
sudo systemctl enable growi.service

Apacheによるリバースプロキシの設定

  • モジュールインストール
sudo a2enmod proxy_http proxy_wstunnel rewrite header
  • apache再起動
sudo systemctl restart apache2.service
  • ログ保存ディレクトリ作成
sudo mkdir /var/log/growi/
  • 所有者変更
sudo chown -R www-data:www-data /var/log/growi
  • 設定ファイル作成
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/growi.conf
<VirtualHost _default_:80>
    ServerName 【hoge.example.com】
    # ドメイン名を指定します
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTPアクセスを強制的にHTTPSにリダイレクトします
</VirtualHost>

<VirtualHost _default_:443>
    ServerName 【hoge.example.com】
    # ドメイン名を指定します
    CustomLog /var/log/growi/growi_access.log combined 
    ErrorLog /var/log/growi/growi_error.log

#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
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-ECDSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

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

    # Header に Host: example.com を追加するため
    ProxyPreserveHost On
    # HTTPS利用時: Header に x-forwarded-proto: https を追加するため
    RequestHeader set x-forwarded-proto 'https'
    # Apache では static assets で 304 が返らないことがあるので ETag を無効化する
    <ifModule mod_headers.c>
            Header unset ETag
    </ifModule>

FileETag None 

<FilesMatch "\.(js|css|png|jpg|gif|svg|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

# リバースプロキシー設定
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

ProxyPass        / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/


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

    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"
</VirtualHost>
__EOF__

【】内を自分の環境に変更してください。

  • 設定反映
sudo a2ensite growi.conf
  • コンフィグ確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache2再起動
sudo systemctl restart apache2.service

Growiインストール確認

http://設定したドメイン
でアクセスします。

初期サイトが表示されたらインストール完了です。

  • 管理者メールアドレス
  • 管理パスワード

等を設定してログインします。

Redmine5.xとGmailを連携させる。

前に書いたこちらの記事を、よりステップを追うと共に実運用に沿って記述したものです。

本記事で実施すること

  • RedmineとGmailアカウントを紐付け、Redmineからの各種通知をメールで受け取れるようにする。

想定している読者

  • メール通知機能を行いたいが、SMTPサービスを用意したくない
  • (AWSはSMTP機能を遮断しているなど)
  • Redmineのconfiguration.ymlを設定していない

前提

以下が必須です。

  • Redmine稼働サーバのSSHアクセス権限がある
  • かつ管理者権限を持っている
  • Gmailアカウントを持っている
    • ※この連携のためだけに、一つ、連携専用のアカウントを作成することを「強く、強く」推奨します。

また、Redmineのディレクトリを

/home/www-data/redmine

としていますので、自分の環境に合わせてください。

注意事項

本記事により、以下のリスクが発生します。

  • Gmailアプリパスワード漏洩により、用意したアカウントでメールが送信される。
  • その他、 Googleアカウント全体が危険にさらされる。

そのため、この作業は細心の注意を払ってください。

さっくりとした手順

  1. Gmailの2段階認証を有効にします。
  2. アプリパスワードを発行します。
  3. Redmine稼働サーバでメールの設定を行います。
  4. 送信確認を行います。

Googleアカウントで設定をします。

  1. Googleアカウント > セキュリティに移動します。
  2. Googleへのログインで「2段階認証プロセス」をオンにします。

どういう方法で認証をするかは運用に合わせてください。

アプリパスワードを用意します。

  1. Googleアカウント > セキュリティに移動します。
  2. Googleへのログイン > アプリパスワードに移動します。
  3. プルダウンメニューから以下を入力し、「生成」をクリックします。
  4. アプリを選択:メール
  5. デバイスを選択:その他(名前を入力)
  6. 任意の名前(redmine等)を入力
  7. 生成されたパスワードを控えます。
  8. このパスワードはGoogleアカウントへのアクセス権が付与されることに注意ください。
  9. このパスワードはRedmineサイトのDBパスワードと同様の厳密さで運用しましょう。

メールサーバ情報を設定します。(RedmineサーバにSSH接続)

【】内は、自分の環境に合わせます。

cat <<- __EOF__ | sudo tee -a 【/home/www-data/redmine/config/configuration.yml】
production:
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: "smtp.gmail.com"
      port: 465
      ssl: true
      authentication: :plain
      domain: "smtp.gmail.com"
      user_name: "【Gmailアドレス】"
      password: "【上述したアプリパスワード】"
__EOF__
ls -l /home/www-data/redmine/configconfiguration.yml

配置したディレクトリは自分の環境に合わせます。

設定を反映します。

sudo systemctl restart apache2.service

自分が使っているWebサービスに合わせます。

Redmineサイトに管理者アカウントでログインします。

  1. 管理>設定に移動します。
  2. 「メール通知」がタブが有効になっているので、このタブをクリックします。

通知メールの設定を行います。

以下を設定して「保存」をクリックします。

  • 送信元メールアドレス:自分のメールアドレス
  • 宛先を非表示(bcc):チェックを外す
  • メール通知の送信対象とする操作:運用に合わせます。

通知メールの確認を行います。

  1. Redmineの個人設定に移動します。
    1.「自分自身による変更の通知は不要」のチェックを外し、保存をクリックします。
  2. 任意のチケットを発行/変更し、メールが届いていることを確認します。

以上で、設定は完了です。

トラブルシューティング:メールが届かない場合

Googleからのセキュリティ通知を確認する

新しいサーバー(VPS)からの最初のログインは、Googleによって「不審なログイン試行」と見なされ、一時的にブロックされることがあります。

その場合、Gmailアカウントの受信トレイに「セキュリティ通知」メールが届いているはずです。メールの内容に従い、「はい、心当たりがあります」などの操作を行って、アクセスを許可してください。

サーバーからGmailへの接続を確認する:

RedmineサーバーからGmailのSMTPサーバーに到達できるかを確認します。SSHで以下のコマンドを実行します。

telnet smtp.gmail.com 587

Connected to smtp.gmail.com.のように表示されれば、ネットワーク的な接続は問題ありません。(終了するには quit と入力します)

Mod_Securityチューニングのケーススタディ:「PCRE limits exceeded」エラーへの対処

概要

先日の記事でgitを用いたmod-securrity core rule setのアップデートを行いました。

このアップデートにより新たに検知されたルールの対処を行います。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Mod_Security 2系
  • OWASP Core Rule Set v4.1.5
  • ApacheのバーチャルファイルごとにModSecurityを制御

事象

OWASP Core Rule Set (CRS) を導入したModSecurityをブロックモード(SecRuleEngine On)に切り替え後、

Apacheのエラーログに、これまで見られなかった Execution error - PCRE limits exceeded (-47) というエラーが大量に記録されていることを発見しました。

  • エラー例(IPアドレスやホスト名は改変済み)
[Sat Jun 14 11:09:05.195039 2025] [security2:error] [pid 28306:tid 28306] [client AAA.BBB.CCC.DDD:59314] [client AAA.BBB.CCC.DDD] ModSecurity: Rule 73f4b9603e90 [id "951190"][file "/usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"][line "246"] - Execution error - PCRE limits exceeded (-47): (null). [hostname "hoge.example.com"] [uri "/path/to/page.html"] [unique_id "aE_NnHj4jZdbb2PH1-4O0QAAABc"]
[Sat Jun 14 11:09:05.195564 2025] [security2:error] [pid 28306:tid 28306] [client AAA.BBB.CCC.DDD:59314] [client AAA.BBB.CCC.DDD] ModSecurity: Rule 73f4b95f9e98 [id "951210"][file "/usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"][line "288"] - Execution error - PCRE limits exceeded (-47): (null). [hostname "hoge.example.com"] [uri "/path/to/page.html"] [unique_id "aE_NnHj4jZdbb2PH1-4O0QAAABc"]

このログから、SQLインジェクション系の情報漏洩を検知するRESPONSE-951-DATA-LEAKAGES-SQL.confの内容に沿ったものと特定。

cat /var/log/apache2/hoge/error.log |grep 951190 |wc -l

としたところ、数時間で2万件近いログを検知。

PCEリミットとは?

複雑な正規表現を、非常に大きなデータ(Webページなど)に対して実行すると、サーバーのCPUやメモリを大量に消費し、サービス拒否(DoS)攻撃に繋がる危険性があります。これを防ぐため、ModSecurityには処理の複雑さや再帰の深さに上限(リミット)が設けられています。

エラーの原因

今回のエラーは、サーバーが返信するHTMLページ(レスポンスボディ)の内容を、情報漏洩がないか確認するルールがスキャンしようとした際に、そのWebページの内容が非常に大きい、または複雑であったため、PCREの処理上限値を超えてしまったことが原因です。(筆者のサイトの長文が災いしています)

対処内容

この、処理上限値を超えてしまったことでエラーが発生したのですからmodsecurity.confSecPcreMatchLimitの値を大きくすると言うのが考えられる対処ではありますが、

運用しているサイトのvpsのリソースを鑑みて、より簡便な「原因となっている特定のルールのみの無効化」を行いました。

さっくりとした手順

  1. Apacheのバーチャルサイト設定(.confファイル)のバックアップを取ります。
  2. .confファイルの修正を行います。
  3. Apache再起動で修正を反映させます。
  4. ログを確認し、設定反映を確認します。

設定ファイルの修正

  • ファイルのバックアップ
sudo cp -ci /etc/apache2/sites-available/hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)

設定ファイルやバックアップディレクトリは自分の環境に合わせます。

  • バックアップ確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) /etc/apache2/sites-available/hoge.conf

エラー無く、差分も表示されていなければバックアップは成功です。

  • ファイル修正

/etc/apache2/sites-available/hoge.confを以下のように修正していきます。(要root権限)

# PCREリミット超過エラーを起こす、レスポンスボディスキャン系のルール群を無効化
SecRuleRemoveById 951190
SecRuleRemoveById 951210
SecRuleRemoveById 951220
SecRuleRemoveById 951250
  • ファイル修正確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) /etc/apache2/sites-available/hoge.conf
  • 差分例
+ # PCREリミット超過エラーを起こす、レスポンスボディスキャン系のルール群を無効化
+ SecRuleRemoveById 951190
+ SecRuleRemoveById 951210
+ SecRuleRemoveById 951220
+ SecRuleRemoveById 951250

設定ファイルの設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • 設定反映
sudo systemctl restart apache2.service
  • Apache稼働確認
systemctl status apache2.service

active(running)を確認します。

動作確認

対処後、ターミナルで

tail -f /var/log/apache2/hoge/error.log |grep "PCRE limits"

を実行し、しばらく観察します。

このエラーが表示されないことを確認し、処置が完了です。

gitによるmod-securrity core rule setのアップデート。

概要

こちらの方法で導入したMod-Security(WAF)。

この防御ルールであるOWASP Core Rule Setの更新を行います。

環境

  • Ubuntu 24.04
  • Apache 2.4
    • バーチャルサイトで個別設定
    • aptでインストールしているため
    • 設定ファイルは/etc/apache2/sites-available配下の.confファイル
    • サービス実行ユーザはwww-data
  • Mod Security ver.2系

注意点

アップデートにより

  • 追加されたルール
  • 削除されたルール
  • 変更された挙動

などがあるため、今までと同じ作業をしていたのにWAFがブロックした(あるいは今までブロックされていたアクセスがスルーした)などは可能性としてあります。

なので、

  1. ModSecurityを検知モードにして作業を実施する
  2. しばらく様子を見て有効化に戻す

という作業を取ります。そのため、WAFの防御が一度無効化される時間が発生します。

環境や予算が許すなら、インターネットに公開された別環境で試してからの方が良いでしょう。

→ テストが済んでいる状態であれば、本番環境で「ModSecurityをオフにする」の作業は不要になります。

さっくりとした手順

  1. 【事前準備】ModSecurityを検知モードにします。
  2. 【事前準備】ルールセットディレクトリのバックアップを行います。
  3. gitで最新リリースを確認します。
  4. OWASP Core Rule Setのアップデートを行います。
  5. Webサービスの再起動でアップデートを反映させます。
  6. 【事後作業】ModSecurityを有効化します。

【事前準備】ModSecurityを検知モードにします。

  • ディレクトリ移動
cd /etc/apache2/sites-available && pwd
  • .confファイルのバックアップ
sudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.yyyymmdd
  1. 設定ファイル(.conf)は自分の環境に合わせます。
  2. 任意のバックアップディレクトリを指定します。
  • .confファイルのバックアップ確認
diff -u /path/to/backup/directory/hoge.conf.yyyymmdd hoge.conf

差分が無いことを確認します。

通常、筆者は$(date +%Y%m%d)変数を用いてバックアップを行いますが、「検知モードでの試験」は日をまたぐこともあるため、この形式にしています。

  • .confファイルの編集

hoge.confファイルを管理者権限で修正。

SecRuleEngine On

から

SecRuleEngine DetectionOnly

に変更し、保存します。

  • ファイル修正確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf

以下の差分を確認します。

- SecRuleEngine On
+ SecRuleEngine DetectionOnly
  • 設定ファイル構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動前確認
systemctl status apache2.service

active(running)を確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service

※設定ファイルの修正のみのためreloadで十分ですが、念を入れてrestartにしています。(以下同じ)

  • Webサービス再起動後確認
systemctl status apache2.service

active(running)を確認します。

【事前準備】ルールセットディレクトリのバックアップを行います。

cd /usr/share/modsecurity-crs && pwd

これは、上記のリンク先で示した通り、ルールセットを/usr/share/modsecurity-crs/corerulesetに配置していた場合のディレクトリです。

必要に応じて自分の環境に合わせます。

  • ルールセットのディレクトリコピー
sudo cp -pir coreruleset /path/to/backup/directory/coreruleset.$(date +%Y%m%d)

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

  • ディレクトリコピー確認
ls -l /path/to/backup/directory/coreruleset.$(date +%Y%m%d)

ディレクトリ一式があることを確認します。

OWASP Core Rule Setのアップデート

  • ディレクトリ移動
cd /usr/share/modsecurity-crs/coreruleset && pwd
  • リモートリポジトリの確認
sudo git fetch origin
  • 最新バージョンとの差分確認
sudo git status

筆者環境で、以下のように表示されました。

ブランチ main

このブランチは 'origin/main' に比べて172コミット遅れています。fast-forwardすることができます。

  (use "git pull" to update your local branch)


Changes not staged for commit:

  (use "git add/rm <file>..." to update what will be committed)

  (use "git restore <file>..." to discard changes in working directory)

        deleted:    crs-setup.conf.example


no changes added to commit (use "git add" and/or "git commit -a") 

コミット内容が大幅に変わっているので、上述した「検知モードで様子見にする」が活きてきます。

  • gitによるアップデート
sudo git pull

これで、OWASP Core Rule Setが最新版に変更されました。

Webサービスの再起動でアップデートを反映させます。

  • Webサービス再起動前確認
systemctl status apache2.service

active(running)を確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動後確認
systemctl status apache2.service

active(running)を確認します。

その後、既存のWebシステムに問題が無いかを確認します。

tail -f /var/log/hoge/hoge_error.log

等として、通常の作業を行い

  1. 既存のサービスに異常は無いか?
  2. 新たな偽陽性は発生していないか?

等を確認し、それに応じて新たな偽陽性の除外などを行っていきます。

【事後作業】ModSecurityを有効化します。

アップデートの影響で既存サービスに問題が無いことが判明したら、再びModSecurityを有効化します。この例では、バックアップから.confファイルを切り戻します。

  • バーチャルサイト(.conf)ファイルのディレクトリに移動
cd /etc/apache2/sites-available && pwd
  • バックアップから切り戻し
sudo cp -pi /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf
  • Webサービス再起動前確認
systemctl status apache2.service

active(running)を確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動後確認
systemctl status apache2.service

active(running)を確認します。

その後、既存のWebシステムに問題が無いかを確認します。

有効化前に既存.confファイルを修正した場合

新たに偽陽性を追加した、既存のファイルを削除した、またはそれに伴う設定変更を行ったことにより、バックアップ前と.confファイルが異なるケースはあります。

その場合は、.confファイルの

SecRuleEngine DetectionOnly

SecRuleEngine On

と修正した後で以下の作業を行います。

  • 設定ファイル構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動前確認
systemctl status apache2.service

active(running)を確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動後確認
systemctl status apache2.service

active(running)を確認します。

update-motdでのメモリ監視。

UbuntuのWebサーバで、スワップの使いすぎによる再起動の判断を行うためのスクリプトを仕込みました。

スクリプト内容

#!/bin/bash
#
# メモリとSWAPの使用量を表示し、閾値を超えた場合に再起動を促す
#

# --- 設定 ---
# 再起動を促す警告を表示する閾値
# 両方の条件を満たした場合に警告が表示されます
readonly MEM_THRESHOLD=75  # 実メモリ使用率 (%)
readonly SWAP_THRESHOLD=10 # SWAP使用率 (%)

# --- 処理 ---

# freeコマンドの出力を取得 (-m オプションでMB単位)
free_output=$(free -m)

# メモリ情報を抽出・計算 (GB単位に変換して保持)
read mem_total_gb mem_used_gb mem_percent <<< $(echo "$free_output" | awk '
/^Mem:/ {
    total=$2;
    used=$3;
    if (total > 0) {
        percent=(used/total)*100;
    } else {
        percent=0;
    }
    printf "%.1f %.1f %.0f", total/1024, used/1024, percent;
}')

# SWAP情報を抽出・計算 (GB単位に変換して保持)
# SWAP領域が存在しない場合も考慮
if echo "$free_output" | grep -q '^Swap:'; then
    has_swap=true
    read swap_total_gb swap_used_gb swap_percent <<< $(echo "$free_output" | awk '
    /^Swap:/ {
        total=$2;
        used=$3;
        if (total > 0) {
            percent=(used/total)*100;
        } else {
            percent=0;
        }
        printf "%.1f %.1f %.0f", total/1024, used/1024, percent;
    }')
else
    has_swap=false
    swap_total_gb=0
    swap_used_gb=0
    swap_percent=0
fi


# --- 表示 ---

echo ""
# メモリとSWAPの使用率を整形して表示
# printfのフォーマットで表示幅を揃え、見やすくしています
printf "メモリ: %5.1f GB 中 %5.1f GB 使用 (%d%%)\n" "$mem_total_gb" "$mem_used_gb" "$mem_percent"

# SWAPの合計が0より大きい場合のみ表示
if (( $(echo "$swap_total_gb > 0" | bc -l) )); then
    printf "SWAP  : %5.1f GB 中 %5.1f GB 使用 (%d%%)\n" "$swap_total_gb" "$swap_used_gb" "$swap_percent"
fi

# 閾値を超えているかチェックし、条件を満たせば警告を表示
if [ "$has_swap" = true ] && [ "$mem_percent" -ge "$MEM_THRESHOLD" ] && [ "$swap_percent" -ge "$SWAP_THRESHOLD" ]; then
    echo ""
    echo "############################################################"
    echo "#  メモリ量の枯渇                                            #"
    echo "#  パフォーマンス低下を避けるため、再起動を検討してください。#"
    echo "############################################################"
fi

このスクリプトを

sudo chmod +x 

`/etc/update-motd.d/50-memory-check`

として仕込みます。

起動時にメモリ量やスワップ量を検査。

警告が出れば、再起動の検討やプロセスの見直しなどを行うことができます。

Redmine5.1.4→Redmine5.1.8へのアップデート手順。

公開用Redmine

https://atelier.reisalin.com

のバージョンを5.1.4→5.1.8にアップデートしたときのメモです。

環境

  • Ubuntu 24.04
  • 動かしていたRedmine:5.1.4
  • アップデートしたRedmie:5.1.8
  • Apache 2.4 / mod-passangerでRubyアプリを使用(Ruby 3.2系)
  • MySQL 8.0.3

作業に備えての前提

  • Webサービスを止めるため、ユーザアクセスができない状況が発生します。
  • 利害関係者への事前周知・作業時間の確保は十分に行ってください。(慣れれば20分程度で完了しますが、1時間は取っておいた方が無難です)
  • また、筆者環境はfiles配下をクラウドストレージにマウントしています。手順は自身の環境に合わせてください。

さっくりとはいかない手順

  1. (強く推奨)システム全体のバックアップ
  2. DBのバックアップ
  3. redmineのディレクトリを一度mvでリネームしてバックアップ。
  4. apache停止
  5. ディレクトリを再作成し、新しい空のRedmineを作る。
  6. themesとpluginを再配置。filesのシンボリックリンクを貼り替える。
  7. themesとpluginを再配置した状態でDBマイグレーション。
  8. apache再開
  9. バージョンアップ確認

システム全体のバックアップ(スナップショット)

  • AWS
  • 仮想サーバ

などで動かしている場合は、この段階でシステム全体のバックアップ(スナップショット)を取ることを強く推奨します。

mysqlによるDBバックアップ

  • バックアップディレクトリに移動
cd /hoge && pwd

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

  • mysqldump
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql

DB名やDBユーザは自分の環境に合わせます。

  • mysqldump確認
view redmine_backup.$(date +%Y%m%d).sql

DBが平文で読めることを確認します。

データ退避

  • ディレクトリ移動
cd /var/lib && pwd

Redmineが格納されているディレクトリの親ディレクトリに移動します。(筆者環境は/home/www-data)

  • Redmine全体ディレクトリ確認
ls -ld redmine

退避対象のディレクトリがあることを確認します。ディレクトリ名は自分の環境に合わせます。

  • Redmine待避
sudo mv redmine redmine_$(date +%Y%m%d)
  • Redmine待避確認
ls -ld redmine_$(date +%Y%m%d)

ディレクトリがあることを確認します。

apache停止

念のため、apacheを停止します。

  • apache停止前確認
systemctl status apache2.service

active(running)を確認します。

  • apache停止
sudo systemctl stop apache2.service
  • apache停止確認
systemctl status apache2.service

inactive(dead)を確認します。

Redmineプログラムの配置

  • Redmineのディレクトリ作成
sudo mkdir /var/lib/redmine
  • Redmineディレクトリの権限変更
sudo chown -R www-data:www-data /var/lib/redmine
  • Redmineディレクトリの作成確認
ls -ld redmine

ディレクトリがあることと、所有者がwww-dataであることを確認します。

  • ソースダウンロード
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.1-stable /var/lib/redmine

5.1系の最新安定版をダウンロードします。

退避させたディレクトリからconfigファイルコピー

  • database.ymlコピー
sudo -u www-data cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/database.yml /var/lib/redmine/config/database.yml
  • database.ymlコピー確認 
cat /var/lib/redmine/config/database.yml

待避したファイルの内容であることを確認します。

  • configuration.yml コピー
sudo -u www-data cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/configuration.yml /var/lib/redmine/config/configuration.yml
  • configuration.ymlコピー確認
cat /var/lib/redmine/config/configuration.yml

待避したファイルの内容であることを確認します。

退避したディレクトリからデータを再配置

  • プラグイン一式のコピー
sudo -u www-data cp -pir  /var/lib/redmine_$(date +%Y%m%d)/plugins/* /var/lib/redmine/plugins/

移行元・移行先は自分の環境に合わせます。

  • テーマ一式のコピー
sudo -u www-data cp -pir /var/lib/redmine_$(date +%Y%m%d)/public/themes/* /var/lib/redmine/public/themes/

シンボリックリンク貼り替え

これは筆者の環境がlogディレクトリとfilesディレクトリを別の場所(wasabiクラウドストレージ)にリンクを張っているための措置です。
それ以外の場合は上述した /var/lib/redmine_$(date +%Y%m%d)からfilesやlogをコピーして下さい。

  • Redmineルートディレクトリに移動
cd /var/lib/redmine && pwd

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

  • filesディレクトリ削除
sudo rm -rf files
  • ログディレクトリ削除
sudo rm -rf log
  • filesディレクトリにシンボリックリンクを張る
sudo ln -sf /mnt/wasabi/redmine/files files

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

  • filesシンボリックリンクの所有者変更
sudo chown -h www-data:www-data files
  • filesシンボリックリンク確認
ls -l files
  1. filesがシンボリックリンクになっていること
  2. 所有者がwww-dataであること

を確認します。

  • logディレクトリにシンボリックリンクを張る
sudo ln -sf /var/log/redmine log
  • logシンボリックリンクの所有者変更
sudo chown -h www-data:www-data log
  • logシンボリックリンク確認
ls -l log
  1. logがシンボリックリンクになっていること
  2. 所有者がwww-dataであること

を確認します。

DBマイグレーション

  • Redmineルートディレクトリに移動
cd /var/lib/redmine

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

  • bundle インストール
sudo -u www-data bundle install --without development test --path vendor/bundle
  • シークレットトークン発行
sudo -u www-data bundle exec rake generate_secret_token
  • DBマイグレーション(本体)
sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate
  • DBマイグレーション(プラグイン)
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production
  • キャッシュクリア
sudo -u www-data RAILS_ENV=production bundle exec rake tmp:cache:clear
  • セッションクリア
sudo -u www-data RAILS_ENV=production bundle exec rake tmp:sessions:clear

apache再起動

  • apache再起動前確認
systemctl status apache2.service

inactive(dead)を確認します。

  • apache再起動
sudo systemctl start apache2.service
  • apache再起動確認
systemctl status apache2.service

active(running)を確認します。

動作確認

この状態でRedmineに管理者権限でログインします。手順通りなら

  • テーマ
  • 添付ファイル
  • プラグイン
  • チケット一覧

などが有効に動いていて、正常に稼働します。

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

  • 待避したファイルの削除/バックアップ

/var/lib/redmine_$(date +%Y%m%d)一式を削除、または任意の方法でバックアップします。

トラブルシューティング

bundle install が終わらない

Installing... の表示で止まっているように見えても、実際にはCPUを消費して動作していることがある(ネイティブ拡張機能のコンパイル)。topコマンドでcc1plusなどのプロセスが動いていないか確認する。

"Something went wrong" エラー

Redmineのアプリケーション起動エラー。原因はログに記録されている。

  1. まず /var/lib/redmine/log/production.log を確認する。
  2. 上記にログがなければ、/var/log/apache2/error.log を確認する。

ログから見る主な原因の例

  • プラグインの非互換: Redmine本体の機能とプラグインが競合している場合がある (Overwriting existing method 警告など)。
  • gemのバージョン競合: Ruby本体に付属のgemと、プラグインが要求するgemのバージョンが異なると起動に失敗することがある (base64の競合など)。この場合は、Gemfileでバージョンを明示的に指定するなどの対策が必要。

Redmineにfavicon(サイトアイコン)を設定。

概要

こちらのように、サイトアイコン(favicon)をRedmineに設定するメモです。

環境

  • Ubuntu 24.04
  • Redmine 5.1
  • Apache 2.4
    • サービス実行ユーザはデフォルトのwww-data

で実施しています。(Redmine 6.xはディレクトリ構造が異なります)

準備

  1. ファイルfavicon.pngfavicon.icoを用意します。
  2. このファイルをRedmineサーバに転送します。
  3. ファイルの所有者をRedmine実行ユーザに変更します。sudo chown www-data:www-data favicon.png など

手順

faviconファイルの配置

  • faviconディレクトリの作成
cd /path/to/redmine/root/directory/public/theme/theme_name && pwd

ルートディレクトリやテーマディレクトリは自分の環境に合わせます。 (筆者環境/home/www-data/redmine/public/themes/redmine_theme_kodomo)

sudo -u www-data mkdir favicon && cd favicon && pwd

faviconディレクトリにいることを確認します。

  • 転送したファイルの配置
sudo -u cp -pi /hoge/favicon.png ./

上記、転送した際のディレクトリを指定します。

Redmineサイトの設定

  1. Redmineのサイトに管理者権限でログインします。
  2. 管理>設定>表示に移動します。
    3.「Gravatarのアイコンを使用する」にチェックを入れて保存します。

この後、ブラウザをリロードしてアイコンが変わっていることを確認できれば設定完了です。

アクセスログを圧迫するクローラーへの対処。(Apache 2.4と外部ファイル連携によるクローラーのアクセス遮断とログ軽減)

はじめに

Webサイトを外部に公開していると、非常に厄介なクローラーがアクセスログに蓄積。これらは

  • 超高速
  • 超高頻度

で行われるため、本当に必要なアクセスログ(どの検索サイトから来たか、攻撃の兆候となる不審な点はないか)がつかみにくくなっています。

これを解決するため、以下の措置を執りました。

  1. クローラーや悪質なボットのアクセス拒否
  2. それらをアクセスログにすら残さず、きちんとしたアクセスログを追いやすくする

(※こちらの記事を更に強力に推し進めたものです)

環境

  • Ubuntu 24.04
  • Apache 2.4
    • setenvifモジュール
    • authz_core モジュール
    • (特段の理由がない限り、上記2つは標準で組み込まれていることが多いです。)
    • ない場合はsudo a2enmod setenvif等とした後、sudo systemctl restart apache2.serviceとしてモジュールを組み込みます。
  • また、バーチャルサイトによる複数ドメインにも対応しています。

さっくりとした手順

  1. クローラーのリストファイルを作成します。
  2. Apacheバーチャルサイトの.confファイルを修正します。
  3. 設定を反映後、状況を確認します。

クローラーのリストファイルを作成

  • /etc/apache2/sites-enabled/il-vento-d-oro.txt

としてファイルを作成。(ファイル名や格納場所は自分の環境に合わせてください)

SetEnvIfNoCase User-Agent "facebookexternalhit/1\.1" bad_bot dontlog
SetEnvIfNoCase User-Agent "SemrushBot/7~bl" bad_bot dontlog
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot dontlog
SetEnvIfNoCase User-Agent "DotBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Baiduspider" bad_bot dontlog
SetEnvIfNoCase User-Agent "YandexBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Sogou web spider" bad_bot dontlog
SetEnvIfNoCase User-Agent "Exabot" bad_bot dontlog
SetEnvIfNoCase User-Agent "MegaIndex\.ru" bad_bot dontlog
SetEnvIfNoCase User-Agent "SeznamBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Bytespider" bad_bot dontlog
SetEnvIfNoCase User-Agent "DataForSeoBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "serpstatbot" bad_bot dontlog
SetEnvIfNoCase User-Agent "SeekportBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "index\.community crawler" bad_bot dontlog
SetEnvIfNoCase User-Agent "PetalBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "BacklinksExtendedBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "meta-externalagent/1\.1" bad_bot dontlog
SetEnvIfNoCase User-Agent "ICC-Crawler" bad_bot dontlog
SetEnvIfNoCase User-Agent "bingbot" bad_bot dontlog
SetEnvIfNoCase User-Agent "msnbot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Applebot" bad_bot dontlog
SetEnvIfNoCase User-Agent "DuckDuckBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Majestic-SEO" bad_bot dontlog
SetEnvIfNoCase User-Agent "cognitiveSEO" bad_bot dontlog
SetEnvIfNoCase User-Agent "archive\.org_bot" bad_bot dontlog
SetEnvIfNoCase User-Agent "CCBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "^$" bad_bot dontlog
SetEnvIfNoCase User-Agent "Custom-AsyncHttpClient" bad_bot dontlog
SetEnvIfNoCase User-Agent "ImagesiftBot" bad_bot dontlog

上記は、サイトを運営していく中で

  • robots.txtを無視し
  • あらゆるページにアクセスし
  • 下手をすれば帯域を阻害する

ものを集めています。"^$"は、エージェントを偽装するスクレイピングへの措置です。

この、

  • SetEnvIfNoCase User-Agent "エージェント名"
  • bad_bot
  • dontlog

と、続けて書くことで、厄介なボットへの対処とアクセスログへの無視を決めます。

もちろん、これらのbotが必要というのであれば省いていきます。

apacheの設定ファイルを編集

  • 設定ファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)

設定ファイルは自分の環境に合わせます。
任意のバックアップディレクトリを指定します。

  • diffによるバックアップ確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf

差分(エラー)が無いことを確認します。

  • ファイルの修正

以下のように修正していきます。(要管理者権限)

例)

<VirtualHost *:443>
    # ServerName、ErrorLogは自分の環境に合わせます
    ServerName hoge.example.com
    ErrorLog /var/log/apache2/hoge/error.log
    # 1)Robots.txtをすり抜ける悪質なbotのリスト(先ほど作成したリストファイルのパスをフルパスで指定) 
    Include /etc/apache2/sites-enabled/il-vento-d-oro.txt
    # dontlogを付与したエージェントはアクセスログに記録させません
    # CustomLogは自分の環境に合わせます
    CustomLog /var/log/apache2/hoge/access.log combined env=!dontlog

# DocumentRootは自分の環境に合わせます。
DocumentRoot /var/www/html/hoge

# Directoryディレクティブは自分の環境に合わせます。
    <Directory /var/www/html/hoge>
        Options -MultiViews
        AllowOverride All
     <RequireAll>
      # 上記リストに従い、"bad_bot"変数がセットされているクローラーのアクセスを拒否します
      Require not env bad_bot
      # それ以外は許可
      Require all granted
     </RequireAll>
    </Directory>

# Require notでForbiddenにすると、クローラーは「拒否されただけで本体はある」と判断し、Webアクセスを繰り返すパターンがあるため、403に404を返す設定を付け加えます
# Directory
ErrorDocument 403 "Not Found"
  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf
  • 上記、加えた設定が+になっていること
  • ディレクティブの重複や閉じ忘れがないこと

を改めて確認します。

設定反映と確認

  • 別のセッションでアクセスログを確認
tail -f /var/log/apache2/hoge/access.log

※この段階ではクローラーからのアクセスが多々来ています

  • 構文確認
sudo apache2ctl configtest

Syntax Okを確認します

  • Apache再起動前確認
systemctl status apache2.service

active(running)を確認します

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動後確認
systemctl status apache2.service

active(running)を確認します

この段階で、上記、

tail -f /var/log/apache2/hoge/access.log

が止まっていれば設定は成功です。

  • 今までと同じようにアクセスができること
  • 既存のWebサイトに異常が無いこと
  • その場合のアクセスログが表示されること

を確認し、作業は成功です。

作業を切り戻す場合

何か不具合が起きた場合は、バックアップしていた.confを切り戻します。

  • 差分確認
sudo cp -pi /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf

作業時に指定したバックアップディレクトリです。

  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf

差分が ない ことを確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax Okを確認します

  • Apache再起動前確認
systemctl status apache2.service

active(running)を確認します

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動後確認
systemctl status apache2.service

active(running)を確認します

設定前になっていることを確認します。

Nextcloud、アップロードしたファイルを一定期間保持後に削除する方法。

ファイルサーバとしても使えるNextcloud。

しかし、サーバの容量によっては無制限にファイルを増やせるわけではありません。

今回、個人用に外部環境に構築したNextcloudは

「Talk機能によるスマートフォンからの高速メモ」

という尖った運用を行うために、ファイルサーバの利用は限定的として

  • アップロードしたファイルは猶予期間を設ける
  • 猶予期間を過ぎたら問答無用でファイルを削除する

設定を行いました。

環境

  • Ubuntu 24.04
  • Nextcloud 31.0.5
  • Apache 2.4
  • MySQL 8.3
  • PHP 8.3

構築については以下の通りです。

https://barrel.reisalin.com/books/nextcloud/page/ubuntu-2404nextcloud

準備

以下のプラグイン(アプリ)をそれぞれインストールします。Nextcloud 31.0.5で動くことを確認しています。

手順

Nextcloudに管理者権限でログインします。

付与するタグを作成します。

管理者設定>基本設定に進みます。

「タグの作成または編集」の項目があるので、

  • コラボレーションタグ
  • タグの名前:任意(30日で消去など、分かりやすい名前にします)
  • タグのレベル:不可視

にして、「作成」をクリックします。

ファイルアップロード時にタグを付与するようにします。

管理者設定>Flowに進みます。

上の方にある緑のボタン「自動タグ付け」の「新しいフローを追加」をクリックします。

以下のように設定します。

  • いつ
  • ファイルが変更されています(これは変更不可)
  • かつ
  • 「ファイルシステムタグ」
  • 「に次のタグがついていない」
  • 先ほど設定したタグ(30日で消去)

設定後、作成→アクティブ化。

一定期間が過ぎたらファイルが消去されるように設定します。

管理者設定>Flowの

「ファイル保持と自動削除」で以下のように設定します。

  • タグを選択
  • 先ほど設定した「30日で消去」を選択。
  • 保持期間(時間単位)
    • 30日
  • いつから
    • 作成日から

として作成。

タグ付け確認

Nextcloudのファイルアップロードで、任意のファイルをアップロードします。(要管理者権限)

ファイルの項目に、自動的に「30日で消去」が付与されていたら設定は完了です。

Page 1 of 28

Powered by WordPress & Theme by Anders Norén