結論からいうと、下記許可ルールを追加すると解決する。

ローカル側：UDP 67-68ポート
リモート側：UDP 67-68ポート 信頼ゾーン

非常に気持ち悪いのだが、ひとまず解決策。

追記：
VMWareのIP幅を信頼ゾーンに加えてないと、失敗するかもしれない。未検証。

追追記：
サポートに推奨設定を問い合わせていたが、その返答がきた。曰く、

プロトコル：UDP
方向：内向き
アクション：許可
ローカルポート：68
リモートポート：67

を追加するようにとのこと。これで変なところで引っかからずきちんとファイアウォールを使うことができる。ありがたい。

Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
[Fri Sep 26 03:51:51 2008] [notice] child pid 335 exit signal Trace/BPT trap (5)
[Fri Sep 26 03:51:54 2008] [notice] child pid 136 exit signal Trace/BPT trap (5)

あちこち調べた結果、どうもMacPortsの問題としてちょうど俎板の上に乗っている問題で、gdのimagettftext()関数がApacheを巻き込んで死んでしまうということらしい。解決方法はfreetypeのPortfileを持ってきて、コンパイルオプションを変えて手で突っ込めということらしい。

この時点でかなり嫌気が差すが、あきらめてまずfreetypeのPortfileを開く。Portfileはえらく深い階層(/opt/local/var/macports/sources/ rsync.macports.org/release/ports/print/freetype/Portfile)にあったので見つけるのに苦労したが、これの50行目–with-old-mac-fontsをコメントアウトする。

# --with-old-mac-fonts

そしてfreetypeを強制再インストール。

$ sudo port -nf upgrade freetype

次にphp5をもう一度ビルドし直す。

$ sudo port -nf upgrade php5

これでひとまず問題は解決した。portの中身をsyncするたびに元に戻ってしまうので根治療法にはならないが、Macports側の対応がなされるまでの間の手当としては妥当なところだろう。手数も最小限だ。

参考になれば幸い。

dekiwiki8.05.2がリリースされた。フィクスされたバグはChangelogを見てもらうとして、割と困っていたのが「#4292    Templates cannot be added to unsaved pages」。テンプレートを使えば、事務仕事のかなりの部分をwikiへ移管できると目論んだのに、このバグのせいでテンポが悪いことこの上なかったのだ。それと、SWFUploaderもうまく動いていなかったのだが、Changelogにあがっているので直っていればうれしい。

8.05.1から8.05.2への置き換えは簡単。dekiwikiのサービスを停止し、ドキュメントルート以下全てのファイルをバックアップ。ドキュメントルートに8.05.2のweb/*をコピーして、バックアップからLocalSettings.phpとattachments/をドキュメントルートへ移す。全てのファイルのグループとオーナーをapache:apacheへ変更すれば完了。思った以上に簡単に終わって安心した。

アップデートの結果、テンプレートは思った通りにきちんと動くようになった。残念なことに、SWFUploaderがIOエラーで動かない問題は解決せず。もしかするとこれはこちらの手元環境に問題があるのかもしれない。追って調べる必要がある。

追記：ごく一部のボタン類に文字化けがある。UTF8をEUC-JPにしようとして失敗してるんじゃないかなぁと思うような化け方。文字化け判定表はこんなのがある。

• http://nonn-et-twk.net/twk/nondrupal/mojibakeMatrix.html
• http://blog.livedoor.jp/dankogai/archives/50809008.html

たまに便利だ。

追記：バグレポートが上がっていた。こちら。

方法は、調べてみるとopengarden.orgのHow do I…Provide HTTPS access to Deki Wiki?で説明されていて、今使っている最新のバージョンでは問題なく出来そうな雰囲気で記述してあるため、この内容を見つつ、これまでVirtualHost *:80と書いてあった部分をVirtualHost *:443へ変更を行った。

余談だが、実は社内のサーバは*.example.comというドメインに対しての証明書として作ってあるため、同じドメイン内の違うサブドメインはNameVirtualHostで振り分けることが出来る。ただし社内用なのでオレオレ証明書にならないために鍵は管理者が厳密に管理の上、USBメモリで物理的に渡している。

ついでに全アクセスをhttps化したいので、VirtualHost *:80の設定はmod_rewriteを用いてrewriteルールを記述し、httpアクセスは全てhttpsへ転送するようにした。

が、ここで問題１つめが発生した。dekiwikiは日本語も直接URLに含め、内部ではPATHINFOを用いて文字列処理を行っているようなのだが、コンテンツ名に ? が含まれると文字が途中で分断されてしまう。どうも内部的な処理とApacheの文字処理がおかしいのだと思うが、これをうまく解決する方法を見つけることが出来なかった。「PATHINFO Apache 文字化け」、のようなキーワードで検索すると、Windows環境ではまっている人を何人か見つけることが出来るが、おそらく同種の問題なのだと思う。mod_encodingを使えば解決できるかもしれないと考えたものの、パッケージがメンテナンスされていない雰囲気だった上yumで導入できないこともあり、httpアクセスは全てhttpsでのドキュメントルートへ転送し、もう一度ページを移動してもらうこととした。結果、http向けのVirtualHost設定は下記のようになった。AllowEncodeSlashesを書いておかないとひどいめにあうので注意(ひどいめにあった)。

<VirtualHost *:80>
        ServerName wiki.sensignal.org
        RewriteEngine On
        RewriteCond %{SERVER_PORT} !^443$
        RewriteRule ^/.*$ https://%{HTTP_HOST}/ [L,R,NE]
        AllowEncodedSlashes On
</VirtualHost>

だが、その決定をしておおむねうまく動きそうな中、また次のはまりポイントが出てきた。サイトナビゲーション部分のURLがhttpsにならないのだ。

サイトナビゲーションとは、右画像のような、dekiwiki左端に出ているドキュメントツリーをうまく表示してくれる仕組みなのだが、ここのソースを見ると相対パスではなく絶対パスで表示している。そのせいでリンク先がhttpになってしまい、トップへ転送され続けるという困ったことになってしまっている。

調べること小半日、かなりソースコードを追いかけた(phpからc#の部分からDBの中身までorz)結果、問題はかなり上の方に書いたこの文章「これまでVirtualHost *:80と書いてあった部分をVirtualHost *:443へ変更を行った」というところにあった（がーん）。実はここで書かねばならぬ、SSLEngine On、という１行を書き忘れていたがために、Apacheが80番と同じ挙動をしていたというもの。証明書がブラウザへ送られてきていたので、まんまと引っかかってしまったが、Apacheは443番へのアクセスの場合、証明書を送ってきてくれるものの、HTTP_PORTは80のまま、SSLは稼働せずという非常に中途半端な扱いにしてしまうらしい。そのため、見かけ上はhttps通信が出来ているように見えるものの、URLは全然書き換わらないという悪夢におそわれることになった。

解決したからいいようなものの、思い切り脱力してしまった。

導入

まず、導入先環境と導入したDekiwikiのバージョンだが、Fedora8にDekiwiki8.05.1(Jay Cooke)のソース版。こちらからダウンロードできる。

導入自体はチュートリアルやあちこちのサイトに書いてある通りで殆ど苦労せず。mono関係もFedora8であればmono1.2.xが入るので問題ない。ただ、どのコンポーネントが要るのか不明だったことと、他の問題(後述)の原因がmonoにあると思いこんでいたので、yum install mono-*.x86_64という結構乱暴なことをしているところが反省したいところだ。もっと手軽にやりたい場合、dekiwiki用のyum repositoryがあるのでそれを定義した設定ファイルを/etc/yum.repos.d/以下においてyumで入れる、という手があるとのこと。うちの場合は更新時面倒なことになるのがイヤなのと、VirtualHostをいくつも定義している都合でこの方法は使わなかった。

startup.xmlを直す

はまりどころは１カ所、/etc/dekiwiki/mindtouch.deki.startup.xmlに記述する内容で、XML Pathでいうところのscript/action/config/pathの規定値。これが正しい内容になっていなかったせいでAPIが正しくコールされず、下記のエラーが出てしまっていた。

Site settings could not be loaded
We were unable to locate the API to request site settings. Please see below for debugging information.
HTTP Response Status Code: 404

pathの値は、APIコールされる先(規定ではttp://localhost:8081/deki/@about)の下線部をいれておくのが正しい。うちでは規定通りにしたかったので、deki、と書き直して旨く動かすことが出来た。

いくつか問題が・・

これでひとまず動いたdekiwikiだが、階層構造が閉じている状態のとき、クリックしても何ら反応してくれないという問題に出くわした。早速ゴキブリ^H^H^H^HFirebugsを出してつついてみると、一つ上位のDOMがonClickイベント時にreturn falseしていることが原因の模様。ちょっとphp側のソースをさらってみたものの、それっぽいコードは見あたらない。c#ソースのほうに原因があるとすれば結構根っこが深い問題なのでどうしたものだろう。

(追記：フォルダをいくつか作っているうちに解決した。キャッシュか何かが影響していた可能性もあるので、同じ現象が起きたら再度追跡してみたい。)

さらに、添付したファイルが開けないという問題もあった。ブラウザではInternal Server Errorの表示だが、httpdのerror logに下記のようなエラーが出る。

[Sat Jun 21 04:47:25 2008] [warn] proxy: No protocol handler was valid for the URL /@api/deki/files/1/hogefuga.dat. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

これはdekiwikiの問題ではなく、apacheの設定が不足していた。調べてみると、mod_proxyだけでなく、mod_proxy_httpもLoadModuleしておく必要があったようだ。httpd.confを修正して再起動することでこの問題は解決した。

wikiとしての評価

インストールに手間がかかるといってもわかればさほど難しいものでもないし、社用で使うには他のwikiの追随を許さないくらい使いやすい。ユーザをグループとして管理する機能は社用では必須といっても過言ではないだろうし、独自wiki記法の類も覚える必要は一切ない。知識のあまりない人でも低い学習コストで使い始めてもらうことが出来ることは大変ありがたい。

レスポンスがちょっと悪い(CPU負荷を食ってるのかAPI通信で遅いのかは不明)のが難点ではあるが、これも昨今のCPU速度をもってすれば殆ど気にならない程度で済む(うちではPentiumD(DualCore)/3GHzのネイティブ環境に導入)。それに加え、ページの階層を強く意識させる構造があることも、wikiを普通の人に勧めるときに困る「とっかかりがつかみづらい」問題の回避に役立つと思う。

時間切れでさわれなかったネタ：Desktop Connector、Outlook Connector、Modules。いずれもSourceForgeのダウンロードページにあるので、時間のある方は試してみていただきたく。

また何かあったらネタとしたい。:-)