WordPress | じじぃの引出し https://www.kazuban.com/blog なにかしら、皆さんの参考になれば幸いです！ Sat, 13 Jun 2026 06:26:03 +0000 ja hourly 1 https://wordpress.org/?v=7.0 https://www.kazuban.com/blog/wp-content/uploads/2020/05/cropped-ICON-1-32x32.png WordPress | じじぃの引出し https://www.kazuban.com/blog 32 32 WordPress の「バックアップ・リストア」BASHスクリプト https://www.kazuban.com/blog/rokeylinux9-7-wordpress-backup/ https://www.kazuban.com/blog/rokeylinux9-7-wordpress-backup/#respond Sun, 07 Jun 2026 06:28:26 +0000 https://www.kazuban.com/blog/?p=12790 バックアップ・リストアの記事は、以前こちらでも紹介しました

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

]]> https://www.kazuban.com/blog/rokeylinux9-7-wordpress-backup/feed/ 0 RockyLinux9.7で「WordPress環境構築「Vol-04」WordPressインストール https://www.kazuban.com/blog/wordpress-install-no4/ Sun, 10 May 2026 00:03:42 +0000 https://www.kazuban.com/blog/?p=12701 いよいよWordPressをインストールしていきます
このサイトでも、同様の記事は書いていますが、変更点もあるので新しく投稿します。

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環境構築まとめ

１

２

３

４

５

６

]]> RockyLinux9.7で「WordPress環境構築「Vol-03」PHP8.4、MariaDB11.4 https://www.kazuban.com/blog/wordpress-install-no3/ Fri, 01 May 2026 01:36:17 +0000 https://www.kazuban.com/blog/?p=12568 WordPress構築のために、PHPとMariaDB(Mysql)環境を整備していきます
現状の状態は、
WordPress6.9.4、PHP 8.2.30 MariaDB10.5.29です。
今回は、バックアップ用が目的ですが、トライアルもかねて、なるべく新しいバージョンにしておきたいと思います。
現wordpressに対応している、phpとwordpressのバージョンは下記を参考にしました

PHP
MariaDB

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

PHPのインストール

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

php --version

やはりインストールされていませんが、もしインストールされている場合には、必要あればバックアップを取り、問題なければすべて削除します

sudo dnf remove php*
sudo dnf remove php-*

PHP モジュールリストを確認します

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をインストールしようと思います

sudo dnf module install php:remi-8.4
sudo dnf install php

拡張機能を追加

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

sudo dnf install \
  php-mysql php-curl\
  php-mysql php-exif\
  php-mysql php-fileinfo\
  php-mysql php-gd\
  php-mysql php-imagick\
  php-mysql php-intl\
  php-mysql php-json\
  php-mysql php-mbstring\
  php-mysql php-mysqli\
  php-mysql php-openssl\
  php-mysql php-xml\
  php-mysql 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

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

項目推奨設定
ERROR 2002 (HY000): Can’t connect to local server through socketMariaDB サービスが起動していない場合、このエラーがでます。その場合は起動させます。
sudo systemctl start mariadb
Enter current password for root (enter for none):
カレントrootパスワード：		以前設定していなければ「Enter」
Switch to unix_socket authentication [Y/n]
Unix socket 認証		n（パスワード認証を使う場合）
Change the root password? [Y/n]
root パスワード設定
このパスワードは、データベース作成時にも使用するので、忘れないようにメモします		y → パスワードを入力
データベースへのログインで使用する
mysql -u root -p[パスワード]
Remove anonymous users? [Y/n]
匿名ユーザーの削除		y
Disallow root login remotely? [Y/n]
リモート root ログインの禁止		y
Remove test database and access to it? [Y/n]
テスト DB の削除		y
Reload privilege tables now? [Y/n]
権限テーブルのリロード		y

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

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

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環境構築まとめ

１

２

３

４

５

６

]]> RockyLinux9.7で「WordPress環境構築「Vol-02」Apache設定と、HTTPS化 https://www.kazuban.com/blog/wordpress-install-no2/ Fri, 24 Apr 2026 23:49:17 +0000 https://www.kazuban.com/blog/?p=12446 前回、RockyLinux9.7をインストールし、WindowsターミナルでSSH接続できるようになりました
今回は、Apache、MariaDB、PHPをインストールし、WordPressを起動させます
筆者の環境ではすでに自宅内で、Wordpress（このブログサイト）は起動しているのでテスト環境として、仮にwww2.hogehoge.com で設定を行っています
この仮ドメインは、実際のドメインに変更してご利用ください。

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環境構築まとめ

１

２

３

４

５

６

]]> RockyLinux9.7で「WordPress環境構築「Vol-01」WindowsからのSSH接続でリモート管理 https://www.kazuban.com/blog/wordpress-install-no1/ Sat, 18 Apr 2026 08:18:05 +0000 https://www.kazuban.com/blog/?p=12299 ひと昔以上前のノートに、「ubuntu」入れてみたのが、２年前

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環境構築まとめ

１

２

３

４

５

６

]]> Ubuntu24.04LTSでWorsPressを動作させる。WordPress インストール、バックアップと復元 https://www.kazuban.com/blog/wordpewss-ubuntu/ Sun, 30 Jun 2024 06:22:28 +0000 https://www.kazuban.com/blog/?p=8935 「RockyLinux9」への「WordPress」のインストールはこちらで説明しています。

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 インストール、バックアップと復元

]]> RockyLinux9.３で自宅サーバーを再構築V07・WordPress のバックアップとリストア https://www.kazuban.com/blog/rokeylinux9-3-wordpress-backup/ Mon, 08 Jan 2024 01:58:11 +0000 https://www.kazuban.com/blog/?p=8476 ここまでで、新しい環境「RocyLinux9.3」でWordPressが動作できました。
今回の目的は、旧サーバー「centOS7」環境を「RocyLinux9.3」へ移行する事です。
まずは「centOS7」のWordPressデータのバックアップを取り、そのデータを
「RocyLinux9.3」へリストアする方法を説明します。

WordPressバックアップ

バックアップは、データベースとデータファイルを行います。
データベースは、MariaDBが管理保存しています
投稿記事や設定などが保存されています。
データファイルは、WordPress ディレクトリの、「wp-content」内のデータで
主に、テーマやプラグイン、画像データなどが保存されているデータです。

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

データベースは、「mysqldump」でバックアップします。
データベース値は前回の例を参考にします。

・管理者パスワード： hogehoge_passwd
・データベース名：WpDb
・ユーザー名:WpAdmin
・パスワード:WpPasswd
・データベースホスト:localhost

前回例を参考にすると、コマンドのパラメータは、下記になります。

-u ユーザー名：WpAdmin
-p ユーザーパスワード：WpPasswd
-h ホスト名：localhost
-A すべてのデータベースの意味

バックアップファイル名：WordPress.bak

「mysqldump」が吐き出したデータを出力リダイレクト「>」でファイルに保存します

$ mysqldump -u WpAdmin -pWpPasswd  -h localhost -A > WordPress.bak

データベース・MariaDBのリストア

バックアップは、「mysqldump」で行いましたが、リストアは「mysql」でできます。

-u ユーザー名：root
-p 管理者パスワード：hogehoge_passwd
-データベース名：WpDb

バックアップファイル名：WordPress.bak

$ mysql -u root -phogehoge_passwd WpDb < WordPress.bak

これで、データベースのリストアは完了ですが、もしバックアップ元とバックアップ先の
URLなどの設定を違えたい場合には、ここを参考にして、内容を書き換えます。

データファイル・wp-content のバックアップ

WordPressをインストール後、投稿により追加変更される
重要なディレクトリが「wp-content」です。
したがって、定期的に「wp-content」をバックアップしておくと、上記のデータベース復元
と共に「wp-content」ディレクトリを書き換える事で、バックアップ時の状態へ戻す事ができます。
日々の更新により「wp-content」内の全てが更新されていく訳ではありませんが
作業の単純化のために、「wp-content」全てをバックアップする事にします。
バックアップ作業は簡単です、適当なバックアップ保存用のディレクトリを用意し
「 [WordPressディレクトリ]/wp-content」を圧縮し、保存用ディレクトリに保存しておきます。
バックアップしたファイル名には、日付を付けておくと、バックアップ時期がわかりやすいです。
筆者は、下記のような設定で運用します。

バックアップ保存ディレクトリ：/home/hogehoge/BackupDir/
バックアップ保存ファイル名：20240103-Wp-content.tar.gz
バックアップ元ディレクトリ：/home/www/html/blog/wp-content/

$ tar czf /home/hogehoge/BackupDir/20240103-Wp-content.tar.gz  /home/www/html/blog/wp-content/

データファイル・wp-content のリストア

データファイルの復元は上記のデータベースの復元と共に行う事が重要です。
基本的には、バックアップされているディレクトリと入れ換えるだけですが
いきなり入れ替えでは戻せなくなるので、まずは既存を名前変更で残しておきます。
・圧縮保存されている、バックアップファイルを展開
・既存の、「WordPressディレクトリ」/wp-content/ を「wp-content_bak」などに変更
・展開された「バックアップディレクトリ」内の「wp-content」を
「WordPressディレクトリ」に移動。
・移動された「wp-content」の属性を「apacheユーザー」属性にすべて変更
この作業で、サイトへアクセスすると、バックアップ時の状態になっています。

$ cd /home/hogehoge/BackupDir/
$ tar xzf ./20240103-Wp-content.tar.gz
$ ls
20240103-Wp-content.tar.gz  home

$ sudo mv /home/www/html/blog/wp-content/ /home/www/html/blog/wp-content_bak/
$ sudo mv ./home/www/html/blog/wp-content/ /home/www/html/blog/
$ sudo chown -R apache.apache /home/www/html/blog/wp-content
$ ls -la /home/www/html/blog/
・
drwxr-xr-x.  6 apache apache    84 1月 3 11:15 wp-content
drwxr-xr-x. 10 apache apache   164 1月 3 9:29 wp-content_bak
・

WordPress 自動バックアップ

WordPress には、バックアップのプラグインもありますが、自宅サーバーなど
シェルが利用できる環境であれば、シェルスクリプトを組む事で自動バックアップが可能になります。

バックアップさせるシェルスクリプトを作成します。
シェルスクリプトの構文や文法は、ネット上に情報がありますのでそちらで確認してください。
まずは、シェルシェルスクリプトを置くディレクトリを作成します。
筆者は、「管理ユーザーのホームディレクト」/bin/ としました。
さらに、バックアップを置くディレクトリも作成します。
「ホームディレクト」/Backup/を作成し、「Backup」の下に「MariaDB」と「Wp-content」を作成し、この中に保存しようと思います。
バックアップ用のディレクトリは、事前に作成しておきます。

$ cd
$ mkdir ./bin
$ mkdir ./Backup
$ mkdir ./Backup/MariaDB
$ mkdir ./Backup/Wp-content
/home/hogehoge
├─Backup
│  ├─MariaDB       <--- データベース用
│  └─Wp-content    <---　データファイル用
├─bin         <---- 自動バックアップスクリプト
├─Desktop
├─Documents
├─Downloads
├─Music
├─Pictures
├─Public
├─Templates
└─Videos

MariaDBのバックアップスクリプト

スクリプト内では次の変数を定義します。
変数は、自分の環境に合わせて編集します。

BackupDir=”/home/hogehoge/Backup/MariaDB” #バックアップ用ディレクトリ
MysqlUser=”WpAdmin” #ユーザー名
MysqlUserPasswd=”WpPasswd” #ユーザーパスワード
LOG=”mariadb_backup.log” #バックアップログファイル

バックアップファイル名は、日付+”-MariaDB.bak” を自動設定する仕様にします。

#!/bin/sh
#
#  MariaDB_Backup.sh    2024/01/03 by kazuban
#
#------------------------------------
BackupDir="/home/hogehoge/Backup/MariaDB"
MysqlUser="WpAdmin"
MysqlUserPasswd="WpPasswd"
LOG="mariadb_backup.log"
#------------------------------------

cd $BackupDir
echo "`date` Execute Backup!! " >> $LOG

DATE=`date '+%Y%m%d'`
FILENAME="$DATE-MariaDB.bak"
CMD="mysqldump -u $MysqlUser -p$MysqlUserPasswd -h localhost -A " 
echo $CMD >> $LOG
echo $CMD " > $FILENAME"
$CMD  > $FILENAME 
echo "`date` ------------ End" >> $LOG

このファイルを、適当なファイル名で、スクリプト用ディレクトリへ保存します。
筆者は「/home/hogehoge/bin/」に「MariaDB_Backup.sh」で保存しました。
このファイルは、実行できるように、実行権限を付けます

$ chmod 700 /home/hogehoge/bin/MariaDB_Backup.sh

wp-content のバックアップスクリプト

wp-contentディレクトリは、「home/hogehoge/Backup/Wp-content/に保存します。
こちらの変数も、自分の環境に合わせます。

BackupDir=”/home/hogehoge/Backup/Wp-content” #バックアップ用ディレクトリ
BackupSorceDir=”/home/www/html/blog/wp-content” #バックアップ元
LOG=”wp-content_backup.log” #バックアップログファイル

バックアップディレクトリは圧縮しファイル名は、
日付+”-Wp-content.tar.gz” を自動設定する仕様にします。

#!/bin/sh
#
#	Wp-Content_Backup.sh    2024/01/03 by kazuban
#
#--------------------------------------------
BackupToDir="/home/hogehoge/Backup/Wp-content"
BackupSorceDir="/home/www/html/blog/wp-content"
LOG="wp-content_backup.log"


cd $BackupToDir
echo "`date` Execute Backup!! " >> $LOG

DATE=`date '+%Y%m%d'`
FILENAME="$DATE-Wp-content.tar.gz"
PARA="czf"

CMD="tar $PARA $FILENAME $BackupSorceDir/" 
echo $CMD >> $LOG
echo $CMD
$CMD  > /dev/null 2>&1 
echo "`date` ------------ End" >> $LOG

このファイルも同様に「Wp-ContentBackup.sh」で保存しました。
このファイルにも、実行できるように、実行権限を付けます

$ chmod 700 /home/hogehoge/bin/Wp-Content_Backup.sh

自動バックアップ

ここでの例では、/home/hogehoge/bin ディレクトリ内にスクリプトを作成しました
まずは、正常に動作するか、確認してみます。

$ cd /home/hogehoge/bin
$ ls      <---- 作成したスクリプト確認
MariaDB_Backup.sh  Wp-Content_Backup.sh  <----- スクリプト名確認
・
・
$ /home/hogehoge/bin/MariaDB_Backup.sh  <----- スクリプト実行
mysqldump -u WpAdmin -pWpPasswd -h localhost -A  > 20240107-MariaDB.bak
                                        <---- 正常終了
$ /home/kazu/hogehoge/Wp-Content_Backup.sh  <----- スクリプト実行
tar czf 20240107-Wp-content.tar.gz /home/www/html/blog/wp-content/
                                        <---- 正常終了
$ ls /home/hogehoge/Backup/MariaDB/
20240107-MariaDB.bak  mariadb_backup.log  <---- 作成されている
$ ls /home/hogehoge/Backup/Wp-content
20240107-Wp-content.tar.gz wp-content_backup.log  <----- 作成されている

スクリプトの正常動作が確認できたら、自動バックアップするようにスケジューリングします
スケジューリングは、「crontab」コマンドで行います。
「crontab」は、実行時間を、「分」「時」「日」「月」「曜日」で設定し、
実行したいコマンドを書きます。
例えば、朝６：３０に「MariaDB.sh」を実行したい場合には、下記になります。

30 06 * * * /home/hogehoge/bin MariaDB.sh

定義済みのスケジュールは「crontab -l」で確認でます。
定義されていない場合には、なにもでてきません。
定義するには、「crontab -e」で行います。
例として、AM3:00に「MariaDB_Backup.sh」、AM3:30に「Wp-Content_Backup.sh」
をスケジュールしてみます。

$ crontab -e     <--- -eオプションで設定
00 3 * * *       /home/hogehoge/bin/MariaDB_Backup.sh
30 3 * * *       /home/hogehoge/bin/Wp-Content_Backup.sh
・
・
$ crontab -l     <--- -lオプションで確認

これで、毎日WordPressの自動バックアップができます。

リストア、スクリプト

リストア用のスクリプトはとちょっと面倒です。
いきなり、リストアしてしまったら、「あ～」直前に戻したいぃ・・・
になるかもしれません。
やはり、仕様としてはリストア直前にバックを取ってから実行したほうが安全です。
既存のバックアップ仕様の組込など考えると、結構面倒ですしリストア自体は、
バックアップのように定期的にやるものではないので、手動でやったほうが安全かもしれません。
ある程度、バックアップファイルの実績がとれたら、リストアスクリプトも作成しようと思います。

復元の確認

データベース・MariaDBのリストア、データファイル・wp-content のリストア
今回は上記の方法で、手動で復元してみます。
手動復元が完了したら、ページを表示して確認してみましょう。
トップページは正常に表示されています。
管理画面での設定も、バックアップ前と同じになっています。
ところが・・・・・

記事のリンクへ飛べない！

記事をクリックしても、そのリンクが「Not Founf」で開きません。

パーマリンク

調べてみると、「パーマリンク」が怪しいです。

https://haniwaman.com/permalink-not-reflected/#index_id3
https://irohaplat.com/wordpress-httpd-conf-setting-for-permanentlink/

「基本」にしてみると、正常にリンクできるようになりました。
ところが、いままでの設定の「投稿名」にすると、リンクエラーになります。

.htaccess

WordPressのパーマリンクは、「変更を保存」ボタンを押す事で、サーバーの
「WordPress」ディレクトリへ「.htaccess」を作成し、リンク内容を書き込むようです。
確かに、「変更を保存」実行前までは、「WordPress」ディレクトリで「ls -la」しても、「.htaccess」は存在していませんでしたが「変更を保存」する事で、自動作成されました。
ところが、これでも、リンクエラーは解消しません。

mod_rewriteモジュール

「mod_rewrite.so」モジュールが組み込まれているかを確認します。

$ vi /etc/httpd/conf.modules.d/00-base.conf
・
#
# This file loads most of the modules included with the Apache HTTP
# Server itself.
#

・

・

LoadModule request_module modules/mod_request.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
・

モジュールは読み込まれています。

Apacheの、AllowOverrideの設定

Apacheの設定ファイル、「httpd.conf」を確認してみます。

# vi /etc/httpd/conf/httpd.conf
・
・
# Further relax access to the default document root:
#<Directory "/var/www/html">
<Directory "/home/www/html">
・
    AllowOverride None
・
</Directory>

デフォルトでは「 AllowOverride None」になっていました。
この設定を「All」にしたほうがよさそうですが、筆者の「WordPress」のディレクトリは
「/home/www/html/blog」なので、「/home/www/html/」ではなくて
「/home/www/html/blog」を「AllowOverride All」設定にします。
追加の設定は、直接「httpd.conf」に追加する方法と、「/etc/httpd/conf.d」のディレクトリ内に
「 [WordPress用].conf 」のファイルを追加する方法があります。
「confファイル」追加の有効性は、「httpd.conf」の「IncludeOptional」で確認できます。

$ vi /etc/httpd/conf/httpd.conf
・
# Supplemental configuration
#
# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf
・
・

この設定であれば、直接「httpd.conf」を編集しなくても、
後者の「/etc/httpd/conf.d」に「wordpress.conf」を追加する方法が可能です。

$ sudo vi /etc/httpd/conf.d/wordpress.conf
<Directory "/home/www/html/blog">
    AllowOverride All
</Directory>
・
・          <-------- 書き込み保存で新規作成後、httpd を再起動
$ sudo systemctl restart httpd

この設定で、正常にリンク先にアクセスできるようになりました。
これで、バックアップは定期的に自動作成されているので、
もしトラブルなどあった場合には、以前の状態に復元する事ができますし
今回の記事のテーマの、サーバー本体の引っ越しにも、使用できます。

RockyLinux9.3で自宅サーバーを再構築・記事一覧

インストール

SSHでリモート管理

firewalldでアクセス制御

Apache編

PHP8.2とMariaDB10.5編

WordPress インストール

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

postfix で送信専用メールサーバー構築

]]> RockyLinux9.３で自宅サーバーを再構築V06・WordPress インストール https://www.kazuban.com/blog/rokeylinux9-3-wordpress-install/ Sun, 07 Jan 2024 04:06:55 +0000 https://www.kazuban.com/blog/?p=8463 前回までで、新サーバーへLANP環境が出来上がりました。
ここから、WordPress環境を構築し、現サーバーから引越ししたいと思います。

WordPress インストール

現サーバーのインストールは、このサイトでも紹介しています。

自宅サーバでWordPressを動かそう。インストール
前回までで、WordPress要求の PHPバージョン7.3以上、MySQLバージョン5.6またはMariaDBバージョン10.0以上の環境は出来上がっています。いよいよ、WordPress をインストールしようと思います。環境の確認インストール状況を確認するには、「rpm -qa 」や「yum l...
www.kazuban.com
2019.11.12

WordPress 準備

・ホームディレクトリの「Downloads」へ移動
・最新のWordPressパッケージをダウンロード
・ダウンロードされた、パッケージを展開

$ cd ~/Downloads/   <--- 一旦保存するディレクトリへ移動
$ wget https://ja.wordpress.org/latest-ja.tar.gz <--- 最新盤ダウンロード
・
・
$ ls
latest-ja.tar.gz  <--- ダウンロードされた、WordPress パッケージ
$ tar xvzf latest-ja.tar.gz  <---- 展開
・
・
$ ls
latest-ja.tar.gz  wordpress     <---- wordpress ディレクトリが作成された
$ ls wordpress/         <---- パッケージが展開されている。
index.php             wp-includes
license.txt           wp-links-opml.php
readme.html           wp-load.php
wp-activate.php       wp-login.php
wp-admin              wp-mail.php
wp-blog-header.php    wp-settings.php
wp-comments-post.php  wp-signup.php
wp-config-sample.php  wp-trackback.php
wp-content            xmlrpc.php
wp-cron.php

WordPressパッケージの移動

・wordpressディレクトリをApacheのドキュメントルートへ移動
・wordpressディレクトリを、現状に合わせて、blogに変更

$ cd ~/Downloads/
$ su
パスワード:
# mv ./wordpress/ /home/www/html/   <----- ドキュメントルートへ移動
# cd /home/www/html/
# ls
index.html  wordpress       <----- 移動確認
# mv ./wordpress/ ./blog/    <----- WordPress のディレクトリ名変更
# ls 
blog  index.html
# chown -R apache.apache ./blog/  <----- Webサーバーユーザーに変更

MariaDBの設定

データベース作成

mariaDBにwordpress用のデータベースを作成前に、設定情報をメモしておきます。
・データベース名：WpDb
・ユーザー名:WpAdmin
・パスワード:WpPasswd
・データベースホスト:localhost

mariaDBに接続し、「CREATE DATABASE」でデータベース作成
「SHOW DATABASES」で確認できます。

$  mysql -u root -p[パスワード] <----- -pの後スペースなし
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 10.5.22-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)]> CREATE DATABASE WpDb;
Query OK, 1 row affected (0.000 sec)

MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+

| WpDb               |
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.000 sec)

データベース管理者の作成

MariaDB [(none)]> GRANT ALL ON WpDb.* TO 'WpAdmin'@'localhost' IDENTIFIED By 'WpPasswd';
Query OK, 0 rows affected (0.105 sec)

MariaDB [(none)]> USE 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      |
+-----------------+-----------+
| WpAdmin         | localhost |

| mariadb.sys     | localhost |
| mysql           | localhost |
| root            | localhost |
+-----------------+-----------+
5 rows in set (0.001 sec)
MariaDB [mysql]> SHOW GRANTS FOR 'WpAdmin'@'localhost';
+--------------------------------------------------------------------------------------------------------------
--+
| Grants for WpAdmin@localhost                                                                                 
  |
+--------------------------------------------------------------------------------------------------------------
--+
| GRANT USAGE ON *.* TO `WpAdmin`@`localhost` IDENTIFIED BY PASSWORD '*1D7A79234966407F4E4D1D1739BD39F36A92BA16
' |
| GRANT ALL PRIVILEGES ON `WpDb`.* TO `WpAdmin`@`localhost`                                                    
  |
+--------------------------------------------------------------------------------------------------------------
--+
2 rows in set (0.000 sec)
MariaDB [mysql]> quit
Bye

WordPress の設定

Webブラウザから、WordPress本体のWebアドレスへアクセスすると、初期設定画面が表示されるはずです。

　https://www.hogehoge.com/blog/

ＭySQL拡張機能エラー

筆者の今までの設定環境では、初期画面のはずが
「お使いのサーバーのPHPではWordPressに必要なMySQL拡張を利用できないようです。」
のエラーがでました。

何かが足りないのか？
とりあず、「php」と「mysql」でパッケージを検索してみます。

$ dnf search php | grep mysql
・
php-mysqlnd.x86_64 : A module for PHP applications that use MySQL databases
・

「php-mysqlnd」が見つかりました。
インストール状態を調べてみます。

$ dnf list --installed | grep php-mysql
$

なにも出てきません。インストールされていないようです。
とりあえず、インストールして再起動してみます。

# dnf install php-mysqlnd
・
インストール:
 php-mysqlnd     x86_64     8.2.14-1.el9.remi     remi-インストール済み:
  php-mysqlnd-8.2.14-1.el9.remi.x86_64                                                                           

・
完了しました!
# systemctl restart php-fpm.service 
# systemctl restart httpd

初期設定

どうにか、初期設定画面がでてきました！！

「さあ、始めましょう！」で次へ進み、
mariaDBに作成したデータベース情報を設定していきます。

設定が終了したら、「送信」

「インストール実行」で「ようこそ」画面が表示されます。

ブログのタイトルや、管理者ユーザー情報を入力
ここでの、ユーザー名・パスワードは、ワードプレス管理画面へログインする時の情報です
mariaDBに作成したデータベース情報とは違います。
設定したら、「WordPressをインストール」をクリック

「成功しました！」が表示されれば、成功です。
「ログイン」リンクで、ログイン画面が表示されます

ユーザー名とパスワードを入力すると、管理ページが表示されます。

管理ページが出ない場合は、下記からアクセスできます。

　https://www.hogehoge.com/blog/wp-admin/

こちらの「設定」から、タイトルやパスワードなどの変更だけでなく、さらに詳細な設定ができます。

画面左上「ホームアイコン」⇒「サイト表示」でトップページが表示されます。

wp-config.phpのアクセス権限

上で設定した、「データベースのユーザー名」や「データベースのパスワード」の情報は、
設定後にWordPress本体のディレクトリの「wp-config.php」ファイルに書かれています。
このファイルの情報は非常に重要なため、アクセス権を厳しく設定しておきます。
また、バックアップを取りたいと思い、コピー先ファイルの拡張子「.php」を
「.bak」など他の拡張子にするのも危険です。
まず、WordPress本体のディレクトリに移動し、「chmod 600」でアクセス権を厳しくします

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

ローカルからドメイン名でのアクセス

hostsファイル

「https://」のアドレスをＷｅｂブラウザで確認する場合、IPアドレスでなくドメインでアクセスする必要があります。
ドメインの場合、IPアドレスとの紐づけが必要で、一般的にはDNSに解決してもらいますが
Webサーバーと同じローカル内のＰＣから確認したい場合には、うまく接続できない事があります。
そんな時には、クライアントの「hosts」ファイルに対応リストを書いておくことで、DNSに頼らず、ローカル内からも接続できるようになります。
「hosts」ファイルはクライアントが、Windowsの場合には、
「C:\Windows\System32\drivers\etc\hosts」。
linuxの場合には、「/etc/hosts」ファイルになります。

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.11 www.hogehoge.com

WordPress のサイトヘルスエラー

WordPress をインストールして、ローカルのWindwsPCから、確認をしてみました。
「hosts」設定により、普通にアクセスでき、ページは正常に表示されましたが、
管理画面のサイトヘルスが致命的エラーを吐き出しました。

ネット情報を参考に、いろいろやってみましたが、解決しません。
エラー内容から、「curl」のエラーなのが、わかりました。
このコマンドを、立ち上げ中の「RocyLinux9」のターミナルで実行すると、エラーがでます

$ curl https://www.hogehoge.com
curl: (35) error:0A000102:SSL routines::unsupported protocol

ドメイン名でのアクセスは、クライアントだけかと思っていましたが、
サーバー側でも利用してるみたいです。
こちらも、名前解決できていないのが、原因のようですね。
筆者はWindowsPCの「hosts」しか編集していませんでしたが、
サーバーの「/etc/hosts」も編集したところ、このエラーを解決する事ができました。

$ sudo vi ./hosts
・
$ curl https://www.hogehoge.com
<html>
  <body>
    <h1>This website is currently under maintenance.</h1>
  </body>
</html>

サイトヘルスも、「おすすめ改善」はありますが、「致命的な問題」は消えました。

これで、新しいブログを公開する準備は整いました。
今回のテーマは再構築なので、次回は、旧サーバーから既存のデータのバックアップを行い
この新しい環境で表示できるようにしたいと思います。

RockyLinux9.3で自宅サーバーを再構築・記事一覧

インストール

SSHでリモート管理

firewalldでアクセス制御

Apache編

PHP8.2とMariaDB10.5編

WordPress インストール

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

postfix で送信専用メールサーバー構築

]]> ダウンロードページを作る。VSCodeを使ってHTMLで書いてみる。 https://www.kazuban.com/blog/vscode-html/ Sun, 11 Jul 2021 00:59:25 +0000 https://www.kazuban.com/blog/?p=5489 このサイトで公開してきた、フリーソフトも増えてきたので、説明とダウンロードのページを作ろうと思います。
このサイトでは、「WordPress」を使わせていただいていますが、「WordPress」では、「ブログ」のような投稿ページと一般的なホームページのような「固定ページ」を作成する事ができます。
今回考えている、ソフトの一覧ページは、「固定ページ」で作成しようと思います。

ブロックエディタ

「WordPress」の更新はかなり多くて、更新によって記事を書くエディタも変わってきています。
現在は「ブロックエディタ」と呼ばれる形式になっています。
「ブロックエディタ」は、文章や画像をブロック単位で作成していきます。
もともと、Webに公開するには「HTML」言語を使用しますが、「ブロックエディタ」を使うと「ワード」などのような感覚でHTMLを知らなくても記事をレイアウトできます。
実際に、このページも「ブロックエディタ」で作成しています。
ブロックの種類はかなり沢山用意されているので、これを利用してソフトの一覧ページは作れそうです。

「テーブル」や「メディアテキスト」などで、なんとか作れそうですが、ちょっとやってみた感じでは思っているようなページにするには難しそうです。
リンク集を作るプラグインもあるようですが、こっちもいろいろ面倒そう！？
結局自分で「HTML」を書いたほうがよさそうです。
HTMLは以前ちょっとだけ触った経験がありますが、もう忘れてしまっているので再挑戦です。
練習問題としては、ちょうどいいかもしれません。
HTMLは、ネット上に情報がたくさんあるので、リンク集程度のページを作るには、不自由しないですね。

HTML

ページのイメージとしては、左側にソフトのスクリーンショットがあって、その画像は記事にリンクさせます。
次に簡単な説明文、さらに次の列にダウンロードリンクがあるようなイメージです。
そうなると、やっぱり表になりそうです。
忘れてしまっていたので探してみて、
このサイトを参考にさせていただきます。
こちらのサイトもとても参考になりました。
HTMLで表を作るのは、<table>タグを使います。
さらに、<tr>から</tr>の間に、行の情報。
<td>から</td>の間に、列の情報を書いて行きます。
最初の<td>を<th>にすれば、見出しになるようです。
ちょっと、かいてみましょう。

<table>
  <tr>
    <th>ソフト</th>
    <th>概要</th>
    <th>ダウンロード</th>
  </tr>
  <tr>
    <td>G90G91Convert</td>
    <td>G90をG91に変換する</td>
    <td>https://www.vector.co.jp/soft/winnt/business/se521023.html</td>
  </tr>
</table>

これを、「html_test01.html」と言うファイル名で保存して、Edgeなどブラウザで表示させてみました。

予定通り、最初の行が表題になり、次の行で３列の表になってくれました。

ブロックエディタは自動的に属性が付く

これを、「WordPress」の「ブロックエディタ」の「HTML」モードにコピペしてみると、

ソフト概要ダウンロード
G90G91ConvertG90をG91に変換するhttps://www.vector.co.jp/soft/winnt/business/se521023.html

自動的に、属性を付けてくれて、より表らしくなりました。
表らしくはなりましたが、スタイルの変更はどうやってやるんでしょう？
「WordPressテーマ」の「CSS」の変更でできそうですが、他への影響も考えられるのであまりやりたくないです。
自分用の「CSS」を用意しようと思います。
通常スタイルは「CSS」を追加して変更していきますが、「WordPress」の場合どこに書くのでしょう？
こちらも、少し調べてみようと思います。

VSCode(Visual Studio Code) の Emmet

その前にタグを書いていくわけですが、「WordPress」の「HTML」モードでも、書いていくことは可能です。
ただ、「HTML」は文字や画像を＜タグ＞と＜／タグ＞ではさむのが基本ですし、今回の表のような場合には同じようなコードを何度も書くことになります。
面倒だな～と思っていたところ、このサイトでもFusion360のポストプロセッサの記事で紹介した、「VSCode」が「HTML」を書くのにも非常に便利だとの情報を見つけました。
https://blog.proglus.jp/3461/
https://qiita.com/tedkuma/items/67876e6be3369b0e730c
https://b1tblog.com/2019/10/23/vscode-html/
https://pouhon.net/html-emmet/430/
ここを参考すると、「Emmet」という強力な機能があるようです。
タグではさむ場合は、「<」は省略して、タグ名だけ書いて「Tab」キーを押す事で完成させてくれますし、
タグ名も途中まで書いただけで、補完して希望の候補を表示してくれます。
さらに、タグ名を「>」で繋げる事で一気にかけたり、「*」で同じタグを複数書けたりするようです。
例えば

table>tr>th*3

このように書くだけで、補完内容が表示されます。

ここで、「Tab」キーを押すと、一気に書きだしてくれます。

いやぁ、便利ですね～
さらに、「スニペット」と言うのを登録するを、自作もできるそうです。
https://tt-computing.com/vscode-user-snippets

CSS

見栄えを編集するには、「CSS」を使います。
通常「CSS」を書く場所は、３種類あるようです。
・外部ファイル
・<head>～</head>の中の<style>～</style>タグ内
・<p>などのタグに、直接書く（インライン）
このなかで、「外部ファイル」を用意するのがスッキリしそうですが、
「WordPress」の場合、テーマを自由に選択でき、サイトの外観を簡単に変更する事ができます。
したがって、外観を制御する「CSSファイル」もインストールした各テーマ内のファイルを追加・編集するようです。
一つのページのスタイルだけのために、これはちょっと面倒です。
かと言って、インラインに直接書いた場合、同じ設定のタグが複数ある場合、修正する場合大変です。
私は、<style>タグに書くことにしました。
まずは、VSCode で新規ファイルを開きし、「html」の拡張子で、適当なファイルを作成します。
まっさらな状態で「Emmet」を使ってみましょう！
「　!　」キーを入力し、「TAB」キーを押すと、すごいです、瞬時にHTMLのひな型が出来てしまいます。

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>

</body>
</html>

ここの、</head> の上部に<style>を追加して行こうと思います。

こちらを参考にさせていただきました。

<style>タグ

参考に<style>　～　</style>の間に、書いて表示させてみます。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
  <style>
    table {
      border-collapse: separate;
      border-spacing: 5px;
      width: 100%;
    }
    table th {
      background-color: purple;
      border: solid 1px blue;
      color:white;
      border-radius: 10px;
      text-align: center;
      padding: 10px 0;
    }
    table td {
      background-color: lightblue;
      border: solid 1px blue;
      border-radius: 10px;
      text-align: center;
      padding: 10px 0;
    }
  </style>
</head>
<body>
  <table>
    <tr>
      <th>ソフト</td>
      <th>概要</td>
    </tr>
    <tr>
      <td>G90G91Convert</td>
      <td>G90をG91に変換する</td>
    </tr>
  </table>
</body>
</html>

この表示は別のブラウザで表示させたものを、切り取った画像ですが
単独のHTMLファイルでは、思ったようなスタイルになりました。
ところが「WordPress」のブロックエディタに組み込むとうまく反映されず、
逆に、別のところにこのスタイルが反映されていたりしました。
既存のスタイルと混同してしまったのかもしれません。

これも、ブラウザで表示した画像を切り取ったものですが、表のタイトルが標準のスタイルになっています。
逆に、サイドバーのカレンダーに影響を与えてしまっています。

クラス属性

そこで、<table>や<td>のタグに、クラス属性を付けてみます。
<table>タグにクラス属性を付けるには、「CSS」で「.」に続いてクラス名を書きます。
使用するときは、「<タグ名 class=”クラス名”>」とします。
上の例では、<table>を<table.kazuban> <table th>を<table.kazuban th>と変更してみました。
クラスを利用するには、「class=”クラス名”」とします。
今回の場合には、「<table class=”kazuban”」としました。

Document
ソフト 概要
G90G91Convert G90をG91に変換する

この表示は、「WordPress」ブロックエディタの「HTML」モードへ書き込んだデータです。
したがって、上部二つの例の画像表示ではなく、「HTML」を直接ブラウザを通して表示させています。
クラス属性を付ける事で、思ったスタイルになりました。
こんな感じで、「フリーソフト」ページを作成しました。

固定ページで登録しました。
最上部メニュー「フリーソフト」からもアクセスできます。

まとめ

久しぶりに、「HTML」を使ってみました。
「HTML」は＜タグ＞と＜/タグ＞で閉じなければいけなくて、表を作成する場合は同じようなコードをいくつも書かなければいけません。
ところが、「VSCode」の「Emmet」を使うと、一気に書いてくれます。
さらにスタイルに重要な色データも、プルダウンで目確認しながら選択でるのでとても便利です。
最初から自分で書き上げる場合は問題ないでしょうが、「WordPress」内で「CSS」を使用する場合には、すでに「WordPressテーマ」内で「CSS」が定義されているので、場合によっては希望しない影響がでる事もありそうです。
スタイルを追加する場合には、自分専用のユニークなクラス属性を使た方がよさそうです。

]]> CentOS8 でミラーサイトを作る／WordPress のバックアップ https://www.kazuban.com/blog/mirror-site-v2/ Sun, 22 Mar 2020 00:36:31 +0000 https://www.kazuban.com/blog/?p=1992 前回、Webサーバーの設定まで終了したので、WordPress をインストールして、このサイトのミラーサイトにしておこうと思っています
まずはWordPress を動作させるに、PHP と　MySql　をインストールしますが、以前とそれほど変わらないと思っています。

WordPress インストール

PHP 、MariaDB、WordPress とインストールしていきます

PHP7.3 のインストール

centOS8 のデフォルトは、PHP7.2なので、remiレポジトリを導入しPHP7,3をインストール

# dnf -y install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
# dnf module disable php
# dnf module install -y php:remi-7.3
# php -v

php-fpmの起動

# cp -p /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf.org
# vi /etc/php-fpm.d/www.conf
  ・
  ・
 listen.owner = apache
 listen.group = apache
 listen.mode = 0666


# systemctl start php-fpm
# systemctl enable php-fpm
# systemctl is-enabled php-fpm
 enabled

PHP 基本的な設定

# cp -p /etc/php.ini /etc/php.ini.org
# vi /etc/php.ini
 expose_php = Off
 post_max_size = 80M
 upload_max_filesize = 80M
 date.timezone = "Asia/Tokyo"
 mbstring.language = Japanese
 mbstring.internal_encoding = UTF-8
 mbstring.http_input = UTF-8
 mbstring.http_output = pass
 mbstring.encoding_translation = On
 mbstring.substitute_character = none 

$ php -r 'phpinfo();' |  grep 'PHP Version'
PHP Version => 7.3.15

MariaDB 10 のインストール

$ dnf list | grep maria

centOS8 になり、デフォルトで「MariaDB 10」が導入されているので、そのままインストール

# dnf install -y mariadb-server mariadb mariadb-devel
 完了しました!

# systemctl restart mariadb
# systemctl status mariadb
# systemctl enable mariadb

mysql_secure_installationの実行

管理者パスワードは、事前に決めてメモしておく
　　 ★管理者パスワード　：　 hogehoge_passwd
このパスワードは、mysql コマンドで「root」ユーザーのパスワード となる

$ sudo mysql_secure_installation
・
Set root password? [Y/n] y                <--------------- 管理者パスワード
Remove anonymous users? [Y/n] y       <--------- 匿名ユーザー削除
Disallow root login remotely? [Y/n] y     <----- リモート管理者ログイン拒否
Remove test database and access to it? [Y/n] y <---- test データベース削除
Thanks for using MariaDB!

文字コードの設定

# cp -p /etc/my.cnf.d/mariadb-server.cnf /etc/my.cnf.d/mariadb-server.cnf.org 
# vi mariadb-server.cnf
   ・
   ・
 [mariadb]                 <------ 追加  character-set-server = utf8mb4 
 [client-mariadb]          <------ 追加  default-character-set =　utf8mb4 

# systemctl start mariadb 
# systemctl status mariadb

データベースにアクセスし、確認

$ mysql -uroot -p「★管理者パスワード」
MariaDB [(none)]> show variables like "chara%";
 +--------------------------+------------------------------+
 | Variable_name            | Value                        |
 +--------------------------+------------------------------+
 | character_set_client     | utf8mb4                      |
 | character_set_connection | utf8mb4                      |
 | character_set_database   | utf8mb4                      |
 | character_set_filesystem | binary                       |
 | character_set_results    | utf8mb4                      |
 | character_set_server     | utf8mb4                      |
 | character_set_system     | utf8                         |
 | character_sets_dir       | /usr/share/mariadb/charsets/ |
 +--------------------------+------------------------------+

MariaDB [(none)]> quit
 Bye

WordPress インストール

centOS7時の記事を参考に、インストール

自宅サーバでWordPressを動かそう。インストール
前回までで、WordPress要求の PHPバージョン7.3以上、MySQLバージョン5.6またはMariaDBバージョン10.0以上の環境は出来上がっています。いよいよ、WordPress をインストールしようと思います。環境の確認インストール状況を確認するには、「rpm -qa 」や「yum l…
www.kazuban.com
2019.11.12

バックアップ

とりあえず、WordPress は動作したと思うので、本サーバーのバックアップをしていきます、

WordPress データベースのバックアップ

本サーバー側で作業していきます
まずは、バックアップを保存するディレクトリを作成し、データベースをバックアップ。データバースの、ユーザ名、ホスト名、パスワードは事前に明確にしておきます

  • データベース名　　　　　｜ WpDb
  • ユーザー名　　　　　　　｜ WpAdmin
  • パスワード　　　　　　　｜ WpPasswd
  • データベースのホスト名　｜ localhost

「mysqldump」でバックアップ

・バックアップ作業用ディレクトリを作成
・本サーバーでデータベースをすべてバックアップ
・ミラーサーバーへコピー
・ミラーサーバーのデータベースをリストア
・WordPress の設定をミラーサーバー用に変更

//バックアップ作業用ディレクトリ作成
$ cd ~
$ mkdir ./Backup
$ cd ./Backup/

//本サーバーでバックアップ
$ mysqldump -u  WpAdmin -pWpPasswd  -h localhost -A > WordPress.bak

//バックアップファイルをミラーＰＣへコピー
// SSH のポート番号　54321 の場合
$ scp -P 54321 ./WordPress.bak 192.168.0.100:
Enter passphrase for key '/home/hogehoge/.ssh/id_ecdsa':

//ミラーサーバーのデータベースをリストア 
$ mysql -u root -p WpDb  < WordPress.bak
 パスワード：  <-- データベースのパスワードではなく、mysql の　root パスワード

これで、データベースのコピーは終了したが、WordPress の設定情報も更新されています。
したがって、本サーバーとミラーサーバーでは、アドレスが違うためミラーサイトへ直接のアクセスしても、内部的には本サーバーのURLで動作するので、正常に表示されません
データベースのWordPresのURL設定を変更する必要があります
変更方法は、mysqlのデータバース内容を直接変更する方法と、wordpressの設定ファイルで変更する方法を紹介します。
後者の方が簡単で通常のページは正常になりますが、投稿編集などの画面が英語になったり、保存できなかったりすることがあります
その場合は、①前者の作業で治ります。

ミラーサイトのURL情報を変更：①mysql で設定の情報を書き換える

//ミラーサイトでの作業
$ mysql -u root -p「rootパスワード」
 MariaDB [(none)]> show databases;
 +--------------------+
 | Database           |
 +--------------------+
 |  WpDb              |
 | information_schema |
 | mysql              |
 | performance_schema |
 +--------------------+
 4 rows in set (0.001 sec)
 MariaDB [(none)]> use WpDb
 MariaDB [WpDb]> select * from wp_options where option_name = "siteurl";
 +-----------+-------------+------------------------------+----------+
 | option_id | option_name | option_value                 | autoload |
 +-----------+-------------+------------------------------+----------+
 |         1 | siteurl     | http://www.hogehoge.com/blog | yes      |
 +-----------+-------------+------------------------------+----------+
 1 row in set (0.000 sec)
 MariaDB [WpDb]> select * from wp_options where option_name = "home";
 +-----------+-------------+------------------------------+----------+
 | option_id | option_name | option_value                 | autoload |
 +-----------+-------------+------------------------------+----------+
 |         2 | home        | http://www.hogehoge.com/blog | yes      |
 +-----------+-------------+------------------------------+----------+
 1 row in set (0.000 sec)

//次のコマンドで、www.hogehoge.com を www2.hogehoge.com に変更する
 MariaDB [WpDatabase]>update wp_options SET option_value = "http://www2.hogehoge.com/blog" where option_id = 1 OR option_id = 2;

ミラーサイトのURL情報を変更：②wp-config.phpを編集する

#サーバーでの作業
#ブログのディレクトリへ移動
cd /home/www/html/blog/
# wp-config のバックアップを取る
sudo cp -p wp-config.php wp-config.php.bak

#編集
vi ./wp-config.php

#最後の行に、URL情報を追加
####
####
define('WP_HOME', 'http://www2.hogehoge.com/blog/');
define('WP_SITEURL', 'http://www2.hogehoge.com/blog/');
###
###
#保存

確認: 新しいURLで管理画面にログインし、「設定」>「一般」でURLが正しく認識されているか確認します。 

メニューの「カスタムリンク」でうまく設定できない場合がありました

私の環境では、バックアップURLでほぼ正常に動作しましたが、一部のリンクで本サーバーURLへリンクされる場合が確認されました
調べてみると、必ずＮＧではないですが「カスタムリンク」でそのような現象が起きてます
カスタムリンクでは、「URL」項目に直接リンク先URLを設定しますが、そこに本サーバーのURLを設定している場合、うまく変換されず本サーバーへリンクしてしまう現象です
このリンク先のURLを相対パスにすることで、とりあえずは治りました

#カスタムリンク
https://www.hogehoge.com/blog/
    #　↓
    #相対アドレスへ変更
/blog/

これで、ミラーサイト（www2.hogehoge.com）でも本サーバーと同様にWordPress にアクセスできるようになりました

wp-content をバックアップ

投稿記事内容は、mysql に保存されていますが、テーマやアップロードしたメディアなどは、wp-content ディレクトリに保存されているようなので、これもバックアップします。
・WordPress インストールディレクトリへ移動
・tar コマンドで圧縮
・ミラーサイトへコピー
・ファイルをミラーサイトの作業ディレクトリへ移動
・展開
・展開された、wp-content ディレクトリをhttpd ユーザーアカウントに変更
・ミラーサイトのwp-contentディレクトリの名前変更
・作業ディレクトリのwp-content を移動

// wp-content をバックアップ
# cd /home/www/html/blog
# tar cvzf blog.tar.gz ./wp-content/

// blog.tar.gzを作業用のディレクトリに移動
# mv blog.tar.gz /home/hogehoge/Backup/

// アカウントの変更
# chown hogehoge.hogehoge blog.tar.gz

// ミラーサイトへコピー
# exit
$ cd /home/hogehoge/Backup/
$ scp -P 54321 ./blog.tar.gz 192.168.0.100:
Enter passphrase for key '/home/kazu/.ssh/id_ecdsa':

// ミラーサイトで作業
// ユーザーホームディレクトリにコピーされている
// 作業ディレクトリへ移動
$ mv ./blog.tar.gz ./Backup/
$ cd ./Backup/

// 展開
$ tar xvzf ./blog.tar.gz

// 展開されたディレクトリをhttpd ユーザーアカウントに変更
 $ sudo chown -R apache.apache ./wp-content/

// wordpress ディレクトリへ移動し、バックアップディレクトリ名を変更
$ cd /home/www/html/hogehoge.com/blog/
$ sudo mv wp-content wp-content.org

// オリジナルのディレクトリを移動
$ sudo mv ./wp-content /home/www/html/hogehoge.com/blog/

これでミラーサイトのWordPress にログインできるはずなので
wordpress の「設定」⇒「一般設定」を確認

]]>