月: 2025年6月 Page 1 of 3

『ライザのアトリエ2』超高難易度DLC「陽炎の島」攻略に向けての特性調達。(神秘の力→中和剤ループ→水に変換)

前回、難易度を下げて挑戦した「陽炎の島」。

早速、今後の攻略の鍵となる良質な特性が見つかったので調合していきます。

神秘の力→燃料への素材変換

必要な特性「エコノミーコア」は幻獣の毛皮に付与されていました。

  • 神秘の力
  • 動物素材

を持っているため、「マナランタン」の「神秘の力」のスロットに投入して調合していきます。

  • エコノミーコア
  • スーパーボディ
  • ドッジムーブ

の特性を付与。(燃料)付与も忘れずに行います。

中和剤ループ

こうして得たマナランタン(燃料)を中和剤・赤の素材にします。

後は中和剤ループ。

レベルのある特性は 99まで上昇しました。

中和剤を更に使いやすく変換

このテクニックは『ライザのアトリエ』からの伝統なので、ここでも使います。

調合メニューからゼッテルを開き、中和剤のマテリアル環に

  • スーパーボディ 99
  • ドッジムーブ 99
  • エコノミーコア

が付与された中和剤を投入。

泡立つ水を入れ、そのまま旅人の水珠へとレシピ変化をします。

そこから調合を進め

更に使いやすく「水」として加工しました。

ここまで来れば他の材料に更に調合しやすくなります。

『ライザのアトリエ2』超高難易度DLC「陽炎の島」攻略に向けての準備。(ネタバレあり)

自分のブログで継続して読まれているこの記事を、再攻略とともに更に検証を深めていこうと思います。

「陽炎の島」について

超高難易度DLCを謳うだけあって、その難易度は尋常ではありません。

  1. 本編のラスボスを超えるHPや攻撃力を持つ通常敵が襲いかかります。
  2. 攻撃も重く、一撃で戦闘不能や全員のブレイクも必至です。
  3. 下手なコアドライブやフェイタルドライブは露払い程度です。
  4. ましてやマップのボスはゲームが違うレベルの強さです。
難易度LEGENDでの敵の例。トータルで120万ダメージを与える必要があります

反面、利点は

  1. 本編では得られない優秀な特性の数々を得られる
  2. 一点ものの希少な素材により武器・防具をチューンナップできる

の2点。特に以下に代表される特性は魅力的です。

  • 全能力強化++
    • すべてのステータス値が最大50上がる
  • 心の破壊力
    • アイテムの威力が最大で100%増加し、クリティカルになる確率が最大で100%増加する
  • エコノミーコア
    • 消費CCが1下がる。(0にはならない)

方針

『陽炎の島』攻略に向けての方針は

  1. 難易度を極限まで下げてマップを踏破していく。
  2. 途中で得られる特性を厳選していきアイテムを作り直していく。
  3. 慣れてきたら難易度を戻していく。

です。また、それに応じて高品位の武器が必要になるので、実質的にDLC

  1. 戦いの極み
  2. 調合の極み

は必須です。

では、攻略の準備を進めていきます。

前提

  • 本編クリア済みであること。
    • → そもそもクリアデータがないと『陽炎の島』は解放されません。
  • 調合に関するスキルツリーを埋めていること。
  • ジェムを無限に稼ぐ手段を整えること。
    • →調合の極みで追加されるアイテム(アナザープラネットなどが便利です)

チェックに従い難易度を下げます。

これが一番重要です。

Easyでも全滅する場合があるため、以下の判断基準を筆者にて用意しました。

難易度判定チェック

クリア後、「霊なる竜の棺」の「魂の眠りし場所」に転送器が活性化されています。

ここの奥に鎮座する敵を倒してみましょう。実績対象だけあって、ラスボス以上の強さの敵です。

以下、筆者の体感となる基準です。

  • Legendでも楽勝
    • Charisma
  • Legendで辛勝
    • Very Hard かHard
  • Normal~Very Hardで倒した
    • → EasyかNormal
  • Normalでようやくクリアできた
    • → Very Easy
  • Easyでも全滅した
    • → 倒せるまで装備や攻撃アイテムを調えましょう。

素材(インベントリ)を整理していきます。

  • 調合アイテム
  • 装備品
  • 使用アイテム

すべてを見直すため、採取を頻繁に行います。そのため、コンテナ容量5000はすぐに埋まります。

属性値や品質の低いものをジェムに変えていきます。また、盲点になるのが異界結晶です。必要な分以外は処分しましょう。

ゲーム初期に得ていた低品質の素材は

  1. ジェム還元でジェムやエッセンスに変える
  2. フォーゲル商会で売りさばきショップの品揃えを充実させる

などにしてインベントリを減らしていきます。

上記の前提や準備が揃ったら、いよいよ攻略開始です。

なお、本検証では、2023年のセーブデータは参照に留め、まっさらなデータであることを付記しておきます。

『ライザのアトリエ2』グランツオルゲン調合。

インゴット系の最上位種、グランツオルゲン。

『ライザのアトリエ2』では「ロミィの店でセプトリエンを売ることでショップに登録される」システムですが、

本格的な調合はラストダンジョンまで待つ必要があります。

なぜなら、必須材料である異界結晶がラストダンジョンの敵のドロップアイテムだからです。

これを手に入れてしまえば後は調合。

レシピ変化による調合

『ライザのアトリエ2』でのグランツオルゲンの調合は

「ゴルドテリオン」からのレシピ変化です。これ自体も元を辿っていくと

  1. インゴット
  2. スタルチウム
  3. クリミネア
  4. グランツオルゲン

と変化していきます。

調合メニューからインゴットを選びます。

特性を選びます。

こちらの通り、中和剤の特性ループにより

  • 攻撃強化++ 50
  • スキル強化 ++ 30
  • 全能力強化 30

を持たせた(鉱石)が付与された中和剤・黄を入れていきます。

上記例ではここのマテリアル環の活性化条件は氷属性のアイテム。

ですが、活性化されていない状態でも「特性入りの素材が入った」ことは調合中に記憶されます。

逆に言えば、レシピ変化を伴う調合中、最終段階(変化を終えた状態で)の調合で特性枠を活性化させないと意味がありません。

他の材料を入れていき、スタルチウムへとレシピ変化。

途中、影響拡大を持つアイテムで「材料を入れることなくマテリアル環の活性化」を図っていき、

クリミネア → ゴルドテリオン

と材料を入れていきます。

ゴルドテリオンのマテリアル環に「異界結晶」を入れるスロットが出てくるので、投入。

エッセンス投入による威力強化

グランツオルゲンの「効果1」並びに「効果2」に、その属性に対応したエッセンスを入れます。

これにより、効果テーブルが1段階上がります。活性化までの属性値は上昇しますが、効果が更に上がります。

こうして、グランツオルゲンでの特性枠を埋めたら調合完了。

  • 装備作成 全能+7
  • 装備作成 攻速+7

の効果を持ち、

  • 攻撃強化++ 50
  • スキル強化 ++ 30
  • 全能力強化 30

の特性を持たせたインゴット素材「グランツオルゲン」が完成です。

『ライザのアトリエ2』『ライザのアトリエ3』中和剤ループによる特性のレベル上げ。

ユミアの攻略に少し余裕が出てきたので、こちらに軸を移します。

以前に書いた

これらの記事を更に初心者向けに解説したものです。

そもそも特性とは?

すごくさっくり言うと

「素材(調合アイテム含む)にあり、調合するアイテムに付与するもの」

です。

  • 品質を上げる
  • 売却価格を上げる
  • 武器や防具のステータスを上げる
  • 特定の魔物に効力を発揮する
  • 攻撃/回復アイテムの効果を強める

など、プラスの効果を与えます。

一例を見てみましょう。

この武器「ノクターナルレリック」は特性を持たせる前のステータスは

  • HP:289
  • 攻撃力:643
  • 防御力:286
  • 素早さ:527

となっていますが、ここに

  • 全能力強化++ Lv.99
    • 全ての能力値が最大で50増加する
  • 攻速強化++ Lv.99
    • 攻撃力と素早さが最大で100増加する
  • スペシャルアーツ Lv.99
    • スキルの威力が最大100%増加する。さらに通常攻撃で得られるAPが一定確率で増加する

を付与します。

  • HP:339
  • 攻撃力:793
  • 防御力:336
  • 素早さ:677

とステータスアップしていることが分かります。

特性レベルと特性

特性の多くはレベル制を採用しており、レベルが高ければ高いほどその恩恵に与れます。

このレベルは調合時に加算されます。

先の「全能力強化++ Lv.3」と「全能力強化++ Lv.10」を持つ素材を調合することで「全能力強化++ Lv.13」となるという足し算。

しかし、大概の素材は特性レベルがそれほどありません。なので、「調合による特性のレベルアップ」を行っていきます。

特性のレベルアップのケーススタディ:中和剤・赤

この特性レベルアップのキーとなるのが中和剤。4色(赤・青・黄・緑)とある中で、一番分かりやすい赤を見てみましょう。

中和剤のマテリアル環(素材を入れるスロット)には火薬を入れるよう指示されています。

その先のマテリアル環には「(火薬)付与」の言葉があります。

つまり、

  1. 中和剤・赤の効果で(火薬)を付与して中和剤・赤を調合する。
  2. 「1」で調合した中和剤・赤を燃料のマテリアル環に投入する

ことで、このレベルアップが達成できます。

手順

レベルアップさせたい特性を選びます。

破壊力上昇++ を絞り込みで検索。

材料を投入していきます。

破壊力上昇 ++ Lv.10を持つ素材が見つかりましたので、これを投入。

回復力上昇++ 等も入れていきます。

いざ、特性を選ぶ段で

3つある特性のうち

  • 回復力上昇++
  • クリティカル++

がロックされていることが分かります。これは、

マテリアル環の「特性枠」が活性化されていないためです。いくらいい特性を持たせても、「特性枠」を活性化させないと上記のループは意味を成しません。

そうした上で活性化させ、特性を選択させます。このレベルアップの「ループ」の基本となる中和剤が完成。

こうしてできた中和剤は基本的に4つほど。この「4つ」というのがポイントです。

中和剤を原料に特性のレベルアップを行います。

再び調合メニューから「中和剤・赤」を選択して、火薬のスロットに、上述した基本となる中和剤をいれます。

左上の特性枠には

  • 破壊力上昇++ 40 (10×4)
  • 回復力上昇++ 36(9×4)
  • クリティカル++ 4(1×4)

となっています。この段階でループが完成。あとは、レベルの上限になるまでこのループを達成させます。

最初のレベルが1であっても、

1 → 4 → 16 → 64...

といった具合で飛躍的に上がっていきます。

こうしてできあがった中和剤・赤が

  • クリティカル++ 99
  • 回復力上昇 ++ 50
  • 破壊力上昇 ++ 50

となります。

中和剤・赤補足

また、中和剤・赤の効果の一つに(燃料)付与もあるため、

火薬や燃料を必要とする他の素材へと転用が可能です。

他の中和剤の場合

※全ての効果を活性化させた場合です。

中和剤・青

  • 気体

が付与されます。「花」のスロットに中和剤・青を入れることでループを行えます。

中和剤・黄

  • 鉱石
  • 雑貨

が付与されます。「鉱石」のスロットに中和剤・黄を入れることでループを行えます。

中和剤・緑

  • 木材
  • 石材

が付与されます。「木材」のスロットに中和剤・緑を入れることでループを行えます。

これらの中和剤ループを念頭に置いておくだけでも、本作の攻略の難易度は大きく変わります。

備考

この中和剤ループはタイトルで示したとおり『ライザのアトリエ』2と3で使えるメカニズムです。

『ライザのアトリエ』では、

『ゼッテル』によるループを挟みます。

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のアイコンを使用する」にチェックを入れて保存します。

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

Page 1 of 3

Powered by WordPress & Theme by Anders Norén