« May 2011 | Main | July 2011 »

June 2011

2011.06.29

WebDAVフォルダで「読み取りのみ」ユーザーと「読み書き」ユーザーを区別する(2)

WebDAVフォルダで「読み取りのみ」ユーザーと「読み書き」ユーザーを区別する の対応では、「読み取りのみ」のユーザーの場合、CarotDAVなどのWebDAVクライアントでのアクセスができなくなってしまいます。

これは、GETリクエスト以外は拒否しているにも関わらず、WebDAVクライアントの場合はOPTIONSやPROPFINDなどのメソッドを投げてくるため。単純にブラウザ経由でダウンロードするだけであればこれでも何とかなるのですが、フォルダ単位でサーバーからファイルをコピーする場合などは、やはりCarotDAVなどを使いたいところ。

ってことで、設定を見直してみました。単純に、制限するメソッドとして、GET以外にOPTIONSとPROPFINDを指定すればオッケーのようです。

<LimitExcept GET OPTIONS PROPFIND>
  Require group testgroup1
</LimitExcept>
<Limit GET OPTIONS PROPFIND>
  Require group testgroup1 testgroup2
</Limit>

上記のような感じに設定すると、testgroup2は読み取りのみ可能となり、また、CarotDAVからも問題なくアクセスできるようになりました。

| | Comments (0) | TrackBack (0)

2011.06.28

TortoiseSVNとSSLクライアント証明書(パスワードが保存されない)

TortoiseSVNとSSLクライアント証明書 では、そもそもサーバーにアクセスできない(エラーが発生する)という現象だったのですが、今回は、「クライアント証明書のパスワードが保存されない」という現象に遭遇。

やはり同様にTortoiseSVNでSSL証明書のパスフレーズが保存されないの内容で解決。というか、このページの内容は、まさに今回の現象そのもの(前回の現象は、レジストリパスなどの参考になった、って感じでしょうかね?)

レジストリエディタを起動し、 HKEY_CURRENT_USER\Software\tigris.org\Subversion\Servers\(servername) に以下の値を追加(文字列値(REG_SZ))。

ssl-client-cert-password = password

これで、期待した動きになりました(^^

パスワードが平文で保存されているので、取り扱いには注意が必要でありますが(^^;

| | Comments (0) | TrackBack (0)

2011.06.26

muninからのメール送信

メール送信の設定をしていないのに、5分に1回muninからメール送信が行われていることに気付きました(さくらのVPSにて)。他のサーバーではこんな現象が出ていないので、どこか設定の問題だとは思いつつ・・・。

munin on FC6では、muninディレクトリの所有権の問題で同様の現象が発生しうるとのことですが、特に問題はなし。

ん~・・・
muninの結果の画面を確認したところ、HDD temparatureの結果を取得できていないようで、このエラー通知を行おうとしてメール送信をしているのでは? と推測。

# cd /etc/munin/plugins
# rm hddtemp_smartctl

でHDD temparatureデータ取得用のプラグインを削除してmunin-nodeを再起動。

今のところ、問題なさそうな感じ。

| | Comments (0) | TrackBack (0)

2011.06.23

Trac>管理画面でUnicodeDecodeError

突如、Tracの管理画面で

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1: ordinal not in range(128)

のエラーが。しかも、全ての設定項目で発生するわけではないところが謎。数日前までは動いていたので、追加でインストールしたプラグインが影響しているのかもしれませんが、かといって、プラグインを無効化するわけにもいかず。

調べてみると・・・[Trac]Trac0.11.2.1.ja1でUnicodeDecodeErrorへの対応方法の内容で解決。

Pythonのインストールパスに合わせて、

# touch /usr/local/share/python2.6.6/lib/python2.6/site-packages/sitecustomize.py

でファイルを作成。

中身は、以下の通り。

import sys
sys.setdefaultencoding("utf-8")

Apacheを再起動すると、無事に表示されるようになりました。

#Trac0.11.7-ja1にて。

| | Comments (0) | TrackBack (0)

2011.06.22

Trac>ProtectedMacro or AccessMacro

ProtectedMacroと、AccessMacro を導入してみました。
どちらも、同種のマクロで、Wikiページの特定の部分に関して「権限がない場合は非表示にする」ことができます。

今回やりたかったのは、iframeで表示したカレンダーに関して、直接編集可能なユーザーと、閲覧のみのユーザーを定義する、ということ(wdCalendar側のphpスクリプトを書き換えることで編集できないページも作る)。

結果としては、AccessMacro になりそうな感じ。

「特定の権限を持っている場合はAを、持っていない場合はBを表示する」という制御はProtectedMacroでは無理っぽい感じでしたので・・・。

例えば、WIKI_ADMIN権限を有しているかどうかで判断するとした場合、

{{{
#!access
#allow(WIKI_ADMIN)
{{{
#!html
<iframe width="100%" height="500" src="/calendar/index_editable.php">カレンダー</iframe>
}}}
}}}
{{{
#!access
#deny(WIKI_ADMIN)
{{{
#!html
<iframe width="100%" height="500" src="/calendar/index_viewonly.php">カレンダー</iframe>
}}}
}}}

って感じで設定すると、期待した動きをしてくれそうな雰囲気。

| | Comments (0) | TrackBack (0)

2011.06.21

Trac>DiscussionPlugin

その昔、インストールしたことがある(その1その2その3その4)のですが、その後は全然使っていませんでした。

で、久しぶりにインストールしてみたのですが(r9787)・・・なかなかよさげな感じですね。頑張ってOSQAをインストールしたのですが、DiscussionPluginで充分まかなうことができそうな感じ?

いろんなアプリケーションを使うと、ユーザー管理が煩雑になったり、いろんなページにアクセスしなければいけなかったりするのでちょっと面倒だなぁ・・・と思っていたので、まずはDiscussionPluginで頑張ってみようかと。

修正依頼 => Ticket
各種連絡事項 => FullBlogPlugin
仕様検討やQ&A => DiscussionPlugin

ってな感じの組み合わせでしょうか。せっかくなので、http://servername/ のような感じでアクセスしてきた場合、Tracのトップページにリダイレクトするようにしてみました(笑

RewriteEngine on
RewriteRule ^/$ /trac/projectname/wiki/ [R=301,L]
RewriteRule ^/index\.html$ /trac/projectname/wiki/ [R=301,L]

#OSQAを使わないのであれば、Python2.5のままでも良かったのですが、これを機にいろんなものをアップデートする気になったので、良しとしますか(笑

| | Comments (0) | TrackBack (0)

2011.06.20

Subversion1.5.9から1.6.17にアップデート

Tracを0.11.1から0.11.7に変更したついでに、Subversionを1.5.9から1.6.17に変更してみました。

念のため、1.5.9の状態でsvnadmin dumpでリポジトリのバックアップを作成。

インストール。subversion-depsもあわせて取得すると、依存ファイルが含まれているので、ラクです(例えば、CentOS5系列の場合、SQLiteは3.3.xなのですが、Subversion1.6.17は3.4以上(できれば3.6.11など)が必要となるので)。ちなみに、インストールしたのは64bit版。


# wget http://subversion.tigris.org/downloads/subversion-1.6.17.tar.gz
# wget http://subversion.tigris.org/downloads/subversion-deps-1.6.17.tar.gz
# tar zxvf subversion-1.6.17.tar.gz
# tar zxvf subversion-deps-1.6.17.tar.gz
# cd subversion-1.6.17
# ./configure --prefix=/usr/local/share/subversion1.6.17 --with-apxs=/usr/local/apache2/bin/apxs --with-apr=/usr/local/apache2/bin/apr-1-config --with-apr-util=/usr/local/apache2/bin/apu-1-config --with-ssl --enable-shared CFLAGS=-fPIC -enable-shared
# make
# make install
# make swig-py
# make install-swig-py
# ln -s /usr/local/share/subversion1.6.17/lib/svn-python/svn /usr/local/share/python2.6.6/lib/python2.6/site-packages/svn
# ln -s /usr/local/share/subversion1.6.17/lib/svn-python/libsvn /usr/local/share/python2.6.6/lib/python2.6/site-packages/libsvn

今までは、デフォルトのパスにインストールしていたのですが、今回は何となくprefixを指定したので、シンボリックリンクを作成。

# cd /usr/local/bin
# mkdir svn1.5.9
# mv svn svn1.5.9/
# mv svnadmin svn1.5.9/
# mv svndumpfilter svn1.5.9/
# mv svnlook svn1.5.9/
# mv svnserve svn1.5.9/
# mv svnsync svn1.5.9/
# mv svnversion svn1.5.9/
# ln -s /usr/local/share/subversion1.6.17/bin/svn /usr/local/bin/svn
# ln -s /usr/local/share/subversion1.6.17/bin/svnadmin /usr/local/bin/svnadmin
# ln -s /usr/local/share/subversion1.6.17/bin/svndumpfilter /usr/local/bin/svndumpfilter
# ln -s /usr/local/share/subversion1.6.17/bin/svndumplook /usr/local/bin/svnlook
# ln -s /usr/local/share/subversion1.6.17/bin/svnserve /usr/local/bin/svnserve
# ln -s /usr/local/share/subversion1.6.17/bin/svnlook /usr/local/bin/svnlook
# ln -s /usr/local/share/subversion1.6.17/bin/svnsync /usr/local/bin/svnsync
# ln -s /usr/local/share/subversion1.6.17/bin/svnversion /usr/local/bin/svnversion

ライブラリ側も同様に。

# cd /usr/local/lib
# mkdir svn1.5.9
# mv libsvn*.la svn1.5.9/
# mv lib*.so.0.0.0 svn1.5.9/
# ln -s /usr/local/share/subversion1.6.17/lib/libsvn*.la /usr/local/lib/
# ln -s /usr/local/share/subversion1.6.17/lib/libsvn*.so.0.0.0 /usr/local/lib

バックアップファイルをロードして、リポジトリを再構築(chownも忘れずに)。

とりあえず、動いてくれているようです。

#ライブラリのコピー(リンク)を忘れると、Tracで

Warning: リポジトリと同期できません (Unsupported version control system "svn": "/usr/local/lib/libsvn_client-1.so.0: undefined symbol: svn_mergeinfo__catalog_dup" )。詳細は Trac のログを参照してください。

というエラーを食らいます。

| | Comments (0) | TrackBack (0)

2011.06.19

Trac0.11.1から0.11.7へのアップデート

OSQAを使用するために、Python2.6を導入し、そこにTracの環境を構築したのですが・・・添付ファイルをアップロードできないという問題が発覚。調べてみると、同様の報告多数。

Tracで添付ファイルがアップロードできない。
Trac Users - Can't add attachments.

Trac0.11.4以降を使えば問題ないとのこと。選択肢としては2つ。
1)Python2.5に戻す
2)Trac0.11.4以降を導入する

OSQAとの兼ね合いもあったりすることから、現時点での0.11系列の最新版である0.11.7(ja1)を導入することに。0.12はさすがに見送りです・・・(プラグインの修正なども必要となりそうですし)。

0.11.1本体にも結構手を加えていたので、とりあえずは、それらの修正内容を0.11.7に適用してインストールすることに。一部ソースコードの整理などの影響で、そのまま適用できないところもありましたが、特に問題なく作業完了。Apacheを再起動すると、とりあえず、問題なさげ。

ただ、元々TopicPathMacroを組み込んで使用(htmlテンプレートに直接埋め込み)していたのですが、同等の機能が標準で組み込まれたため、「パンくず」が2行表示されることに(笑)。TopicPathMacro の使用をやめることで解決。

さて、これでしばらく様子を見てみることにしますか・・・。

| | Comments (0) | TrackBack (0)

2011.06.18

wdCalendarの内容をTracに埋め込む

wdCalendarの内容をTracのwikiページに埋め込むことができればいいなぁ・・・と。

(挑戦1)
Include external resources in a wiki page のマクロを使用。wikiの render_unsafe_content の値を true にセット。
このマクロは、「Tracが稼働しているサーバー」からリクエストが行われ、その結果をWikiページに埋め込むという動きになっています。なので、TracとwdCalendarが同一サーバーで動いている場合、http://localhost/~ のような記述でも対応可能。
・・・ただ、wdCalendarのレイアウト等は全く再現できず、ただしく表示できなかったのであえなく挫折。

せっかくなので、マクロのインストール手順を。

# svn checkout http://trac-hacks.org/svn/includemacro
# cd includemacro/0.11/
# python setup.py install

(挑戦2)
iframeを使用。これまた、render_unsafe_content の値を true にセットしておく必要があります。

{{{
#!html
<iframe src="http://servername/wdcalendar/index.php" width="100%" height="500" >カレンダーが表示されます</iframe>
}}}

のような感じでWikiページに埋め込むと、wdCalendarの内容が表示されました。また、iframeを使用しているので、編集も直接行うことができます。

なかなか強引な方法ではありますが、いろんなURLを飛び回る手間を省けるのは魅力的。ただ、render_unsafe_content を true にしなければならないため、セキュリティリスクは高まってしまいます。アクセス可能なメンバーが限定されているような環境(LAN内に構築しているチーム用Tracなど)の場合は、使い道があるかもしれませんね。

| | Comments (0) | TrackBack (0)

2011.06.12

LDAPで認証させている場合の注意点

Apacheの認証でLDAPを使用している場合、LDAPが停止していると、「Internal Server Error」が発生。

それはまぁいいのですが、困ったことに、error_logなどには何も出力されないっぽいこと。30分くらい悩んでしまいました(^^;

#サーバーセットアップ中で、まだ自動起動の設定を行っていない状態で再起動したため、LDAPは手動起動の必要があった・・・。

| | Comments (0) | TrackBack (0)

2011.06.11

64bit版CentOSにmod_wsgiをインストール

64bit版CentOS(5.6)にApache2.2.17 / Python2.6.6 / mod_wsgi 3.3をインストールしようとすると、コンパイルに失敗。

調べてみると、64bit版CentOSにインストールする場合、Pythonおよびmod_wsgiをconfigureする際に

CFLAGS=-fPIC -enable-shared

の指定が必要となるようで。
./configure --prefix=/usr/local/share/python2.6.6 CFLAGS=-fPIC -enable-shared

なお、これだけだと、python実行時に
python: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory

というエラーが発生するので、ライブラリを /usr/lib64 にコピーしておく必要あり。
cp libpython2.6.so.1.0 /usr/lib64
cp libpython2.6.so /usr/lib64

mod_wsgiに関しては、以下のような感じ。

./configure --with-apxs=/usr/local/apache2/bin/apxs --with-python=/usr/local/share/python2.6.6/bin/python CFLAGS=-fPIC -enable-shared

| | Comments (0) | TrackBack (0)

2011.06.08

SELinuxの設定変更

CentOS(5.6)をGUIなしでサーバー用にインストールした場合、デフォルトでSELinuxは有効な状態(enforcing)になっているんですね。

SELinuxを無効化する場合、 /etc/sysconfig/selinux ファイルの以下の部分を変更。

SELINUX=disabled

mod_wsgi を読み込む際に、

cannot restore segment prot after reloc: Permission denied

というエラーが発生したことで気付きました(参考:modwsgi Application Issues)。

| | Comments (0) | TrackBack (0)

2011.06.07

VMware上のLinuxの時刻ずれ

VMware上でゲストOSにLinuxをインストールした時に時刻がずれてしまうのは有名な話。

今回、VMwarePlayer(3.1.4)でそれの対応をしたので、そのメモ。ゲストOSはCentOS5.6でGUIなしのサーバー環境をインストール。

OSのインストール完了後、VMwareToolsを導入。まずは、VMwarePlayerのメニューからToolsのダウンロードを実行。その後、rootでログインし、VMwareToolsをビルドし、インストール。

# cd /
# mount /dev/cdrom /media
# mkdir /work
# mkdir /work/vmwaretools
# cd /work/vmwaretools
# cp /media/VMwareTools-8.4.6-385536.tar.gz .
# tar zxvf VMwareTools-8.4.6-385536.tar.gz
# cd vmware-tools-distrib
# ./vmware-install.pl

いくつか質問事項が表示されるので、全てデフォルトの値を使用(そのままEnterを押下すればOK)。

In which directory do you want to install the binary files?
[/usr/bin] そのままEnter

What is the directory that contains the init directories (rc0.d/ to rc6.d/)?
[/etc/rc.d] そのままEnter

What is the directory that contains the init scripts?
[/etc/rc.d/init.d] そのままEnter

In which directory do you want to install the daemon files?
[/usr/sbin] そのままEnter

In which directory do you want to install the library files?
[/usr/lib/vmware-tools] そのままEnter

The path "/usr/lib/vmware-tools" does not exist currently. This program is going to create it,
including needed parent directories. Is this what you want?
[yes] そのままEnter

In which directory do you want to install the documentation files?
[/usr/share/doc/vmware-tools] そのままEnter

The path "/usr/share/doc/vmware-tools" does not exist currently. This program is going to create it,
including needed parent directories. Is this what you want?
[yes] そのままEnter

(略)

Before running VMware Tools for the first time, you need to configure it by invoking the following command:
"/usr/bin/vmware-config-tools.pl". Do you want this program to invoke the command for you now?
[yes] そのままEnter

アンマウントも自動的に行われるようですね。

続いて、/boot/grub/grub.conf の kernel行に以下のオプションを追加し、ゲストOSをシャットダウン。

clock=pit nosmp noapic nolapic

vmxファイルの以下の行を設定変更し、ゲストOSを起動。

tools.syncTime = "TRUE"

設定を行う前は、数時間で数秒ずれていたのですが、設定変更後は、今のところ、いい感じです。

なお、物理CPUのコア数やゲストOSへの割り当てCPU数によって変わってくるかもしれません(今回は、今時珍しい、シングルコアCPUでの動作確認です)。

| | Comments (0) | TrackBack (0)

2011.06.06

OSQAで複数サイトを同時に稼働させる

同一サーバーで複数のOSQAを稼働させたいようなケースもあるかと。例えば、「アプリケーションの利用」の観点からのQAと、「開発」の観点からのQA。アプリケーションの利用者にとっては開発ネタなんて興味がないケースも多く、ぎゃくん、開発側にとっても開発ネタをあまり一般に見せたくないってこともあるかと(逆に、開発ネタが「アプリケーションの利用」の中に埋もれてしまうのを避けたいかもしれませんね)。

ってことで、同一サーバーで複数のOSQAを稼働させてみました。参考にしたのは、How to modify *.wsgi file to specify settings.py file for multiple sites running on one instance of OSQA? および Can I run multiple OSQA sites through a single OSQA install? の内容。ただ、ちらほらと誤植があるっぽい・・・?(単にOSQAのバージョン違いに起因するのかもしれませんが)

以下、メモ。

settings.pyとsettings_local.pyのコピーを作成する。例えば、今回はdevsettings.pyとdevsettings_local.pyを作成。

devsettings_local.pyを書き換える。今回書き換えたのは、以下の通り。実際の環境に応じて。
・ログ出力の部分

filename=os.path.join(SITE_SRC_ROOT, 'log-dev', LOG_FILENAME),

・DBファイルのパス(今回はSQLiteを使用)
DATABASE_NAME = '/opt/OSQA/dbdev/osqa.db'

・キャッシュのパス
CACHE_BACKEND = 'file://%s' % os.path.join(os.path.dirname(__file__),'cache-dev').replace('\\','/')

・URL
APP_URL = 'http://servername/dev'

devsettings.pyを書き換える。多分、以下のところだけ?

# User settings
from devsettings_local import *

wsgiスクリプトを作成。今回は、osqa.wsgiをosqa-dev.wsgiとコピーしてから編集。

os.environ['DJANGO_SETTINGS_MODULE'] = 'OSQA.devsettings'

各フォルダを作成する。

# mkdir cache-dev
# mkdir dbdev
# mkdir log-dev

初期データベースの作成を行う(ここでハマってしまいました・・・)。

# python manage.py syncdb --settings=devsettings

フォルダの所有権を変更。

# chown -R daemon:daemon cache-dev
# chown -R daemon:daemon dbdev
# chown -R daemon:daemon log-dev

Apacheの設定ファイルを変更。元々の設定に、URLとスクリプトの組み合わせを間違えないように以下の1行を追加。

WSGIScriptAlias /dev /opt/OSQA/osqa-dev.wsgi

ってことで、Apacheを再起動しそれぞれのURLにアクセスしてみると・・・とりあえず、きちんと分離された状態で動いているようです。ユーザーもそれぞれで登録され、また、表示もそれぞれで。

ただ、「OSQA-1」でログイン中に、同じブラウザで「OSQA-2」にログインすると、OSQA-1側からは強制的にログアウトされてしまうっぽいですね。セッション情報を管理しているキーが共通なんですかね?

まぁ、これはこれで理にかなっているのかも知れませんが、どっちのOSQAも使用するようなユーザーの場合、ちょっと不便かも(何か設定があるのかもしれませんが)。

#ファイルのアップロード(特に同じファイルをそれぞれのサイトにアップロードした場合)などは大丈夫なのかどうか、ちょっと不安(^^;

| | Comments (0) | TrackBack (0)

2011.06.05

svnsync: Couldn't get lock on destination repos after 10 attempts

svnsync実行中に同期先のリポジトリを格納しているディスク容量がなくなったりした場合、ディスク容量を確保してもどのままでは同期できなくなってしまいます(svnsync: Couldn't get lock on destination repos after 10 attemptsといった感じのエラー)。

その場合、

svn propdel svn:sync-lock --revprop -r 0 同期先リポジトリ

でロックを開放すればOK。Webに設置しているリポジトリを、ローカルのHDDにミラーしているような場合、
svn propdel svn:sync-lock --revprop -r 0 file:///path

のような感じになるかと。

参考:
svnsync中に落ちた
svnsyncによるリポジトリ同期中にエラーが発生した時の対処法

| | Comments (0) | TrackBack (0)

2011.06.04

Trac>TicketCloneプラグイン

TicketCloneプラグインを導入してみたので、そのメモ。

以下のような環境において有用かもしれません。

・類似の2つのシステムをメンテナンスしている。
・同じTracプロジェクトで管理している。ただし、Ticketそのものはシステム毎に起票するルール。
・片方で不具合が出た場合、他方でも同様の不具合が発生しているケースが多い(⇒ほとんど同じ内容のチケットを2件起票する)。

リポジトリからticket_clone.pyをダウンロード(Trac 0.11系列用)。ソースを見た感じ、チケットのクローンを行うためにはTICKET_ADMINの権限が必要とのこと。

とりあえず、TICKET_CLONABLEという権限を別途追加して、チケットのクローン作成を行う場合は、この権限を有していればOKとなるように改造(さすがに、TICKET_ADMINは乱発したくないので)。

改造したソースはこちらから ⇒ ticket_clone-r284.zip (1.0K)

egg形式ではないので、導入したいプロジェクトのpluginsフォルダ内に ticket_clone.py をコピーしてApacheを再起動すればOK。

ほとんど内容が同じTicketなので、本文などはCopy&Pasteで対応できていましたが、各プロパティは個々に設定していく必要があり、それなりに時間がかかっていました。TicketCloneプラグインの導入で、その時間を大幅に短縮できるのではないかと期待されます(あと、入力ミスも減らせるかも)。

| | Comments (0) | TrackBack (0)

2011.06.03

shapado

OSQAはPython+Djangoですが、RoRで作られている同種アプリケーションとしてshapadoってのがあるんですね。何て読むんでしょ??

ただ、現状では、どちらも日本語の情報はあまり多くない感じですね・・・。

なお、OSQAインストールの時は、オープンソースstackoverflowクローン OSQA を参考にさせていただきました。

| | Comments (0) | TrackBack (0)

2011.06.02

OSQAの管理者

OSQAのユーザーテーブルに対して最初に登録されたユーザーに、自動的に管理者(Superuser)の権限が付与されるっぽいですね。

ただ、初期セットアップ時の、


You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no):

という質問に対して yes と回答してしまった場合、その限りではないようです(参考)。

最初のユーザーに自動的にSuperuser権限が付与されるってことは、最初に誰がログインするか(最初に誰にログインさせるか)っていうのは重要になってくるかもしれません(もっとも、インストール担当者=管理者となることが多いような気もしますが)。

ちなみに、他のユーザに対してSuperuser権限を付与する場合、「管理」ページではなく、「ユーザー一覧」を表示し、そこから権限を付与したいユーザーを選択してから実行するようですね(管理者の場合、各ユーザーのいろんな情報も書き換え可能)。

| | Comments (0) | TrackBack (0)

2011.06.01

OSQAのデータキャッシュの問題・・・暫定的に解決したかも?

関係しそうなチケットを見つけました ⇒ Cache is not working

確かに、ファイルベースのキャッシュシステムの設定にしていても、cacheフォルダに何も出力されないので不思議に感じていたのですが・・・試しに、settings.py の

from django.middleware.csrf import CsrfViewMiddleware

の行をコメントアウトしてみると、cacheフォルダ内に大量のキャッシュが出力されるように。合わせて、不正なデータキャッシュが残るっていう現象も改善したような感じです。

起票者を見てみると、atsuo ishimoto さん・・・オープンソースQ&Aシステム OSQAのインストール方法で参考にさせていただいたatsuoishimotoさんですね。

(2011/06/12追記)
Trunkのソースをチェックしてみたところ、rev.1059(2011/06/08commit)で修正されているっぽいですね。

| | Comments (0) | TrackBack (0)

« May 2011 | Main | July 2011 »