カテゴリー: ガジェット Page 6 of 85

MySQLのデータベースを暗号化してバックアップするスクリプト。

概要

以前も作成していた、MySQLのデータベースのバックアップを自動的に取得するスクリプトを少々リファインさせました。

変数指定により、複数のDBを任意にバックアップできます。

スクリプトの動き

  • サーバ内にあるDBのバックアップを取得し、暗号化して指定ディレクトリに保存します。
  • 複合化のパスワードはスクリプトが自動生成し、暗号化と同時に別ディレクトリに保存します。
  • cronの自動実行を前提としているため、古い暗号化ファイルと複合化のパスワードは一定期間後に削除を行います。

動作を確認したサーバ

  • Ubuntu 24.04
  • MySQL 8.0.39

前準備

アカウントファイル

任意のディレクトリに、db_account.txtといった、DBにユーザー名とパスワードを記したファイルを作成しておきます。

[client]
user = db_user
password = "password"
  • パーミッションは400にします。(chmod 400 db_account.txt)
  • 取り扱いは慎重に行ってください。

バックアップDBの格納先

  1. 冗長性があり
  2. 機密性が保たれる

場所を指定してください。筆者はクラウドストレージ(wasabi)をマウントしています。

パスワードの格納先

/home/hoge/dbrestore_password のように、複合化のパスワードを格納するディレクトリを作っておきます。
こちらも運用に合わせ、適切に保管ができる場所を指定します。

それぞれ、スクリプト実行アカウントがアクセス/実行できるものにします。

スクリプト

スクリプト内容

  • スクリプトファイル名(例)
    • mysql_db_backup.sh

変数などは間違いの無いように指定ください。

#!/bin/bash

## 変数ここから ##
# $HOMEの変数を指定します。
HOME_DIR="/home/hoge"
# SQLをバックアップするディレクトリ(保管先)を指定します。運用に合わせて指定ください。
backup_dir="/path/to/backup/directory"
# 保持するバックアップの世代を日数で指定します。
keep_days=7
# ファイルに付与する日付/作業ディレクトリ名/バックアップファイル名を指定します。
current_date=$(date +%Y%m%d)
backup_name="backup_mysql_${current_date}"
zip_file="backup_mysql.${current_date}.zip"
# アカウントファイルを指定します。運用に合わせて指定ください。
credentials_file="${HOME_DIR}/script/config/db_account/db_account.txt"
# パスワードを記録するファイル名を指定します。運用に併せてして指定ください。
password_dir="${HOME_DIR}/dbrestore_password"
password_file="${password_dir}/db-restore.${current_date}.txt"
# redmineのデータベース名を指定します。
database_name=database
# バックアップ時に指定するオプションを指定します。
options="--defaults-extra-file=$credentials_file --no-tablespaces --single-transaction"
# バックアップファイルのパターンを指定します。
backup_file_pattern="backup_mysql.*.zip"
# パスワードファイルのパターンを指定します。
password_file_pattern="*restore*.txt"
## 変数ここまで ##

## 処理ここから ##

# 1.アカウントファイルのパーミッションが400かどうかチェックします。
# 400以外は処理そのものを終了します。
permissions=$(stat -c "%a" "$credentials_file")
if [ "$permissions" != "400" ]; then
echo "アカウントファイルのパーミッションは400である必要があります。"
exit 1
fi

# 2.一時的なバックアップディレクトリを作成します。
mkdir "${backup_dir}/${backup_name}"

# 3. mysqldumpを実行してデータベースのバックアップを取ります。
mysqldump $options -h localhost $database_name > "${backup_dir}/${backup_name}/${backup_name}.sql"

# 4. パスワードによる暗号化を実施します。
password=$(openssl rand -base64 12)
cd "${backup_dir}/${backup_name}"
zip -r "${backup_dir}/${zip_file}" -P "$password" .
cd -

# 5. 一時的なバックアップディレクトリを削除します。
rm -rf "${backup_dir}/${backup_name}"

# 6. 解凍パスワードを指定ディレクトリに保存します。
echo $password > $password_file

# 7.パスワードの読み取り権限を600に変更します。
chmod 600 $password_file

# 8. 保持期間より古いバックアップファイルを削除します。
find "$backup_dir" -name "$backup_file_pattern" ! -type f -newermt "${keep_days} days ago" -delete
find "$password_dir" -name "$password_file_pattern" ! -type f -newermt "${keep_days} days ago" -delete

## 処理ここまで ##

作成後、

chmod +x mysql_db_backup.sh

で実行権を付与します。

スクリプトの動かし方

スクリプトの動き

./mysql_db_backup.sh

として実行すると、

  1. 変数で指定したアカウントファイルを読み込み、mysqldumpでバックアップを取ります。
  2. バックアップ作成後、パスワード付きzipファイルに圧縮します。
  3. 圧縮されたバックアップと複合化のためのテキストファイルを変数で指定したディレクトリに格納します。
  4. 変数で指定した期日が過ぎたバックアップファイルと複合化のためのテキストファイルは自動的に削除されます。

バックアップDBの解凍

unzip backup_mysql.yyyymmdd.zip

とすると、パスワードを尋ねられます。

db-restore.yyyymmdd.txtに表示された文字列を入力します。

または、

unzip -P $(cat /path/to/password_file.txt) /path/to/zip_file.zip -d /path/to/output_directory

でファイルを直接引数にして解凍することもできます。

cronの指定

動作を確認したら、

crontab -e -u hoge

でcron編集画面を出し、

0 2 * * * /home/hoge/script/directory/mysql_db_backup.sh

などとして指定すれば、日次のDBバックアップを取得可能です。

Ubuntu 20.04で動いていた Redmine 4.2のデータを Ubuntu 24.04上のRedmine 5.1に移行。

概要

Redmine 4.2 を動かしている Ubuntu 20.04 が2025年4月にEOLを迎えるため、Redmine 5.1 (Ubuntu 24.04)にリプレースをしました。

最初に

  • 「この手順で上手くいった」という筆者のメモ書きです。
  • Rubyのバージョン違いなどで動かないプラグインがいくつかあります。代替手段は別途考慮してください。

動かなかったプラグインとワークアラウンド

redmine_knowledgebase です。

5.xで動くフォークを試したものの、rubyの兼ね合いで動きませんでした。

そのため、記事をこのBookStackに移行させています。

環境

移行前環境

  • Ubuntu 20.04
  • Redmine 4.2
  • Ruby 2.7
  • Apache 2.4
  • MySQL 8.0.39

移行後環境

  • Ubuntu 24.04
  • Redmine 5.1
  • Ruby 3.2
  • Apache 2.4
  • MySQL 8.0.39

さっくりとはならない手順

  1. 【移行先】空のRedmineを構築します。
  2. 【移行元】DBのダンプファイルを作成し、移行先に転送します。
  3. 【移行元】ファイル、メール設定ファイルなどを移行先に転送します。
  4. 【移行先】DBをリストアします。
  5. 【移行先】gemのアップデートを行います。
  6. 【移行先】移行元で稼働していたプラグインを入れていきます。
  7. 【移行先】動作確認を行います。
  8. 【移行元】移行元のredmineを停止します。
  9. 【移行先】必要に応じてDNSの切り替えと移行先のサイト設定を行います。

【移行先】Redmineを構築していきます。

  • こちらのページに従って、移行先のUbuntu 24.04サーバに、Redmineを構築していきます。
  • 構築したてのRedmineのアカウントとパスワードは admin /admin なので、仮パスワードを設定しておきます。

【移行元】DBのダンプファイルを作成して転送します。

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

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

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

ユーザー名(-uの後)とDB名(>の前)は自分の環境に合わせます。

  • ダンプファイル内容確認
view redmine_backup.$(date +%Y%m%d).sql

SQL文が平文で読めることを確認します。

作成後、任意の安全な方法で移行先に転送します。

【移行元】各種ファイルを転送します。

以下のディレクトリやを任意の安全な方法で転送します。

/path/to/redmine/root/directory配下(移行前のRedmineルートディレクトリ)の

  • files ディレクトリ(添付ファイル一式)
  • config/configuration.yml ファイル(メール設定がある場合)
  • public/thme/配下のテーマディレクトリ

これらのファイルは転送後、移行後のRedmineに対応するディレクトリ/ファイルに、そのまま上書きます。

【移行先】DBのリストアを行います。

  • ダンプファイル格納ディレクトリに移動
cd /hoge && pwd
  • ダンプファイル確認
ls -l redmine_backup.$(date +%Y%m%d).sql

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

  • DBリストア
mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql

このときのパスワードは、「移行先のRedmineのDBユーザのパスワード」です。

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

Webサービス再起動後に

  1. 移行後のRedmineサイトが移行元と同じ見た目であること
  2. ログインできること
  3. プロジェクト一覧が見られること

までは確認しましたが、チケットを確認しようとすると

500 internal server error

が発生し、閲覧も編集もできない事態が発生しました。

【移行先】gemのアップデートを行います。

こちらの、チケット表示でinternal server errorを解消するため、

Has 500 Internal Server Error when upgrade 4.1.1 to 4.2.7, please help.
https://www.redmine.org/boards/2/topics/67435

この手順を追加します。

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

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

  • gem update
 sudo gem update

しばらく時間がかかります。

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

gemのアップデート後、今度はエラーが出ないことを確認です。

【移行先】各種プラグインを入れていきます。

移行前に動いていたプラグインを確認しながら、プラグインを入れていきます。

DBマイグレーション中にrake abortedが出た場合は、そのプラグインはRedmine/Rubyのバージョンが合わないので、動かないプラグインです。

【移行先】動作環境を行っていきます。

プラグインを入れながら、既存の機能(別のユーザーがログインできるか、アクセス権は合っているか、チケットの作成や更新ができるか)などを見ていきます。

【移行元】稼働していたRedmineサイトを停止します。

移行元のサーバにSSHログインし、

sudo a2dissite redmine.conf

redmine.confは自分の環境に合わせます。

で設定ファイルを無効化後、

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

として、稼働していた移行元のサイトにアクセスできないことを確認します。

【移行先】必要に応じてDNSの切り替えと移行先のサイト設定を行います。

これは、移行元でも同じURL(ドメイン)を使いたい場合の措置です。

  • DNS向き先変更

DNを利用して、ドメインを移行先のIPアドレスへと付け替えます。

各種DNSサービスによって異なるので、そちらを参照してください。

  • apacheバーチャルサイトの設定変更

/etc/apaches/site-available/redmine.conf (自分の環境に合わせます)

の以下の箇所を編集していきます。

<VirtualHost *:80>
servername hoge.example.com
# 今まで動いていたドメイン名

<VirtualHost *:443>
    ServerName hoge.example.com
# 今まで動いていたドメイン名
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

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

切り替え後

  1. 前と同じドメインで、新しいRedmineサイトにログインできる
  2. (プラグインが廃止していなければ)同じ機能を使える

ことを確認できれば作業完了です。

移行後の処理

  1. DB移行時に利用したダンプファイルを削除します。
  2. 時期を見て旧サーバのデータの削除を行います。

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

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

袋とペンケース。

新たな文具入れを作ってもらいました。

大きめの巾着袋です。こちらに入るのは

  • ジブン手帳
  • ほぼ日Weekly
  • 情報カードホルダー
  • サブのペンケース。

表、裏ともに贅沢に芯地を使って丈夫さは相当のもの。

それだけにとどまらず、

今年作ってもらったペンケースと同じ裏地が使われています。

  • ペンケース
  • ほぼ日(オリジナル)

と合わせ、日常の文具セットが統一です。

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. 移行元と同じデータがあることを確認します。

Page 6 of 85

Powered by WordPress & Theme by Anders Norén