変更点と日本語リソース問題の解決Apache 2.0でWebDAV(前編)(2/2 ページ)

» 2002年06月25日 00時00分 公開
[宮本久仁男NTTデータ]
前のページへ 1|2       

日本語リソース名の取り扱い

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 ユーザー権限を分けられるため、複数のApache(httpd)を起動する必要がない 図2 ユーザー権限を分けられるため、複数のApache(httpd)を起動する必要がない

 この機能が実現すれば、図2のようにhttpdのユーザー権限とは異なるプライベートな(例えばユーザーwakatono権限やユーザーkmiya権限などを持った)VirtualHostを立ち上げることが可能になります。この場合、suexecのようなwrapperを持つ必要がなく、より自由度が上がります。

 本格的なアクセスコントロールを実現するためには、ACLのRFC化と実装を待つ必要がありますが、ファイルを読み書きするためのプライベートストレージとしては十分な機能といえるでしょう。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。