投稿者: manualmaton Page 2 of 246

Redmineサイトのセキュリティヘッダー修正。(脆弱性サイトの評価をA→A+に引き上げ)

外部に公開しているRedmineサイト。

https://plan.io/redmine-security-scanner

で確認したところ、評価はA。

X-Content-Type-Options header not set Content sniffing may enable cross-site scripting attacks. Since your Redmine server is not properly sending the X-Content-Type-Options header, your users are vulnerable to this attack vector.

の診断が出てA+に至りませんでした。

そこで、設定を修正し、脆弱性評価をA+に引き上げます。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Redmine 5.1
  • mod_headers モジュール有効化済み

現状のセキュリティヘッダー確認

  • /etc/apache2/sites-available/redmine.conf

で以下の箇所を確認。

    Header always set Strict-Transport-Security "max-age=63072000"
  Header set X-Content-Type-Options "nosniff"
  Header always append X-Frame-Options "SAMEORIGIN"
  Header set X-XSS-Protection "1; mode=block"

セキュリティヘッダーの適用方法を見直し、適切に設定されるよう修正します。

設定修正

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

※自分のRedmineサイトの設定ファイルを指定します。

任意のバックアップディレクトリを指定します。(筆者環境 /etc/apache2/old/redmine.conf.$(date +%Y%m%d)

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

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

  • ファイルの修正

上記のredmine.confを、以下の差分になるように修正します。(管理者権限が必要)

-    Header set X-Content-Type-Options "nosniff"
-   Header always append X-Frame-Options "SAMEORIGIN"
-   Header set X-XSS-Protection "1; mode=block"
+   Header always set X-Content-Type-Options "nosniff"
+   Header always set X-Frame-Options "SAMEORIGIN"
+   Header always set X-XSS-Protection "1; mode=block"
  • ファイル修正確認
diff -u /path/to/backup/directory/redmine.conf.$(date +%Y%m%d) /etc/apache2/sites-available/redmine.conf 

上記の差分が出てくればOKです。

設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apacheステータス確認(反映前)
systemctl status apache2.service

active (running)を確認します。

  • Apache再起動
sudo systemctl restart apache2.service && echo $?

→ 成功時は 0 が出力されます。

  • Apacheステータス確認(反映後)
systemctl status apache2.service

active (running)を確認します。

修正確認

  • curlによる確認
curl -I https://redmineサイト

以下のような表示を確認します。

X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Request-Id: ***********
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.615862
X-Content-Type-Options: nosniff
  • 脆弱性診断サイトによる確認

https://plan.io/redmine-security-scanner

でURLを入力します。

過去の診断結果が表示されるため、『Re-Scan』をクリックして最新の診断結果を取得します。

「A+」の評価と、以下のような表示が出れば修正できています。

It looks like you are running Redmine 5.1.4. That's a version without any known security issues. Your Redmine is protected by properly configured TLS/SSL. All security relevant headers are configured properly. It appears that you have 3 or more Redmine plugins installed.

Firefly-iii 6.1.5→6.2.5アップグレード失敗と切り戻し

firefly-iiiのアップグレードを試みたところ、失敗。その記録と原因についてメモを残します。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0.39
  • PHP 8.3.16
  • Composer 2.7.9
  • firefly-iii 6.1.5
  • → 6.2.5にアップグレードを試みた

試した手順

  1. DBのバックアップを取得します。
  2. 最新版のパッケージをダウンロードして展開します。
  3. 利用中のfirefly-iiiを待避させます。
  4. 待避させたfirefly-iiiからファイル/ディレクトリをコピーします。
  5. アップグレードを行います。(失敗)

DBのバックアップ

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

任意の作業ディレクトリに移動します。

  • DBバックアップ
mysqldump --no-tablespaces --single-transaction -u username -h localhost -p database_name > DB_Backup.$(date +%Y%m%d).sql

usenamedatabase_name、及びDB_Backupは自分の環境に合わせます。

  • バックアップ確認
head -100 DB_Backup.$(date +%Y%m%d).sql

バックアップができていること、平文でSQLが読めることを確認します。

パッケージ取得

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

任意の作業ディレクトリに移動します。

  • wget
wget https://github.com/firefly-iii/firefly-iii/releases/download/v6.2.5/FireflyIII-v6.2.5.zip
  • ファイル所有者変更
sudo chown www-data:www-data FireflyIII-v6.2.5.zip
  • ファイル確認
ls -l FireflyIII-v6.2.5.zip

ファイルがあること、所有者がWebアプリ実行ユーザ(www-data)であることを確認します。

アップデート前のfirefly-iiiを待避

  • ディレクトリごと待避
sudo mv /home/www-data/firefly-iii /home/www-data/firefly-iii.$(date +%Y%m%d)

自分の環境に合わせます。firefly-iiiがインストールされているディレクトリをまるごと移動します。

  • 待避確認
ls -ld /home/www-data/firefly-iii

→ ディレクトリが無いこと

ls -ld /home/www-data/firefly-iii.$(date +%Y%m%d)

→ ディレクトリがあること

アップデートパッケージの解凍と配置

  • 解凍
sudo -u www-data unzip -o /hoge/FireflyIII-v6.2.5.zip -x "storage/*" -d /home/www-data/firefly-iii

/hogeは先ほど取得したパッケージがある場所です。アップデート前と同じ位置、名前に解凍します。

  • 解凍・配置確認
ls -l /home/www-data/firefly-iii

ファイル一式があり、www-dataが所有者になっていること

アップデート前のファイル・ディレクトリをコピー

  • 待避させたディレクトリに移動
cd /home/www-data/firefly-iii.$(date +%Y%m%d) && pwd

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

  • .envファイルをコピー
sudo -u www-data cp -pi .env /home/www-data/firefly-iii/.env

コピー先のディレクトリは自分の環境に合わせます。

  • .envファイルコピー確認
ls -l /home/www-data/firefly-iii/.env

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

  • storageディレクトリのコピー
sudo -u www-data cp -pir storage /home/www-data/firefly-iii/
  • storageディレクトリのコピー確認
ls -l /home/www-data/firefly-iii/storage

ファイルやディレクトリがあることを確認します。

アップグレード → 失敗

  • アップグレード後のディレクトリに移動
cd /home/www-data/firefly-iii && pwd

先ほど展開したディレクトリに移動します。

  • DBマイグレーション
sudo -u www-data php artisan migrate --seed

ここで失敗。以下のエラーが出ました。

Composer detected issues in your platform:

Your Composer dependencies require a PHP version ">= 8.4.0". You are running 8.3.16.

PHP Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.4.0". You are running 8.3.16. in /home/www-data/firefly-iii/vendor/composer/platform_check.php on line 22

そのため、切り戻しを行います。

失敗したため切り戻し

  • Webコンテンツ配置ディレクトリに移動
cd /home/www-data && pwd

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

  • 展開したディレクトリ削除
sudo rm -rf /home/www-data/firefly-iii
  • ディレクトリ退避から復旧
sudo mv /home/www-data/firefly-iii.$(date +%Y%m%d) /home/www-data/firefly-iii
  • ディレクトリ復旧確認
ls -l /home/www-data/firefly-iii

ファイル一式があり、www-dataが所有者になっていること

切り戻し反映・確認

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service
  • 霧もろし確認
  1. アップデートを行ったfirefly-iiiサイトにブラウザでアクセスします。
  2. ログインできることを確認します。
  3. バージョンが上がっていることを確認します。
  4. 登録操作などができることを確認します。

失敗の要因

これは明白にして単純です。

リリースノートを確認していなかった

に尽きます。LAMP環境で動くからこそ、ミドルウェアのバージョン(この場合はPHP)の必要とするバージョンを確認していなかった自分の落ち度です。

v6.2.0のリリースノートに

Firefly III requires PHP 8.4.

と書かれていることを見落としていました。

切り戻しが迅速だった要因

「切り戻しを前提としていた手順」に助けられました。

  • 作業前にDBのバックアップ
  • 動いていた環境を退避

させる二段構えにより、迅速な切り戻しが可能になりました。

結局のところ、

「自分の確認不足」から来るミスを「自分の確認不足を想定した手順」でカバーした形です。

防護と回収。(統率者メモ2025/02/10)

昨日の続き。「サワギバを統率者とした場合のデッキ」を割とテコ入れです。

統率者

  • リスの将軍、サワギバ/Chatterfang, Squirrel General

デッキ

クリーチャー

  • 大釜の使い魔/Cauldron Familiar
  • マリオネットの見習い/Marionette Apprentice
  • ズーラポートの殺し屋/Zulaport Cutthroat
  • 実験的な菓子職人/Experimental Confectioner
  • 無情な無頼漢/Ruthless Knave
  • 巣穴の魂商人/Warren Soultrader
  • 血魔道の集会/Veinwitch Coven
  • ネイディアの夜刃/Nadier's Nightblade
  • 悲哀の徘徊者/Woe Strider
  • 無慈悲な略奪者/Pitiless Plunderer
  • 無情な屍技術師/Ruthless Technomancer
  • ヘイゼルの醸造主/Hazel's Brewmaster
  • 溜め込む親玉/Hoarding Broodlord
  • 森を護る者/Sylvan Safekeeper
  • 金のガチョウ/Gilded Goose
  • エルフの神秘家/Elvish Mystic
  • ラノワールのエルフ/Llanowar Elves
  • 極楽鳥/Birds of Paradise
  • 献身のドルイド/Devoted Druid
  • 茨越えの餌あさり/Thornvault Forager
  • 裕福な亭主/Prosperous Innkeeper
  • ペレグリン・トゥック/Peregrin Took
  • 不屈の補給兵/Tireless Provisioner
  • 小走り樫/Scurry Oak
  • リスの小走り/Scurry of Squirrels
  • 秘密を知るもの、トスキ/Toski, Bearer of Secrets
  • 永久の証人/Timeless Witness
  • 深き森の隠遁者/Deep Forest Hermit
  • 悪魔の職工/Fiend Artisan
  • 蔦刈りの導師/Vinereap Mentor
  • 根花のヘイゼル/Hazel of the Rootbloom
  • 歩行バリスタ/Walking Ballista
  • アカデミーの整備士/Academy Manufactor
  • カルドーサの鍛冶場主/Kuldotha Forgemaster
  • マイアの戦闘球/Myr Battlesphere

インスタント

  • 命取りの論争/Deadly Dispute
  • 切断マジック/Saw in Half
  • 蓄え放題/Cache Grab
  • 新緑の命令/Verdant Command
  • 暗殺者の戦利品/Assassin's Trophy
  • ウィンドグレイスの裁き/Windgrace's Judgment

ソーサリー

  • 発掘/Unearth
  • 大渦の脈動/Maelstrom Pulse
  • 根鋳造の弟子入り/Rootcast Apprenticeship
  • 群がり庭の虐殺/Swarmyard Massacre

エンチャント

  • 清掃人の才能/Scavenger's Talent
  • アクロゾズの約定/Promise of Aclazotz
  • 想起の拠点/Bastion of Remembrance
  • 美食家の才能/Gourmand's Talent
  • パンくずの道標/Trail of Crumbs
  • 殺しのサービス/Killer Service
  • イトリモクの成長儀式/Growing Rites of Itlimoc
  • 獣使いの昇天/Beastmaster Ascension
  • 似通った生命/Parallel Lives

アーティファクト

  • 魔女のかまど/Witch's Oven
  • 太陽の指輪/Sol Ring
  • 頭蓋骨絞め/Skullclamp
  • 恐竜の遺伝子/Dino DNA
  • ヌカコーラ自動販売機/Nuka-Cola Vending Machine
  • アシュノッドの供犠台/Ashnod's Altar
  • 前兆の時計/Clock of Omens
  • 旗印/Coat of Arms
  • 囀り吐き/Chitterspitter

プレインズウォーカー

  • 飢餓の潮流、グリスト/Grist, the Hunger Tide

バトル

  • イコリアへの侵攻/Invasion of Ikoria

土地

  • 7:沼/Swamp
  • 8:森/Forest
  • 見捨てられたぬかるみ、竹沼/Takenuma, Abandoned Mire
  • 成長の揺り篭、ヤヴィマヤ/Yavimaya, Cradle of Growth
  • 眠らずの小屋/Restless Cottage
  • 屍花の交錯/Necroblossom Snarl
  • 疾病の神殿/Temple of Malady
  • 緑ばんだ沼/Viridescent Bog
  • 草むした墓/Overgrown Tomb
  • 汚れた森/Tainted Wood
  • 森林の墓地/Woodland Cemetery
  • 憑依されたぬかるみ/Haunted Mire
  • 黄昏のぬかるみ/Twilight Mire
  • ゴルガリの腐敗農場/Golgari Rot Farm
  • ラノワールの荒原/Llanowar Wastes
  • 群がりの庭/Swarmyard
  • 不気味な辺境林/Grim Backwoods
  • 新緑の地下墓地/Verdant Catacombs
  • 風変わりな果樹園/Exotic Orchard
  • 祖先の道/Path of Ancestry
  • 統率の塔/Command Tower

主な変更点

  • 猫かまどを追加。
    • 食物もあるし、地上も止めたいため。また、1ターンとはいえ無料のサクり台は貴重です。
    • また、アカデミーの整備士+前兆の時計でも無限ドレインを狙えます。
  • 回収手段
    • ピンポイントで除去されすぎて統率者税が払えず憤死しました。そこで、発掘や竹沼などで回収を試みます。
  • サーチと防護
    • 森を護る者、イコリアへの侵攻の丸めのカードを入れてみました。

まずは改良の筋道を立てたので、次は実戦です。

強化と拡張。

アナログゲームを色々買い足しました。

統率者用パーツ

2月最初にサワギバデッキを試したところ、

  • 年末に鮮やかな勝利を決めたことからヘイトが上がっている
  • 統率者故に確実に除去される

などの弱点を補う形です。

ボードゲーム『アイドルアライブ』一式

  • カジュアルプレイ(1箱を2人で構築)は明らかに愛称の差があり
  • 拡張版を合わせてのカジュアルでようやく勝負ができた

ことから、本ゲームは「エキスパート構築」でないとカードの愛称を覆そうにないと判断。

  • 本体×2
  • 拡張×2

に加えて

  • 専用プレイマット
  • アップグレードトークンを兼ねたアクリルスタンド9体分
  • 1stシングル(プロモカード付き)

を一気に揃えました。

これで、かなり戦略に差が生まれるので、本格的なゲームの評価ができそうです。

『ライザのアトリエ3』到達しづらいランドマークへのアクセス方法-1-

実績の一つ、「全てのランドマークを見つける」の一助となるTIPSです。

ランドマークは

  • ストーリー進行で確実に訪れることができる
  • ワールド/キャラクタークエストなどで訪れる
  • 寄り道しないと見つけられない
    • 更にエメラルドバンドが必要
    • 秘密の鍵を使う

の3~5種類に分けられます。ここでは

  • 寄り道しないと見つけられない
    • 更にエメラルドバンドが必要

の代表、クーケン島周辺エリアにあるランドマークです。

切り株のステージ

ライザ1/ライザ2(クーケン島ツアー)では地続きでアクセスできたこのランドマーク。

今作では橋が崩れていて、別のルートからたどる必要があります。

必要な道具:エメラルドバンド

やりかたによってはカーク群島探索時に調合可能。(あまり現実的ではないので推奨はしません)

アクセス方法

吊り橋の手前の分かれ道に戻り、エメラルドバンドで向こう岸にジャンプします。

後は

  • 蔦を上る
  • 更にエメラルドバンドでジャンプ

して、ここに到達です。

イベントからまず、特殊な条件がそろっているので見つけにくいランドマーク。

リーゼ峡谷の石巨人塚も同様の場所となっています。

Ubuntu 22.04でのNextcloudのPHPを8.1→8.2にバージョンアップ。

概要

  • Ubuntu 22.04
  • PHP 8.1
  • Apache 2.4
  • MySQL

環境でNextcloudを30.xの最新版にアップデート後、以下の警告が出ました。

One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command occ maintenance:repair --include-expensive to perform the migrations.

現在、あなたは PHP 8.1.31 を実行しています。PHP 8.1 は Nextcloud 30 では非推奨となっています。Nextcloud 31 では少なくとも PHP 8.2 が必要になる可能性があります。できるだけ早く、PHP グループが提供する公式にサポートされている PHP のバージョンにアップグレードしてください。 詳細については、ドキュメント↗を参照してください。


いくつかの欠落しているオプションのインデックスを検出しました。データベースのパフォーマンスを向上させるために、(Nextcloudまたはインストールされたアプリケーションによって)新しいインデックスが追加されることがあります。インデックスの追加には時間がかかり、一時的にパフォーマンスが低下することがあるため、アップグレード時には自動的には行われません。インデックスが追加されると、それらのテーブルへのクエリが速くなるはずです。インデックスを追加するには、occ db:add-missing-indices コマンドを使用してください。インデックスが不足: "fs_name_hash" テーブル内の "filecache". 詳細については、ドキュメント↗を参照してください。

これに対して対応を行います。

備考

Webサーバの全体的な変更を伴います。作業は慎重に、可能な限り検証環境で試してからの反映を強く推奨します。

ややさっくりしない手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Nextcloudで用いているDBのバックアップを取ります。
  3. PHP8.2をインストールします。
  4. PHP8.2の設定を行います。
  5. PHP8.1の無効化とPHP8.2の有効化を行います。
  6. 警告に対する対処を行います。
  7. Nextcloudのメンテナンスモードを無効化します。
  8. 復旧を確認します。

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

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

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

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

mysqldumpでバックアップを取得する

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

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

  • DBバックアップ作成
mysqldump -h localhost -u nextcloud -p --no-tablespaces --single-transaction nextcloud > nextcloud_backup.$(date +%Y%m%d).sql

DB名やユーザーは自分の環境に合わせます。

  • DBバックアップ作成確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

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

必要パッケージをインストールします。

  • PHP8.2インストール
sudo aptitude install php8.2

→ 好みでaptitudeを用いています。aptでもOKです。

  • PHPモジュールインストール
sudo aptitude install php8.2-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev,imagick,gmp}
  • PHP8.2対応
sudo aptitude install libapache2-mod-php8.2
  • PHP8.1無効化
sudo a2dismod php8.1
  • PHP8.2有効化
sudo a2enmod php8.2
  • Apache再起動
sudo systemctl reload apache2.service
  • PHPアップグレード確認
php -v

表示例PHP 8.2.27 (cli) (built: Jan 2 2025 15:36:15) (NTS)

Nextcloudに併せたPHPの設定を行います。

  • memcacheとAPCuの有効化
cd /etc/php/8.2/cli/conf.d
cat <<- __EOF__ | sudo tee -a /etc/php/8.2/cli/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee -a /etc/php/8.2/cli/conf.d/20-apcu.ini
[apcu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php
__EOF__

php.iniバックアップ

sudo cp -pi /etc/php/8.2/apache2/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。(筆者環境/etc/old/)

  • バックアップ確認
diff -u /etc/php/8.2/apache2/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)

差分が存在しないことにより、バックアップが取れていることを確認します。

  • sedによるファイル書き換え
sudo sed -i 's/memory_limit = 128M/memory_limit = 512M/g' /etc/php/8.2/apache2/php.ini

memory_limitを推奨値の512Mに置き換えます。

  • 書き換え後の差分確認
diff -u  /path/to/backup/php.ini.$(date +%Y%m%d) /etc/php/8.2/apache2/php.ini
  • 差分
-memory_limit = 128M
+memory_limit = 512M
  • apache 再起動
sudo systemctl restart apache2.service

Nextcloudの警告解消

  • Nextcloudのディレクトリに移動
cd /path/to/nextcloud/root/directory && pwd

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

  • DBリペア
sudo -u www-data php8.2 occ maintenance:repair --include-expensive
  • DB追記
sudo -u www-data php8.2 occ db:add-missing-indices
  • メンテナンスモード無効化
sudo -u www-data php8.2 occ maintenance:mode --off

復旧確認

  1. 設定を行ったNextcloudにアクセスします。
  2. メンテナンスモードが解除されていることを確認します。
  3. 管理者権限でアクセスし、管理者設定から上記のエラーやワーニングがないことを確認します。

備考:切り戻し

何か不具合があった場合の切り戻し手順です。上記、メンテナンスモードを有効化してから行ってください。

  • PHP8.2無効化
sudo a2dismod php8.2
  • PHP8.1有効化
sudo a2enmod php8.1
  • Apache再起動
sudo systemctl restart apache2.service
  • PHP切り戻し確認
php -v

→ 8.1に戻っていることを確認します。

  • バックアップしたDBがあることを再確認する
ls -l /hoge/nextcloud_backup.$(date +%Y%m%d).sql

バックアップを行ったディレクトリを指定します。

head -100 /hoge/nextcloud_backup.$(date +%Y%m%d).sql

ファイルがあること、平文で読めることを確認します。

  • 管理者権限でMySQLにログインする
mysql -u root -p
  • 対象のDBを確認する
SHOW DATABASES;

nextcloudが動いているDBであることを再確認してください。

  • 本当に削除すべきDBかを確認する
SELECT COUNT(*) FROM nextcloud.oc_users;
  • 不具合が発生したDBを削除する

二回ほど深呼吸して、落ち着いて作業しましょう。

DROP DATABASE nextcloud;
  • DBを再作成する
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
  • MySQLから抜ける
EXIT
  • DB復元
mysql -h localhost -u nextcloud -p nextcloud < /hoge/nextcloud_backup.$(date +%Y%m%d).sql

この後、メンテナンスモードを解除して、以前と同じ状態か確認します。

作業後:バックアップDBの削除

平文でSQLがサーバ上にあるのは危険な状態なので、以下の措置を執ります。

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

バックアップを行ったディレクトリを指定します。

  • DBバックアップ確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

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

  • バックアップしたDBの削除
shred -u nextcloud_backup.$(date +%Y%m%d).sql
  • DBバックアップ削除確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

ファイルが無いことを確認します。

Webサーバに複数のWebサイトを運用する際の確認・Apache再起動スクリプト。

Webサーバ1つに複数のサイトを運用している場合、

「バーチャルホストでどんなWebサービスが動いているか?」「設定変更後の構文は正しいか?」「Webサービス再起動後、ステータスは正常か?」

を確認したい場合は多々あります。

それを解決するためのスクリプトがこちらです。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • バーチャルホストはデフォルトの/etc/apache2/site-enabledを踏襲

スクリプト内容

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

# サイト設定ディレクトリ
SITES_DIR="/etc/apache2/sites-enabled"

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

# 1. /etc/apache2/sites-enabled 配下のファイルとURL表示
echo "==== 有効なサイト設定ファイル ===="
if [ -z "$(ls -A "$SITES_DIR")" ]; then
    echo "サイト設定が存在しません。"
else
    for site in "$SITES_DIR"/*; do
        echo "設定ファイル: $(basename "$site")"

        # ServerNameとServerAliasを正規化して抽出
        entries=$(grep -hi -E "ServerName|ServerAlias" "$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
fi

echo "=================================="

# 2. Apache構文チェック
echo "構文チェック中..."
if ! apachectl configtest; then
    echo "構文エラーが検出されました。Apacheを再起動できません。"
    exit 1
fi
echo "構文チェック完了: 問題ありません。"

# 3. Apache再起動の確認
read -p "Apacheを再起動しますか? (y/n): " CONFIRM
if [[ "$CONFIRM" =~ ^[Yy]$ ]]; then
    echo "Apacheを再起動します..."
    if ! systemctl restart apache2; then
        echo "Apacheの再起動に失敗しました。"
        exit 1
    fi
    echo "Apacheが正常に再起動されました。"

    # 4. Apacheステータス確認
    echo "==== Apacheステータス ===="
    systemctl status apache2 --no-pager
else
    echo "Apacheの再起動はキャンセルされました。"

保存後、

sudo chmod +x apache2-check.sh

として、

sudo bash apache2-check.sh

を実行することで、

  • /etc/apache2/site-enabled/ 配下のコンフィグからWebサイト名を表示
  • 設定ファイルの構文を確認
  • Webサービス再起動の確認
  • Webサービス再起動後のステータスの表示

を一括で行うことができます。

使った後

このスクリプトを使うことで、Apacheの設定確認と再起動作業が大幅に効率化されました。

  • 設定ファイルの一覧表示: どのサイトが有効になっているか一目で確認できるため、サイト管理がしやすくなりました。
  • ServerName/ServerAliasの抽出: 各サイトの設定内容を簡単に確認できるため、設定ミスを防ぐのに役立ちました。
  • 構文チェック: 設定変更後の構文エラーチェックを確実に行えるため、Webサイトの停止時間を減らすことができました。
  • 再起動手順の簡略化: 再起動時の確認メッセージがあるため、誤操作を防ぐことができます。

『ライザのアトリエ3』カーク群島探索前の寄り道。

ライザ/レント/タオ/クラウディアの4人でカーク群島に向かうタイミング。

ランドマーク「聖堂臨む隠れ浜」でイベントが終わると、別のトリガーが引かれます。

それは、「クーケン島周辺エリアを歩き回れること」です。

島の探索を後回しにしてでも、ここを巡る価値は十分にあります。

新たな素材の発見

特に、聖堂臨む隠れ浜の北の崖をジャンプして届くエリア

「忘れ去られた廃村」では、ちょっと強めの敵が出てくるものの

属性値2の氷/風属性を持つ植物や

池から属性値3の黒水を入手可能です。

ランドマークさえ解放していけば

  • ファストトラベルで一気に進むことができる
  • 後々のキーメイク巡りが楽になる

などのメリットがあります。そして、レベル上げも行えます。

難易度を下げてでも周辺エリア全域を巡ることを推奨します。

『ライザのアトリエ3』カーク群島到着前の「超純水」調合。

  • ゼッテル
  • 旅人の水珠

が調合可能になったことで、「超純水」も調合可能になります。

4人での冒険を開始した後、

  • いい素材が手に入りにくい
  • そんな中でもSPを稼ぎ、他のスキルツリーを伸ばしたい

場合に有効です。

必要な素材

旅人の水珠

前述したとおり

  • ゼッテル

から調合します。

ユピトピニオン

隠れ家周辺、彩花の円環の更に西、大きなキノコから薪割り斧でユピトピニオンを採取できます。

  • 気体を持ち
  • 火と風属性

と、この超純水を調合する際に役立ちます。

調合

調合メニューから「超純水」を選びます。

効果1に旅人の水珠を入れます。

効果2の気体に、ユピトピニオンの属性値が3になるように入れます。

特性枠に、ユピトピニオンの属性値が4になるように入れます。

残り1枠は旅人の水珠や中和剤・青などを入れます。

  • 属性値3
  • 特性2つ
  • 調合 作成個数+1

の水ができます。

中和剤のマテリアル環を一発で埋めることができるので、他のマテリアル環に素材を回せます。

『ライザのアトリエ3』最序盤での「旅人の水珠」調合。

4人での冒険を開始する前に、調合の基礎となる「水」を作っていきます。

今回は「旅人の水珠」。

「影響拡大」を持つには至りませんが、

  • 安定した属性値
  • 高い品質
  • 原料「ゼッテル」の影響で必然的に数を増やせる

逸品です。また、これ自体が水であり、

  • ゼッテルで中和剤の特性を統合
  • 旅人の水珠に変換し
  • 別の中和剤に変換する

ことも可能です。

必須材料

ゼッテル

これは先に示したとおりです。

火属性の石材

隠れ家近くの岩を斧で砕くことで甘露岩を取得できます。

更に、「素材:石材付与」が発現された中和剤・緑があるとなお品質が高くなります。

調合

調合メニューから「旅人の水珠」を入れ、ゼッテルを投入。

甘露岩を属性値が3になるように入れます。

後は適当に。というのも、移動できる範囲がクーケン島/隠れ家周辺しかない最序盤では

  • 「雷属性の石材」が手に入らない
  • カーク群島の探索を開始しても属性値3ほどの石材を入手するのは大変

という制約がありますので、

最初の段階では特性を発揮できません。当然、影響拡大も発現できません。

とはいえ、

  • 後の超純水の必須素材であること
  • SPを稼げること

から、最初の内から調合しておくのは重要です。

Page 2 of 246

Powered by WordPress & Theme by Anders Norén