2008またもやdekiwikiネタ。Woods)が出たので導入。Woods)のアップデートとなる。apache:apacheとして所有者をapache稼働ユーザに。事前バックアップはDB、コンテンツディレクトリともに確実に行うことは言うまでもない。特記事項としては、新コントロールパネルが登場したので、Apacheのリライトルールを書き換える必要がある。いっても数文字足すだけで下記の通り。!^/(@api|editor|skins|config|@gui|deki-cp)/これでApacheも再起動しておけば良い。セキュリティ上の懸念からすべてSSL必須としているうちの運用では、SSL動作が全体的に快適になったことが何よりも大きい。2008ここのところdekiwikiネタばかり。dekiwiki8.05.2がリリースされた。テンプレートを使えば、事務仕事のかなりの部分を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.htmlhttp://blog.livedoor.jp/dankogai/archives/50809008.htmlたまに便利だ。追記:バグレポートが上がっていた。2008外部のネットワークからdekiwikiへアクセスすることも増えてきたのだが、そうなると気になるのが途中経路におけるスニフィングだ。それに対しての最も簡単なソリューションはhttpsアクセスを行うことなので、その設定を行ってみることにした。*:443へ変更を行った。余談だが、実は社内のサーバは*.example.comというドメインに対しての証明書として作ってあるため、同じドメイン内の違うサブドメインはNameVirtualHostで振り分けることが出来る。社内用なのでオレオレ証明書にならないために鍵は管理者が厳密に管理の上、USBメモリで物理的に渡している。*:80の設定はmod_rewriteを用いてrewriteルールを記述し、httpアクセスは全てhttpsへ転送するようにした。ここで問題1つめが発生した。含まれると文字が途中で分断されてしまう。内部的な処理とApacheの文字処理がおかしいのだと思うが、これをうまく解決する方法を見つけることが出来なかった。文字化け」、のようなキーワードで検索すると、Windows環境ではまっている人を何人か見つけることが出来るが、おそらく同種の問題なのだと思う。mod_encodingを使えば解決できるかもしれないと考えたものの、パッケージがメンテナンスされていない雰囲気だった上yumで導入できないこともあり、httpアクセスは全てhttpsでのドキュメントルートへ転送し、もう一度ページを移動してもらうこととした。結果、http向けのVirtualHost設定は下記のようになった。AllowEncodeSlashesを書いておかないとひどいめにあうので注意(ひどいめにあった)。On</VirtualHost>だが、その決定をしておおむねうまく動きそうな中、また次のはまりポイントが出てきた。サイトナビゲーション部分のURLがhttpsにならないのだ。サイトナビゲーションとは、右画像のような、dekiwiki左端に出ているドキュメントツリーをうまく表示してくれる仕組みなのだが、ここのソースを見ると相対パスではなく絶対パスで表示している。そのせいでリンク先がhttpになってしまい、トップへ転送され続けるという困ったことになってしまっている。*:443へ変更を行った」というところにあった(がーん)。On、という1行を書き忘れていたがために、Apacheが80番と同じ挙動をしていたというもの。証明書がブラウザへ送られてきていたので、まんまと引っかかってしまったが、Apacheは443番へのアクセスの場合、証明書を送ってきてくれるものの、HTTP_PORTは80のまま、SSLは稼働せずという非常に中途半端な扱いにしてしまうらしい。そのため、見かけ上はhttps通信が出来ているように見えるものの、URLは全然書き換わらないという悪夢におそわれることになった。解決したからいいようなものの、思い切り脱力してしまった。