最終的にやったこと
Webサーバーをリプレースした
元々は CentOS7 だったが、あるコンポーネントの都合で Alma Linux 8 に変更した
導入したい理由
さくらブログ を利用していたが、「3月で新規受付終了」のメッセージが常に出る
この文から察するに さくらインターネットはブログ運用はもうやめたい 雰囲気を感じるので、利用できる場所を探した
あとさくらブログの記事編集はレガシーなので、近代化したインタフェースにしたいというのもある
WordPress の存在は知っていたが、昨今それ以外のもあるのかと思って調べた
しかし，結局 WordPress に行き着いたので重い腰を上げて導入を開始
ちなみに Twitter で下記を提案いただいたので紹介だけ
300円で WordPress が一瞬で作れるので、自宅サーバー勢にもおすすめ
⇒ 【AWS】Amazon Lightsail の”意外”な落とし穴 https://www.twinfami.com/amazon_lightsail_cpu_credit
導入開始
まずは すでにあるサーバーに単純に WordPress を突っ込んでみる
・・・がその前に DB に専用のデータベースが必要
ということで、 mariadb にWordpress用のデータベースと、フルアクセスできるユーザを追加した
create database [WordPress用のDB名] default charset utf8mb4;
grant all on [WordPress用のDB名].* to '[DBにアクセスするユーザ]'@'localhost' identified by '[パスワード]';WordPress を DL してアップロード、ルートにアクセスして手続きを開始する
ちなみに、データベースのホスト名指定は「localhost」ではなく「127.0.0.1」にすること
ここで、WordPressがディレクトリのルートにアクセスできないと wp-config.php をお前が作れと言い出す
手動で作っても良いが、ディレクトリの所有者やパーミッションを調整すること
で初期設定を進めていき、設定が終わったところで
このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメール受信ボックスを確認してください。
というメッセージが wp-admin が出す
これの詳細を調べる場合、wp-config.php にてデバッグ有りを設定する
define( 'WP_DEBUG', true );すると理由がわかる
私の場合は下記だった
Fatal error: Uncaught Error: Call to undefined function gzinflate() in ～(省略)
これは gzip の命令が無いとのエラーメッセージとなる
私はPHPを手動コンパイルしていたので、コンポーネント不足が起こることもある
これについては、PHP を –with-gzip をつけて再コンパイルした
この時に PHPを 7 から 8 にバージョンアップをした
一旦導入は完了したが・・・
WordPress には サイトヘルス というサイトの状態を見る機能がある
それで分析すると大量の「推奨モジュールが存在しません」が出ている
これは今見たもの、imagickが入ってないのはいずれ対処しよう
それを解決するには、PHPのコンパイルし直しとなる
が・・・これが非常に大変な作業となる
設定当初のサーバー(CentOS7) では、私は 全部makeでコンポーネントを導入する ということをしていたので、
PHPのコンパイルに必要なライブラリ群も手動導入が必要となる
この量がとても多くなるので大変
で、途中で折れて phpenv による導入、また各コンポーネントはdnfによる導入を開始するが、
CentOS7 の libzip のバージョンが古く、phpenv (8.0.10) によるビルドが通らない
makeによるコンポーネント導入とdnf導入が混同するカオスな環境となりつつある上、CentOS7がレガシーになっているのもあって、
Alma Linux 8 への乗り換えを敢行
大変な移行作業
まあ、当然移行は大変であって手数を必要とした
ただ、設定ファイルの移行、サービスの定義の転写 などをするだけで大半は稼働したので、最初から構築よりは早かった
以降においていくらか苦難があったので下記に示す
mariadb のユーザ移行
5のいくらかから、5の最新 への移行は、mysql.user のダンプではできない
というのも5の最新では mysql.user はビューに変更されているから
手段としてはDBのファイル自体を持っていって mysqlのアップデート用のスクリプトを動作させるらしいが、
私は show grants などを用いて手動移行を行った
個人だからユーザ数も少ないため
PHP8 導入について
phpenv を用いて導入はするのたが、AlmaLinux8 には oniguruma-devel が提供されていない
リポジトリ導入をしたかったが、こればっかりはどうにもならなさそうなので oniguruma は手動コンパイルすることにした
・・・ということをするんだった 旧環境でも libzip を手動コンパイルすれば良かったとは思う
oniguruma
https://github.com/kkos/oniguruma/
dnf -y install wget unzip autoconf automake libtool make
wget https://github.com/kkos/oniguruma/archive/refs/heads/master.zip
unzip master.zip
cd ./oniguruma-master
autoreconf -vfi
./configure --prefix=[prefixは必要ならば設定] --disable-dependency-tracking
make -j
make installphpenv install を仕掛ける前に oniguruma の PKG_CONFIG_PATH を export すること
不要コンポーネント削除によるOS起動不可
導入完了後、gcc とかは不要なので削除したが、再起動するとOSが上がらなくなった
tar とかも勝手に削除することがあったので、Alma Linux 8 では導入したコンポーネントは削除しないほうが良い
対処としては、スナップショット巻き戻しからのそこからやり直しをした
スナップショットを取れない場合は1からやり直しを
nginx がOS起動とともに上がってこない
nginx のサービス起動順がおかしいので、設定を変える
vi /usr/lib/systemd/system/nginx.service
[Unit] を変更
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network-online.target remote-fs.target nss-lookup.target
Wants=network-online.targetいろんなサイトがちゃんと出力されない
https://extrose.stoicsounds.jp/ とか、今は出る
PHPを 7から8にした都合で、連想配列の指定が統一?されたため
$array{'hash'}; // ← これはPHP8ではだめ
$array['hash']; // ← これからはこれ (要は {} ではなく [] を使う)dokuwiki もちゃんと出ない
上記同様
Gregtech6 のwiki https://extrose.stoicsounds.jp/_gregtech6 では Dokuwikiを採用している
対処法は無いかと思ったが、Develop版でアップグレードすると一先ず表示された
Develop版なので不具合があるかもしれない
ちなみにアップグレードは単純に上書きによって行った
やる前に念の為のバックアップをお忘れなく
stable版はphp7なので、dokuwiki 利用を想定する場合、phpは7にすること
ちなみにWordPressは8対応
PHPのセッション情報がちゃんと保存されない
php.iniでセッションを保管するフォルダは指定しており、該当フォルダへのパーミッションは正常だがこの症状が出る
phpinfo を見てもphp.ini の値はちゃんと適用されている様子
nginx の設定でphpのログを取るようにしたところ、想定とは全く異なる場所へセッション情報を保存しようとしていた
該当の箇所の所有者を php-fpm サービス実行者 に変更して対処した
php.iniの値が採用されない理由については要調査
WordPressの各種操作でftp認証が要求される
テーマ導入、プラグイン導入など
先述した WordPress以下の所有者変更を行わないとこうなる
つまるところ、Wordpress 自身が、自身のフォルダへのアクセス権が無いことが原因
所有者なりパーミッションなりを調整すること
リンクがおかしい
リンクというのは各記事ページなど
私は自宅サーバーで運用しているので、ローカルから接続するホスト名と、外部から接続するホスト名が異なる
ローカルから接続するホスト名で設定していった都合で、外部から接続する人にもそのホスト名が採用されており、外部からは正しく参照されない状況となっていた
これは設定⇒一般 にある WordPressアドレス と サイトアドレス を補正することで解決した
・・・が、サイトヘルスにて REST API エラーとかが表示されるようになったので、この辺りはいずれ解決しなければならない
さくらブログからの移行
さくらブログには エクスポート機能がある
Movable Type 形式で出力される
WordPressで取り込むときは、Movable Type 用のインポートプラグインを導入した後にインポートしていく
画像リンクについてまでは自動解決してくれないので、画像の張替えは手動で
・・・ただ面倒なので普通はやらないと思う
ちなみにさくらブログの画像ファイルの一括ダウンロードはサイト機能にはない
ftpでサーバーへ接続してダウンロードしにいくこと
ということがあって現ブログ運用となる
こういうめんどくさいことが嫌な人は、最初に紹介した記事に従って、AWS lightsail の WordPress インスタンス利用をおすすめする
サーバー維持保守もAmazonくんがやってくれるしね