2009-12-17

Scriptでコンテンツタイプの変換 (Plone)

plone-usersのML(海外)をチェックしていたら、普段はぜんぜん英語についていけないのですが、たまたま目に留まったのでメモします。

内容は、オブジェクトのコンテンツタイプを変更する、というもの。
ざっと見ると、ExFileで作成したコンテンツを、スクリプトでATFileに変更する際の質問でした。

『おお!』と思ったのは、そのもの、タイプを変更する手順です。

Ploneに特殊なコンテンツタイプの場合は変更は難しいのですが、ちょうどバイナリファイルのタイプの扱いに悩んでいたところです。

Data.fsの肥大化は避けたいと思い、plone.app.blobを使ってファイルの格納先をファイルシステムにしたのはいいのですが、保存されるファイル名がなにやらハッシュのため、どうも今ひとつな印象を持っています。

可能なら、いったんblob化されたATFileをExFileとかに変えたいなあと思っていたのですが、膨大(?)かもしれない数を自分で1つ1つ間違いなく取り出すのは至難の業です。

なにかできないかな、と思っていたところに、こちらの記事でした。(こちらの場合は、ExFile –> ATFileへの変換なので、パターンは逆ですが)

まだ何も試してはいませんが、ソースが出ていましたので、とても参考になりました。

2009-12-11

ezFAQを入れてみました (Redmine0.8.7)

現在稼動中のRedmineを、0.8.7にアップデートするために、いろいろ動作確認をしています。Redmine本体は問題ないのですが、心配なのはPluginまわりです。

今回は、r-labsで提供されている、Redmine0.8x対応の ezFAQ を組み込もうと、プラグイン追加の処理を行いました。
(※ezFAQ本家のtrunkは、Redmineのtrunk / 0.9x のみの対応です)

さて、動作確認をしたところ…。

新規投稿のところで、いきなりエラーが発生してしまいました(^^;
画面には特にエラーメッセージが出ずに、『真っ白』…。

しかし、前の画面に戻って、FAQの一覧表示画面を参照すると、ちゃんとFAQのエントリは作成されています。

production.log に表示されたエラーは、以下の通りです。

ActionView::TemplateError (Translation value "FAQ %s は %s によって更新されました。" with arguments [{:title=>"#11", :author=>#<User id: 3, login: “…….", hashed_password: "", firstname: "xx", lastname: "xxx", mail: "xxxxx", mail_notification: false, admin: true, status: 1, last_login_on: "2009-xx-xx 08:35:37", language: "ja", auth_source_id: 2, created_on: "2008-02-14 13:31:34", updated_on: "2009-xx-xx 09:26:19", type: nil>}] caused error 'too few arguments') on line #1 of faq_mailer/faq_add.text.html.rhtml:
1: <%= l(:text_faq_added, :title => "##{@faq.id}", :author => @faq.author) %>
2: <hr />
3: <%= render :partial => "faq_text_html", :locals => { :faq => @faq, :faq_url => @faq_url } %>

    vendor/plugins/gloc-1.1.0/lib/gloc-internal.rb:93:in `_l'
    vendor/plugins/gloc-1.1.0/lib/gloc.rb:19:in `l'….

 

どうやら、メール送信用のテンプレートでエラーが発生している模様。素直にメッセージを読むと、Transrationのための引数が足りてない、とのことです。でも、前後のソースを読むと、引数は足りているっぽい。

どうしたものかしら…と思ったのですが、このエラーは新規登録の時だけで、更新の場合にはエラーが出ていません。(更新の場合も、models/faq_mailer.rb でメール送信の処理を行っています)

ja.ymlなどの言語ファイルを見ても、更新と新規登録の際のフォーマットはほとんど同じ。

なぜだろう…と思って、views/ 以下のファイルを比べてみたところ、微妙な違いがありました。

  1. faq_add.text.html.rhtml
    <%= l(:text_faq_added, :title => "##{@faq.id}", :author => @faq.author) %>
  2. faq_update.text.html.rhtml
    <%= l(:text_faq_updated, "##{@faq.id}", @faq.author) %>

こちらを、後者(2)のように治したところ、ひとまずエラーが回避できました。Railsの多言語化のところでひっかかったのだろうなあ..。とは思うのですが、同じRedmien0.8.7を使っていても、エラーになるのは私だけかもしれません。(ちなみに、ezFAQのtrunkでは、(1)の記載で統一されています)

ちゃんとRORを理解せずに使いだしたので、これはいけないなあ…と思い始めた今日この頃です….。

2009-12-10

Redmineの(なんちゃって?)SSO対応

現在利用中のRedmineですが、同一ドメインで動かしているWebアプリケーションとSingle Sign Onで運用できたらいいなあ…と思い始めました。

※ なお、Redmineも他のアプリケーションも、IDとパスワードについては同じLDAPを参照しているので、少なくとも、IDとパスワードは一元化されています。

そこで、RedmineとSSOをキーワードに検索をしてみたところ、以下の記事がヒットしました。(Redmine.org本家のフォーラムです)

Running redmine on Apache2 on Windows; using SSPI authentication; is it possible?

上記の内容では、Apacheの環境変数に入ったユーザ情報を、RemineのApplicationControllerで取得して、Sessionに格納されているUserIdの代わりに利用する、というものでした。

わたしの環境では、WindowsのSSOではなく、また、Apacheの環境変数にもユーザを識別する情報は入らないのですが、なんらかの方法でユーザIDを取得して、ここだけ修正すれば問題なさそうです。

 if session[:user_id]
# existing session
(User.find_active(session[:user_id]) rescue nil)
+elsif (forwarded_user = request.env["HTTP_X_REMOTE_USER_6E3RZQKX"])
+ # web server authentication
+ (User.find_by_login(forwarded_user) rescue nil)

elsif cookies[:autologin] && Setting.autologin?
# auto-login feature
User.find_by_autologin_key(cookies[:autologin])


Apacheの基本認証であれば request.env[“REMOTE_USER”]を指定すればいいし、Cookieなどであれば、cookies[“….”]で値を拾って処理すれば大丈夫でした。



動作としては、以下のようになりました。(Apacheの基本認証の例)




1. Redmineのログインフォームから認証済みであれば、そちらをまず利用。

2. Redmineにログインしていない場合で、Apacheの認証済みの場合、その情報を利用。



3. ただし、Apacheの認証を行っていても、Redmineのユーザ登録を行っていなければ、User.find_by_login でヒットしないため、匿名アクセス扱いになる。




どちらの認証も済んでいるのであれば、Redmine本来のセッション情報のほうが優先されます。

やってみると、少しの調整で済んだので、大変ありがたいです。


逆に、Redmineに認証済みで、その情報を他のアプリにも渡したいとなると、Redmineから他のアプリからも取得できるようなCookieをセットしてもらうとか、ユーザ情報を返すAPIを追加するとか、ちょっと面倒ですね…。



他にいろいろ(もっと良い)方法があるかと思いますので、見つかったらまた追記したいと思います。

2009-12-07

Plone3.3.2 –> python-ldap-2.3.10 が入らない!

順序がちぐはぐですが、Plone3.3.2の覚え書き。

一番最初の構成は成功したので、次に必須であるLDAP対応のPloneを構成しようと思いました。

こちらは、いろいろ参考にさせていただいている、清水川さまの設定に倣って、LDAP用のプロダクトを追加しました。

  • Products.LDAPMultiPlugins
  • Products.LDAPUserFolder

buildoutなので、依存プロダクトなどは勝手に追加されるはず…。

ところが。

PythonはOSにインストールしたpython2.4.6 を利用しているんですが、buildoutの途中に python-ldap-2.3.10 のインストールのステップが入るのですが、これがどうしても失敗してしまいます。

前に作ったStandaloneのPlone(Plone3.3)では、python-ldapは別途、setup.py でインストールして、Products.LDAPMultiPlugins なども buildoutではなく /Products に追加する形で動かしていたので、そちらの構成と見比べてみました。

Plone3.3のほうは、python-ldap-2.3.8 で、バージョンが古いものになっています。こちらのソースが残っていたので、pythonのモジュールとして組み込んでみましたが、Plone3.3.2のbuildoutでは、このバージョンではNGの模様。
相変わらず、python-ldap-2.3.10 のインストールを促され、途中で失敗となりました。

では、と思って、python-ldap-2.3.10 のソースをダウンロードして setup.py してみたところ、これもNG!

どうすればいいんだ~!と困り果て、再度清水川さまの記事を見ると、ちゃんと、python-ldap-2.3.10 のインストールで不具合がある旨の記載がありました…。

こちらを眺めると、HEADリビジョンは修正がなされているらしい書き込みがあったので、CVSリポジトリからチェックアウトしてみることにしました。

# cvs -d:pserver:anonymous@python-ldap.cvs.sourceforge.net:/cvsroot/python-ldap login

# cvs -z3 -d:pserver:anonymous@python-ldap.cvs.sourceforge.net:/cvsroot/python-ldap co -P python-l
dap

#ちなみに、使っているCentOSには、CVSは入っていません…。せめてSVNなら良いのに、と思いつつ、yum install cvs してしまいました。

ということで、上記のソースを再度、setup.py してみると、あっさりインストールが完了。buildout も通るようになりました。

buildoutの出力を眺めてみると、インストールされたHEADのpython-ldap は python-ldap-2.3.11 でした。

こちらは、まだhttp://pypi.python.org/ には登録されていない模様ですが、いずれ対応するのかと思います。

とりあえず、清水川さま、ありがとうございました!

Plone3.3.2のインストール(以前)

※続きがあるかどうかは不明ですが、自分用の覚え書き。

現在使っているPlone3.3は、Unified Installerの形式になってから、初めて作ったものです。以前のPlone2.1xも、Windows環境だったので、本来の正しいZope/Ploneの作り方がわかっていたわけではありませんが、Unified Installerになってからは、buildoutやら easy_installやら、さらに謎の世界になっていました。

あれこれ思考錯誤しているうちに、なんとかPlone3.3の利用にこぎつけたものの、パフォーマンスやバックアップの問題が出てきて、やっぱりちゃんと理解して作らないとだめかなあ…と(いまさら)思うようになりました。

特に、PackやIndexの再構築の際、CPUの負荷が上がってしまい、閲覧専用の動作にも支障をきたすようになっ(てしまいました。VarnisやCacheの調整を行ってみましたが、こちらもZope側とのセッションでタイムアウトが発生したりすると、お手上げです。

作り直すなら、まだユーザの少ないうちに…と思い、改めて別環境にPloneをインストールすることにしました。(もちろん、本番は問題を抱えながらもそのままですが)

今回は、先の経験を踏まえ、以下のような方針にしてみました。

  • Pythonのバイナリ は、Unified Installで /usr/local/Ploneに専用に追加されるものではなく、先にOSにインストールした /usr/local/python を利用。
  • CentOS付属のPython2.3は削除もしくはそのまま残し、Zopeに対応するバージョンを別途インストール。
  • 管理用のプロセスと通常利用のプロセスを分けられるように、ZEOの構成をとる。
  • blobは引き続き利用。
  • なんでもかんでもbuildout.cfgに記載してインストールをすることは避ける(不要なプロダクトは追加しない)
  • 本番環境ではbuildoutは使えない点に注意し、ソースを個別にダウンロードしてのeasy_install, setupに慣れるようにする。

一番の課題は、やはりZEOに慣れる、実際に使えるかどうか評価することです。幸い、easy_install や buildout はおぼろげながら慣れてきているので、まっさらな状態で開始するよりはマシかな、と思っています。

また、Plone3の情報も、日本語のリソースも含め、今年の春の段階よりもずいぶん増えてきています。(これは本当にありがたいこと)

さて、どうなることやら。
続きは次のエントリで…(^^;