特集 Linuxで動く.NET環境「Mono 1.0」の実力（後編） 株式会社ピーデー 川俣 晶 2004/10/20
Page1 Page2 Page3 Page4

Apacheを用いたASP.NET

　Mono Projectでは、Apacheの中でASP.NET Webアプリケーションの実行を実現するプラグイン・モジュール「mod_mono」も提供している。これはまだ開発中のもので、完成度は高くない。ソース・コードで入手して、自分でmakeを行う必要があるというだけでなく、動作させるハードルがとても高いといわれている。

　実は筆者は、これを動作させる再現可能な手順を確立するまでに、（それだけに専念していたわけではないが）約3週間半の時間を費やしてしまった。もちろん試行錯誤の中でいつ正解に突き当たるかは確率の問題なので、もっと短い時間で動作させられたかもしれない。実際、動作させるだけなら取り組んだ初日に実現できていたのだが、動作する条件を確定するために残りの時間を費やしたことになる。ちょっとした思い込みによって、関係ない個所で試行錯誤を繰り返したことが理由ではあるが、そのような勘違いが私だけの専有物であるという保証はどこにもない。

　さて、以下に再現可能なインストール手順を説明しよう。ただし、この手順の中には、サーバよりその時点での最新版のソフトウェアを取得する手順があり、それによって完全に同じ条件が再現できない可能性があることをお断りしておく。

　なおここでは、前編の「Mono 1.0.1のインストール」で述べた手順により、Mono 1.0.1がインストールされている（「yum install mono-complete」の実行が完了している）状態となっているところから、mod_monoのインストール手順を解説する。

　Mono 1.0.1のインストールに続いては、まずXSPをインストールするのだが、この手順は前編で述べたXSPのインストール手順と異なることに注意が必要である。

　というのも、Apacheのmonoプラグインであるmod_monoは、/tmp/mod_mono_serverという名前付きパイプを経由して、/usr/bin/mod-mono-server.exeに実際の処理を要求するのだが、このmod-mono-server.exeがmod_monoの期待する書式のデータを返さないことが筆者の経験した問題の原因であった。

　このmod-mono-server.exeは、mod_monoの一部ではなく、XSPに含まれるxsp.exeの派生ソフトウェアである。「yum install xsp」によりインストールされるxsp.exeは問題なく動いているように見えるのだが、同時にインストールされるmod-mono-server.exeに問題があった。結局、mod_monoが期待するとおりの通信を行うmod-mono-server.exeを手に入れるには、自分でXSPをmakeしてインストールすればよいということが分かった。そこで、ここでは次にこれをroot権限でmakeする。

■makeによるXSPのインストール

　まず、Mono Projectのサイトより、XSP web server 1.0.1（xsp-1.0.1.tar.gz）を/rootにダウンロードしておく。

　次に、GNOME端末を開き、以下のコマンドを順に打ち込む。

tar xvfz xsp-1.0.1.tar.gz
cd xsp-1.0.1
./configure --prefix=/usr
make
make install
cd ..


■makeによるmod_monoのインストール

　次に、プラグインであるmod_monoをインストールする。まず、Mono Projectのサイトより、Apache Mono module 1.0.1（mod_mono）（mod_mono-1.0.1.tar.gz）を/rootにダウンロードしておく。

　すでに開いているGNOME端末上で、引き続き以下のコマンドを順に打ち込む。

tar xvfz mod_mono-1.0.1.tar.gz
cd mod_mono-1.0.1
export CFLAGS=-I/usr/include/apr-0
./configure --prefix=/usr
make
make install
cd ..


　ちなみに、「export CFLAGS=-I/usr/include/apr-0」という部分を忘れるとmakeに失敗する。これは、必要なヘッダ・ファイルがデフォルトのインクルード・ファイルの検索パス内になく、発見できなかったようなので追加したものである（これが最善の手段であるかは分からないが、とりあえずこれでうまくいったのでここに記しておく）。

■Apacheの設定

　以上で、プラグインmod_monoのインストールは完了したが、これだけではまだASP.NETは使えない。XSPの場合と同じように、XSPのデモ・ページを閲覧可能にするには、/etc/httpd/conf/httpd.confの最後に以下の設定を書き加える。

Alias /demo "/usr/share/doc/xsp/test" MonoApplications "/demo:/usr/share/doc/xsp/test" <Location /demo>     SetHandler mono </Location>

/etc/httpd/conf/httpd.confに追加する設定

この設定により、Apache上でXSPのデモ・ページを実行させることができるようになる。

　ここまでできたら以下のコマンドを実行して、Apacheをスタートさせよう。

apachectl start

　すでにApacheがスタートしているなら以下のコマンドを実行して、Apacheを再起動する。

apachectl restart

■ApacheでASP.NET Webアプリケーションを実行

　以上で準備は完了である。同一マシン上のWebブラウザから以下のURLにアクセスしてみよう。

http://127.0.0.1/demo/

　もちろん、ほかのPCからもアクセスできる。以下はWindowsマシンのInternet ExplorerからApache上で動作するASP.NETにアクセスした例である。開いたページは、XSPの解説でアクセスしたページと同じである。

Apache上で動作しているXSPのデモ・ページ

この画面は、WindowsからLinux上のApacheにアクセスしているところ。

　

Apache上で動作しているbutton.aspx

　以上のように、Linuxカーネル上のApacheでASP.NETを動作させることは確かに可能であった。この例を見ると、インストールのハードルが高いために難しいと思った読者も多いかもしれない。確かに筆者が行った作業のハードルは高い。何しろ、単に時間がかかっただけでなく、CとC#のソースを読み、エラー・ログにメッセージを書き出させるコードを書き加えて実行するprintfデバッグもどきも行ったのである（より正確にいえば、あまりに時間がかかりすぎるのでソースの領域にまで入って動作確認を行ったところ、大きな思い違いが判明して、それから進展が見られるようになった）。これだけのハードルをクリアできるユーザーが、それほど多いとは思えない。

　しかし、実際に業務で使うことを考えれば、業者がASP.NETを動作可能な状態にセットアップしたPCを提供するか、あるいは、セットアップすればASP.NETがすぐ動作するように設定済みのインストール媒体を提供することになると思うので、さほど大きな問題ではないだろう。また、このプラグインはまだ開発中のバージョンで不安定であること考えれば、近い将来、より確実かつ安定的にインストールして動作するようになると考えることも可能だろう。

　いずれにせよ、まだ生まれたばかりのソフトウェアである。幼い子どもが短い時間に大きく変わっていくように、mod_monoも大きく変わっていく可能性は十分にあり得る。もうしばらく、温かい目で見守ってもよいのではないかと思う。

終わりに

　今回の記事は、ひたすら時間に敗北した感がある。例えば、MonoでGUIアプリケーションを作成するためのクラス・ライブラリ「gtk#」や、統合開発環境には触れることもできなかった。もちろん、この記事に費やした時間は決して短いものではない。むしろ、原稿料から考えて大赤字と考えてよいだけの時間を注ぎ込んだ。それにもかかわらず、時間に敗北した理由は、情報不足と、ソフトウェア間の依存性にあるように感じられる。これは、Monoに限らず、オープンソースが克服すべき課題という印象も受ける。以前のEclipse C#プラグインの記事を書いたときと印象が似ているからだ。

　情報不足というのは、公式のドキュメントに不備があることや、情報へのアクセス方法が分かりにくいことである。Monoの公式のドキュメントは、まだまだ圧倒的に不足という感がある。ページがあっても中身がまだ書かれていないものすらあった。

　また、知りたいことに到達する経路も明確ではない。コマンドの使い方は、それをインストールできてしまえば「man コマンド名」で調べることができるのだが、用意されたコマンドにどのようなものがあるか分かりにくかった。例えば、JITではなくインタプリタとしてプログラムを実行するmintコマンドは、正規ドキュメントの「Tools and Reference」の配下には説明が見つからなかった。「man mint」は実行できるが、もちろんmintという名前を知らなければ使うことができない。

　このような、ドキュメントの不備やアクセス性の悪さは、Monoに限らずオープンソースに典型的に見られる傾向ではないかと思う。確かに、マイクロソフトのMSDNライブラリも万全であるとはいえないし、アクセス性が良いともいえないが、それでもまだMSDNライブラリの方に一日の長がある感じを受ける。

　もう1つのソフトウェア間の依存性という問題は、これを使うにはあのソフトウェアが必要というような関係が複雑に絡み合っている状況を意味する。昔のUNIXは、そのような絡み合いの少ない世界であって、依存性の絡み合い（いわゆるDLL Hell）に苦しむWindowsを高みから笑えたように思う。しかし、微妙に違う流儀のディストリビューションの増加、OSとは別のサイクルで開発される主要なソフトウェアへの依存、共有されるライブラリの増加などによって、いまのLinuxは混乱と複雑の度合いが加速している感がある。今回筆者が遭遇した問題も、互いに通信を行うmod_monoとXSPの非互換性にあった。もしや、歴史は繰り返し、Windowsの世界がようやく克服しつつあるDLL Hellの類似問題に、Linuxも巻き込まれているところなのだろうか。

　いずれにせよ、多くの問題がまだあることは踏まえたうえで、1人のC#プログラマとして、Monoが誕生したことは歓迎したい。自分の書いたコードが実行できる環境が増えることは、それだけで大きな力となる。また、互換性のあるコンパイラや実行環境が複数あれば、そこには当然切磋琢磨する競い合いが発生するだろう。それは、ソフトウェアの前向きな進歩をもたらし、利用者のメリットとなる。そのような状況をもたらしてくれたMonoは、歓迎するに値する存在ではないだろうか。

INDEX
	［特集］Linuxで動く.NET環境「Mono 1.0」の実力（前編）
	1．WindowsとLinuxとを結ぶ「Mono」
	2．Monoが生まれた背景
	3．Monoの機能とインストール
	4．C#コンパイラとVB.NETコンパイラ
	［特集］Linuxで動く.NET環境「Mono 1.0」の実力（後編）
	1．バイナリの互換性を検証する
	2．環境間の相違と対策／Monoと.NET Frameworkとの速度比較
	3．XSPを用いたASP.NET
	4．Apacheを用いたASP.NET

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）