カテゴリー: Linux Page 7 of 46

Redmineのチケットリマインダースクリプト、改良。

このスクリプトを改良しました。

スクリプト内容

  • redmine_reminder.sh
#!/bin/bash

# Redmineのルートディレクトリを変数化
REDMINE_ROOT="/var/lib/redmine"

# 引数で日数を指定(デフォルトは3日)
DAYS=${1:-3}

# Redmineのルートディレクトリに移動
cd $REDMINE_ROOT

# リマインダーを送信
bundle exec rake redmine:send_reminders days=$DAYS RAILS_ENV=production

改良内容として

ルートディレクトリを変数化することで、サーバを変えても動かしやすくしています。

一番の改良点は引数を指定できること。

redmine_reminder.sh 7

を実行すれば7日以内に到来するチケット、

redmine_reminder.sh 31

で同様に31日前のチケットをメール送信させることができます。

あとはcrontabに

# 8:20に31日前のリマインダーを送信
20 8 * * * /home/hoge/scripts/redmine_reminder.sh 31
# 8:30に1日前のリマインダーを送信
30 8 * * * /home/hoge/scripts/redmine_reminder.sh 1

# 16:30に7日前のリマインダーを送信
30 16 * * * /home/hoge/scripts/redmine_reminder.sh 7
# 16:40に1日前のリマインダーを送信
40 16 * * * /home/hoge/scripts/redmine_reminder.sh 1

# 20:20に3日前のリマインダーを送信
20 20 * * * /home/hoge/scripts/redmine_reminder.sh 3
# 20:30に1日前のリマインダーを送信
30 20 * * * /home/hoge/scripts/redmine_reminder.sh 1

などと実行しておけば、柔軟な設定が可能になります。

Redmine View Customize Pluginによる期日自動入力。(日報などの時限性トラッカー)

やること

日報代わりにRedmineのチケットを用いる場合、作成日=期日というパターンは割とあります。

そこで、チケットの作成と同時に、期日を自動的に入れるスクリプトを入れました。

環境

  • Redmine 5.1
  • 要 Redmine View Customize plugin

設定

  1. Redmineに管理者権限でログインします。
  2. 管理>表示のカスタマイズ>新しい表示のカスタマイズをクリックします。

スクリプト内容

  • パスのパターン
    • /issues/new$
  • プロジェクトのパターン
    • 空白
  • 挿入位置
  • チケット入力欄の下
  • 種別
  • JavaScript

スクリプト内容

$(document).ready(function() {
// トラッカーの選択が変更されたときに実行
$('#issue_tracker_id').change(function() {
var selectedTrackerId = $('#issue_tracker_id').val();
var startDate = $('#issue_start_date').val(); // 開始日を取得

// 特定のトラッカーIDが選択された場合
// トラッカーIDは管理>トラッカーから確認可能
if (selectedTrackerId == '6') {
$('#issue_due_date').val(startDate); // 期日に開始日を設定
}
});

// ページ読み込み時にトラッカーが既に選択されている場合にも対応
var selectedTrackerIdOnLoad = $('#issue_tracker_id').val();
var startDateOnLoad = $('#issue_start_date').val();

// 先に指定したトラッカーIDを指定する
if (selectedTrackerIdOnLoad == '6') {
$('#issue_due_date').val(startDateOnLoad);
}
});

作成後、保存をクリックします。

挙動

設定したトラッカーがあるプロジェクトに遷移し、新しいチケットを作成します。

トラッカーを選択後、期日が当日になっていれば設定完了です。

Ubuntu 24.04に設定したMod_Securityでファイルアップロードエラーを退避。

事象

Redmineでクリップボードの画像を貼り付けようとした際、画像のアップロードができませんでした。

そこで、エラーログを確認したところ、以下のメッセージが表示されました。

ModSecurity: Request body no files data length is larger than the configured limit (131072). [hostname "redmine-url"] [uri "/uploads.js"] [unique_id "Zv0wom0FwSak1tXDUgFRLAAAAAw"], referer: https://redmine-url/issues/3

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Mod_Security 2
  • Redmine 5.1

確認したこと

バーチャルサイトのMod_Securityの設定

SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000

と、50MBはアップロードできるようになっています。

Redmineでアップロード可能なファイル容量

管理> 設定 > ファイルの「添付ファイルサイズの上限でも`51200KB`を確認。

Mod_Security Confファイル確認

`cat /etc/modsecurity/modsecurity.conf |grep Limit` の結果、以下を確認しました。

SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
SecRequestBodyJsonDepthLimit 512
SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial

原因

`/etc/modsecurity/modsecurity.conf`の設定がバーチャルサイトの設定にオーバーライドしたため、こちらの設定が上書きされた模様です。

これを変更していきます。

対応手順

ファイルバックアップの作成

sudo cp -pi /etc/modsecurity/modsecurity.conf /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d)

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

バックアップ作成確認

diff -u /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d) /etc/modsecurity/modsecurity.conf

バックアップできていること(差分がないこと)を確認します。

sedによる書き換え

sudo sed -i 's/SecRequestBodyNoFilesLimit 131072/SecRequestBodyNoFilesLimit 52428800/; s/SecRequestBodyInMemoryLimit 131072/SecRequestBodyInMemoryLimit 52428800/; s/SecRequestBodyLimit 13107200/SecRequestBodyLimit 52428800/' /etc/modsecurity/modsecurity.conf

ファイル書き換え確認

diff -u /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d) /etc/modsecurity/modsecurity.conf

以下の差分を確認します。

-SecRequestBodyLimit 13107200
-SecRequestBodyNoFilesLimit 131072
+SecRequestBodyLimit 52428800
+SecRequestBodyNoFilesLimit 52428800
 
 # Store up to 128 KB of request body data in memory. When the multipart
 # parser reaches this limit, it will start using your hard disk for
 # storage. That is slow, but unavoidable.
 #
-SecRequestBodyInMemoryLimit 131072
+SecRequestBodyInMemoryLimit 52428800

設定反映

sudo systemctl restart apache2.service

書き換え後、無事にファイルのアップロードができることを確認しました。

Mod_Securityの連携。(検知した怪しい挙動とtor出口リストをブロックする)

個別に走らせていたスクリプトを1つにまとめました。

前提

  • Apache / Mod_Security導入済み
  • サイトのログローテーションが毎日であること

スクリプト

スクリプトの動き

  1. Tor出口リストを公式からダウンロードします。
  2. このリストからIPアドレスだけを抽出します。
  3. 変数に従ってエラーログからMod_Securityが検知したIPアドレスだけを抽出します。
  4. これらをMod_Securityのnegativelistに入れ、以下のサイトアクセスを丸ごと弾きます。
    • Tor出口リストに登録されているIPアドレス
    • Mod_Securityが検知したIPアドレス
  5. 自分の偽陽性を防ぐため、自分のゲートウェイなどのIPアドレスからのアクセスは除外します。
  6. リストを反映させるためApacheを再起動します。

スクリプト内容

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

スクリプトの他に用意するもの

  • exclude_ips.txt
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.txt
  • cron設定
sudo crontab -e -u root

として、

0 2 * * * /path/to/this_script.sh

等と設定すれば、毎日2時に、その日に検知した怪しい動きをシャットダウンしてくれます。

NextcloudのDB、照合順序を変更。

NextcloudのインストールでDBを作成す際に

CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

としていました。

運用中、より正確な比較やソートが必要という判断をしたのでDBの照合順序をci(Case Insentive)ではなく、bin(Binary)に変更します。

DBを操作するため、作業前後にメンテナンスモードに入るとともに、ユーザーへの周知は徹底して行ってください。

メンテナンスモードを実行

  • Nextcloudのルートディレクトリ移動
cd /var/www/html/nextcloud && 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

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

DB設定変更

  • 管理者権限でMySQLにログインする
mysql -u root -p
  • 対象のDBを確認する
SHOW 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';
  • MySQLから抜ける
EXIT

メンテナンスモードの解除を実行

  • Nextcloudのルートディレクトリ移動
cd /var/www/html/nextcloud && pwd

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

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

運用中のNextcloudのURLにアクセスし、普通にアクセスできることを確認します。

切り戻し

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

  • バックアップした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を削除する

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

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の削除
rm nextcloud_backup.$(date +%Y%m%d).sql
  • DBバックアップ削除確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

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

Linuxサーバの履歴を追いやすくする設定。

初期設定の機会が多くなったので、改めてメモをします。

「いつ、どのような操作をしたか」を追いやすくするために以下の設定を行います。

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
  • 全ユーザーでhistoryコマンドの履歴を5万行に引き上げます。
  • コマンド実行した日付を記載します。

設定後、新しいシェルセッションを開始するか、

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

のように、日付と時間入りでコマンド操作履歴が表示されます。

Snipe-ITのデータを別サーバに移行したときにハマったこと。(Ubuntu20.04/v6→Ubuntu24.04/v7)

Snipe-IT のv7からPHP 8.1以降(PHP8.3含む)で動くようになりました。

こちらの方法を用いることでUbuntu24.04でもインストール可能だったことを確認していますが、データ移行はかなりハマりました。

うまくいかなかった手段1:データのバックアップ/リストア機能

Snipe-ITはデータ全体のバックアップとリストア機能を備えていますが、

  • 移行元:Ubuntu 20.04
    • v6
    • PHP8.1
    • Apache2.4
    • MySQL8
  • 移行先:Ubuntu 24.04
    • v7
    • PHP8.3
    • Apache2.4
    • MySQL8

のため、PHPのバージョンが合わないせいかインポート時にエラー発生。再アクセスしようとすると500エラーが発生。

うまくいかなかった手段2:データの移行とSQLリストア

  • firefly-iii
  • BookStack

と同じように、アップロードしたファイルを移行先に持っていき、mysqldumpで取得したファイルをインポートすることでうまくいくのではと思いましたが、これでも500エラーが発生。

お手上げ状態だった時に公式ドキュメントを見ると、答えが書いてありました。

うまくいった手段:keyファイルの上書きとマイグレーション

「手段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

とあります。上記サイトにある情報を元に、手順化を行います。

【移行先】Snipe-ITを新たにインストールします。

セットアップを行い、管理者アカウントを作成するところまで進めます。

【移行元】→【移行先】各種データを転送します。

  • SQLのダンプファイル
mysqldump -h localhost -u snipeit -p --no-tablespaces --single-transaction snipeit > snipeit_db.$(date +%Y%m%d).sql

パスワードは移行元のDBパスワードです。取得したダンプファイルは、任意の安全な方法で移行先に転送します。

  • .envのAPP_KEY

移行元先ルートディレクトリ/storage配下にある.envAPP_KEY=base64:移行の文字列を、

移行元のAPP_KEY=base64:のものにそのまま上書きして保存します。

  • ファイルディレクトリ一式の転送

移行元のルートディレクトリ配下

public/uploads
storage/private_uploads

のディレクトリ一式を、同じように移行先に転送した上で、移行先のディレクトリに上書きます。(アクセス権は一致させます)

  • OAuth key

移行元のルートディレクトリ/storage配下にある

oauth-private.key
oauth-public.key

を、移行先の同じディレクトリにコピーして上書きます。

【移行先】DBのリストアとマイグレーションを行います。

これ以降は移行先のみで作業を行います。

  • ダンプファイルのリストア
mysql -h localhost -u snipeit -p snipeit < /path/to/backup/directory/snipeit_db.$(date +%Y%m%d).sql

転送したディレクトリにあるダンプファイルのパスを指定します。

  • Snipe-ITのルートディレクトリに移動
cd /var/www/html/snipe-it && pwd

など、移行先のsnipe-itのルートディレクトリに移動します。

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

途中のプロンプトはyesを指定します。

  • コンフィグクリア
sudo -u www-data php artisan config:clear

Webサービスを再起動し、データ移行を確認します。

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

active(running)を確認します。

  • データ移行確認
  1. 移行先のSnipe-ITをインストールしたURLにアクセスします。
  2. 移行元のアカウントでログインできることを確認します。
  3. 移行元と同じデータがあることを確認します。

BookStackのサーバ移行でハマったこと。

LAMP環境で動くアプリケーションを移行する際、だいたいは

  1. 移行先でWebアプリを作成する
  2. 移行元から移行先へとデータ(画像や添付ファイル)をコピーする
  3. DBをエクスポート→インポートする

の流れで別サーバへと移行が可能です。BookStackも同じような理屈で移行が行えるかを確かめたところ、罠がいくつかありました。

環境

共通環境

  • Apache 2.4
  • MySQL8系

移行元

  • Ubuntu 20.04
  • PHP 8.1

移行先

  • Ubuntu 24.04
  • PHP 8.3

さっくりといかない手順

  1. 【移行先】BookStackを構築します。
  2. オプション【移行元】アカウントのセキュリティ設定を一度解除します。
  3. 【移行元】→【移行先】画像や添付データ一式を転送します。
  4. 【移行元】→【移行先】MySQLのダンプを行い、DBを転送します。
  5. 【移行先】DBをインポートします。
  6. 【移行先】DBマイグレーションを行います。
  7. オプション【移行先】URLの変更処理を行います。
  8. 【移行先】設定の反映を行います。
  9. 【移行先】移行先で確認を行います。

【移行先】BookStackを構築します。

自サイトで恐縮ですが、手順はこちらをそのまま用いています

オプション【移行元】管理アカウントの二要素認証を解除。

これが一番ハマったポイントでした。

マイアカウント > アクセス&セキュリティ > 多要素認証

で、二要素認証をオンにしていると、移行先でログインができませんでした。

なので、移行時の一時的な措置として解除を行います。

【移行元】→【移行先】データの転送

BookStackのルートディレクトリ配下の

/public/uploads/を一式、移行先へと転送して、同じディレクトリ構造に上書きします。SCPやtarで固める塔、任意の方法で転送します。

このとき、アクセス権をWebサービス実行ユーザにしてください。(Ubuntuのデフォルトはwww-data)

【移行元】→【移行先】DBのデータ移行

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は、任意の(安全で確実な)方法で移行先に転送します。

【移行先】DBのリストア

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

ダンプしたDBファイルが転送されているディレクトリに移動します。

  • DBインポート
mysql -h localhost -u bookstackuser -p bookstack < bookstack_backup.$(date +%Y%m%d).sql

【移行先】DBのマイグレーション

これもハマったポイントでした。

  • BookStackルートディレクトリに移動
/path/to/BookStack/root/directory && pwd

/var/www/html/BookStackなど、移行先の、BookStackがインストールされているディレクトリに移動します。

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

このマイグレーションを行わないと、リストアしたDBを参照してくれませんでした。

オプション【移行先】URL変更処理

サーバの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

という但し書きがありますので、この処理を行います。

  • BookStackルートディレクトリに移動
/path/to/BookStack/root/directory && pwd
  • URLアップデート
sudo -u www-data php artisan bookstack:update-url https://old.example.com https://new.example.com

二回ほど確認されますので、両方とも「yes」で答えます。

DB上書き反映

  • BookStackルートディレクトリに移動
/path/to/BookStack/root/directory && pwd
  • キャッシュクリア
sudo -u www-data php artisan cache:clear
  • Webサービス(apache)再起動
sudo systemctl restart apache2.service
  • Webサービス(apache)再起動確認
systemctl status apache2.service

active(running)を確認します。

サーバ移行確認

  1. ブラウザで移行先のURLにアクセスします。
  2. ログインできることを確認します。
  3. 前のデータ(画像や添付含む)が閲覧できることを確認します。
  4. 記事の作成等が行えることを確認します。
  5. 多要素認証をしている場合は、再設定します。

Mod_Securityで特定のルールを無視する設定(Nextcloudでの偽陽性を排除)

Nextcloudにmod_securityを導入するに当たり、気をつけなければならないのがファイルの閲覧や登録、入力処理中にMod_securityが不審な処理として判断してしまうこと(偽陽性)です。

そこで、

  1. 偽陽性と思われるログの調査
  2. 調査時の補助線引き
  3. 偽陽性になるルールを無視する設定

を行います。

ログ確認

/var/log/nextcloud_error.logから、以下のようなログを見ました。

[Wed Sep 11 16:35:02.048442 2024] [security2:error] [pid 32762:tid 32762] [client aaa.bbb.ccc.ddd:56994] [client aaa.bbb.ccc.ddd] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "92"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [ver "OWASP_CRS/3.3.5"] [tag "event-correlation"] [hostname "nextcloud.hoge.com"] [uri "/ocs/v2.php/apps/user_status/api/v1/heartbeat"] [unique_id "ZuFIJU_udFaqxqrJvRLaPQAAAAA"]

ここで見たいのは

  • クライアントのIPアドレス
  • どのようなルールIDを
  • どのぐらい検知したか

です。

ログ確認のワンライナー

これらを確認するため、copilotの助けを借りてawkスクリプトを生成します。

awk '/ModSecurity/ {
ip = gensub(/.*\[client ([0-9.]+):.*/, "\\1", "g", $0);
rule_id = gensub(/.*\[id "([0-9]+)"\].*/, "\\1", "g", $0);
print rule_id, ip;
}' /var/log/nextcloud/nextcloud_error.log | sort | uniq -c

これを実行したところ、Mod_Securityがエラーとして検知したログの中から

     36 911100 127.0.0.1
    267 911100 aaa.bbb.ccc.ddd
     65 920420 aaa.bbb.ccc.ddd
     36 949110 127.0.0.1
    267 949110 aaa.bbb.ccc.ddd
     36 980130 127.0.0.1
    267 980130 aaa.bbb.ccc.ddd

という結果を確認しました。127.0.0.1はローカルアドレス、aaa.bbb.ccc.dddも自分がアクセスしてきたIPアドレス。この間、自分がしていたのはNextcloudの設定変更やファイルの閲覧のみです。

Mod_securityが検知したルールIDを「偽陽性」と判断し、処置していきます。

Mod_Securityで特定のルールを検知させない処理

Apacheのバーチャルサイトで設定しているという形です。

設定ファイルの修正

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

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

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

エラー無く、差分も表示されていなければバックアップは成功です。

  • ファイル修正

/etc/apache2/sites-available/nextcloud.confを以下のように修正していきます。(要root権限)

# Mod_security
## 最初は検知モード

SecRuleEngine DetectionOnly

## 偽陽性と判断したID
SecRuleRemoveById 911100
SecRuleRemoveById 920420
SecRuleRemoveById 949110
SecRuleRemoveById 980130
  • ファイル修正確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

SecRuleRemoveById IDで、これにマッチするパターンは無視します。

  • 差分例
 ## 最初は検知モード

 SecRuleEngine DetectionOnly
+
+## 偽陽性と判断したID
+SecRuleRemoveById 911100
+SecRuleRemoveById 920420
+SecRuleRemoveById 949110
+SecRuleRemoveById 980130
+
 </VirtualHost>

設定ファイルの設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • 設定反映
sudo systemctl restart apache2.service
  • Apache稼働確認
systemctl status apache2.service

active(running)を確認します。

動作確認

ターミナルで

tail -f /var/log/nextcloud/nextcloud_error.log

としてエラーログを流します。(エラーログは自分の環境に合わせます)

  • 上記処理を行ったNextcloudにアクセスして操作をしていきます。
  • 処理を行ったIDが検知されないことを確認します。

Ubuntu 20.04で動いていたfirefly-iiiをUbuntu24.04にデータ移行。

Linuxで動く財務管理システムfirefly-iii。

Ubuntu 24.04で動くことを確認したので、20.04からのデータを移行しました。(自分の手順では)

環境

移行前

  • Ubuntu 20.04
  • PHP 8.1
  • firefly-iii 5.7.9

移行先

  • Ubuntu 20.04
  • PHP 8.3
  • firefly-iii 6.1.16

その他はApache、MySQL環境です。

さっくりとした(?)手順

  1. 移行先のfirefly-iiiを構築します。
  2. 移行前のSQLダンプファイルを取得します。
  3. 移行先でダンプファイルをインポートします。
  4. 動作を確認します。

【移行先】firefly-iiiを構築します。

方法はこちらです。

【移行元】DBのダンプファイルを取得します。

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

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

  • ダンプファイル取得
mysqldump -u firelfy -p --no-tablespaces --single-transaction firefly > firefly_$(date +%Y%m%d).sql

-u DBユーザー >の左のfireflyはDB名です。自分の環境に合わせます。

  • パスワードを入力してもファイルが取得できないときは?

パスワードに!などの特殊文字が入っていると羽の肥えるパターンがあります。passwdといったファイルを作成し、以下のように記入します。

[mysqldump]
user=DBユーザー
password=''

※パスワードはシングルクォーテーションで囲みます。

こちらのファイルを作った上で、

mysqldump --defaults-extra-file=passwd --no-tablespaces --single-transaction firefly > firefly_$(date +%Y%m%d).sql

実行します。 このpasswdファイルは作業後に削除します。

  • ファイル取得確認
head -50 firefly_$(date +%Y%m%d).sql

ダンプファイルの内容が見られることを確認します。

このダンプファイルを任意の安全な方法で移行先にコピーします。

【移行先】DBのインポートを行います。

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

ダンプファイルを転送したディレクトリを指定します。

  • DBインポート
mysql -h localhost -u firefly -p firefly < firefly_$(date +%Y%m%d).sql 

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

  • Webサービス(Apache)再起動
sudo systemctl restart apache2.service
  • サービス再起動確認
systemctl status apache2.service

active(running)を確認します。

動作の確認を行います。

移行先のfirefly-iiiをインストールしたドメインにアクセスして

  • 移行元のアカウントで認証できること
  • 移行元のデータが確認できること
  • データの検索や登録ができること

を確認できればOKです。

作業の後処理を行います。

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

ダンプファイルを転送したディレクトリを指定します。

  • ダンプファイル削除
sudo rm firefly_$(date +%Y%m%d).sql 

必要に応じて、移行元サイトの閉鎖を行います。

Page 7 of 46

Powered by WordPress & Theme by Anders Norén