2026年9月8日火曜日

動物の謝肉祭、お祭りや、クラシック音楽、その他、について、雑学や業界話を、交えながら解説して下さい😊

2026年9月7日月曜日

debian12.15で、最も、最新のphpと、依存関係とか、必要な、ものを、入れるには、?、

同じGNOMEデスクトップで、Debian13もFedora44もUIは、そっくりです、

hiroppy123@debian:~/schedule_manager$ php artisan optimize:clear Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.4.0". You are running 8.2.33. PHP Fatal error: Uncaught RuntimeException: Composer detected issues in your platform: Your Composer dep
pasted

debian12.15で、最も、最新のphpと、依存関係とか、必要な、ものを、入れるには、?、

Debian 12(bookworm)の公式リポジトリはPHP 8.2が最新で、PHP 8.4は含まれていません(Debian 13 trixieなら公式で8.4が入ります)。Debian 12でPHP 8.4を使うには、Ondřej Surý氏が管理するSury(deb.sury.org)リポジトリを追加する必要があります。SURYはDebianのPHPパッケージメンテナが管理していて、広く信頼されているリポジトリです。 Vultr

手順

  1. 必要なパッケージを準備
bash
sudo apt update
sudo apt install -y lsb-release ca-certificates apt-transport-https software-properties-common gnupg2 curl
  1. Sury GPGキーを追加
bash
curl -fsSL https://packages.sury.org/php/apt.gpg | sudo gpg --dearmor -o /usr/share/keyrings/sury-php.gpg
  1. リポジトリを追加
bash
echo "deb [signed-by=/usr/share/keyrings/sury-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/sury-php.list
  1. パッケージリストを更新して確認
bash
sudo apt update
apt policy php

packages.sury.org/php bookworm/main からPHP 8.4系が候補として出てくるはずです。

  1. PHP 8.4とスクリプトが必要とする拡張をインストール
bash
sudo apt install -y php8.4 php8.4-cli php8.4-common php8.4-mbstring php8.4-xml php8.4-curl php8.4-zip php8.4-bcmath php8.4-intl php8.4-mysql

(先ほどのapt installが失敗していたのはこのリポジトリが未追加だったためです)

  1. CLIのデフォルトを8.4に切り替え(複数バージョン共存時)
bash
sudo update-alternatives --set php /usr/bin/php8.4
php -v

mysql-serverについて

mysql-serverはDebian公式には無く(MariaDBが標準です)、代わりに以下のどちらかを使ってください:

bash
sudo apt install mariadb-server

または、Oracle公式のMySQL APTリポジトリを別途追加する必要があります。Laravelなら通常MariaDBで問題なく動きます。

Apache連携の再設定

PHP 8.2用のlibapache2-mod-php8.2が有効になっているので、8.4に切り替える場合はmod_phpではなくPHP-FPM運用が推奨です(Suryのmod_php8.4も存在しますが、FPMの方が今どきの構成です)。


この後 composer install を再実行すれば、platform_check.phpのエラーは解消するはずです。進め方(FPM+Apache連携の設定まで)も必要であれば教えてください。

いっそのこと、13にアップグレードは、出来ますか?それから、すべての手順を、

はい、Debian 12(bookworm)から13(trixie)へのアップグレードは公式にサポートされています。trixieは2025年8月9日に安定版としてリリース済みで、PHP 8.4が標準リポジトリに含まれるようになるので、Suryリポジトリを使わずにPHP 8.4を導入できます。ただしメジャーアップグレードなので、事前バックアップは必須です。

手順

1. 事前準備・バックアップ

bash
# 念のためユーザーで実行(rootでも可)
sudo su
cd /home/hiroppy123/schedule_manager

# アプリのバックアップ(DBとコードごと)
tar czf /root/schedule_manager_backup_$(date +%F).tar.gz /home/hiroppy123/schedule_manager
mysqldump -u root -p --all-databases > /root/all_databases_backup_$(date +%F).sql

仮想マシンなら、可能ならスナップショットも取っておいてください。

2. 現在のシステムを完全に最新化

bash
apt update
apt upgrade -y
apt full-upgrade -y
apt autoremove -y

ここで保留パッケージがないか確認してから進めます。

3. ディスク容量の確認

/bootに十分な空き(目安1GB以上)、ルートに5GB以上の空きがあることを確認してください。

bash
df -h

4. sources.list を bookworm → trixie に書き換え

bash
# ファイルの中身を確認
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

/etc/apt/sources.list(または.sources形式のDEB822ファイル)内のbookwormをすべてtrixieに置換します。

bash
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
# sources.list.d 配下に別ファイルがあれば同様に置換
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list 2>/dev/null
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.sources 2>/dev/null

先ほど追加したSuryリポジトリ(sury-php.list)は、trixieでは不要になるので無効化・削除しておいてください(trixie標準でPHP8.4が入るため、Suryが残っていると競合の可能性があります)。

bash
rm -f /etc/apt/sources.list.d/sury-php.list

5. パッケージ一覧の更新

bash
apt update

ここでエラーが出ないか確認してください。

6. 最小限のアップグレード(依存関係の衝突回避)

bash
apt upgrade --without-new-pkgs -y

「保留されました」というパッケージが出ても、この段階では正常です。

7. 本アップグレード

bash
apt full-upgrade -y

途中で設定ファイルの差分(.dpkg-distなど)について聞かれることがあります。基本的にはメンテナ版を維持するか、自分の変更を残すか確認しながら進めてください(Apache/MySQL/PHP関連の設定は特に注意)。

8. 不要パッケージの削除と再起動

bash
apt autoremove -y
apt autoclean
reboot

9. 再起動後の確認

bash
cat /etc/debian_version    # 13.x になっているはず
php -v                     # 標準でPHP 8.4系になっているはず
lsb_release -a

10. アプリ側の再セットアップ

bash
cd /home/hiroppy123/schedule_manager
php -v
composer install
php artisan optimize:clear

MySQLについては、公式リポジトリにもmariadb-serverはあるはずなので:

bash
apt install mariadb-server

注意点

  • RabbitMQを使っている場合はbookworm→trixieの直接アップグレードに対応していないので、事前に別対応が必要です。 Debian
  • MariaDBのメジャーバージョンアップグレードは、クリーンシャットダウン後でないと確実に動作しないことがあります。 Debian
  • リモート(SSH)でアップグレードしている場合、接続が切れることがあるので、tmuxscreenの中で作業することを強く推奨します。 LinuxConfig

進めてみて、途中でエラーが出たら貼ってください。一緒に見ていきます。

今のブラウザでの状況を教えてください——例えば「真っ白なページが出る」「エラーメッセージが出る」「そもそもURLにアクセスできない」など、実際に何が起きているかで対応が変わります。

ローカルのWordPress環境は今どんな状態ですか?先程の、phpコードが、そのまま、ひょうじされ、つまり、アパッチや、PHPの設定が、必要ですか?、

その症状は典型的な「PHPが実行されずソースコードがそのまま出力されている」状態です。原因はだいたい以下のどれかです。

まず教えてください

  1. どうやってアクセスしましたか?
  • ブラウザのアドレスバーに file:///home/.../wp-login.php のように直接パスを入力した → これが原因です(PHPはWebサーバー経由でないと実行されません)
  • http://localhost/...http://IPアドレス/... でアクセスした → サーバー側の設定問題です
  1. Webサーバー(Apache)は起動していますか?
bash
systemctl status apache2
  1. PHPモジュールはApacheに読み込まれていますか?
bash
apache2ctl -M | grep php

何も出なければ、これが直接の原因です。


想定される原因と対処

ケースA: file://で直接開いている

ブラウザURLバーがfile://から始まっている場合、必ずhttp://localhost/...のようにApache経由でアクセスし直してください。

ケースB: mod_phpが有効になっていない

今回Debian 13にアップグレードした際、PHPが8.2→8.4に上がったので、Apacheに紐づくlibapache2-mod-phpが更新後もPHP8.4用に正しく設定されていない可能性が高いです。

bash
# 現在有効なPHPモジュールを確認
apache2ctl -M | grep php

# PHP8.4のApacheモジュールをインストール
sudo apt install libapache2-mod-php8.4

# 有効化して再起動
sudo a2enmod php8.4
sudo systemctl restart apache2

ケースC: WordPressをファイルとしてどこに置いているか

bash
# ドキュメントルート配下にwp-login.phpを含むWordPress一式があるか確認
ls /var/www/html/
cat /etc/apache2/sites-enabled/000-default.conf | grep DocumentRoot

WordPress本体が正しいドキュメントルートに置かれていないと、Apache経由でも見つけられません。


まずは systemctl status apache2apache2ctl -M | grep php の結果、そしてブラウザのアドレスバーに実際に何と入力しているか教えてもらえますか?それで原因を絞り込みます。

【医師解説】老化も病気も左右する「ミトコンドリア」の新しい概念とは - - YouTube動画の解説

npm監査対応(Nodejsブログアプリ)

いいですね、ここまで原因の切り分けができていれば、あとは実装に落とし込むだけです。調査結果を踏まえて、app.js を実際に書き換えてみます。

結論(先に要点)

対象 現状 置き換え先 理由
csurf archived / cookie@0.4.0 csrf-sync 御社の構成は既に express-session を使っているので、ステートレスな csrf-csrf より Synchronizer Token Patterncsrf-sync の方が自然に収まる(csrf-csrf の公式ドキュメントも「セッションを使っているなら csrf-sync を使え」と明言)
connect-sqlite3 内部で古い sqlite3@5.1.7node-gyp@8.4.1tar@6.2.1 を抱える better-sqlite3 + better-sqlite3-session-store セッション専用DBだけ切り離して置き換えれば、脆弱な依存ツリーごと消せる。記事DB用の sqlite3@6.0.1 はそのまま触らなくてOK

ejsuuid のメジャーアップは今回の脆弱性とは無関係なので後回しでOKというのも、そのままで合っています。

実際に書き換えます。

手順

1. パッケージの入れ替え

bash
npm uninstall csurf connect-sqlite3
npm install csrf-sync better-sqlite3 better-sqlite3-session-store

これで csurf が抱えていた cookie@0.4.0 と、connect-sqlite3 が抱えていた sqlite3@5.1.7 → node-gyp@8.4.1 → tar@6.2.1 の依存ツリーが両方消えます。記事DB用に使っている sqlite3@6.0.1 はそのまま残るので、db.all / db.get / db.run 系のコードは一切変更不要です。

2. app.js の変更点(上の添付ファイル済み)

  • セッションストア: connect-sqlite3better-sqlite3-session-store(better-sqlite3 はネイティブビルド周りがシンプルで、古い node-gyp/tar チェーンを引きずりません)
  • CSRF対策: csurfcsrf-sync(セッション前提の Synchronizer Token Pattern。req.csrfToken() はすべて generateToken(req) に置換済み)
  • EJS テンプレート側は _csrf という隠しフィールド名の慣習を csrf-sync も踏襲しているので変更不要です

3. 動作確認

bash
npm start

ログイン → 記事投稿 → 編集 → 削除の一連のフォームが通ること(CSRFトークンが正しく検証されること)と、再起動後もログインセッションが sessions.db に残っていることを確認してください。

4. 最終チェック

bash
npm audit
npm ls csurf connect-sqlite3   # → 何も出なければOK

これで9件の脆弱性のうち、少なくとも csurf/connect-sqlite3 経由のものは解消されるはずです。ejs(5→6)と uuid(13→14)のメジャーアップグレードは breaking changes を含む可能性があるので、今回とは別タスクとして落ち着いてから対応するのがおすすめです。

 
App
JS
hiroppy123@fedora:~/projectxpro029/pro-blog-app$ npm audit found 0 vulnerabilities hiroppy123@fedora:~/projectxpro029/pro-blog-app$ npm ls csurf connect-sqlite3 pro-blog-app@1.0.0 /home/hiroppy123/projectxpro029/pro-blog-app └── (empty) hiroppy123@fedora:~/projectxpro029/pro-blog-app$ node app.js 1
pasted

Good news: npm audit は 0 件になりました 🎉 これで csurf / connect-sqlite3 経由の脆弱性は解消です。

今出ているエラーは全く別の問題です。

原因

Error: Could not locate the bindings file...
.../sqlite3/compiled/24.20.0/linux/x64/node_sqlite3.node

これは Node.js v24.20.0 がとても新しくsqlite3(記事DB用に使っている非同期ドライバ、v6.0.1)がその Node バージョン向けのビルド済みバイナリ(prebuilt binary)をまだ用意していない、という意味です。sqlite3 はネイティブアドオン(C++)なので、Node の ABI バージョンごとに専用バイナリが必要です。今回の csurf/connect-sqlite3 の入れ替え作業で npm install が走った際に依存関係が再解決され、この不整合が表面化したと考えられます(直接の原因ではなく、たまたま今気づいた形です)。

対処法

方法A: ソースからビルドし直す(その場しのぎ)

bash
# Fedora の場合、ビルドツールが必要
sudo dnf install -y make gcc-c++ python3

npm rebuild sqlite3 --build-from-source

これで手元の環境用にコンパイルされます。ただし Node をまたバージョンアップすると同じ問題が再発します。

方法B: Node のバージョンを prebuilt が存在するものに合わせる(安定運用向け)

v24.20.0 は最新すぎるため、LTS版(v22系など)に落とすのが手堅いです。

bash
nvm install 22
nvm use 22
npm rebuild sqlite3

方法C: 記事DBも better-sqlite3 に統一する(根本対策・おすすめ)

セッションストアで既に better-sqlite3 を導入しましたが、これは N-API ベースで ABI 安定性が高く、新しい Node バージョンでも prebuilt バイナリが出やすい設計です。sqlite3(コールバック形式)と better-sqlite3(同期形式)は API が違うため、db.all(...) / db.get(...) / db.run(...) を書き換える必要がありますが、今後 Node を上げるたびにこの手のエラーに悩まされなくなります。

まずは方法A方法Bで今すぐ動く状態に戻すのが早いです。方法Cは規模の大きい変更になるので、時間があるときに別タスクとして着手するのがよいと思います。どちらを試しますか?

良いものを見つけました。この style_css.unused02 は、これまで見た他の版とほぼ同じ内容(空白の詰め方が違うだけ)ですが、1点だけ実質的に重要な違いがあります。

重要な発見:ヘッダー装飾画像の参照先が違う

ファイル 該当プロパティ 参照パス
現在使用中の public/css/style.css header > p:after url('/images/wanko.svg')存在しないファイル(404)
header.admin > p:after url("/img/wanko_admin.svg")存在しないファイル(404)
今回の style_css.unused02 header > p:after url('/images/top.svg')public/images/top.svg は実在します
header.admin > p:after url("/img/top.svg") /img/フォルダの存在は要確認

つまり、**この unused02 は「壊れた wanko.svg 参照を、実在する top.svg に差し替えた版」**である可能性が高いです。以前の ls public/images の結果に top.svg(18,469バイト)がちゃんと存在していたのを覚えていますか?これを使えば、あの404を画像の追加なしに解消できます。

差分は他は全てインデント・改行スタイルの違いだけで、実質的な内容(色・レイアウト)は現在推奨している版と同じです。

提案:この修正を採用する

public/img/top.svg が存在するかだけ確認してください。

bash
ls public/img 2>/dev/null || echo "public/img フォルダは存在しません"

もし public/img フォルダ自体が無ければ、admin用も /images/top.svg に統一するのが安全です。反映しておきます。

まとめ

style_css.unused02 は機能・配色面では既存の推奨版と同じでしたが、壊れた画像参照(wanko.svg)を実在する top.svg に差し替えていたヒントを含んでいました。それを反映し、今回の最終版では:

  1. 配色を落ち着いたブランドカラー(青緑系)に統一
  2. header > p:afterheader.admin > p:after の背景装飾画像を、存在しない wanko.svg/wanko_admin.svg から、実在する /images/top.svg に変更

これで 404画像エラーも解消されるはずです。

反映方法

bash
cp style.css public/css/style.css
node app.js 127.0.0.1 3000

ブラウザで Ctrl+Shift+R して、ヘッダー右下の装飾画像が404にならず表示されるか確認してください。念のため ls public/img を実行して /img/ フォルダの中身も確認しておくと安心です(もし違う画像が入っていれば、admin用だけそちらに差し替えることもできます)。