タグ: Ubuntu Page 1 of 21

BookStackのフォントをサーバ内のフリーフォントに変更。

BookStackの表示フォントを、サーバー内に配置したカスタムフォント(kiloji)に変更したときのメモです。

これには2つの目的があります。

  • 見た目を変えて独自性を出す。
  • サーバ内にあるフォントを指定することで読み込み速度を大幅に上げる。

環境

  • BookStack v25.07.2
  • PHP 8.3
  • MySQL 8
  • Apache 2.4
    • Apacheの実行ユーザはwww-data

さっくりとした手順

  1. カスタムフォントを用意します。
  2. BookStackのpublicフォルダにフォントファイルを格納します。
  3. カスタムCSSを設定します。
  4. 設定を確認します。

カスタムフォントを用意します。

今回用いたのは手書きボールペンのようなフォント、きろ字。(フリーで使えるフォントです)

公式サイトからフォントファイル一式をダウンロードします。

使うフォントファイルは

  • kiroji.ttf
  • kiroji.woff
  • kiroji.woff2
  • kiroji_b.ttf
  • kiroji_b.woff
  • kiroji_b.woff2

となっています。ダウンロード後、サーバの適当な位置に格納します。

BookStackのファイルにフォントを格納します。

  • BookStackのpublicディレクトリに移動
cd /path/to/bookstack/public && pwd

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

  • fontsディレクトリを作成します。
sudo -u www-data mkdir -p fonts/kiloji
  • フォントファイルの格納
sudo -u www-data cp -pi /path/to/fonts/directory/kiroji*woff2 /path/to/bookstack/public/fonts/kiloji/
  • フォントファイルの格納確認
ls -l /path/to/bookstack/public/fonts/kiloji/

追加したフォントがあることを確認します。

カスタムCSSを修正します。

ブラウザでBookStackにアクセスし、管理者権限でログインします。

設定>カスタマイズに移動します。

「カスタムheadタグ」のテキストボックスに、以下のCSSコードを貼り付けます。

<style>
/* --- フォントの定義 --- */

/* 1. 通常の太さのフォントを 'kiloji' として定義 */
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: normal;
  src: url('/fonts/kiloji/kiloji.woff2') format('woff2'),
       url('/fonts/kiloji/kiloji.woff') format('woff'),
       url('/fonts/kiloji/kiloji.ttf') format('truetype');
}

/* 2. 太字用のフォントを、同じ 'kiloji' という名前で定義 */
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: bold;
  src: url('/fonts/kiloji/kiloji_b.woff2') format('woff2'),
       url('/fonts/kiloji/kiloji_b.woff') format('woff'),
       url('/fonts/kiloji/kiloji_b.ttf') format('truetype');
}

/* --- フォントの適用 --- */

/* 1. ページ全体の基準となる文字サイズとフォントを指定 */
body {
  font-family: 'kiloji', sans-serif !important;
  font-size: 16px; /* ← この数値で大きさを調整 */
}

/* 2. 見出しやナビゲーションなど、個別にフォントが指定されている箇所にも適用 */
h1, h2, h3, h4, h5, h6, .btn, a, input, textarea,
.page-nav, .sidebar-page-nav a, .tri-layout-container, .chapter-contents, .book-contents a {
  font-family: 'kiloji', sans-serif !important;
}
</style>

適用後、ページ下部の「設定を保存」ボタンをクリックします。

設定変更確認

BookStackにアクセスし、指定したフォントに替わっていたら設定変更です。

補足:最初の試行(一部のみフォントが変わったCSS)

以下は、bodyタグにのみフォントを指定した最初のコードです。見出しなど、個別にCSSが設定されている要素には適用されませんでした。

<style>
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: normal; 
  src: url('/fonts/kiloji/kiloji.woff2') format('woff2');
}
@font-face {
  font-family: 'kiloji';
  font-style: normal;
  font-weight: bold; 
  src: url('/fonts/kiloji/kiloji_b.woff2') format('woff2');
}
body {
  font-family: 'kiloji', sans-serif !important;
}
</style>

Ubuntu24.04にGrowi2.7.3.xをインストール

概要

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

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

備考

  • v7系は利用するMongoDBの関係上、CPUを選びます。(Celeron系や古いアーキテクチャでは動きません)
  • v7.3.0より、Elasticsearchのバージョンは従来のv8ではなくv9を必要とします。
    • Elasticsearchを用いる方は注意ください。

環境

  • Ubuntu 24.04
  • Apache 2.4

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

前提

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

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

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

手順

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

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

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

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

Node.js環境の構築(nvm, npm, pnpm)

Growiの実行にはNode.jsが必要です。ここでは、バージョン管理を容易にするためnvm(Node Version Manager)を使ってインストールします。

メンテナンスユーザーでnvmをインストール

rootではなく、作成したメンテナンスユーザーで実行します。

  • メンテナンスユーザーでログインしていることを確認
whoami
  • nvmインストールスクリプトを実行
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

このスクリプトは、~/.bashrcに必要な設定を自動で追記してくれます。

nvm環境を有効化

設定を現在のセッションに反映させるため、以下のコマンドを実行するか、一度ログアウトして再ログインしてください。

source ~/.bashrc

nvm --versionでバージョンが表示されれば成功です。

nvm経由でNode.jsと各種パッケージをインストール

Growiが必要とするバージョンのNode.jsと、npm, pnpmをインストールします。

  • Node.js v20.19.2 をインストール
nvm install v20.19.2
  • 使用するバージョンとして設定
nvm use v20.19.2
nvm alias default v20.19.2
  • npmをv11.4.0にアップデート
npm install -g npm@11.4.0
  • pnpmをインストール
npm install -g pnpm
rootユーザーにもnvm環境を適用(systemd連携のため)

Growiをサービスとして自動起動させるgrowi-start.shスクリプトは、root権限で実行されるsystemdから呼び出されます。そのため、rootユーザーもnvmの場所を知っている必要があります。

以下のコマンドで、メンテナンスユーザー用にインストールしたnvmへのシンボリックリンクを、rootのホームディレクトリに作成します。

sudo ln -sf /home/【maintenance_user】/.nvm /root/.nvm

【】内は自分のLinuxアカウント(メンテナンスユーザー名)に置き換えてください

これにより、rootで実行されるスクリプトも、メンテナンスユーザーと同じNode.js環境を参照できるようになります。

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をインストールします。

※v7.3.0よりElasticsearchのv9を用いるようになっています。

  • 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/9.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-9.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-icu インストール
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/mongod.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/growilabs/growi /home/www-data/growi

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

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

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

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

2025/09/17時点での最新リリースです

  • 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 headers
  • 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://設定したドメイン でアクセスします。

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

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

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

Growi v7.1.x・v.7.2.x→v7.3.0へのアップデート

概要

Growi 7.1/7.2からv7.3.0Growiアップグレードの手順です。
Elasticsearchの全文検索を利用している方は「Elasticsearchのバージョンアップ」を伴う作業になります。

前提

  • 既にgrowi v7.1.x/v7.2.xをインストールしていること。
  • 管理画面トップやトップページ右下からバージョンが7.1.xまたは7.2.xであることを再確認します。
  • systemdによってサービス化されていること。
  • 具体的な手順はhttps://atelier.reisalin.com/projects/zettel/knowledgebase/articles/105
  • 最新版や安定版がリリースされていることを以下のサイトで確認していること。
  • https://github.com/growilabs/growi/releases
  • ※設定ファイルの変更やパッケージインストールの変更、nodeのバージョンアップの必要等があれば、それも事前に済ませます。

さっくりはならない手順

  1. Growiをメンテナンスモードにします。
  2. Growi・Elasticsearchのサービスを停止します。
  3. バックアップを取ります。
  4. gitコマンドで最新版をcheckoutします。
  5. アップグレードを行います。
  6. Elasticsearch・Growiのサービスを再開します。
  7. Growiのメンテナンスモードを解除します。
  8. アップグレードされたことを確認します。

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

  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
  • サービス停止確認
systemctl status elasticsearch.service

inactive(dead)を確認します。

  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status growi.service

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)

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

リポジトリ設定ファイル名をv9用に変更

Elasticsearchのバージョンを指定するリポジトリをv9に変更します。

  • 現行のリポジトリリストをバックアップ
sudo cp -pi /etc/apt/sources.list.d/elastic-8.x.list /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d)
  • リポジトリリストのバックアップ確認
diff -u /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d) /etc/apt/sources.list.d/elastic-8.x.list
  • リポジトリリストの名前変更
sudo mv /etc/apt/sources.list.d/elastic-8.x.list /etc/apt/sources.list.d/elastic-9.x.list
  • リポジトリリストの名前変更確認
ls -l /etc/apt/sources.list.d/elastic-9.x.list

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

sedコマンドでファイル内の参照先を8.xから9.xに書き換え

sudo sed -i 's/8.x/9.x/g' /etc/apt/sources.list.d/elastic-9.x.list

Elasticsearchのアップグレード

  • パッケージ全体のバックアップ
sudo aptitude update

好みでaptitudeを用いています。必要に応じてaptを用いてください。

  • Elasticsearchのアップグレード
sudo aptitude upgrade elasticsearch

※ Growiインストール時、/etc/elasticsearch/jvm.optionsファイルなどの設定変更を行っているため、アップグレード時の設定ファイルを残すかどうかの確認では、必ずN(残す)を選択します。

  • プラグインのアンインストール

Growiに必要なElasticsearchのプラグインは自動更新されません。この処置を執らないとせっかくアップグレードしたのに起動しないという事態が発生します。

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
  • プラグインの再インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji

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 【バージョン】

リリースタグは再確認しましょう。

  • pnpm install
sudo pnpm i
  • ビルド
sudo npm run app:build

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • サービス開始確認
systemctl status elasticsearch.service

active(running)を確認します。

  • バージョンアップ確認
curl -X GET "localhost:9200"

"number" : "9.1.3",など、9系にアップグレードされていることを確認します。

  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス停止確認
systemctl status growi.service

active(running)を確認します。

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

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

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

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

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

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

Growi v7.3.0へのバージョンアップに伴う全文検索負荷への対応。(Elasticsearchのバージョンアップ)

Growi をv7.2.10→v7.3.0へとアップグレード後、全文検索ができなくなったので、その対処方法をメモに残します。

環境

  • Growi v7.3.0
    • systemdによってサービス化
  • ElasticSearch v8.19.3
  • Ubuntu 24.04
  • MongoDB v6.0.26
  • node v20.19.2
  • Apache 2.4によるリバースプロキシ

エラー内容

Growiの管理>全文検索管理で以下のエラーが出ました。

Accept version must be either version 8 or 7, but found 9

エラーの原因

Growi v7.3.0のリリースノートで確認したところ、このバージョンからElasticsearch v9がサポート(必須化)されたことが判明しました。

support: Elasticsearch v9 (#10127)

  • Growi(クライアント側): v9形式でリクエストを送信
  • 既存環境(サーバー側): v8.19.3であったため、v9形式のリクエストを拒否

このバージョンの不一致が原因で、検索機能が停止していたと判明。対処を行います。

エラーを解決した手段

Elasticsearchをv9.1.3にバージョンアップしたことで解決しました。

手段によるサーバへの影響

「Elasticsearchバージョンアップ」です。他にこれを使うアプリが同一サーバ上にある場合、その影響を十分に確認ください。

対処方法のさっくりとした手順

  1. Elasticsearch/Growiを停止します。
  2. Elasticsearchのデータディレクトリのバックアップを行います。
  3. Elasticsearchのリポジトリをv9に併せます。
  4. Elasticsearchのバージョンアップを行います。
  5. Elasticsearchのプラグインのアンインストール/インストールを行います。
  6. Elasticsearch/Growiを起動します。
  7. エラーの解消を確認します。

ElasticsearchとGrowiの停止

  • Elasticsearchサービス停止
sudo systemctl stop elasticsearch.service
  • サービス停止確認
systemctl status elasticsearch.service

inactive(dead)を確認します。

  • Growiサービス停止
sudo systemctl stop growi.service
  • サービス停止確認
systemctl status growi.service

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)

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

リポジトリ設定ファイル名をv9用に変更

Elasticsearchのバージョンを指定するリポジトリをv9に変更します。

  • 現行のリポジトリリストをバックアップ
sudo cp -pi /etc/apt/sources.list.d/elastic-8.x.list /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d)
  • リポジトリリストのバックアップ確認
diff -u /path/to/backup/dir/elastic-8.x.list.$(date +%Y%m%d) /etc/apt/sources.list.d/elastic-8.x.list
  • リポジトリリストの名前変更
sudo mv /etc/apt/sources.list.d/elastic-8.x.list /etc/apt/sources.list.d/elastic-9.x.list
  • リポジトリリストの名前変更確認
ls -l /etc/apt/sources.list.d/elastic-9.x.list

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

sedコマンドでファイル内の参照先を8.xから9.xに書き換え

sudo sed -i 's/8.x/9.x/g' /etc/apt/sources.list.d/elastic-9.x.list

Elasticsearchのアップグレード

  • パッケージ全体のバックアップ
sudo aptitude update

好みでaptitudeを用いています。必要に応じてaptを用いてください。

  • Elasticsearchのアップグレード
sudo aptitude upgrade elasticsearch

※ Growiインストール時、/etc/elasticsearch/jvm.optionsファイルなどの設定変更を行っているため、アップグレード時の設定ファイルを残すかどうかの確認では、必ずN(残す)を選択します。

  • プラグインのアンインストール

Growiに必要なElasticsearchのプラグインは自動更新されません。この処置を執らないとせっかくアップグレードしたのに起動しないという事態が発生します。

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
  • プラグインの再インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji

ElasticsearchとGrowiの再開

  • Elasticsearchサービス開始
sudo systemctl restart elasticsearch.service
  • サービス開始確認
systemctl status elasticsearch.service

active(running)を確認します。

  • バージョンアップ確認
curl -X GET "localhost:9200"

"number" : "9.1.3",など、9系にアップグレードされていることを確認します。

  • Growiサービス開始
sudo systemctl restart growi.service
  • サービス停止確認
systemctl status growi.service

active(running)を確認します。

動作確認

  1. Growiに管理者権限でログインします。
  2. 管理画面>全文検索管理に進みます。
  3. インデックスの再構築を実行し、エラーが発生せず、正常に完了することを確認します。

その後、Growi上でキーワード検索を行い、検索結果が正しく表示されることを確認しました。

Growiのリポジトリ変更に伴う対応。

Growiのリポジトリが

https://github.com/weseek/growi

から

https://github.com/growilabs/growi

に移行したというTwitter(現X)の投稿がありました。今後のサポートなどを踏まえ、今利用しているGrowiのリポジトリの大本を変えます。

環境

  • Ubuntu 24.04
  • Growi v7.2.10
    • Growiの実行ユーザはroot

さっくりとした手順

  1. 現在のリポジトリを確認します。
  2. リポジトリのURLをgitコマンドで変更します。
  3. リポジトリの変更を確認します。

Growiのディレクトリに移動

cd /path/to/growi && pwd

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

gitの参照リポジトリを確認

  • gitコマンドによる確認
sudo  git remote -v
  • 参照結果
origin  https://github.com/weseek/growi (fetch)
origin  https://github.com/weseek/growi (push)

上記を確認。

gitコマンドによるリポジトリ変更

  • リポジトリ変更
sudo git remote set-url origin https://github.com/growilabs/growi.git

gitの参照リポジトリの変更確認

  • gitコマンドによる確認
sudo  git remote -v
  • 参照結果
origin  https://github.com/growilabs/growi.git (fetch)
origin  https://github.com/growilabs/growi.git (push)
  • 最新の履歴確認
sudo git fetch origin
  • ローカルとリモートの差分確認
sudo git status

Your branch is behind 'origin/main' by X commits...
(あなたのブランチは、リモートよりX個のコミット分遅れています)
のように表示されれば、新しいgrowilabsリポジトリへの接続は成功しており、そこに新しい更新が存在することを確認できます。

なお、筆者は別環境で「リポジトリ変更後、新しいバージョン(v7.2.9→v7.2.10)へのバージョンアップを、新しいリポジトリを介して行えたことを補足しておきます。

Ubuntu24.04にPiwigoインストール。(PHP-FPM対応版)

概要

画像管理に特化したオープンソースのフォトギャラリー「Piwigo」。Ubuntu24.04での構築メモです。

前提/環境

  • Ubuntu 24.04の基本的な設定が完了している。
  • Apache, MySQL, PHP-FPMがインストール済みである。
    • PHP及びPHP-FPMは8.3
    • Apacheの実行ユーザはwww-data
  • Piwigoを公開するドメイン名と、対応するSSL証明書が用意されている。

さっくりとした手順

  1. データベースの作成: Piwigoが使用するMySQLデータベースとユーザーを作成します。
  2. PHP拡張機能の確認: Piwigoの動作に必要なPHP拡張機能がインストールされているか確認します。
  3. Piwigoの配置: プログラム本体をサーバーに配置します。
  4. Apacheの設定: ApacheがPiwigoを正しく表示できるように設定します。
  5. Webインストーラーの実行: ブラウザから初期設定を完了させます。

データベースの作成

  • MySQLログイン
sudo mysql -u root -p
  • DB作成
CREATE DATABASE piwigo CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  • ユーザー作成と権限付与(【】内は強固なパスワードに置き換えてください)
CREATE USER 'piwigo'@'localhost' IDENTIFIED BY '【YOUR_STRONG_PASSWORD】';
GRANT ALL PRIVILEGES ON piwigo.* TO 'piwigo'@'localhost';
FLUSH PRIVILEGES;
EXIT;
  • DB作成確認
mysql -u piwigo -p

先ほど作成したDBユーザです。

SHOW DATABASES;

作成したDBが表示されることを確認します。

EXIT

確認後、MySQLコンソールから抜けます。

PHP拡張機能の確認・インストール

Piwigoは、画像の処理のためにgdimagemagickといったPHPの拡張機能を必要とします。
これらがインストールされているか確認します。(ない場合は以下の手順でインストール)

  • 既存のPHP拡張機能で不足しているものをインストールする例
sudo aptitude install php8.3-gd php8.3-imagick php8.3-mysql

筆者の好みに合わせてaptitudeを用いています。必要に応じてaptに読み替えます。

Piwigoの配置

  • Web公開用ディレクトリに移動
cd /var/www/html && pwd

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

  • git cloneによる配置
sudo -u www-data git clone https://github.com/Piwigo/Piwigo.git piwigo

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

Apacheの設定

  • ログディレクトリの作成
sudo mkdir -p /var/log/piwigo

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

  • ディレクトリの権限変更
sudo chown -R www-data:www-data /var/log/piwigo

Piwigo用のApache設定ファイル(例: /etc/apache2/sites-available/piwigo.conf)を以下の内容で作成します。

<VirtualHost *:80>
    # ドメイン名を指定します
    servername photo.example.com
    # HTTPアクセスを強制的にHTTPSにリダイレクトします
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName photo.example.com
    # アクセスログ
    CustomLog /var/log/piwigo/piwigo_access.log combined
    # エラーログ
    ErrorLog /var/log/piwigo/piwigo_error.log

    # PHP-FPMと連携するための設定
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost/"
    </FilesMatch>
    DocumentRoot /home/www-data/piwigo
    <Directory /home/www-data/piwigo>
        AllowOverride All
        Require all granted
    </Directory>

    #SSL設定
      SSLEngine on
    Protocols h2 http/1.1

    # 推奨されるSSL/TLS設定 (Mozilla Intermediate Compatibility)
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     on
    SSLCompression          off
    SSLSessionTickets       off # PFSを強化する場合

    # SSL証明書を指定します
    SSLCertificateFile 【SSL証明書のパスを絶対パスで指定】
    # 秘密鍵を指定します
    SSLCertificateKeyFile 【SSL証明書に対応した秘密鍵のパスを絶対パスで指定】

    #セキュリティヘッダー付与
        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>
  • 設定ファイルの有効化
sudo a2ensite piwigo.conf
  • 設定ファイルの整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apacheリスタート
sudo systemctl restart apache2.service
  • apacheリスタート確認
systemctl status apache2.service

active(running)を確認します。

Webインストーラーの実行

  1. ブラウザで、設定したドメイン(https://【photo.example.com】)にアクセスします。
  2. Piwigoの初期設定ウィザードが表示されます。
  3. 画面の指示に従い、データベース情報(ステップ1で作成したもの)や、管理者アカウントの情報を入力します。

インストーラーが完了すれば、Piwigoのフォトギャラリーが利用可能になります。

実行中のプロセスのメモリ量を昇順で表示するワンライナー。

概要

LinuxでWebサーバを運用していく中で気になるメモリの使用量。

「どのプロセスが一番メモリを消費しているのか?」

を調査してみます。

ワンライナーの設定

通例、メモリの使用量を見るのは

ps aux

とするのですが、

  • 全ての情報が見えてしまうので探しにくい
  • 単位が分からない

等の問題が発生します。そこで、

現在利用中のプロセスから、一番メモリを使用しているサービスを昇順で5つ抜き出し、そのメモリ量を見やすい形で成形するワンライナー

を生成AIにて作ってもらいます。(Gemini 2.5 Proを利用)

物理メモリ使用量(RSS: Resident Set Size)を基準にして、MB単位で表示するワンライナー

ps aux | tail -n +2 | sort -k 6 -rn | head -n 5 | sort -k 6 -n | awk '{cmd=""; for(i=11;i<=NF;i++){cmd=cmd" "$i}; printf "%10.2f MB   %s\n", $6/1024, cmd}'

コマンドの解説

ps aux
  • 現在実行中の全ユーザーのプロセスを詳細な情報付きで表示します。
tail -n +2
  • ps コマンドが出力する結果の1行目(ヘッダー行)を除外し、2行目以降のプロセス情報のみを次のコマンドに渡します。
sort -k 6 -rn
  • 6列目にある RSS(物理メモリ使用量) を基準に、数値を大きい順(降順)に並べ替えます。
  • -k 6: 6列目をソートキーに指定します。
  • -r: 逆順(降順)でソートします。
  • -n: 文字列ではなく数値としてソートします。
head -n 5
  • 降順にソートされた結果から、上位5つのプロセス(最もメモリを使用している5つ)を抽出します。
sort -k 6 -n
  • 抽出された5つのプロセスを、再度6列目のRSSを基準に、今度は小さい順(昇順)に並べ替えます。
awk '{ ... }'
  • 最終的な出力を見やすい形式に整形します。
  • cmd=""; for(i=11;i<=NF;i++){cmd=cmd" "$i}: 11列目以降の文字列をすべて連結し、スペースを含む完全なコマンド名を変数 cmd に格納します。
  • printf "%10.2f MB %s\n", $6/1024, cmd}: 6列目のRSS(KB単位)を1024で割ってMB単位に変換し、小数点以下2桁までの浮動小数点数としてフォーマットします。メモリ量を右寄せ10桁で表示した後、コマンド名を表示します。

表示例

ps aux | tail -n +2 | sort -k 6 -rn | head -n 5 | sort -k 6 -n | awk '{cmd=""; for(i=11;i<=NF;i++){cmd=cmd" "$i}; printf "%10.2f MB   %s\n", $6/1024, cmd}'
    236.36 MB    node -r dotenv-flow/config dist/server/app.js
    288.86 MB    Passenger RubyApp: /home/www-data/redmine1 (production)
    379.55 MB    Passenger RubyApp: /home/www-data/redmine2 (production)
    543.54 MB    /usr/sbin/mysqld
    654.73 MB    /usr/share/elasticsearch/jdk/bin/java -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j2.formatMsgNoLookups=true -Djava.locale.providers=CLDR -Dorg.apache.lucene.vectorization.upperJavaFeatureVersion=24 -Des.distribution.type=deb -Des.java.type=bundled JDK --enable-native-access=org.elasticsearch.nativeaccess,org.apache.lucene.core --enable-native-access=ALL-UNNAMED --illegal-native-access=deny -XX:ReplayDataFile=/var/log/elasticsearch/replay_pid%p.log -Des.entitlements.enabled=true -XX:+EnableDynamicAgentLoading -Djdk.attach.allowAttachSelf=true --patch-module=java.base=lib/entitlement-bridge/elasticsearch-entitlement-bridge-8.19.2.jar --add-exports=java.base/org.elasticsearch.entitlement.bridge=org.elasticsearch.entitlement,java.logging,java.net.http,java.naming,jdk.net -XX:+UseG1GC -Djava.io.tmpdir=/tmp/elasticsearch-10892987525338221374 --add-modules=jdk.incubator.vector -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError -XX:HeapDumpPath=/var/lib/elasticsearch -XX:ErrorFile=/var/log/elasticsearch/hs_err_pid%p.log -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/elasticsearch/gc.log:utctime,level,pid,tags:filecount=32,filesize=64m -Xms256m -Xmx256m -XX:MaxDirectMemorySize=134217728 -XX:G1HeapRegionSize=4m -XX:InitiatingHeapOccupancyPercent=30 -XX:G1ReservePercent=15 --module-path /usr/share/elasticsearch/lib --add-modules=jdk.net --add-modules=jdk.management.agent --add-modules=ALL-MODULE-PATH -m org.elasticsearch.server/org.elasticsearch.bootstrap.Elasticsearch

と、一番はElasticsearch(Growiで利用)。次いでMySQL、Redmineと続きます。nodeはGrowi関係です。

メモリ使用率(%MEM)を基準にして、MB単位で表示するワンライナー

続いて、システム全体のメモリ使用率を基準にする場合。

ps aux | tail -n +2 | sort -k 4 -rn | head -n 5 | sort -k 4 -n | awk '{cmd=""; for(i=11;i<=NF;i++){cmd=cmd" "$i}; printf "%5s%%   %s\n", $4, cmd}'

ソートの基準をRSS(6列目)から %MEM(4列目) に変更している点が主な違いです。

  4.3%    node -r dotenv-flow/config dist/server/app.js
  4.8%    Passenger RubyApp: /home/www-data/redmine1 (production)
  6.4%    Passenger RubyApp: /home/www-data/redmine2 (production)
  9.1%    /usr/sbin/mysqld
 11.0%    /usr/share/elasticsearch/jdk/bin/java -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j2.formatMsgNoLookups=true -Djava.locale.providers=CLDR -Dorg.apache.lucene.vectorization.upperJavaFeatureVersion=24 -Des.distribution.type=deb -Des.java.type=bundled JDK --enable-native-access=org.elasticsearch.nativeaccess,org.apache.lucene.core --enable-native-access=ALL-UNNAMED --illegal-native-access=deny -XX:ReplayDataFile=/var/log/elasticsearch/replay_pid%p.log -Des.entitlements.enabled=true -XX:+EnableDynamicAgentLoading -Djdk.attach.allowAttachSelf=true --patch-module=java.base=lib/entitlement-bridge/elasticsearch-entitlement-bridge-8.19.2.jar --add-exports=java.base/org.elasticsearch.entitlement.bridge=org.elasticsearch.entitlement,java.logging,java.net.http,java.naming,jdk.net -XX:+UseG1GC -Djava.io.tmpdir=/tmp/elasticsearch-10892987525338221374 --add-modules=jdk.incubator.vector -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError -XX:HeapDumpPath=/var/lib/elasticsearch -XX:ErrorFile=/var/log/elasticsearch/hs_err_pid%p.log -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/elasticsearch/gc.log:utctime,level,pid,tags:filecount=32,filesize=64m -Xms256m -Xmx256m -XX:MaxDirectMemorySize=134217728 -XX:G1HeapRegionSize=4m -XX:InitiatingHeapOccupancyPercent=30 -XX:G1ReservePercent=15 --module-path /usr/share/elasticsearch/lib --add-modules=jdk.net --add-modules=jdk.management.agent --add-modules=ALL-MODULE-PATH -m org.elasticsearch.server/org.elasticsearch.bootstrap.Elasticsearch

と、実メモリ6GB中の11%をElasticsearchが占めていることが明らかになりました。

Apache & PHP-FPM 管理スクリプト (引数対応版)。

Webサーバを運用する上で役立ている

  1. Apacheで有効になっているサイトの設定情報を表示
  2. 構文を確認
  3. 問題が無ければApache再起動
  4. 再起動後にステータスを表示する

スクリプト。非常に便利なものでしたが、VPS新調に際してPHP-FPMを導入。

そこで、

  1. PHP-FPMも構文チェックを行う
  2. 他、引数による処理

を改訂しました。(元ネタ:ChatGPT、リファクタリングはdeepseekとGemini)

スクリプト内容

  • apache2-check.sh
#!/bin/bash

#================================================================
# Apache & PHP-FPM 管理スクリプト (引数対応版)
#================================================================
#
# 機能:
# 1. Apacheで有効になっているサイトの設定情報を表示します。
# 2. ApacheとPHP-FPMの設定ファイルの構文をチェックします。
# 3. ApacheとPHP-FPMの再起動を個別に確認し、実行します。
# 4. 再起動後に各サービスのステータスを表示します。
#
# 引数:
#  -y : 確認プロンプトをすべてスキップし、自動で'yes'と応答します。
#  -a : Apacheのみを対象とします。
#  -p : PHP-FPMのみを対象とします。
#  -h : このヘルプを表示します。
#
#================================================================

# --- 設定項目 ---

# Apacheのサイト設定が格納されているディレクトリ
SITES_DIR="/etc/apache2/sites-enabled"

# 操作対象のPHPバージョン (例: "8.3", "8.2", "7.4")
PHP_VERSION="8.3"

# --- 設定ここまで ---


# --- スクリプトの動作を制御するフラグ ---
AUTO_YES=false
RESTART_APACHE=true  # デフォルトでは両方実行
RESTART_PHP=true     # デフォルトでは両方実行
EXCLUSIVE_MODE=false # -a または -p が指定されたかを判定するフラグ

# --- ヘルプ表示関数 ---
usage() {
    echo "Usage: $(basename "$0") [-y] [-a] [-p] [-h]"
    echo "  -y : 確認プロンプトをすべてスキップし、自動で'yes'と応答します。"
    echo "  -a : Apacheのみを対象とします。"
    echo "  -p : PHP-FPMのみを対象とします。"
    echo "  -h : ヘルプを表示します。"
    echo "引数なしの場合は、ApacheとPHP-FPMの両方が対象となります。"
    exit 0
}

# --- 引数解析 ---
while getopts "yaph" opt; do
  case $opt in
    y)
      AUTO_YES=true
      ;;
    a)
      if ! $EXCLUSIVE_MODE; then
          # -a or -p が初めて指定された場合、排他モードにしてデフォルトをリセット
          RESTART_APACHE=false
          RESTART_PHP=false
          EXCLUSIVE_MODE=true
      fi
      RESTART_APACHE=true
      ;;
    p)
      if ! $EXCLUSIVE_MODE; then
          # -a or -p が初めて指定された場合、排他モードにしてデフォルトをリセット
          RESTART_APACHE=false
          RESTART_PHP=false
          EXCLUSIVE_MODE=true
      fi
      RESTART_PHP=true
      ;;
    h)
      usage
      ;;
    \?)
      # 不正なオプション
      usage
      ;;
  esac
done

# PHP-FPMのサービス名とコマンド名を変数から生成
PHP_FPM_SERVICE="php${PHP_VERSION}-fpm"
PHP_FPM_COMMAND="php-fpm${PHP_VERSION}"

#
# サービスを再起動し、ステータスを表示する関数
#
restart_and_check_service() {
    local service_name="$1"
    local service_label="$2" # 表示用の名前
    local confirm_action="n"

    if [ "$AUTO_YES" = true ]; then
        confirm_action="y"
        echo "${service_label} を再起動します... (-yオプションにより自動確認)"
    else
        read -p "${service_label} を再起動しますか? (y/n): " confirm_action
    fi

    if [[ "$confirm_action" =~ ^[Yy]$ ]]; then
        if [ "$AUTO_YES" = false ]; then
          echo "--- ${service_label} を再起動します... ---"
        fi
        if ! systemctl restart "$service_name"; then
            echo "エラー: ${service_label} の再起動に失敗しました。"
        else
            echo "${service_label} が正常に再起動されました。"
            echo
            echo "==== ${service_label} ステータス ===="
            systemctl status "$service_name" --no-pager
            echo "=================================="
        fi
    else
        echo "${service_label} の再起動はキャンセルされました。"
    fi
    echo
}

# スクリプトを root ユーザーで実行しているかチェック
if [ "$EUID" -ne 0 ]; then
    echo "エラー: このスクリプトは root 権限で実行する必要があります。"
    exit 1
fi

# 1. 有効なサイト設定とドメインを表示
# このセクションは引数に関わらず常に表示される情報として実行します
echo "==== 有効なサイト設定ファイル ===="
if [ -z "$(ls -A "$SITES_DIR" 2>/dev/null)" ]; then
    echo "サイト設定が存在しません。"
else
    shopt -s nullglob
    for site in "$SITES_DIR"/*; do
        echo "設定ファイル: $(basename "$site")"
        entries=$(grep -hi -E "^\s*(ServerName|ServerAlias)\s+" "$site" | sed -E 's/^[[:blank:]]+//;s/[[:blank:]]*#.*//' | awk '{
            original_directive = $1
            directive = tolower(original_directive)
            proper_directive = (directive == "servername") ? "ServerName" : \
                               (directive == "serveralias") ? "ServerAlias" : original_directive
            for (i=2; i<=NF; i++) {
                domain = tolower($i)
                sub(/[;,]*$/, "", domain)
                gsub(/^[[:blank:]]+|[[:blank:]]+$/, "", domain)
                if (domain) {
                    printf "%s %s\n", proper_directive, domain
                }
            }
        }' | sort -u)
        if [ -z "$entries" ]; then
            echo "  ※ ServerName/ServerAliasが定義されていません"
        else
            echo "$entries" | sed 's/^/  /'
        fi
        echo
    done
    shopt -u nullglob
fi
echo "=================================="
echo

# 2. 構文チェック
echo "--- 構文チェック ---"
SYNTAX_OK=true

# Apache構文チェック
if [ "$RESTART_APACHE" = true ]; then
    echo "Apache の構文をチェックしています..."
    if ! apachectl configtest 2>&1 | grep -q "Syntax OK"; then
        echo "エラー: Apacheの構文エラーが検出されました。"
        apachectl configtest # エラー詳細を再表示
        SYNTAX_OK=false
    else
        echo "Apacheの構文は正常です。"
    fi
    echo
fi

# PHP-FPMの存在確認と構文チェック
PHP_FPM_ENABLED=false
if [ "$RESTART_PHP" = true ]; then
    if systemctl list-units --type=service --all | grep -q "${PHP_FPM_SERVICE}.service"; then
        if command -v "$PHP_FPM_COMMAND" &>/dev/null; then
            PHP_FPM_ENABLED=true
            echo "${PHP_FPM_SERVICE} の構文をチェックしています..."
            if ! "$PHP_FPM_COMMAND" -t 2>&1 | grep -q "test is successful"; then
                echo "エラー: ${PHP_FPM_SERVICE} の構文エラーが検出されました。"
                "$PHP_FPM_COMMAND" -t # エラー詳細を再表示
                SYNTAX_OK=false
            else
                echo "${PHP_FPM_SERVICE} の構文は正常です。"
            fi
        else
            echo "警告: ${PHP_FPM_SERVICE} サービスは存在しますが、${PHP_FPM_COMMAND} コマンドが見つかりませ
ん。PHP-FPMのチェックはスキップします。"
            RESTART_PHP=false # 実行フラグをオフにする
        fi
    else
        echo "情報: ${PHP_FPM_SERVICE} サービスが見つかりません。PHP-FPM関連の処理はスキップします。"
        RESTART_PHP=false # 実行フラグをオフにする
    fi
    echo
fi

# 構文エラーがあれば処理を中断
if [ "$SYNTAX_OK" = false ]; then
    echo "構文エラーが検出されたため、処理を中断します。"
    exit 1
fi
echo "--------------------"
echo

# 3. サービスの再起動
if [ "$RESTART_APACHE" = false ] && [ "$RESTART_PHP" = false ]; then
    echo "再起動対象のサービスがありません。"
    exit 0
fi

# Apacheの再起動
if [ "$RESTART_APACHE" = true ]; then
    restart_and_check_service "apache2" "Apache"
fi

# PHP-FPMの再起動
if [ "$RESTART_PHP" = true ] && [ "$PHP_FPM_ENABLED" = true ]; then
    restart_and_check_service "$PHP_FPM_SERVICE" "$PHP_FPM_SERVICE"
fi

スクリプトの動き

  1. sudo bash apache2-check.shとすることで
  2. A@acheを起動するか、PHP-FPMを起動するかの2択が生まれます。
  3. -yオプションの場合は全てyにしてプロンプトを省略します。
  4. -aでApacheのみの再起動-pはPHP-FPMのみの再起動

と、柔軟かつやりやすいスタイルへと仕上がりました。

ケーススタディ・ModSecurity影響下でファイルアップロードできない事象に対応

概要

Redmineでファイルをアップロードしようとした際、ModSecurity (WAF) によってブロックされ、エラーになる事象が発生しました。
その原因と事象解決のメモです。

環境

  • Ubuntu 24.04
  • Apache 2.4
    • RedmineをApacheのMod_Passangerで稼働
  • Redmine 5.1
  • ModSecurity v2 / OWASP Core Rule Set (CRS)

事象の確認

環境をWebArenaからXServerに移行した直後。
Redmineのチケットでファイルをアップロードしようとすると、ファイルアップロードのプログレスバーが完了せず、アップロードできません。

原因の特定

こういうときの答えはたいがい、エラーログに書かれているのでそれを確認します。

見つけたログ(IPアドレスやホスト名は改変済み):

[Wed Aug 13 12:47:21.713637 2025] [security2:error] [pid 11190] [client AAA.BBB.CCC.DDD:40404] ModSecurity: Request body no files data length is larger than the configured limit (131072). [hostname "hoge.example.com"] [uri "/uploads.js"] [unique_id "aJwKye92u8EKc4H_FxCb5QAAABQ"], referer: https://hoge.example.com/issues/123

Request body no files data length is larger than the configured limit (131072)

これは、「ファイル以外のリクエストデータ(no files data)のサイズが、設定された上限値(131072バイト = 128KB)を超えています」という意味です。

Redmineは、ファイルをアップロードする際、ファイルそのものとは別に、チケットの題名や説明といったテキスト情報も同時にサーバーへ送信します。このテキスト情報の合計サイズが、ModSecurityのデフォルトの上限値である128KBを超えてしまったため、攻撃と誤認され、ブロックされる。

というのがAI(Gemini)の回答。

既にApacheのバーチャルサイトの.confファイルには

SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000

と記述していますが、サーバの入れ替えと同時にModSecurityのCRSをアップデートしたことで設定が足りなかったようです。

ここまで分かれば、解決まであと少し。

対処手順

設定ファイルのバックアップ

ModSecurityのメイン設定ファイルで、SecRequestBodyNoFilesLimitの上限値を設定で上書きしていきます。

  • エラーを起こしているバーチャルサイトの.confファイルのバックアップ
sudo cp -pi /etc/apache2/site-available/redmine.conf /path/to/backup/directory/redmine.conf.$(date +%Y%m%d)

.confの名前やバックアップディレクトリは自分の環境に合わせます。

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

差分がなければ(エラーがなければ)バックアップ成功。

上限値を修正する

上述した設定ファイルを以下のように修正。

修正前(例):

SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000

修正後(例):

SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
SecRequestBodyNoFilesLimit 524288000

両方の値を同じにしておくと、管理が分かりやすくなります。

なお、500MBとしているのは一時的に大きなファイルを置くこともあるからです。上限値は自分の運用方針やストレージ量に合わせましょう。

修正確認

  • ファイル修正後の差分
diff -u /path/to/backup/directory/redmine.conf.$(date +%Y%m%d) /etc/apache2/site-available/redmine.conf
  • 差分例
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
+SecRequestBodyNoFilesLimit 524288000

と、追記した行が出てくることを確認します。

設定反映&動作確認

  • confファイルの構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

Running(active)を確認します。

  • 動作確認

Redmineのチケット作成/編集画面でファイルが正常にアップロードできるようになれば対処完了です。

まとめ

新環境の構築時、最新のCRSを導入したため、旧環境をそのまま引き継いだというのが直接的な原因でした。
こういう罠があちこちに潜んでいるので、何かあったらログを見て事象を確かめるのが事象解消の近道です。

confファイルのチューニングでPassangerのメモリ量を節約。

WebArenaからXServerに移行し、メモリを6GBまで増強したものの、スワップの使用量増加が止まらず。

これをチューニングによりなんとか抑えられたというメモ書きです。

経緯

  1. スペックの負荷状況を調べるためにGrowiを導入
  2. 十分な性能が見込めたためにNextcloudやBookStackなどを入れていく
  3. それでも稼働していったのでRedmineの移行を終える。
  4. Redmineを入れた途端、スワップ使用率が高くなった。

環境

  • Ubuntu / Debian系OS
  • Apache 2.4
  • libapache2-mod-passengerがインストール済み
  • Redmineを複数稼働

チューニングの目的

上記環境のmod_passengerは、筆者のように複数のアプリケーションを、リソースが限られたVPSで運用する場合(いわゆる逸般的な使い方)は、メモリを過剰に消費し、サーバー全体のパフォーマンスを低下させる可能性があります。

事実、free -hコマンドで、Swapの使用量が放置しているのに高まってきたという状況でした。

そこで、リクエストがあれば都度、プロセスを増やしてしまうpassengerの機能をチューニングで抑制します。

さっくりとした手順

  1. passengerの設定ファイルのバックアップを行います。
  2. ファイルの修正によるチューニングを行います。
  3. 設定を反映させ、状況を確認します。

Passengerの設定ファイルをのバックアップ

※この設定は、バーチャルサイト個別設定ではなく、一括で設定を行います。

なぜなら、Passenger関連のディレクティブが、<VirtualHost>ブロックの中に書くことができないからです。

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

バックアップディレクトリは自分の環境に合わせます。(筆者環境:/etc/conf/backup)

  • ファイルのバックアップ確認
diff -u -pi /path/to/backup/direcotry/passenger.conf.$(date +%Y%m%d) /etc/apache2/mods-available/passenger.conf 

差分がなく、エラーがなければバックアップはできています。

メモリ管理ディレクティブを追記

上記passenger.confファイルを開き、<IfModule mod_passenger.c>...</IfModule>ブロックの中に、以下の設定を追記します。

<IfModule mod_passenger.c>
  PassengerRoot /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini
  PassengerDefaultRuby /usr/bin/ruby

  # --- ▼ここから追記▼ ---
  # Passengerが起動するRubyプロセスの最大数を4に制限
  PassengerMaxPoolSize 4
  # 各アプリケーションごとに起動する最大プロセス数を1に制限
  PassengerMaxInstancesPerApp 1
  # プロセスが300秒(5分)アイドルだったら停止させる
  PassengerPoolIdleTime 300
  # --- ▲ここまで追記▲ ---
</IfModule>

各ディレクティブの解説

ディレクティブ説明
PassengerMaxPoolSizePassengerがサーバー全体で起動するRubyプロセスの最大総数です。サーバーのメモリ上限を超えないよう、搭載メモリ量に応じて設定します。
PassengerMaxInstancesPerApp各アプリケーションごとに起動できるプロセスの最大数です。例えば1に設定すると、一つのRedmineサイトは同時に1つのプロセスしか使えなくなります。
PassengerPoolIdleTimeプロセスがここで指定した秒数以上アクセスがない場合、Passengerはそのプロセスを停止させ、メモリを解放します。

設定の反映

ファイルを保存した後、Apacheを再起動して設定を反映させます。

  • 構文確認
sudo apache2ctl configtest

Syntax Okを確認します。エラーが出たらその箇所を確認し、Syntax OKが出るまで修正します。

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

Running(Active)を確認します。

動作確認

この状態で一晩ほど様子を見ました。

free -h
               total        used        free      shared  buff/cache   available
Mem:           5.8Gi       3.3Gi       551Mi       141Mi       2.3Gi       2.4Gi
Swap:          2.0Gi       1.5Mi       2.0Gi

のまま。チューニング前はSwapを100~500MBも使用していたことから、動作は安定。設定は有効のようです。

Page 1 of 21

Powered by WordPress & Theme by Anders Norén