表題の通りウェブサーバーの立て直しです。さくらVPS上でCentOS Stream9版KUSANAGI9が使えるようになったらしいのでこの際VPSのOSごと再インストールしていきます。
何をしなくちゃいけなかったのか・ありがちな手順から何を変えたのか、そういうことを毎回忘れちゃうのでできるだけ記録に残した方がいいよなと思い、何を参考にしたのかとかも含め書いていければと思います。読み返せば淡々と書かれたつまらない記事です。
これをここに書けているということは作業が完遂されたことを意味しますが、この通りにすれば他の環境でもうまくいくというものでは全くないのであしからず。また、この記事の大量のリンクはその多くが比較的近いうちにリンク切れとなるリスクの高いリンクであることに留意頂きたい。EOLしたドキュメントなんて残されないよねって話。
Contents list
移行前の準備
今回はVPSのOS再インストールということで、望ましくないのですが既存のサーバー自体が消し飛んでしまいます。別でVPSを立てて移行するのが理想ですが低予算なのでやむを得ません。ここでやり忘れがあると、もう戻せないので慎重に。
悲しい裏事情
移行前のOSなんですがCentOS Stream8版KUSANAGI9を使用してました。そう、同じKUSANAGIなので実はkusanagi migrateコマンドが使えるんです。これを使えば簡単に移行が出来る…そのはずでした。
簡単に言うと、偶然このバージョンに限ってkusanagi migrateコマンドが実行できなかったんですね。そうとは知らず、何か環境に対して行ったカスタマイズが悪くコマンドが使えなくなったと思い込んだ私はすべてを手動で移行したわけです。アップデートが配布されそれがバグであったことを知った時にはすべての作業が完了しておりました。
ドキュメントルートのバックアップ
KUSANAGI9のドキュメントルートは/home/kusanagi/<profile>/DocumentRootですのでこれをそのままzipアーカイブにしてダウンロードしておきました。
そう、WordPress環境なんかはドキュメントルート外にバックアップすべきファイルがあったりしませんか？忘れないでね。
データベースのバックアップ
“2.6.1. mariadb-dump を使用した論理バックアップの実行”に則りWordPressのデータベースを.sqlファイルにバックアップしました。
mariadb-dump --databases tellaresdo > tellaresdo.sql
その他のバックアップなど
データとしてバックアップしたのはこの程度ですが、個人的にカスタマイズした設定やパーミション等をメモしておいた方がいいです。KUSANAGI9のWAFを使う人などはわかってるとは思いますがnaxsiのログ等も忘れずに。
VPSのOSを再インストール
OSを再インストールします。これ以降引き返せません。
上記KUSANAGI9の公式ドキュメント通りにやっていけば…と書くはずだったんですがこちらのドキュメントはCentOS Stream 8版の情報です。CentOS Stream 9版は変更点が若干あるので下記、さくらVPSのCentOS Stream 9のドキュメントと併せて読んだ方がいいです。CentOS Stream 9用に追記が入りました。1
わかりやすいところだとデフォルトユーザーはrootではなくなりました。なんならrootユーザーはデフォルトで無効化されており、centosユーザーにsudoersが付与されている構成になります。rootで実行する必要があるコマンドもcentosでログインした上でsudoでコマンドを実行する形になります。
また、SELinuxに関してはデフォルトでPermissiveですが、カーネルパラメータで無効化されています。
移行先の作業
スワップ領域の作成
メモリの少ないVPSではこれをしないとdnfが動いてくれないんです。私のVPSはメモリ1GBの安いプランなのでdnfが途中でKilledされてしまい、なんでだろうって思ったらこれを忘れてました。
sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab
なお、KUSANAGI9の推奨メモリ量は4GBなのでKUSANAGI9の全力は発揮できない環境です。CDN通すのであまり関係ないのですが。
IPv6の有効化
さくらVPSではIPv6がデフォルト無効なので有効化します。公式ドキュメント通りやるのが一番よいでしょう。
cloudflaredのインストールと設定
あまりこの辺の構成に言及しすぎるとセキュリティリスクの開示に繋がるのでサクッと流しますがCloudflare packagesに則ってcloudflaredをインストールします。こいつが後に大問題を起こします。
Cloudflare Zero Trustの方だとrpmをダウンロードしてのインストールが案内されますが個人的にはこの方法が便利です。
あと、さくっと流すついでにわかる人にだけわかる話。ここでNetworkManagerでループバックアドレスを追加するためにダミー接続を作成します。何の為でしょうね？そうそう、172.16.0.2はWARP自身に使用されてて使えないらしいですよ。うまく動かなかったら変えてみてください。そんでもってある方法で接続が確認出来たらfirewalldの全ポートを閉じます。
この辺はまあ、ほかの機会にちょっとだけ紹介出来たらと思ってます。
sudo nmcli connection add type dummy ifname dummy0 ipv4.method manual ipv4.addresses 172.16.xxx.xxx/xx ipv6.method disabled
SELinuxの設定 [詰みかけ事案]
VPS勢！！！GRUB_TIMEOUTは絶対長めに延ばしておけ！！！
これをやらかすまではSELinuxに阻まれて起動が完了出来なくなる可能性があると思ってなかった。
SElinuxをenforcingにして、rebootしてからgetenforceしたら何故かまだDisabledだったんですね。そこで先述のカーネルパラメータの値に気付き、そのままカーネルパラメータをselinux=1にしてrebootしました。
起動しなくなりました
reboot後いつまで経ってもsshで入れないのでVPS管理画面からVNCコンソールを見たらcloudflaredとsshdがSELinuxに阻まれて起動ループに突入してました。やらかした。
この状態からSELinuxを一旦無効化するにはgrub2の待機画面からカーネルパラメータを起動前に変更するしかありません。その待機時間であるGRUB_TIMEOUTデフォルト値は5。5秒しかありません。
VPS管理画面から強制再起動をかけて5秒以内にVNCコンソールを開いてEキーを押す必要があります。強制再起動をかけてからVNCコンソールが使用可能になるまでラグがあることを考えるとほぼ不可能ですが…ダメもとで何度か試した結果奇跡的にできました。本当に詰んだと思い「またOS再インストールからやり直しか…」と頭を抱えていたところでした。
「まずPermissiveでAVCエラー吐かないか見ろよ！」って言われてもその通りでしかないのですが、それでもEnforcingにしたときに確実に起動する保証はないということをここで知りました。改めて言います。
VPS勢！！！GRUB_TIMEOUTは絶対長めに延ばしておけ！！！
そんなわけでこの辺を参考にしてGRUB_TIMEOUTを長くしておきました。
sudo vi /etc/default/grub sudo grub2-mkconfig -o /boot/grub2/grub.cfg
もちろんこのまま再起動したら一時的に変更したカーネルパラメータは戻ってしまうので、その前に再起動ループ時に表示されていたAVCエラーからSELinuxポリシーを作って適用しておきました。
ちなみに私はSELinux初心者なので基本的にポリシーを作るときはauditログをaudit2allowに投げて生成される.teファイルを参考に作ります。OS再インストール前は.teファイルも読まずに言われるがままsemanageで適用してたからその時よりは成長してます。多分。
KUSANAGIの設定
基本的に上記公式ドキュメントの言う通りにしましょう。しいて言うならinitとprovisionなどはルート権限が必要です。また、運用の方向性によってはinitで作成されるkusanagiアカウントをsudoersに追加した方がいい場合があります。
ドキュメントルートの復元
バックアップしていたzipアーカイブをアップロードして新しいドキュメントルートに展開しました。展開後のファイルやディレクトリのパーミッションが正しいか見ておいた方がいいです。
あと、KUSANAGIではドキュメントルートが通常と異なる場所にある関係でディレクトリのタイプがWebサーバーにあるべきタイプになっていません。このままだとアクセスできないのでhttpd_sys_content_tまたはhttpd_sys_rw_content_tに変更しておきましょう。WordPressは更新等で書き換えが発生するのでhttpd_sys_rw_content_tのほうがいいですがその分防御力は劣ります。
データベースの復元
データベースの復元は簡単ですね。ただ、wp-config.phpが機能する前にやっておかないと自動で作られたDBと衝突するかな…なんて…
mariadb < tellaresdo.sql
cronの設定
DISABLE_WP_CRON環境なので設定する必要がありました。
(crontab -l; echo "* * * * * /opt/kusanagi/php/bin/php -q /home/kusanagi/tellaresdo/DocumentRoot/wp-cron.php >/dev/null") | crontab -
その他の復元
この他カスタマイズや細々した設定を必要性の精査も含め確認しつつ復元していきます。
WordPress環境で忘れがちな事といえば、SMTPサーバーを使うプラグイン等導入してなければWordPressがメールを送る時用にopendkim等でDKIMの設定をやってますよね？そういった設定をお忘れなきよう。
諸々確認したら完了です。
まとめ
たまたまバグありバージョンにぶち当たって要らない作業をする羽目になったりSELinuxと大乱闘を繰り広げたりした一方で、普通のLinuxサーバーではありがちなnginxのconfを書くとかそういうことはほとんどせずに設定を完了できました。これがKUSANAGIサーバーの利点だと思います。
移行の記事ですが引っ掛かりがちなポイントをまとめたので新規構築の際も参考程度にはなるかと思います。みんなもKUSANAGI9、使える環境なら使ってみてね！
もし次の移行があるとしたらkusanagi migrateコマンドがきちんと使えるといいなあ！
- 2024年6月23日追記。 ↩︎
