このページでは、mod_dav のコンパイル、インストール、そして設定について可能な限り多くの情報を解説していきます。なお、バイナリ形式で配布されているmod_davの設定についてはこのページではサポートしませんが、Apacheの設定については適用可能です。
|
このページで"UNIX"と表記している部分は、一般的にはあらゆるUnixやUnixライクなプラットフォーム(Linux,*BSD,Solaris,AIX,HP/UX他)を示します。
[ back to the main mod_dav page ]
mod_davをインストールするには、2通りの方法があります。1つは、apxsコマンドを使ってダイナミックリンクモジュールとしてmod_davを作成する方法、もう1つはApacheの実行形式にmod_davのモジュールをスタティックリンクする方法です。
どの方法を選ぶかによって、以下のいずれのコマンドラインを使うかが変わります。ダイナミックリンク形式にするのであれば前者を、スタティックリンク形式にするのであれば後者を選んでください。
./configure --with-apxs=/usr/local/apache/bin/apxsまたは
./configure --with-apache=/usr/local/apache
もちろん、前者で指定するのは apxs コマンドですし、後者で指定するのは Apache のビルドディレクトリです。
注意:もし単に--with-apxsを指定しただけ（パスの記述なし）の場合、configure スクリプトはapxsコマンドはすでにpathが通っているものとみなします。
注意:時々、インストールされているAPXSが不正な動作をすることがあります。このような場合は、PHPのFAQエントリを参照してください。そちらには、そのような問題についてよく解説されています。
configuration中、Expatライブラリ（XMLパーサライブラリ）を見つける処理があります。このライブラリはApache1.3.9（以降）に含まれ、通常は自動的に見つけられます。しかしもしそれより古いバージョンのApache（最低でも1.3.4以上である必要がありますが）を利用している場合、Expatをどこかから入手する必要があります。configureは、/usr/{include,lib}や/usr/local/{include,lib}を探しますが、これで見つからない場合は configure は --with-expat=<dir> というオプションを付加して Expat ライブラリのありかを指定する必要があります。例えば以下のような具合になります。
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-expat=/home/gstein/expat Expatが必要な場合は、このドキュメントの最後のセクションを読んで下さい。Expatの入手とインストールの方法が記述されています。
ここは本当に簡単です。以下の2つのコマンドを実行してください。
makemake install
もしAPXSを利用してダイナミックリンクモジュールとすることを選んだのであれば、この時点でApacheの実行環境にモジュールはインストールされています。
注意: APXSを利用して、かつインストールされているApacheがダイナミックリンクをサポートしていない場合は、APXSコマンドはエラーを出力して終了します。このような場合は、おおむね以下のようなメッセージが出力されます。
apxs:Break: Command failed with rc=16711680
このような状態になった場合は、Apacheをmod_soモジュールを含めて再ビルドの上再インストールしてください。
1点注意することは、再インストールの時点で新しいApacheがビルドされてインストールされても新しいAPXSがインストールされないことがある点です。このような場合、問題は解決されません。
PHPは、このような問題への対処をそのFAQ entryの中で述べています。
mod_dav を Apache にスタティックリンクする場合、mod_dav は部分的にコンパイルされ、make installを実行する時にApacheをビルドするソースツリー配下に配置されます。この時点で、はじめてApacheを（再）ビルドする準備が出来ました。Apacheをconfigureする時に、2つの方法が選べます。APACIスタイル（./configureスタイル）を使う時は、以下のコマンドラインオプションを./configure実行時に付加してください。
--activate-module=src/modules/dav/libdav.a
オールドスタイルのコンフィグレーションを採用する場合は、Configure.tmplファイルに以下の行を追記してください。
SharedModule modules/dav/libdav.a
まず最初に、Expatをインストールしなければなりません。このドキュメントの最後の方に、Expat セクション の説明があるのでそちらを参照してください。
Microsoft Visual C++ を使って mod_dav をビルドするのであれば、以下のコマンドラインをmod_davのファイル群が格納されているディレクトリで実行するだけです。
nmake /f mod_dav.mak この手順で、最適化されたバージョンの mod_dav がRelease/mod_dav.dllとして作成されます。
mod_davは、提供される .dsp ファイルを用いることで、Microsoft Visual Studio 5.0以降でビルドすることも可能です。
mod_davのインストール時には、以下の3つのファイルを Apache のモジュールが格納されているディレクトリ（ServerRoot）にコピーして下さい。
Release/mod_dav.dll expat/bin/xmlparse.dll expat/bin/xmltok.tll
もしコンパイル済みのバイナリを使うのであれば、これらの3つのDLLがServerRootディレクトリにあることを確かめてください。
Apache に mod_dav を追加するためには、以下の行をhttpd.confファイルに追加してください。
LoadModule dav_module mod_dav.dll mod_dav 0.9.8以前のバージョンを利用している場合、注意を参照してください。
AddmoduleディレクティブとLoadModuleディレクティブを用いてApacheがmod_davを利用する旨を設定する必要があります。LoadModuleディレクティブは、mod_davをダイナミックリンクするように作った場合にのみ指定します（例えば、APXSを使ってmod_davをビルドした時や、Win32プラットフォーム上で実行する場合には指定が必要です）。これらの設定行は、UNIXプラットフォームでインストールした場合は、（通常は）自動的に挿入されます（ダイナミックリンクモジュールとしてmod_davをビルドした場合のインストール時、もしくはスタティックリンクモジュールとしてmod_davをビルドした上でApacheそのものをビルドする時）。しかし、Win32プラットフォームの場合は手動で設定ファイルを編集し、それらの行を追加する必要があります。
（この情報は、参考のためにここに書いてあります。もしApacheがDAVやDAVLockDBのようなmod_davで追加されたディレクティブを解釈できないような場合は、先述の設定行が抜けている可能性があります。）
Loadmodule dav_module libexec/libdav.so Addmodule mod_dav.c
Addmodule mod_dav.c
Loadmodule dav_module mod_dav.dll Addmodule mod_dav.c
mod_davモジュールの機能を設定するのは非常に簡単です。実際には、Apacheの設定ファイル（例：httpd.conf）中で指定される<Directory>ディレクティブもしくは<Location>ディレクティブ中にて、以下の行を挿入するだけです。
DAV On もしDAVが<Directory> ディレクティブの中で指定される場合、DAV機能はそのディレクトリおよびサブディレクトリの中で有効になります。<Location>ディレクティブの中で指定される場合は、DAV機能はそのディレクティブが指し示すURL名前空間中で有効になります（訳注：例えば www.foo.bar という Web サーバにおいて、<Location /hoge>という指定がされている場合、DAV機能はhttp://www.foo.bar/hoge/という文字列で始まるURL名前空間上で有効になります。）。
次に、DAVLockDBディレクティブを設定ファイルのトップレベルで設定してください（例えば、<Directory>ディレクティブや<Location>ディレクティブの外など）。このディレクティブでは、mod_davが作成するファイル名を指定する必要があります。このファイルが作成されるディレクトリについては、Webサーバプロセスが書き込み可能である必要があります（訳注：例えば、Apacheをユーザnobody権限で走行させている場合、DAVLockDBディレクティブで指定するファイルを作成するディレクトリは作成されている必要があり、かつnobody権限でファイルを作成できる必要があります。）。
注意:ここで指定するディレクトリは、NFSマウントされたパーティションであってはなりません。mod_davは、flock()/fcntl()を使ってロックデータベースへのアクセスを制御していますが、中にはNFSマウントされた領域についてこれらの制御が出来ないOSがあります。
以下の例では、DAVロックデータベースが/usr/local/apache/varディレクトリ配下に作成されます。mod_davが必要に応じてロックデータベースファイルを作成しますが、その名前はDAVLockというものになります。
（実際には、mod_davは1つ以上のファイルを作成します。そして、そのファイル名は指定したファイル名（この場合は DABLockDB）に拡張子を付加したものになります）
DAVLockDB /usr/local/apache/var/DAVLock DABLockDBディレクティブは、いかなるコンテナ（ディレクティブ）にも含まれないか、もしくは<VirtualHost>の中にのみ含まれ、1回だけ指定が可能です。また、ファイルの拡張子は指定しません。
追加指定可能なディレクティブとして、DAVMinTimeoutディレクティブがあります。これは、ロックの最小生存時間を秒単位で指定するものです。クライアントがDAVMinTimeoutで指定した時間より短い時間をロックタイムアウトの時間として指定した場合、DAVMinTimeoutで指定した値がロックタイムアウト値として採用され、返却されます。例えば、MicrosoftのWebフォルダは、ロックタイムアウト値が2分に設定されますが、ネットワークトラフィックを減らしたりネットワークの遅延によりロックが失われたりすることを想定して、このタイムアウトを10分にすることが可能になります。
DAVMinTimeoutディレクティブはオプショナルであり、サーバごとやディレクトリ／ロケーションごとに指定することが可能です。値としては、単一の正の整数を指定可能です。この値が設定されることで、最小タイムアウトが有効になったといっても、0を設定すると機能が無効になります。DAVMinTimeoutのデフォルト値は0です。
Depth: Infinityヘッダが付加されたPROPFINDリクエストが投げられると、サーバに巨大な負荷が発生します。この種のリクエストは、全てのリポジトリを走査し、見つかったリソースごとの情報を返却します。mod_davは、返却する情報をメモリの上で組み立て、結果としてこの種類のリクエストは潜在的に大量のメモリを消費します（もちろんリクエストが完了するとこれらのメモリは解放されますが、ピーク時のメモリ消費量は巨大になります）。
このような類のリクエストを回避するために、DAVDepthInfinityディレクティブが提供されています。on/offのみ設定可能なシンプルなディレクティブで、サーバごとやディレクトリ／ロケーションごとに指定することが可能です。このディレクティブのデフォルト値はoffです。これは、この種類のリクエストは許可されないことを意味します。
注意:WebDAV Working Group は、DAVサーバがこの種類のリクエスト拒否することは許容できる旨述べています。適切に記述されたクライアントソフトウェアは、そのようなリクエストを出すべきではありませんし、この設定を無効にすることについて心配することはありません。
mod_davは、メモリ上でXMLリクエストボディをパースします。mod_davサーバに対して巨大なリクエストボディを送ることは、効果的な"Denial of Service"アタックになります。（これに対抗するために）ApacheではLimitRequestBodyディレクティブを定義していますが、これは全てのメソッドについて、そのリクエストボディの大きさを制限します。不幸なことに、mod_davサーバに対して巨大なデータを伴ったPUTリクエストを許可しなければならないような場合は、あまり効果的なしくみではありません。
XMLリクエストボディを持ったメソッドのみを制限するために、mod_davではLimitXMLRequestBodyディレクティブを定義しています。デフォルト値はコンパイル時に設定されている定数で決定され、その値は通常は1000000バイトです。この値を0に設定した場合、XMLボディの大きさに制限はなくなります。
LimitXMLRequestBodyは、サーバごとやディレクトリ／ロケーションごとに指定することが可能です。そして単一の正の整数を指定します。
DAVに関するサンプル設定は以下のようになります。
|
DAVディレクティブおよびDAVLockDBディレクティブの2つを指定するだけで、DAVサーバ機能を追加するための設定は完了します。しかし、通常は、特定のユーザのみに対して書き込みを許可するのがサイトを安全に保つためにはベターです（訳注：原文ではベストとなってましたが、それ以上に良い方法がありそうなのでベターとしてます）。このためには、<Limit>ディレクティブの指定が必要です。以下に指定例を示します。
|
上記の設定では、認可されたユーザに対してサイトの操作を許可しています。しかしながら、この設定では思ったより少し広い自由度を許可することになります。特に、認可されたユーザが.htaccessファイルをターゲットディレクトリに置いて、サーバの設定を変更することが出来てしまうかもしれません。もしかしたら、サーバの設定で.htaccessファイルの類を読めないように設定しているかもしれませんが、確認するのが確実です。また、DAV機能が有効なディレクトリについて、CGI,シンボリックリンク,SSIその他の機能を無効にしたいとも思うかもしれませんね。ここでは追加で制限をかけた形の設定を示します。
|
LimitExceptの使用サーバをセキュアに保つために、<Limit>ディレクティブを使って制限するHTTPメソッドのリストを指定するのもいいですが、<LimitExcept>ディレクティブを使った指定も可能です。このディレクティブは、指定したメソッド以外の全てのメソッドについてアクセス制限を適用します。設定の例を以下に示します。
|
<LimitExcept>ディレクティブを使うか、それとも<Limit>ディレクティブを使うかは、どのような指定を優先するかだけの問題です。<Limit>ディレクティブは正確であり、かつ明示的に制限するメソッドを表現します。しかし<LimitExcept>ディレクティブは将来的に追加されるかもしれないメソッドについても自動的に制限がかかります。
上記の設定例において、read-onlyなものであるにもかかわらずPROPFINDメソッドが制限されています。これは、PROPFINDメソッドによって、DAV機能が有効になったディレクトリについて、ファイル一覧が取得できてしまうからです。セキュリティ上の理由から、普通はファイル一覧が見えないことを希望するでしょうね。
その他、コンテンツの変更を行うメソッドは限られたメンバにしか開示しない一方で、PROPFINDについてはユーザグループ、ドメイン、ホストの単位で許可したいと思うことがあるでしょう。このシナリオは、例えば、あなたの会社の従業員がサーバーのファイルをブラウズすることを可能にします。しかし、それらを変更できるのは数人だけであり、匿名の(認証されなかった)外部の人間はそれをブラウズしたり修正することはできません。
結局、Webサーバを一般的かつ読み取り可能なファイルリポジトリとして構成することを指向しているのであれば、PROPFINDの制限を単純に省略することができます。こうすることで、誰もがディレクトリの内容をブラウズし、かつファイルを読み取ることを許可します。
mod_davのメインWebページ上にあるmod_davのセキュリティセクションをご覧になることをお薦めします。DAVに関連した（特にmod_davに関連した）セキュリティ上の問題点について、さらなる情報が記されています。
それらのバージョンについては、DAVLockDBディレクティブを含んでいません。従って、適切にmod_davを使いたい場合はその指定を追加して下さい。
mod_dav はドキュメントが格納されるファイルシステムに対するread/writeアクセスを行います。以下につきましては、例としてUNIXを用いますが、Win32プラットフォームでNTFSパーティション（ファイル／ディレクトリセキュリティが提供されているパーティション）を使う場合はUNIXの場合と類似します。
read/writeアクセスの必要は、ファイルのオーナやグループがWebサーバプロセスのそれになるだろうということを意味します。議論のために、Apacheの設定において以下のディレクティブが含まれていることを前提にします。
|
上記の設定において、Webサーバプロセスはユーザ"nobody"、グループ"www"として走行しています。mod_davは、/home/www/davhomeディレクトリに対してファイルを読み書きしますが、ディレクトリの内容一覧は、たとえばこんな感じになります。
|
この例では、Webサーバプロセスはファイルリポジトリ/home/www/davhomeにあるファイルの読み書きをするにあたってなんの問題も起きないでしょう。
注意:ファイルリポジトリはmod_davやWebサーバからは「プライベートである」（他の操作の干渉を受けない）とみなされています。FTPや他のファイルシステムを操作するコマンドによるファイルの変更については、許可されるべきではありません。これは、以下の対になった理由によります。
DAVスペック(RFC2518)は、セキュリティモデルは組み込まれていません。これについては、Webサーバやファイルシステムセキュリティに依存しますし、それらはサーバ管理者の設定に依存します。
UNIXマシンにおいて、Webサーバプロセスは、DAV機能を有効にしたディレクトリやDAV機能を使っての変更対象となるファイルについてwriteを行う権限をもっていなくてはなりません。
DAV機能を有効にしたディレクトリに格納されているファイルをサーバローカルで操作することはよいこととはいえません。特に、DAV経由のファイルロックはmod_davにて実装されていますが、これはファイルシステムのロック機構とは無関係です。
James Clark の Expat パーサは、Apache 1.3.9 およびその後リリースされているApacheには含まれています。従って、それより古いバージョンのApacheを使う場合にのみ、Expatの配布パッケージを取得し、ビルドすることが必要となります。
Apacheの配布物中には、コンパイル済みのExpat DLLは含まれていません。しかし、Win32 版 mod_dav の配布物中にこれらは含まれます。
必要であれば、James Clark の Expat パーサは、以下のところから取得可能です。
http://www.jclark.com/xml/
mod_dav のファイルが格納されたディレクトリ配下に Expatパーサの .zip アーカイブを展開してください。この際に、zip中に格納されたフォルダを使ってください。Expat は expat/サブディレクトリに展開されるはずです。
ExpatのMakefileを利用したからといって、自動的に Expatライブラリを作ってはくれないことに注意して下さい。以下のルールをMakefileに追加して下さい。
libexpat.a: $(OBJS) ar -rc $@ $(OBJS) ranlib $@
（ar と ranlib について記述がある行の先頭にTABを挿入するのを忘れないで下さい）
それから、make libexpat.aとタイプして下さい。
そして、libexpat.aを、/usr/local/libにコピーして下さい。そして、xmlparse/xmlparse.hを/usr/local/includeにコピーして下さい。もし異なるディレクトリへそれらのファイルをコピーしたいのであれば、./configure実行時にコマンドラインオプション--with-expatを付加してください。
インストール、設定、mod_davの操作に関する問題があったら、dav-dev mailing listまでその旨を送って欲しい。このMLには、あなたの問題解決の助けになる知識を持った人が多くsubscribeしており、Gregのメールボックス（いつもいっぱいです）に対して直接メールを送るよりも早く問題解決ができるでしょう。
あなたがメールを送る時に含めなければならない情報は、例えば以下のようなものです。
httpd.conf中の適切な部分
error_logやaccess_logの適切な部分
dav-dev MLにメールを送る時は、以下のアドレスになります。
dav-dev@lyra.org
ML参加の案内やMLのアーカイブへのリンクは以下のとおりです。
http://dav.lyra.org/mailman/listinfo/dav-dev
Apacheは、リクエストを処理するにあたって、1つの「コンテントハンドラ」しか許可されないと固有の設計上の制限があります。認証、アクセスチェック、MIMEタイプ操作その他複数のステージがありますが、コンテントハンドラはただ1つしかありません。
コンテントハンドラは、SetHandlerディレクティブ、AddHandlerディレクティブ、もしくはMIMEタイプと対応づけることで間接的に指定されます。リクエストを処理している間は、Apacheモジュールもそれらをハンドラとしてアサートします。mod_davもこれに従い、特定のディレクトリやロケーションにおいてDAVディレクティブが指定され、DAV機能が有効である場合に、自分自身をアサートします。コンテントハンドラは、リクエストメソッドに基づいて自分自身をアサートするかどうか決定できます。mod_davは、PUT,DELETE,PROPPATCHのようなメソッドの時には自分自身をアサートしますが、GETメソッドのようなものを処理する場合にはアサートしません（他のモジュールやApache自身により処理されるために残ります）。
これにより生じる問題は、リクエストメソッドにかかわらず多くのモジュールが自分自身をアサートしようとすることです。PHPやCGIモジュールがPROPFINDメソッドに対して完全なレスポンスを行う機能を有していると仮定すると、DAVクライアントがPROPFINDを発行した時に、mod_davでない他の（それらの）モジュールにより横取りされたりする可能性があります。しかしmod_davがそのメソッドの処理を行われることを（ユーザは）望んでいます。
以下のセクションでは、いくつかの一般的な問題とそれらの解決法についてカバーします。
問題点: CGIスクリプト,サーバ側でパースされる（.shtmlのような）ファイル、もしくはPHPファイルのような、ダイナミックなリソースに対するコピーを試みると、以下のようなメッセージが記述されたエラーダイアログが表示されるだろう。
An error occurred copying some or all of the selected files.
これは、サーバサイドスクリプトがLast-Modifiedヘッダを返さないことに起因して発生する問題です。もし（例えばCGIやPHPなどの）スクリプトがこのようなヘッダを返すことをサポートしているのであれば、Last-Modifiedヘッダが返却されることを保障するよう変更されるべきです。
注意:以下の推奨設定は、機能しないということがわかりました。この設定は、ダイナミックスクリプトの出力に対し、一定のLast-Modifiedヘッダを付加するためのものです。ユーザのブラウザやProxyは、一定の時間を見ると出力は変更されていないと信じます。この時、その問題に対する特定の答えはありません。
（（.shtmlのような）サーバ側でパースされるHTMLファイルのように）スクリプトがヘッダを返せない場合、Apacheに対してmod_headersモジュールを導入することで解決が可能です。次に、httpd.confに対して以下のような設定を追加してください。
|
指定する日付は未来であってはなりません。このように設定することで、サーバー側でパースされるファイルはすべて特定の一定の変更日を持ったかのように振舞うことでしょう。しかし、事態は改善するかもしれません。
注意: 私は、決まった時間を持ったLast-Modifiedヘッダを強要する分岐を発見するための徹底的なテストを実行していません。私のテストでは、Webフォルダによるコピーが成功するかどうか、そしてInternet Explorer経由でのアクセスを行った際に正しく動作するかということしか確認してません。
これは、GETが常にスクリプトを実行するということから引き起こされています。「スクリプトの実行結果を受け取るためのGET」と、「オーサリングのためのGET」を識別するための方法はありません。
注意:この問題は、あらゆるサーバサイドスクリプティングソリューションにあてはまります。PHPに特化した問題ではありません。でもの目的で、PHPを例に使ってみます。
PHPとmod_davは、異なるHTTPリクエストメソッドを取り扱う時にコンフリクトを起こす可能性があります。これは、両方のモジュールが同じロケーションもしくはディレクトリについて設定されているという単純な事実のために引き起こされます。そして、どちらもコンテントハンドラとして動作しようとして、動作が競合します。
これを解決するには、いくつかの方法があります。PHPのソースにアクセスするための独立したURLを提供することで、問題は全て解決可能です。
|
他の解決法は、例えば以下のような設定を使い、バーチャルサーバを通じてソースを見せることです。
|
同種の設定を行う似たような方法は、多分いくつかあるでしょう。私は最初の形式（セカンダリURLスペースを使う方法）を試してうまくいってますが、2つ目のバーチャルホストの方法は試していません。しかしながら、他の人が試してうまく行ってる旨のレポートをもらってます。
問題解決のためのこれらの方法のいずれについても、同じファイルシステム上のスペースに対応する異なるURL名前空間があるという事実を利用しています。複数のURL空間に異なる処理を対応づけることで、（URL空間から）ファイルシステムへの変換時に異なる挙動をさせることが可能になります。
最終的に、私はmod_davがAddModuleディレクティブにて指定されるモジュールに現れることを確約できることを信じている。そして、mod_dav がGET以外のメソッドのコンテントハンドラになる。もしPHPがそうなったら、結局すべてのメソッドを扱うことになるでしょう。しかしながら、この策略はオーサリングの問題を解決することはありません。