WordPressの構築

01 / 前提とWordPressの取得

Nginx、PHP-FPM、MariaDBを同じUbuntu Server 22.04へ導入済みであることが前提です。公開用ドメインを使う場合はHTTPSの設定を先に終えてください。管理者のパスワードやDB情報をインターネット上のHTTP接続で送信しません。

ここでは新規の専用サイト/var/www/server-guide/publicへ導入します。既存のサイト・既存のWordPress・既存DBの上書きは対象外です。コードとDB、必要なら既存のNginx設定を、Web公開領域の外へ退避してから作業します。

取得前にWordPress公式要件と利用するテーマ・プラグインの対応範囲を確認します。今回取得したWordPress 7.1.4の最低要件はPHP 7.4・MySQL 5.5.5でしたが、推奨環境はPHP 8.3以降・MariaDB 10.6以降です。Ubuntu 22.04公式パッケージのPHP 8.1は推奨PHPより古く、Ubuntu側のセキュリティ保守とアプリの互換性を別々に確認します。新しい本番環境では新しいOS/PHPの採用も検討してください。

一般管理者のシェルで、作業用ディレクトリーへ公式配布ファイルを取得します。latest.tar.gzの内容は変わるため、実際に取得したバージョンを記録します。

WORKDIR="$(mktemp -d)"
curl --fail --location --proto '=https' --tlsv1.2 \
  --output "$WORKDIR/wordpress.tar.gz" https://wordpress.org/latest.tar.gz
sha256sum "$WORKDIR/wordpress.tar.gz"
tar -xzf "$WORKDIR/wordpress.tar.gz" -C "$WORKDIR"
grep -E '^\$(wp_version|required_php_version|required_mysql_version)' "$WORKDIR/wordpress/wp-includes/version.php"

HTTPSによる公式配布元への接続を検証し、ダウンロード失敗や証明書エラーを無視しません。ここで計算するSHA-256は取得物の記録であり、それだけで配布元の署名を検証したことにはなりません。撮影用の取得物は7.1.4、SHA-256は881e53a4681ff2cd911651b11cccdede5ae477ddf0765af5d6a1a8b219a1d835でした。別バージョンへこの値を流用しません。

02 / コードと接続設定を配置する

このサイト専用の公開ディレクトリーへ配置します。wp-config.phpがすでに存在する場合は、既存サイトかどうかを調べ、以下の新規導入は中止します。

sudo test ! -e /var/www/server-guide/public/wp-config.php &&
sudo cp -a "$WORKDIR/wordpress/." /var/www/server-guide/public/ &&
sudo chown -R root:root /var/www/server-guide/public &&
sudo find /var/www/server-guide/public -type d -exec chmod 755 {} + &&
sudo find /var/www/server-guide/public -type f -exec chmod 644 {} +

Webプロセスへコード全体の書き込み権限を渡しません。次は同名設定ファイルがないと確認できた場合だけ実行し、サンプルから権限を絞って作成します。

sudo test ! -e /var/www/server-guide/public/wp-config.php &&
sudo install -o root -g www-data -m 640 \
  /var/www/server-guide/public/wp-config-sample.php \
  /var/www/server-guide/public/wp-config.php &&
sudoedit /var/www/server-guide/public/wp-config.php

エディターで下の項目を自分の値に置き換えます。DB_HOSTはlocalhostです。PHPは同じマシンのUnixソケットでMariaDBへ接続します。パスワードは前のページで専用ユーザーへ設定した値を使い、シェルのコマンド引数や公開ログへ書きません。

サンプルにある認証用キーとsaltも、WordPress公式の生成サービス等から得たサイト専用の値で置き換えます。生成値と設定ファイルは秘密情報なので、画面共有・チャット・リポジトリへ貼り付けません。設定ファイルの「編集をやめる」コメントより前へdefine('DISALLOW_FILE_EDIT', true);も追加し、管理画面のコード編集を無効にします。

sudo chown root:www-data /var/www/server-guide/public/wp-config.php
sudo chmod 640 /var/www/server-guide/public/wp-config.php
sudo install -d -o www-data -g www-data -m 755 \
  /var/www/server-guide/public/wp-content/uploads
sudo php8.1 -l /var/www/server-guide/public/wp-config.php

構文検査が成功することを確認します。WordPressが書き込めるのはアップロード用ディレクトリーだけです。コード全体をwww-data所有へ変えたり、chmod 777で解決したりしないでください。

03 / NginxをWordPressへ接続する

既存のサイト設定を退避し、/etc/nginx/sites-available/server-guideの対象serverブロックを編集します。HTTPSを導入済みなら、443番側のルート設定を修正し、証明書設定や80番側のHTTPS転送を残してください。以下は追加・変更する箇所です。同じlocationを重複させず、元のPHP設定と置き換えます。

root /var/www/server-guide/public;
index index.php index.html;

location / {
    try_files $uri $uri/ /index.php?$args;
}

location = /wp-config.php {
    deny all;
}

# 汎用PHP locationより前に配置する
location ~* ^/wp-content/uploads/.*\.php(?:/|$) {
    deny all;
}

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}

fastcgi-php.confを使うUbuntu標準構成の例です。try_filesによる存在検査も同スニペットに含まれます。PHPバージョンを変えた場合は実際のソケット名へ合わせます。前のページで設定した隠しファイルの拒否なども維持します。

sudo nginx -t && sudo systemctl reload nginx
systemctl is-active nginx
systemctl is-active php8.1-fpm

構文検査が失敗したら再読み込みせず、エラーの場所を修正します。Webページが502ならFPMの状態とソケット、403ならファイル/ディレクトリー権限、404ならルートと設定対象のserverブロックを確認します。ログは/var/log/nginx/error.logとsudo journalctl -u php8.1-fpm -b --no-pagerで調べます。

04 / ブラウザーで初期設定する

管理端末から自分のサイトのhttps://ドメイン名/を開きます。証明書の警告がないこと、意図したサイトへ接続していることを確認します。ドメインが未定でローカル検証する場合だけ、信頼できる隔離管理ネットワーク内のHTTPを使います。外部へ公開する前にHTTPSへ切り替えてください。

1. 言語の選択画面が出たら利用する言語を選び、続行します。すでにwp-config.phpを作ったため、DB接続情報の入力画面は通常省略されます。
2. サイトのタイトル、管理者ユーザー名、強い固有のパスワード、管理用メールアドレスを入力します。画面例や固定の共通パスワードは使いません。
3. 公開前は検索エンジンへの表示を抑制する設定を選べますが、これは認証やアクセス制限ではありません。非公開サイトには別途アクセス制御が必要です。
4. 「WordPressをインストール」を実行し、完了画面から作成した管理者でログインします。
5. 管理画面とサイト表示の両方を確認し、設定のサイトURLが意図したHTTPSのURLかを調べます。ドメインやURLを変更する場合は、先にバックアップと復旧方法を用意します。

DB接続エラーなら、前ページの専用ユーザーで接続できるかとwp-config.phpの値を照合します。PHPのmysqli拡張がない場合はPHPページのパッケージとFPM再起動を確認します。設定ファイルを書けない場合でも、公開ディレクトリー全体の権限を緩めないでください。

確認用のPHPファイルは残さず、存在しないPHPが404、/wp-config.phpが拒否されることも確認します。アップロード先のPHP実行も拒否される設定を維持します。

05 / 更新・バックアップ・検証範囲

不要な初期プラグイン・テーマを整理し、利用するものの配布元・対応PHP・更新状況を確認します。コードはroot所有のため、管理画面からの本体/プラグイン/テーマ更新は書き込み権限が足りず完了しない構成です。FTP等の資格情報を求められても、サーバー管理用の資格情報を入力して解決しません。管理者が保守時間にバックアップを取得し、検証した更新コードを配置する方針と担当者を決めます。

バックアップはDB、wp-config.phpを含むコード、アップロードを一組として、Web公開領域/Gitの外へ保存します。以下は稼働状態を考慮した保守時間に実行する保存例です。ファイルとDBの整合性を保ち、別の環境で復元できることも確認してください。作成できただけでは復元検証になりません。

BACKUP="$(sudo mktemp -d /root/wordpress-backup.XXXXXX)" &&
sudo cp -a /var/www/server-guide/public "$BACKUP/files" &&
sudo sh -c 'umask 077; mariadb-dump --single-transaction wordpress_db > "$1/database.sql"' sh "$BACKUP"
printf '保存先: %s\n' "$BACKUP"

サーバー障害にも備えて暗号化した別媒体への保存と保持期間を決めます。公式の更新手順、バックアップの公式資料も確認してください。

Ubuntu Server 22.04.5の実VMでWordPress 7.1.4を導入し、ブラウザーの初期設定完了、管理者ログイン、ダッシュボード、トップページのHTTP 200と初期投稿を確認しました。公式配布物の3,782ファイルは、公式APIのファイル別チェックサムとも一致しました。撮影は隔離した管理用SSHトンネル内のHTTP接続です。wp-config.phpとアップロード先・隠しパスのPHPは403、削除済みの確認用PHPと存在しないPHPは404でした。サービス再起動後の表示も確認しています。ファイルとDBのバックアップを保存し、SQLを検証用の別DBへ読み戻して12テーブルとサイト名を確認しました。これはWebサイト全体の災害復旧やファイル復元までの実証ではありません。

利用するドメインが未定のため、実ドメインのDNS設定とLet's Encrypt証明書の発行は未検証です。ローカルで表示できても、インターネット上の公開・HTTPS・メール送信・バックアップ復元が完了したとは扱いません。