PostPath:エンタープライズ品質のオープンソースのExchange代替ソフト
このような相互運用性を実現できるのは、PostPath開発者がExchangeと同じプロトコルを使用した結果、Exchangeクライアントとの通信に特別なコネクターを使う必要がなく、PostPathがExchange管理と完全な互換性を備えているからである。社内にExchangeインフラストラクチャがすでにあり、この環境を拡張する必要がある企業は、PostPathを実行するメールサーバを追加できる。このサーバは、新しいExchangeサーバであると認識される。この方法の最大のメリットはコスト削減にある。PostPath本体のライセンス料金は、ユーザ60席と予備サーバ1台のセットで$4,000、これにユーザを1席追加するごとに$45の負担が必要になる。さほど高性能ではないハードウェアでもPostpathは満足なパフォーマンスを発揮する。メモリ2～4GBのデュアルコア・システムで十分だ。また、CentOSなどのフリーのオペレーティングシステムでも動作する。
現在、PostPathはExchange 2007までの環境に対応している。ただし、Windows VistaクライアントがHTTP接続経由でリモート・プロシージャ・コール（RPC）を使う場合、Outlook 2007はPostPathに接続できない（詳しくはトラブルシューティングガイドを参照）。ユーザ12席用のPostPath 30日試用版をダウンロードしてテストできる。
PostPathの稼働要件
PostPathをインストールする前に、用意したサーバが最低でもPentium 4プロセッサ、1～2GBのRAM、100GBのハードディスクを搭載したものかどうかを確認する必要がある。最低100人のユーザを抱える運用環境であれば、デュアルコア・プロセッサ、2～4GBのRAM、100GB（メールボックスのサイズ設定によって異なる）のハードディスク領域を備えたサーバを強く推奨する。オペレーティングシステムに関しては、フリーのCentOS 4.4（32ビット）、CentOS 4.5（64ビット）、Red Hat Enterprise Linux 4.4/4.5（32/64ビット）、SUSE Linux Enterprise Server 10（32/64ビット）を使用できる。クライアントとしては、Outlook Express、Outlook 2003/2007、Eudora、またはThunderbirdを使用できる。
ハードウェアとオペレーティングシステムのほかに、電子メールのインフラストラクチャを準備する必要がある。最初の仕事は、Active Directoryとドメインネームサーバを正しく設定することだ。Network Time ProtocolとNetBIOSも有効にする必要がある。PostPathをExchangeなしで単独でインストールして稼働させることはできるが、PostPathを1台のExchangeサーバとして認識させ、Exchange管理ユーティリティの制御下に置き、Active Directoryに統合するには、同じネットワーク上にExchangeがインストールされている必要がある。PostPathは、利便性の高い機能の1つであるActive Directoryからの管理機能に対応するためにExchangeエクステンションを必要とする。PostPathの管理は付属の管理ツールでも行えるが、それでは相互運用性が成り立たないし、Active Directoryインフラストラクチャから簡単に管理できるという利点が失われてしまう。こういった点を除くと、PostPathは、成長を続けるExchange生態系の全体を真に差し替えることができるものであり、単なるスタンドアロンのサーバとしてそこへ加わるものではない。さて、準備が整ったら、PostPathを展開する作業に進もう。
展開
今回はPostPathをCentOS 4.5にインストールし、スタンドアロンのメッセージング・プラットフォームとしての動作と、1台のExchange 2003サーバを相手とする動作を確認した。インストーラ./postpath-installer.binをダウンロードした後で、PostPath Server Daemon（PostPathエンジン）、PostPath Recipient Update Service（既存のExchangeサーバがない場合に使用）、PostPath Administration、PostPath Webmailをインストールした。
インストール・プロセスでは、プライマリ・ドメインネームサーバ、Active Directoryドメイン名、NetBIOS名、完全修飾ドメイン名、PostPathサーバのNetBIOS名、Simple Mail Transfer Protocolドメイン、ドメイン管理用のアカウントとパスワードなどを設定する。
スタンドアロンのPostPathサーバだけをインストールする場合は、インストール過程で対話式スクリプトのforestprepとdomainprepを選択する。PostPathが最初の電子メールサーバであり、Exchangeがまだなければ、選択するスクリプトはforestprepとdomainprepの2つだけでよい。これらのスクリプトを使うと、PostPathなどの電子メールサーバを既存のActiver Directory環境に組み込むことができる。つまり、Active Directory内のユーザとグループが電子メールサーバに反映され、逆に電子メールサーバのユーザとグループがActive Directoryにも反映されることになる。forestprepとdomainprepについては、MSExchange.orgに詳しい情報がある。
注意すべきは、このようにPostPathサーバとActive Directory間でユーザとグループが相互に反映されるにもかかわらず、メールボックスを作成できるのはPostPathサーバのコンソールだけであり、Active Directoryでは作成できないことだ。また、Active Directoryにはユーザやグループのメールボックスに関する情報はいっさい表示されない。
ドメインが複数ある場合は、レプリケーション処理が完了し、現ドメインのActive Directoryに加えた変更がレプリケートされてすべてのドメインが更新されるまで、次の作業に進まないようにする。たとえば、ドメインでユーザを作成したり、アクセス許可を変更したりすると、その変更もレプリケート（同期）される必要がある。そうしないと、整合性が崩れ、加えた変更が他の関連ドメインに反映されない。
forestprepとdomainprepの実行が完了した後で、PostPath Server Daemon（PPSD）コア本体の設定に進む。この設定によってActive Directoryが変更される。たとえば、アクセス権の設定がPostPathに許可される。また、PPSDはPostPathをActive Directoryに追加し、Postfixを（まだインストールされてなければ）インストールし、Postfixを設定する。Postfixを手動で設定するオプションもあるが、知識がないとパラメータの適切な値を入力できないため、この設定をPostPath Server Daemonコア設定の一環として処理することをお勧めする。PostPath Server DaemonにPostfixの設定を任せると、PostPath Server Daemonの設定プロセスで入力したドメイン名、DNSサーバ、PostPathサーバとDNSの完全修飾名、コンピュータ名などの詳細情報が、Postfixの設定にも使用される。
次に、Exchangeがインストールされていない場合は、PostPath Recipient Update Serviceを設定する。これで、PostPathはActive Directory内のユーザ属性を制御できるようになる。設定するドメインが1つだけであれば、Exchangeがネットワークにインストールされているかどうかに関係なく、設定に必要な時間は15～20分だ。しかし、ドメインが複数ある場合はレプリケーションの時間を計算に入れる必要がある。この時間は、ドメインの数と他のドメインとの接続速度によって異なる。ドメイン間が高速回線で結ばれている場合は、1つのドメインへのレプリケートに約5分かかる。Exchangeがすでにネットワークにインストールされているなら、forestprepとdomainprepを使う必要はない。レプリケーションは、PPSDの設定中に一度だけ実行される。
PostPath Server Daemonの設定を終えたら、次はPostPath AdministrationとPostPath Webmailを設定する番だ。この作業は特に難しい点はなく、PostPath Server Daemonの設定よりもはるかに短時間で終わる。Exchangeサーバがすでにある環境での展開についても、forestprep、domainprep、PostPath Recipient Update Service設定以外は、スタンドアロンの展開と手順はほとんど同じである。PostPathのリソースサイトには、完全なインストールおよび管理のガイドが用意されている。
インストール後と若干の問題点
設定プロセスを最後まで終えたら、PostPathサービスを起動できる。最初は、PostPathエンジンだ。PostPathサービスを起動したところ、Active Directoryに関連する”PPSD [Log:EMERG] DATE TIME :ERROR: Could not load AD configuration Data.”というエラーが起きた。しばらく調べた結果、PostPathによってActive Directoryに作成されたアカウントオブジェクトが適切なアクセス許可を持たないことがわかった。この問題を修正すると、サービスは正常に起動した。
PostPath Webmailの動作にはTomcatサービスが必要だが、このサービスは特に問題なく起動された。最後に、PostPath Recipient Update Serviceを起動した。PostPathを管理するためにPostPath Administrationを実行したが、ログインにSecure Sockets Layer（SSL）接続が使われなかったと警告が表示された。PostPath AdministrationはActive Directoryと統合されているが、SSLを使わないとユーザの作成などの変更は行えない。この問題を解決するため、自分の証明書サービスを起動し、SSL証明書をActive Directoryサーバに作成した。これで、PostPath Administrationを使って変更を行ったり、ユーザのメールボックスを作成したりできるようになった。ExchangeサーバなしでPostPathを稼働する環境では、これがメールボックスを作成する唯一の方法である。
Exchangeサーバがインストールされている環境ではシナリオは異なる。ExchangeエクステンションがActive Directoryに配置されている場合、Active Directoryを使ってPostPathのメールボックスを作成できる。PostPathは1台のExchangeサーバに見えるので、Exchange Management Consoleを使ってPostPathサーバを管理することもできる。したがって、ユーザメールボックスを作成する際に、Exchangeの場合と同様に、PostPathサーバを電子メールサーバとして選択するオプションが提示される。テスト用のユーザを数人作成した後で、PostPathをメールサーバとして使ってPostPath WebmailクライアントとOutlook 2003クライアントの両方を試してみた。Webmailの動作はOutlook Web Accessと変わるところはなく、Outlook 2003はPostPathを正常に動作するExchangeサーバであると認識した。
感想
今回のテストでは、PostPathは真のExchange代用品として機能した。パブリック・フォルダ、グローバル・アクセス・リストなど、ほとんどのExchange機能は満足にサポートされている。Outlookクライアントの予定表、コンタクトの共有、メールボックスなどの機能も動作に支障はなかった。スケジュール機能も期待どおりの働きを見せ、メール配信にも問題はなかった。
対応の必要な問題は、Exchangeのシステム管理ユーティリティに相当するものがPostPathにないことだ。実際のところ、対話式のテキストベース管理コンソールはあり、Exchangeのグラフィカルな構成機能によって扱われるタスクはこのコンソールでもほとんどが実行可能だが、PostPathのターゲットである企業ユーザにとって、テキストベースの管理コンソールを操って設定を行うとしたら、時間と労力は指数関数的に増えると予想される。また、PostPathは既存のExchangeユーザをPostPath環境に移行させることも狙いとするが、移行が完了し、Exchangeが不要になった時点で、パブリック・フォルダなどのサーバ機能の管理をシステム管理コンソールなしでどう扱うかが問題となる。PostPath Administrationはこの懸念に部分的には応じられるが、大規模な環境で使用するには扱いにくいツールである。
総合的には、PostPathは、ほとんどのExchange環境の機能に真に替わることができる指し込み型の低コスト代替品と言える。若干の機能の不足、Vistaクライアントへの未対応などの改善点はあるが、Exchangeのような圧倒的存在にここまで迫ったことは感慨深い。
