CommuniGate Pro：WindowsからLinuxへの移行
私は最近、稼働中のCommuniGate ProをWindows NT 4.0からRed Hat Linux 9に移行し、クライアントのメッセージング・パフォーマンスを向上させることに成功した。作業は決して難しくないが、私と同様の移行を考えているユーザには、いくつか注意点をお伝えしておきたいと思う。
私が担当したクライアントは、使用していたWindows NTベースのサーバが古くなり、現在求められているパフォーマンスを果たせなくなってきたために、メッセージング・システムのアップグレードを必要としていた。Windows 2000にアップグレードしなかったのは、主に予算面の理由と、私の勧めからであった。MicrosoftはWindows NTのサポート打ち切りを発表しているため、Windows NTを継続して使う、という選択肢はなかった。
CommuniGate Proはクロスプラットフォームであるため、現在のクライアント、そして今後のクライアントにとって非常に魅力的だ。このソフトウェアは、Windows 95からIBM OS/400に至るまで、30以上のOSとプラットフォームの組み合わせでネイティブに実行することができる。さらに、このプラットフォームの互換性のおかげで、拡張性が非常に高い。CommuniGate Proでは、クラスタリングによって何百万ものユーザアカウントを扱うことができる。あるドイツ企業は、CommuniGate Proを利用して450万人ものクライアントにサービスを提供している。
Stalker社は、Microsoft Exchangeの機能の大部分を果たすことができるMAPIコネクタを販売している。また、ユーザが電子メールにアクセスし、すべてのメール機能を管理することができるネイティブのWebサーバも提供している。メール・ドメインの管理をユーザに任せることができれば、システム管理者は助かるはずだ。コマンドライン・インターフェイス中毒の人々には、CommuniGate Proを操作する数多くのツールが用意されている。
CommuniGate Proは、開発当初から、アカウントや設定情報からプログラムコードを分離するという目的の下で設計された。これにより、組織は、新しいバージョンへのアップグレードや（めったにないだろうが）ダウングレードをすばやく行うことができる。アカウントと設定に関するすべての情報は、1つの基本ディレクトリに格納されている。ここでは、NTサーバでの基本ディレクトリはC:\CommuniGate Filesで、Linuxサーバでは/var/CommuniGateである。
移行の下準備として、私は古いNTサーバをCommuniGate Proの4.0-6にアップグレードした。また、同じバージョンのLinuxプラットフォーム向けインストール（自己完結型RPM）もダウンロードした。新しいサーバは、2.4GHzのPentium 4 CPUを搭載したDellのPowerEdge 1600だった。100ドルの追加料金で、あらかじめRed Hat Linux Professional 9が構成されている。ドライブ・サブシステムは、IDE RAIDコントローラと、ミラー化された2台の80GB IDEドライブだ。このマシンには1GBのRAMが構成されているが、Linuxカーネルのオーバーヘッドは低いし、CommuniGate Proはさほどリソースを消費しないので、256MBもあれば十分だ。
第1ラウンド
CommuniGate Proのインストールを同じプラットフォームのマシン間で移動させるのは非常に簡単で、ベース・ディレクトリを圧縮して、新しいマシンのベース・ディレクトリでそれを復元するだけでいい。小規模〜中規模の典型的な企業なら、同じプラットフォーム間の移行には30分もあれば十分だ。
異なるプラットフォーム間の移行は、テキストファイル内の改行文字やEOF文字が異なるため、特にWindowsからLinuxへの移行では注意が必要だ。マニュアルでは、この落とし穴をはっきりと指摘しており、FTPの利用を推奨している。FTPなら、ベース・ディレクトリからファイルを転送する際に、この問題を自動的に解決してくれるからだ。
NTサーバには、IPSWITCH SoftwareのWS_FTP Serverのトライアル版をインストールした。数分間の設定で、サーバが使用できるようになる。続いて、LinuxのgFTPクライアントを使って、新しいLinuxサーバの保管領域にNTのベース・ディレクトリを移した。viでいくつかのファイルを検証してみると、無事に届いていることがわかったが、FTP経由で転送したすべてのファイルに実行可能属性（x）が付いているというおもしろい現象が起きていた。この問題を解決するにはchmod -R -x *を実行すればよい。マニュアルによれば、所有者はroot、グループはmailにしておく必要がある。ここでも、-R（再帰）スイッチを指定してchownとchgrpを実行すればよい。
白状してしまうと、先の手順では少々ずるい手を使っている。私は、自分の都合のいいように環境を設定する目的で、CommuniGate Pro RPMをインストールしたのだ（/var/CommuniGateディレクトリを除いては）。ここでのポイントは、ソフトウェアをインストールしても、デーモンを開始しないことだ。
次の手順は、ほかのメール・サービスを無効にすることだ。Red Hatディストリビューションでは、sendmailをインストールして開始することが推奨されている。sendmailを無効にするには、chkconfig sendmail offを実行する。私はデフォルトのディレクトリを使用していたが、念のため最後に、/etc/rc.d/init.d/CommuniGateにあるデーモンの起動スクリプトを見て、変数に正しい値が設定されていることを確認した。
起動前チェックリストをよく確認した後、私はネットワークケーブルを引き抜いて、./CommuniGate startコマンドを打ち込んだ。しかし、何も起こらなかった。pgrep CGSを実行すると、アクティブになっているスレッドは1つもないことがわかった。
第2ラウンド
ケアレスミスがなかったかどうかを確認し、気休めでldconfigを実行した後も、CommuniGateは起動してくれなかった。そこで私は、Googleでヒントを探してみた。Stalker社のWebサイトがヒットしたので見てみると、サポート情報が非常に充実していることがわかった。私は、CommuniGate Proのメーリング・リストの中で、同じ問題に直面したという投稿を見つけることができた。Stalkerからの回答は、コアダンプを出力するようCommuniGateを設定し、そのファイルをサポートチームに送るように、という内容だった。しかし、そこに記されたコアダンプの方法は私の環境ではうまくいかなかった。この投稿に対してStalkerがすぐにコアダンプを要求しているところを見ると、どうやら、メーリング・リストに頼る前に、まずは問題をしっかり見極める必要があるようだ。
サーバに戻って設定を変更し、ログに記録することのできる数を増やした。CommuniGateサービスを再起動すると、サーバは、上位のプロバイダからキューに入れられたメールを取得することができた。サービスを終了して、再度ベース・ディレクトリの中身をFTP経由でLinuxマシンに転送した。この繰り返しだ。結局、設定を変えてはFTPでファイルを転送する、という悪循環にはまってしまい、うまくいくことはなかった。
第15ラウンド
いまやっている方法でうまくいかないならば、ほかの方法を試してみるべきだ。FTPのプロセスが怪しいと思った私は、ベース・ディレクトリに設定ファイルを1つずつ置いてプログラムを実行してみた。私はこの作業のほとんどをMicrosoftプラットフォームで行ったが、これは、役に立つエラーメッセージなど期待していなかったからだ。わざわざこれを断っておいたのは、私が雷に打たれたようにヒントを見つけたからだ。tail -f <FILE>コマンドを使って、ターミナル画面でCommuniGate Proのログファイルをスクロールしていたとき、私はあることに気が付いた。ログファイルには、プログラムがクラッシュした際のさまざまなアクティビティが記録されていたが、すべてのログは、クラッシュの直前にRouter.data設定ファイルを読み取る際に発生したシンタックス・エラーを反映したものだったのだ。
あとはRouter.dataファイルとの格闘だ。ルーティング・ファイルをすべてviで入力しなおした後は、ものの10分ですべてが解決した。ファイルはFTPで転送されたにもかかわらず、ファイルに含まれていたEOF文字がシステムで問題になったのだ。ちなみに、CommuniGate ProがRouter.dataファイルを解析する際には、コメントが一切無視されるので、ログ内に記録されるエラーの位置は、ファイル内の実際の場所とは異なるということに注意してほしい。
私が成功の喜びを噛みしめるよりも前に、CommuniGateは、それまでの3時間にキューに入れられたメールをすでにダウンロードし始めていた。そう、私は、トラブルシューティングの後、パッチコードを抜くのを忘れていたのだ。
最後に、旧サーバのIPアドレスを変更し、変更前のIPアドレスを新しいサーバに追加する。基底プラットフォームへの依存を少なくするために、サービスを仮想化するとよいだろう。このIPアドレスは、メール・サービスを実行しているマシンではなく、メール・サービスそのものに割り当てられる。簡単なシェルスクリプトで、仮想アドレスの追加や削除が好きなように行えるので、ネットワーク上で混乱が起きることもない。NTサーバでIPオーバーラップを防ぐのはもっと簡単で、ネットワークのパッチコードを抜くだけでいい。
典型的なサブネットが要求される場合、ifconfig eth0:0 xxx.xxx.xxx.xxxのようにifconfigコマンドを実行すれば、Linuxで別名アドレスを追加できる。この変更は、ifcfg-ethX:Zファイル（XはEthernetカード、Zは0で始まる仮想IP番号。区切りのコンマは必須）を/etc/sysconfig/network-scriptsディレクトリに追加して初めて永続的になる。仮想IPアドレスを永続的にするのは、rc.local起動ファイルでも行えるが、Red Hatではここで紹介した方法をお勧めする。
新しいサーバの準備が整ったらこれを起動して、Webの管理インターフェイスを利用してすべての設定を確認した。テスト・メッセージを送ってログを確認するという作業を30分間行い、転送に問題がなかったことを確信できた。最後に覚えておいてほしいのは、少なくとも1つのドメインは、すべて利用可能なIPアドレスを使うようにしておくということだ。さもないと、Webの管理ページにアクセスできなくなる恐れがある。
WindowsからLinuxへのサーバの移行は、大規模なプロジェクトではほんの前哨戦だ。これに続いて、スパムメール・フィルタやウィルス・スキャナのインストールが待っている。移行前のプラットフォームには、どちらも実装されていなかった。クライアントは、パフォーマンスが大きく向上したことに感銘を受けると同時に、残りの作業に不安を覚えているようだ。
選択肢について
読者の中には、Debianのような「フリー」のディストリビューションと、おなじみのsendmailをRPOPなどと組み合わせて使えば、もっと費用を節約できると考える方もいるだろう。今回のケースでは、FOSSソリューションを適切なツールとともに使うと決定したのはクライアントの方だった。このクライアントはさまざまな理由からMicrosoft製品を採用しないと決めたが、かといってMicrosoftのやり方をすべて否定することもないということで意見が一致した。Microsoftのモノリシックなソリューションを、私の、より小さいモノリシックなソリューションで置き換えるよう勧めれば、クライアントは費用を節約できるが、その代償として、私に頼りっきりになってしまう。DellのハードウェアとRed Hat Linux、そしてCommuniGate Proを選んだことで、たとえ私との関係が悪化しても、クライアントはこの構成の恩恵を受け続けることができる。
Scott Stahlは12年の経験を持つ、システム管理のスペシャリストである。過去3年間、イリノイ州ホームウッドのComputer and Network Specialistsにおいて、シニア・プロジェクト・コンサルタントを務めていた。同時に、過去2年間には、Provena Healthで、地域のLAN/WAN管理者も務めた。
