RockyLinux9.7で「WordPress環境構築「Vol-03」PHP8.4、MariaDB11.4

RockyLinux9.7のインストール記事です。 なるべくコピペで設定きるようにまとめています PHP、MariaDB、第三弾。つづく・・・

www.kazuban.com

2026.05.01

本サーバーのほうは、WordPress本体しか更新していませんでした。
WordPress のサイトヘルスで更新の改善のメッセージがでていました。
サイトヘルスは「ダッシュボード　➡　ツール　➡　サイトヘルス」で確認できます
私の環境では、ステータスとしては「良好」ではありますがおすすめの改善が４件ありました
その中でも、「PHPのバージョン」「データベースのバージョン」は改善したほうがよさそうです

2026/09/11
下記設定で正常に、PHP8.４、Mariadb10.11 に更新できましたが
後日サーバー機の更新「sudo dnf update」で一部のパッケージが更新できない！
というエラーがでました。
AIに相談し、下記記事で改善できました

WordPress 必須条件（2026.08時点）

2026.08時点では、「PHP 8.3以上」「MariaDB 10.11以上」が必須条件になっています

必須要件

Requirements To run WordPress, it’s recommended your host supports: That’s really it. Apache or Nginx is recom

ja.wordpress.org

私の環境では、「サイトヘルス」➡「情報」で確認すると「PHP 8.2」「MariaDB 10.5」です

PHPバージョンの更新

現バージョンの確認

php --version

（事前に）バックアップを取る

必須ではありませんが、wp-config.php, DB, ファイル一式のバックアップが推奨されます
wp-config.phpは「cp」コマンドで簡単にコピーできます
DB や WordPressのファイル一式は、こちらでも紹介しているスクリプトでも取る事ができます

WordPress の「バックアップ・リストア」BASHスクリプト。crontab で自動バックアップ

RockyLinux9.7でバックアップサーバーを新しくしたので、バックアップ＆復元スクリプトも書き直してみました。 せっかくなので、最新のBASH構文をAIに聞きながらですが、本当すごいなAIは・・ デバッグ方法も教えてもらいました。 コードは、コピペで利用できるように投稿しています。

www.kazuban.com

2026.06.07

Remiリポジトリ追加

AppStreamの、8.3を利用する場合やすでにRemiリポジトリが設定されている場合には不要ですが
より新しいPHPバージョンにアップデートした場合には、追加しておきます
今回筆者は、8.4に更新しようと思っているので、Remiリポジトリを追加します

## Rocky Linux 9の場合
sudo dnf install -y epel-release
sudo dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm

モジュールリスト確認

dnf module list php

もし、404などのエラーが出てしまう場合には、一度キャッシュをクリアして再確認します

sudo rm -f /etc/dnf/vars/releasever
sudo dnf clean all && sudo dnf makecache
dnf module list php

Rocky Linux 9 - AppStream
Name       Stream            Profiles                        Summary                                
php        8.1               common [d], devel, minimal      PHP scripting language                 
php        8.2               common [d], devel, minimal      PHP scripting language                 
php        8.3               common [d], devel, minimal      PHP scripting language                 

Remi's Modular repository for Enterprise Linux 9 - x86_64
Name       Stream            Profiles                        Summary                                
php        remi-7.4          common [d], devel, minimal      PHP scripting language                 
php        remi-8.0          common [d], devel, minimal      PHP scripting language                 
php        remi-8.1          common [d], devel, minimal      PHP scripting language                 
php        remi-8.2          common [d], devel, minimal      PHP scripting language                 
php        remi-8.3          common [d], devel, minimal      PHP scripting language                 
php        remi-8.4          common [d], devel, minimal      PHP scripting language                 
php        remi-8.5          common [d], devel, minimal      PHP scripting language 

PHPモジュールのリセット

sudo dnf module reset php -y

新しいPHPバージョンの有効化（例: 8.4）

sudo dnf module enable php:remi-8.4 -y

新規インストールの場合

sudo dnf install php php-fpm -y

新規インストールで拡張機能追加（よく使うパッケージ一式）

sudo dnf install -y \
  php-mysqlnd \
  php-curl \
  php-exif \
  php-fileinfo \
  php-gd \
  php-imagick \
  php-intl \
  php-mbstring \
  php-xml \
  php-zip

アップグレードの場合

sudo dnf update php\* -y

更新の確認

php -v

再起動

sudo systemctl restart httpd
sudo systemctl restart php-fpm

更新の確認

これで更新されたと思います
対象のWordPressへログインし、「サイトヘルス」で確認してください。

MariaDBバージョンの更新

現バージョンの確認

mariadb --version

（事前に）バックアップを取る

sudo mysqldump -u root -p --all-databases > /path/to/backup_$(date +%Y%m%d).sql

PHP更新の項目でも紹介したこちらスクリプトでもバックアップは可能です

モジュールリスト確認

dnf module list mariadb

$ dnf module list mariadb
メタデータの期限切れの最終確認: 1:19:24 前の 2026年08月03日 10時24分16秒 に実施しました。
Rocky Linux 9 - AppStream
Name         Stream      Profiles                         Summary                       
mariadb      10.11       client, galera, server [d]       MariaDB Module                            
mariadb      11.8        client, galera, server [d]       MariaDB Module                            

MariaDB停止

sudo systemctl stop mariadb

キャッシュのクリアとmariadbモジュールのリセット

sudo dnf clean all
sudo dnf module reset mariadb -y

新しいモジュール（10.11）へ切り替え

sudo dnf module switch-to mariadb:10.11 -y
sudo dnf update mariadb-server mariadb -y ##念のためパッケージ更新も明示
mariadb --version ##10.11になっているか確認

設定ファイル「/etc/my.cnf.d/mariadb-server.cnf」 更新

設定ファイルのセッション名にバージョン番号（mariadb-10.5など）が含まれている場合があります
その項目下になにもない場合は、特に編集の必要はありませんが、今後追加の予定などある場合には
バージョンに合わせたセッション名に書き換えておいたほうが無難です

cd /etc/my.cnf.d/
sudo vi ./mariadb-server.cnf

・
・
# This group is only read by MariaDB-10.5 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don't understand
#[mariadb-10.5]
# ↓ 変更　
[mariadb-10.11] 
・
・

MariaDB 起動

sudo systemctl start mariadb
sudo systemctl enable mariadb

DB 内部の更新

sudo mariadb-upgrade -u root -p「DB管理者パスワード」

Apache＆PHP-FPM　再起動

sudo systemctl restart php-fpm
sudo systemctl restart httpd

更新の確認

対象のWordPressへログインし、「サイトヘルス」で確認します

筆者の環境では、トラブルなく更新できました。

トラブル時、mariaDB 事前バックアップからリストアする方法

基本のリストアコマンド

sudo mariadb -u root -p < /path/to/backup_20260803.sql

リストア時の注意点

MariaDBが起動している必要があります

sudo systemctl status mariadb  ##起動確認
sudo systemctl start mariadb   ##停止していたら起動

アップグレード失敗などで「元の10.5環境に戻す」場合

sudo dnf module switch-to mariadb:10.5 -y
sudo dnf update mariadb-server mariadb -y ##念のためパッケージ更新も明示
mariadb --version ##10.5になっているか確認

既存データとの重複に注意

--all-databases のダンプには CREATE DATABASE 文が含まれているため、同名DBが既に存在する場合は上書きされます。もし「クリーンな状態に戻したい」なら、リストア前に対象DBを削除しておくと安全です。

##例：wordpress用DBを削除してからリストアする場合
sudo mariadb -u root -p -e "DROP DATABASE wordpress;"
sudo mariadb -u root -p < /path/to/backup_20260803.sql

リストア後の確認

sudo mariadb -u root -p -e "SHOW DATABASES;"

後日の、dnf update でエラーがでました

後日、サーバーの「dnf update」でエラーがでました
一部のパッケージが更新できない！というエラーです

• エラー:
  問題 1: package gd3php-2.3.3-9.el9.remi.x86_64 from @System requires libavif.so.15()(64bit), but none of the providers can be installed
• cannot install both libavif-1.1.1-2.el9.next.x86_64 from epel-next and libavif-0.11.1-5.el9.x86_64 from @System
• cannot install both libavif-1.1.1-2.el9.next.x86_64 from epel-next and libavif-0.11.1-5.el9.x86_64 from epel
• パッケージの最良アップデート候補をインストールできません libavif-0.11.1-5.el9.x86_64
• パッケージの最良アップデート候補をインストールできません gd3php-2.3.3-9.el9.remi.x86_64
• nothing provides libdav1d.so.6()(64bit) needed by libavif-0.11.1-0.x86_64 from remi-safe
  問題 2: package php-gd-8.4.25-1.module_php.8.4.el9.remi.x86_64 from @System requires libgd.so.103()(64bit), but none of the providers can be installed
• package gd3php-2.3.3-9.el9.remi.x86_64 from @System requires libavif.so.15()(64bit), but none of the providers can be installed
• package gd3php-2.3.3-9.el9.remi.x86_64 from remi-safe requires libavif.so.15()(64bit), but none of the providers can be installed
• package gd3php-2.3.3-8.el9.remi.x86_64 from remi-safe requires libavif.so.14()(64bit), but none of the providers can be installed
• package libavif-0.11.1-5.el9.x86_64 from @System requires libSvtAv1Enc.so.0()(64bit), but none of the providers can be installed
• package libavif-0.11.1-5.el9.x86_64 from epel requires libSvtAv1Enc.so.0()(64bit), but none of the providers can be installed
• package libavif0.10-0.10.1-2.el9.x86_64 from epel requires libSvtAv1Enc.so.0()(64bit), but none of the providers can be installed
• cannot install both svt-av1-libs-2.3.0-2.el9.next.x86_64 from epel-next and svt-av1-libs-0.9.0-1.el9.x86_64 from @System
• cannot install both svt-av1-libs-2.3.0-2.el9.next.x86_64 from epel-next and svt-av1-libs-0.9.0-1.el9.x86_64 from epel
• パッケージの最良アップデート候補をインストールできません svt-av1-libs-0.9.0-1.el9.x86_64
• パッケージの最良アップデート候補をインストールできません php-gd-8.4.25-1.module_php.8.4.el9.remi.x86_64
• nothing provides libdav1d.so.6()(64bit) needed by libavif-0.11.1-0.x86_64 from remi-safe
  (競合するパッケージを置き換えるには、コマンドラインに ‘–allowerasing’ を追加してみてください
  または、’–skip-broken’ を追加して、インストール不可のパッケージをスキップしてください
  または、’–nobest’ を追加して、最適候補のパッケージのみを使用し
  ないでください)

警告メッセージに、スキップする助言があったので、一つづつやってみます

sudo dnf update --allowerasing

sudo dnf update --skip-broken

sudo dnf update --nobest

どのオプションがいいのかわかりませんが、私の環境では、最後のオプションで、先へ進み
更新できないパッケージ以外はupdate はできましたが、
これでいいのかな？ -> AIさん教えて！

結論から言うと、そのままにしておくのは良くありません。システムが壊れているわけではありませんが、一部のパッケージ（gd3php や php-gd）の更新がスキップされており、今後セキュリティアップデートなどを受け取れなくなる危険性があります。

原因

epel-next リポジトリが有効化されていることが原因です。

• EPEL-Next は、CentOS Stream（次期RHEL）向けの先行テストリポジトリです。
• Rocky Linux（安定版RHELクローン）でこれを有効にすると、epel-next から入ってきた新しすぎるパッケージ（libavif-1.1.1 や svt-av1-libs-2.3.0）が、通常の epel や remi リポジトリのパッケージと競合を起こしてしまいます。

対処手順

1.epel-next の無効化と CRB の有効化:競合の原因を無効化。
競合の元になっている epel-next を無効にし、Remiに必要な crb リポジトリを有効化します。

sudo dnf config-manager --set-disabled epel-next
sudo dnf config-manager --set-enabled crb

確認方法: dnf repolist を実行し、crb があり epel-next がないことを確認します。

dnf repolist

2.PHP 8.4 モジュールの指定:PHP 8.4 へのリセット。
PHP 8.4 モジュールを明示的に有効化し直します。
確認方法: dnf module list php を実行し、remi-8.4 の項目に [e] が付いていることを確認します。

dnf module list php

3.キャッシュクリアと同期（distro-sync）:バージョン調整。
キャッシュを破棄し、epel-next 由来の不整合パッケージを正規バージョンへダウングレード・同期させます。

sudo dnf clean all
sudo dnf distro-sync -y

4.確認:仕上げ
通常の dnf update を実行:
最後にオプションなしでシステム全体を更新します。

sudo dnf update

エラーやスキップの警告が出ずに「完了しました!」と表示されれば成功です。
作業完了後、php -v を実行して PHP 8.4.x と表示されることを確認してください。

php -v

PHP 8.4 で gd モジュールが正常に読み込まれているか確認

php -m | grep -i gd

実行してターミナルに gd と表示されれば、モジュールは正常に読み込まれています。
さらに、JPEGやPNG、WebP、AVIFなどの画像フォーマットが有効になっているか詳しく確認したい場合は、次のコマンドを実行してください。

php -r "print_r(gd_info());"

Array
(
    [GD Version] => 2.3.3
    [FreeType Support] => 1
    [FreeType Linkage] => with freetype
    [GIF Read Support] => 1
    [GIF Create Support] => 1
    [JPEG Support] => 1
    [PNG Support] => 1
    [WBMP Support] => 1
    [XPM Support] => 1
    [XBM Support] => 1
    [WebP Support] => 1
    [BMP Support] => 1
    [AVIF Support] => 1
    [TGA Read Support] => 1
    [JIS-mapped Japanese Font Support] =>
)

AIさん、おかげで、正常になりました

RockyLinux9.３で自宅サーバーを再構築V07・WordPress のバックアップとリストア

引越しするには、旧環境のデータをバックアップし、新環境へリストアします。 WordPress のバックアップとリストアの方法を説明し、自動バックアップするスクリプトを作成します。 バックアップ・リストアができると、引越しだけでなく、トラブル時にも以前の状態まで戻せます。

www.kazuban.com

2024.01.08

新しいBASH

前回のスクリプトは、2020年に紹介したコマンド操作をネット情報を参考にスクリプト化しましたが、今回はこのスクリプトをAIに投げて、最新のBASH構文への変換を教えてもらいながら作成しました。
投稿のスクリプト類はちょっと長くなりましたが、全てコピペできるようにしました。
また、開発途中ではBASHで一行づつのデバッグもやってみました。

デバッグ

編集はVSCodeを利用したので、デバッグプラグインもインストールしてみましたが、あまり思ったように動いてくれませんでした。
AIに聞いてみると、BASH自体にも、構文チェックやステップデバッグができる機能があるようです

shellcheck

shellcheck [スクリプト名.sh]のようにコマンド実行するだけで、スクリプトのバグや構文エラーを簡単にチェックできます。
パッケージ名は、キャメルケース的書き方「ShellCheck」になるので注意が必要です

sudo dnf install ShellCheck

もしパッケージが見つからない場合には、EPELリポジトリが有効になっていない可能性があるのでEPELを有効化した上で再度インストール

sudo dnf install epel-release
sudo dnf install ShellCheck

shellcheck は、スクリプトのバグや構文エラーを検出してエラーコードと共に表示してくれます。
標準では致命的でない場合でも警告を出してくるのでちょっとうるさく感じる事もありますが、
エラーコードをAIに聞くことでより安全なコードの書き方の学習にもなります

set コマンド

Bashの set コマンドは、シェルの動作やオプションを設定・変更するためのコマンドです。
主にスクリプトの安全運転モードやデバッグのために、シェルの冒頭でオプションと組み合わせて使用されます
・set -euo pipefail
実務でよく使われる定番のオプション
これにより、スクリプト実行時のバグや予期せぬトラブルを大幅に減らせます

・set -x: デバッグ開始
実行されるコマンドや変数の展開結果をすべて画面（標準エラー出力）に表示

・set +x: デバッグ開始
実行トレース出力を停止

・trap ‘read -p “STEP> ” < /dev/tty’ DEBUG
実行中、すべてのコマンドを実行する直前で指定文字（STEP>）プロンプトで一時停止

・export PS4=’+ ${LINENO}: ‘
デバッグモード（set -x）で実行されるコマンドを表示する際、そのコマンドのスクリプトでの行番号を出力に含める設定

これらコードをスクリプト上部で実行しておくことで、シェルスクリプトのバグの原因特定が早くなります。
サンプルコードを書いてみました。

#!/bin/bash

set -euo pipefail
# --- debug mode: DEBUGGING=1 で有効 ---
DEBUGGING=1

if [[ $DEBUGGING == "1" ]]; then
  echo "Debug mode is 'true' !! "
  export PS4='+ ${LINENO}: '
  set -x
  trap 'read -p "STEP> " < /dev/tty' DEBUG
else
  echo "Debug mode is 'false' !! "
fi

# テスト用コード
echo "最初の処理"
x=10
y=20
result=$((x + y))
echo "結果は $result"

このコードを実行すると、デバッグの状況が体験できます

次に今回作成したWordPressのバックアップ＆リストアのスクリプトを紹介します
デバッグコードは、Header.sh に別スクリプトにして、呼び出す形式にしました。

スクリプト構成

WordPressのバックアップは、大きく分けて「ファイル（サーバー内のデータ）」と「データベース（MySQL/MariaDB）」の2つが必要になります。
前回スクリプトは、昔の経験とネット検索を参考に、自分で作成しましたが
今回は、BASHもかなり進化しているみたいなので、AIのサポートで最新の構文で書き直しました。
バックアップファイルやスクリプトの構成は
・「ユーザーホーム」内に、「Backup」ディレクトリを作成
・「Backup」内に、「WordPress」と「bin」ディレクトリを作成
・「WordPress」内にWordPress パッケージをインストールしたディレクトリ名（筆者環境では「blog」）を作成します
・「blog」内に、データベースとサーバー内データのバックアップを保存します
・「bin」内に実行スクリプトを保存します

.[ユーザーホームディレクトリ]
├── Backup #「バックアップデータを保存する」
│   ├── WordPress #「WordPerss関連データ」
│   │   └── blog #「blog内のバックアップデータ」
│   │       ├── 20260530-MariaDB.bak       # データベースバックアップ
│   │       ├── 20260530-Wp-content.tar.gz # WordPressコンテンツ
│   │       ├── mariadb_backup.log
│   │       └── wp_backup.log
│   ├── bin #「スクリプト」
│   │   ├── Header.sh                #「デバッグ用のスクリプト」
│   │   ├── MariaDB_Backup.sh        #「データベースのバックアップ」
│   │   ├── MariaDB_Restore.sh       #「データベースのリストア」
│   │   ├── Tidyup_backfile.sh       #「バックアップデータの整理」
│   │   ├── WordPress_Config_Data.sh #「バックアップ環境の設定」
│   │   ├── Wp-Backup.sh             #「バックアップ用メインスクリプト」
│   │   ├── Wp-Content_Backup.sh     #「WordPressデータのバックアップ」
│   │   ├── Wp-Content_Restore.sh    #「WordPressデータのリストア」
│   │   └── Wp-Restore.sh            #「リストア用メインスクリプト」

WordPress_Config_Data.sh : 変数設定

#!/bin/bash
#  WoredPressバックアップ設定ファイル
#    WordPress_Config_Data.sh    2026/05 by Kazuban
#------------------------------------
export USER="kazuban"
export USER_DIR="/home/${USER}"
export SUB_DIR="blog"
export DOCUMEN_ROOT="/home/www/html"
#----- MariaDB ----------------------
export MYSQL_ROOT_PASSWD="hogehoge_passwd"
export DATABASE="WpDb"
export MYSQL_USER="WpAdmin"
export MYSQL_USER_PASSWD="WpPasswd"
#----- WordPress --------------------
export WP_CONTENT_DIR="wp-content"
export WP_CONTENT_FILENAME="Wp-content"
export WP_CONTENT_PATH="/home/www/html/${SUB_DIR}/${WP_CONTENT_DIR}"
export WP_CONTENT_OWNER="apache:apache"

Wp-Backup.sh : データベース＆WordPressコンテンツのバックアップ

#!/bin/bash
#  WoredPress のバックアップ
#    データベース(Mysql)とサーバーデータ(wp-content)
#  Wp-Backup.sh    2026/05 by Kazuban
#------------------------------------
#--- debug mode, set "DEBUG=1". -----
export DEBUG=
#------------------------------------
export CALLER_SCRIPT="$0"
#export SCRIPT_DIR=$(dirname "$(realpath "$0")")
#shellscriptで警告でたので、AIに聞くとこの書き方が安全らしい
SCRIPT_DIR=$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")
export SCRIPT_DIR
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
source "${SCRIPT_DIR}/WordPress_Config_Data.sh"
export BACKUP_DIR="${USER_DIR}/Backup/WordPress/${SUB_DIR}"
#---- MariaDB -----------------------
export MYSQL_BACKUP_SCRIPT="${SCRIPT_DIR}/MariaDB_Backup.sh"
export MYSQL_LOG="${BACKUP_DIR}/mariadb_backup.log"
#---- WordPress ---------------------
#export BACKUP_SOURCE_DIR="${DOCUMEN_ROOT}/${SUB_DIR}/wp-content"
export WP_BACKUP_SCRIPT="${SCRIPT_DIR}/Wp-Content_Backup.sh"
export BACKUP_SOURCE_DIR="${DOCUMEN_ROOT}/${SUB_DIR}/${WP_CONTENT_DIR}"
export WP_LOG="${BACKUP_DIR}/wp_backup.log"
#------------------------------------
export TIDY_UP_SCRIPT="${SCRIPT_DIR}/Tidyup_backfile.sh"
export DAYS_AGO="5"
#-----　関数定義 -----------------------
user_dir=$(pwd)
echo $user_dir
# スクリプト終了時に実行させたい場合はここで再定義
cleanup() {
#  echo "Wp-Backup 終了処理"
  :
}
check_backup_dir(){
  #$BACKUP_DIRが存在しない場合には作成
  mkdir -p $BACKUP_DIR 
}
cmd_mariadb()   { check_backup_dir; $MYSQL_BACKUP_SCRIPT; }
cmd_wordpress() { check_backup_dir; $WP_BACKUP_SCRIPT; }
cmd_all()       { cmd_mariadb; cmd_wordpress; }
cmd_help() {
  echo "--- WordPress Backup Script ---"
  echo "Directory: ${SCRIPT_DIR}"
  echo "Usage: $0 {db|wp|all|help}"
  echo "  db   = データベース(MariaDB)"
  echo "  wp   = Word Press (Wp-Content)"
  echo "  all  = db + wp"
  echo "  help = オプション"
}

#-----　メインプログラム　-------------
#------------------------------------
case "${1:-}" in
  db)        cmd_mariadb   ;;
  wp)        cmd_wordpress ;;
  all)       cmd_all       ;;
  help|"")   cmd_help      ;;
  *)
    echo "Unknown command: $1"
    cmd_help
    exit 1
    ;;
esac

MariaDB_Backup.sh : データベースバックアップ（Wp-Backup.shから呼ばれる）

#!/bin/bash
#  WoredPress のデータベースバックアップ
#    MariaDB_Backup.sh    2026/05 by Kazuban
#------------------------------------
# 直接実行ガード（呼び出し元スクリプトからのみ実行可）
if [[ -z "${CALLER_SCRIPT:-}" ]]; then
  echo "直接実行はできません。"
  echo "[WP-Backup.sh db] から呼び出してください。"
  exit 1
fi
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
#------------------------------------
# --- 関数定義 ---
usage() {
  echo "使用方法: ${SCRIPT_NAME:-$(basename "$0")}"
  echo "  データベース(MariaDB)をバックアップし、古いファイルを整理します。"
  exit 0
}

log() {
  local message="$1"
  echo "$(date '+%Y-%m-%d %H:%M:%S') ${message}" | tee -a "${MYSQL_LOG}"
}

failed() {
  echo "エラー: $1" >&2
  log "ERROR: $1"
  exit 1
}

# バックアップファイル名を生成する（同名ファイルがあれば連番を付加）
make_filename() {
  local date_str
  date_str=$(date '+%Y%m%d')
  local basename="-MariaDB.bak"
  local filename="${date_str}${basename}"
  local i=1
  while [[ -e "${BACKUP_DIR}/${filename}" ]]; do
    filename="${date_str}-${i}${basename}"
    (( i++ )) || true
  done
  echo "${filename}"
}

# --- ヘルプ ---
if [[ "${1:-}" == "-?" || "${1:-}" == "-h" || "${1:-}" == "--help" ]]; then
  usage
fi

# --- 事前チェック ---
[[ -d "${BACKUP_DIR}" ]]      || failed "バックアップ先が見つかりません: ${BACKUP_DIR}"
[[ -x "${TIDY_UP_SCRIPT}" ]]  || failed "整理スクリプトが見つかりません: ${TIDY_UP_SCRIPT}"

# --- ファイル名決定 ---
FILENAME=$(make_filename)
BACKUP_PATH="${BACKUP_DIR}/${FILENAME}"

# --- バックアップ実行 ---
log "MariaDB バックアップ開始: ${FILENAME}"
echo "MariaDB を ${FILENAME} にバックアップします。"

if mariadb-dump \
    --user="${MYSQL_USER}" \
    --password="${MYSQL_USER_PASSWD}" \
    --host=localhost \
    --all-databases \
    --single-transaction \
    --quick \
    > "${BACKUP_PATH}" \
    2>> "${MYSQL_LOG}"; then
  log "バックアップ成功: ${FILENAME} ($(du -sh "${BACKUP_PATH}" | cut -f1))"
else
  failed "mariadb-dump コマンドが失敗しました"
fi

# --- 古いファイルの整理 ---
log "古いバックアップを整理します（${DAYS_AGO} 日以前）"
"${TIDY_UP_SCRIPT}" "${BACKUP_DIR}" "${DAYS_AGO}"

log "MariaDB バックアップ完了"
echo "MariaDB Backup Complete."

Wp-Content_Backup.sh : WordPressコンテンツバックアップ（Wp-Backup.shから呼ばれる）

#!/bin/bash
#  wp-content ディレクトリのバックアップスクリプト
#    WP-content_Backup.sh    2026/05 by Kazuban
#------------------------------------
# 直接実行ガード（呼び出し元スクリプトからのみ実行可）
if [[ -z "${CALLER_SCRIPT:-}" ]]; then
  echo "直接実行はできません。"
  echo "[WP-Backup.sh wp] から呼び出してください。"
  exit 1
fi
#------------------------------------
readonly SCRIPT_NAME="$(basename "$0")"
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
#------------------------------------
# スクリプト終了時に実行させたい場合はここで再定義
cleanup() {
#  echo "Wp-Backup 終了処理"
  :
}
#------------------------------------
# --- 関数定義 ---
usage() {
  echo "使用方法: ${SCRIPT_NAME}"
  echo "  wp-content ディレクトリをバックアップし、古いファイルを整理します。"
  exit 0
}

log() {
  local message="$1"
  echo "$(date '+%Y-%m-%d %H:%M:%S') ${message}" | tee -a "${WP_LOG}"
}

failed() {
  echo "エラー: $1" >&2
  log "ERROR: $1"
  exit 1
}

# バックアップファイル名を生成する（同名ファイルがあれば連番を付加）
make_filename() {
  local date_str
  date_str=$(date '+%Y%m%d')
  local basename="-Wp-content.tar.gz"
  local filename="${date_str}${basename}"
  local i=1
  while [[ -e "${BACKUP_DIR}/${filename}" ]]; do
    filename="${date_str}-${i}${basename}"
    (( i++ )) || true
  done
  echo "${filename}"
}

# --- ヘルプ ---
if [[ "${1:-}" == "-?" || "${1:-}" == "-h" || "${1:-}" == "--help" ]]; then
  usage
fi

# --- 事前チェック ---
[[ -d "${BACKUP_DIR}" ]]   || failed "バックアップ先が見つかりません: ${BACKUP_DIR}"
[[ -d "${BACKUP_SOURCE_DIR}" ]]  || failed "バックアップ元が見つかりません: ${BACKUP_SOURCE_DIR}"
[[ -x "${TIDY_UP_SCRIPT}" ]]  || failed "整理スクリプトが見つかりません: ${TIDY_UP_SCRIPT}"

# --- ファイル名決定 ---
FILENAME=$(make_filename)
DEST="${BACKUP_DIR}/${FILENAME}"

# --- バックアップ実行 ---
log "WordPress バックアップ開始:"
log "${BACKUP_SOURCE_DIR} → ${DEST}"
echo "WordPress Backup Starting..."

#echo "バックアップファイル：${DEST}"
#echo "sudo chown ${USER}: ${DEST}"
#exit 1
if sudo tar \
    --create \
    --gzip \
    --file="${DEST}" \
    "${BACKUP_SOURCE_DIR}"; then # \
    #2>> "${WP_LOG}"; then
  echo "バックアップファイル：${DEST}"
  echo "sudo chown ${USER}: ${DEST}"
  sudo chown ${USER}: ${DEST}
  log "バックアップ成功: ${FILENAME} ($(du -sh "${DEST}" | cut -f1))"
else
  failed "tar コマンドが失敗しました"
fi

# --- 古いファイルの整理 ---
log "古いバックアップを整理します（${DAYS_AGO} 日以前）"
"${TIDY_UP_SCRIPT}" "${BACKUP_DIR}" "${DAYS_AGO}"

log "WordPress バックアップ完了"
echo "WordPress Backup Complete."

Wp-Restore.sh : データベース＆WordPressコンテンツの復元

#!/bin/bash
#  WoredPress の復元
#    データベース(Mysql)とサーバーデータ(wp-content)
#  Wp-Restore.sh    2026/05 by Kazuban
#------------------------------------
#--- debug mode, set "DEBUG=1". -----
export DEBUG=
#------------------------------------
export CALLER_SCRIPT="$0"
#export SCRIPT_DIR=$(dirname "$(realpath "$0")")
SCRIPT_DIR=$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")
export SCRIPT_DIR
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
source "${SCRIPT_DIR}/WordPress_Config_Data.sh"
export BACKUP_DIR="${USER_DIR}/Backup/WordPress/${SUB_DIR}"
#---- MariaDB -----------------------
export MYSQL_RESTORE_SCRIPT="${SCRIPT_DIR}/MariaDB_Restore.sh"
export PRE_BACKUP_FILE="Pre-Backup.bak"
#---- WordPress ---------------------
export WP_RESTORE_SCRIPT="${SCRIPT_DIR}/Wp-Content_Restore.sh"
#------------------------------------
export PRE_BACKUP="Y"    # リストア前に現行 wp-content を退避するか Y/N
#-----　関数定義 -----------------------
#user_dir=$(pwd)
#echo $user_dir
# スクリプト終了時に実行させたい場合はここで再定義
cleanup() {
#  echo "Wp-Backup 終了処理"
  :
}
check_backup_dir(){
  if [ ! -d $BACKUP_DIR ]; then
    echo "バックアップディレクトリがありません！"
    exit 0 
  fi
}
cmd_mariadb()   { check_backup_dir; $MYSQL_RESTORE_SCRIPT; }
cmd_wordpress() { check_backup_dir; $WP_RESTORE_SCRIPT; }
cmd_all()       { cmd_mariadb; cmd_wordpress; }
cmd_help() {
  echo "--- WordPress Restor Script ---"
  echo "Directory: ${SCRIPT_DIR}"
  echo "Usage: $0 {db|wp|all|help}"
  echo "  db   = データベース(MariaDB)"
  echo "  wp   = Word Press (Wp-Content)"
  echo "  all  = db + wp"
  echo "  help = オプション"
}

#-----　メインプログラム　-------------
#------------------------------------
case "${1:-}" in
  db)        cmd_mariadb   ;;
  wp)        cmd_wordpress ;;
  all)       cmd_all       ;;
  help|"")   cmd_help      ;;
  *)
    echo "Unknown command: $1"
    cmd_help
    exit 1
    ;;
esac

MariaDB_Restore.sh データベース復元（Wp-Restore.shから呼ばれる）

#!/bin/bash
#  WoredPress のデータベース復元スクリプト
#    MariaDB_Restore.sh    2026/05 by Kazuban
#------------------------------------
# 直接実行ガード（呼び出し元スクリプトからのみ実行可）
if [[ -z "${CALLER_SCRIPT:-}" ]]; then
  echo "直接実行はできません。"
  echo "[WP-Backup.sh db] から呼び出してください。"
  exit 1
fi
# --- debug mode: DEBUG=1 で有効 ---
#DEBUG=
PRE_BACKUP="Y"   # リストア前にバックアップを取るか Y/N
PRE_BACKUP_FILE="Pre-Backup.bak"
#------------------------------------
export SCRIPT_DIR=$(dirname "$(realpath "$0")")
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
source "${SCRIPT_DIR}/WordPress_Config_Data.sh"
#export BACKUP_DIR="${USER_DIR}/Backup/WordPress/${SUB_DIR}"
#------------------------------------

# ---- 関数定義 ---------------------------------------
# バックアップファイルの一覧を配列に格納する
load_backup_files() {
  BACKUP_FILES=()
  while IFS= read -r f; do
    BACKUP_FILES+=("$(basename "$f")")
  #done < <(find "${BACKUP_DIR}" -maxdepth 1 -name "*.bak" | sort)
  done < <(find "${BACKUP_DIR}" -maxdepth 1 -name "*-MariaDB.bak" | sort)
}

# 番号付きリストを表示する
list_backups() {
  echo "--------------------"
  echo "バックアップディレクトリ: ${BACKUP_DIR}"
  echo "--------------------"

  # --- # は個数を表し、[@] は配列のすべての要素
  if [[ ${#BACKUP_FILES[@]} -eq 0 ]]; then
    echo "（バックアップファイルが見つかりません）"
  else
    local i=1
    for f in "${BACKUP_FILES[@]}"; do
      printf "  [%d] %s\n" "$i" "$f"
      (( i++ )) || true   # set -e 対策: (( )) は 0 になると終了コード 1 を返すため
    done
  fi
  echo "--------------------"
}

# 入力値（番号 or ファイル名）からファイル名を解決して返す
resolve_input() {
  local input="$1"

  # 数字のみ → 番号として解釈
  if [[ "$input" =~ ^[0-9]+$ ]]; then
    local idx=$(( input - 1 ))
    if (( idx < 0 || idx >= ${#BACKUP_FILES[@]} )); then
      echo "エラー: 番号 ${input} は範囲外です（1〜${#BACKUP_FILES[@]}）" >&2
      exit 1
    fi
    echo "${BACKUP_FILES[$idx]}"
  else
    # 文字列 → ファイル名として解釈（リスト内に存在するか確認）
    local f
    for f in "${BACKUP_FILES[@]}"; do
      if [[ "$f" == "$input" ]]; then
        echo "$f"
        return
      fi
    done
    echo "エラー: ファイルが見つかりません: ${input}" >&2
    exit 1
  fi
}

# 対話形式でファイルを選択させる
select_backup_file() {
  local selected=""
  while [[ -z "$selected" ]]; do
    read -r -p "番号またはファイル名を入力してください (q で終了): " INPUT
    case "$INPUT" in
      [qQ])
        kill -USR1 $$    # 親プロセス（スクリプト自身）にシグナルを送る
        exit 1;;
      "")   echo "入力してください" ;;
      *)    selected=$(resolve_input "$INPUT") ;;
    esac
  done
  echo "$selected"
}

usage() {
  echo "使い方: $(basename "$0") [バックアップファイル名 or 番号]"
  echo "  引数なしで起動すると対話形式で選択できます。"
  echo "--------------------"
  list_backups
  exit 1
}

run_pre_backup() {
  local date_str
  date_str=$(date '+%Y%m%d-%H%M')
  local pre_backup_path="${BACKUP_DIR}/${date_str}-${PRE_BACKUP_FILE}"

  echo "--------------------"
  echo "-- 事前バックアップを開始します... --"

  #mysqldump \
  mariadb-dump \
    --user="${MYSQL_USER}" \
    --password="${MYSQL_USER_PASSWD}" \
    --host=localhost \
    --all-databases \
    --single-transaction \
    --quick \
    > "${pre_backup_path}"

  echo "-- 事前バックアップ完了: ${pre_backup_path} --"
  echo "--------------------"
}

run_restore() {
  local backup_file="${BACKUP_DIR}/${1}"

  echo "--------------------"
  echo "-- リストア対象: ${1} --"
  echo "-- データベース: ${DATABASE} --"
  echo "--------------------"

  read -r -p "リストアを実行しますか？ (y/n): " YN
  case "${YN}" in
    [yY])
      echo "-- リストアを開始します... --"
      #mysql \
      mariadb \
        --user=root \
        --password="${MYSQL_ROOT_PASSWD}" \
        "${DATABASE}" \
        < "${backup_file}"
      echo "-- リストア完了 --"
      ;;
    [nN])
      kill -USR1 $$    # 親プロセス（スクリプト自身）にシグナルを送る
      exit 0
      echo "-- 中止しました --"
      exit 0
      ;;
    *)
      echo "エラー: y または n を入力してください" >&2
      exit 1
      ;;
  esac
}

# ----- メイン処理 --------------------------------------------

# バックアップディレクトリの存在確認
if [[ ! -d "${BACKUP_DIR}" ]]; then
  echo "エラー: バックアップディレクトリが存在しません: ${BACKUP_DIR}" >&2
  exit 1
fi

# ファイル一覧をグローバル配列に読み込む
# declare 変数の属性やタイプ -a 「配列(Array)」
declare -a BACKUP_FILES
load_backup_files

# ヘルプ
if [[ "${1:-}" == "-h" || "${1:-}" == "--help" ]]; then
  usage
fi

# ファイル選択：引数あり → 解決、なし → 対話形式
if [[ $# -gt 0 ]]; then
  list_backups
  SELECTED_FILE=$(resolve_input "$1")
else
  list_backups
  SELECTED_FILE=$(select_backup_file)
fi

echo "-- 選択されたファイル: ${SELECTED_FILE} --"

# 事前バックアップ
if [[ "${PRE_BACKUP}" =~ ^[Yy]$ ]]; then
  run_pre_backup
fi

# リストア実行
run_restore "${SELECTED_FILE}"

Wp-Content_Restore.sh: WordPressコンテンツ復元（Wp-Restore.shから呼ばれる）

#!/bin/bash
#  wp-content ディレクトリの復元スクリプト
#    WP-Content_Restore.sh    2026/05 by Kazuban
#------------------------------------
# 直接実行ガード（呼び出し元スクリプトからのみ実行可）
if [[ -z "${CALLER_SCRIPT:-}" ]]; then
  echo "直接実行はできません。"
  echo "[WP-Backup.sh db] から呼び出してください。"
  exit 1
fi
# --- debug mode: DEBUG=1 で有効 ---
#export DEBUG=
PRE_BACKUP="Y"    # リストア前に現行 wp-content を退避するか Y/N
#------------------------------------
export SCRIPT_DIR=$(dirname "$(realpath "$0")")
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
source "${SCRIPT_DIR}/WordPress_Config_Data.sh"
#------------------------------------

# --- 関数定義 ---
# バックアップファイルの一覧を配列に格納する
load_backup_files() {
  BACKUP_FILES=()
  cmd="find ${BACKUP_DIR} -maxdepth 1 -name *-${WP_CONTENT_DIR}.tar.gz"  #${WP_CONTENT_DIR}
  while IFS= read -r f; do
    BACKUP_FILES+=("$(basename "$f")")
  done < <(find "${BACKUP_DIR}" -maxdepth 1 -name "*-${WP_CONTENT_FILENAME}.tar.gz" | sort)
}

# 番号付きリストを表示する
list_backups() {
  echo "--------------------"
  echo "バックアップディレクトリ: ${BACKUP_DIR}"
  echo "--------------------"

  if [[ ${#BACKUP_FILES[@]} -eq 0 ]]; then
    echo "（バックアップファイルが見つかりません）" >&2
  else
    local i=1
    for f in "${BACKUP_FILES[@]}"; do
      printf "  [%d] %s\n" "$i" "$f"
      (( i++ )) || true   # set -e 対策: (( )) は 0 になると終了コード 1 を返すため
    done
  fi
  echo "--------------------"
}

# 入力値（番号 or ファイル名）からファイル名を解決して返す
resolve_input() {
  local input="$1"

  # 数字のみ → 番号として解釈
  if [[ "$input" =~ ^[0-9]+$ ]]; then
    local idx=$(( input - 1 ))
    if (( idx < 0 || idx >= ${#BACKUP_FILES[@]} )); then
      echo "エラー: 番号 ${input} は範囲外です（1〜${#BACKUP_FILES[@]}）" >&2
      exit 1
    fi
    echo "${BACKUP_FILES[$idx]}"
  else
    # 文字列 → ファイル名として解釈（リスト内に存在するか確認）
    local f
    for f in "${BACKUP_FILES[@]}"; do
      if [[ "$f" == "$input" ]]; then
        echo "$f"
        return
      fi
    done
    echo "エラー: ファイルが見つかりません: ${input}" >&2
    exit 1
  fi
}

# 対話形式でファイルを選択させる
select_backup_file() {
  local selected=""
  while [[ -z "$selected" ]]; do
    read -r -p "番号またはファイル名を入力してください (q で終了): " INPUT
    case "$INPUT" in
      [qQ])
        kill -USR1 $$
        exit 1 ;;
      "")   echo "入力してください" ;;
      *)    selected=$(resolve_input "$INPUT") ;;
    esac
  done
  echo "$selected"
}

# 使い方表示
usage() {
  echo "使い方: $(basename "$0") [バックアップファイル名 or 番号]"
  echo "  引数なしで起動すると対話形式で選択できます。"
  echo "--------------------"
  list_backups
  exit 1
}

# 既存 wp-content を日付付きディレクトリ名にリネームして退避する
run_pre_backup() {
  local date_str
  date_str=$(date '+%Y%m%d-%H%M')
  local backup_path="${WP_CONTENT_PATH}-${date_str}.bak"

  echo "--------------------"
  echo "-- 事前バックアップ（退避）を開始します... --"
  echo "-- ${WP_CONTENT_PATH} → ${backup_path} --"
  sudo mv "${WP_CONTENT_PATH}" "${backup_path}"
  echo "-- 事前バックアップ完了 --"
  echo "--------------------"
}

# リストア実行
run_restore() {
  local backup_file="${BACKUP_DIR}/$1"
  local work_dir
  #work_dir=$(mktemp -d) #添付ディレクトリの利用
  work_dir=$BACKUP_DIR

  echo "--------------------"
  echo "-- リストア対象: $1 --"
  echo "-- 展開先 (${WP_CONTENT_DIR}): ${WP_CONTENT_PATH} --"
  echo "--------------------"

  read -r -p "リストアを実行しますか？ (y/n): " YN
  case "${YN}" in
    [yY])
      echo "-- リストアを開始します... --"

      # 1. アーカイブ内の wp-content の階層数を確認
      echo "-- 展開中: ${backup_file} --"
      local wp_path strip_count

      list=$(tar tzf "${backup_file}")
      wp_path=$(echo "$list" | grep -m1 "${WP_CONTENT_DIR}/$" || true)
      echo "------ $wp_path --------"
      if [[ -z "${wp_path}" ]]; then
        echo "エラー: アーカイブ内に ${WP_CONTENT_DIR} ディレクトリが見つかりません" >&2
        exit 1
      fi
      # パスの / の数から除去する階層数を算出
      # 例: home/www/html/sweb01/wp-content/ → スラッシュ5個 → strip=4
      strip_count=$(echo "${wp_path}" | tr -cd '/' | wc -c)
      strip_count=$(( strip_count - 1 ))
      echo $strip_count
      #exit 1
      if [[ $strip_count < 0 ]]; then
        echo "エラー: 階層がありません" >&2
        #echo "エラー: アーカイブ内に wp-content ディレクトリが見つかりません"
        exit 1
      fi
      #DIR="${work_dir}/wp-content"
      DIR=${work_dir}
      echo "${DIR}がない場合には作成します"
      mkdir -p "$DIR"
      # --strip-components で wp-content/ を作業ディレクトリ直下に展開
      tar xvzf "${backup_file}" -C "${DIR}" \
        --strip-components="${strip_count}"
      ls -la $DIR

      # 所定の場所に配置してオーナーを設定
      echo sudo mv "${work_dir}/${WP_CONTENT_DIR}" "${WP_CONTENT_PATH}"
      echo sudo chown -R "${WP_CONTENT_OWNER}" "${WP_CONTENT_PATH}/"
      sudo mv "${work_dir}/${WP_CONTENT_DIR}" "${WP_CONTENT_PATH}"
      sudo chown -R "${WP_CONTENT_OWNER}" "${WP_CONTENT_PATH}/"

      echo "-- リストア完了 --"
      # スクリプト終了時に作業ディレクトリを削除
      #trap 'rm -rf "${work_dir}"' EXIT

      ;;
    [nN])
      kill -USR1 $$
      exit 0
      ;;
    *)
      echo "エラー: y または n を入力してください" >&2
      exit 1
      ;;
  esac
}
cleanup() {
  echo Clean up!!
  echo ${BACKUP_DIR}
  #read -r -p "${BACKUP_DIR}/${WP_CONTENT_DIR} 削除しますか？ (Y/N): " INPUT
  #  case "$INPUT" in
  #    [Yy])
  #      rm -rf "${BACKUP_DIR}/${WP_CONTENT_DIR}"  
  #  esac
}

# --- メイン処理 ---

# バックアップディレクトリの存在確認
if [[ ! -d "${BACKUP_DIR}" ]]; then
  echo "エラー: バックアップディレクトリが存在しません: ${BACKUP_DIR}" >&2
  exit 1
fi

# ファイル一覧をグローバル配列に読み込む
declare -a BACKUP_FILES
load_backup_files

# ヘルプ
if [[ "${1:-}" == "-h" || "${1:-}" == "--help" ]]; then
  usage
fi

# ファイル選択：引数あり → 解決、なし → 対話形式
if [[ $# -gt 0 ]]; then
  list_backups
  SELECTED_FILE=$(resolve_input "$1")
else
  list_backups
  SELECTED_FILE=$(select_backup_file)
fi

echo "-- 選択されたファイル: ${SELECTED_FILE} --"

# 事前バックアップ（現行 wp-content の退避）
if [[ "${PRE_BACKUP}" =~ ^[Yy]$ ]]; then
  run_pre_backup
fi

# リストア実行
run_restore "${SELECTED_FILE}"

Header.sh : デバッグモード仕様（変数 DEBUG=1 で有効）

#!/bin/bash
#
#  Header.sh    2026/05 by AI & Kazuban
#  共通ヘッダー: source で読み込んで使う
#  使い方: source "${SCRIPT_DIR}/Header.sh"
#
#------------------------------------
#-e：失敗で停止：#-u：未定義変数禁止:#pipefail：パイプの途中も検知
set -euo pipefail

# --- traps ---
trap 'echo "-- 中止しました --"; exit 0' USR1
trap 'echo "Error at line $LINENO"; exit 1' ERR
trap cleanup EXIT

# cleanup は呼び出し元スクリプトで上書き可能
cleanup() {
  :
}

# --- debug mode: DEBUG=1 で有効 ---
export DEBUG=${DEBUG:-0}
if [[ "$DEBUG" == "1" ]]; then
  echo "Debug mode is 'true' !! "
  export PS4='+ ${LINENO}: '
  set -x
  trap 'read -p "STEP> " < /dev/tty' DEBUG
else
  echo "Debug mode is 'false' !! "
fi

Tidyup_backfile.sh : バックアップファイルの整理（引数：対象ディレクトリ・保存日数）

#!/bin/bash
# Delete $DAY days ago from backup
#
#  Tidyup_backfile.sh  by AI & Kazuban 2026/05
#                default 10 days ago
#
#------------------------
# delete_backup - バックアップファイルを整理するスクリプト
# 使用方法: delete_backup [削除対象ディレクトリ] [何日前まで残すか]

#set -euo pipefail
#--- for debag ----------------------
#--- デバッグモード（DEBUG=1 で有効）---
#if [[ "${DEBUG:-0}" == "1" ]]; then
#  export PS4='+ ${LINENO}: '
#  set -x
#  trap 'read -p "STEP> " < /dev/tty' DEBUG
#fi

readonly SCRIPT_NAME="$(basename "$0")"

usage() {
    echo "使用方法: ${SCRIPT_NAME} <削除対象ディレクトリ> [保持日数]"
    echo "  削除対象ディレクトリ  : バックアップファイルのあるディレクトリ"
    echo "  保持日数              : 何日前までのファイルを残すか (デフォルト: 10)"
    exit 1
}

# --- 引数チェック ---
if [[ $# -lt 1 || "$1" == "-?" || "$1" == "-h" || "$1" == "--help" ]]; then
    usage
fi

TARGET_DIR="$1"
DAYS="${2:-10}"

# --- 数値チェック ---
if ! [[ "$DAYS" =~ ^[0-9]+$ ]]; then
    echo "エラー: 保持日数には正の整数を指定してください: ${DAYS}" >&2
    exit 1
fi

# --- ディレクトリ存在チェック ---
if [[ ! -d "$TARGET_DIR" ]]; then
    echo "エラー: ディレクトリが見つかりません: ${TARGET_DIR}" >&2
    exit 1
fi

# --- 削除基準日を算出 ---
DEL_DATE="$(date --date="${DAYS} days ago" +%Y%m%d)"
echo "削除基準日: ${DEL_DATE} より前のファイルを削除します (保持日数: ${DAYS}日)"

# --- 対象ファイルの処理 ---
# 数字始まりのファイル名から先頭8桁(YYYYMMDD)を取得して重複排除
while IFS= read -r file_date; do
    if [[ "$file_date" < "$DEL_DATE" ]]; then
        echo "削除: ${TARGET_DIR}/${file_date}*"
        rm -f -- "${TARGET_DIR}/${file_date}"*
    fi
done < <(
    ls -- "$TARGET_DIR" \
        | grep -E '^[0-9]' \
        | awk '{ print substr($0, 1, 8) }' \
        | sort -u
)

echo "完了"

リストアする場合の注意点

リストアスクリプトでは、バックアップファイルのリストが表示されますが、
必ず、データベースとコンテンツのバックアップファイルのリスト番号（日付）は同じにする事をお勧めします
また、バックアップサーバーなどへリストアする場合、URLが異なる場合があるかもしれません
その時は、こちらの作業が必要になる場合があります

この作業をAIにスクリプト化してもらったのが、下記になります

update_wp_url.sh

#!/bin/bash

# ==========================
SCRIPT_DIR=$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")
export SCRIPT_DIR
#--- debug mode, set "DEBUG=1". -----
export DEBUG=
#------------------------------------
source "${SCRIPT_DIR}/Header.sh"
source "${SCRIPT_DIR}/WordPress_Config_Data.sh"
# ===== 設定 =====
DB_USER="root"
DB_PASS=${MYSQL_ROOT_PASSWD}
DB_NAME=${DATABASE}
OLD_URL="http://www.hogehoge.com/blog"
NEW_URL="http://www2.hogehoge.com/blog"

# ===== 実行前確認 =====
echo "=== WordPress URL変更スクリプト ==="
echo "DB      : $DB_NAME"
echo "変更前  : $OLD_URL"
echo "変更後  : $NEW_URL"
echo ""
read -p "続行しますか？ (y/N): " confirm
[[ "$confirm" != "y" && "$confirm" != "Y" ]] && echo "キャンセルしました。" && exit 0

# ===== 変更前の値を確認 =====
echo ""
echo "--- 変更前 ---"
mysql -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" -e \
  "SELECT option_id, option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');"

# ===== UPDATE実行 =====
mysql -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" -e \
  "UPDATE wp_options SET option_value = '$NEW_URL' WHERE option_id = 1 OR option_id = 2;"

echo ""
echo "--- 変更後 ---"
mysql -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" -e \
  "SELECT option_id, option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');"

echo ""
echo "✅ 完了しました。"

自動バックアップ

こちらでも、紹介していますが、「crontab」に下記のように設定する事で、毎日２時に自動バックアップできるようになります

00 2 * * *        /home/kazuban/Backup/bin/Wp-Backup.sh all

WordPress インストール

最新のWordPresssダウンロード

ダウンロード後展開する作業場所へ移動し、ダウンロードします
筆者は、ユーザーディレクトリの「Downloads」を作業場所にしました

cd ~/Downloads/
wget https://ja.wordpress.org/latest-ja.tar.gz
tar xvzf latest-ja.tar.gz
ls wordpress/ 

WordPress パッケージが展開されました

index.php             wp-config-sample.php  wp-mail.php
license.txt           wp-content            wp-settings.php
readme.html           wp-cron.php           wp-signup.php
wp-activate.php       wp-includes           wp-trackback.php
wp-admin              wp-links-opml.php     xmlrpc.php
wp-blog-header.php    wp-load.php
wp-comments-post.php  wp-login.php

WordPressパッケージをApache設定場所へ移動

展開した「wordpress」ディレクトリを、前回「httpd.conf」で「DocumentRoot」に設定したディレクトリ配下へ移動します
また、「wordpress」というディレクトリ名は、公開する時のアドレス名になります
この場合、https://「サイトドメイン」/wordpress/ です。
変更したい場合には、好みの名前に変更します
次の例では、「blog」という名前に変更し、所有権も「apache」に変更しています

cd ~/Downloads/
sudo mv ./wordpress/ /home/www/html/ 
cd /home/www/html/
sudo mv ./wordpress/ ./blog/
sudo chown -R apache.apache ./blog/
ls -la

・
・
drwxr-xr-x. 5 apache apache 4096  4月  3 01:00 blog
-rw-r--r--. 1 apache apache  121  4月 24 10:52 index.html

「blog」と言う名前に変更され、所有者も「apache」になっていれば、WordPressの配置は完了です。

MariaDBの設定

WordPress用のデータベースとユーザーを作成します
設定情報は、事前にメモを作成しておくとスムーズに進行できます
例として、下記で設定します

• root パスワード：初期設定で、「Change the root password」で作成したパスワード
• データベース名：WpDb
• ユーザー名：WpAdmin
• パスワード：WpPasswd
• データベースホスト：localhost

データベースの作成

mysql -u root -p[rootパスワード] #-pの後ろはスペースは入れない
・
・データベース作成
MariaDB [(none)]>CREATE DATABASE WpDb CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
・
・データベース確認
MariaDB [(none)]> SHOW DATABASES;
・
・管理者作成
GRANT ALL ON WpDb.* TO 'WpAdmin'@'localhost' IDENTIFIED By 'WpPasswd';
・
・確認
USE mysql
SELECT user,host from user;
SHOW GRANTS FOR 'WpAdmin'@'localhost';

もし、データベース名やユーザーを変更したい場合には、「DROP」コマンドで
一度削除し、再生成します

DROP DATABASE データベース名;
・より安全を考慮した次のコードでは存在しない場合のエラーを回避できます
DROP DATABASE IF EXISTS データベース名;

DROP USER 'username'@'localhost';
・存在しない場合のエラーを回避
DROP USER IF EXISTS 'username'@'localhost'; 

WordPress 初期設定

初期設定

Apacheの設定で、ドメインでのアクセスが可能であればドメインで、
ドメインでの設定をしていない場合には、IPアドレスを
ChromeなどWebブラウザに入力して確認します
「WordPressへようこそ・・・」の画面が表示されます。

その画面で「さあ、始めましょう！」をクリック
上記で設定したデータベース情報を設定します

「サイトタイトル」「ユーザー名」「パスワード」を設定しますが
ここでのユーザー名は、WordPressの管理画面にログインするユーザーを設定します
データベースの管理ユーザーとは違いますので注意してください

ログインで、WordPressの管理画面からWordPressの設定ができるようになります

サイトヘルス

「https://「サイトドメイン」/blog/wp-admin/site-health.php」にアクセスすると、サイトの状態が確認できますが、自宅環境では、「REST API 」エラーが出ました

自宅内での設定の場合、名前解決ができていないのが原因のようです
同じLAN上のwindowsPCには「hosts」ファイルに設定しましたが、サーバー（Linux）側も
「hosts」設定し強制的に名前解決させようと思います。

sudo vi /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.100 www2.hogehoge.com

これで、「・・/wp-admin/site-health.php」を更新すると、「REST API 」エラーは消えていました

Hello World!

「https://「サイトドメイン」/blog/」にアクセスすると、デフォルトのサンプルページが表示されます

WordPress環境構築終了

これで、WordPress環境構築は終了です
「https://「サイトドメイン」/blog/wp-admin/」で、ダッシュボード（管理画面）が開きます。
コンテンツから外観までいろいろな設定変更が可能で、「管理画面（ダッシュボード）」を使いこなすことから始めます。
まずは、「外観」⇒「テーマ」を変更する事で、見栄えをガラッと変えましょう！

WordPress環境構築まとめ

PHP
MariaDB

上記を参考に、PHP8.4 MariaDB11.4(LTS)をインストールします

PHPのインストールまたは更新

筆者の現環境では、PHPはまだインストールしていませんが、とりあえず確認します

php --version

やはりインストールされていませんが、もしインストールされている場合には、モジュールのリセットやキャッシュクリアしたほうがトラブルは少ないと思います
事前にwp-config.php, DB, ファイル一式のバックアップを取っておきましょう

Remiリポジトリ追加（Rocky Linux 9の場合）

sudo dnf install -y epel-release
sudo dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm

キャッシュをクリア

sudo dnf clean all && sudo dnf makecache

モジュールリスト確認

dnf module list php

もし404のエラーが出た場合

sudo rm -f /etc/dnf/vars/releasever
sudo dnf clean all && sudo dnf makecache
dnf module list php

Rocky Linux 9 - AppStream
Name     Stream       Profiles                      Summary                            
php      8.1          common [d], devel, minimal    PHP scripting language             
php      8.2          common [d], devel, minimal    PHP scripting language             
php      8.3          common [d], devel, minimal    PHP scripting language             

Remi's Modular repository for Enterprise Linux 9 - x86_64
Name     Stream       Profiles                      Summary                            
php      remi-7.4     common [d], devel, minimal    PHP scripting language             
php      remi-8.0     common [d], devel, minimal    PHP scripting language             
php      remi-8.1     common [d], devel, minimal    PHP scripting language             
php      remi-8.2     common [d], devel, minimal    PHP scripting language             
php      remi-8.3     common [d], devel, minimal    PHP scripting language             
php      remi-8.4     common [d], devel, minimal    PHP scripting language             
php      remi-8.5     common [d], devel, minimal    PHP scripting language  

私の環境では、AppStream には、8.3までですが、Remiでは、8.5まで登録されています
ここでは、最新は避けて8.4を使用しようと思います

PHPモジュールのリセット

sudo dnf module reset php -y

新しいPHPバージョンの有効化（例: 8.4）

sudo dnf module enable php:remi-8.4 -y

新規インストールの場合

sudo dnf install php php-fpm -y

アップグレードの場合

sudo dnf update php\* -y

更新の確認

php -v

拡張機能を追加

WordPressを動作させるのに、必須と推奨なPHP拡張機能があります。
こちらとAIの意見を参考にして、インストールしておきたいと思います。
すでに、インストール済みや一致するものがない場合もありましたが、インストールしました

sudo dnf install -y \
  php-mysqlnd \
  php-curl \
  php-exif \
  php-fileinfo \
  php-gd \
  php-imagick \
  php-intl \
  php-mbstring \
  php-xml \
  php-zip

再起動

sudo systemctl restart httpd
sudo systemctl restart php-fpm

PHP8.4について、🧑‍💻AIからのアドバイス

補足：PHP 8.4での注意点（AIからのアドバイス）

PHP 8.4は比較的新しいため、利用しているWordPressテーマや古いプラグインがまだ対応しておらず、非推奨（Deprecated）の警告が出る場合があります。

• もしエラーが出る場合は、WordPressの管理画面から「サイトヘルス」を確認し、足りないモジュールがないかチェックしてみてください。

もし特定のプラグインで「これが足りない」と言われた場合は、dnf search php-拡張名 で探すとすぐに見つかりますよ。

php.ini の設定

PHPの設定は、「/etc/php.ini」で行います。
念のためバックアップととり、編集します。

sudo cp -p /etc/php.ini /etc/php.ini.org
sudo vi /etc/php.ini

筆者の利用方法としては、記事内に画像貼り付けと少数ですが動画も貼り付けたいと思っているので、多少余裕をもった設定にしました。

・
・
;expose_php = On
expose_php = Off

;max_execution_time = 30
max_execution_time = 300

;max_input_time = 60
max_input_time = 300

;max_input_vars = 1000
max_input_vars = 3000

;post_max_size = 8M
post_max_size = 300M

;upload_max_filesize = 2M
upload_max_filesize = 256M

;max_file_uploads = 20
max_file_uploads = 50

;date.timezone =
date.timezone = "Asia/Tokyo"

;mbstring.language = Japanese
mbstring.language = Japanese

;mbstring.internal_encoding =
mbstring.internal_encoding = UTF-8

;mbstring.http_input =
mbstring.http_input = UTF-8

;mbstring.http_output =
mbstring.http_output = pass

;mbstring.encoding_translation = Off
mbstring.encoding_translation = On

;mbstring.detect_order = auto
mbstring.detect_order = auto

;mbstring.substitute_character = none
mbstring.substitute_character = none
・
・

キャッシュ拡張用の10-opcache.ini の設定変更

OPcache（オプキャッシュ）は、PHPスクリプトのコンパイル結果（バイトコード）を共有メモリにキャッシュすることで、PHPの動作を高速化する拡張モジュールですが、その設定ファイルも余裕をみた設定にしました
/etc/php.d/10-opcache.ini もバックアップをとって編集します

sudo cp -p /etc/php.d/10-opcache.ini /etc/php.d/10-opcache.ini.org
sudo vi /etc/php.d/10-opcache.ini

・
・
opcache.enable=1

;opcache.memory_consumption=128
opcache.memory_consumption=256

;opcache.memory_consumption=128
opcache.memory_consumption=256

;opcache.max_accelerated_files=10000
opcache.max_accelerated_files=20000
・
・

sudo systemctl restart php-fpm
sudo systemctl restart httpd

httpd.conf の編集

こちらは、必須ではないですが、やっといたほうがいいかも？との🧑‍💻AIのアドバイスです

/etc/httpd/conf/httpd.conf

・
・
LimitRequestBody 314572800  #（= 約300MB）
・

ただ、こちらの情報では、

デフォルト値が 0 (無制限) から 1 GiB に変更されたようです。

デフォルトでは無制限ではなくなったみたいです。

多少の動画添付を考慮した、WordPress側の設定

こちらも、🧑‍💻AIのアドバイス
画像貼り付け予定であれば、設定しておいたほうがよいとの事
こちらは、wordpress立ち上げ時に設定しようと思います

WordPress側の設定（wp-config.php）

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

PHP確認

「/home/www/home」に「index.php」という、ファイルを作成し、ブラウザに「https://www2.hogehoge.com/index.php」で確認します

echo '<?php phpinfo(); ?>' | sudo tee /home/www/html/index.php

アドレスバーに「https://www2.hogehoge.com/index.php」で確認します

確認ができたら、削除しておきましょう

sudo rm /home/www/html/index.php

MariaDB 11.4(LTS)

11.5も動作すると思いますが、11.4(LTS)をインストールしようと思います

リポジトリ追加

リポジトリ追加

curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-11.4"

パッケージキャッシュの更新

sudo dnf makecache

EPEL リポジトリ系のネットワーク接続エラーが出たので、AIに聞いてみましたが、問題はないようです
AIの回答では閉鎖環境では、EPELを無効化する事でエラーは消えるようです（筆者は試していません）

EPEL リポジトリ系エラーについて、🧑‍💻AIの回答

なるほど、閉域網環境なんですね。その状況なら無効化で問題ないです。

EPEL を無効化する

sudo dnf config-manager --disable epel

確認

sudo dnf makecache

エラーが消えれば OK です。

本機トラブル時に外部接続が必要になったら

その時は再度有効化すればいいだけです：

sudo dnf config-manager --enable epel

切り替えが簡単なので、普段は無効化しておいて問題ありません👍

パッケージ情報の一覧は、下記で確認できます
11.4のパッケージが確認できました

dnf list mariadb*

・
MariaDB-client.x86_64          11.4.10-1.el9     @mariadb-main
MariaDB-client-compat.noarch   11.4.10-1.el9     @mariadb-main
MariaDB-common.x86_64          11.4.10-1.el9     @mariadb-main
MariaDB-server.x86_64          11.4.10-1.el9     @mariadb-main
MariaDB-server-compat.noarch   11.4.10-1.el9     @mariadb-main
MariaDB-shared.x86_64 
・

MariaDB 11.４ のインストール

sudo dnf install -y MariaDB-server MariaDB-client

MariaDB サービスの起動と自動起動設定

sudo systemctl start mariadb
sudo systemctl enable mariadb

初期セキュリティ設定

sudo mariadb-secure-installation

対話形式で以下を設定します：

ファイアウォールの設定（外部接続が必要な場合）

外部からデータベースに接続する場合には、ファイヤフォールに許可します
筆者は外部からデータベースへのアクセスの予定はないので、今回は設定していませんが
覚書として、書いておきます。

sudo firewall-cmd --permanent --add-service=mysql
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=public

インストール確認

sudo systemctl status mariadb

文字コードの設定

文字化け防止に、文字コードを編集します
設定ファイルは
「/etc/my.cnf.d/server.cnf」
「/etc/my.cnf.d/client.cnf」で行うので
バックアップアップを取って、編集。

sudo cp -p /etc/my.cnf.d/server.cnf /etc/my.cnf.d/server.cnf.org 
sudo cp -p /etc/my.cnf.d/client.cnf /etc/my.cnf.d/client.cnf.org 

sudo vi /etc/my.cnf.d/server.cnf

・
・
# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]
# ----- 2026/05/01 -----
character-set-server = utf8mb4
collation-server     = utf8mb4_unicode_ci
・
・

sudo vi /etc/my.cnf.d/client.cnf

・
・
#
# These two groups are read by the client library
# Use it for options that affect all clients, but not the server
#
[client]
# ----- 2026/05/01 -----
default-character-set = utf8mb4
・
・

再起動と確認

sudo systemctl restart mariadb
sudo systemctl status mariadb

mysql -u root -p[パスワード]
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 11.4.10-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables like "chara%";
+--------------------------+------------------------------+
| Variable_name            | Value                        |
+--------------------------+------------------------------+
| character_set_client     | utf8mb4                      |
| character_set_collations |                              |
| character_set_connection | utf8mb4                      |
| character_set_database   | utf8mb4                      |
| character_set_filesystem | binary                       |
| character_set_results    | utf8mb4                      |
| character_set_server     | utf8mb4                      |
| character_set_system     | utf8mb3                      |
| character_sets_dir       | /usr/share/mariadb/charsets/ |
+--------------------------+------------------------------+
9 rows in set (0.002 sec)

MariaDB [(none)]> quit
Bye

utf8mb4 になっていることを確認します
もし、「latin1」とかになっていた場合には、再起動「sudo systemctl restart mariadb」で反映されます。

WordPress環境構築まとめ

Apache

コピペで設定できるように、まとめます
詳細は、こちらを参照してください

RockyLinux9.３で自宅サーバーを再構築V04・LAMPの「A」、Apache編

LAMPの「A」のApacheの構築編です。 インストール、セキュリティ対策、ファイヤーウォール、https化、HTTP2通信設定を説明します。 さらに例では、CGIも動作できるような設定にしています。

www.kazuban.com

2024.01.06

Remi リポジトリのインストール

ApacheやPHPの最新バージョンにも対応したいので、Remi リポジトリのインストールします
Remiのインストールには、「crb」や「epel」のインストールが必要なようです

sudo dnf config-manager --set-enabled crb
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

httpdインストール

続いて、httpd関連をインストールし、自動起動するように設定します

sudo dnf install httpd httpd-tools mod_ssl
sudo systemctl start httpd
sudo systemctl enable httpd
sudo systemctl is-enabled httpd
sudo systemctl status httpd

● httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
     Active: active (running) since Sat 2026-04-18 17:24:47 JST; 54min ago

active (running)とservice; enabledで確認できます。

Firewalld に許可

「http」と「https」を許可します

sudo firewall-cmd --add-service=http --zone=public --permanent
sudo firewall-cmd --add-service=https --zone=public --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=public

「services: 」で確認できます

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp8s0
  sources:
  services: cockpit dhcpv6-client http https ssh

ブラウザのアドレスバーにIPアドレス「http://192.168.*.*」をに入力すれば、テストページが表示されれば動作しています

httpd.conf

サーバー上のディレクトリや、ホスト名など、自分の環境に合わせて設定ファイルを編集します
筆者の場合、「DocumentRoot」を「/home/www/html」に変更します
「ServerName」は、バックアップ用なので本サーバーとの識別のためドメイン名は
「www2」とし「www2.hogehoge.com」に設定します
CGIスクリプトを使用する場合では、AddHandlerでスクリプトの拡張子を指定し、ScriptAlias以外のディレクトリにスクリプトを置く場合には、その指定ディレクトリに「Options ExecCGI」を追加します
まずは、設定ファイル「httpd.conf」はバックアップを取ってから作業します

cd /etc/httpd/conf/
sudo cp -p httpd.conf httpd.conf.org
sudo vi ./httpd.conf

edhitor

#ServerAdmin root@localhost
ServerAdmin root@localhost

#ServerName www.example.com:80
ServerName www2.hogehoge.com:80

#DocumentRoot "/var/www/html"
DocumentRoot "/home/www/html"

#<Directory "/var/www">
<Directory "/home/www">

#<Directory "/var/www/html">
<Directory "/home/www/html">

#ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
ScriptAlias /cgi-bin/ "/home/www/cgi-bin/"

#<Directory "/var/www/cgi-bin">
<Directory "/home/www/cgi-bin">

#Options Indexes FollowSymLinks
Options FollowSymLinks

#AddHandler cgi-script .cgi
# --- 2026/04/19 add by kazuban
AddHandler cgi-script .cgi
<Directory /home/www/html/script>
  AllowOverride None
  Options ExecCGI FollowSymLinks
  Order allow,deny
  Allow from all
</Directory>

筆者の場合、デフォルトにディレクトリを変更したので、そのディレクトリを作成し、所有者をapacheに変更します

sudo mkdir /home/www
sudo mkdir /home/www/html
sudo mkdir /home/www/cgi-bin
sudo chown apache.apache /home/www/html/
sudo chown apache.apache /home/www/cgi-bin/
ls -la /home/www
httpd -t

「Syntax OK」が出れば、正常に変更されています

セキュリティ対策

・テストページや「icons」一覧を非表示にする
・Apacheバージョン情報とＴRACEメソッドOFF
・X-Frame-Optionsの有効を確認
・設定したドキュメントルートにindex.htmlを作成

cd /etc/httpd/conf.d
sudo cp -p welcome.conf welcome.conf.org
sudo cp -p  autoindex.conf  autoindex.conf.org
sudo vi ./welcome.conf

表示させたくないので、削除や名前変更もできますが、自動的に復活するらしいので、<Directory>設定は、全てコメントにしました。
autoindex.confも同様です

sudo vi autoindex.conf

httpdを再起動すると、「http://192.168.*.*」は表示されなくなっていれば正常です

sudo systemctl restart httpd

さらに、Apacheバージョン情報とＴRACEメソッドもOFFにします
/etc/httpd/conf/httpd.confを編集

sudo vi /etc/httpd/conf/httpd.conf

最終行に、設定コードを追加

##--- kazuban added. 2026/04/19
ServerTokens ProductOnly
ServerSignature off
TraceEnable off

構文チェックしOKであれば、再起動します

httpd -t
sudo systemctl restart httpd

X-Frame-Optionsは、Webサイトを不正な埋め込み（クリックジャッキング攻撃）から守るために非常に重要だと言うことなので、こちらも有効になっているか確認します
「/etc/httpd/conf.modules.d/00-base.conf」に、mod_headers.soの記載があればモジュールは入っています

cat /etc/httpd/conf.modules.d/00-base.conf | grep mod_headers.so

次に、「/etc/httpd/conf/httpd.conf」の最後に、
「 Header append X-FRAME-OPTIONS “SAMEORIGIN” 」
を追加して、apacheを再起動します

sudo vi /etc/httpd/conf/httpd.conf

・
・
##--- kazuban added. 2026/04/19
ServerTokens ProductOnly
ServerSignature off
TraceEnable off

Header append X-FRAME-OPTIONS "SAMEORIGIN"

sudo systemctl restart httpd
sudo systemctl status httpd

ドキュメントルートのトップページの表示

上記セキュリティ対策でトップページが表示されなくなったので、「index.html」を作成し、簡単な表示が出るようにしておきます。

cd /home/www/html/
cat <<EOF | sudo tee index.html
<html>
  <body>
    <h1>This website is currently under maintenance.</h1>
  </body>
</html>
EOF
sudo chown apache:apache ./index.html
httpd -t
sudo systemctl restart httpd

これで、「http://192.168.*.*」でトップページが表示されるようになりました

Let’s Encrypt証明書でhttps化

https化を行う場合には、ファイヤーウォールでの許可が必要ですが、上記ですでに許可してますから、ここでは確認だけ行います

sudo firewall-cmd --list-all --zone=public

「services: 」に「https」があれば、許可済みです

sslモジュール

「mod_ssl」も、上記でインストールされています、確認してみます

dnf list installed | grep mod_ssl
httpd -M | grep ssl

Certbot クライアントのインストール

Let’s Encryptで証明書の取得には、「Certbot」と言うソフトを利用します
パッケージの状態を確認します

dnf list --all | grep certbot

複数でてきますが、「certbot.noarch」「python3-certbot-apache.noarch」をインストールします

sudo dnf install certbot
sudo dnf install python3-certbot-apache
dnf list installed | grep certbot

証明書発行

すでにhttpdが動作している場合には、「webroot プラグイン」を使います
動作していない場合には、「Standaloneプラグイン」を使います
ただし、両方とも外部から対象のPCの80番ポートへ通信は必要です
したがって、外部（インターネット側）から、対象のドメインのが名前解決が必要です
私は、無料のサービスhttps://www.mydns.jp/　を利用させてもらっています
80番ポートは「Standalone」の場合は、certbot が占有します
「webroot」は、apacheが使います
したがって、「webroot」はwebサーバーが動作している必要がありますが、「Standalone」では停止しておく必要があります

まず、外部からの80番へのリクエストが、対象のPCアドレスへ転送されるように設定します
自宅であれば、ルーターの「ポートマッピング」などの項目で設定できると思います
次に、httpdの起動状態を確認

sudo systemctl status httpd

80番と、httpdの起動が確認できたら、certbot を起動しましょう
確認はしていませんが、権限が必要なファイルに書き込むので、「su」での起動がいいと思います

su
certbot certonly --webroot -w /home/www/html/ -d www2.hogehoge.com -d hogehoge.com

対話での設定になります

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): 　　　　　<------自分のEメールアドレスを入力

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
 https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y　<----- 利用規約を読んでください

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y  <--------- 電子フロンティア財団からEメールが届いてもいいか？
Account registered.
Requesting a certificate for www2.hogehoge.com and hogehoge.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/www2.hogehoge.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/www2.hogehoge.com/privkey.pem
This certificate expires on 2026-07-18.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

「Successfully」になれば、証明書ファイルは保管されています

証明書の設定

証明書を「/etc/httpd/conf.d/ssl.conf」で反映させます
まずは、バックアップをとってから、編集します

cd /etc/httpd/conf.d
sudo cp -p ssl.conf ssl.conf.org
sudo vi ./ssl.conf

/etc/httpd/conf.d/ssl.conf

・
#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile /etc/letsencrypt/live/www2.hogehoge.com/fullchain.pem       
・
・
#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/letsencrypt/live/www2.hogehoge.com/privkey.pem
・

保存後、確認でOKなら、httpd再起動

sudo httpd -t
sudo systemctl restart httpd
sudo systemctl status httpd

https:// でのアクセス確認

証明書発行では80番ポーとを通しましたが、httpsでは443ポートを通してておきます
ただし、筆者の環境のように、同じLAN上にWebサーバーとアクセスPCがある場合には外部DNSを使用しないので、アクセスできない場合があります
その場合、アクセス側PCの「hosts」ファイルで設定しておくと可能になります

C:\Windows\System32\drivers\etc\hosts　(windows)

#Server 
192.168.1.100 hogehoge.com
192.168.1.100 www.hogehoge.com

#TestServer
192.168.1.101 www2.hogehoge.com

この設定後、「https://www2.hogehoge.com」で正常に「index.html」画面が表示されれば証明書は正常です

HTTP/2を利用する

詳細は、こちらを確認してください
まず、eventMPMモジュールとhttp2モジュールが必要ですが、Rocky9では、デフォルトで有効になっているようです。
確認してみます

sudo httpd -M | grep mpm
sudo httpd -M | grep http2

次に、「httpd.conf」で有効設定する予定ですが、設定前にhttp2の有効状態を確認してみました
確認は、Chromeで「https://www2.hogehoge.com」を表示後、F12キーで表示される開発ページの「Network」「Protocol」で確認できますが、筆者の環境ではすでに「h2」になっていて、http2が有効になっていました。
AIに聞いてみると、Apacheのバージョンによっては、有効になっている場合もあるが、明示的に設定をいれる事を推奨するの事なので、設定はしておこうと思います

設定は、「/etc/httpd/conf/httpd.conf」で行います

sudo vi /etc/httpd/conf/httpd.conf

最終行に追加して、httpdを再起動

・
<IfModule http2_module>
    Protocols h2 http/1.1
    ProtocolsHonorOrder on
</IfModule>
・

sudo systemctl restart httpd

HTTP/2有効確認

Chromeで「https://www2.hogehoge.com」を表示後、F12キーで表示される開発ページの「Network」「Protocol」で確認できますが、「Protocol」が表示されていない場合があります
・開発ページが表示された後、CTRL+R でページを更新
・もし、翻訳のダイアログが出た場合には、「日本語」にしてみます

・開発ページが更新されても、デフォルトでは「Protocol」が非表示になっている場合があります
・「Network」タブの、「Name」セル上でマウス右ボタンで、表示項目の選択ができるので「Protocol」をチェックする事で、表示されます

・表示された「Protocol」が、「h2」や「h3」になっていれば、HTTP/2で応答しています

WordPress環境構築まとめ

Ubuntu24.04LTSでWorrPressを動作させる。インストール・SSH・ファイヤーウォール

「Ubuntu24.04LTS」に、「RHEL系、RockyLinux9」と同様の設定で、「WordPress」を動作させます。 特に、「apache」の設定方法が違っているので戸惑いました。 「RHEL」から移行の方には参考になると思います。

www.kazuban.com

2024.06.29

会社でもローカル環境にwordpressでのコミュニティサイトを検討しているので、wordpress環境構築作業に戸惑わないよう、コピペできるよう、まとめました。
せっかくなので、RockyLinux10で試してみましたが、筆者の１０数年前のノートPCではインストーラさえ起動しませんでした
RockyLinux9.7であれば起動したので、クリーンインストールして再構築しました

RockyLinux9.7 ダウンロード・インストール

ダウンロード・インストールの詳細はこちらを確認してください

RockyLinux9.3で自宅サーバーを再構築V01・インストール。記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

2023年、このサイトは、centOS7 で構築していますが、サポート終了が近づいてきました。 centOS8のサポートも既に終了しています。 今回、RockyLinux9.3で再構築した記録のインストール編です。 記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

www.kazuban.com

2024.01.05

有線デバイスを認識しない

wifiを利用していたので、あまり意識しませんでしたが、wifiでのトラブルがあったので、有線LANを利用しようとしましたが、認識しない状況になりました。
AIに聞きながらどうにか解決したので、ここに覚書としてメモしておきます

インターフェースの確認:

nmcli device

通常、正常であればここに enp... や eth0 といった名称のデバイスが表示されますが
リストに出てきませんでした。
AIに相談すると

リストにないということは、設定の問題ではなく「ドライバが読み込まれていない」か「ハードウェアが認識されていない」可能性が極めて高いです。
次の結果を教えてください

lspci -nn | grep -i net

$ lspci -nn | grep -i net

08:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)

09:00.0 Ethernet controller [0200]: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] (rev 05)

原因が特定できました。搭載されている有線LANコントローラー 「JMicron JMC250 [197b:0250]」 は、Rocky Linux 9 (RHEL 9) の標準カーネルではサポート（ドライバが同梱）されていません。

JMicron用ドライバのインストール

JMicron JMC250 [197b:0250]」 は、ELRepo リポジトリからドライバを提案してもらいましたが、結局、Rocky Linux 9 (EL9) 用には JMicron [197b:0250] のドライバが提供されていない ようです

「ELRepo-kernel」から最新カーネルを試す（成功率：中）

成功率は「中」ですが、新しいカーネルには、稀に古いドライバが復活していたり、汎用ドライバで動く可能性があるとの事なので、やってみます

# 最新カーネルのインストール
sudo dnf --enablerepo=elrepo-kernel install kernel-ml

# 再起動して、起動メニューで新しいカーネル（数字が大きい方）を選択
sudo reboot

再起動後に nmcli device を確認

nmcli device

DEVICE          TYPE      STATE            CONNECTION     
wlp8s0          wifi      接続済み         aterm-e41133-g 
lo              loopback  接続済み (外部)  lo             
enp9s0f0        ethernet  切断済み         --             

認識されました

ethernetデバイスを接続する

接続は「nmcli device connect デバイス名」で接続できます

sudo nmcli device connect enp9s0f0

その他、ネットワーク設定は、下記を参考にしてください

RockyLinux9.3で自宅サーバーを再構築V01・インストール。記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

2023年、このサイトは、centOS7 で構築していますが、サポート終了が近づいてきました。 centOS8のサポートも既に終了しています。 今回、RockyLinux9.3で再構築した記録のインストール編です。 記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

www.kazuban.com

2024.01.05

インストール直後の設定

ホームディレクトリの日本語表記を英語表記に変更

linux

LANG=C xdg-user-dirs-gtk-update

特定のユーザーにsudo を可能にする

linux

su
visudo

visudo で、コメント行になっている、下記の「#」を外し有効にします
%wheel ALL=(ALL) NOPASSWD: ALL

linux

・
・
## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

・
## Same thing without a password
%wheel  ALL=(ALL)       NOPASSWD: ALL

その後、特定ユーザーを、「wheel」グループに追加すればそのユーザーはパスワードなしで「sudo」実行が可能になります

linux

usermod -aG wheel hogehoge

SSH利用状況の確認

RockyLinux9では、ほとんどの選択でsshは自動起動している状態になっています。
動作は、「ssh」コマンドで確認できます

linux

ssh

usage: ssh [・・・・」のような
コマンドの使い方を示すヘルプメッセージが表示されれば動作しています
また、sshサービスはファイヤーウォールでの制限対象ですが、こちらも標準では許可されていますが、確認しておきます
詳細は、下記記事を参照してください

RockyLinux9.３で自宅サーバーを再構築V03・firewalldでアクセス制御

firewalldを少し詳しく調べていました。 一例として、sshサービスを、LAN内（指定アドレス）からのみ接続可能な設定にしました。

www.kazuban.com

2024.01.06

ここでは、sshの許可状態だけ確認します

firewalldでのsshの確認

まず、「firewalld」の起動状態を確認してみます

linux

systemctl status firewalld

これで、active (running)になっていれば、起動しています

ファイヤーウォールのアクセスルール対象となるのはアクティブゾーンになります
まずは、アクティブゾーンを確認します

linux

 sudo firewall-cmd --get-active-zones

public
  interfaces: wlp8s0

アクティブゾーンは「public」のみと言うのがわかりました
今回は「ssh」の許可状態は「public」の設定で確認すればわかります

linux

sudo firewall-cmd --list-all --zone=public

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp8s0
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 

「services」に、「ssh」があるので、許可されています

SSHでリモート操作

上で確かめたように、RockyLinux9では、デフォルトでsshサービスもファイヤーウォールでの許可も利用可能な状態になっています。
「ssh」コマンドでアクセスしてみましょう。
windowslinux

ssh hogehoge@192.168.*.* -p 22

ssh 「Linux側のユーザー@IPアドレス」 でパスワード入力で接続できます
「-p 22」は、ポート番号指定です。sshはデフォルトでは２２番ポートです。
デフォルトであれば、省略できます。
「-p 22」はオプションですが、違うポート番号の場合は、その番号を指定します。
また以前ポート番号などを変更していたなどで接続できない事もあります
その場合には、標準ポート番号「22」を指定する事で接続できるようになります
windowsターミナルでも同じコマンドです
接続ができれば、windowsから、Linuxマシンを殆どリモートで設定できます　
ローカル内だけでの運用であれば、この設定でもいいかもしれませんが、後ほどポート番号変更と鍵認証方式に変更しようと思います

インストール後の設定２（SSHでも可）

まずは、パッケージのアップデート

sshアクセスができれば、windowsターミナルからでも操作できまます
インストール初期のアップデートで、依存関係の競合とかでエラーが表示される事があります
エラーメッセージでは、「--skip-broken」の付加のアドバイスが出ますが、ついでに「–allowerasing」オプションも追加したほうがいいようです

linux

sudo dnf update --skip-broken --allowerasing
sudo reboot

SELinuxに強制させない設定

SELinuxはセキュリティをより強固にする機能で、RockyLinuxなどRedHat系では標準で有効になっていますが、思うように動作しないトラブルも多いようです。
ポリシーを読み込まず、無効的な状態にする方法もありますが、警告のみでポリシーを強制しない「Permissiveモード」に設定にしようと思います

linux

su
vi /etc/selinux/config

editor

・
・
#SELINUX=enforcing
SELINUX=permissive
・
・

linux

reboot

再起動後、確認

linux

sudo getenforce

「Permissive」が返ってくれば、設定されています

設定中に本体のGUIがクラッシュした

外部PCからsshで操作していて、たまに戻ると、画面がクラッシュしている場合があります
これはGUIのディスプレイマネージャー（gdm）がロックやスリープ状態になっているか、セッションがクラッシュしている場合に起こるようです

復旧方法：キーボードショートカットで復旧

私の状況は、マウスカーソルだけが動く状態だったので、その画面で：

• Ctrl + Alt + F2（または F3〜F6）を押す → テキストコンソールに切り替え
• ログイン後、以下を実行：

linux

systemctl restart gdm

Ctrl + Alt + F1（または F7）でGUI画面に戻る

恒久対策として：スリープ・省電力設定を無効化する

linux

# GNOMEのスクリーンセーバー・自動サスペンドを無効化
sudo -u ユーザー名 gsettings set org.gnome.desktop.screensaver lock-enabled false
sudo -u ユーザー名 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

このコマンドは、私の環境でSSH経由では、X11のDISPLAY環境変数がないとのエラーになりました
ssh経由の場合には、DISPLAY変数を指定して実行します

ssh

sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings set org.gnome.desktop.screensaver lock-enabled false
sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

確認方法

linux

sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings get org.gnome.desktop.screensaver lock-enabled
sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type

下記の結果がでれば、正常に反映されている

false
'nothing'

CUIモードをデフォルトにする

SSH経由でのリモートがほとんどになれば、CUIモードのほうがトラブルは少なそうなので、CUIモードに設定します

linux

sudo systemctl set-default multi-user.target

これで、再起動後はGUIなしで起動します。
もし、GUIが必要になったら、

linux

sudo systemctl start gdm

再度GDMを停止させCUIに戻るには、サーバー機で操作できる場合には

Ctrl + Alt + F2

または、リモートも含めたコマンド操作の場合は

sudo systemctl stop gdm

このコマンド操作で、画面が止まったように見える場合は、サーバー機で

上記の Ctrl + Alt + F2

SSHのセキュリティ向上対策

SSHを鍵認証方式で運用

「鍵認証方式」は、「秘密鍵」と「公開鍵」のペアの鍵を作成し、アクセスする側は「秘密鍵」が必要になり、アクセスされる（サーバー）側には、「公開鍵」を登録します
一般的には、アクセス側で鍵を生成し、「公開鍵」の登録をサーバーへお願いします
鍵生成は、windowsでもLinuxでも、「ssh-keygen」コマンドで生成できます
今回は、windowsターミナルで生成します

windowslinux

ssh-keygen -t ed25519

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\hogehoge/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again
Your identification has been saved in C:\Users\hogehoge/.ssh/id_ed25519
Your public key has been saved in C:\Users\hogehoge/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:o2ojnUu7UflR12VZq2yOcTY/Ky-VzibafGh/PJbPe6C hogehoge@hoge-Pc
The key's randomart image is:
+--[ED25519 256]--+
|             .+.o|
|               Oo|
|     o + o .   . |
|    . Z   . . o..|
|    . o     . *AC|
+----[SHA256]-----+

秘密鍵のアクセス権限を厳しく設定

下記のアクセス権の設定は、windowsターミナルでの操作コマンドです。
Linuxでの操作は、こららを参考にしてください

継承の無効化と権限のクリア

windows

icacls "$HOME\.ssh\id_ed25519" /inheritance:r

ユーザーにのみ読み取り権限を付与

windows

icacls "$HOME\.ssh\id_ed25519" /grant:r "$($env:USERNAME):R"

「自分自身」以外のユーザー権限を削除

windows

icacls "$HOME\.ssh\id_ed25519" /remove "SYSTEM"
icacls "$HOME\.ssh\id_ed25519" /remove "Administrators"
icacls "$HOME\.ssh\id_ed25519"

エクスプローラの「プロパティ」⇒「セキュリティ」でも確認できます

公開鍵をサーバー側へコピー

作成した、「id_ed25519.pub」をサーバー側ユーザーの「.ssh」ディレクトリへコピー
・windowsの自分自身のホームの「.ssh」に移動
・scp コマンドへ、サーバー側ユーザーの「.ssh」へコピー

windows

cd $HOME\.ssh
scp .\id_ed25519.pub hogehoge@192.168.*.*:.ssh

サーバー側へsshでログインし操作

windows側から、sshログインし、「.ssh」ディレクトリへ移動し確認

windows

ssh hogehoge@192.168.*.*

ログイン後、コピーされているか、確認

sshlinux

cd ./.ssh
ls -la

公開鍵を保存ファイル（authorized_keys）へ登録

コピーされた公開鍵を、保存用のファイルへ登録し、そのファイルのアクセス権は厳しくします
持ってきて、公開鍵は削除しておきます

sshlinux

cd ~/.ssh 
cat id_ed25519.pub >> authorized_keys 
chmod 600 authorized_keys
rm id_ed25519.pub
exit

再度、鍵を使って、SSHログイン

ssh に「i」オプションで鍵指定

windows

ssh -i .ssh/id_ed25519 hogehoge@192.168.*.*

ログイン時、鍵生成時登録したパスフレーズを入力し、ログイン

鍵認証以外ではログイン拒否

鍵を使ってのログインが確認できたら、鍵以外でのログインは拒否する設定をしておきます
設定は、「/etc/ssh/sshd_config」ファイルの”PasswordAuthentication”を”no”に設定します
まずは、ファイルをバックアップして、編集します

ssh linux

sudo cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org
sudo vi /etc/ssh/sshd_config

editor

・
・
#PasswordAuthentication yes
PasswordAuthentication no
・
・

ついでにリモートからのROOTログインも拒否設定します

「/etc/ssh/sshd_config」ファイルの”PermitRootLogin”も”no”に設定

editor

・
・
#PermitRootLogin prohibit-password
PermitRootLogin no
・
・

さらに、ポート番号を変更

「ssh」のポートは「22番」が標準なので、自動スキャンなどのアタックが増えるので、違う番号に変更しておきます。
ポート番号も「/etc/ssh/sshd_config」ファイルの”Port”で設定します
ポート番号は登録済み番号などもあるので、49152–65535の範囲に設定します

editor

・
・
#Port 22
Port 55522
・
・

「22番」は「ssh」サービスのデフォルトなので、firewalldの設定でsshは「22番」になります
firewalld設定は、ポート番号を直接設定する事もできますが、やはりsshのポート番号を変更する方法がfirewalldは再起動だけで、設定は不要なのでスマートだと思います
デフォルト設定は、「 /usr/lib/firewalld/services/ ssh.xml 」に保存されているので、
そのファイルを「 /etc/firewalld/services /」にコピーして編集します。

ssh linux

sudo cp -p /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/
sudo cd /etc/firewalld/services/
sudo ls /etc/firewalld/services/
sudo vi /etc/firewalld/services/ssh.xml

editor

・
・
<port protocol="tcp" port="22"/>
↓
<port protocol="tcp" port="55522"/>
・
・

sshとfirewall　サービスを再起動して、アクセスにはポート番号を明示します

ssh linux

sudo systemctl reload sshd.service
sudo firewall-cmd --reload
ssh  -p 55522 hogehoge@192.168.*.*

ここまでで、RockyLinux9.7のインストールと、やっておきたい初期設定を解説しました
「ssh」の設定も完了しているので、windowsターミナルからでも実行できます

WordPress環境構築まとめ

RockyLinux9.３で自宅サーバーを再構築V08・postfix で送信専用メールサーバー構築

このサイトには「お問い合わせフォーム」を設定していますし、起動しているサーバーがエラーなどの連絡を発信する場合もあります。 重要なメールもあるので、メインのメールアドレスへ配信させる設定を行います。 今回は、サーバー側から、配信するのみの設定を行います

www.kazuban.com

2024.01.08

この設定により、このブログサイトへの、「お問い合わせ」も設置できているのですが、この不具合では、「お問い合わせ」もこちらに届きません
う～ん、困った。

こんな時ほど、Aiに相談だぁ！

最初は、ググってみましたが、なかなか的確なサイトにぶち当たりません。
Aiに聞いてみよう！
ChatGPT と Gemini 2.5Flash に同じ質問をしてみましたが、ほぼ同じ回答内容でしたが
ChatGPTのほうが、みやすく感じます
ただ、ChatGPTは次から次に、逆質問をしてくるのが、ちょっとウザいかも・・・

rocky linux9 で自宅サーバーを運用していますが、2025/10月からサーバーからのメールが送信できなくなりました sudo cat /var/log/maillog | grep -i error を実行してみると、下記エラーがでます。原因はなんでしょう？
sudo cat /var/log/maillog | grep -i error
（エラー内容）
・
・

それにしても、エラー内容をそのまま突っ込めるのは、今までの検索では考えられないですね。

Aiのエラー内容の整理

ログのエラー内容を整理すると：
Postfix が プロバイダ のメールサーバ (mx.hogehoge.com) に TCP ポート 25 で接続しようとしてタイムアウトしています。

主な原因候補

１０月からであれば、原因とは考えにくいですが・・・
Rocky Linux の firewalld やルーターで 25番ポートのアウトバウンドが塞がれた可能性。

プロバイダ側のポート25ブロック
2025年現在、多くの ISP（特に家庭向け回線）はスパム対策のため ポート25を塞いでいる ことが多いです。
それまでは通っていたけど、2025年10月から「送信ポリシー変更」でブロックされた可能性があります。

プロバイダ 側の受信制限
プロバイダ の受信サーバが外部からの直接SMTPを拒否するようになった可能性があります。

ファイアウォール / サーバ側の設定
個人宅サーバからの直接送信を受け付けない運用に切り替えた可能性。

確認方法

自宅サーバーからプロバイダメールサーバーへ直接接続できるか試す

telnet mx.hogehoge.com 25

もしタイムアウトするなら → 回線側（ISPやプロバイダ）で遮断。
もし「220〜」の応答があれば → Postfixの設定やファイアウォールの問題。

結果、telnet mx.hogehoge.com 25 が応答なし（タイムアウト）でした。
ということは、サーバー側(Postfix)の問題ではなく、回線側で25番ポートがブロックされている可能性が非常に高いと言うことのようです。

状況まとめ

• 以前は送れた → 2025年10月から送れなくなった
• ログでは「Connection timed out」
• telnet も通らない

👉 これは「ISP（プロバイダ 側）が 自宅回線からの直接25番SMTP送信を禁止 に切り替えた」ケースに一致します。
最近は迷惑メール対策で家庭向け回線ではほぼ標準でブロックされます。

解決方法

１．プロバイダのメールサーバ経由（SMTPリレー / smarthost）
　・Postfix の relayhost 設定でプロバイダの SMTP サーバ（587 or 465ポート）を使う
２．外部のメールリレーサービスを利用
　・SendGrid, Gmail SMTP relay, AWS SES など
３．自宅サーバではなく VPS 経由で送信
　・自宅サーバからVPSへ転送して、VPSから外へ送信。

解決策（おすすめ）

プロバイダのSMTPサーバを経由する（最も現実的）

Postfix で 「スマートホスト」設定をして、smtp.hogehoge.com:587 経由で送信するのがベストです。（25番ではなく 587 番（Submission ポート）がベスト）

まずは、 外部からの直接配送(mx) ではなく、 認証付きの送信サーバ(smtp) なら接続できるかの確認

telnet smtp.hogehoge.com 25
telnet smtp.hogehoge.com 587

結果、両方とも接続できました
telnet smtp.hogehoge.com 587
Trying 000.000.000.0… Connected to smtp.hogehoge.com. Escape character is ‘^]’.
220 hogehoge.com ESMTP server ready Sat, 4 Oct 2025 15:42:22 +0900

整理すると

mx.hogehoge.com:25 → タイムアウト（接続できない）
smtp.hogehoge.com:25 → 接続できる（220応答あり）
smtp.hogehoge.com:587 → 接続できる（220応答あり）
つまり：
プロバイダ は 外部からの直接配送(mx) を制限している
代わりに 認証付きの送信サーバ(smtp) なら 25 でも 587 でも受け付けている
じゃあどっちを使うべき？
587（submission ポート） が推奨です（標準仕様で「認証あり専用の送信ポート」）
25番で smtp.nifty.com に直接送ることもできますが、将来的にブロックされる可能性が高いです。
なので、Postfixの relayhost を smtp.hogehoge.com:587 にして、SMTP認証を通す設定がベストです。

設定方法

認証情報ファイルを作成

/etc/postfix/sasl_passwd　ファイルを作成し、アドレスとパスワードを追記：
「プロバイダのメールアドレス」：「アドレスパスワード」

[smtp.hogehoge.com]:587 myaddress@hogehoge.com:mypasswd

Postfix設定ファイルを修正

/etc/postfix/main.cf の末尾あたりに下記追記：

# hogehoge の SMTP サーバをリレーに指定
relayhost = [smtp.hogehoge.com]:587

# SMTP認証を有効化
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

# TLS を使用
smtp_use_tls = yes
smtp_tls_security_level = may
smtp_tls_note_starttls_offer = yes

ハッシュ化して権限設定

sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd*

Postfix再起動

sudo systemctl restart postfix

テスト送信

echo "This is a test mail" | mail -s "Postfix smtp test" myaddress@hogehoge.com

確認

/var/log/maillog を確認して、status=sent になれば成功

後日、Gmailへの転送がNGになった

後日、バックアップサーバーの立ち上げをやっていて、GmailへのテストメールがNGになった

 echo "This is a test mail to gmail" | mail -s "Postfix smtp test2" hogehoge@gmail.com

ここも、AIに聞いてみる

Gmailで該当メールを開いて 「︙」→「メッセージのソースを表示」 し、以下の行を確認してみてください：

Authentication-Results: mx.google.com;
   spf=pass  ← ここがfailだとアウト
   dkim=pass ← ここがfailだとアウト

その結果を教えてもらえれば、どこが問題か特定できます！

Authentication-Results: nifty.com;
    dmarc=none header.from=kazuban.com;
    dkim=none;
    spf=fail smtp.mailfrom=kazuban.com;
    sender-id=Fail (pra) header.From=kazuban.com

原因が明確になりました！

AIが問題点指摘

spf=fail → kazuban.com のDNSにSPFレコードがないか、Niftyのサーバーが許可されていないNiftyのSMTP経由で送っているのに、Fromアドレスが @kazuban.com なので、
「kazuban.comのSPF的にNiftyは許可されてないよ」とGmailに判断されています。

A. kazuban.com のDNSにSPFレコードを追加（推奨）

種別     ホスト名          内容
TXT      @ （または空欄）  v=spf1 include:nifty.com ~all

設定後、反映に数分〜数時間かかる場合があります。確認コマンドはこちら：

dig TXT kazuban.com | grep spf

v=spf1 include:nifty.com ~all が表示されれば成功です。

正常にもどった

いまさらですが、Aiはすごいですね
ちょっと前までは、プロンプトが重要とか言われていましたが、最近ではあまり感じません
普通に個人の言葉で、質問すれば、かなり理解してくれます
もしかすると、サポート会社などへ、電話質問するよりも簡単かもしれません
理解力と分析力は、はるかに人間を超えているように思います

Difyをクローン化

gitの確認

difyをクローン化するのに、「git」を利用するので、「git」のインストール状況を確認します。
windows ターミナルを開き、wsl を起動し、「git -v」で状況を確認します。

PS C:\Users\hogehoge2> wsl

$ git -v
git version 2.43.0
インストールされていない場合には、インストール
$ sudo apt update
$ sudo apt install git

Gitでdifyをクローン化する

「git clone ・・」でクローン化を実行すると、カレントディレクト下「dify」ディレクトリへソースコードがクローン化されます。
windowsターミナルで、「wsl」を実行し、ubuntu環境へ入ると、デフォルトでは、winndowsユーザーのディレクトリへセットされた状態で起動します。
好みの問題だと思いますが、この場所へ「dify」環境を作成してもいいと思いますが、筆者はubuntuのユーザーホームディレクトリ下に作成しようと思います。
wsl、ubuntuプロンプトで、「cd」を実行すると、ユーザーのホームディレクトリへ移動します。
その場所で「git clone・・」すると、そのディレクトリ直下に「dify」さらにその下に「docker」ディレクトリが作成されています。
「ls」コマンドで確認できます。
「dify/docker」ディレクトリへ「cd」コマンドで移動しておきます。
「pwd」コマンドで、現在のディレクトリが確認できます。

hogehoge2@hoge-PC:/mnt/c/Users/hogehoge2$
$ cd
$ git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 153846, done.
remote: Counting objects: 100% (536/536), done.
remote: Compressing objects: 100% (359/359), done.
remote: Total 153846 (delta 396), reused 178 (delta 177), pack-reused 153310 (from 3)
Receiving objects: 100% (153846/153846), 87.73 MiB | 5.07 MiB/s, done.
Resolving deltas: 100% (111131/111131), done.
$ ls
dify
$ cd dify/docker/
$ pwd
/home/hogehoge2/dify/docker

Difyコンテナ起動

「git clone」を実行したディレクトリに、「dify/docker」ディレクトリが作成されています。
その中に「.env.example」のサンプル環境変数ファイルが作成されています。
通常ファイルは「ls」コマンドで確認できますが。「.」で始まるファイルは表示されません。
その場合「ls -la」コマンドを実行すると、表示されます。
コピーは「cp <オリジナルファイル名>　<複写ファイル名>」で複写できます。
「.env.example」ファイルを、正式な環境変数「.env」としてコピーし、「docker compose」コマンドで、コンテナを起動させます。

$ pwd
/home/hogehoge2/dify/docker
$ cp .env.example .env
$ docker compose up -d
[+] Running 80/80    
✔ web Pulled             149.7s
✔ sandbox Pulled         221.1s
 ✔ ssrf_proxy Pulled      88.2s
 ✔ db Pulled             224.4s
 ✔ worker Pulled         402.2s
 ✔ plugin_daemon Pulled  404.6s
 ✔ nginx Pulled           36.4s
 ✔ weaviate Pulled       225.1s
 ✔ redis Pulled          221.2s
 ✔ api Pulled            402.2s
[+] Running 12/12
 ✔ Network docker_default             Created    0.1s
 ✔ Network docker_ssrf_proxy_network  Created    0.0s
 ✔ Container docker-web-1             Started    3.7s
 ✔ Container docker-ssrf_proxy-1      Started    4.0s
 ✔ Container docker-sandbox-1         Started    3.7s
 ✔ Container docker-redis-1           Started    3.7s
 ✔ Container docker-weaviate-1        Started    3.7s
 ✔ Container docker-db-1              Healthy    10.7s
 ✔ Container docker-worker-1          Started    9.3s
 ✔ Container docker-plugin_daemon-1   Started    9.3s
 ✔ Container docker-api-1             Started    9.5s
 ✔ Container docker-nginx-1           Started    10.0s

docker compose upでエラー発生！AIに聞いてみる。

上記は正常な例ですが、古いPCをテストマシンとして利用した時、「docker compose up」で下記エラーがでた事がありました。

dependency failed to start: container docker-db-1 is unhealthy

この時もgeminiに聞いてみたところ、「docker logs docker-db-1」でログを確認してくれとの事なので、ログを直接貼り付けると、

Ai

ログを見る限り、データベースの初期化自体は正常に完了しています (PostgreSQL init process complete; ready for start up.)。 その後の起動プロセスも進んでいますが、2025-04-29 00:02:07.998 UTC [557] FATAL: the database system is starting up という致命的なエラーが出力されています。

このエラーは、PostgreSQLサーバーが起動してリカバリなどの内部処理を行っている最中に、外部からの接続要求（この場合はおそらくDockerのヘルスチェックや、依存するDifyコンテナからの初期接続試行）があった場合に発生することがあります。

つまり、データベースサーバー自体は最終的に database system is ready to accept connections の状態になりますが、Dockerのヘルスチェックがサーバーの準備が完全に整う前に接続を試み、上記の FATAL エラーを受け取ってしまい、それが原因でコンテナが unhealthy と判定されている可能性が高いです。

解決策:

Dockerのヘルスチェック設定を調整し、データベースが完全に起動して接続可能になるまで、チェックを待つように設定を変更するのが最も有効な対策です。

データベースサービス (db または postgresql) の healthcheck 設定を見つける:
services のセクションにある、データベースコンテナに対応するサービス定義（通常は db という名前）を探します。その中に healthcheck というブロックがあるはずです。

YAML
services:

db: # ... その他の設定 ...
healthcheck: # ここに設定があります
　　・
test: ["CMD-EXEC", "pg_isready -U <db_user> -d <db_name>"] # 例
interval: 10s
timeout: 5s
retries: 5
start_period: 30s # <-- この値を調整します

docker-compose.yml を開く: Difyを起動するために使用している docker-compose.yml ファイルをテキストエディタで開きます。

じじぃ

docker-compose.yamlを確認した所、「start_period:」の設定がありません。

Ai

start_period が指定されていない場合、コンテナが起動を開始すると同時にヘルスチェックが始まります。今回のデータベースのログで見たように、起動直後の一時的な準備期間中に接続を試みると FATAL: the database system is starting up のようなエラーが発生することがあります。

interval: 1s と非常に短い間隔でチェックが実行されるため、データベースが完全に準備できる前に多くのチェックが走ってしまい、すぐにリトライ回数（retries: 60）を使い果たして unhealthy と判定されてしまう可能性が高いです。

解決策:

start_period を追加し、必要に応じて interval も調整しましょう。

1. healthcheck 設定に start_period を追加する: データベースが起動して準備ができるまでの猶予期間として、start_period を設定します。
   例えば 30s または 60s (30秒または60秒) を指定します。
   YAML
   services:
db: # ... その他の設定 ...

healthcheck:
test: [ 'CMD', 'pg_isready', '-h', 'db', '-U', '${PGUSER:-postgres}', '-d', '${POSTGRES_DB:-dify}' ]
interval: 5s # 例: 毎秒ではなく5秒ごとにチェックに緩和
timeout: 3s
retries: 10 # 例: リトライ回数を調整 (intervalを長くすればretriesは少なくても良い)
start_period: 60s # <- この行を追加 (例: 60秒待つ)
   
   ポイント: start_period の間は、ヘルスチェックが失敗してもコンテナは starting 状態のままとなり、unhealthy とは判定されません。start_period が経過した後に初めて、ヘルスチェックの失敗が unhealthy の判定に使われます。
2. interval も少し長めにすることをお勧めします: interval: 1s は開発時などに素早く確認したい場合には便利ですが、本番に近い環境や安定性を重視する場合は 5s や 10s に設定することが一般的です。これにより、データベースへの不要な負荷も軽減されます。
3. docker-compose.yml を保存する。
4. Docker Compose を再起動する: 変更を反映させるために、コンテナを再作成して起動します。

アドバイス通りに、編集して再度「docker compose up -d」を実行すると、正常になりました。
いやぁ～、AIさまさま、ですね～
おそらく、ネット検索では、解決できなかったと思います。
ただし、古いPCだったのが、一番の原因かもしれません。
５年ほど前のPCでは、このエラーはでなかったので、レアなケースかもしれませんが、AIの利用例として紹介しました。

Dify起動

初期画面

「docker compose up」が正常に終了すると、Webブラウザで「http://localhost/install」へアクセスすると「dify」の初期設定が開きます

Difyの動作と試用

とりあえず、起動しました。
以前このサイトでも説明していますが、簡単なチャットボットを作成し試してみます。
LLMモデルはオンラインの「gemini」を登録し、動作を確認できました。
オンラインであれば、「LM Studio」や「Ollama」など、ローカルLLMを利用するアプリは必要ないので、すぐに確認できます。

Difyを自動起動

Difyを動作させるには、Dockerが起動していなくてはいけません。
それには、WSL上で、ubuntuも起動している必要があります。
手動でやる場合、

・windowsターミナル起動
・wslコマンドで、ubuntuターミナル起動
・ubuntuターミナルでカレントディレクトリを、Difyのクローンディレクトリに移動
・「docker compose up -d」 コマンド実行

このような手順が必要ですが、問題なのは、ターミナルを閉じるとdockerも終了してしまうことです
Difyを使うには、dockerが起動していなくてはいけません。
windowsアプリの「docker desktop」であれば、標準で自動起動設定だったと思いますし、起動後もシステムトレイのアイコンで起動が確認できます。右ボタンで状態確認や終了も簡単です。
ubuntu経由の場合には、GUIでの確認ができないので、ここが面倒なところですね～。
自動起動方法をいろいろ調べると、windowsバッチファイルを作成し、スタートアップフォルダに登録する事で、windows起動時に、自動起動できそうです。
ただ、
「コマンドプロンプト　⇒　ubuntuターミナル　⇒　docker」
のタスクが必要で、ターミナルは開いた状態にしておく必要があります。
このようなバッチファイルを作りたいですが、どんなコードにすればいいのか・・？
うまいコードを考え付かなかったので、difyの試しもかねて起動しているチャットボットで設定しているgeminiに考えてもらいました。

@echo off
title Starting Dify via WSL

echo Starting WSL and navigating to ~/dify/docker...
echo Running 'docker compose up -d'...
echo WSL window will remain open after commands.

REM WSLを起動し、bashシェル内でコマンドを実行します。
REM cd ~          : ホームディレクトリに移動 (念のため)
REM cd ./dify/docker : dify/docker ディレクトリに移動
REM docker compose up -d : docker compose をバックグラウンドで起動
REM exec bash     : 上記コマンド実行後、インタラクティブなbashシェルを開始して終了させない
wsl.exe -e bash -c "cd ~/dify/docker && docker compose up -d && echo '--- Dify containers started (or attempted to start) ---' && exec bash"

echo WSL window launched. This batch window can be closed if desired.
REM pause REM Optionally uncomment this line to keep the batch window open until a key is pressed

すごいです。
ほとんど実際の起動には影響がない「REM」や「echo」文がほとんどですが、
「REM」文を使っての説明文や、「echo」での実行中のメッセージにも手抜きがないですね！
このコードをコピーしてエディターで、「start_dify.bat」というファイルで保存しました。
バッチファイルの単独実行では問題ありませんでした。
後はこのファイルのショートカットを、スタートアップフォルダへコピーするだけです。

・上記の作成したバッチファイルを、適当は場所へ保存します
　私は、ユーザーフォルダ「C:\Users\「ユーザー」」へ保存しました。
・次に、このファイルのショートカットを作成します。
・このショートカットを「スタートアップフォルダ」へ保存します。
　スタートアップフォルダは、エクスプローラーのアドレスバーへ「shell:startup」と入力すると開くことができます。

特に必須ではないですが、ターミナルは起動状態にさせるので邪魔になる場合、作成したショートカットファイルを、マウス右ボタンで「プロパティ」を開きます。
「プロパティ」の「ショートカット」タブの「実行時の大きさ」を「最小化」に設定すると、起動時にタスクバーに最小化状態で起動できます。

これで、再起動すると、自動起動したターミナルはタスクバーへ最小化状態ですが、環境によっては起動途中の場合があるので、すぐに使用したい場合には、一度開いてDockerの状態を確認したほうがいいと思います。
正常に起動できると、Webブラウザのアドレスバーに「http://localhost/install」でdifyが起動できます。
場合によっては、「http://localhost/signin」にリダイレクトされる場合もあります

この画面が開くと、ローカルPCでは、Difyを利用する事ができますが、今回はサーバーとして利用したいので、LAN上の別のPCからのアクセスも必要です。

Difyをサーバー化して、他のPCからもアクセスさせる

同じLAN上であっても、「localhost」では、他のPCではアクセスできません。
前回後半で少し話題にしましたが、「windowsホスト」「WSL(ubuntu)」「Docker」と複雑な通信環境なので面倒です。

DifyPCのIPアドレス調査

IPアドレスは、windowsターミナルでは「ipconfig」コマンド
WSLターミナルでは、「ip addr」で確認できます。
この情報を、Aiに添付して聞いてみました。

Ai

詳細な情報ありがとうございます！ipconfig と ip a の結果から状況がより明確になりました。
原因の特定
・Windows ホスト:
　あなたの Windows PC の Wi-Fi アダプターには 192.168.0.94 という IP アドレスが割り当てられています。
　これはご自宅などの LAN 内の IP アドレスです。
・WSL (Ubuntu):
　Windows Subsystem for Linux (WSL) 環境内の Ubuntu には、eth0 インターフェースに 172.31.226.6 という IP アドレスが割り当てられています。
　これは WSL が使用する仮想ネットワーク内の IP アドレスです。

Ai

WSL2 環境で Docker コンテナを動かしている場合、Windows ホストからそのコンテナ内のサービスにアクセスするには、通常以下のいずれかのアドレスを使用します。
１．localhost:
　Windows ホストのブラウザで http://localhost/chat/…と入力する。
　WSL2 は localhost 経由でのポートフォワーディングをサポートしています。
　（これが最も一般的な方法です）
２．WSL の IP アドレス: http://172.31.226.6/chat/…
　(今回アクセスできている方法)

・http://192.168.0.94/chat/… でアクセスできないのは、WSL2 と Docker のネットワークアーキテクチャ上、自然なことです。
サービスが Windows ホストの物理的な IP アドレスに直接公開されているわけではないためです。
・もし、LAN 内の他の PC (例: 192.168.0.100) からもこの Dify 環境にアクセスしたい場合は、追加の設定が必要になる可能性があります:

１．Windows ファイアウォールの設定: Windows のファイアウォールで、外部からのポート 80 (または Dify が使用しているポート) への着信接続を許可する必要があります。
２．ポートフォワーディング (状況による): WSL2 のネットワーク設定によっては、Windows ホストの 192.168.0.94 のポート 80 へのアクセスを、WSL の 172.31.226.6 のポート 80 へ転送する設定が必要になる場合があります。
これは 「netsh interface portproxy」 コマンドなどで設定できますが、まずは localhost や WSL の IP でアクセスできることを確認するのが先決です。

要約:
・Windows ホストからアクセスする場合: http://localhost/chat/… または http://172.31.226.6/chat/… を使用してください。
・http://192.168.0.94/chat/… でアクセスできないのは仕様であり、問題ではありません。

Windowsのアドレスからは、アクセスできない。

じじぃ

http://localhost や http://172.31.226.6 からはアクセスできています。
今回は、LAN上の別のPCからhttp://192.168.0.94 にアクセスしたいため、自分PCで試したら、アクセスできませんでした

Ai

なるほど、LAN上の他のPCからアクセスできるようにしたい、ということですね。承知いたしました。

ご自身のPC (192.168.0.94) から http://192.168.0.94/chat/... にアクセスできなかったのは、まさにその設定がまだされていないためです。Windowsホストのネットワーク(192.168.0.x) と WSL内部のネットワーク (172.31.x.x) は分離されており、外部（LANを含む）から直接WSL内のサービスにアクセスするには、「ポートフォワーディング（ポート転送）」という設定が必要になります。

設定手順

以下の手順を管理者権限で実行してください。

1. Difyが使用しているポートを確認 (重要):
   • まず、DifyがWSL内でどのポート番号で待ち受けているか確認します。HTTPなので通常は 80番 ですが、Dockerの設定によっては異なるポート（例: 3000番など）がホスト(WSL)に公開されている場合があります。
   • Docker Composeを使っている場合は docker-compose.yml ファイルの ports: セクションを確認してください。例えば ports: - "80:80" や ports: - "3000:80" のようになっています。左側の数字がWSL側で公開されているポート番号です。
   • docker ps コマンドを実行しても確認できます。PORTS 列に 0.0.0.0:80->80/tcp や 0.0.0.0:3000->80/tcp のように表示されます。0.0.0.0: の後の数字がWSL側で公開されているポート番号です。
   • 以降の説明では、Difyがポート 80 を使用していると仮定します。もし異なるポート（例: 3000）だった場合は、コマンド内の 80 をその番号に読み替えてください。
2. Windows ファイアウォールでポートを開放:
   • LAN内の他のPCからのアクセスを許可するために、WindowsのファイアウォールでDifyが使用するポート（ここでは80番）を開ける必要があります。
   • 管理者としてPowerShellを開き、以下のコマンドを実行します。
     powershell New-NetFirewallRule -DisplayName "Allow Dify Access from LAN" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
     (もしコマンドプロンプトを使いたい場合は、管理者として開き netsh advfirewall firewall add rule name="Allow Dify Access from LAN" dir=in action=allow protocol=TCP localport=80 を実行)
3. ポートフォワーディングの設定:
   • Windowsホスト (192.168.0.94) のポート80に来た通信を、WSL (172.31.226.6) のポート80に転送するように設定します。
   • 管理者としてPowerShell（またはコマンドプロンプト）を開き、以下のコマンドを実行します。 powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6
     • listenport=80: Windows側で外部からの接続を待ち受けるポート番号。
     • listenaddress=0.0.0.0: Windowsの全てのIPアドレス（192.168.0.94 を含む）で待ち受ける設定。特定のIP (192.168.0.94) だけを指定することも可能です。
     • connectport=80: 転送先のWSL内でDifyが待ち受けているポート番号。
     • connectaddress=172.31.226.6: 転送先のWSLのIPアドレス。
4. 動作確認:
   • 設定後、まずご自身のPCのブラウザから http://192.168.0.94/chat/84aj9r6azPSYjXt8 にアクセスできるか試してください。 (ポートが80以外の場合は http://192.168.0.94:ポート番号/chat/... のように指定)
   • アクセスできれば、LAN内の他のPCからも同じアドレス (http://192.168.0.94/chat/...) でアクセスできるはずです。

注意点:

• WSLのIPアドレスの変動: WSLを再起動すると、WSLのIPアドレス (172.31.226.6) が変わる可能性があります。もしアクセスできなくなった場合は、ip a コマンドでWSLの新しいIPアドレスを確認し、手順3のポートフォワーディング設定を一度削除して再作成する必要があります。
  • 削除コマンド: netsh interface portproxy delete v4tov4 listenport=80 listenaddress=0.0.0.0
  • 再作成コマンド: (新しい connectaddress を指定して再度実行)
• 管理者権限: ファイアウォールとポートフォワーディングの設定には管理者権限が必要です。
• ポート番号: Difyが使用しているポート番号を正確に確認し、コマンド内の 80 を適宜修正してください。

この手順で、LAN内の他のPCからアクセスできるようになるはずです。試してみてください。

docker ps コマンドで実行中のコンテナーを提出

じじぃ

docker ps では下記になっています。
$ docker ps
・・
・
・

Ai

docker ps の出力結果、ありがとうございます。

コンテナ docker-nginx-1 の PORTS 列にご注目ください。

PORTS
0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp

これは、以下のことを意味しています。

• 0.0.0.0:80->80/tcp: WSLホスト（172.31.226.6 など）の ポート 80 (HTTP) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 80 に転送する。
• [::]:80->80/tcp: 上記のIPv6版。
• 0.0.0.0:443->443/tcp: WSLホストの ポート 443 (HTTPS) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 443 に転送する。
• [::]:443->443/tcp: 上記のIPv6版。

docker-web-1 コンテナ自体は内部的にポート 3000 を使っていますが、外部（WSLホスト）からのアクセスは docker-nginx-1 コンテナがポート 80 (HTTP) と 443 (HTTPS) で受け付けています。Nginx がリバースプロキシとして動作し、リクエストを docker-web-1 や docker-api-1 などに振り分けている構成です。

結論

あなたが LAN 上の他の PC からアクセスしたい HTTP のポート番号は 80 です。

したがって、先ほどのポートフォワーディング設定のコマンドは、ポート番号 80 を使って実行してください。

1. ファイアウォール開放 (ポート 80): New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
2. ポートフォワーディング設定 (ポート 80):
   powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

これで、 http://192.168.0.94 (ポート80は省略可能) でアクセスできるはずです。

もし将来的にHTTPS (https://192.168.0.94) でアクセスしたい場合は、同様にポート 443 用のファイアウォールルールとポートフォワーディング設定を追加する必要があります。

ファイヤーウォールとポートフォワーディング設定

ファイアウォールを開放し、ポートフォワーディング設定をしろ、のアドバイスです。
教わったコードを実行してみます。

１．ファイアウォール開放 (ポート 80):

PowerShell
PS C:\Users\hoge2>　New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow

コントロールパネル→システムとセキュリティ→windows Defender ファイアウォール→詳細設定
受信の規則で
コマンドで指定したAllow Dify Access from LAN(HTTP)が設定されているのが、確認できます。
コマンドではなく、この画面で、GUI設定する事もできます。

2．ポートフォワーディング設定 (ポート 80):

管理者権限のPowerShell の、「netsh」コマンドで設定します。

PowerShell（管理者）
PS C:\Users\hoge2> netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

「netsh interface portproxy show v4tov4」で確認できます。

PS C:\Users\hoge2> netsh interface portproxy show v4tov4
ipv4 をリッスンする:         ipv4 に接続する:
Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         80          172.31.226.6    80

アクセスできた～

これで無事に「http://192.168.0.94/instal」でアクセスできました。
LAN上の別のPCからも、アクセス確認できました。
おそらく、ネット検索では、ここまで的確なアドバイスを見つけるのは至難の業だと思います。
ちょっと前までは、言語生成AIをうまく使うには、プロンプトが重要だと言われていましたが、最近の言語生成AIはかなり言語の理解力が向上していると感じます。
上記のじじぃの質問でもわかりますが、ほとんど「プロンプト」など意識していません。
とにかくわからない事やPCからの出力を、自分の言葉で質問しているだけです。
それでもかなり的確な回答をくれます。
たまには、間違った回答もありますが、それでエラーが発生した場合、そのエラーやログをそのまま突っ込めば、新たな回答をくれます。
すごい時代になりました。

DifyにLLMを設定して、カスタムチャット環境を構築

やっとDifyサーバーが起動できました。

次に、このDifyにLLMモデルを設定することで、チャットボットをはじめカスタムLLMアプリを開発する事ができるようになります。
左図の例では、
一番上の「Gemini」はオンラインで公開されているLLMです。
二番目は、「LM Studio」でダウンロードしたローカルLLMです。
三番目は、「Ollama」で読み込んでいるローカルLLMです。
このように、「Dify」ではオンライン、ローカルあまり意識せず、使用するLLMを自由にカスタマイズできます。

DifyにLLMの設定方法

ネット上でも、多くの情報があると思いますが、このサイトでも以前の記事で紹介しています。

オンラインLLMの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。

LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。

www.kazuban.com

2025.03.23

LM Studio モデルの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。

LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。

www.kazuban.com

2025.03.23

Ollama　モデルの登録

DifyとOllamaを連携させ、ローカルチャットボット環境を作る

前回はLM StudioとDifyの連携でしたが、今回は、Ollamaと連携させてみました。どちらもそれぞれ特徴があるので、使い分けてもいいと思います。 私的には、スタンドアローンで使うならLM Studio。Difyとの連携であればOllama かな？と思っています。

www.kazuban.com

2025.03.30

あとがき

Windowsアプリ「Docker Desktop」を使わず、「Ubuntu」にインストールした「Docker Engine」で「Dify」をサーバー化する方法を紹介しました。
「Docker Desktop」はWindows環境向けのツールであり、構築の手間は比較的少ないですが、Ubuntuサーバー上で動作させる際は、仮想化環境の設定やネットワーク通信の複雑さが生じるため、トラブルシューティングがやや難しくなります。
今回は、AIのアシストにより、Difyサーバーを構築することができました。
設定プロセスだけでなく、AIを活用した実践例として、このやり取りもご参考にしていただければ幸いです。

話題のDifyをインストールしてみた。失敗談あり。

話題のDifyをローカルインストールしてみました。普通にやれば何てことない作業ですが、余計な事したので時間がかかってしましました。

www.kazuban.com

2025.03.15

この状態では、「WSL」環境には、別途Linuxはインストールされていません。
「wsl -l -v」コマンドで確認できます。

PS C:\Users\hoge> wsl -l -v
  NAME              STATE           VERSION
* docker-desktop    Running         2

現在は、仮想環境として「Docker Engine」のみが動作し、そのコンテナとして「Dify」が動作しています。
この状態でも、「Dify」を利用する場合には問題ありませんが、せかっくの「WSL」なので「ubuntu」環境に「Docker」を構築し、「Dify」コンテナを構築し直そうと思います。
また、windowsアプリ「Docker Desktop」は、ライセンス的に完全オープンではありませんし、「Dify」もLinuxとの組み合わせのほうが、貧弱スペックマシンでは、パフォーマンスが向上しそうな気がしています。

Docker Desktop と WSLを完全アンインストール

再度、クリーンな状態から再インストールしたい場合もあると思います
gemini君に教えてもらった、クリーンインストール方法をメモしておきます。

Docker Desktop のアンインストール

★Docker Desktopのアンインストール
1. 「設定」アプリを開く:
　Windowsキー + Iキーを押すか、スタートメニューから「設定」を選択します。
2. 「アプリ」を開く:
　「アプリ」をクリックします。
3. 「アプリと機能」を開く:
　左側のメニューから「アプリと機能」を選択します。
4. Docker Desktopを選択してアンインストール:
　アプリの一覧から「Docker Desktop」を見つけて選択し、「アンインストール」をクリックします。
　画面の指示に従ってアンインストールを完了させます。

★ 関連するファイルの削除 (オプション)
Docker Desktopのアンインストール後、残りのファイルを手動で削除することで、より完全にアンインストールすることができます。

1. 以下のフォルダを削除:
　`C:\Program Files\Docker`
　`C:\ProgramData\DockerDesktop`
　`C:\Users\<ユーザー名>\AppData\Local\Docker`
　`C:\Users\<ユーザー名>\AppData\Roaming\Docker`
2. Hyper-Vを無効化 (Docker DesktopでHyper-Vを使用していた場合):
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Hyper-V」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
3. WSL 2を無効化 (Docker DesktopでWSL 2を使用していた場合):
　管理者としてPowerShellを開きます。

　`wsl --unregister docker-desktop`と`wsl --unregister docker-desktop-data`コマンドを実行します。
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Linux用Windowsサブシステム」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
4. 環境変数の削除 (Docker関連の環境変数を設定していた場合):
　「システム環境変数の編集」を検索して開きます。
　「環境変数」ボタンをクリックします。
　ユーザー環境変数とシステム環境変数から、Dockerに関連する変数を削除します。
★注意点:
　上記のフォルダやファイルは、環境によって異なる場合があります。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。
　Docker Toolboxを使用していた場合は、VirtualBoxもアンインストールする必要があります。

wslを完全に削除する

★ WSLディストリビューションのアンインストール
　WSLに、既にLinuxディストリビューションがインストールされている場合、
　まず、これらを個別にアンインストールします。
1. 管理者権限でPowerShellまたはコマンドプロンプトを開きます。
2. `wsl --list --verbose` または `wsl -l -v` コマンドを実行し、インストールされているディストリビューションの一覧と名前を確認します。
3. `wsl --unregister <ディストリビューション名>` コマンドを実行します。
　例：`wsl --unregister Ubuntu-24.04`
4. 他のディストリビューションに対しても同様の手順を繰り返します。
**補足:**
　ディストリビューションをアンインストールすると、そのディストリビューションに関連付けられたすべてのデータが削除されます。
　必要なデータがある場合は、事前にバックアップしてください。
　Microsoft Storeからインストールしたディストリビューションは、通常のWindowsアプリと同様にアンインストールすることも可能です。

★WSL機能の無効化
　ディストリビューションをアンインストールした後、WSL機能を完全に無効化することもできます。
1. 「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
2. 「Windows Subsystem for Linux」と「仮想マシン プラットフォーム」のチェックボックスをオフにします。
3. 「OK」をクリックし、コンピューターを再起動します。
**補足:**
　WSL機能を無効化すると、すべてのWSL関連機能が利用できなくなります。
　Hyper-Vを有効にしている場合は、Hyper-Vも無効にする必要があります。
**その他の注意点**
　 WSL関連のファイルやフォルダが残っている場合は、手動で削除することも可能です。ただし、システムの重要なファイルを誤って削除しないように注意してください。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。

これらの手順に従うことで、WSLを完全に削除することができます。

ハードディスクのチェック

古いPCにインストールしていると、ハードディスクの調子が悪いのか？WSLが正常にインストールできない事がありました。
Windows付属のチェッカーで回復する可能性がありますので、メモしておきます。

★システムファイルチェッカー（SFC）の実行:
システムファイルの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「sfc /scannow」と入力して実行。

★DISMコマンドの実行:
SFCで修復できないシステムイメージの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「DISM /Online /Cleanup-Image /RestoreHealth」と入力して実行。

WSLにUbintu24.04をインストール

「Docker Desktop」と「WSL」のアンインストール方法を紹介しました。
今回は、WSLに「Ubuntu24.04」を構築し、「Docker Engine」環境を構築しますが、まだ「Docker Desktop」の環境は残しておきたいので、Windowsに新しいユーザーアカウントを作成し新しい環境で作業したいと思います。

Windows新しいアカウント作成

新しいユーザーの作成方法は、ネット上に情報がありますので、検索してみてください。
新しいユーザーでサインインし、新たに「WSL」環境を構築する場合では、こちらを参考してしてください。
新しいユーザーでサインインした初期状態では「wsl -l -v」で確認すると、なにも環境がないのがわかります。

PS C:\Users\hoge2> wsl -l -v
Linux 用 Windows サブシステムにインストールされているディストリビューションはありません。
この問題を解決するには、以下の手順に従ってディストリビューションをインストールしてください:

'wsl.exe --list --online' を使用して利用可能な配布を一覧表示する
および 'wsl.exe --install <Distro>' を使用してインストールしてください。

Ubuntu24.04インストール

いよいよインストールを始めますが、２つの方法
「Microsoft Store 経由」と「wsl コマンド経由」があります。
どちらでもいいと思いますが、アンインストールなどアプリの管理は「Microsoft Store 経由」のほうが簡単です

インストール自体はどちらも、簡単です。

「Microsoft Store 経由」
・Microsoft Store を開き、「Ubuntu 24.04」を検索。
・ 「入手」をクリック。
・ インストールが完了したら、「起動」をクリックします。

「wsl コマンド経由」
・PowerShell またはコマンドプロンプトを管理者権限で開く。
・「wsl --list --online」　でLinux ディストリビューションが一覧表示できる
・希望のディストリビューションをインストール
・「wsl --install -d Ubuntu-24.04」
・インストールが完了後「Ubuntu」起動

ユーザーとパスワード設定

「ubuntu」の起動は、「Microsoft Store 経由」であれば、「スタートメニュー」にアイコンが作成されています。
「wsl コマンド経由」の場合は、ターミナルを起動し「wsl」コマンドで起動できます。
「ubuntu」の最初の起動では、Unixユーザ名の作成を求められます。
特に、WIndowsユーザーと同じ必要はないので、適当なユーザー名とパスワードを設定します。

・
Enter new UNIX username: hoge2
New password:
Retype new password:
passwd: password updated successfully
Installation successful!
・

root パスワード設定

こちらでもレポートしましたが、「ubuntu」では管理権限が必要な場合には「sudo」コマンドで行い、「root」ユーザーは極力使わないを基本にしているみたいです。
したがってデフォルトでは「root」パスワードは設定されていません。
ただ、管理者権限が必要なコマンドやフォルダのアクセスなど、設定やメンテナンスの場合一回一回「sudo」を使うのは面倒です。
「root」での作業は、注意が必要ですが、管理者コマンドの連続の場合、筆者は使用しています。
その場合、筆者は「root」パスワードを設定しています。
「root」パスワードは、「sudo passwd root」コマンドで設定できます。

$ sudo passwd root
[sudo] password for hoge2:
New password:
Retype new password:
passwd: password updated successfully

設定されました。
「root」になりたい時には、「su」コマンドを使用します。
「root」になると「$」プロンプトが「#」に換わります。
元のユーザに戻るには「exit」コマンドを実行します。
現在のユーザーは「whoami」で確認できます。

$ su
Password:
# whoami
root
# exit
exit
$ whoami
hoge2

パスワード入力なしで「sudo」を実行する

通常は「sudo」コマンドを使用しますが、いちいちパスワードを聞かれるので、結構面倒です。
パスワードなしで「sudo」を実行できる設定は「visudo」コマンドの特殊なエディターで設定します。

$ sudo visudo
・
・
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
・
## Same thing without a password
%sudo  ALL=(ALL)       NOPASSWD: ALL
・
・

開いた設定ファイルに、
「%sudo ALL=(ALL) NOPASSWD: ALL」
この設定値を追加し上書き保存します。
この設定で、「sudo」グループのユーザーは「sudo」が実行でき、パスワードが不要になります。
ただし、「sudo」コマンドを実行できるのは、「sudoグループ」登録されているユーザーのみなので、現ユーザーを「suduグループ」に登録します。

$ sudo usermod -aG sudo $USER
$ newgrp sudo

この設定で、現ユーザーは「sudoグループ」に登録され「sudo」コマンドが実行できます。

Docker Engine をインストール

「ubuntu」を操作できるユーザー設定が完了したので、いよいよ「Docker Engine」をインストールしていきます。

古いバージョンのアンインストール

古いバージョンがインストールされている可能性がある場合には、念のため次のコマンドを実行してアンインストールしておきます

$ sudo apt-get remove docker docker-engine docker.io containerd runc

完全に削除するには、次のコマンドでボリュームやイメージデータを削除します

$ sudo rm -rf /var/lib/docker
$ sudo rm -rf /var/lib/containerd

Docker Engine インストール手順（Ubuntu 編）

・依存パッケージのインストール

$ sudo apt-get update
$ sudo apt-get install -y ca-certificates curl gnupg lsb-release

・ディレクトリを作製し、Docker の公式 GPG 鍵を追加

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

・Docker リポジトリを追加

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

・パッケージ更新＆インストール

$ sudo apt-get update
$ sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

・Docker の動作確認

$ sudo docker run hello-world

↑ これで「Hello from Docker!」が出れば OK！

・dockerコマンド実行は、「sudo」 が必要ですが、実行ユーザーがdockerグループであれば、不要になります。
下記コマンドで、douckerグループに参加させます。

$ sudo usermod -aG docker $USER
$ newgrp docker

コンテナの削除

動作確認で「hello-world」コンテナを作製しましたが、コンテナ削除操作を覚書しておきます。

★コンテナの一覧を表示
$ docker ps -a

★コンテナ削除
$ docker rm <CONTAINER ID または NAMES>

★hello-world イメージ自体を削除
★動作している場合に、エラーになるので、コンテナ削除後にイメージ削除
　 ※"hello-word"のCONTAINER IDを表示する
　 $ docker ps -a -q --filter ancestor=hello-world
$ docker rm $(docker ps -a -q --filter ancestor=hello-world)
$ docker rmi hello-world

★全てのコンテナと全てのコンテナイメージを削除
  -f オプションを付加すると、強制的に削除されるので注意
$ docker rm -f $(docker ps -a -q)
$ docker rmi -f $(docker images -a -q)

★ボリュームの削除: 全ボリュームを削除します。
$ docker volume rm $(docker volume ls -q)

★ネットワークの削除: ネットワークを削除します。
$ docker network rm $(docker network ls -q)

★キャッシュのクリア: 必要に応じて、Dockerのキャッシュをクリアします。
$ docker system prune -a

★すべての停止中コンテナと未使用イメージのみを一掃
　実行中のコンテナは削除しない
$ docker system prune

WSL、Ubuntu24.04、Docker Engine、環境完了

WSL、ubuntu、docker の環境が出来上がりました。
次に、dockerでDifyの環境をセットアップする予定ですが、windowsアプリの「docker Desktop」の場合は、ある程度アプリがやってくれそうですが、今回は「Ubuntu24.04」環境に「Docker」をインストールしたのでネットワーク環境が複雑になりそうな気がしています。

ubuntu、docker の通信状態

windows環境とwsl環境で、通信状態を調べてみます。

Windowsターミナルで、ipconfig コマンド

PS C:\Users\hogehoge2> ipconfig
Windows IP 構成
・
Wireless LAN adapter Wi-Fi:
   接続固有の DNS サフィックス . . . . .:
   IPv6 アドレス . . . . . . . . . . . .: 240f:110:2717:1:f62b:3484:aafb:ade5
   一時 IPv6 アドレス. . . . . . . . . .: 240f:110:2717:1:b1bf:2b2:5d5d:2a98
   リンクローカル IPv6 アドレス. . . . .: fe81::84c1:d56e:ece:1ad8%15
   IPv4 アドレス . . . . . . . . . . . .: 192.168.0.94
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: fe81::fab7:98ff:fe4b:95b8%15
・                                          192.168.0.1
イーサネット アダプター vEthernet (WSL):
   接続固有の DNS サフィックス . . . . .:
   リンクローカル IPv6 アドレス. . . . .: fe81::f749:f04d:c08e:932%44
   IPv4 アドレス . . . . . . . . . . . .: 172.31.224.1
   サブネット マスク . . . . . . . . . .: 255.255.240.0
   デフォルト ゲートウェイ . . . . . . .:

WindowsホストマシンIPアドレス、家庭内LAN：
192.168.0.94/24

WSL Windows側IPアドレス、WindowsとWSL間の通信するためのゲートウェイ：
172.31.244.1/20

wslで、ip a コマンド

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:c8:2e:42 brd ff:ff:ff:ff:ff:ff
    inet 172.31.226.6/20 brd 172.31.239.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe81::215:5dff:fec8:2e42/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether ba:b5:41:49:d7:3c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

WSL Docker側IPアドレス、WSL環境はこのアドレスで、Windowsと通信：
172.31.226.6/20

docker0 のIPアドレス、Dockerがコンテナにネットワーク機能を提供するためにWSL 2のLinux環境内に作成するブリッジネットワークインターフェースです
172.17.0.1/16

ネットワーク環境・・複雑ですね

次回、DockerにDifyのコンテナを作成しようと思います。
LAN内でも別のPCからのアクセス可能にしたいので、設定状況をレポートします。

WordPressを動作させる

最新のWordPressをダウンロードとドキュメント・ルートへ設置

・ホームディレクトリの仮のダウンロードディレクトリに移動
・WordPress 最新版のダウンロード
・圧縮ファイルを展開
・WordPress ディレクトリ全体を、Apacheのドキュメント・ルートへ移動
・必要に応じて、「wordpress」ディレクトリ名を自分の環境へ変更
・WordPressディレクトリ全体の、ユーザーとグループの変更

$ cd ~/Downloads/
$ wget https://ja.wordpress.org/latest-ja.tar.gz
$ tar xvzf latest-ja.tar.gz
$ sudo mv ./wordpress/ /home/www/html/
$ cd /home/www/html/
$ sudo mv ./wordpress/ ./blog/
$ sudo chown -R apache:apache ./blog/

MariaDBにデータベースと管理ユーザーの設定

「CREATE DATABASE」でWordPress用のデータベースを作成し
「GRANT ALL ON」でデータベースへ全権限を持つ ユーザを作成します。
mariaDBに wordpress用のデータベースを作成前に、設定情報をメモしておきます。
・データベース名：WpDb
・ユーザー名:WpAdmin
・パスワード:WpPasswd
・データベースホスト:local

$ mysql -u root -p[パスワード] <----- -pの後スペースなし
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 32
Server version: 10.11.8-MariaDB-0ubuntu0.24.04.1 Ubuntu 24.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE WpDb;  <--- データベース作成
Query OK, 1 row affected (0.001 sec)

MariaDB [(none)]> SHOW DATABASES;  <---- データベース確認
+--------------------+
| Database           |
+--------------------+
| WpDb              |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.001 sec)
          <---------- 作成したデータベースの管理者ユーザーの作成
MariaDB [(none)]> GRANT ALL ON WpDb.* TO 'WpAdmin'@'localhost' IDENTIFIED By 'WpPasswd';
Query OK, 0 rows affected (0.008 sec)

MariaDB [(none)]> USE mysql   <---- 管理者ユーザーのデータベースは「mysql」
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [mysql]> SELECT user,host from user;  <---- ユーザーデータベースの確認
+-----------------+-----------+
| User            | Host      |
+-----------------+-----------+
| WpDb           | localhost |
| mariadb.sys     | localhost |
| mysql           | localhost |
| root            | localhost |
+-----------------+-----------+
4 rows in set (0.003 sec)

MariaDB [mysql]> SHOW GRANTS FOR 'WpAdmin'@'localhost'; <--- 権限の確認
+------------------------------------------------------------------------------------------------------------------------+
| Grants for WpAdministrator@localhost                                                                                   |
+------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `WpAdmin`@`localhost` IDENTIFIED BY PASSWORD '*1234567AABBB2024A1B2222CC33344A2014Z' |
| GRANT ALL PRIVILEGES ON `WpDb`.* TO `WpAdmin`@`localhost`                                                |
+------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)

MariaDB [mysql]> quit
Bye

WordPress 初期設定

さあ、準備が完了したので、アドレスバーに公開サイトURLを入力すると「初期画面」が出てくるはずですが、前回の「RockyLinux」同様、エラーが出てしまいました。

「php-mysql*」の状態を調べてみます

$ dpkg -l | grep php-mysql
l$ apt list php-mysql*
一覧表示... 完了
php-mysql/noble 2:8.3+93ubuntu2 all

「RockyLinux9」では、「php-mysqlnd」が必要でしたが、「ubuntu2.4」では「php-mysql」のようなのでインストールします

$ sudo apt install php-mysql

インストール後再度公開サイトへアクセスすると、無事に初期設定　画面がでてきました。

「さぁ、始めましょう！」をクリックする事で、次の「ようこそ」画面で必要情報を入力する事でサンプルページが出てきます。

確認が済んだら、設定した「データベースのユーザー名」などの情報は、/home/www/html/blog/wp-config.phpに書かれているので、アクセス権は厳しくしておきます

$ cd /home/www/html/blog
$ sudo chmod 600 ./wp-config.php

Apacheの、rewriteモジュールとAllowOverrideの設定

WordPress設定のパーマリンクで「基本」以外の設定にしたい場合、Apache上でURLの書き換えを行う「mod_rewrite」モジュールを有効にする必要があります。
したがって、「mod_rewrite.so」モジュールが組み込まれている必要があります。
またパーマリンクの設定で、「基本」以外に設定した場合、URLの書き換えを行う設定がWordPressのディレクトリ内の「.htaccess」として作成されます。
apacheは「.htaccess」を見つけると、この設定を有効にしますが、AllowOverride がNoneで設定されていると「.htaccess」は無視されます。
「mod_rewriteモジュール」と「AllowOverride ディレクティブ」の確認を行います

$ ls /etc/apache2/mods-enabled/ | grep rewrite
　・・     <--- 有効になっていない

$ ls /etc/apache2/mods-available/ | grep rewrite
rewrite.load
　・・     <--- 設定ファイルはあるので、有効にする

$ sudo a2enmod rewrite
Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2

　・・     <--- AllowOverrideの設定ファイルを作成
$ cd /etc/apache2/conf-available
$ sudo vi ./wordpress.conf
<Directory "/home/www/html/blog">
    AllowOverride All
</Directory>
　・・     <--- 設定ファイル保存し、有効にする
$ sudo a2enconf wordpress
Enabling conf wordpress.
To activate the new configuration, you need to run:
  systemctl reload apache2

WordPress バックアップとリストア

バックアップの詳細はこちらで紹介しているので、興味あればご確認ください
今回以前自作した、バックアップとリストアのスクリプトをダウンロード可能にしました。
環境をあわせれば、使用できると思いますし、スクリプトなのでご自身の環境に合わせる事で使用できると思います。

スクリプトの環境

基本的は構造は下記になります。

・「自分のホームディレクトリ」に「bin」ディレクトリを作成
・「bin」にスクリプトを保存し、スクリプトには実行権限「+X」もしくは「700」に設定
・「自分のホームディレクトリ」にバックアップ用「Backup」ディレクトリを作成
・「Backup」に「MariaDB」と「WordPress」のバックアップ用ディレクトリを作成

$ cd <—– ホームディレクトリに移動
$ mkdir ./bin <—– スクリプトを保存するディレクトリ
$ mkdir ./Backup <—– バックアップ保存用ディレクトリ
$ mkdir ./Backup/MariaDB <——– MariaDBデータ保存用ディレクトリ
$ mkdir ./Backup/Wp-content <—— WordPressコンテンツ保存用ディレクトリ

スクリプトのダウンロードと展開

下記からダウンロードし、展開して使用します。
https://www.kazuban.com/soft/wordpress-back-restore.tar.gz

$ cd 
$ wget https://www.kazuban.com/soft/wordpress-back-restore.tar.gz
$ tar xvzf wordpress-back-restore.tar.gz
$ cd .bin
$ chmod 700 ./*
$ ls
MariaDB_Backup.sh  MariaDB_Restore.sh  Tidyup_backfile.sh  Wp-ContentRestore.sh  Wp-Content_Backup.sh

５個のスクリプトが展開されます。
・MariaDB_Backup.sh　　　MariaDBデータベースのバックアップ
・MariaDB_Restore.sh　　　MariaDBデータベースの復元
・Tidyup_backfile.sh 　バックアップデータの整理
・Wp-ContentRestore.sh　　WordPressコンテンツの復元
・Wp-Content_Backup.sh　　WordPressコンテンツのバックアップ

自分の環境に合わせて、編集

MariaDBデータベースのバックアップスクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#  MariaDB_Backup.sh    2023/12
#
#------------------------------------
BackupDir="/home/hogehoge/Backup/MariaDB"   <-------- バックアップディレクトリ
MysqlUser="WpAdmin"                        <-------- WordPressのユーザー
MysqlUserPasswd="WpPasswd"                 <-------- WordPressユーザーのパスワード
TidyUpScript="/home/hogehoge/bin/Tidyup_backfile.sh" <---- データ整理スクリプト
DaysAgo="4"               <-------- データを整理する日数
LOG="mariadb_backup.log"　<------- ログファイル名
#------------------------------------
　　・
　　・

実行すると、バックアップを開始します。
設定されている、バックアップディレクトリに、
「実行時の日付」-MariaDB.bak　の名前で保存されます
もし、古いバックアップがある場合、その作成日が「DaysAgo=”4″」より古い場合削除されます

MariaDBデータベースの復元スクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#  MariaDB_Restore.sh    2024/02
#
#------------------------------------
BackupDir="/home/hogehoge/Backup/MariaDB"     <-------- バックアップディレクトリ
MySqlPasswd="Password"                        <-------- MariaDBのパスワード
DataBase="WpDb"                               <-------- WordPressデータベース
#------------------------------------
PreBackup="Y"   # Do you want to back up? Y/N <---- 事前バックアップの有無
PreBackupFile="Pre-Backup.bak"                <------事前バックアップのファイル名
MysqlUser="WpAdmin"                           <----- WordPressデータベースユーザー
MysqlUserPasswd="WpPassword"                    <-------- WordPressユーザーのパスワード
BackupScript="/home/hogehoge/bin/MarinaDB_Backup.sh"
#------------------------------------
echo "--------------------"
　　・
　　・

復元スクリプトは、引数なしで実行すると、バックアップディレクトリに保存されているファイルのリストを表示するので、再度バックアップしたい日付のファイルを引数に指定して実行します。
「PreBackup=”Y”」に設定されている場合には、
復元前の状態のバックアップととり、確認後復元を開始します

$ ./MariaDB_Restore.sh     <---- 引数なしで実行
--------------------
/home/hogehoge/Backup/MariaDB　　<----- バックアップディレクトリ内のファイルを表示
20240625-MariaDB.bak
20240626-MariaDB.bak
20240627-MariaDB.bak
20240628-MariaDB.bak
20240629-MariaDB.bak
--------------------
MariaDB_Restore.sh [Backup file name]
--------------------
-- You are able to select from the list above.--
--------------------

$ ./MariaDB_Restore.sh 20240629-MariaDB.bak　<---- ファイルを指定して再実行
--------------------
/home/hogehoge/Backup/MariaDB
20240629-MariaDB.bak
--------------------
--------------------
preliminary backup start.  <----- 実行前データバックアップ
mysqldump -u WpAdmin -pWpPassword -h localhost -A  > 20240629-Pre-Backup.bak
-- The backup is complete. --
--------------------
-- Mysql restore start --
mysql -u root -pPassword WpDb < 20240629-MariaDB.bak
Restore?(y/n):y   <----- 確認

WordPress内容の復元スクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#       WP-contentRestor.sh   2024/02
#
#--------------------------------------------
BackupDir="/home/hogehoge/Backup/Wp-content" <---- WordPressのバックアップディレクトリ
WordPressWpContentDir="/home/www/html/blog/wp-content"　　<----WordPressコンテンツ本体 
#------------------------------------
echo "--------------------"
　　・
　　・

MariaDBと同様に、引数なしで実行すると、バックアップディレクトリに保存されているファイルのリストを表示するので、再度バックアップしたい日付のファイルを引数に指定して実行します
復元前の状態のバックアップととり、確認後復元を実行します

$ ./Wp-ContentRestore.sh
--------------------
/home/hogehoge/Backup/Wp-content　　<----- バックアップディレクトリ内のファイルを表示
20240625-Wp-content.tar.gz
20240626-Wp-content.tar.gz
20240627-Wp-content.tar.gz
20240628-Wp-content.tar.gz
20240629-Wp-content.tar.gz
wp-content_backup.log
--------------------
Wp-content_Backup.sh [????????-Wp-content.tar.gz] 
--------------------
-- You are able to select from the list above.--
--------------------

$ ./Wp-ContentRestore.sh 20240629-Wp-content.tar.gz　<---- ファイルを指定して再実行
--------------------
/home/hogehoge/Backup/Wp-content
20240625-Wp-content.tar.gz
20240626-Wp-content.tar.gz
20240627-Wp-content.tar.gz
20240628-Wp-content.tar.gz
20240629-Wp-content.tar.gz
wp-content_backup.log
--------------------
--------------------
/home/hogehoge/Backup/Wp-content
tar xzf 20240629-Wp-content.tar.gz  <----展開、容量により時間がかかります
---- Restore --------
sudo mv /home/www/html/blog/wp-content /home/www/html/blog/wp-content-20240629
sudo mv /home/hogehoge/Backup/Wp-content /home/www/html/blog/wp-content /home/www/html/blog/wp-content
sudo chown -R apache:apache /home/www/html/blog/wp-content/
Restore completed!
--------------------

WordPress内容のバックアップスクリプト

自分の環境に合わせて、変数を編集します。

#!/bin/sh
#
#       WP-content_Backup.sh    2020/03
#                               2023/12
#
#--------------------------------------------
BackupToDir="/home/hogehoge/Backup/Wp-content" <-- WordPressのバックアップディレクトリ
BackupSorceDir="/home/www/html/blog/wp-content"<----WordPressコンテンツ本体
TidyUpScript="/home/hogehoge/bin/Tidyup_backfile.sh" <---- データ整理スクリプト
DaysAgo="4"               <-------- データを整理する日数
LOG="wp-content_backup.log"　<------- ログファイル名
#--------- Help -----------------------------
　　・
　　・

バックアップは引数なしで実行が始まります。
事前にWordPressのディレクトリを日付付きのファイルに圧縮して保存します

$ ./Wp-Content_Backup.sh
tar czf 20240629-Wp-content.tar.gz /home/www/html/blog/wp-content/  <---- 事前バックアップ
rm 20240625*  <--- バックアップファイル整理
rm 20240626*

バックアップ自動化

Linux の「Crontab」コマンドで、スケジューリングする事で自動的にバックアップする事も可能になります。
「crontab -e」でスケジュールを編集し、「crontab -l」で確認できます。
また、「MAILTO=」を設定する事で、指定ユーザーに結果をメールを送信してくれます

$ crontab -e
MAILTO=root
00 1 * * *       /home/hogehoge/bin/MariaDB_Backup.sh
30 1 * * *       /home/hogehoge/bin/Wp-Content_Backup.sh

$ crontab -l
MAILTO=root
00 1 * * *       /home/hogehoge/bin/MariaDB_Backup.sh
30 1 * * *       /home/hogehoge/bin/Wp-Content_Backup.sh

これで、プラグインを使用しなくても、Wordpressのバックアップが可能になりました。

Ubuntu24.04LTSでWordPressを構築する記事一覧

インストール・SSH・ファイヤーウォール

Apache2のインストールと設定

SSL、PHP、MariaDB、Let’s Encrypt証明書でhttps化

WordPress インストール、バックアップと復元