前回、難易度を下げて挑戦した「陽炎の島」。
早速、今後の攻略の鍵となる良質な特性が見つかったので調合していきます。
必要な特性「エコノミーコア」は幻獣の毛皮に付与されていました。
を持っているため、「マナランタン」の「神秘の力」のスロットに投入して調合していきます。
の特性を付与。（燃料）付与も忘れずに行います。
こうして得たマナランタン（燃料）を中和剤・赤の素材にします。
後は中和剤ループ。
レベルのある特性は 99まで上昇しました。
このテクニックは『ライザのアトリエ』からの伝統なので、ここでも使います。
調合メニューからゼッテルを開き、中和剤のマテリアル環に
が付与された中和剤を投入。
泡立つ水を入れ、そのまま旅人の水珠へとレシピ変化をします。
そこから調合を進め
更に使いやすく「水」として加工しました。
ここまで来れば他の材料に更に調合しやすくなります。
自分のブログで継続して読まれているこの記事を、再攻略とともに更に検証を深めていこうと思います。
超高難易度DLCを謳うだけあって、その難易度は尋常ではありません。
反面、利点は
の2点。特に以下に代表される特性は魅力的です。
『陽炎の島』攻略に向けての方針は
です。また、それに応じて高品位の武器が必要になるので、実質的にDLC
は必須です。
では、攻略の準備を進めていきます。
これが一番重要です。
Easyでも全滅する場合があるため、以下の判断基準を筆者にて用意しました。
クリア後、「霊なる竜の棺」の「魂の眠りし場所」に転送器が活性化されています。
ここの奥に鎮座する敵を倒してみましょう。実績対象だけあって、ラスボス以上の強さの敵です。
以下、筆者の体感となる基準です。
すべてを見直すため、採取を頻繁に行います。そのため、コンテナ容量5000はすぐに埋まります。
ゲーム初期に得ていた低品質の素材は
などにしてインベントリを減らしていきます。
上記の前提や準備が揃ったら、いよいよ攻略開始です。
なお、本検証では、2023年のセーブデータは参照に留め、まっさらなデータであることを付記しておきます。
インゴット系の最上位種、グランツオルゲン。
『ライザのアトリエ2』では「ロミィの店でセプトリエンを売ることでショップに登録される」システムですが、
本格的な調合はラストダンジョンまで待つ必要があります。
なぜなら、必須材料である異界結晶がラストダンジョンの敵のドロップアイテムだからです。
これを手に入れてしまえば後は調合。
『ライザのアトリエ2』でのグランツオルゲンの調合は
「ゴルドテリオン」からのレシピ変化です。これ自体も元を辿っていくと
と変化していきます。
調合メニューからインゴットを選びます。
特性を選びます。
こちらの通り、中和剤の特性ループにより
を持たせた（鉱石）が付与された中和剤・黄を入れていきます。
上記例ではここのマテリアル環の活性化条件は氷属性のアイテム。
ですが、活性化されていない状態でも「特性入りの素材が入った」ことは調合中に記憶されます。
逆に言えば、レシピ変化を伴う調合中、最終段階（変化を終えた状態で）の調合で特性枠を活性化させないと意味がありません。
他の材料を入れていき、スタルチウムへとレシピ変化。
途中、影響拡大を持つアイテムで「材料を入れることなくマテリアル環の活性化」を図っていき、
クリミネア → ゴルドテリオン
と材料を入れていきます。
ゴルドテリオンのマテリアル環に「異界結晶」を入れるスロットが出てくるので、投入。
グランツオルゲンの「効果1」並びに「効果2」に、その属性に対応したエッセンスを入れます。
これにより、効果テーブルが1段階上がります。活性化までの属性値は上昇しますが、効果が更に上がります。
こうして、グランツオルゲンでの特性枠を埋めたら調合完了。
の効果を持ち、
の特性を持たせたインゴット素材「グランツオルゲン」が完成です。
ユミアの攻略に少し余裕が出てきたので、こちらに軸を移します。
以前に書いた
これらの記事を更に初心者向けに解説したものです。
すごくさっくり言うと
「素材（調合アイテム含む）にあり、調合するアイテムに付与するもの」
です。
など、プラスの効果を与えます。
一例を見てみましょう。
この武器「ノクターナルレリック」は特性を持たせる前のステータスは
となっていますが、ここに
を付与します。
とステータスアップしていることが分かります。
特性の多くはレベル制を採用しており、レベルが高ければ高いほどその恩恵に与れます。
このレベルは調合時に加算されます。
先の「全能力強化++ Lv.3」と「全能力強化++ Lv.10」を持つ素材を調合することで「全能力強化++ Lv.13」となるという足し算。
しかし、大概の素材は特性レベルがそれほどありません。なので、「調合による特性のレベルアップ」を行っていきます。
この特性レベルアップのキーとなるのが中和剤。4色(赤・青・黄・緑）とある中で、一番分かりやすい赤を見てみましょう。
中和剤のマテリアル環（素材を入れるスロット）には火薬を入れるよう指示されています。
その先のマテリアル環には「（火薬）付与」の言葉があります。
つまり、
ことで、このレベルアップが達成できます。
破壊力上昇++ を絞り込みで検索。
破壊力上昇 ++ Lv.10を持つ素材が見つかりましたので、これを投入。
回復力上昇++ 等も入れていきます。
いざ、特性を選ぶ段で
3つある特性のうち
がロックされていることが分かります。これは、
マテリアル環の「特性枠」が活性化されていないためです。いくらいい特性を持たせても、「特性枠」を活性化させないと上記のループは意味を成しません。
そうした上で活性化させ、特性を選択させます。このレベルアップの「ループ」の基本となる中和剤が完成。
こうしてできた中和剤は基本的に4つほど。この「4つ」というのがポイントです。
再び調合メニューから「中和剤・赤」を選択して、火薬のスロットに、上述した基本となる中和剤をいれます。
左上の特性枠には
となっています。この段階でループが完成。あとは、レベルの上限になるまでこのループを達成させます。
最初のレベルが1であっても、
1 → 4 → 16 → 64...
といった具合で飛躍的に上がっていきます。
こうしてできあがった中和剤・赤が
となります。
また、中和剤・赤の効果の一つに（燃料）付与もあるため、
火薬や燃料を必要とする他の素材へと転用が可能です。
※全ての効果を活性化させた場合です。
が付与されます。「花」のスロットに中和剤・青を入れることでループを行えます。
が付与されます。「鉱石」のスロットに中和剤・黄を入れることでループを行えます。
が付与されます。「木材」のスロットに中和剤・緑を入れることでループを行えます。
これらの中和剤ループを念頭に置いておくだけでも、本作の攻略の難易度は大きく変わります。
この中和剤ループはタイトルで示したとおり『ライザのアトリエ』2と3で使えるメカニズムです。
『ライザのアトリエ』では、
『ゼッテル』によるループを挟みます。
前に書いたこちらの記事を、よりステップを追うと共に実運用に沿って記述したものです。
以下が必須です。
また、Redmineのディレクトリを
/home/www-data/redmine
としていますので、自分の環境に合わせてください。
本記事により、以下のリスクが発生します。
そのため、この作業は細心の注意を払ってください。
どういう方法で認証をするかは運用に合わせてください。
【】内は、自分の環境に合わせます。
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サービスに合わせます。
以下を設定して「保存」をクリックします。
以上で、設定は完了です。
新しいサーバー（VPS）からの最初のログインは、Googleによって「不審なログイン試行」と見なされ、一時的にブロックされることがあります。
その場合、Gmailアカウントの受信トレイに「セキュリティ通知」メールが届いているはずです。メールの内容に従い、「はい、心当たりがあります」などの操作を行って、アクセスを許可してください。
RedmineサーバーからGmailのSMTPサーバーに到達できるかを確認します。SSHで以下のコマンドを実行します。
telnet smtp.gmail.com 587Connected to smtp.gmail.com.のように表示されれば、ネットワーク的な接続は問題ありません。（終了するには quit と入力します）
先日の記事でgitを用いたmod-securrity core rule setのアップデートを行いました。
このアップデートにより新たに検知されたルールの対処を行います。
OWASP Core Rule Set (CRS) を導入したModSecurityをブロックモード（SecRuleEngine On）に切り替え後、
Apacheのエラーログに、これまで見られなかった Execution error - PCRE limits exceeded (-47) というエラーが大量に記録されていることを発見しました。
[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万件近いログを検知。
複雑な正規表現を、非常に大きなデータ（Webページなど）に対して実行すると、サーバーのCPUやメモリを大量に消費し、サービス拒否（DoS）攻撃に繋がる危険性があります。これを防ぐため、ModSecurityには処理の複雑さや再帰の深さに上限（リミット）が設けられています。
今回のエラーは、サーバーが返信するHTMLページ（レスポンスボディ）の内容を、情報漏洩がないか確認するルールがスキャンしようとした際に、そのWebページの内容が非常に大きい、または複雑であったため、PCREの処理上限値を超えてしまったことが原因です。(筆者のサイトの長文が災いしています)
この、処理上限値を超えてしまったことでエラーが発生したのですからmodsecurity.confでSecPcreMatchLimitの値を大きくすると言うのが考えられる対処ではありますが、
運用しているサイトのvpsのリソースを鑑みて、より簡便な「原因となっている特定のルールのみの無効化」を行いました。
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 951250diff -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 951250sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
対処後、ターミナルで
tail -f /var/log/apache2/hoge/error.log |grep "PCRE limits"を実行し、しばらく観察します。
このエラーが表示されないことを確認し、処置が完了です。
こちらの方法で導入したMod-Security（WAF）。
この防御ルールであるOWASP Core Rule Setの更新を行います。
/etc/apache2/sites-available配下の.confファイルアップデートにより
などがあるため、今までと同じ作業をしていたのにWAFがブロックした（あるいは今までブロックされていたアクセスがスルーした）などは可能性としてあります。
なので、
という作業を取ります。そのため、WAFの防御が一度無効化される時間が発生します。
環境や予算が許すなら、インターネットに公開された別環境で試してからの方が良いでしょう。
→ テストが済んでいる状態であれば、本番環境で「ModSecurityをオフにする」の作業は不要になります。
cd /etc/apache2/sites-available && pwdsudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.yyyymmdddiff -u /path/to/backup/directory/hoge.conf.yyyymmdd hoge.conf差分が無いことを確認します。
通常、筆者は$(date +%Y%m%d)変数を用いてバックアップを行いますが、「検知モードでの試験」は日をまたぐこともあるため、この形式にしています。
hoge.confファイルを管理者権限で修正。
SecRuleEngine Onから
SecRuleEngine DetectionOnlyに変更し、保存します。
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf以下の差分を確認します。
- SecRuleEngine On
+ SecRuleEngine DetectionOnlysudo apache2ctl configtestSyntax OKを確認します。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.service※設定ファイルの修正のみのためreloadで十分ですが、念を入れてrestartにしています。（以下同じ）
systemctl status apache2.serviceactive(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)ディレクトリ一式があることを確認します。
cd /usr/share/modsecurity-crs/coreruleset && pwdsudo git fetch originsudo 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") コミット内容が大幅に変わっているので、上述した「検知モードで様子見にする」が活きてきます。
sudo git pullこれで、OWASP Core Rule Setが最新版に変更されました。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
その後、既存のWebシステムに問題が無いかを確認します。
tail -f /var/log/hoge/hoge_error.log等として、通常の作業を行い
等を確認し、それに応じて新たな偽陽性の除外などを行っていきます。
アップデートの影響で既存サービスに問題が無いことが判明したら、再びModSecurityを有効化します。この例では、バックアップから.confファイルを切り戻します。
cd /etc/apache2/sites-available && pwdsudo cp -pi /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.confsystemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
その後、既存のWebシステムに問題が無いかを確認します。
新たに偽陽性を追加した、既存のファイルを削除した、またはそれに伴う設定変更を行ったことにより、バックアップ前と.confファイルが異なるケースはあります。
その場合は、.confファイルの
SecRuleEngine DetectionOnlyを
SecRuleEngine Onと修正した後で以下の作業を行います。
sudo apache2ctl configtestSyntax OKを確認します。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
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`
として仕込みます。
起動時にメモリ量やスワップ量を検査。
警告が出れば、再起動の検討やプロセスの見直しなどを行うことができます。
公開用Redmine
のバージョンを5.1.4→5.1.8にアップデートしたときのメモです。
などで動かしている場合は、この段階でシステム全体のバックアップ（スナップショット）を取ることを強く推奨します。
cd /hoge && pwd任意のディレクトリを指定します。
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sqlDB名やDBユーザは自分の環境に合わせます。
view redmine_backup.$(date +%Y%m%d).sqlDBが平文で読めることを確認します。
cd /var/lib && pwdRedmineが格納されているディレクトリの親ディレクトリに移動します。（筆者環境は/home/www-data)
ls -ld redmine退避対象のディレクトリがあることを確認します。ディレクトリ名は自分の環境に合わせます。
sudo mv redmine redmine_$(date +%Y%m%d)ls -ld redmine_$(date +%Y%m%d)ディレクトリがあることを確認します。
念のため、apacheを停止します。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl stop apache2.servicesystemctl status apache2.serviceinactive(dead)を確認します。
sudo mkdir /var/lib/redminesudo chown -R www-data:www-data /var/lib/redminels -ld redmineディレクトリがあることと、所有者がwww-dataであることを確認します。
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.1-stable /var/lib/redmine5.1系の最新安定版をダウンロードします。
sudo -u www-data cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/database.yml /var/lib/redmine/config/database.ymlcat /var/lib/redmine/config/database.yml待避したファイルの内容であることを確認します。
sudo -u www-data cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/configuration.yml /var/lib/redmine/config/configuration.ymlcat /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をコピーして下さい。
cd /var/lib/redmine && pwd自分の環境に合わせます。
sudo rm -rf filessudo rm -rf logsudo ln -sf /mnt/wasabi/redmine/files files自分の環境に合わせます。
sudo chown -h www-data:www-data filesls -l filesを確認します。
sudo ln -sf /var/log/redmine logsudo chown -h www-data:www-data logls -l logを確認します。
cd /var/lib/redmine自分の環境に合わせます。
sudo -u www-data bundle install --without development test --path vendor/bundlesudo -u www-data bundle exec rake generate_secret_tokensudo -u www-data RAILS_ENV=production bundle exec rake db:migratesudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=productionsudo -u www-data RAILS_ENV=production bundle exec rake tmp:cache:clearsudo -u www-data RAILS_ENV=production bundle exec rake tmp:sessions:clearsystemctl status apache2.serviceinactive(dead)を確認します。
sudo systemctl start apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
この状態でRedmineに管理者権限でログインします。手順通りなら
などが有効に動いていて、正常に稼働します。
/var/lib/redmine_$(date +%Y%m%d)一式を削除、または任意の方法でバックアップします。
bundle install が終わらないInstalling... の表示で止まっているように見えても、実際にはCPUを消費して動作していることがある（ネイティブ拡張機能のコンパイル）。topコマンドでcc1plusなどのプロセスが動いていないか確認する。
Redmineのアプリケーション起動エラー。原因はログに記録されている。
/var/lib/redmine/log/production.log を確認する。/var/log/apache2/error.log を確認する。Overwriting existing method 警告など)。base64の競合など)。この場合は、Gemfileでバージョンを明示的に指定するなどの対策が必要。こちらのように、サイトアイコン(favicon)をRedmineに設定するメモです。
www-dataで実施しています。（Redmine 6.xはディレクトリ構造が異なります）
favicon.pngやfavicon.icoを用意します。sudo chown www-data:www-data favicon.png など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 && pwdfaviconディレクトリにいることを確認します。
sudo -u cp -pi /hoge/favicon.png ./上記、転送した際のディレクトリを指定します。
この後、ブラウザをリロードしてアイコンが変わっていることを確認できれば設定完了です。
Powered by WordPress & Theme by Anders Norén