投稿者: manualmaton Page 4 of 259

Redmine Knowledgebase プラグイン (v5.0.0) on Redmine 5.1 (Ruby 3.2+, Rails 6.1+) インストール・マイグレーション手順

自分にとってのキラープラグインと言えるRedmine Knowledgebase。

これをRedmine 5.1に導入する際に恐ろしくハマったので、解決したときのメモです。

なお、本件の解決にはGoogle Gemini Advanced(2.5 Pro preview)の助けが必要でした。

環境

  • Ubuntu 24.04
  • Redmine 5.1.x
  • Apache 2.4で稼働
  • Ruby 3.2.x (本手順は Ruby 3.2.3 で確認)
  • Rails 6.1.x (本手順は Rails 6.1.7.10 で確認)
  • データベース: MySQL 8.0 (他のデータベースでも同様の問題が発生する可能性があります)
  • プラグインソース: alexbevi/redmine_knowledgebase

盛大にハマった結果で得た手順

  1. DBのバックアップを取得します。
  2. プラグインのインストールを行います。
  3. マイグレーションエラーに対応します。
  4. マイグレーションの成功を確認します。
  5. Redmine(Webサービス)を再起動します。
  6. プラグインのインストールと動作確認を行います。

バックアップを取得します。

  • 作業ディレクトリに移動
cd /hoge && pwd

任意のバックアップディレクトリに移動します

  • mysqldumpによるバックアップ
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql

それぞれ-h ホスト名 -u redmine -p ユーザ オプション db名です。パスワードはRedmineインストール時に設定したDBユーザのものです。

環境が許すなら、VPSのスナップショットのようにシステム全体のバックアップを取ることを強く推奨します。

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

  • Redmineのプラグインディレクトリに移動
cd /path/to/redmine/root/directory/plugins && pwd

筆者環境/home/www-data/redmine/plugins

  • git clone
sudo -u www-data git clone https://github.com/alexbevi/redmine_knowledgebase

Redmineの実行ユーザでgit cloneとした方が、後にsudo chownする手間が省けます。

  • clone確認
ls -l redmine_knowledgebase

ファイル一式があることと、ファイル群の所有者がwww-data(Redmineの実行ユーザ)であることを確認します。

  • Redmineのルートディレクトリに戻ります。
cd /path/to/redmine/root/directory/plugins && pwd

筆者環境/home/www-data/redmine/

  • (必要に応じて)依存関係をインストールします。
sudo -u www-data bundle install

初回マイグレーション実行 (エラー発生との対処)

以下のコマンドでプラグインのマイグレーションを実行します。このとき、壮大にハマったので、AIの力を借りて(というよりもほぼその指示に従って)解決しました。

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production --trace

マイグレーションエラーの修正

エラーが発生した場合は、以下の手順で関連ファイルを修正し、その都度上記 redmine:plugins:migrate コマンドを再実行してください。

修正箇所1: 20121205100143_add_versioning.rb ファイルの対応

このマイグレーションでは、以下の2つのエラーが連続して発生する可能性があります。

  • Mysql2::Error: Duplicate column name 'version_comments' (in kb_articles table)
  • ArgumentError: wrong number of arguments (given 2, expected 1) (in KbArticle.create_versioned_table 内部の create_table 呼び出し)

対象ファイルA: plugins/redmine_knowledgebase/db/migrate/20121205100143_add_versioning.rb

以下に従って修正していきます。

  • 修正前の class AddVersioning ... end の内容(主要部分):
  class AddVersioning < ActiveRecord::Migration
    def self.up
      KbArticle.create_versioned_table
      add_column :kb_articles, :version_comments, :string, :limit => 255, :default => ""
    end

    def self.down
      remove_column :kb_articles, :version_comments
      KbArticle.drop_versioned_table
    end
  end
  • 修正後の class AddVersioning ... end の内容:
  class AddVersioning < ActiveRecord::Migration[6.1] # Rails 6.1 互換にする
    def self.up
      # kb_article_versions テーブルが存在しない場合のみ作成
      unless ActiveRecord::Base.connection.table_exists?(:kb_article_versions)
        if defined?(KbArticle) && KbArticle.respond_to?(:create_versioned_table)
          KbArticle.create_versioned_table # この呼び出しは次の acts/versioned.rb の修正が必要
        else
          # このエラーは通常発生しないはずだが、念のため
          raise "Cannot create kb_article_versions: KbArticle model or create_versioned_table method is not available."
        end
      end

      # kb_articles テーブルに version_comments カラムが存在しない場合のみ追加
      unless column_exists?(:kb_articles, :version_comments)
        add_column :kb_articles, :version_comments, :string, :limit => 255, :default => ""
      end
    end

    def self.down
      if column_exists?(:kb_articles, :version_comments)
        remove_column :kb_articles, :version_comments
      end
      if ActiveRecord::Base.connection.table_exists?(:kb_article_versions)
        if defined?(KbArticle) && KbArticle.respond_to?(:drop_versioned_table)
          KbArticle.drop_versioned_table
        end
      end
    end
  end

対象ファイルB: plugins/redmine_knowledgebase/lib/active_record/acts/versioned.rb

KbArticle.create_versioned_table が内部で呼び出す create_tableArgumentError が発生します。このファイルを修正します。

  • 修正対象箇所 (ファイル内の create_versioned_table メソッドの中、通常503行目あたり):
  # 修正前
            self.connection.create_table(versioned_table_name, create_table_options) do |t|

Ruby

  # 修正後 (create_table_options の前に ** を追加)
            self.connection.create_table(versioned_table_name, **create_table_options) do |t|

上記AとBの両ファイルを修正後、再度以下を実行しましたが、エラーが発生しました。

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production --trace
修正箇所2: 20150326093122_add_taggings_counter_cache_to_tags.rb ファイルの対応

次のエラーとして NameError: uninitialized constant ...::RedmineCrm が発生する可能性があります。

対象ファイル: plugins/redmine_knowledgebase/db/migrate/20150326093122_add_taggings_counter_cache_to_tags.rb

  • 修正前の class AddTaggingsCounterCacheToTags ... end の内容(主要部分):
  class AddTaggingsCounterCacheToTags < Rails.version < '5.1' ? ActiveRecord::Migration : ActiveRecord::Migration[4.2] # 古い形式
    def self.up
      RedmineCrm::Tag.reset_column_information
      # ... (RedmineCrm::Tag を参照するコードが続く) ...
    end
    def self.down
      # ... (関連する可能性のある remove_column など) ...
    end
  end
  • 修正後の class AddTaggingsCounterCacheToTags ... end の内容:

(Redmine Crmプラグインを使用していない場合、関連処理をスキップします)

  class AddTaggingsCounterCacheToTags < ActiveRecord::Migration[6.1] # Rails 6.1 互換にする
    def self.up
      puts "INFO: Skipping 'up' method in 20150326093122_add_taggings_counter_cache_to_tags.rb due to missing RedmineCrm module or intentional skip."
      # 元の RedmineCrm::Tag に関連する処理は全てコメントアウトまたは削除
    end

    def self.down
      puts "INFO: Skipping 'down' method in 20150326093122_add_taggings_counter_cache_to_tags.rb."
      # 元の remove_column 処理なども、up で対応する処理を行わないためコメントアウトまたは削除
    end
  end

上記ファイルを修正後、更に以下を実行します。

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production --trace

これらの手順で、ようやく、

  • コンソールにエラーメッセージが出ないこと
  • db:schema:dumpがログに出力されること

を確認しました。

マイグレーション完了の確認

念のため、

mysql -u root -p

としてMySQLコンソールにログイン。

USE DATABASE redmine;

(自分が使っているRedmineのDBを指定します)

  • kb_article_versionsテーブルの確認
SHOW TABLES LIKE 'kb_article_versions';
DESCRIBE kb_article_versions;
DESCRIBE kb_articles;

それぞれ、テーブルが作成されていること、kb_articles テーブルに version_comments カラムが存在すること、および content カラムの型が変更されていること(ChangeColumnArticleToLongText マイグレーションによる)を確認します。

Redmineの再起動

ここではWebサービス(Apache)の再起動を前提とします。

  • 稼働前確認
systemctl status apache2.service

active(running)を確認します。

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

active(running)を確認します。

プラグインの動作確認

Redmineにログインし、ナレッジベースプラグインの各機能

  • 記事の作成
  • 編集
  • 表示
  • バージョン管理
  • ファイル添付

などが正常に動作するか確認してください。

注意点:

  • 上記の手順は、特定のバージョンの組み合わせで発生した問題への対処法です。プラグインやRedmineのバージョンが異なる場合は、別の問題が発生したり、異なる修正が必要になる場合があります。
  • 途中でマイグレーションが認識されなくなるなどの不可解な問題が発生した場合は、一度プラグインディレクトリを削除し、データベースをリストア(または関連テーブルを手動削除)、再度GitHubからクリーンにクローンし直してから上記手順を開始すると、問題が解消されることがあります。

おまけ:切り戻し手順

この手順で成功したとはいえ、失敗はつきものです。そのため、以下に切り戻し手順を記します。

通常の切り戻し

ディレクトリ移動

  • Redmineのルートディレクトリに戻ります。
cd /path/to/redmine/root/directory/plugins && pwd

筆者環境/home/www-data/redmine/

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

sudo -u www-data bundle exec rake redmine:plugins:migrate NAME=redmine_knowledgebase VERSION=0 RAILS_ENV=production

ディレクトリ削除

sudo rm plugins/redmine_knowledgebase -Rf

Webサービス再起動

  • 稼働前確認
systemctl status apache2.service

active(running)を確認します。

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

active(running)を確認します。

それでもダメだった切り戻し(DBリストア)

  • DBをバックアップしたディレクトリに移動
cd /hoge && pwd
  • DBリストア
mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql

パスワードはredmineインストール時に設定したDBユーザのものです

  • 稼働前確認
systemctl status apache2.service

active(running)を確認します。

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

active(running)を確認します。

再起動後、復旧しているかを確認します。

『ユミアのアトリエ』特性結晶「質の力」合成メモ。(ネタバレあり)

はじめに

特性結晶「質の力」は、アイテムの品質や使用者のレベルに応じて威力が大きく上昇する強力な効果を持ち、便利な特性結晶です。

装備可能なアイテム

  1. 攻撃アイテム
  2. 強化アイテム
  3. 回復アイテム
  4. 弱体化アイテム

【インレンジ効果】 アイテムの品質に応じて威力が増加。最大200%/品質999

【アウトレンジ効果】 使用者のLvに応じて威力が増加。最大100%/Lv100

最初の結論

  • 見た目よりも大変なステップを踏みます。
  • 便利で強力とは言え、通常の難易度ではオーバーキル気味の特性となります。
  • これを複数作るには、余程ではない限りオススメしません。
    • これがまだ有効なうちに増やしておくのオススメです。

前提

この特性結晶を合成するためには、まずスキルツリーから特性理解を最大まで上げておきます。

さっくりとは言い難い手順

  1. 基本となる特性結晶を入手します。(ドロップ限定の結晶が多いです)
  2. 特性「質の力」の材料となる結晶を合成していきます。
  3. 特性「質の力」を合成します。

ステップ1:基本特性の収集

まず、以下の特性を持つアイテムをそれぞれドロップで入手する必要があります。ここが一番大変でした。

  • 〔攻撃/弱体〕破壊力上昇+
  • 〔攻撃/弱体〕シングルブースト
  • 〔攻撃/強化/回復/弱体〕CT短縮 (複数個利用します)
  • 〔攻撃/強化/回復/弱体〕アイテム使用回数増加
  • 〔攻撃/弱体〕マルチブースト
  • 〔武器〕ぷに特攻
  • 〔武器〕ミミズク特攻
  • 〔武器〕ナエギ特攻
  • 〔攻撃/弱体〕毒付与
  • 〔攻撃/弱体〕睡眠付与
  • 〔攻撃/弱体〕火傷付与
  • 〔攻撃/弱体〕麻痺付与
  • 〔攻撃/弱体〕凍傷付与
  • 〔攻撃/強化/回復/弱体〕インレンジ強化
  • 〔攻撃/強化/回復/弱体〕アウトレンジ強化

ステップ2:「観察眼」の特性を持つアイテムの合成

次に、ステップ1で収集した特性を用いて、特性「観察眼」を合成します。

「観察眼」の合成に必要な特性(アイテム):

以下の5種類の特性を持つアイテムのうち、

いずれか4種類

を使用して合成します。

  1. 特性「毒付与」
  2. 特性「睡眠付与」
  3. 特性「火傷付与」
  4. 特性「麻痺付与」
  5. 特性「凍傷付与」

ステップ3:「質の力」の中間の合成

ステップ1で収集したドロップ限定特性を持つアイテムと、ステップ2で合成した「観察眼」の特性を持つアイテムを使って、「質の力」の合成に必要となる以下の4つの特性を持つアイテムをそれぞれ合成します。

特性「簡易化」合成

  • 特性「破壊力上昇+」(ステップ1で入手)
  • 特性「シングルブースト」(ステップ1で入手)

特性「複雑化」合成

  • 特性「CT短縮」(ステップ1で入手)
  • 特性「アイテム使用回数増加」(ステップ1で入手)
  • 特性「破壊力上昇+」(ステップ1で入手)
  • 特性「マルチブースト」(ステップ1で入手)

特性「博識」 合成

  • 特性「ぷに特攻」(ステップ1で入手)
  • 特性「ミミズク特攻」(ステップ1で入手)
  • 特性「ナエギ特攻」を持つアイテム(ステップ1で入手)
  • 特性「観察眼」を持つアイテム(ステップ2で合成)

特性「アイテム使い」合成

  • 特性「CT短縮」(ステップ1で入手)
  • 特性「アイテム使用回数増加」(ステップ1で入手)
  • 特性「インレンジ強化」(ステップ1で入手)
  • 特性「アウトレンジ強化」(ステップ1で入手)

ステップ4:特性結晶「質の力」の合成

最後に、ステップ3で作成した4つの特性(「簡易化」「複雑化」「博識」「アイテム使い」)を素材として、目的の特性結晶「質の力」を合成します。

  1. 特性「簡易化」(ベース)
  2. 特性「複雑化」
  3. 特性「博識」
  4. 特性「アイテム使い」

まとめ

  1. 基本となる特性結晶をドロップや宝箱などからで全て集める。
  2. 集めた素材(5種類のうち4種類)から「観察眼」を合成する。
  3. ドロップ限定特性と「観察眼」を使って、「簡易化」「複雑化」「博識」「アイテム使い」をそれぞれ合成する。
  4. 最後に、4つの上位特性を使って「質の力」を合成する。

この、1が特に大変なステップ。

身も蓋もない言い方ではありますが、改めて手順化すると

  • ここまでやらなくても通常の難易度であれば十分対応可能。
  • 高難易度で敵を倒したい
  • ダメージ検証に役立てたい

方向けの結晶の作り方でした。

Let’s Encrypt仕様変更によるSSL Staplingの無効化

新たなSSL証明書を導入したサーバにて、以下のエラーを確認。こちらの解決のメモです。

前提

  • Ubuntu 24.04
  • Apache 2.4
  • Let's Encryptによるワイルドカード証明書を発行

エラー内容

サイトのエラーログに以下を発見しました。

[Thu May 22 14:03:51.270340 2025] [ssl:error] [pid 929:tid 929] AH02218: ssl_stapling_init_cert: no OCSP URI in certificate and no SSLStaplingForceURL set [subject: CN=*.ryza.jp / issuer: CN=E6,O=Let's Encrypt,C=US / serial: 058A8F3B6C32F08B41E5E56BEAD92451D34A / notbefore: May 21 12:08:57 2025 GMT / notafter: Aug 19 12:08:56 2025 GMT]
[Thu May 22 14:03:51.270358 2025] [ssl:error] [pid 929:tid 929] AH02604: Unable to configure certificate atelier.ryza.jp:443:0 for stapling 
  • 意味:
  • ApacheがSSL証明書 (CN=*.ryza.jp) のOCSP Staplingを初期化しようとしましたが、証明書内にOCSPレスポンダのURI(OCSP URI)が見つかりませんでした。また、Apacheの設定で SSLStaplingForceURL も指定されていません。
  • OCSP Staplingとは:
  • SSL証明書の失効状態を効率的に確認するための仕組みです。ウェブサーバーが事前にCA(認証局)に問い合わせて証明書の有効性を確認し、その応答(OCSPレスポンス)を証明書と一緒にクライアントに提供することで、クライアント側の確認負荷を軽減し、表示速度を向上させます。

なお、Apacheの.confファイルには以下の項目があります。

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

つまり、ApacheでSSL Stapling設定されているにもかかわらず、OCSPレスポンスが働いていないことを意味します。

状況確認

現行の証明書の状況

openssl x509 -in /path/to/your/certificate.pem -noout -ocsp_uri

結果は何もなし。証明書内にこれがないことで、先のエラーが発生したようです。

過去にLet's Encryptで発行した証明書の状況

2024年9月に発行したLet's Encryptの証明書で

openssl x509 -in /path/to/your/certificate.pem.202409 -noout -ocsp_uri

を実施したところ、http://e6.o.lencr.orgと返ってきました。

導き出される状況

  • 証明書発行時に何らかのエラーが発生して、このURIが欠落した
  • 筆者は他に複数のドメインを利用し、いずれもLet's Encryptで証明書を発行しています。1つだけならいざ知らず、現行全てのドメインでの証明書でこのURLが欠落しているのは一時的なエラーではないと考えました。

そこで、もう一つの可能性として「Let's Encryptの仕様が変わったのでは?」と情報を探していきます。

答えを発見

Removing OCSP URLs from Certificates from Let's Encrypt

Let’s Encrypt will be removing OCSP URLs from certificates on May 7, 2025 as part of our plan to drop OCSP support and instead support certificate revocation information exclusively via CRLs.
Let's Encryptは、2025年5月7日にOCSPのサポートを停止し、代わりにCRLを介してのみ証明書の失効情報をサポートする計画の一環として、証明書からOCSP URLを削除します。

状況そのもののアナウンスを見つけました。この、OCSPのURLが消えた証明書は、いずれも、2025年5月18日以降に発行したものです。完全に時期的に一致。

対処

ここが分かれば、後は設定変更です。Ubuntuサーバで設定を変更します。

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

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

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

差分がなければバックアップ完了です。

  • ファイル編集

任意の方法で(要管理者権限)以下のように編集します。

# 2025年5月のLet's Encryptの方針によりOCSPが廃止されたため
SSLUseStapling Off
#SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
  • 編集確認
diff -u /path/to/backup/directory/virutal.conf.$(date +%Y%m%d) /etc/apache2/sites-available/virutal.conf
-SSLUseStapling On
-SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
+# 2025年5月のLet's Encryptの方針によりOCSPが廃止されたため
+SSLUseStapling Off
+#SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

active(running)を確認します。

  • Apache再起動
sudo systemctl restart apache2.service

※reloadより確実なrestartを採用しています

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

active(running)を確認します。

修正確認

設定を反映させたサイトを適当に閲覧し、エラーログにて、冒頭のエラーがないことを確認しました。

Redmineのマルチドメインのメモ。

公開用Redmine等で取得しているreisalin.com。今回、新たに「ryza.jp」を取得しました。

そこで、「1つのRedmineサイトに対して、別のドメインからアクセス可能にする」方法を取ったのでメモに残します。

やったこと

の両方からアクセスできるようにする。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Redmine 5.1
  • (DB等は割愛)

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

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/19

準備

  1. DNS設定で、両方のドメインから同一のIPが引けるように設定を行いました。
  2. ワイルドカード証明書を取得しました。

実施手順

ディレクトリ移動

cd /etc/apache2/sites-available && pwd

ファイルコピー

sudo cp -pi atelier.conf atelier_ryza.jp.conf

ファイル編集

  • 主な編集
-servername atelier.reisalin.com
+servername atelier.ryza.jp
  RewriteEngine On
         RewriteCond %{HTTPS} off
         RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

-    CustomLog /var/log/atelier/atelier_access.log combined env=!dontlog
+    CustomLog /var/log/atelier_ryza/atelier_access.log combined env=!dontlog

-SSLCertificateFile /etc/certs/reisalin.com.crt
-SSLCertificateKeyFile /etc/private/reisalin.com.key
+SSLCertificateFile /etc/certs/ryza.jp.crt
+SSLCertificateKeyFile /etc/private/ryza.jp.key

かなり単純な編集です。すなわち、コピーした後で

  • servernameを変える
  • ログの出力先を必要に応じて追加する
  • 証明書と秘密鍵をドメインに応じたものに変える

.conf有効化と反映

  • .conf有効化
sudo a2ensite atelier_ryza.jp.conf
  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

Webサービス再起動

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

active(running)を確認します。

  • サービス再起動
sudo systemctl restart apache2.service && $?

0を確認します。

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

active(running)を確認します。

確認

以下、両方のサイトにアクセスします。

それぞれで同じコンテンツが見えればOKです。

備考

なぜ、このマルチドメインがうまくいったか?

Redmineのプログラムが、内部処理としてURLを参照しないというある種のおおらかさに救われました。また、リンクの参照なども(明示しない限りは)相対パスで記述されるため、混乱も少なかったと思います。

これが、他の(特にLalavelフレームワークのようなPHP環境)だとAPP_URLが関係するため、両立は今回のように上手くいきません。別途、リバースプロキシーを立てるなどの配慮が必要です。

『ユミアのアトリエ』ラクーナ地方のメインシナリオ完了までにアクセス可能な宝物庫一覧。(ネタバレあり)

宝物庫、ラクーナ地方は5つのみ。とはいえ、2つほど開拓任務で必要な宝物庫があります。

なお、この地方に宝物庫の鍵はありません。他3つの地方で探します。

皇陵区

  • 宝箱1:
    • 【家具】遺構風の土台(床など)
  • 宝箱2:
    • 《装備品》アナザーメモリー
  • 宝箱3:
    • 《使用アイテム》エンデメテオ
備考

遺構風の家具の設計書(床や土台)が一気に手に入ります。

政治区・東

  • 宝箱1:
    • 《使用アイテム》栄冠のメルクマール
  • 宝箱2:
    • 【家具】天井飾りB
    • 《使用アイテム》輪廻の生命石
  • 宝箱3:
    • 《使用アイテム》デスグラシア

政治区・南※開拓任務・ノーマルクエストで必要な宝物庫※

  • 宝箱1:
    • 《使用アイテム》グランシャイン
  • 宝箱2:
    • 《使用アイテム》スペリオルグリモア
    • 【家具】遺構風壁セット(エクステリアや階段など含む)
  • 宝箱3:
    • 【家具】プレハブ小屋
    • 《使用アイテム》天啓のアーミラリ

政治区・北

  • 宝箱1:
    • 【家具】遺構風屋根セット
    • 《装備品》不動八満
  • 宝箱2:
    • 【家具】スイッチB
    • 《装備品》オーバーテイカー
  • 宝箱3:
    • 《装備品》道化師の仮面

[LM]哨戒街道・南※開拓任務で必要な宝物庫※

  • 宝箱1:
    • 【家具】掲示板
    • 《装備品》トリリオンロケット
  • 宝箱2:
    • 【家具】リゾートベッド
    • 《調合アイテム》グランツオルゲン×3
  • 宝箱3:
    • 《調合アイテム》セージコート×3
備考
  • 家具「リゾートベッド」は開拓任務で必要になります。

『ユミアのアトリエ』アウルーマ地方のメインシナリオ完了までにアクセス可能な宝物庫一覧。(ネタバレあり)

これらの記事の続き、アウルーマ地方のメインシナリオ完了までにアクセス可能な宝物庫の一覧です。

  • アウルーマ地方:20
  • シバーシュ地方:2

と、かなりの数になっています。

[LM]ラムスヴィーア丘陵・南 ※開拓任務(開拓クエスト)で必要な宝物庫※

  • 宝箱1:
    • 【家具】妖精さん人形
      • 開拓クエストの選択肢でもこれを設置するパターンがあります。
    • 《使用アイテム》アンフェルキューブ
  • 宝箱2:
    • 【家具】豪華なベッド
    • 《使用アイテム》ディスディメンジョン
  • 宝箱3:
    • 〔特性結晶〕攻防上昇+(Rank.4)

金剛石の欠片の採取地・南※開拓任務・キャラクタークエストで必要な宝物庫※

  • 宝箱1:
    • 【家具】ティーセット
      • ニーナのキャラクタークエストで必要です。
    • 《調合アイテム》三色水晶×3
  • 宝箱2:
    • 【家具】武器ラック
    • 《調合アイテム》ダマスカスプレート×3
  • 宝箱3:
    • 《調合アイテム》神秘の二重螺旋
備考
  • 地図的に一番近いランドマークは坑路入口ですが、高低差があるため、こちらの採取地を経由した方が早いです。
  • ニーナのキャラクタークエストでも必要な宝物庫です。

マナ錬成炉・北※記念の社中継器※

  • 宝箱1:
    • 【家具】観葉植物C
    • 〔特性結晶〕攻撃力上昇+(Rank.4)
  • 宝箱2:
    • 【家具】飾り棚A
    • 〔特性結晶〕クリティカル+(Rank.3)
備考

間に「祈念の社の中継器を含む」という問題ありの宝物庫です。

アラディス軍基地道路・東

  • 宝箱1:
    • 〔特性結晶〕攻速上昇+(Rank.4)
  • 宝箱2:
    • 【家具】チェストD
    • 〔特性結晶〕防速上昇+(Rank.4)
  • 宝箱3:
    • 【家具】ぷにんぎょう
    • 《調合アイテム》鉄屑の残り香
備考

高さの関係で、ここからが一番アクセスしやすいです。

[LM]大地の裂け目・西

  • 宝箱1:
    • 《パーツ》メタルパーツ
  • 宝箱2:
    • 【家具】フロアライト
    • 《調合アイテム》ビスマステン×3
  • 宝箱3:
    • 【家具】観葉植物B
    • 《調合アイテム》ビスマスクリスタル×3
備考

西に進むと言うより、ランドマークから飛び降ります。

[LM]住宅街十字路・北西

  • 宝箱1:
    • 【家具】一人がけの椅子A
    • 〔特性結晶〕火ダメージ追撃+(Rank.3)
  • 宝箱2:
    • 【家具】装飾柱
    • 〔特性結晶〕ブレイク時強化+(Rank.3)
  • 宝箱3:
    • 〔特性結晶〕会心ダメージ増加+(Rank.3)

[LM]ラムスヴィーア丘陵・更に南

  • 宝箱1:
    • 【家具】ピザ釜
    • 《使用アイテム》ステラプラジグ
  • 宝箱2:
    • 【家具】照明E
    • 《使用アイテム》シャルフラム
  • 宝箱3:
    • 《使用アイテム》ハルトレヘルン

[LM]黄金の遊閉地・南

  • 宝箱:1
    • 《調合アイテム》永久機関×3
  • 宝箱:2
    • 【家具】街灯
    • 《調合アイテム》ポイズンファン×3
  • 宝箱3:
    • 【家具】丸形のカーペットA
    • 《調合アイテム》カクタス繊維×3

[LM]座礁建造郡中枢・東

  • 宝箱1:
    • 《使用アイテム》ヒールアンブレラ
  • 宝箱2:
    • 【家具】上品なテーブル
    • 《使用アイテム》ヴィジオンルフト
  • 宝箱3:
    • 《使用アイテム》パナケイアスフィア

商業区大型建造物ハウジングエリア・南

  • 宝箱1:
    • 《調合アイテム》古代の劇物×3
  • 宝箱2:
    • 【家具】木製の棚D
    • 《調合アイテム》プロテクタイト×3
  • 宝箱3:
    • 【家具】大きめのカーペットA
    • 《調合アイテム》コイルクローバー×3

アウルーマ調査拠点・西

  • 宝箱1:
    • 【家具】木製の棚B
    • 《装備品》クルーガークローク
  • 宝箱2:
    • 【家具】絵画枠
    • 《装備品》コランダムアーマー
  • 宝箱3:
    • 《装備品》武人の装束

[LM]侵食峡谷・北

  • 宝箱1:
    • 【家具】展示台
    • 《装備品》祈念の指輪
  • 宝箱2:
    • 【家具】タペストリーC
    • 《装備品》軍師のチョーカー
  • 宝箱3:
    • 《装備品》エターナルフラワー

[LM]黄金湖の展望地・西

  • 宝箱1:
    • 【家具】花瓶A
    • 《装備品》息災延命の輪
  • 宝箱2:
    • 【家具】一人がけの椅子D
    • 《使用アイテム》再生のエネルギア
  • 宝箱3:
    • 【家具】天窓
    • 《使用アイテム》バイタルスロットル

[LM]鉱脈断層・東

  • 宝箱1:
    • 〔特性結晶〕スキル強化+(Rank.3)
  • 宝箱2:
    • 【家具】チェストA
    • 〔特性結晶〕防御力上昇+(Rank.3)
  • 宝箱3:
    • 【家具】2階建てガセポ
    • 〔特性結晶〕素早さ上昇+(Rank.3)

[LM]北部地域入口・北東(1)

  • 宝箱1:(要:リペアツール)
    • 【家具】ブックスタンド
    • (素材)カットラス×3
  • 宝箱2:
    • 〔特性結晶〕会心ダメージ増加+(Rank.3)
  • 宝箱3:
    • (素材)キノコモドキ×3

[LM]北部地域入口・北東(2)

  • 宝箱1:
    • 【家具】ひよこ人形
    • (素材)エンデ・ガイド×3
  • 宝箱2:
    • 〔特性結晶〕攻速上昇+(Rank.3)
  • 宝箱3:
    • (素材)ルブムムリリー

[LM]砂滝の高台・東

  • 宝箱1:要:リペアツール
    • 【家具】木箱
    • (素材)ゴーレムコア
  • 宝箱2:
    • (素材)ゴーレムコア
  • 宝箱3:
    • (素材)ゴーレムコア

[LM]岩場の隘路・北

  • 宝箱1:
    • 【家具】テディベア
    • (素材)ぷにフォッシル
  • 宝箱2:
    • (素材)ブロンズスイマー
  • 宝箱3:
    • (素材)インパースメタル

アルバーの大集落・北西※ハズレ宝物庫※

  • 宝箱1:
    • 〔特性結晶〕防速上昇+(Rank.3)
  • 宝箱2:
    • 〔特性結晶〕攻防上昇+(Rank.3)
  • 宝箱3:
    • 〔特性結晶〕攻防上昇+(Rank.3)
備考

特性結晶のみのハズレ宝物庫です。

[LM]ペルグラオスト・南東

  • 宝箱1:
    • 〔特性結晶〕回復量上昇+(Rank.3)
  • 宝箱2:
    • 【家具】本棚B
    • 《調合アイテム》お手製ブラックホール×3
  • 宝箱3:
    • 〔特性結晶〕破壊力上昇+(Rank.3)

シバーシュ地方

[LM]光花の高台※ハズレ宝物庫※

  • 宝箱1:
    • (素材)ゴーレムコア×3
  • 宝箱2:
    • (素材)コングの装甲×3
  • 宝箱3:
    • (素材)ゼリーキューブ×3
備考
  • 開拓任務で訪れるシバーシュ地方です。
  • 正直、開発者の意図を疑いたくなるレベルの酷すぎるハズレ宝物庫です。

[LM]貯水施設・南

  • 宝箱1:
    • (素材)狩人の鉤爪×3
  • 宝箱2:
    • (素材)動物の毛皮×3
  • 宝箱3:
    • 【家具】暖炉
    • (素材)浮竜の羽毛×3
備考
  • 開拓任務で訪れるシバーシュ地方です。
  • 家具があるだけ、ハズレを免れています。

『ユミアのアトリエ』選択肢によるエンディング分岐。(強烈なネタバレのためページ分割:追記あり)

概要

上記の記事で

周回を前提とした実績や、選択肢で異なる実績はありますか?

 ありません。1回のプレイで全実績を解除することが可能です。

と書きましたが、

本作は選択肢によって「エンディングが分岐」します。(ただし、どちらに分岐しても実績には関係ありません)

エンディング分岐の条件

作中、度々発生する選択肢。

ストーリー上、重要な選択肢のどちらを選ぶかで、選択肢の背景が

に変化します。このとき、赤と緑、どちらの選択肢を多く選択したかによってエンディングの分岐が決まります。(ばらけている場合は選択肢が出るようです)

※エンディングに変化を及ぼさない通常の選択肢を選んだ場合、背景は青のまま変化しません(画像はその通常の選択肢です)※

次のページから解説です。

『ユミアのアトリエ』2025/05/23アップデートによる最高難易度の洗礼。

こちらの記事にて

しかし、調合システムによってキャラクターのステータスを大幅に強化できてしまうため、調合のコツを掴んでしまうと、戦闘が文字通り一瞬で終わってしまうことが多くなりました。

特に「戦闘」の比重が(調合による強化で)相対的に軽くなっている印象を受けます。この点は、今後のストーリー展開や、アップデートで追加されるであろう高難易度コンテンツで、より歯ごたえのあるバランスになることを期待したいです。

と書きました。この期待に大幅に応えてくれるアップデートが2025/05/23配信。

最高難易度LEGEND追加

最高難易度、LEGENDの実装です。

まさか、それでもまだ弱いと言うことはないよな? 思いながら、かなり上から目線で挑戦したのですが……

予想を超える難易度

「今までの高難易度は何だったのか」というぐらい、手応えあるものになっています。

特に高濃度マナ領域では「戦闘時にHPが削られていく」仕様も相まって

マナ争奪戦ではユミア、戦闘不能。トロコンしてから初めての出来事です。

上級包帯のありがたさを知るという事態が発生。

ヴィラン(リリーボレア)相手には「全滅」の憂き目に遭いました。

ステータスをここまで上げていたにもかかわらず、です。

今後の方針

  • 更なる武器と防具の錬成見直し
  • レベル上限が底上げされたのでレベル最大上げ
  • 回復アイテムの効果検証(難易度CHARISMA程度では不要でした)
  • 特性結晶の調合と検証
  • 効率の良い戦い方の確立

など、一気に課題が増えてきました。

Let’s Encryptによるワイルドカード証明書の設定。(証明書発行のみ)

こちらの記事を2025年版に対応すると共に、改めて、「証明書の発行」に絞った形です。

期せずして新たなドメインが取得できたので、こちらのワイルドカード証明書をLet's Encryptで作っていきます。

環境

  • Ubuntu 24.04

前提条件

  • 取得したドメインへのDNSが設定できること。
  • Let's Encryptが取得できていること
  • 備考として、別サーバでも配布しやすいように、オリジナルの/etc/letsencrypt/live/ではなく、任意の作業ディレクトリに証明書一式を保存する運用を行っています。

実施手順

サーバにターミナル接続して実施します。

root昇格

sudo su -

作業ディレクトリ作成

  • ディレクトリ作成
mkdir /hoge/bbb.jp_ssl$(date +%Y%m)
  • ディレクトリ移動
cd /hoge/bbb.jp_ssl$(date +%Y%m)

証明書発行

certbot certonly --manual \
    --preferred-challenges dns \
    --server https://acme-v02.api.letsencrypt.org/directory \
    -m あなたの有効なメールアドレス@example.com \
    -d "*.bbb.jp" \
    -d "bbb.jp"
  1. コマンド発行後、TXTレコードの登録指示がある。
  2. 管理しているDNSサーバにて、指示があったTXTレコードを登録
  3. 以下のコマンドで結果が返ってくるまでしばらく待つ
nslookup -type=TXT _acme-challenge.bbb.jp

→ 結果が返ってきたらEnter。証明書が更新される。

証明書一式を作業ディレクトリにコピー

  • 証明書を作業ディレクトリにコピー
cp -pi /etc/letsencrypt/live/bbb.jp/fullchain.pem ./bbb.jp.crt.$(date +%Y%m)
  • 秘密鍵を作業ディレクトリにコピー
cp -pi /etc/letsencrypt/live/bbb.jp/privkey.pem ./bbb.jp.key.$(date +%Y%m)

(通例、証明書は制限されています。読み取り時は注意してください)

証明書の整合性を確認

  • 期限が延びていることを確認
openssl x509 -noout -dates -subject -in bbb.jp.crt.$(date +%Y%m)
  • 証明書から公開鍵を取得
openssl x509 -pubkey -in bbb.jp.crt.$(date +%Y%m) -noout | openssl md5
  • 秘密鍵から公開鍵を取得
openssl pkey -pubout -in bbb.jp.key.$(date +%Y%m) | openssl md5

→ 両者が同じことを確認

  • 証明書のチェーンを確認
openssl crl2pkcs7 -nocrl -certfile bbb.jp.crt.$(date +%Y%m) | openssl pkcs7 -print_certs -outform PEM | awk 'BEGIN {c=0;} /BEGIN CERTIFICATE/ {c++} { print > "cert" c ".pem"}' && openssl verify -CAfile cert2.pem cert1.pem

openssl verify -CAfile cert2.pem cert1.pem
cert1.pem: OK

となることを確認

後は、これらの証明書を適切な位置に配置すれば完了です。

注意事項

  • 秘密鍵の保管は慎重に行ってください。
  • Let's Encryptのワイルドカード証明書の有効期限は90日と短いものです。更新忘れは特に注意してください。

nvmによるnpmアップデートとGrowiの起動スクリプト修正。

Growiサーバのメンテナンス中、「新しいnpmのバージョンが出ている」ということで、

以下のコマンドを実施。

sudo npm install -g npm@11.4.0

しかし、以下のエラーが出てきました。

npm error code EBADENGINE
npm error engine Unsupported engine
npm error engine Not compatible with your version of node/npm: npm@11.4.0
npm error notsup Not compatible with your version of node/npm: npm@11.4.0
npm error notsup Required: {"node":"^20.17.0 || >=22.9.0"}
npm error notsup Actual:   {"npm":"10.9.0","node":"v20.15.1"}
npm error A complete log of this run can be found in: /root/.npm/_logs/2025-05-20T01_02_55_477Z-debug-0.log 

これを解決するため、結構なハマり案件があったのでメモを残します。(実施日:2025/05/20)

動作前環境

  • Ubuntu 22.04
  • Growi v7.2.4
  • node.js 20.15.1
  • npm 10.9.0
  • pnpm 9.12.3
  • MongoDB/Apacheによるリバースプロキシーは割愛します。

以下を参考にインストールしています。

https://barrel.reisalin.com/books/growi/page/ubuntu2404growi-v7v710-ImY

(盛大にハマったものの)最終的に解決した手順

  1. nvm (Node Version Manager)のインストールと環境設定
  2. Growiサービス(systemd 経由)起動時でのバージョン不一致の特定
  3. 起動スクリプトの修正

nvmインストール

  • root昇格

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

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

inactive(dead)を確認

  • 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の削除
rm -rf /root/.local/share/pnpm
  • コマンドパスのキャッシュクリア
hash -r
  • pnpmインストール
npm install -g pnpm
  • pnpmバージョン確認
pnpm -v

10.11.0を確認

  • rootから抜ける
exit

Growiとのバージョン不一致と原因確認

  • growi起動
sudo systemctl start growi.service
  • growi起動確認
systemctl status growi.service

とし、Growiの管理画面にアクセスしましたが、バージョンは変わらず。

システム上は確かにバージョンアップされているにもかかわらず、です。

そこで、

pgrep growi

で原因を探し、

ls -l /proc/<PID>/exe

を確認したところ、systemdから起動されたGrowiのNode.jsプロセスが、バージョンアップ前の

/usr/local/bin/nodeを利用していることを確認。

これは、上述したリンク先のsystemdサービスの実行環境が、nvmの環境変数(PATH)を正しく引き継いでいなかったからです。

起動スクリプトの修正

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

inactive(dead)を確認

  • Growi起動ディレクトリに移動
cd /path/to/growi/root/directory && pwd

筆者環境/home/www-data/growi

  • 起動スクリプトのバックアップ
sudo cp -pi growi-start.sh /path/to/backup/diretory/growi-start.sh.$(date +%Y%m%d)

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

  • diffによるバックアップ確認
diff -u /path/to/backup/diretory/growi-start.sh.$(date +%Y%m%d) growi-start.sh

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

  • スクリプト修正

growi-start.shを、任意の手段で修正します。

#!/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

# GROWIの起動コマンド
  • 修正確認
diff -u /path/to/backup/diretory/growi-start.sh.$(date +%Y%m%d) growi-start.sh
+
+# 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
+
+# GROWIの起動コマンド

修正確認

  • growi起動
sudo systemctl start growi.service
  • growi起動確認
systemctl status growi.service

この後、Growiに管理者権限でアクセスし、管理画面に移動します。

項目
GROWI7.2.4
node.js20.19.2
npm11.4.0
pnpm10.11.0

となっていたため、正しく参照できています。

Page 4 of 259

Powered by WordPress & Theme by Anders Norén