正直一週間も悩んでいないのだけれど、ひたすらに長かった気がする。

まずは結論から。
Apacheにも、aprにも問題はなし。
AuthName を単独で.htaccessに出していたのがまずかった。

他のディレクティブは全アカウント共通なので、ルートとなるディレクトリの Directoryディレクティブに書いていたのだけれど、これではダメで、(9)Bad file descriptor: Could not open password file: (null) の悪夢がやってくる。

結果として、httpd.confと.htaccessは以下のようになった。
## .htaccess ##
AuthType Digest
AuthName “hoge”
AuthDigestProvider dbd
Require valid-user

## httpd.conf ##(いろいろ端折ってるけど)
# .htaccess Allow
AllowOverride AuthConfig

# allow
Order deny,allow
allow from all

# Auth DB query
AuthDBDUserRealmQuery
“SELECT md5( username || ‘:’ || $2 || ‘:’ || password )
FROM user_list WHERE username = %s AND realm = %s”

これで、無事に認証が通った。
結局やりたかった事というのは、
１、WebのGUIでアカウント登録
２、PostgreSQLのアカウント情報DBに書き込み
３、アカウント用にSubversionのリポジトリを作成
４、httpsの通信用にアカウント情報を含む.htaccessを作成
５、再起動なしに動的に追加したSubversionのリポジトリをmod_dav_svn経由で利用(この時DBのアカウント情報利用)。
という事だったりする。
まぁ、現状アカウント名＝Realm名になってるので今ひとつセキュアさには欠けるが。

Realm名でSubversionのリポジトリのアクセスを分けているので、Digest認証は必須だったんだよなぁ。

ともあれ、この結論に達するまでに支払った代償は大きい。
連休３日と、Web鯖の全データだもの……

ここまで書いて、リポジトリ名はアカウント名とは別にしたくなってきた。
でも、Web鯖復旧（という名のフルスクラッチ作り直し）のが先なのでしばらく放置。
なので、公開もしばらく後。

ところで、気の向くままに作ったのはいいのだけれど、これ、需要あるんかな……

端的に、起こった事実だけを述べよう。

konata.net上のWebサーバに格納していた全でデータを吹っ飛ばした。
rm -Rf htdocs を躊躇無く実行した自分に乾杯。

いや、急いでたんだよ。
Digest認証の失敗の関連で、ようやくportsのaprを使ったhttpdのパッケージが作れたからすぐ入れたかったんだよ。
まぁ、結論から言うとそっちも失敗して進展なしなんだが。

というわけで、ラノベ評価サイトも、ロト６の当選番号通知も、FreeBSDの鯖構築マニュアルもWikiも全部抹消されてしまった。
あ、あとらいつべバルーンも。

復旧方法を模索して、数時間、UFSの復旧ソフトはほとんどないっぽい。
R-Studioの最新版を試すもののディレクトリごと吹っ飛ばしたファイルは認識されず完全に手詰まり。
唯一の希望は、仕事場に今作りかけのSubversionレンタルのソースが残っていることと、
消したのはファイルだけなので、MySQLやPostgreSQLのバックエンドのDBデータは丸々残っていることか。

今日は仕事がないっぽいので、朝一で会社からまずはBlogの復旧。
１、新しく暫定のDBを作って、Nucleusのインストールをする。
２、Config.phpを書き換えて復旧したいDBを参照するように変更。
３、暫定のDBを削除。

とりあえず、これでBlogデータにはアクセスできるようになったけど、当然のことながらスキンとテンプレートは空っぽなので、見栄えの復旧には至らない。
大体２ヶ月分くらいの作業がパーになったので正直かなりダメージが……(´；ω；`)

復旧にどれだけ時間がかかるか想像もつかん……

いろいろやってみるものの、今ひとつうまくいかないのでメモ的意味で、エントリを残す。

やってみたこと
・Basic認証でfile認証 → OK
・Basci認証でmod_dbd → OK
・Digest認証でfile認証 → OK
・Digest認証でmod_dbd → NG
・AuthBasicAuthoritative Off →NG
・AuthUserFile /dev/null → NG
・aprをApacheのソースからではなく、Subversion関連のPorts側を使用するように変更。→ パッケージ名にpgsqlついてるくせに、apr_dbd_pgsql.so が作成されない。デフォルトの/usr/localにインストールしてないためだと思われる。NG
・httpd.confの記述チェック → うまくいっている環境とめぼしい差分は特になし
・LoadModuleでロードする順番を変える → モジュール化して順番を変えてみてもNG
・DBD接続は起動時にプリペア化したクエリを読み込んでいるのでDBの設定ミスはなし
・Apacheのソースにprintfデバッグを埋め込んでチェック → AuthDigestProvider dbdの登録は走っている
・configureのオプションで –disable-authn-file を指定 → No Authn provider configured でNG

いい加減疲れてきたよ……(‘A`)
ていうか、登録走ってるのに No Authn provider configured は酷くないか？
お前、今さっき登録したじゃねーか……
printfを追加してさらに試す。
・No Authn provider configured でNG時の、AuthDigestのコンフィグデータのアドレスが登録時と変わってる……そりゃ呼べねーわorz

mod_dbdを使ったApacheの認証をPostgreSQLのDBにやらせようと画策している。
今作っているWebページは、登録制でメンバー以外のアクセスを弾く必要があるのだけれど、いちいちBasic認証と.htacsessで弾くのは面倒だし、それに今ひとつ美しくない。
ユーザ情報はDBに持たせるべきなのだ。

閑話休題。
で、Digest認証を挿せようとして以下のコンフィグを書いた。
AuthName だけはRealmを動的に生成させる必要があったので、.htaccessに逃がしている。

DBDriver pgsql
DBDParams “host=xxx.xxx.xxx.xxx dbname=xxxxx user=xxxxxxxx password=xxxxxxx”

DBDMin 2
DBDKeep 8
DBDMax 20
DBDExptime 300

# Authorization
AuthType Digest
AuthDigestProvider dbd
Require valid-user

が、
(9)Bad file descriptor: Could not open password file: (null)
というエラーメッセージが出てきて500エラーになって認証が失敗する。
ちなみに、適当に作った AuthUserFile を指定してファイルで認証させるとうまくいく。
が、AuthDigestProvider dbd を完全に無視している様子。
DB見に行って欲しいんだが……

AuthUserFile /dev/null を指定すればいいらしい話もあったのだけれど、
どっちにせよDBを見に行かないので意味がない。

Webで情報を探し、いくつか似たような事象は発見するも、今回の例に一致したものはない様子。
というか、同じhttpd.confで別マシンで試したときは素直に通ったんだよな……
その後の今回のキモのところで詰まったけど……

Apacheを作り直してみたり、aprを作り直してみたり、DBのログとったりで今日一日をほとんどつぶしてしまった。

仕方がないので、今新しく別マシンを立てて環境構築中。
こっちで通ったらモジュールごとコピーしてもってこよう。

昨日のエントリの関連なのだけれど、PF設定をあれこれしたのはこれがやりたかったからなのである。

ぶっちゃけると、今作ってるWebサイトでSSLを使いたい。
年間数万の維持費をかけるわけにはいかんので、証明書はオレオレ証明書を使うことになるが。

が、konata.netはSSLの443番ポートはすでに使用済み。
SSLで通信をしていることには変わりないが、その中身は外からSSHな自宅鯖接続用の通信なわけで。
なので、１つのポートでWebとSSHの２つのサービスを動かさなければならん。
ポート番号を分ければいいのだけれど、URLの後ろにくっつけるのはなんとなくかっこ悪いので却下。
ちょっと考えて、Dalegateを使って通信を振り分けることにした。
しかし、これが上手くいかない。
最初はportsからのインストールでエラー吐くし……
無理やりmakeしたものの、今度は設定の豊富さ故に迷う迷う。
合計４～５時間ほど迷った結果、少なくとも今の自分には無理という結論に達した。

なんか他の手段はないものかと、適当な単語を入れてGoogle様にお伺いを立てることにした。
その結果が昨日のエントリになる。
PFで要求をそのまま別ポートにリダイレクトしてやればいいのだ。

書いたpf.confはこんな感じ。
rdrで要求を転送して、後の行で入力と出力を許可してやる。
# SSL Select
rdr on $ext_if inet proto tcp from <rdr_addr> to <ext_addr> port https -> <ext_addr> port 10022
pass in quick inet proto tcp from any to <ext_addr> port 10022 keep state
pass out quick inet proto tcp from any to any port https keep state

んで、10022ポートで受けた先でSSLを取っ払って、SSH本来の22番ポートに到達。
晴れて外部からのSSH接続に成功という流れである。

ちなみに、<rdr_addr>テーブル以外からのアクセスはApacheがそのまま受け取ってSSLで通信する。

結果として、新しいアプリを入れることなく、かつ、処理が高速なPFで片付いたので最適解に落ち着いた気がする。