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

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

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

表、裏ともに贅沢に芯地を使って丈夫さは相当のもの。
それだけにとどまらず、

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

- ペンケース
- ほぼ日(オリジナル)
と合わせ、日常の文具セットが統一です。
初期設定の機会が多くなったので、改めてメモをします。
「いつ、どのような操作をしたか」を追いやすくするために以下の設定を行います。
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
のように、日付と時間入りでコマンド操作履歴が表示されます。
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:clear
sudo systemctl restart apache2.service
systemctl status apache2.service
active(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 && pwd
sudo -u www-data php artisan bookstack:update-url https://old.example.com https://new.example.com
二回ほど確認されますので、両方とも「yes」で答えます。
/path/to/BookStack/root/directory && pwd
sudo -u www-data php artisan cache:clear
sudo systemctl restart apache2.service
systemctl status apache2.service
active(running)
を確認します。
Nextcloudにmod_securityを導入するに当たり、気をつけなければならないのがファイルの閲覧や登録、入力処理中にMod_securityが不審な処理として判断してしまうこと(偽陽性)です。
そこで、
を行います。
/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"]
ここで見たいのは
です。
これらを確認するため、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を「偽陽性」と判断し、処置していきます。
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
systemctl status apache2.service
active(running)
を確認します。
ターミナルで
tail -f /var/log/nextcloud/nextcloud_error.log
としてエラーログを流します。(エラーログは自分の環境に合わせます)
Linuxで動く財務管理システムfirefly-iii。
Ubuntu 24.04で動くことを確認したので、20.04からのデータを移行しました。(自分の手順では)
その他はApache、MySQL環境です。
方法はこちらです。
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
ダンプファイルの内容が見られることを確認します。
このダンプファイルを任意の安全な方法で移行先にコピーします。
cd /hoge && pwd
ダンプファイルを転送したディレクトリを指定します。
mysql -h localhost -u firefly -p firefly < firefly_$(date +%Y%m%d).sql
ユーザ名やDB名は自分の環境に合わせます。
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
必要に応じて、移行元サイトの閉鎖を行います。
運用の好みの問題です。
sudo su -
等でrootに昇格する際、入力されたかを確かめる*
を表示するようにして視認性を高めます。
sudo cp -pi /etc/sudoers /path/to/backup/directory/sudoers.$(date +%Y%m%d)
任意のバックアップディレクトリを指定します。
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers
差分が無ければバックアップは成功です。
sudo sed -i 's/^Defaults\s\+env_reset$/Defaults env_reset,pwfeedback/' /etc/sudoers
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers
-Defaults env_reset
+Defaults env_reset,pwfeedback
設定を行ったサーバに対して、新しくSSHセッションを作成します。
sudo su -
でパスワードを入力時に*
が表示されれば設定は反映されています。
ApacheのWAFモジュールであるmod_securityを導入します。
として機能しているにもかかわらず文書化していなかったので、Web Arenaでの検証を機に文章に残します。
※ パッケージ管理にaptitudeを用いています。必要に応じてaptに読み替えてください。
sudo aptitude update
sudo aptitude install libapache2-mod-security2
sudo apache2ctl -M |grep security
security2_module (shared)
と表示されていることを確認します。
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
推奨ファイルをそのまま設定ファイルとして書き換えます。
cd /usr/share/modsecurity-crs && pwd
sudo git clone https://github.com/coreruleset/coreruleset.git
sudo mv /usr/share/modsecurity-crs/coreruleset/crs-setup.conf.example /usr/share/modsecurity-crs/coreruleset/crs-setup.conf
cd /etc/apache2/mods-available/ && pwd
sudo cp -pi security2.conf /path/to/backup/directory/security2.conf.$(date +%Y%m%d)
任意のバックアップディレクトリを指定します。
diff -u /path/to/backup/directory/security2.conf.$(date +%Y%m%d) security2.conf
エラーがなければバックアップは成功です。
/etc/apache2/mods-available/security2.conf
を、以下の差分になるように教義・信仰に沿ったエディタで編集します。(要root権限)
- </IfModule>
+ # Include OWASP ModSecurity CRS rules if installed
+ IncludeOptional /usr/share/modsecurity-crs/*.load
+</IfModule>
sudo apache2ctl configtest
Syntax OK
を確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active (running)
を確認します。
稼働済みのApacheバーチャルサイトの設定ファイルをいじります。バックアップ確認は入念に行ってください。
cd /etc/apache2/sites-available && pwd
sudo cp -pi your_site.conf /path/to/backup/directory/your_site.conf.$(date +%Y%m%d)
.confファイルやバックアップディレクトリは自分の環境を指定します。
diff -u /path/to/backup/directory/your_site.conf.$(date +%Y%m%d) your_site.conf
エラーがなければバックアップは成功です。
/etc/apache2/sites-available/your_site.conf
を、以下の差分になるように教義・信仰に沿ったエディタで編集します。(要root権限)
# Mod Security
## ModSecurity有効化
SecRuleEngine On
## ModSecurity検知モード
### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
#SecRuleEngine DetectionOnly
## ファイルのアップロードをできるようにします。
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## テスト用の検知パラメータを付け加えます。
SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
diff -u /path/to/backup/directory/your_site.conf.$(date +%Y%m%d) your_site.conf
+# Mod Security
+
+## ModSecurity有効化
+SecRuleEngine On
+## ModSecurity検知モード
+### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
+#SecRuleEngine DetectionOnly
+
+## ファイルのアップロードをできるようにします。
+SecRequestBodyInMemoryLimit 524288000
+SecRequestBodyLimit 524288000
+
+## テスト用の検知パラメータを付け加えます。
+ SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
+
sudo apache2ctl configtest
Syntax OK
を確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active (running)
を確認します。
?modsecparam=test
を追加してアクセスします。のように、アクセスできないことを確認します。
また、サーバでも
sudo cat /path/to/sites_log/directory/sites_error.log
※ログの格納場所やログの名前は自分の環境に合わせます。
を開き、
ModSecurity: Access denied with code 403 (phase 2). String match "test" at ARGS:modsecparam. [file "/etc/apache2/sites-enabled/your_site.conf"] [line "53"] [id "4321"] [msg "ModSecurity test rule has triggered"] [hostname "host_address"] [uri "/"] [unique_id "xxxxxxx"]
のように、エラーが発生していることを確認します。
WordPress、Redmine等のWebアプリは自身の操作によって「不審なアクセス」として遮断することが極めてよくあります。(偽陽性)
そのため、テストを行った後は
## ModSecurity有効化
#SecRuleEngine On
## ModSecurity検知モード
### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
SecRuleEngine DetectionOnly
として検知モードとして動かした方が良いでしょう。
ここから施行を繰り返し、「結局、Ubuntu24.04でなければ動かないだろう」という結論。
無事にインストールできたので、その記録です。
以下、既に構築済みという状況です。
そして、以下を準備済みです。
cd /home/www-data
Web公開用のディレクトリを指定します。
git clone https://github.com/firefly-iii/firefly-iii.git -b v6.1.19
※PHP8.3で稼働するバージョンを指定しています。
ls -ld firefly-iii
ディレクトリが作成されていること、Web実行ユーザ(www-data)であることを確認します。
mysql -u root -p
CREATE DATABASE firefly character set utf8mb4;
CREATE USER 'firefly'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON firefly.* TO 'firefly'@'localhost';
FLUSH PRIVILEGES;
EXIT;
ポリシーに合わせて強固なパスワードを指定します。
sudo cp -pi .env.example .env
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=firefly
DB_USERNAME=firefly
DB_PASSWORD=your_password
最低限、上記を指定します。パスワードはDB作成時のものです。
sudo -u www-data php artisan firefly-iii:upgrade-database
sudo -u www-data php artisan firefly-iii:correct-database
sudo -u www-data php artisan firefly-iii:report-integrity
sudo -u www-data php artisan passport:install
sudo mkdir /var/log/firefly
sudo chown -R www-data www-data /var/log/firefly
ls -ld /var/log/firefly
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/firefly-iii.conf
<VirtualHost *:80>
servername 【bank.example.com】
# ドメイン名を指定します
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTPアクセスを強制的にHTTPSにリダイレクトします
</VirtualHost>
<VirtualHost *:443>
ServerName 【bank.example.com】
# ドメイン名を指定します
CustomLog 【/var/log/firefly/firefly_access.log】 combined
ErrorLog 【/var/log/firefly/firefly_error.log】
DocumentRoot 【/home/www-data/firefly-iii/public】
# 自身の環境に合わせます
<Directory 【/home/www-data/firefly-iii/public】>
# 自身の環境に合わせます
AllowOverride All
Require all granted
</Directory>
#SSL設定
SSLEngine on
Protocols h2 http/1.1
# SSLを有効化します
SSLCertificateFile 【/etc/certs/bank.example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/bank.example.com.key】
# 秘密鍵を指定します
# SSLCACertificateFile 【/etc/certs/bank.example.com.crt】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します
#セキュリティヘッダー付与
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"
</VirtualHost>
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC6-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
__EOF__
sudo a2ensite firefly-iii.conf
sudo systemctl restart apache2
設定したURLにアクセスします。(ここではbank.example.com)
を設定して、「Register」をクリックします。
続いて初期設定(メインバンクや通貨、言語の指定など)完了後、ダッシュボードが出てくればインストール完了です。
ドメイン変更を伴うサーバのサイト移転を行いました。そこで、旧サーバのサイトのみの停止措置を行います。
データの移行が完全に済んでいることを確認します。
cd /etc/apache2/sites-enabled && pwd
ls -la
sites-le-ssl.conf
のように、Let's Encryptの自動更新を利用しているサイトにシンボリックリンクが張られていることを確認します。
コマンドによるサイト停止
sites-le-ssl.conf
ls -la
シンボリックリンクがないことを確認します。
cd /etc/apache2/sites-available/ && pwd
sudo mv sites-le-ssl.conf /path/to/backup/directory/sites-le-ssl.conf.$(date +%Y%m%d)
ls -la sites-le-ssl.conf
ファイルがないことを確認します。
ls -la /path/to/backup/directory/sites-le-ssl.conf.$(date +%Y%m%d)
ファイルがあることを確認します。
sudo apache2ctl configtest
Syntax OK
を確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active (running)
を確認します。
旧サイトにアクセスできないことを確認します。
sudo certbot delete --cert-name 無効化するドメイン
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Deleted all files relating to certificate ドメイン
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
のように、メッセージが出ればOKです。
Powered by WordPress & Theme by Anders Norén