月: 2026年8月 Page 1 of 4

はじめに

前回の記事では、Redmine 6.xへの移行準備として、redmine_dmsf を完全に切除しました。

その流れで、「それならKnowledgebaseも同じ手順で片付くだろう」と考えたのが、今回の始まりです。

長年ナレッジ管理として活躍してくれた redmine_knowledgebase ですが、現在はMarkdownネイティブな BookStack を主に利用しており、今後も利用予定はありません。

Redmine 6.xへのメジャーバージョンアップを見据え、依存関係を少しでも整理するため、完全アンインストールを行うことにしました。

前回の教訓もあります。

「マイグレーションを一つずつ戻す」のではなく、

• データベース
• マイグレーション履歴
• プラグイン本体

をまとめて切除する外科手術方式です。

ところが今回は、それだけでは終わりませんでした。

Knowledgebaseを削除したはずなのに、ブラウザには何度アクセスしても

We're sorry, but something went wrong.

と表示され続けます。

今回の記事は、この500エラーの犯人を追い掛けた記録です。

今回の前提

今回の作業も、本番環境ではなく前回構築した Side-by-Side 構成の検証環境 (redmine-clone) で実施しています。

今回も、「失敗してもやり直せること」を前提に作業を進めています。

まずはバックアップ

前回と同様、テーブル削除を伴うため、最初にMySQLのダンプを取得します。

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  --default-character-set=utf8mb4 \
  -u redmine_clone \
  -p \
  redmine_clone \
  > redmine_clone_before_knowledgebase.sql

このバックアップが、最後の保険です。

Step1 Knowledgebaseを切除する

今回は最初から外科手術方式を採用しました。

まずは関連テーブルを削除します。

USE redmine_clone;

SET FOREIGN_KEY_CHECKS = 0;

DROP TABLE IF EXISTS
    kb_articles,
    kb_article_versions,
    kb_categories;

SET FOREIGN_KEY_CHECKS = 1;

続いて、マイグレーション履歴を削除します。

DELETE
FROM schema_migrations
WHERE version LIKE '%-redmine_knowledgebase%';

注意

この方法は「Knowledgebaseを今後利用しない」ことを前提としています。

将来的に再利用する予定がある場合は、通常の移行手順を検討してください。

最後にプラグイン本体を退避します。

cd /home/www-data/redmine-clone

sudo mv plugins/redmine_knowledgebase \
    /home/www-data/retired_plugins/

sudo touch tmp/restart.txt

ここまでは、前回のDMSFとほぼ同じ流れです。

そして私は、この時点で終わったと思っていました。

……終わらなかった

ブラウザを更新すると、

We're sorry, but something went wrong.

The issue has been logged for investigation.
Please try again later.

何度更新しても500エラー。

Knowledgebaseは削除したはずです。

それなのにRedmineは起動しません。

ここから、本当の原因調査が始まりました。

容疑者その1 ― ログが出ていない

まず最初にproduction.logを確認します。

……ところが、ログが増えません。おかしい。

シンボリックリンクを確認すると、

/home/www-data/redmine-clone/log
    ↓
/var/log/redmine

なんと、検証環境のログが本番環境を向いたままでした。

クローン作成時に張り替えたつもりだったシンボリックリンクが、そのまま残っていたのです。

修正します。

cd /home/www-data/redmine-clone

sudo rm log

sudo ln -sf /var/log/redmine-clone log

これでようやく検証環境のログが取得できるようになりました。

……しかし、500エラーは変わりません。容疑者その1、シロでした。

容疑者その2 ― Passenger

次に、Passengerを完全再起動します。

そこで、

passenger-config restart-app

を実行すると、

ArgumentError:
too long unix socket path
(116 bytes given but 108 bytes max)

というエラー。

UNIXドメインソケットの108バイト制限に引っ掛かっていました。

結局、

sudo touch tmp/restart.txt

sudo systemctl reload apache2

という昔ながらの方法で再起動することにしました。

……それでも500エラー。Passengerも違いました。

真犯人

ログが正常に取得できるようになったため、

rake コマンドで環境初期化を実行すると、ついに原因が現れました。

NoMethodError:

undefined method
`requires_redmineup'

plugins/redmine_questions/init.rb

Knowledgebaseではありませんでした。

真犯人は redmine_questions です。

Redmineは起動時に、すべてのプラグインの init.rb を読み込みます。

Knowledgebaseを削除しても、同居していた redmine_questions が redmineup のメソッドを要求し、その時点で初期化が停止していました。

つまり、Knowledgebaseを削除したことで壊れたのではなく、

以前から潜んでいた依存関係の問題が表面化しただけだったのです。

決断 ― 疑わしき依存はすべて切り離す

redmine_questions の利用状況を改めて確認した結果、今後利用する予定はありませんでした。依存関係を抱えたままRedmine 6.xへ進むリスクを考え、こちらもKnowledgebaseと同様に完全切除することにしました。

Questionsを切除する

まずは関連テーブルを削除します。

mysql -u redmine_clone -p

USE redmine_clone;

SET FOREIGN_KEY_CHECKS = 0;

DROP TABLE IF EXISTS
    questions,
    questions_answers,
    questions_sections,
    questions_statuses;

SET FOREIGN_KEY_CHECKS = 1;

続いてマイグレーション履歴を削除します。

DELETE
FROM schema_migrations
WHERE version LIKE '%-redmine_questions%';

最後にプラグイン本体を退避し、キャッシュを削除します。

sudo mv \
plugins/redmine_questions \
/home/www-data/retired_plugins/

sudo rm -rf tmp/cache/*

sudo touch tmp/restart.txt

sudo systemctl reload apache2

動作確認

ブラウザを更新すると……

500エラーは完全に解消しました。確認できた内容は次のとおりです。

• Redmineが正常起動する
• トップページが表示される
• 管理画面へログインできる
• Plugin一覧から
  • DMSF
  • Knowledgebase
  • Questions
    が消えている
• エラーログに新たな例外が出ていない

ここまで確認できれば、今回の切除作業は完了です。

おわりに

今回の500エラーは、Knowledgebaseそのものが原因ではありませんでした。

長年運用してきたプラグイン同士の依存関係が、Knowledgebaseの切除をきっかけに姿を現しただけだったのです。

一つ外せば終わると思っていたものが、実際には別のプラグインを炙り出す。長期間運用してきたRedmineらしい現象だったと感じています。

結果として、

• redmine_dmsf
• redmine_knowledgebase
• redmine_questions

という、今後利用予定のない大型プラグインを整理することができました。

Redmine本体はまだ5.1のままですが、不要な依存を抱えない、できるだけ素の状態へ近づけることができています。

そして今回も、問題の切り分けが落ち着いてできたのは、前回構築した redmine-clone の存在があったからです。

本番環境だったら、500エラーが出るたびに焦っていたかもしれません。しかし検証環境だからこそ、一つずつ仮説を立て、ログを確認し、原因を潰していくことができました。

いよいよ次は、Redmine 6.xへのメジャーバージョンアップの下準備です。

ここまで整理してきた環境が、どこまで素直に新しいバージョンを受け入れてくれるのか。それを確認する段階まで、ようやくたどり着きました。

はじめに

「既にサポート終了になっているRedmine 5.1。これをバージョンアップしたい」がそもそものきっかけ。

しかし、Redmineのメジャーバージョンアップは、RubyやRailsの更新だけではありません。利用しているプラグインやテーマとの互換性、添付ファイル、データベース、さらにはWebサーバーやWAFとの兼ね合いまで確認しなければならず、思いのほか確認項目は多くなります。

特に本番環境を運用している場合、「とりあえずアップデートしてみる」というわけにはいきません。

迂闊にアップデートするとRedmineそのものが動くならない事象が発生します。

そこで今回は、稼働中のRedmine 5.1環境をそのまま複製し、本番とは完全に独立した検証環境を同一サーバー上へ構築しました。

目的は単なるバックアップではなく、Redmine 6.xへの移行を何度でも試行錯誤できる環境を作ることです。

構築環境

今回の構成は次のとおりです。

同一サーバー上へ検証環境を追加するため、Apache・Ruby・MySQLは共有しながら、Redmine本体・データベース・ログ・添付ファイルのみを完全に分離します。

本番環境と検証環境の構成

今回の構成では、以下のように役割を分離しています。

このようにしておけば、本番環境へ一切影響を与えることなく、何度でもアップグレードの検証を繰り返せます。

さっくりしていそうでさっくりしない手順

あくまでも筆者の手順です。

1. MySQLダンプを取得
2. Redmine環境の（アプリの）クローン

1. まずはMySQLのダンプを取得する

アプリケーションをコピーする前に、現在のデータベースをバックアップしておきます。

※DB名、ユーザー名は自分の環境に合わせてください。

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  --default-character-set=utf8mb4 \
  -u redmine \
  -p \
  redmine \
  > redmine.sql

--single-transactionを利用しているため、InnoDB環境であればサービス停止なしで整合性の取れたバックアップを取得できます。

2. Redmine本体を複製する

アプリケーション本体は cp ではなく rsync を利用しました。

ACLや拡張属性も含めてそのまま複製できるため、権限周りで悩むことが少なくなります。

※ディレクトリ名も自分の環境に合わせます。

cd /home/www-data

sudo rsync -aX redmine/ redmine-clone/

ここではまだ添付ファイルやログは本番環境を参照しています。(エイリアスを切っているため)

次の手順で検証環境用へ切り替えます。

3. 添付ファイルとログを分離する

添付ファイルはS3互換ストレージをマウントしているため、検証用ディレクトリへ切り替えます。

※サーバ上にそのまま保存している場合でも容量に注意しましょう

cd /home/www-data/redmine-clone

sudo ln -sf /mnt/storage/redmine-clone/files files

続いてログディレクトリを作成します。

sudo mkdir -p /var/log/redmine-clone

sudo chown -R www-data:www-data /var/log/redmine-clone

sudo ln -sf /var/log/redmine-clone log

これで本番・検証それぞれのログを独立して取得できます。

4. 検証用データベースを作成する

MySQLへログインし、新しいデータベースとユーザーを作成します。

※DBの向き先は要注意です。パスワードもポリシーに則り、適切なものを指定します。

CREATE DATABASE redmine_clone CHARACTER SET utf8mb4;

CREATE USER 'redmine_clone'@'localhost' IDENTIFIED BY 'password';

GRANT ALL PRIVILEGES ON redmine_clone.* TO 'redmine_clone'@'localhost';

FLUSH PRIVILEGES;

5. ダンプをリストアする

取得したバックアップを検証用データベースへ投入します。

※※要注意※※

リストア先とリストア元は三回ぐらい深呼吸して、事前に確認しましょう。

「クローン先のDB名」が先で、「クローン元のダンプファイル」が後です。

mysql \
  -u redmine_clone \
  -p \
  redmine_clone \
  < redmine.sql

これでデータベースも本番環境と同じ状態になります。

6. database.ymlを書き換える

Redmineが参照するデータベースを検証環境へ向けます。

production:

- database: redmine
+ database: redmine_clone

- username: redmine
+ username: redmine_clone

password: ********

忘れがちですが、この変更をしないと検証環境が本番データベースへ接続してしまいます。死ぬほど笑えない事象は、往々にしてこういうところから始まります。（始まりました）

7. ModSecurityの除外設定を追加する (オプション)

今回はApacheでModSecurityとOWASP CRSを利用しています。

RedmineはPATCHやPUTなどのHTTPメソッドを使用するため、通常のCRSでは誤検知されるケースがあります。

本番環境ですでに除外ルールを適用している場合は、検証用ホスト名も同様に対象へ追加します。

- redmine.example.com
+ redmine.example.com
+ redmine-test.example.com

これを忘れると、画面上では保存ボタンを押しただけなのに403 Forbiddenになることがあります。

8. Apache VirtualHostを追加する

本番用VirtualHost/etc/apache2/sites-available/redmine.confをコピーし、/etc/apache2/sites-available/redmine-clone.conf

• ServerName
• DocumentRoot
• ErrorLog
• CustomLog

を検証環境用へ変更します。

例えば、

/home/www-data/redmine/public

を

/home/www-data/redmine-clone/public

へ変更し、

/var/log/redmine

も

/var/log/redmine-clone

へ変更します。

設定後は有効化してApacheを再読み込みします。

sudo a2ensite redmine-test.conf

sudo apache2ctl configtest

sudo systemctl reload apache2

動作確認

ここまで終わったら、検証環境へアクセスして以下を確認します。

• ログインできる
• チケット・Wiki・プロジェクトが一致している
• 添付ファイルが表示される
• ログが検証用ディレクトリへ出力される
• ModSecurityで403にならない

ここまで確認できれば、Side-by-Side構成のクローン環境は完成です。

おわりに

サーバー運用では「バックアップを取ってから更新する」は半ば常識になっています。しかし、メジャーバージョンアップのような大きな変更では、それだけでは十分とは言えません。

実際に必要なのは、「失敗してもやり直せる環境」を用意しておくことです。

今回のように本番と完全に切り離した検証環境を用意しておけば、Redmine 6.xへのアップグレードだけでなく、Rubyやgemの更新、不要プラグインの整理、設定変更なども心置きなく試せます。

運用者であれば「更新前にバックアップを取る」は自然とできるようになります。しかし、その先の「何度でも検証できる環境を用意する」まで仕組みにしておくと、運用はさらに一段安定します。

私自身、今回の移行作業ではこの検証環境のおかげで、結果として、一度きりの「勝負」ではなく、納得いくまで検証を重ねた上で本番移行へ臨めます。