複数の FreeBSD サーバーを管理していますが、そのうち 3台が FreeBSD9.3 で、2016年末でサポートが終了。半年くらい掛けてアップグレードすればいいと考えていたのですが、いろいろな問題が発生してしまい、結局、1ヶ月以内に全台更新してしまいました。BIND をソースからのビルドは更新できなくなってしまったことが主な原因。
1台目は、昨年末からパーツ選定など作業を行っていたサーバーで、完全にハードウェアの交換で済ませました。新しく構築したサーバーを設置場所へ送ってNICだけリプレースして作業完了。
2台目は、リモートから更新をかけたところでネットワークがつながらなくなり、現場に出かけて修復。PPPoE に不安が残るものの、OSは順調に動作中。
3台目がこのサーバー。サーバー上で動かしているサービスが多いことと、アクセス数増加によるハードウェアの限界から PCハードウェアを交換することにしました。一時的に旧サーバーと新サーバーを同時に動かして、データコピーとテスト行いながらの切り替えになりましたので、サーバーIPアドレスを2回変更しました。
次回サーバー交換に備えて、3台目サーバー交換作業項目を記録しておきます。
FreeBSD サーバーリプレース作業
旧サーバーOS: FreeBSD 9.3, Celeron 1.2GHz + 1GB RAM
新サーバーOS: FreeBSD 10.3, AthlonXP 1600+ + 3GB RAM
- 新サーバーへ FreeBSD 10.3 をインストール
- まず、何らかのインストールメディアから新サーバーへOSを入れます。今回使用するGA-7VTXEは、内蔵ATAPI CD-ROMドライブから FreeBSD 10.3 を起動できないため、別の FreeBSD 10.3 インストールCDを起動できるUSB接続CD-ROMが使えるマシンで base と kern を入れたHDDを作成し、そのHDDをつなぎ替えて起動し、bsdinstall コマンドで再度インストールを行い、基本的な FreeBSD 10.3 システムを構成しました。
- 続いて、freebsd-update コマンドによりOSを最新状態にし、pkg コマンドで必要なユーティリティを、portsnap コマンドで /usr/ports をインストールします。
- 今までは、旧システム上の設定ファイルやユーザーファイルを tar ,cpio, dump/restore でファイルシステムをコピーすることが多かったのですが、CD-ROM起動が出来ないことから、今回は fixit が使用できないため、rsync コマンドを使う事にしました。実は、rsync コマンドを使うのは初体験。アーカイブファイルを作る必要がないので、作業スペースの節約になることと、一週間程度 旧サーバーと新サーバーが並行して運営することになるので、旧サーバーをダウンさせる直前のファイルを自動的に同期できることから rsync を使う事にしました。
- 旧サーバー設定のコピー
- FreeBSD 9.2 → 9.3 のようなマイナーバージョンアップではなく、9.3→10.3 のようなメジャーバーションアップの場合、前バージョン 9.3 の設定ファイルは（とりあえず）そのまま使えるものの、記述方法が変更になっていることが多々あります。9.3→10.3 のあと10.3 で使い続ける時はまだいいのですが、11.x へバージョンアップする時や、10.3 の新規インストールマシンに設定を行う場合に、戸惑うことになりかねません。
rsync でワークディレクトリにコピーした /etc と /usr/local/etc のファイルを見ながら、手作業で移行を行うことにしました。- passwd と group ファイル
passwd ファイルのフィールド機能は同じであるものの、パスワード暗号化アルゴリズムが変更になっているようで、旧ユーザーのパスワードと手動追加ユーザーのパスワードの長さが違っています。group ファイルの中身は同じものの、vigr というグループ管理コマンドが追加になっていて、vipw 的に使用できます。これは便利。 - ホスト名やネットワークパラメータの設定場所や記述は同じ。
ただし、一時的に並行運用するので、同じPPPoEアカウントは使用できず。私の場合は、PPPoE アカウントの他に、Interlink マイIP アカウントがあるので、新マシンはVPN接続で運用開始しました。このため、現行マシンとは別の設定を行わなければならず面倒でした。（VPNでつないでいる間、外出先から固定IPで自宅へログインすることが出来ないのがちょっと不便でした。） - セキュリティーの要とも言えるロギング。アプリケーションによりマシンをプロテクトするのもいいですが、まずは、外部からのアクセス状況をきちんと記録することが一番。そのために必要なのが、syslog.conf と newsyslog.conf。/etc の下にありますが、この記述が時々変わるんですよ。仕方なく、旧ファイルを見ながら新ファイルを手作業で編集して行きます。newsyslog.conf に関しては、newsyslog.conf.d というディレクトリが追加され、ローテートしたい設定を newsyslog.conf.d に保存しておけば、バージョンアップの時などにオリジナルの newsyslog.conf を編集する必要が無く、追加設定だけを newsyslog.conf.d へコピーするだけで済みそうだったのですが、記述方法が悪いのかファイル名が悪いのかよく分かりませんが機能しませんでした。やむなく newsyslog.conf を手編集。
- 同様に、/etc/hosts.allow も旧設定を見ながら手編集。
- /etc/mail 下は、virtusertable と aliases, access などをコピーして、make maps で作り直し。sendmail.cf は旧ファイルの記述を見ながら、ホストのパフォーマンス向上を考慮しながら再設定（中）。
- BIND: 今回、早急なOSバージョンアップを行う原因となったBIND。
設定場所が/etc/namedb → /usr/local/etc/namedb と大きく変わったため、named.conf を始め基本的に全部のファイルを手作業で編集する必要がありました。
今まで、chroot を使わない設定だったのですが、10.x からは素直にデフォルト設定を使う事にしたら、/usr/local/etc/namedb に設定したファイルが /var に移動させられ、シンボリックリンクに変わってしまいました。またキーになるファイルのオーナーやパーミッションも起動時に再設定され、外部からの攻撃で落ちることはあっても汚染はされないようになっているようです。バックアップネームサーバとして使用していたサーバーが、ネットワーク不通になるという事故があったりして、今回はネームサーバー絡みで時間を費やしてしまいました。旧サーバーを落とすタイミングで、また設定を変えなくちゃいけないので、面倒、面倒。 - Apache, MySQL, PHP に関しては、バージョンアップは行われないのでパッケージを入れるだけ。のはずでしたが、やっぱりトラブりました。自動的に入ると思っていたパッケージが抜けていました。
- DHCPD: 自宅ネットワーク用の DHCP。これは設定ファイルをコピーするだけで終了。
- passwd と group ファイル
- FreeBSD 9.2 → 9.3 のようなマイナーバージョンアップではなく、9.3→10.3 のようなメジャーバーションアップの場合、前バージョン 9.3 の設定ファイルは（とりあえず）そのまま使えるものの、記述方法が変更になっていることが多々あります。9.3→10.3 のあと10.3 で使い続ける時はまだいいのですが、11.x へバージョンアップする時や、10.3 の新規インストールマシンに設定を行う場合に、戸惑うことになりかねません。
- ユーザーデータのコピー
- 旧サーバーに rsyncd を設定した後、という感じでファイルを属性ごとコピーできるので、とっても楽。もっと早く使う気になっていれば良かった〜。
# rsync -av --delete root@oldhostname:/home /
- 旧サーバーには、root から ssh でアクセスできるようにセキュリティーを変更しておかないといけませんので多少手間が掛かりましたが、パート、パートに別けて、定期的に上記コマンドを発行すると、必要なファイルを全部更新できるので、例えば、メーリングリストのスプールや、HTTPのログファイルなど更新が行われるファイルも、旧サーバー停止前に rsync することで、更新されたファイルは何だっけ？と考えなくて良いので、とっても便利でした。
- 基本的に、/home の他、/var/log、/var/db あたりに有効です。
- 旧サーバーに rsyncd を設定した後、という感じでファイルを属性ごとコピーできるので、とっても楽。もっと早く使う気になっていれば良かった〜。
- /var データのコピー
- /var/log: 旧サーバーは非公開状態になった後、電源遮断する予定なので、将来、xx月xx日のファイヤーウォールログが必要！となった場合に、サーバーを再接続して再起動するのはとっても面倒です。どちらかというと新しいサーバー構築時情報の方が不要です。ですから、/var/log 以下を rsync で全部新サーバーにコピーし、新サーバーは旧ログに追加する形でログを記録することにしました。
- crontab のコピー：cron で自動起動させているプログラムがあるので、crontab をディレクトリ毎コピーするか、crontab -l で表示させて手動コピー。
- /var/squid : squid proxy を使っていて、/var/squid にキャッシュを置いているので、ディレクトリを作成した後、squid 利用開始前に「squid -z」でキャッシュディレクトリを初期化しておく必要があります。
これだけ準備したら、新サーバーを別のIPアドレスで稼働開始。
この時、ちょっとした失敗をしてしまいました。
WebサーバーのIPアドレスが変更になる場合（同じホスト名で別のIPアドレスに変わる場合）、あらかじめ DNS zoneファイルのキャッシュ時間を1時間以下に短くしておかなくてはいけなかったのに、忘れたままサーバー切り替えを行ってしまいました。気づいたのは翌日。Webページへのアクセス数が通常の5分の1くらいしか発生していなかったことに気づきました。あ〜、と思ったけど、手遅れ。
でもまあ、サーバーのメモリ容量が3倍になった効果か、私の記録作業は楽になりました。CPU性能は、1.2〜1.4倍くらいのはずなので、CPU処理能力よりも主記憶増量の方が効果あったと言えます。
VPN接続なので、接続回線は自由に選択できます。元々ASDLで運営していますが、光回線や格安SIMキャリアのものを使う事も出来ます。光回線を使おうかとも思ったのですが、障害確率が2倍になることと、回線切断時（や不安定時）に自動PPTP再接続を行う方法が未確立のため、安定回線である ADSL にとどまることにしました。
結論として、本サイトのような文章中心のブログサイトで高速回線を使う意味は殆ど無い と判明。複数人がアクセスしている時でも、50kB/sec 以下の通信速度。時々100kB/sec で通信している時間がありますが、数秒程度の間だけです。ファイルのダウンロードが働いている時は、帯域全部が埋まりますけど、いつもいつもダウンロードが行われているわけではないので、ADSLの上り（購読者から見た場合、下り）回線使用率は 10% 以下ということになります。当サイト一日のデータ上り転送量は1GB以下ですからね。
VPN で新サーバーのテストを行い、問題ないことを確認した後の本日(2017/01/22)、旧サーバーを停止させ、新サーバーと切り替えました。
もちろん、DNSキャッシュ時間を調整した後、その他 named の設定ファイルなどを Master に切り替えて、不都合部分がないか確認中です。（チェックしたつもりでも、2,3 不都合が見つかるんですよねぇ〜。）
これで、一応、マイサーバー移行作業は完了とします。