Apache 2.0.53 で WebDAV を使えるようにする
SERVER
WebDAV
WebDAV とは、簡単に言うと Web サーバのデータを読み書きする仕組み、とでも言うのでしょうか…。これを使うことで HTTP プロトコルをつかってサイトの更新などができるようになります。
以前にも EZ-NET: Apache 2.0.48 で WebDAV を使えるようにする にて RedHat および Slackware へ WebDAV 環境を構築したことがあったのですけど、このたび Slackware 9.0 にて WebDAV 環境を用意しようと思ったら、なにやら手間取ってしまったのでした。
原因はきっとソフトウェアのバージョンが変わったせいなのでしょう。
ともあれ前回のお話は実験的な色が強かったのもありますし、それを整理する意味も兼ねて、改めてインストールのお話を書いてみることにしました。
Apache のインストール
まずは Welcome! - The Apache HTTP Server Project さまから、最新版の Apache を入手します。
現在は Apache 2.0.53 が公開されているようでしたので、そのソースファイル httpd-2.0.53.tar.gz を入手して次のように展開し、出来上がったディレクトリに移動します。
tar xvzf httpd-2.0.53.tar.gz
cd httpd-2.0.53/
つづいて、コンパイルとインストールです。その際に configure にいくつかオプションを指定します。
--enable-shared 動的にモジュールを組み込みたいので、このオプションで DSO 対応にします。 --enable-dav WebDAV を有効にします。 --enable-headers FrontPage 2003 の発行先に使いたいときには必要みたいです。 これらのオプションを付けて、コンパイルとインストールを行いました。
以下ではついでに SSL 関連のオプションもつけてみました。なお、以前に試してみたときのお話ですけど FrontPage 2003 で SSL 対応の WebDAV サイトへは上手く発行できなかった経験がありますので、そうしようかと思っている人は注意しましょう。
./configure --enable-shared --enable-dav --enable-headers --enable-ssl --with-ssl=/usr/include/openssl
make
make install
特にエラーもなく、これでインストールは完了でした。
WebDAV を有効にするための準備
Apache の起動アカウントを用意する
WebDAV はファイルアクセスが関係する都合もあるので、まずは Apache を起動するアカウントをしっかりと登録しておくことにします。今回は次のようにして apache_u アカウントと apache_g グループを作成してみました。ここでは apache_u の UID として 80 番を割り当てておくことにします。
groupadd apache_g
useradd -g apache_g -u 80 -d /dev/null -s /bin/true apache_u
そうしたら /usr/local/apache2/conf/httpd.conf を編集して、このアカウントで Apache が起動するように調整しておきます。
User apache_u
Group apache_g
WebDAV 用のロックファイルを用意する
つづいて WebDAV が使用するロックファイルを用意します。
今回は /var/httpd/dav.lock というファイルを用意しました。このファイルは Apache が読み書きできる必要があるので、Apache を起動するプロセス、今回は Apache が書き込めるようにします。
mkdir /var/httpd
touch /var/httpd/dav.lock
chwon apache_u.apache_g /var/httpd/
chown apache_u.apache_g /var/httpd/dav.lock
ロックファイルの作成が完了したら、/usr/local/apache2/conf/httpd.conf 内のどこかに次の行を追記して先ほどのロックファイルを使用するようにします。
DAVLockDB /var/httpd/dav.lock
認証を実装する
Apache 標準の認証をつかうのが一番早いのですけど、パスワードを /etc/passwd で統一したかったので別のモジュールを組み込んでみます。ただ /etc/passwd を認証に使うのは、セキュリティの面で危険とのことなので、使用する際はよく考えてから実装しましょう。
ここが今回の手間がかかってしまった部分です。
Mod Auth External をインストールする
Mod_Auth_External さまより Apache 2 用のソースファイル mod_auth_external-2.2.9.tar.gz をダウンロードして展開します。
tar xvzf mod_auth_external-2.2.9.tar.gz
cd mod_auth_external-2.2.9
展開が終わったら、続いてコンパイルとインストールです。
/usr/local/apache2/bin/apxs -c mod_auth_external.c
/usr/local/apache2/bin/apxs -i -a mod_auth_external.la
これでインストール完了です。httpd.conf に自動的に次の行が追加されています。
LoadModule external_auth_module modules/mod_auth_external.so
pwauth のインストール
続けて pwauth のインストールを行います。
以前にインストールしてみたときには Mod Auth External の一部として組み込まれていたのですけど、現在は別々の提供のようですので、まずはそれを入手します。これは PWAUTH にて公開されていましたので、ここから pwauth-2.2.8.tar.gz をダウンロードしました。
tar xvzf pwauth-2.2.8.tar.gz
cd pwauth-2.2.8
展開したら、まずはその中に含まれていた config.h の SERVER_UIDS の値を書き換える必要があります。
#define SERVER_UIDS 80 /* user "apache_u" */
今回は Apache の起動アカウントとして apache_u を作成してありますので、その UID である 80 を SERVER_UIDS に指定します。
編集が終わったらコンパイルとインストールを次のように行います。ここではあらかじめ /usr/local/libexec/ というディレクトリを作成して、そこへインストールしています。
mkdir /usr/local/libexec/
make
cp pwauth/pwauth /usr/local/libexec/
chmod u+s /usr/local/libexec/pwauth
これが終わったら /usr/local/apache/conf/httpd.conf に次の行を加えます。これはどうやら、仮想ホストを利用している場合は <VirtualHost> ディレクティブの内部に記述する必要がある ようです。
AddExternalAuth pwauth /usr/local/libexec/pwauth
SetExternalAuthMethod pwauth pipe
そして、以下の内容の /etc/pam.d/pwauth ファイルを用意します。
auth required /lib/security/pam_unix_passwd.so shadow nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_unix_passwd.so
/etc/pam.d/ ディレクトリが存在しない場合には、mkdir コマンドでさくっと作ってしまいましょう。
ここで指定されている pam_umix_passwd.so といったファイルは Linux-PAM がインストールされていないと存在しません。Slackware 9.0 では PAM が組み込まれていないようでしたので、続けてそのインストール作業を行います。それと調べたときは pam_pwdb.so と見たのですけど、どうやら pam_unix_passwd.so が正しいようでしたので、上記ではそうしておきました。
PAM のインストール
pwauth を使用するにあたって、Slackware 9.0 では PAM という認証ライブラリをインストールする必要があります。
これは A Linux-PAM page にて提供されていますので、ここから、2005/03/20 現在での最新版の Linux-PAM-0.78.tar.gz をダウンロードして展開します。そして configure を実行してみたところ、エラーが表示されてしまったのでした。
tar xvzf Linux-PAM-0.78.tar.gz
cd Linux-PAM-0.78
./configure
エラー内容は次の通りでした。
checking path to cracklib dictionary... configure: error: none found
どうやら cracklib というライブラリが見つからなかったようです。
調べてみると、cracklib というパスワードチェックライブラリと、cracklib-dicts という標準 CrackLib ディクショナリというものが世の中には存在するようです。そうすると、ここのエラーで言うならば cracklib-dicts が足りなそうな感じですね。
そんな感じで探してみると、とりあえず Linux-PAM が公開されていたのと同じディレクトリ http://www.kernel.org/pub/linux/libs/pam/pre/library/ にて "cracklib-files.tgz" というファイルが見つかりました。
これを入手して展開してみると、次のファイルが展開されました。
- usr/
- usr/doc/
- usr/doc/cracklib-2.5-1/
- usr/doc/cracklib-2.5-1/HISTORY
- usr/doc/cracklib-2.5-1/LICENCE
- usr/doc/cracklib-2.5-1/MANIFEST
- usr/doc/cracklib-2.5-1/POSTER
- usr/doc/cracklib-2.5-1/README
- usr/include/
- usr/include/crack.h
- usr/lib/
- usr/lib/libcrack.a
- usr/lib/cracklib_dict.hwm
- usr/lib/cracklib_dict.pwd
- usr/lib/cracklib_dict.pwi
- usr/sbin/
- usr/sbin/create-cracklib-dict
- usr/sbin/mkdict
- usr/sbin/packer
どうやらルートディレクトリで展開してあげれば、適切な場所へファイルが用意される仕組みのようですね。念のため既にこれらのファイルが存在していないか調べてみましたけど、Slackware 9.0 にはなさそうでしたので、次のようにしてインストールしてしまいました。
tar xvzf cracklib-files.tgz -C /
これでルートディレクトリへ各種ファイルが展開されましたので、再び Linux-PAM のインストールへと戻ります。
cd Linux-PAM-0.78
./configure
make
make install
今度は特にエラーが出ることもなく configure が終了しましたので、続けてコンパイルしてインストールとなりました。
認証を行いたいサイトには…
あとは目的のサイトに次のように認証関連の設定を行えば、認証が実装されます。
AuthType Basic
AuthExternal pwauth
AuthName "test authentication"
require user test
上記の例では test という名前のユーザに限定されています。すべてのユーザが対象となる valid-user にしてもいいかもしれないですけど、念のため最小限のアカウントにのみ許可をしたほうが良さそうな気がします。
なお、これらの記載は <Location> や <Directory> ディレクティブ以外にも、 .htaccess ファイルでもいいようです。
参考として、WebDAV で更新もしたいし、そのままサイトを公開したい場合は、次のような感じの設定になると思います。
<VirtualHost *:80>
ServerName tmp.ez-net.jp
DocumentRoot /tmp/www
AddExternalAuth pwauth /usr/local/libexec/pwauth
SetExternalAuthMethod pwauth pipe
<Location />
DAV On
<LimitExept GET POST HEAD OPTIONS>
AuthType Basic
AuthExternal pwauth
AuthName "test authentication"
require user test
</LimitExcept>
</Location>
上のようにすることで、通常の GET や POST といったメソッドは問題なくアクセスでき、WebDAV で使用するようなその他のメソッドの場合に初めてパスワードが聞かれるため、両立することが出来るようになると思います。
アカウント作成時の注意
Apache 2.0.53 + WebDAV にてアップロードを行う場合、Apache を起動しているプロセスアカウントにて書き込みを行おうとするので注意する必要があります。
そのような理由から WebDAV でアクセスするフォルダには Apache 自身が読み書きできるように権限を設定する必要があるのですけど、今回のように "mod_auth_external" を使用して /etc/passwd にあるアカウントで認証を行うようにすると、まるでその認証に使用したアカウントでアップロードするものと勘違いしてしまったりする可能性もあります。
言い方を変えると、どのアカウントで認証を行っても、実際にアップロードされたファイルの所有者は Apache のアカウントとなります。
たとえば Apache が書き込めるようにと該当するディレクトリ等に Apache のグループ権限 (ここでは apache_g) へ書き込み権限をつけただけならば正しいのですけど、勘違いしてさらにユーザにも同じグループを設定してしまうと、自分の以外の WebDAV でアップロード可能なフォルダすべても操作できるようになってしまいます。
そのような感じなので、アップロードしたいフォルダには Apache 起動アカウントのグループを割り当てて書き込み可能としておくと共に、各ユーザには一般ユーザグループなどの Apache 起動アカウントには使用していないグループを設定しておくのが良さそうです。
日本語環境に対応させる
WebDAV を日本語環境に対応させるモジュールがありますので、それを組み込んでみます。
WebDAV Resources JP さまから、mod_encoding-20021209.tar.gz と mod_encoding.c.apache2.20020611a-2 をダウンロードします。そして次のような手順で、展開とインストールをおこないます。
tar xvzf mod_encoding-20021209.tar.gz
cd mod_encoding-20021209/lib/
./configure
make
make install
cd ..
./configure --with-apxs=/usr/local/apache2/bin/apxs
cp ../mod_encoding.c.apache2.20020611a-2 mod_encoding.c
/usr/local/apache2/bin/apxs -c mod_encoding.c
gcc -shared -o mod_encoding.la mod_encoding.o -Wc -Wall -L/usr/local/lib -Llib -liconv_hook
cp mod_encoding.la /usr/local/apache2/modules/
そして httpd.conf に次の行を追加します。
LoadFile /usr/local/lib/libconv_hook.so
LoadModule encoding_module modules/mod_encoding.la
LoadFile の行は、libiconv_hook.so.1 というファイルが 見つからないとのエラーが発生してしまうようなので明示的に記しています。この行は LoadModule にて mod_encoding.la を呼び出すよりも前に書く必要があるみたいです。
そして httpd.conf のグローバルセクションに次の設定を追加します。
<IfModule mod_encoding.c>
EncodingEngine on
NormalizeUsername on
SetServerEncoding UTF-8
DefaultClientEncoding JA-AUTO-SJIS-MS SJIS
AddClientEncoding "cadaver/" EUC-JP
</IfModule>
これで Apache を再起動すれば、モジュールがロードされるようになりました。
FrontPage 2003 の発行先に出来るようにする
FrontPage 2003 を使って WebDAV にてアップロードをする場合は少し調整を行う必要があります。
httpd.conf のグローバルセクションあたりにでも次の行を追加して、DAV であることを通知するヘッダを送ってあげればいいそうです。なお、Header add を使用する場合には Apache のコンパイル時に --enable-headers をつけておく必要があるようなので注意しましょう。
Header add MS-Author-Via "DAV"
また、FrontPage 2003 はフォルダを散策する際に、まずは末尾に "/" をつけないもので検索を行うようです。そしてそのときに Apache は、301 という通知を返して、改めて今度は末尾に "/" をつけたものを要求する仕組みになっているようなのですけど、FrontPage 2003 は 301 をもらった時点で諦めてしまうようなのでした。
なのでさらに、FrontPage によるアップロードであった場合には、そうならないように配慮する必要があります。
これは BrowserMatch を用いて、特定のクライアントに対して redirect-carefully を指定することで対応できるようです。FrontPage でのアクセスの場合は、次の行を httpd.conf へ追記して Apache を再起動すれば上手く行くようになりました。
BrowserMatch "MS FrontPage" redirect-carefully