今回は、Linuxサーバ内のウエブサイトをカンタンに引っ越すためのヒントです。巷でたくさん書かれているようなcertbotのめんどうな移行など必要なくなる方法なども・・・。
Linuxは引っ越しを検討せざるを得ない
Linuxのディストリビューションにはサポート期限があります。そのたびに同じディストリビューションを自動的に選ぶのではなく、その時その時で最良のディストリビューションに乗り換えたりしますね・・・。
今回は、Linuxサーバの引っ越しが楽になるヒントをお届けします。
筆者は長期サポートの関係で、cent OS（red hat系）からubuntu（debian系）へ移行しましたが、これはノートPCなどのクライアント環境で使えるmint OSが同じdebian系だったことが理由ですが、最近ではred hat系のalma linuxが評判が良いので、将来的にはalma linuxへの変更を考えています。このブログで紹介しているようにシステムに過度の変更を加えず、シェルスクリプトなども多用しないシンプルで質素な使い方をしている限りは、系統の違うLinuxでも比較的引越し作業はカンタンになります。
同じディレクトリ構造を保つ
まずウエブサイトやシステムを保存するフォルダ構成はルート「／」フォルダ以下の構成をすべて絶対に変更しないように気をつけます。筆者の場合、規定となるフォルダは「/home/xxxxxx（xは特定の文字）」というのを必ず使います。/home/なので本来はユーザーのフォルダでが、Linuxユーザーの名前である必要は全くありません。気持ち悪ければ他のフォルダを利用しても構いません。
そのためにわざわざ旧サーバと同じユーザーを設定する必要もありません。
ただし、フォルダ構成は今後絶対に変えてはいけません。この決まったフォルダ構成を永遠に維持する限りにおいて、ウエブサイトを引っ越す時にファイルのgrepをとったりdiffをとったりしてフォルダ名を更新する必要がなくなります。これだけでも引っ越しが劇的に楽になります。
さらに、このフォルダ以下のすべてのサブフォルダはオーナーやグループを変えても、wordpressやpukiwiki程度であれば普通は問題ありません。パーミッションやセキュリティポリシーを設定・変更するときだけは慎重に行いましょう。
系統を変えない
redhat系、debian系、SUSE系、Arch系、Gentoo系などなどいろいろありますが、大元となる系統を変えない限り、サーバの引っ越しは楽です。そもそも系統を変えると、yum＜＞aptなど、重要ないつも使うコマンドも変わってしまう事が多いので、管理者自信が混乱するきっかけを作ってしまいますので、Linuxの系統選びは慎重に行いましょう。シェルスクリプトなどを多用しているサイトは特に要注意です。
certbotは移動しない
certbotの認証ファイルは引っ越しません。新しいサーバのほうで「certbot – -apache」をするだけです。旧サーバのほうは「a2dissite」でサーバを停止しておきます。これで、新サーバのほうで不都合がでた場合でもすぐにDNSを切り替えて旧サーバに戻す「フォールバック」することができます。
証明書などを移動してしまうと、これができなくなりますので、注意が必要です。
sites-availableからコピーするもの
旧サーバから新サーバへのデータ移行の手順サンプルは後述しますが、基本的にSSL証明書のたぐいは一切コピーしません。新サーバ側で認証局から認証ファイルをもらうだけです。そのため、/etc/apache2/sites-availableからも、HTTP用の設定ファイル「ドメイン名.conf」のみをコピーすればよく、「ドメイン名-le-ssl.conf」はコピーしなくてOKです。
旧サーバはしばらく残しておく
旧サーバは、設定データなどを参照したり、最悪の場合フォールバックがカンタンになるように、なるべく変更を加えず放置しておきます。最近はクラウド環境でサーバを運用している場合も多いので、新サーバがいよいよOKとなってから旧サーバを削除してしまえば良いわけです。サーバー自体を削除してしまえばSSL証明書も消滅しますからいちいち移動させる必要はありません。
ベアメタルサーバやオンプレミスでサーバを運用している人は、SSL認証ファイルなどの取り扱いは、クラウドサーバの場合よりは注意して行ってください。
ドメイン名は変えない
これは重要ですが、サーバで利用しているウエブサイトのドメイン名は変えないほうが無難です。wordpressなどでは非常に面倒な移行作業が必要になります。しかし、大抵の場合、フォルダ構成を変更せず、ドメイン名も同じで、サーバのIPアドレスだけが変わるような引っ越しは移行手順が非常にカンタンになります。
wordpressの引っ越し
ドメイン名やフォルダ構成を変更しない「IPアドレスだけの引っ越し」であればWordpressの引っ越しで難しそうなのはSSL証明書の移行でしょう。しかし今回はcertbotのSSL証明書は移動せず新サーバで取り直すだけなので非常に楽です。ここでは、このように引っ越しやすくしたサーバでのWordpressサイトの移行手順を記しておきます。
wordpressカンタン引っ越し手順
１．旧サーバで：wordpressのファイルをアーカイブする
tar cfz <アーカイブファイル名> wordpressサイトのフォルダ名
２．旧サーバのアーカイブを新サーバに転送
３．新サーバで：転送したアーカイブを展開
tar xfz <アーカイブファイル名>
４．Navicatでデータベースを転送
５．/etc/apache2/sites-available の当該するドメイン名のエントリをコピー
このとき新サーバ側には HTTP用の conf ファイルのみを移動し、SSL用の「xxxx-le-ssl.confは転送しない。そのHTTP用のconfファイルの中の「RewriteEngine」と「RewriteCond」と「RewriteRule」の行を削除しておく（あとでcertbotしたときに自動的に追加される）。
６．新サーバで：a2ensite <ドメイン名.conf＞
７．新サーバで：systemctl restart apache2
ここでエラーが出ないことを確認しておく。
８．旧サーバで：a2dissite <ドメイン名.conf＞
９．旧サーバで：a2dissite <ドメイン名-le-ssl.conf＞
１０．旧サーバで：systemctl restart apache2
１１．ドメインレジストラでwwwのIPアドレスを変更する
変更がいきわたるまで暫く待つ。pingなどでドメイン名を確認してIPアドレスが変更されたら次の作業を行う。
１２．新サーバで：certbot –apache を実行
新しい証明書が新サーバに導入される。
完了
pukiwikiの引っ越し
サーバを引っ越す際には、pukiwikiなどのバーションが新サーバのOSに対応しておらず、500エラーを吐き出す場合があります。PHPのバージョンが新しすぎる場合などです。Wordpressは定期的に自動で更新されるので、新バージョンの環境に変わっても動かなくなることは稀ですが、pukiwikiを運用している場合は話が違ってきます。新サーバに引っ越した途端に動かなくなるケースが多いようです。そのようなときは、pukiwikiのバージョンアップを考えましょう。
これをすれば引っ越しが劇的にカンタンになる
pukiwikiは案外バージョンアップがカンタンです。１０年以上前のバージョンを２０２４年最新のバージョンにしたときもcpコマンド２つだけで移行できたほどです。
pukiwikiをゲーム攻略などのサイト用にカスタマイズして公開している人は「スキン」などもコピーし、「設定ファイル」や「pukiwiki本体」などの差分をとる必要があります。これが案外めんどうなので、基本的に会社やグループ内部で私的に利用するのであれば、pukiwikiを過度にカスタマイズせずに、そのままのかたちで使うと最も引っ越しが楽になります。まあ見た目はちょっとしょぼくなりますが・・・。
しかし、このように変更やカスタマイズをせずにそのままのpukiwikiを使う限りにおいては、なにも変える必要がなくコピーコマンドだけで引っ越しができるので、作業が非常にカンタンにできます。
実際の引っ越しコマンド
// attachの引っ越し
cp -r /path/to/old_pukiwiki/attach /path/to/new_pukiwiki/
// pukiwikiコンテンツの引っ越し
cp -r /path/to/old_pukiwiki/wiki /path/to/new_pukiwiki/一応バックアップも
バックアップfルダ「backup」は、pukiwikiを編集するときのバックアップファイルなので、必ずしも新しいサーバに引っ越す必要なないのですが、一応アーカイブだけはとっておきましょう。
tar -cfz backup.tar.gz /path/to/old_pukiwiki/backupDBはNavicatで一発
筆者は長年NavicatをDBの編集・管理に使っているので、他のツールを知らないのですが、Nagicatはサーバ間でデータベースの内容をそっくりそのままコピーする機能があるので、新サーバへの移行はびっくりするくらい楽です。
よくDBサーバ内にphpmyadminを入れてDBを管理している人がいますが、せっかくDBへの外部からのアクセスを遮断しても、phpmyadminのようなWebベースの管理ツールを入れてしまうことによってWebの脆弱性をついた攻撃にまで気をもまなくてはならなくなります。NavicatはSSLやSSHトンネリングを使って外部のデバイスからアクセスできるので、このような余計なセキュリティの問題を考えなくてもよく、さらに１つのNavicatで複数のDBサーバを一元管理できるようになります。筆者はSSHの秘密鍵をセキュリティのかかった特別な保護フォルダで管理しています。
まとめ
一通りみてきたように、
１．ドメイン名は変更しない
２．ルートフォルダからのフォルダ構成を変えない
３．Linuxの系統を大きく変えない（しかし常に一番良いものを選ぶ）
４．余計なことをしない（笑）
これらのことを行うだけで、Linuxサーバの引っ越しがすごく楽になることがおわかり頂けたかと思います。やはり過度なカスタマイズは運用性を低下させてしまうので、ケースバイケースでやりたいですね。自分専用自社専用のサーバだからといって、サーバにゴタゴタと追加のプラグインをインストールしている人も多いですが、本当に必要なものだけにしておいたほうが運用は劇的に楽になりますね。
