OpenGroupware.org、いまだ道遠し
プレスリリースには、「OGoのリリースにより、機能満載の熟成したグループウェアソリューションが出揃い、企業向けOpenOffice.orgスイートの完成が近づいた」という文面も見られた。さっそくインストールして試してみたが、数時間後には、残念ながらこのソフトウェアがまだ企業での使用に耐えるレベルには達していないことがわかった。
開発の背景
OGoは、現在のOpen Sourceグループウェアソリューションにはないさまざまな機能を提供することを目的とした意欲的なプロジェクトだ。その夢はプレスリリースにも語られている。「OGoソフトウェアでは予定表やアドレス帳、電子メール情報を共有することができる。インスタントメッセージングでコミュニケーションを図ることもできれば、フォルダの共有、ドキュメントの交換、変更の管理、ホワイトボードの共有、Webの閲覧も可能だ。しかもすべて同時にである。使うのはオープンなインターネット標準だけだ。対価を支払う必要はない。もちろん、ライセンス料金のことをあれこれ気にする必要もない」
さらにプレスリリースには、OpenOffice.orgグループウェアプロジェクトのリーダー、Gary Frederick氏の次の言葉が引用されている。「これは、簡単に言ってしまえば、Microsoft Exchangeの代替サーバだ。オープンソースソフトウェアのスタックに欠けていた領域を埋める重要な存在だ。主要なインフラストラクチャと標準的デスクトップアプリケーションをすべてフリーソフトウェアに置き換えるという、10年来の努力がこれで報われるだろう」
OGoは、ドイツ企業Skyrix Software AGが7年がかりで開発したSkyrix 4.1 Groupware Serverのコードを使っている。つまり、OGoのコードは完成度の高さが売り物の1つだと言えよう。
インストール奮戦記
OGoは是非とも試してみたいソフトウェアだったが、最初のリリースということもあり、インストールとその後の設定は手作業で行うことは覚悟していたつもりだ（同プロジェクトのWebサイトによると、より便利なインストールプロセスを間もなく提供するとのことだ）。しかし、事実を述べると、インストールは苦労の連続だった。なにしろ、Webページの指示（7月12日現在）どおりに作業を進めても、正常に動作するシステムを得ることはできないのだから。
まず、ダウンロードしたのはインストールするキットのtarballだ。評価に使ったのはRed Hat 9マシンだったので、20MBのRPMのtarballをダウンロードした。tarballを展開して得られるのが48個ものRPMだ。幸い、これは全部インストールしなくてもよい。必要なのは27個で、残りのほとんどは開発キットだ。
開発キットのインストールの順番はOGoのWebサイトに示されている。その中に”opengroupware-libxmlsaxdriver”という名前のキットがあるが、これは明らかに”opengroupware-xml-libxmlsaxdriver”と読むべきものだろう［訳注：現在は訂正されている］。これを除けば、インストールには特に問題はなかった（指示された順番どおりに27個のRPMファイルの名前をカットアンドペーストするのに多少時間はかかったが）。
次に、PostgreSQLサービスを起動し、設定手順どおりに作業した。ここで注意しなければならないのがインストール先だ。私がインストールしたのはRPM版だから、インストール先はDebian版とは異なる（私と同様にRPM版をインストールする読者は、手順説明に記載されているディレクトリツリーを適宜読み替える必要がある）。Red Hat上ではrootでデータベースを作成することができなかった。データベースとユーザを作成するには、su postgresを実行する必要があったのだ（postgresはRed Hatで使用するデフォルトのPostgreSQLユーザ名）。さらに、”ogo”というユーザを作成して、su ogoを実行した。これで、ようやくデータベースにアクセスできるようになった。
次に問題になったのが、OGoサーバの設定に使う”Defaults”ツールだ。PATHにこのユーティリティのディレクトリが見当たらないのだ。さんざん探し回ったあげく、source /opt/opengroupware.org/OpenGroupware.org.shを実行して環境変数を訂正しなければならないことがわかった。
なんとかWebサーバをセットアップして、Webベースの管理インターフェイスを利用できるようにはなったが、今度はOpenGroupwareサーバを実行することができない。実は、Webページに記載されているシンタックスが違っていたのだ。Webページでは、実行ファイルの場所が./OpenGroupware.woa/linux-gnu/gnu-fd-nil/OpenGroupwareとなっていたが、これを./OpenGroupware.woa/ix86/linux-gnu/gnu-fd-nil/OpenGroupwareに変更する必要がある［訳注：現在は訂正されている］。
問題はこれだけではなかった。コネクタが対応しているのがApache 1.3だけで、Red Hat 9のApache 2.xには対応していないのだ。OGoをRed Hat 9上にインストールする場合は、古いApacheサーバを用意しておく必要がある。ただし、テスト目的であれば、OpenGroupware.orgサーバをスタンドアロンで実行することは可能だ。
Apacheコネクタをインストールするには、ソフトウェアの一部を手作業でコンパイルしてApacheのバージョンに合わせる必要があるが、その手順はWebページを見てもらえばわかるとおりかなり長い。実は、スタンドアロンのOGoサーバソフトウェアの動作が完全ではなく、Apacheとのインターフェイスを検証する正当な環境が整わなかったため、これより先の手順は実行していない。
PostgreSQLデータベースとのリンクに関しては、提供されている情報が少なすぎるきらいがある。Webページの指示は手順がいくつか抜けていてるが、その多くについてはFAQ形式のメーリングリストに指摘がなされている。不運にも、私は飛びつくのが早すぎたため、FAQに解決策が載る前に多くの問題に直面してしまうことになったのだ。
PostgreSQLデータベースに接続するには、インストールに関するどのドキュメントにも記載されていないさまざまな作業を行わなければならない。まず、/var/lib/pgsql/data/postgresql.confを編集してtcpip_socket = trueと設定し、以下のコマンドを実行してOGoにPostgreSQLを認識させた。
Defaults write NSGlobalDomain LSAdaptor PostgreSQL72 Defaults write NSGlobalDomain LSModelName OpenGroupware.org_PostgreSQL Defaults write NSGlobalDomain NGBundlePath /opt/opengroupware.org/Library/OpenGroupware.org/
次に、rootで/var/lib/pgsql/data/pg_hba.confを編集し、次の行を追加した。
host all all 127.0.0.1 255.255.255.0 trust
これでローカルノードからPostgreSQLへの接続が受け入れられるようになった。
しかし、サーバがそのディレクトリ構造に情報を保存しようとすると、なんと今度は書き込みエラーが発生し始めたのである。そのため
chown opengroupware.skyrix ../WOApps
を実行して、サーバからディレクトリツリーにアクセスできるようにしなければならなかった。
次に、”opengroupware”ユーザーとなって空のディレクトリ”OpenGroupware.woa/WebServerResources”を削除し、次のコマンド
ln -s /opt/opengroupware.org/WebServerResources/ OpenGroupware.woa/
を実行してリンクを張った。これで、ようやくhttp://localhost:20000/というURLを使ってOGoの管理インターフェイスにアクセスできるようになった。
しかし、それでもすべての機能を使えるようになったわけではない。たとえば、ページ上のすべてのリンクは”wo”および”x”というノード名を想定していたため、この2つのノード名を/etc/hostsに追加し、その両方がlocalhostを指すようにしなければならなかった。
さらに、元に戻ってドキュメントディレクトリ、/opt/opengroupware.org/documentsを作成し、Webサーバーをその新しい場所に差し向ける必要もあった。
Defaults write NSGlobalDomain LSAttachmentPath /opt/opengroupware.org/documents
これで終わりと思ったら大間違い。サーバをスタンドアロンモードでどうにか使えるようになりはしたものの、さらなる問題がいくつも待ちかまえていた。飛ばないリンクがある、画面をいくつか見ただけでサーバが吹っ飛ぶ、前回入力したはずのデータが残っておらず、最初からやり直さなければならない──などだ。サーバにアクセスするためのクライアントソフトウェアの設定など何も説明されていないに等しい。Apacheコネクタのコンパイル手順は示されていたが間違いだらけで、地雷原を歩くような思いをさせられたものだ。
この時点で私は先に進むことをあきらめた。学習、情報収集、デバッグ、ドキュメントの行間を補って読む努力に数時間を費やす結果となった（市販製品のドキュメントを参照しようという考えは見当違いだ。市販製品にはインストーラが付いているから、私が今回遭遇したような問題はそもそも発生するはずがないのだ）。時間をむだにしないため、インストール手順に関するまともなドキュメントが提供されるまで、OGoのインストールは見合わせた方がよいだろう。
まとめ
要するにこういうことだ。ソフトウェア自体の完成度は高いかもしれない。しかし、そのインストール/設定手順はアルファ版以前の代物だ。必要なピースが欠けているので、現時点でそのコードを使うことができるのは開発者本人くらいのものだろう。本稿を執筆している7月12日現在の状態では、企業ユーザがこれをダウンロードしてテストするのは時期尚早だ。
しかし、設定手順だけを整理するだけで済むのであれば、事態は今後1か月以内に劇的に改善するだろう。メーリングリストは、私が体験したのと同じ問題に取り組んでいるユーザたちで盛況だ（ただし、その議論がFAQとしてまとめられるまでに時間がかかっているようだ）。
プロジェクトチームはまっさらなマシンにインストールしようとして悩んだことがなく、作業に必要な手順を単純に書き記しているだけということが明白と思われる。きっと、自分たちの環境で必要な手順だけを書いたはずだ。Webページに記載されている手順に従ってインストールしても、ソフトウェアはリモートマシン上でさえ機能してくれない。これでは、おそらくそれ自体の完成度は高いであろうソフトウェアが泣く。広く普及しているPostgreSQLを使うことを前提としたステップバイステップのインストールガイドさえコードと一緒にリリースされていたら…と惜しまれる。このようなドキュメントが早急に作成されることを切に望む。
今回は、重要な教訓を得ることができた。プロジェクトの構成とコードのリリースをアナウンスすること、そしてもう1つは、産業を変革するソフトウェアの到来をアナウンスすることだ。プロジェクトのアナウンスは暖かく迎えられただろうが、7月10日にリリースされたソフトウェアが実際に企業での使用に耐え得るというのは誰も主張できないだろう。実際にプレスリリースを読み、業務に使用するつもりでそのソフトウェアをダウンロードして時間を浪費した人が他にいないことを願う。プレスリリースに謳われていることが真実と異なることに気づいたユーザは、なかなかそのプロジェクトのソフトウェアをもう一度試そうとはしないはずだ。
OGoは本年度、最も重要なオープンソースプロジェクトとして認められる可能性はある。ただし、それがプレスリリースどおりのものであればだ。 問題がインストールと設定の手順のわかりにくさだけであるなら、あと数週間もすればOGoを導入する企業も出てくることだろう。 インストール手順が整理された頃を見計らって、もう一度OGoのサイトを訪れるつもりだ。 それまでは、OGoを評価目的でダウンロードすることはお勧めできない。 開発者とアルファテスト参加者は、役に立つソリューションを世に送り出したいのであれば、メーリングリストの書き込みを注意深く読むべきだろう。
Russell Pavlicekは、ビジネスでのLinuxの利用を専門に扱うコンサルタント、そしてライターである。週1回のWeb番組『The Linux Show』のパネリストであり、多くのLinux関連Webサイトに協力している。かつては『InfoWorld』誌でオープンソースに関する記事を執筆していた。
