AuthType Basic
AuthName "Restricted Page"
Require group admin staff
AuthzLDAPMethod         ldap
AuthzLDAPServer         127.0.0.1:389
AuthzLDAPUserBase       ou=Users,dc=example,dc=com
AuthzLDAPUserScope      onelevel
AuthzLDAPUserKey        uid
AuthzLDAPGroupBase      ou=Groups,dc=example,dc=com
AuthzLDAPGroupScope     onelevel
AuthzLDAPGroupKey       cn
AuthzLDAPSetGroupAuth   map
AuthzLDAPMapUserToAttr  uid
AuthzLDAPMemberKey      memberUid

識別名 uid=ユーザー名,ou=Users,dc=example,dc=com とパスワードでシンプルバインドすることでユーザー認証の判定がされた後、 ou=Groups,dc=example,dc=com 以下のツリーから cn 属性 の値が admin または staff 、 かつ memberUid 属性 の値が uid=ユーザー名,ou=Users,dc=example,dc=com エントリの uid 属性の値 (ユーザー名) となっているものを含むエントリがある場合、認可される…ということになっていると思う。

http://sourceforge.net/projects/moddosdetector/

まだ使ってないしソースも読んでないので、 トレードオフ (特に速度低下) は不明。

<VirtualHost >
ServerName ml.osstech.jp
...
LayoutDefaultHandlers Off
LayoutMerge On
Alias /mailman/images/  /usr/share/images/mailman/
ScriptAlias /mailman/   /usr/lib/cgi-bin/mailman/
Alias /pipermail/       /var/lib/mailman/archives/public/
<Directory /usr/lib/cgi-bin/mailman>
Order Mutual-Failure
Allow From All
LayoutHandler cgi-script
LayoutHeader /mailman-header.html
</Directory>
<Directory /usr/share/images/mailman>
Order Mutual-Failure
Allow From All
</Directory>
<Directory /var/lib/mailman/archives/public>
Order Mutual-Failure
Allow From All
AddDefaultCharset EUC-JP
LayoutHandler text/html
LayoutHeader /mailman-header.html
</Directory>
...
</VirtualHost>

<VirtualHost *>
ServerName ml.osstech.jp
...
RewriteEngine On
RewriteCond %{REQUESTURI} !^/mailman/images/
RewriteRule ^(/mailman/[^/]+)(/.)$ $1 [passthrough,env=PATH_INFO:$2,last]
...
</VirtualHost>

今度はうまくいった。

Debian GNU/Linux 4.0 (etch) には Apache 1 用の libapache-mod-layout しか用意されていなかったので調べてみたところ、 Apache 2.2 向けには CVS から modlayout 4.0 の最新版をダウンロード しなければならないとのこと。 しかし…コンパイルできない。 こんな感じ:

apxs2 -c   modlayout.c utility.c layout.c
/usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static i486-linux-gnu-gcc -prefer-pic -DLINUX=2 -DGNUSOURCE -DLARGEFILE64SOURCE -DREENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/postgresql -I/usr/include/xmltok -pthread     -I/usr/include/apache2  -I/usr/include/apr-1.0   -I/usr/include/apr-1.0 -I/usr/include/postgresql  -c -o modlayout.lo modlayout.c && touch modlayout.slo
modlayout.c: In function 'layoutfilter':
modlayout.c:278: error: expected ';' before '{' token
modlayout.c: At top level:
modlayout.c:561: error: expected expression before 'layoutconf'
modlayout.c:561: error: initializer element is not constant
modlayout.c:561: error: (near initialization for 'layoutcmds[4].cmddata')
modlayout.c:562: error: expected expression before 'layoutconf'
modlayout.c:562: error: initializer element is not constant
modlayout.c:562: error: (near initialization for 'layoutcmds[5].cmddata')
modlayout.c:567: error: expected expression before 'layoutconf'
modlayout.c:567: error: initializer element is not constant
modlayout.c:567: error: (near initialization for 'layoutcmds[10].cmddata')
modlayout.c:568: error: expected expression before 'layoutconf'
modlayout.c:568: error: initializer element is not constant
modlayout.c:568: error: (near initialization for 'layoutcmds[11].cmddata')
modlayout.c:569: error: expected expression before 'layoutconf'
modlayout.c:569: error: initializer element is not constant
modlayout.c:569: error: (near initialization for 'layoutcmds[12].cmddata')
modlayout.c:574: error: expected expression before 'layoutconf'
modlayout.c:574: error: initializer element is not constant
modlayout.c:574: error: (near initialization for 'layoutcmds[17].cmddata')
modlayout.c:575: error: expected expression before 'layoutconf'
modlayout.c:575: error: initializer element is not constant
modlayout.c:575: error: (near initialization for 'layoutcmds[18].cmddata')
modlayout.c:576: error: expected expression before 'layoutconf'
modlayout.c:576: error: initializer element is not constant
modlayout.c:576: error: (near initialization for 'layoutcmds[19].cmddata')
modlayout.c:577: error: expected expression before 'layoutconf'
modlayout.c:577: error: initializer element is not constant
modlayout.c:577: error: (near initialization for 'layoutcmds[20].cmddata')
modlayout.c:578: error: expected expression before 'layoutconf'
modlayout.c:578: error: initializer element is not constant
modlayout.c:578: error: (near initialization for 'layoutcmds[21].cmddata')
apxs:Error: Command failed with rc=65536
.
make: *** [modlayout.so] エラー 1

これで無事にコンパイルできた。 しかし…安定動作しない。 ページが途切れたり、(null) と表示 (NULL ポインタ参照している?) されたりする。 Prefork MPM なら大丈夫なのかなぁ? ちなみに現在は Event MPM を利用している。

modlayout はもう保守されていないようなので、 素直に諦め、Apache 1.3 + modlayout 3.2 を試してみよう。 続く。

本命と見ていた Metux MPM は、ページを見ると最近は更新されていないみたい。 相変らず情報もほとんどない。 Metux MPM から派生したという Peruser MPM を見つけたが、 I required a non-threaded Apache, … ということで、スレッドではないらしい。 最近 Debian の公式パッケージに入った ITK MPM とどっちがいいんだろう? いずれの MPM も experimental 状態なのが気になるところ。 安定して動作したとしても、ユーザー (仮想ホスト) ごとにプロセスが必要だったり (Metux)、 スレッド対応でなかったりする (Peruser, ITK) ので、大規模な環境には向かなそう。

MPM は期待できなさそうなので、 他人のホームディレクトリへのアクセスは必要ないという前提にして、 ファイルとディレクトリの ACL 設定で実現するのが現実的だろうか。

まずは /etc/postfix/heloaccess を用意して、 postmap /etc/postfix/heloaccess しておく。 内容は以下の通り:

example.com REJECT

次に /etc/postfix/main.cf に以下のような設定を追加して、 postfix reload する:

smtpdhelorestrictions =
checkheloaccess hash:/etc/postfix/heloaccess

何で素直に exmaple.com だけを対象にしないのかね、まったく。 ちなみにこれと同じ変な仕様は、Apache の modaccess にもある。 いや待てよ、もしかしたら、これがいわゆる「普通」なのかも?! だとしたらちょっと狂ってる。 qmail-smtpd(8) の rcpthosts ファイルのように、 exmaple.com だったら exmaple.com だけにマッチし、 .example.com だったら example.com のサブドメインすべてにマッチするという仕様のほうが、 ずっと直感的でわかりやすく、なおかつ使い易いと思う。

気をとりなおして access(5) を斜め読みしてから、 /etc/postfix/heloaccess を以下のように変更してみた:

.example.com DUNNO
example.com REJECT

もう一度 access(5) をようく読んだところ、 parentdomainmatchessubdomains が元凶であることが判明。 そこで /etc/postfix/main.cf に以下を追加して無効にすることにした:

parentdomainmatchessubdomains =

/etc/postfix/heloaccess を最初のものに戻して試したところ、今度は成功した。

• MT には modperl1 対応のコードが含まれているが、 そのコードが modperl2 環境下でも実行されてしまう。 (modperl1 と 2 とで API の互換性がない)
• MT は、スクリプト実行時のカレントディレクトリがスクリプトが置かれているディレクトリであることを期待している。 (modperl2 は、カレントディレクトリを変更しない)

MT を改造して modperl2 対応を試みた例がいくつかあるようだが、 成功例はないみたい。 そこで、以下のような Apache2 + modperl2 設定を考えてみた。

PerlSwitches -I./extlib -I./lib
<VirtualHost *:80>
ServerName www.sfo.jp
...
<DirectoryMatch "^/project/sfo/www/www.sfo.jp/(lib/mt|var/mt/blog)">
Order Mutual-Failure
Allow From All
<Files *.cgi>
Options +ExecCGI
SetHandler perl-script
PerlFixupHandler "sub { \
chdir('/project/sfo/www/www.sfo.jp/lib/mt'); \
return OK; \
}"
PerlResponseHandler ModPerl::Registry
PerlOptions -ParseHeaders
PerlSetEnv MOD_PERL 0
</Files>
</DirectoryMatch>
...
</VirtualHost>

簡単に解説すると、以下のような hack になる:

• 環境変数 MOD_PERL を 0 に上書きし、 MT の mod_perl1 対応コードが実行されないようにする。
• MT の実行 (PerlResponseHandler) の前 (PerlFixupHandler) に、 カレントディレクトリを MT のディレクトリに移動する。
• PerlSwitches は必要ないと思うのだが、ないとモジュールのロードに失敗することがある。何故だ…。
• MT の改造は必要なし!

現在、当サイトの MT は上記のような設定で動作している。

mod_perl2 に対応しているモジュールは、 以下のように mod_perl 判定するのが一般的なようなので、 それらはちゃんと mod_perl2 の API を利用してくれるはず:

if (exists $ENV{MOD_PERL}) {
eval "require mod_perl";
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION >= 1.99) {
...mod_perl2 対応のコード...
} else {
...mod_perl1 対応のコード...
}
}

問題点が 1つ。chdir の結果はスレッドローカルではなくなるため、 Apache2 の MPM が worker の場合、 複数の MT にこの hack を適用すると問題が発生するものと思われる。 （未確認)

<VirtualHost :80>
ServerName www.sfo.jp
...
AliasMatch ^/mt/static/(mt.js|styles.css|images/.|docs/.*)$ /project/sfo/www/www.sfo.jp/lib/mt/$1
ScriptAlias /mt/ /project/sfo/www/www.sfo.jp/lib/mt/
Alias /blog/ /project/sfo/www/www.sfo.jp/var/mt/blog/
...
<DirectoryMatch "^/project/sfo/www/www.sfo.jp/(lib/mt|var/mt/blog)">
Order Mutual-Failure
Allow From All
</DirectoryMatch>
...
</VirtualHost>