1ヶ月以上にわたり、作業をサボっていた万年筆のインク補充。
ようやく終わりと思ったら、補充しようとしていた万年筆のインク切れ。インクそのものも終売となっていたので
万年筆を洗浄して乾燥。コンバータは捨てます。
そうして、インクも換装。
こうして、コンバータ経由でインクの交換を手早く行えるのが利点です。
カテゴリー: ガジェット Page 2 of 88
Ubuntu24.04環境でBookStackをアップグレードしたときの手順メモです。
環境
- BookStack v24.10
- 25.02にアップグレード
- Ubuntu 24.04
- Apache 2.4系
- PHP 8.3
- MySQL 8系
さっくりとした手順
https://manualmaton.com/2023/12/15
以前に実施した、こちらの記事の通りに行いました。
- DBのバックアップを行います。
- 推奨:システム全体のバックアップ
- git pullとアップグレードを行います。
- キャッシュをクリアします。
- Webサービス再起動を行います。
- アップグレード確認と動作確認を行います。
手順
システム全体のバックアップ（推奨）
万一に備え、システム全体のバックアップを取ることを推奨します。AWSや仮想サーバ等の場合は、インスタンスをまるごとバックアップしておくと良いでしょう。
mysqldumpによるDBバックアップ
- 保存ディレクトリに移動
cd /hoge任意のバックアップディレクトリを指定します。
mysqldump -h localhost -u bookstack -p --no-tablespaces --single-transaction bookstack > bookstack_backup.$(date +%Y%m%d).sqlDB名やDBユーザは自分の環境に合わせます。
- バックアップ確認
less bookstack_backup.$(date +%Y%m%d).sql平文で読めることを確認します。
git pullとアップグレード
- BookStackのディレクトリに移動
cd /var/lib/BookStack/ && pwdインストールされているディレクトリを指定します
- git pull
sudo -u www-data git pull origin release実行例(一部抜粋)
remote: Enumerating objects: 6028, done.
remote: Counting objects: 100% (1295/1295), done.
remote: Compressing objects: 100% (47/47), done.
remote: Total 6028 (delta 1263), reused 1248 (delta 1248), pack-reused 4733 (from 3)
Receiving objects: 100% (6028/6028), 5.75 MiB | 18.75 MiB/s, done.
Resolving deltas: 100% (3708/3708), completed with 405 local objects.
From https://github.com/BookStackApp/BookStack
* branch release -> FETCH_HEAD
b0dda6e6a..268e35343 release -> origin/release
Updating b0dda6e6a..268e35343
Fast-forward
.env.example.complete | 5 +
.github/translators.txt | 40 +-
.github/workflows/analyse-php.yml | 4 +-
.github/workflows/lint-js.yml | 4 +-
.github/workflows/lint-php.yml | 6 +-
.github/workflows/test-js.yml | 29 +
.github/workflows/test-migrations.yml | 6 +-
.github/workflows/test-php.yml | 6 +-
.gitignore | 1 +
LICENSE | 2 +-
app/Access/ExternalBaseUserProvider.php | 49 +-
app/Access/Ldap.php | 8 +-composer install
sudo -u www-data composer install --no-dev- 実行例(一部抜粋)
> @php -r "!file_exists('bootstrap/cache/services.php') || @unlink('bootstrap/cache/services.php');"
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Package operations: 5 installs, 70 updates, 8 removals
- Downloading bacon/bacon-qr-code (v3.0.1)
- Downloading dompdf/php-svg-lib (1.0.0)
- Downloading dompdf/php-font-lib (1.0.1)
- Downloading dompdf/dompdf (v3.1.0)
- Downloading symfony/deprecation-contracts (v3.5.1)
- Downloading symfony/http-foundation (v7.2.3)
- Downloading guzzlehttp/uri-template (v1.0.4)
- Downloading intervention/gif (4.2.1)
- Downloading intervention/image (3.11.1)
- Downloading symfony/process (v7.2.0)
- Downloading knplabs/knp-snappy (v1.5.1)
- Downloading symfony/string (v7.2.0)
- Downloading symfony/service-contracts (v3.5.1)
- Downloading symfony/console (v7.2.1)
- Downloading laravel/prompts (v0.3.5)
- Downloading laravel/serializable-closure (v2.0.3)
- Downloading paragonie/constant_time_encoding (v3.0.0)
- Downloading phpseclib/phpseclib (3.0.43)
- Downloading league/oauth1-client (v1.11.0)
- Downloading voku/portable-ascii (2.0.3)
- Downloading symfony/css-selector (v7.2.0)
- Downloading tijsverkoyen/css-to-inline-styles (v2.3.0)
- Downloading symfony/var-dumper (v7.2.3)
- Downloading symfony/uid (v7.2.0)
- Downloading symfony/routing (v7.2.3)
- Downloading symfony/mime (v7.2.3)
- Downloading symfony/event-dispatcher-contracts (v3.5.1)
- Downloading symfony/event-dispatcher (v7.2.0)- DBマイグレート
sudo -u www-data php artisan migrate※この時、Are you sure you want to run this command?というプロンプトには「Yes」が見えるようにカーソルを移動してEnterします。そのままEnterするとキャンセルされ、全体のアップグレードが行われません。
アップグレード後のキャッシュクリアを行います。
- キャッシュクリア
sudo -u www-data php artisan cache:clearsudo -u www-data php artisan config:clearsudo -u www-data php artisan view:clear上記、それぞれ、successfully.で終わることを確認します。
Webサービス(apache)再起動
- apache再起動前確認
systemctl status apache2.serviceactive(running)を確認します
- apache再開
sudo systemctl restart apache2.service && echo $?0を確認します。
- apache再起動後確認
systemctl status apache2.serviceactive(runnning)を確認します
バージョンアップ確認
- BookStackがインストールされているURLにアクセスします。
- 管理者権限でログインします。
- 設定に進みシステムバージョンが作業時の最新版になっていることを確認します。
- ページの作成や編集が正常に行えることを確認します。
バージョンアップ後の作業(dumpファイル削除)
※SQLファイルが平文で読めるのは非常に危険な状態なので、作業を確認次第、早急に実施します※
- 保存ディレクトリに移動
cd /hogeDBバックアップを行ったディレクトリに移動します。
- ファイル削除
shred -u bookstack_backup.$(date +%Y%m%d).sql- ファイル削除確認
ls -l bookstack_backup.$(date +%Y%m%d).sqlファイルがないことを確認します。
Jetpackの代わりとして運用しているWeb解析、Matomo。更新もあまり手間を必要とせず利用可能でした。
このように「新しいアップデート」ボタンが出てきますので
これを押した後に「自動アップデート」をクリック。
この成功の画面が出て、「Matomoを続ける」をクリック。
バージョンによってはDBのアップブレードを示唆されますので、
Matomoのアップグレードをクリック。
このDBのアップグレードも終われば完了。
概要
Growi v7.1.xをインストールしているのであれば、v7.2.0へのアップグレードはv7.1.xと同じ手順でアップグレードできました。
前提
- 既にgrowi v7.1.xをインストールしていること。
- 管理画面トップやトップページ右下からバージョンが7.1.xであることを再確認します。
- systemdによってサービス化されていること。
- 具体的な手順はhttps://barrel.reisalin.com/books/growi/page/ubuntu2404growi-v7v710-ImY
- 最新版や安定版がリリースされていることを以下のサイトで確認していること。
- https://github.com/weseek/growi/releases
- ※設定ファイルの変更やパッケージインストールの変更、nodeのバージョンアップの必要等があれば、それも事前に済ませます。
手順
さっくりとした手順
- Growiをメンテナンスモードにします。
- Growiのサービスを停止します。
- バックアップを取ります。
- gitコマンドで最新版をcheckoutします。
- アップグレードを行います。
- Growiのサービスを再開します。
- Growiのメンテナンスモードを解除します。
- アップグレードされたことを確認します。
メンテナンスモード有効化
- Growiに管理者権限でログインします。
- 管理トップ＞アプリ設定に進み、「メンテナンスモードを開始する」をクリックします。
- トップページに戻り「メンテナンスモード」が表示されていることを確認します。
バックアップ
以下をバックアップします。
- mongodbの格納データ
cat /etc/mongod.conf |grep dbPathとして、ここのディレクトリ一式を控えます。(筆者環境 /home/mongodb)
このディレクトリを任意の方法でバックアップします。
- Growiの添付ファイル一式が納められているディレクトリ（ファイルアップロード先をlocalにしている場合のみ)
/growi/root/directory/apps/app/public(筆者環境 /home/www-data/growi/apps/app/public)ここも念のためバックアップします。
※ 添付ファイルのアップロード先をAWSやAzureなどにしている場合は不要です
- vpsや仮想ゲストの場合はシステム全体：推奨
スナップショット機能などでシステム全体をバックアップした方が確実で安心です。
growiサービスを停止します
- growiのステータス確認(停止前)
systemctl status growi.service※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します
- growiのサービス停止
sudo systemctl stop growi.service- growiのステータス確認(停止後)
systemctl status growi.serviceinactive (dead)を確認します
growiディレクトリに移動します
cd /opt/growi自分の環境に合わせます。(筆者環境/home/www-data/growi)
リリースタグを確認します。
- リリースタグ取得
sudo git fetch --tags- リリースタグ確認
sudo git tag -lスペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。
チェックアウトとインストールを行います。
- 変更を一時的に退避
sudo git stash- チェックアウト
sudo git checkout 【バージョン】- pnpm install
sudo pnpm i- ビルド
sudo npm run app:buildgrowiサービスを起動します。
- 再開前のステータス確認
systemctl status growi.serviceinactive (dead)を確認します
- サービス再起動
sudo systemctl start growi.service※ 完全に起動していないと、アクセスしても503エラーが発生します。
- 再開後のステータス確認
systemctl status growi.service→ サービススクリプトを[growi]にしている場合
active (running)を確認します
メンテナンスモード無効化
- Growiに管理者権限でログインします。
- 管理トップ＞アプリ設定に進み、「メンテナンスモードを終了する」をクリックします。
- トップページに戻り「メンテナンスモード」が表示されていないことを確認します。
バージョンアップを確認します。
- 画面下部にあるバージョンがチェックアウトしたバージョン(v7.2.x)であることを確認します。
- 各種機能（ページ閲覧や編集）などが正常に行えるかを確認します。
バージョンアップ後の作業
必要に応じてバックアップしたファイル一式やスナップショットを削除します。
概要
企業内やコミュニティでNextcloudを運用する際のアカウント作成は割と簡単ですが、
{{thumbnail(clipboard-202503081731-br3pd.png, size=640)}}
このようにデフォルトのファイルがアカウントを作成するたびに増えていきます。
1アカウントにつき33MB程ではありますが、不要なファイルではあるので
- 「アカウント作成時にファイルを作らない」
- 「または特定のファイルやディレクトリを作る」
ように修正します。
環境
以下の環境で動作を確認。
- Ubuntu 22.04
- php 8.2
- Nextcloud 30.6
- Apache 2.4
- MySQL
さっくりとした手順
- サーバにコンソールログインします。
- Nextcloudのルートディレクトリに移動します。
- ディレクトリ情報を修正します。
- Nextcloud(Apache)を再起動します。
Nextcloudのルートディレクトリに移動
cd /path/to/nextcloud/root/directory/core/skeleton && pwd筆者環境/home/www-data/nextcloud/core/skeleton
ディレクトリ・ファイル情報修正
ここに、アカウント作成時に自動的に追加されるファイルが含まれています。
- 'Nextcloud intro.mp4'
- Photos
- 'Reasons to use Nextcloud.pdf'
- 'Templates credits.md'
等を消していきます。
例）
sudo rm 'Reasons to use Nextcloud.pdf'任意の方法でファイル(マニュアルなど)をこのディレクトリに入れることで、アカウント作成時にそのファイルが追加されます。その場合は
sudo chown www-data hogeとして、ファイルの所有者をapache(nextcloud)の実行者に変えます。
設定変更確認
- apache再起動
sudo systemctl restart apache2.service && echo $?0を確認します。
- apache再起動確認
systemctl status apache2.serviceactive(running)を確認します。
- アカウント作成確認
- Nextcloudで管理者権限でログインします。
- 任意のアカウントを作成します。
- 作成したアカウントでログインします。
- 「ファイル」に進み、削除したファイルやディレクトリがないことと追加したファイルがあることを確認すれば設定できています。
概要
Redmineサーバからリマインダーのメールが送信されない事象を解決したときのメモ書きです。
環境
- Ubuntu 24.04
- OpenSSL 3.3.3
- Redmine 5.1
- Apache 2.4
- MySQL 8.0.41
特記事項
サーバにはメール送信の機能を有しておらず、gmailのアプリ連携でメールを飛ばしています。
事象確認
- Redmine ルートディレクトリに移動
cd /path/to/redmine/root/directory && pwd筆者環境/home/www-data/redmine
- リマインダメールを送信
sudo -u www-data bundle exec rake redmine:send_reminders days=7 RAILS_ENV=productionリマインダメール送信されず。
そこで、production.logを確認したところ、メール送信時に以下のエラーログが出力されました：
ERROR -- : [ActiveJob] [ActionMailer::MailDeliveryJob] Email delivery error: SSL_connect returned=1 errno=0 peeraddr=xxx.xxx.xxx.xxx:587 state=error: certificate verify failed (unable to get local issuer certificate)どうやら、証明書回りのエラーのようです。
確認したこと（原因確認）
メール設定の再確認
まず、メール設定を再確認しました。RedmineでのSMTP設定は特に変更していないため、問題は設定に起因するものではないと判断しました。
OpenSSLの設定を再確認
そこで思い当たる節。
パッケージ管理システムからではなく、手動で OpenSSL を更新した影響で、証明書ストアのパスが /usr/bin/openssl から /usr/local/ssl に変更されていたことが原因だと分かりました。
/usr/local/ssl/bin/openssl version -d→ OPENSSLDIR: "/usr/local/ssl" を確認。
対処
CA証明書のコピー
新しい証明書ストア /usr/local/ssl にシステムの CA 証明書をコピーしました：
sudo cp /etc/ssl/certs/ca-certificates.crt /usr/local/ssl/cert.pemまた、証明書ディレクトリを作成し、必要な証明書を全てコピーしました：
- ディレクトリ作成
sudo mkdir -p /usr/local/ssl/certs- システム内の証明書ストア一式をコピー
sudo cp -r /etc/ssl/certs/* /usr/local/ssl/certs/- 証明書ストア一式を再暗号化
sudo /usr/local/ssl/bin/c_rehash /usr/local/ssl/certs/環境変数の設定
/etc/environmentに以下の内容を追記しました。
SSL_CERT_FILE=/usr/local/ssl/cert.pem
SSL_CERT_DIR=/usr/local/ssl/certs- 設定後の反映
sudo source /etc/environmentRedmine(Apache)再起動
- apache再起動
sudo systemctl restart apache2.service ; echo $?0を確認
- apache再起動確認
systemctl status apache2.serviceactive(running)を確認
解決確認
- Redmine ルートディレクトリに移動
cd /path/to/redmine/root/directory && pwd筆者環境/home/www-data/redmine
- リマインダメールを送信
sudo -u www-data bundle exec rake redmine:send_reminders days=7 RAILS_ENV=production今度は正常に送信されることを確認しました。
まとめと教訓
Redmineからメールが送信できなかった問題は、手動で更新したOpenSSLの証明書ストアのパス設定が原因でした。
証明書ストアが適切に設定されていないと、SMTP 送信時に certificate verify failed エラーが発生。
証明書関連の問題が発生した場合、OPENSSLDIR を確認し、適切な CA 証明書が配置されているかチェックすることが重要。
また、証明書周りはシステム全体に影響を及ぼすため、確認が甘かったということも事実。これは、手動でOpenSSLをアップグレードする際にも、改めて手順を確認します。
薬を長期にわたって服用することになったので、何かいい持ち運びのグッズはないものかと100均にて発見。
- 山手線のポーチ
- コンテナのファスナーケース
- 路線図と切符のマスキングテープ
と、JRとの全面コラボ品です。
山手線のポーチは視認性も収納性もバッチリ。
このマスキングテープにしても使い勝手は高め。
メモにも使える形なので楽しみが増えました。
外部に公開している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のアップグレードを試みたところ、失敗。その記録と原因についてメモを残します。
環境
- 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にアップグレードを試みた
試した手順
- DBのバックアップを取得します。
- 最新版のパッケージをダウンロードして展開します。
- 利用中のfirefly-iiiを待避させます。
- 待避させたfirefly-iiiからファイル/ディレクトリをコピーします。
- アップグレードを行います。（失敗）
DBのバックアップ
- 作業ディレクトリに移動
cd /hoge && pwd任意の作業ディレクトリに移動します。
- DBバックアップ
mysqldump --no-tablespaces --single-transaction -u username -h localhost -p database_name > DB_Backup.$(date +%Y%m%d).sqlusename、database_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- 霧もろし確認
- アップデートを行ったfirefly-iiiサイトにブラウザでアクセスします。
- ログインできることを確認します。
- バージョンが上がっていることを確認します。
- 登録操作などができることを確認します。
失敗の要因
これは明白にして単純です。
リリースノートを確認していなかった
に尽きます。LAMP環境で動くからこそ、ミドルウェアのバージョン(この場合はPHP)の必要とするバージョンを確認していなかった自分の落ち度です。
v6.2.0のリリースノートに
Firefly III requires PHP 8.4.
と書かれていることを見落としていました。
切り戻しが迅速だった要因
「切り戻しを前提としていた手順」に助けられました。
- 作業前にDBのバックアップ
- 動いていた環境を退避
させる二段構えにより、迅速な切り戻しが可能になりました。
結局のところ、
「自分の確認不足」から来るミスを「自分の確認不足を想定した手順」でカバーした形です。
概要
- 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-expensiveto 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サーバの全体的な変更を伴います。作業は慎重に、可能な限り検証環境で試してからの反映を強く推奨します。
ややさっくりしない手順
- Nextcloudのメンテナンスモードを有効化します。
- Nextcloudで用いているDBのバックアップを取ります。
- PHP8.2をインストールします。
- PHP8.2の設定を行います。
- PHP8.1の無効化とPHP8.2の有効化を行います。
- 警告に対する対処を行います。
- Nextcloudのメンテナンスモードを無効化します。
- 復旧を確認します。
メンテナンスモードを有効化
- 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).sqlDB名やユーザーは自分の環境に合わせます。
- 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.dcat <<- __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.inimemory_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.serviceNextcloudの警告解消
- 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復旧確認
- 設定を行ったNextcloudにアクセスします。
- メンテナンスモードが解除されていることを確認します。
- 管理者権限でアクセスし、管理者設定から上記のエラーやワーニングがないことを確認します。
備考：切り戻し
何か不具合があった場合の切り戻し手順です。上記、メンテナンスモードを有効化してから行ってください。
- 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ファイルが無いことを確認します。