大晦日から続いた移行作業
大晦日から自信のないまま公開サーバーを置き換えようと模索して、物理的にも旧 PogoPlug が設置されていたスペースに収まりました。
経験のないことで苦労の連続
終ってみれば簡単に事が推移したようにも思えますが、ブログの移行は苦労の連続で、有料プラグインでのマイグレーションではデータを移行するのも簡単らしく書かれていますが、次があるのかいつなのかも不明のまま出資するのに抵抗を感じて、現状のツールだけで進めたいと考えました。
バックアップもマイグレーションも有料オプション
バックアップツールで思い出したように、バックアップだけはしていましたが、このデータからリストアで新しいシステムに戻せるのだろうかと不安でした。結論から言うと PHP のバージョンも大きく変わっていて、直ぐにエラーとなり利用できませんでした。
結局、移行前のサーバーから移行後のサーバーに、ブログの本体である WordPress のディレクトリを rsync コマンドでフルコピーして、MariaDB のデータベースを設定して、アクセスできるユーザーの情報を WordPress のファイルに記述して、バックアップのデータからリストアを試みました。
rsyncでコピーしても同じ動作にならない
それでも移行元の動作状況とは、見た目も動きも程遠くてテーマの設定やら背景の画像やらとしばらく格闘しながら移行前の動作状態に近付けて行きました。
早いサーバーに移行できストレス減少
今回は、なかなか味わえない良い経験をさせていただきました。前のサーバーでは、非力過ぎて待ち時間が長かったのが、そこそこのレスポンスで稼働しているのは安心でき肩の荷が下りた気がします。
物理的にも入替えが終わり、一安心と思っていたのですが、スマホに大量のメールが届いていました。忘れてました大事なことを、データのバックアップ等をさせているサーバーを使い cron で、 ping / http / ssh で公開サーバーに対して５分毎にチェックをしているのです。
消すのも大変なほどのメールが溜まってしまい、慌てて更新しました。
死活チェックに振り回されました
実は、上手く対応できたと思ったのですが、単純に ping して結果をチェックする処理で、その後も５分毎にエラーメールが届いていました。IPv6 のアドレスが、誤って設定されたので気付き直したつもりが、使用を止めたつもりの旧公開サーバーのDNSで名前解決されていて、直したはずの新しいデータがそこには無くて、実在しない IPv6 アドレスに ping を送っていました。
調べてみるとゴーストのイタズラかな
resolv.conf に古いネームサーバーを参照する情報が残っているようで、わけのわからない結果を招いていました。この辺りの動作は何か良くわからない動きをするので困りものです。
/etc/dhcpcd.conf は要注意
対策できたと思って安心していると、その後も５分毎にエラーメールが届きます。更に調べるとエラーメールを送るそのサーバーは、固定アドレスを設定するために、 /etc/dhcpcd.conf の中に固定アドレスを記述しているのですが、一緒にネームサーバーも記述していて、稼働対象外のサーバーアドレスを指定していました。まともな動きをしないのは仕方ないですね。
稼働対象外のサーバーも元はマスターのネームサーバーで稼働していたものなので、定義を変えてスレーブで立上げ直して、しばらく残そうと思い、 /etc/bind/slaves のディレクトリを追加して、マスターから配布されるように設定したつもりでしたが、一向にファイルの配布が行われませんでした。
/etc/bind/slaves の所有者とアクセス権
配布されなかった理由は正確には不明ですが、ディレクトリのオーナーを bind にして、アクセス権を変更して、更に rndc reload のコマンドをマスター側とスレーブ側のサーバーで実行して少し経つとファイルの配布が行われたのを確認できました。
Webalizer も文字化けが解消
文字コードを修正してソースからメイクする情報がネット上にもあるのですが、その中で説明しているファイルを置いていたサーバーが現在接続できなくなっているようです。
最終的には何とか日本語化できたような感じです。見た目の文字列は日本語化されていない部分があちこちに見られますが、文字化けで読めない箇所はないようなので成功したと考えます。しばらくこのまま運用を続けたいと思います。
対策前は、漢字コードが昔懐かしい、euc で書かれていて、UTF-8 として表示しているのか、結果はこんな文字化けが起こって読めません。
文字コードを UTF-8 に変換した結果は、次のような結果となって読めているようなので問題ないレベルになっていると思います。
