変更点と日本語リソース問題の解決：Apache 2.0でWebDAV（前編）（2/2 ページ）
Apache 2.0の正式リリースにより、WebDAVも新たな段階に入った。拡張性が加わり可能性が広がった一方で、1.3時代のmod_encodingがうまく機能しないといった問題も浮上した。
日本語リソース名の取り扱い
Apache 1.3における日本語リソース名
日本語ファイル名の利用とバージョン管理において、日本語リソース名を使用するに当たっての問題点と、Apache 1.3で日本語リソース名の利用を実現する「mod_encoding」というモジュールを紹介しました。このモジュールを使用することによって、Windows 95／98やWindows 2000などのOSからWebフォルダを使って「日本語」リソース名を扱えるようになります。
Apache 2.0での問題
mod_encodingはApache 1.3用のモジュールです。モジュールのAPIが大幅に変わったため、そのままだとApache 2.0では使えません。
この問題の解決方法は2つあります。
- Apache 1.3＋mod_proxy＋mod_encodingをリソース名のエンコーディング変更用のプロキシとして利用する
- Apache 2.0用のmod_encodingを使用する
実は、WebDAV-JP MLにおいて、Apache 2.0＋mod_dav環境で日本語リソース名が「化けた」という報告と「化けなかった」という報告を受けていました。筆者の環境で試したところ「化けた」ため、Apache 1.3用のmod_encodingを2.0用に試験的に移植してみたところ、うまく動いたので現在WebDAV Resources JP（http://webdav.todo.gr.jp/）にて公開中です。
今回は、後者のApache 2.0用mod_encodingについて解説します。
mod_encodingのその後の機能拡張
前述の日本語ファイル名の利用とバージョン管理でmod_encodingを紹介してから、かなりの時間がたっています。当然、その間何もないわけはなく、着実に機能が増えています。以下に簡単にその機能を挙げておきます。
- セキュリティホールのFIX
2002年6月6日にセキュリティホールの存在が確認されました。最新リリースではこのセキュリティホールをFIXしてあります。 - 多様なiconvライブラリの使用／拡張のためのインターフェイス実装
iconv_hookライブラリによってこの機能を実現しています。 - GNU autotools化
configure＋makeでコンパイル可能になりました。 - Windows XPの認証ユーザー名表記対応
最後の「Windows XPの認証ユーザー名表記対応」は、Windows XPでユーザー認証を実施した場合、ユーザー名が「サーバのIPアドレス\ユーザー名」という形式になってしまうという問題への対策です。mod_encodingの最新版では、最初の「サーバのIPアドレス\」という文字列を消し、ユーザー名のみを取り出す設定が可能です。
iconvライブラリとGNU autotools化以外は、すべてmod_encodingの機能そのものです。もちろん、最新版のApache 2.0対応版mod_encodingにも取り込んであります。
mod_encodingのインストールと設定
mod_encodingのApache 2.0対応化
以下の2つのファイルをWebDAV Resources JP（http://webdav.todo.gr.jp/）のdownloadメニューからダウンロードします。mod_encoding.c.apache2.20020611aはmod_encoding.cのApache 2.0用差し替えファイルですが、これはExperimental（試験的実装）の扱いです。
- mod_encoding-20020611a.tar.gz
- mod_encoding.c.apache2.20020611a
次に、mod_encoding-20020611a.tar.gzを展開してmod_encoding.cを差し替えます。
$ gzip -dc mod_encoding-20020611a.tar.gz | tar xvf - $ cp mod_encoding.c.apache2.20020611a mod_encoding-20020611a/mod_encoding.c
iconv_hookライブラリのコンパイルとインストール
iconv_hookライブラリのコンパイルとインストールを行います。iconv_hookライブラリとは、プラットフォームやライブラリによって異なるiconv()の動作について、一部のエンコーディングの扱いを変更するようなライブラリに差し替えたりできる動作フック用のライブラリです。
$ cd mod_encoding-20020611a/lib $ ./configure $ make $ su root # make install
この作業が正常に終わると、libiconv_hook.so（iconv_hookライブラリ）が/usr/local/lib配下にインストールされます。
mod_encodingのコンパイルとインストール
$ cd .. $ ./configure --with-apxs=/usr/local/apache2/bin/apxs $ make $ su root # make install
この作業が正常に終わると、mod_encoding.soライブラリが/usr/local/apache2/modules下にインストールされます。
トラブルシューティング
ここまでで、iconv_hookライブラリとmod_encoding.soがインストールされていると思いますが、mod_encodingのインストール時に「mod_encoding.soファイルがない」と怒られるケースがあります。
この原因が、/usr/local/apache2/buildにあるlibtoolスクリプトの内容が一部不正な状態になっているため、libtoolを使っても.soファイルが作成できないことにあるというところまでは突き止めています。そこで、2つの解決方法を提示しておきます。
●libtoolの内容を編集して直す
筆者が.soの生成に失敗した際、/usr/local/apache2/build/libtoolは以下のように記述されていました。
host_alias=
dlopen_support=unknown
dlopen_self=unknown
dlopen_self_static=unknown
この部分を、
host_alias=i686-pc-linux-gnu
dlopen_support=yes
dlopen_self=yes
dlopen_self_static=no
のように修正します。ただし、これだけではmake installしてもmod_encoding.soを探してもらえないので、
$ cp .libs/mod_encoding.so /usr/local/apache2/modules
などとして.libsに作成されたmod_encoding.soを手動で/usr/local/apache2/modulesにコピーします。
●libtoolを使用せず、gccで最終的な.soファイルを作成する
gccを使って、直接.soファイルを作成する方法もあります。
$ gcc -shared -o mod_encoding.so mod_encoding.o -Wc,-Wall -L/usr/local/lib -Llib -liconv_hook
などというようなコマンドラインを実行し、mod_encoding.soを作成します。こうして作成したmod_encoding.soは、mod_*なモジュールが格納されるディレクトリにコピーしてやることで使用可能になります。
mod_encodingの設定と使用
mod_encodingがインストールできたら、実際に動かしてみましょう。httpd.confの適切な個所に、
LoadModule encoding_module modules/mod_encoding.so <IfModule mod_encoding.c> EncodingEngine on NormalizeUsername on SetServerEncoding UTF-8 DefaultClientEncoding JA-AUTO-SJIS-MS SJIS AddClientEncoding "cadaver/" EUC-JP </IfModule>
と記述することでmod_encodingが動作します。実際の動作は、日本語ファイル名の利用とバージョン管理で紹介しているのと何ら変わることはありません。
mod_davによるperchild MPMの活用
冒頭に書いた「不安定になってしまったが、安定すればWebDAVを利用するに当たって非常に有用なもの」が「perchild MPM」です。
perchild MPMは不幸にして動作が安定せず、Apache 2.0.36のリリースでexperimentalになってしまいましたが、Apache 2.0の新機能とその実力に書かれている以上の拡張が行われています。具体的には、
起動時に生成するサーバプロセスに、個別のユーザー権限を割り当て可能
という機能が付加されています。この機能の概念を図2に示します（注）。
注：perchild MPMは、最初に生成した数以上のプロセスを生成しません。そのためにこうした動作が容易になったのだろうと思います。いまだに安定していませんが……。
この機能が実現すれば、図2のようにhttpdのユーザー権限とは異なるプライベートな（例えばユーザーwakatono権限やユーザーkmiya権限などを持った）VirtualHostを立ち上げることが可能になります。この場合、suexecのようなwrapperを持つ必要がなく、より自由度が上がります。
本格的なアクセスコントロールを実現するためには、ACLのRFC化と実装を待つ必要がありますが、ファイルを読み書きするためのプライベートストレージとしては十分な機能といえるでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.