Archive for the 'dekiwiki' Category

Dekiwiki8.08導入

Posted by ゆのじ on 9月 9th, 2008

またもやdekiwikiネタ。8.08(Kilen Woods)が出たので導入。つまり8.05.2(Jay Cooke) -> 8.08(Kilen Woods)のアップデートとなる。

例によって、こんな手順でおk(うちの運用の場合)

  1. dekiサービス停止
  2. ドキュメントルートにおいてある現在のコンテンツ一式を別の場所に動かす(mv htdocs htdocs.oldとかで)
  3. ダウンロードしたdekiwikiのweb/をドキュメントルートに配置
  4. 元のドキュメントルートにあったLocalSettings.phpを新ドキュメントルートへ配置
  5. 元のドキュメントルートにあったattachments/を新ドキュメントルートへ移動
  6. ドキュメントルートで、chown -R apache:apacheとして所有者をapache稼働ユーザに。
  7. maintenance/update-db.phpを一度呼ぶ
  8. dekiサービス起動

事前バックアップはDB、コンテンツディレクトリともに確実に行うことは言うまでもない。

特記事項としては、新コントロールパネルが登場したので、Apacheのリライトルールを書き換える必要がある。といっても数文字足すだけで下記の通り。

旧:
RewriteCond %{REQUEST_URI} !^/(@api|editor|skins|config|@gui)/
新:
RewriteCond %{REQUEST_URI} !^/(@api|editor|skins|config|@gui|deki-cp)/

これでApacheも再起動しておけば良い。

セキュリティ上の懸念からすべてSSL必須としているうちの運用では、SSL動作が全体的に快適になったことが何よりも大きい。

dekiwiki8.05.2リリース

Posted by ゆのじ on 7月 4th, 2008

ここのところdekiwikiネタばかり。

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にしようとして失敗してるんじゃないかなぁと思うような化け方。文字化け判定表はこんなのがある。

たまに便利だ。

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

https設定のdekiwikiでsite navigationがhttpになる件

Posted by ゆのじ on 7月 2nd, 2008

外部のネットワークからdekiwikiへアクセスすることも増えてきたのだが、そうなると気になるのが途中経路におけるスニフィングだ。それに対しての最も簡単なソリューションはhttpsアクセスを行うことなので、その設定を行ってみることにした。

方法は、調べてみると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へ転送するようにした。

が、ここで問題1つめが発生した。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>

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

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

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

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