2024/09/20の『ライザのアトリエ』シリーズ5周年記念アップデート、思わぬ効果が出ました。
圧倒的な火力を叩き出しているコアアイテム、「ツヴァイレゾナンス」。
必須材料のリバーストン・蒼炎を採取可能なのが異界なので、ネメド地方までの段階では調合は無理だと思っておりましたが、
山果ての廃神殿のこの位置、ランダムクエストで出てくる騎士型の魔物を討伐することで上記、「リバーストン・蒼炎」をドロップ。
確かめようと15回ほど周辺を見てきましたが、結局、そのランダムクエスト自体が現れず。
とはいえ
は既に調合済み。スキルツリーでツヴァイレゾナンスも解放しているので
調合も完了です。この段階では「ロール・アルケミスト」を持つ鍵を作成できないので
でCCを減らすようにしました。
威力は全盛より劣るものの
LEGENDの通常敵は普通に殲滅できるだけのダメージを叩き出すことができます。
後は、再現性を待ちます。
個別に走らせていたスクリプトを1つにまとめました。
#!/bin/bash
# このスクリプトは、Tor出口ノードリストをダウンロードし、特定のログファイルからIPアドレスを抽出して処理します。
# 使い方: このスクリプトを実行することで、最新のTor出口ノードリストを取得し、ログファイルから抽出したIPアドレスと照合します。
# 結果は指定されたディレクトリに保存され、Apacheが再起動されます。
# cronでの指定例: 毎日午前2時に実行する場合 -> 0 2 * * * /path/to/this_script.sh
# === 変数の定義 ===
# 出口ノードリストのURL
TOR_EXIT_LIST_URL="https://check.torproject.org/exit-addresses"
# ダウンロード先ファイル名
OUTPUT_FILE="/hoge/script/log/node_list/exit_nodes.$(date +%Y%m%d).txt"
# 各サイトのログディレクトリ
log_dirs=("/var/log/bookstack") # 各サイトのログディレクトリを指定
# エラーログファイル名
log_file="bs_error.log"
# Tor出口ノードリストのディレクトリ
tor_list_dir="/hoge/script/log/sorted_list" # tor_list.txtのディレクトリを指定
# Tor出口ノードリストのファイル名
tor_list_file="sorted_ip_addresses$(date +%Y%m%d).txt"
# 除外するIPアドレスをファイルで指定
exclude_ips_file="/hoge/script/log/exclude_ips.txt"
# 共通の出力ログディレクトリ
output_log_dir="/hoge/script/log"
# === Tor出口ノードリストのダウンロードと処理 ===
# curlを使用してリストをダウンロード
curl -o "$OUTPUT_FILE" "$TOR_EXIT_LIST_URL" >/dev/null 2>&1
# ダウンロードが成功したかどうかを確認
if [ $? -eq 0 ]; then
echo "Tor出口ノードリストをダウンロードしました。ファイル: $OUTPUT_FILE"
else
echo "ダウンロード中にエラーが発生しました。"
exit 1
fi
# IPアドレスのみを抽出し、ソートして出力
awk '/^ExitAddress/ {print $2}' "$OUTPUT_FILE" | sort -u | tee "$tor_list_dir/$tor_list_file" >/dev/null 2>&1
# === 各サイトのエラーログからIPアドレスを抽出して処理 ===
for log_dir in "${log_dirs[@]}"; do
cd "$log_dir"
awk '/ModSecurity/ && match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort -u > "$output_log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
done
# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存
cat "$output_log_dir/suspicious_ip/suspicious_ip."2* | sort -u > "$output_log_dir/suspicious_ip_all.txt"
# 新たにリストに書き起こすと同時に別のログファイルを読み込んで重複を排除し、negativelist.txtに追加
cat "$output_log_dir/suspicious_ip_all.txt" "$tor_list_dir/$tor_list_file" | sort -u > "$output_log_dir/negativelist.txt"
# 除外するIPアドレスをファイルから削除
while IFS= read -r exclude_ip; do
sed -i "/$exclude_ip/d" "$output_log_dir/negativelist.txt"
done < "$exclude_ips_file"
# Apacheを再起動
systemctl restart apache2.service
192.168.0.1
nnn.nnn.nnn.nnnなど、エラーログから除外したいIPアドレスのリストを作ります。
/etc/apache2/site-available 配下のバーチャルサイトの設定ファイルを以下のように追記します。
# Mod_Security設定
SecRuleEngine On
SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"
sudo ln -sf /hoge/script/log/negativelist.txt /etc/apache2/sites-enabled/negativelist.txtsudo crontab -e -u rootとして、
0 2 * * * /path/to/this_script.sh等と設定すれば、毎日2時に、その日に検知した怪しい動きをシャットダウンしてくれます。
『ライザのアトリエ』シリーズ5周年を記念して配布された「快適化アップデート」。
特に『ライザのアトリエ3』のゲーム進行で特に重要になったアップデートがいくつかありましたので、そのメモです。
シリーズに不慣れな方でも楽しめる難易度が追加されました。本作は難易度指定の実績が存在しないので、実績解除を手早くやりたい方向けとなっています。
異界オーリムでイベントの中心地となる『カラの天幕』がランドマーク化。
ウィンドルでのはしごの上り下り地味に面倒なので、これは嬉しいアップデートです。
https://atelier.reisalin.com/issues/661
とはいえ、新規ランドマーク扱いなので、既に訪れている場合でも、改めて訪れる必要があります。(恐らく実績にカウントされるでしょうが、必ず訪れるランドマークなので無視できるレベルです)
これが個人的に一番大きいものです。
ストーリー終盤で低品質のアイテムを作ることになった、ある意味で最難関クエスト。（特に秘密シリーズを通しでプレイしている人ほど陥る罠）
アップデート前は
の「隠者の軟膏」をそれぞれ用意する必要がありましたが、
と、それぞれの足切りラインが大幅に緩くなりました。
https://atelier.reisalin.com/issues/580
他のアップデートによる修正は他にもあります（フェイタルドライブの早送りなど）が、上記3つが特に大きい内容です。
NextcloudのインストールでDBを作成す際に
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;としていました。
運用中、より正確な比較やソートが必要という判断をしたのでDBの照合順序をci(Case Insentive)ではなく、bin(Binary)に変更します。
DBを操作するため、作業前後にメンテナンスモードに入るとともに、ユーザーへの周知は徹底して行ってください。
cd /var/www/html/nextcloud && pwd自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)
sudo -u www-data php occ maintenance:mode --on運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。
cd /hoge && pwd任意のディレクトリを指定します。
mysqldump -h localhost -u nextcloud -p --no-tablespaces --single-transaction nextcloud > nextcloud_backup.$(date +%Y%m%d).sqlDB名やユーザーは自分の環境に合わせます。
ls -la nextcloud_backup.$(date +%Y%m%d).sqlファイルがあることを確認します。
mysql -u root -pSHOW DATABASES;nextcloudが動いているDBであることを再確認してください。
ALTER DATABASE nextcloud COLLATE utf8mb4_bin;USE nextcloud;SET @DATABASE_NAME = 'nextcloud';DB名は自分の環境に合わせます。
SET @COLLATE = 'utf8mb4_bin';SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' CONVERT TO CHARACTER SET utf8mb4 COLLATE ', @COLLATE, ';')
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = @DATABASE_NAME
AND TABLE_TYPE = 'BASE TABLE';EXITcd /var/www/html/nextcloud && pwd自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)
sudo -u www-data php occ maintenance:mode --off運用中のNextcloudのURLにアクセスし、普通にアクセスできることを確認します。
何か不具合があった場合の切り戻し手順です。上記、メンテナンスモードを有効化してから行ってください。
ls -l /hoge/nextcloud_backup.$(date +%Y%m%d).sqlバックアップを行ったディレクトリを指定します。
head -100 /hoge/nextcloud_backup.$(date +%Y%m%d).sqlファイルがあること、平文で読めることを確認します。
mysql -u root -pSHOW DATABASES;nextcloudが動いているDBであることを再確認してください。
二回ほど深呼吸して、落ち着いて作業しましょう。
DROP DATABASE nextcloud;CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;EXITmysql -h localhost -u nextcloud -p nextcloud < /hoge/nextcloud_backup.$(date +%Y%m%d).sql
この後、メンテナンスモードを解除して、以前と同じ状態か確認します。
平文でSQLがサーバ上にあるのは危険な状態なので、以下の措置を執ります。
cd /hoge && pwdバックアップを行ったディレクトリを指定します。
ls -la nextcloud_backup.$(date +%Y%m%d).sqlファイルがあることを確認します。
rm nextcloud_backup.$(date +%Y%m%d).sqlls -la nextcloud_backup.$(date +%Y%m%d).sqlファイルが無いことを確認します。
新たな文具入れを作ってもらいました。
大きめの巾着袋です。こちらに入るのは
表、裏ともに贅沢に芯地を使って丈夫さは相当のもの。
それだけにとどまらず、
今年作ってもらったペンケースと同じ裏地が使われています。
と合わせ、日常の文具セットが統一です。
初期設定の機会が多くなったので、改めてメモをします。
「いつ、どのような操作をしたか」を追いやすくするために以下の設定を行います。
sudo tee -a /etc/profile.d/history.sh > /dev/null << 'EOF'
export HISTSIZE=50000
export HISTFILESIZE=50000
export HISTTIMEFORMAT='%Y/%m/%d %H:%M:%S '
EOF設定後、新しいシェルセッションを開始するか、
source /etc/profile.d/history.shを実行することで上記が反映されます。
設定後、
history実行後、
1964 2024/09/17 15:12:18 cd /mnt/wasabi/
1965 2024/09/17 15:12:19 ll
1966 2024/09/17 15:12:24 cd redmine/
1967 2024/09/17 15:12:24 ll
1968 2024/09/17 15:12:27 cd files/
1969 2024/09/17 15:12:27 ll
1970 2024/09/17 15:12:31 pwd
1971 2024/09/17 16:27:20 cd
1972 2024/09/17 16:27:24 sudo aptitude update
1973 2024/09/17 16:28:35 sudo aptitude upgrade
1974 2024/09/17 16:30:23 sudo reboot
1975 2024/09/17 16:33:05 df -h
1976 2024/09/17 17:25:47 cd script/
1977 2024/09/17 17:25:47 llのように、日付と時間入りでコマンド操作履歴が表示されます。
ボードゲーム『ポンペイ滅亡』、個人的に遊ぶことが多いために、以下、ルールの覚え書きです。
2013年の再販版なら、
があります。基本ルールでは45枚の片面プリントを全て袋に入れておきます。
『パンデミック』のように、ある程度操作されたデッキを用います。
を分けておきます。
シャッフルした前兆(Omen)カード入りのデッキから下15枚を抜き出し、そこにA.D.79カード1枚を入れてシャッフル。残り17枚をその上に置きます。
シャッフルした前兆(Omen)カード入りのデッキから下15枚を抜き出し、そこにA.D.79カード1枚を入れてシャッフル。残り22枚をその上に置きます。
これが、後半戦トリガーのデッキになります。この上に、残りのA.D.79カードを1枚載せておきます。（表にしておいた方が良いでしょう）
更にその上に最初に切り分けた4枚の7つの束から2つを置きます。
| 2～3人 | 4人 |
|---|---|
| 4枚の束 | 4枚の束 |
| 4枚の束 | 4枚の束 |
| A.D.79カード | A.D.79カード |
| 前兆(Omen)カードが入っていて、A.D.79カードが入っていない17枚の束 | 前兆(Omen)カードが入っていて、A.D.79カードが入っていない22枚の束 |
| 前兆(Omen)カードが入っていて、A.D.79カードが入っている15枚の束 | 前兆(Omen)カードが入っていて、A.D.79カードが入っている10枚の束 |
こうして、適当なプレイヤーからゲームを進めます。
この手番を続け、最初の「A.D.79カード」が公開されたら前半2に進みます。
こうして縁者が増えてくると、プレイした番号のエリアに置けないことが多々起きます。そんなときは、ワイルドカードとして、任意のエリアであるかのように扱うことができます。
以下の条件となったら、火山は噴火します。
高らかに宣言します。「火山が噴火した！」
火山が噴火したら、
全てを箱に戻します。これらは残りのゲームでは使いません。
この、引いてしまった次のプレイヤーはこれまでのカードとコマではなく代わりに、タイルが入った袋に持ち替えます。
当時はまだ火山の脅威も知られていません。
なので、「何かヴェスヴィオスで大きな音がした」ぐらいの感覚で、ポンペイ市民は最初は何もしません。
順番に、溶岩タイルを布袋から引いて、グリッドに置いていきます。
コイン、巻物、青銅などがマップに描かれています。最初にそれらのマーク入りの溶岩タイルを引いたプレイヤーは、まずはそのマップの目印に目指してタイルを置いていきます。
これを、6回繰り返します。
その際に、同じマークのタイルを引いた場合は、既に置かれているタイルに隣接するようにタイルを置きます。この、置いた先にコマがあったら、それら全てをヴェスヴィオス火山に放り込みます。（つまり、溶岩の餌食となりました）
相手のいるコマに容赦なくぶつけるのも、ヘイト管理のため見逃すのも、全てはプレイヤーの意志にかかっています。
6枚のタイルが置かれたら、いよいよ市民達（コマ）は脱出を決意します。
マップ各所に描かれている門を目指していき、脱出したコマがそのまま得点になります。
のサイクルを繰り返します。
このサイクルを繰り返し、自分のコマが全ていなくなった(脱出/火山に放り込まれた問わず)としても、ゲームは続きます。その場合は火山タイルを被害が大きくなるように置いていくでしょう。
のどちらかでゲームが終了です。なお、タイルが尽きた際にまだポンペイ市街にコマがいたとしても、これらは火山に放り込まれます。
各プレイヤーは、逃げ延びたコマの数を数えます。その数が一番多いプレイヤーの勝利です。
多く脱出させたプレイヤーが同数いる場合、火山に放り込まれたコマの数を数えます。死者が少ない（コマが少ない）方が勝利します。
それも同じだった場合は「歴史を繰り返しましょう」。
別に分けていたタイルを一緒に袋に入れておきます。ゲーム中、それらの両面タイルを引いたプレイヤーは、どちらのサイドでも使えます。
ゲーム本体はコマは筒状です。そこで、ミープルに差し替えることで、「今入植させているのは/脱出させているのは」とよりリアリティを出します。
5人目には「ヴェスヴィオス火山の神」になってもらいます。
を、その5人目全てが取り仕切ります。
つまり、溶岩タイルがどこに向かうかは神の機嫌次第です。怒りを買わないようなプレイングを心がけましょう。
Cave! Hoc ludus ex rebus veris motus est. (注意! このゲームは実際の出来事をモチーフにしています)
コンポーネントもルールも全てが不謹慎。デザイナーが『カルカソンヌ』の作者であることを説明すると更に驚かれること間違い無しの作品です。
「A.D.79 イタリア」この年号にピンとくる歴史好きは多いことでしょう。
紀元79年8月24日、たった一夜で(文字通り)埋もれてしまったポンペイの歴史を追体験するゲームです。
に分かれていて、最終的に脱出させた自コマが多いプレイヤーが勝利します。
カードをプレイし、示された地図のグリッドにコマを置いておきます。
最初の「A.D.79」がデッキから公開されたら、入植者は次々に縁者を呼び寄せていきます。（別の共通するグリッドや他の色に更に駒を置くことができます。
この時、前兆となる「Omen」カードを引いたら任意のコマを火山に投げ入れることができます。
2枚目の「A.D.79」がデッキから公開された→ヴェスヴィオスの大噴火。
ゲームは後半戦にスタート。今まで持っていたカードや置かれていないコマを全て箱に戻し、全く別のゲームが始まります。
迫り来る溶岩タイルがポンペイ市街に降り注ぎ、被害は拡散していきます。
溶岩タイルをルールに従って配置し、出口である門の外へとコマを移動させるフェイズです。
そして、全てのコマが地図からいなくなったり溶岩タイルで埋められたらゲーム終了です。
等すべてに出落ち感が満載。歴史にある程度触れているならお察し案件になることもインパクトを増大させます。
『カルカソンヌ』と同じデザイナーということもあって、言語依存は極めて少なく、没入感に溢れたゲーム進行が出できます。
脱出ルールに少し説明が必要ですが、「他の市民を盾にして逃げる」とイメージさせやすいです。
「ゲームと現実の区別がつかない方」には徹底的にオススメできないテーマです。不謹慎さが許容できない方へのチョイスは厳に避けるべきです。
テーマの不謹慎さも相まって日本語版が用意されておらず、再販も2013年に一回しかかありません。自分が和訳ルールつきの新品を2018年に手に入れられたのは本当に幸運でした。
など、「こういう方向性のボードゲームもあるんだ」という、自分のその後の作品チョイスの方向性を決定づけたという記念の作品。
2018年に購入して以来、本当に定期的に遊ぶ作品のため改めてレビューいたしました。
自宅など、環境が許すなら
等の特定の曲/アルバムを流すとニヤリとされます。(この遺跡は漫画『第5部』の戦いの舞台です)
Snipe-IT のv7からPHP 8.1以降(PHP8.3含む)で動くようになりました。
こちらの方法を用いることでUbuntu24.04でもインストール可能だったことを確認していますが、データ移行はかなりハマりました。
Snipe-ITはデータ全体のバックアップとリストア機能を備えていますが、
のため、PHPのバージョンが合わないせいかインポート時にエラー発生。再アクセスしようとすると500エラーが発生。
と同じように、アップロードしたファイルを移行先に持っていき、mysqldumpで取得したファイルをインポートすることでうまくいくのではと思いましたが、これでも500エラーが発生。
お手上げ状態だった時に公式ドキュメントを見ると、答えが書いてありました。
「手段2：データの移行とSQLリストア」に加えて、これが必要でした。
Moving Snipe-ITによると
Moving/migrating Snipe-IT to a new server should be a pretty painless process. You really only have a few things to worry about:
- Your .env
- Your database
- Your uploaded files
- Your OAuth keys
とあります。上記サイトにある情報を元に、手順化を行います。
セットアップを行い、管理者アカウントを作成するところまで進めます。
mysqldump -h localhost -u snipeit -p --no-tablespaces --single-transaction snipeit > snipeit_db.$(date +%Y%m%d).sqlパスワードは移行元のDBパスワードです。取得したダンプファイルは、任意の安全な方法で移行先に転送します。
移行元先ルートディレクトリ/storage配下にある.envのAPP_KEY=base64:移行の文字列を、
移行元のAPP_KEY=base64:のものにそのまま上書きして保存します。
移行元のルートディレクトリ配下
└public/uploads
└storage/private_uploads
のディレクトリ一式を、同じように移行先に転送した上で、移行先のディレクトリに上書きます。（アクセス権は一致させます）
移行元のルートディレクトリ/storage配下にある
└oauth-private.key
└oauth-public.key
を、移行先の同じディレクトリにコピーして上書きます。
これ以降は移行先のみで作業を行います。
mysql -h localhost -u snipeit -p snipeit < /path/to/backup/directory/snipeit_db.$(date +%Y%m%d).sql転送したディレクトリにあるダンプファイルのパスを指定します。
cd /var/www/html/snipe-it && pwdなど、移行先のsnipe-itのルートディレクトリに移動します。
sudo -u www-data php artisan migrate途中のプロンプトはyesを指定します。
sudo -u www-data php artisan config:clearsudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
LAMP環境で動くアプリケーションを移行する際、だいたいは
の流れで別サーバへと移行が可能です。BookStackも同じような理屈で移行が行えるかを確かめたところ、罠がいくつかありました。
自サイトで恐縮ですが、手順はこちらをそのまま用いています。
これが一番ハマったポイントでした。
マイアカウント ＞ アクセス＆セキュリティ ＞ 多要素認証
で、二要素認証をオンにしていると、移行先でログインができませんでした。
なので、移行時の一時的な措置として解除を行います。
BookStackのルートディレクトリ配下の
/public/uploads/を一式、移行先へと転送して、同じディレクトリ構造に上書きします。SCPやtarで固める塔、任意の方法で転送します。
このとき、アクセス権をWebサービス実行ユーザにしてください。（Ubuntuのデフォルトはwww-data）
mysqldump -h localhost -u bookstackuser -p --no-tablespaces --single-transaction bookstack > bookstack_backup.$(date +%Y%m%d).sql-h DBサーバ名、-u bookstackのDBにアクセスできるユーザー DB名という形です。DBユーザに設定されているパスワードを入力してダンプを取ります。
こうしてできたDBは、任意の（安全で確実な）方法で移行先に転送します。
cd /hoge && pwdダンプしたDBファイルが転送されているディレクトリに移動します。
mysql -h localhost -u bookstackuser -p bookstack < bookstack_backup.$(date +%Y%m%d).sqlこれもハマったポイントでした。
/path/to/BookStack/root/directory && pwd/var/www/html/BookStackなど、移行先の、BookStackがインストールされているディレクトリに移動します。
sudo -u www-data php artisan migrate --forceこのマイグレーションを行わないと、リストアしたDBを参照してくれませんでした。
サーバのURLを変える場合はここにも罠があります。BookStackの設定ファイル、.envに
# Application URL
# This must be the root URL that you want to host BookStack on.
# All URLs in BookStack will be generated using this value
# to ensure URLs generated are consistent and secure.
# If you change this in the future you may need to run a command
# to update stored URLs in the database. Command example:
# php artisan bookstack:update-url https://old.example.com https://new.example.comという但し書きがありますので、この処理を行います。
/path/to/BookStack/root/directory && pwdsudo -u www-data php artisan bookstack:update-url https://old.example.com https://new.example.com二回ほど確認されますので、両方とも「yes」で答えます。
/path/to/BookStack/root/directory && pwdsudo -u www-data php artisan cache:clearsudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
Powered by WordPress & Theme by Anders Norén