2010年1月19日火曜日

Django:つまらんことに引っかかった

 先日までのアプリケーションに一区切りつけて、別なアプリケーションを作り始めたのだが、つまらんところで嵌る。

 ページを表示しようとすると、
"Non-ASCII character '\\xe5' in file C:\\Python26...\\views.py on line 51, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details", ('C:\\Python26...
 とエラーが出た。ソースに全角スペースでも紛れ込んだかとバイナリーエディターをダウンロードして調べてみたが、0xe5 で引っかかったのは文字列の中の漢字の一文字目。よく見ると動いているソースの一行目に
# -*- coding: utf-8 -*-
 が入っている。コピペした元ソースにはそんなものは入っていないのだが...。

 ま、いいことにして次に進もう。

2010年1月14日木曜日

HTML:<input type="text">でEnterを押してもsubmitさせない方法

 デプロイしながら本番アプリを動かしていたら、ページが表示されているときに改行を入力するとおかしな動きをすることを発見。

 調べていくと、<input type="text">でEnterを押すと、勝手に submit されるようだ。

 回避方法は javascript を使ったこちらのページのものを使った。

 ちょっと時間はかかったが、高速道路万歳!!

2010年1月13日水曜日

XERA+Django:CORESERVER から XREA に移行

 fastcgi を使うために CORESERVER にデプロイしたのだが、使えないようなので、すでにアカウントを持っている XREA に移行。

 このブログのエントリーを見ながら30分ちょっとで移行終了。二日も嵌った Django の吐く妙なメッセージが XREA では出てこない。python,django その他もろもろのバージョンは全部同じはずなのだが...。

 動いたは動いたが、1ページにイメージをたくさん表示させようとすると 4-5枚しか表示されない。サーバの CPU のパワーの差かと思ったが、再読み込みを繰り返していると読めないイメージが毎回変わってなんだか変。
 よくよく調べると、イメージのパスの変換まで django がやっていた。シンボリックリンクをひとつはって問題解決。CORESEREVER(バグあり)と遜色ないスピードになった。

 レンタルサーバーへの cgi デプロイ編、終了。
 

CORESERVER+Django:本番アプリはあっさり動いた

 本番アプリは python2.6 で開発していてそれなりのボリュームがあるので、CORESERVER の python2.4 で動かすにはそれなりの手直しが必要か思ったが、ソースの修正は全くなしで、settings.py を修正したり、eazy_install で PIL をインストールするだけであっさり動いた。

 ちょっと拍子抜け。

 スピードも coLinux+apache+fastcgi よりは遅いが開発用の runserver よりはずっと早い。

 とりあえずこれで良い事にしよう。

CORESERVER+Django:fastcgi はあきらめた

 CORESEREVER を選んだのは、ネットで fastcgi が使えると書いてあるのを見つけたからだったのだが、そのとおりにやってもどうにも手ごたえが無い。
 調べていくと、オフィシャルページに fastcgi の情報はないし、fastcgi は使えないという情報もちら ほら

 潔くあきらめて、本番アプリケーションのデプロイにいこう。

 

2010年1月12日火曜日

CORESERVER+Django:Script error に嵌ったぁ

 CORESERVER の CORE-MINI に登録して Django のデプロイに挑戦。
 基本的にはこちらこちらのページを見ながら virtual-python を入れて ez_setup を入れてと進み、Django と pysqlite をインストール。デバッグ情報出すために .htaccess に
AddHandler cgi-script-debug .cgid
AddHandler cgi-script .cgi
と cgid を追加。

 2010-03-02 追加:xrea では上の2行は特に必要ない模様。CORE SERVER では未確認。

 

あれこれやって簡単な Django アプリケーションが何とかそれっぽい HTML を吐くようになったのだが
Script Error
The script did not produce proper HTTP headers. Please see the error log to see the detail of the errors. Depending on the server configuration, you can also run thisscript under CGIWrap debugging. Usually, either rename or linkthe script temporarily to a file which ends with .cgidextension, or add a AddHandler cgi-script-debug .cgiline to your .htaccess file.
がでてどうしても先に進めない。

2010年1月9日土曜日

Django+fastcgi:動いた

 昨日は小さなな django アプリケーションが動いたので、今日はこの間まで作っていた大物に挑戦。

 smbclient 経由でアクセスするドライブのパーミッション設定がうまくいかなかった(設定してもすぐ元に戻ってしまう)が気のせいか?SQLite とも相性が悪いみたいだし気をつけないといかんなぁ。

 ちょっと手間取ったが settings.py の編集とファイルの再配置など、一時間ほどで動くようになった。

 apache のおかげか fastcgi のおかげかページ更新が速い速い。アプリケーション作成時も早めに apache 環境で動かしたほうが開発効率があがるかもしれない。

 次のステップは xrea を借りて動かすわけだが、これがまた大変いろいろと初挑戦しなくてはならないことが多そうで...。

 web 系は覚えることが多くて、本当に大変だ。

2010年1月7日木曜日

apache + fastcgi:嵌った

 httpd.conf に手を入れて fastcgi 経由で django を使えるようになったので、今度は .htaccess を使って実行する方法試す。

 これが嵌った。

 オフィシャルページの内容に従って .htaccess を作ったのだが、全く反応がない。 url を色々変えてみるが、.htaccess が効いているのかいないのかさっぱりわからない。
 こちらのページを参考に、アクセス制限をかけると...かかった。.htaccess は生きている。
 色々あったが、結局
RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L]
RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L]
 に変更。違いはスラッシュを取っただけ。ちなみに、httpd.conf にも同じような行があるが、こちらはサンプルソースにスラッシュが無く、あれこれやってスラッシュを入れたら動くようになった。

 うーん、大変だ。

Django+SQLite:Unable to Open Database File は、

 google で検索すると二つ目に Django-Trac のページが引っかかり、「Django says "Unable to Open Database File" when using SQLite3」というドンピシャの項目が。
 ここの最初の、
Make sure Apache can also write to the parent directory of the database. SQLite needs to be able to write to this directory.
で、エラーは解決。データベースのパーミションだけではなく、データベースのあるディレクトリも apache から書き込み可能にする必要があるそうだ。

2010年1月6日水曜日

Django:fastcgi を使ったデプロイに悪戦苦闘中

 基本的にはオフィシャルページの内容を元にあれこれやっているのだが、なかなかうまくいかない。
 ぐぐってみても apache + fastcgi + django でうまくいったという日本語のページが見つからない。うまくいかなくて mod_python にのりかえた人は見つけたが、今回はお目当てのサーバーが apache 1.3.x で mod_python が使えない。
 あっちこっち見ていくうちに、lighthttp + fastcgi で django を動かした人を発見。よく見ると、無くても良いことになっている mysite.fcgi を作っている。
 わらにもすがる思い出同じスクリプトを使い、コマンドらいから起動してエラーが出ないようにして apache から呼び出すと、http エラーが 400 から 403 に変わった。初めての手ごたえ。
 さらに調べていくと、こんなページを発見。コマンドラインから実行してエラーを出さなくするための変更を取り去ると、懐かしい django の画面が出てきた (; ;)。
 もとのページを良く見ると、「Apache を使っている共有ホスティングプロバイダ上で Django を使う」ときには mysite.fcgi が必要とのこと。
 テストは、httpd.conf にアクセスできる環境なのでやっぱり mysite.fcgi は入らないはずなのだが...。ま、今回はどの道レンタルサーバーを使うわけだから、これ以上の深入りは避けよう。
----
 ちなみにオフィシャルページに記述は無いようだが、apache に 'Options +ExecCGI'の追加は必要(こちらのページを 'fastcgi: execcgi option is off in this directory'で検索)。

----
 で、ついなる難関は django が出してきた 'unable to open database file'。読み出しは問題ないのに開けないってどういうこと??
 

2010年1月3日日曜日

Apache が....

Apache 1.3.41 で fastcgi を使おうと色々やっていたのだが、mod_fastcgi を組み込もうとするとエラーになる。

 苦労しながら mod_fastcgi のインストール方法を見つけて

 http.conf に

LoadModule fastcgi_module modules/mod_fastcgi.so


 と追加したのだが、

Invalid command 'LoadModule', perhaps mis-spelled or defined by a module not included in the server configuration


 ファイルが見つからないのか?いつものディレクトリ指定の問題か?いや、LoadModule 自体が 'Invalid command' になっている。調べていくうちに
htpd -l
とやって表示される中に mod_so.c が無いことを発見。
 ダイナミックリンクする要のモジュールらしいのだけれど default で入らないの?
 ./configure やら Makefile やらを見ていくと default でリンクされるのかどうも怪しい。
 Makefile を見ると、起動時にモジュールをダイナミックリンクする設定でコンパイルしないと mod_so.c はスタティックリンクしないようなので、apache のドキュメントを見ながらダミーで適当なモジュールをダイナミックリンクするようにオプションをつけて ./configure -> make -> make install。

 'httpd -l' ではしっかり mod_so.c が見えてる。さて、これで...、mod_fastcgi.so が無いって orz。

 ま、一歩前進した。

Django + SQlite:samba とは相性が悪いらしい

 開発用サーバーの python を 2.6.2 から xrea と同じ 2.4(.41) にバージョンダウンしようとしたのだが、うかつなことをして泥沼に嵌ると何をしているのかわからなくなるのでまずは default で入っていると python で Django を動かすことにした。

 Windows 環境で動いていた Djnago をインストールして Windows で動いていたプロジェクトを動かしたところ、まずは Django のエラーが出た。

 ここまでは OK。

 データベースにアクセスしようとすると...、エラー。python のバージョンダウンをしようとして必要なファイルを無くしてしまったか...。

 色々調べていくと、samba 経由でデータベースのファイルにアクセスしたのが原因らしい
 データベースをローカルファイルに移動して、動くようになった。

 どこに地雷があるやら...。

2010年1月2日土曜日

Apache 1.3.41 coLinux + ubuntu 9.1 でコンパイル成功

 $(SRCDIR)/apaci で検索をかけたらこちらのページがヒット。上から4番目のメッセージのとおり修正したらあっさりコンパイル成功。

 シェルが違うとか、そういう話はどこかで読んだいたのだが...。

Django coLinux に apache 1.3.41がインストールできない

 xrea と同じ apache のバージョン 1.3(.41) をインストールしようとするがうまくいかない。

 apt-get からは apache 2 しかないのでソースを取ってきてコンパイル衣装としたのだが ./configure で失敗する。
Creating Configuration.apaci in src
Syntax error --- The configuration file is used only to
define the list of included modules or to set Makefile in src
options or Configure rules, and I don't see that at all:
`$(SRCDIR)/apaci`
 というエラーなのだがなんともうまくいかない。
 続きは明日だ。

2010年1月1日金曜日

Django デブロイ用サーバー起動

 デブロイテスト用に coLinux をインストールしたのだが、やっと動いた。

 coLinux インストール ->
 ネットワーク設定にてこずる(最初ルーター接続にしてしまった。使っている有線ルーターに LAN 側のゲートウェー設定が無いので coLinux から外に出られず)->
 NAT 接続で coLinux をネットワーク設定。->
 apt-get で samba をインストールしようとしたが、ファイルが 404 で見つからないといわれ失敗。->
 imagefile を ubuntu の 7.1 -> 9.1 に変更して apt-get が使えるようになる。(rpm ファイルを探す、という手が使えないのが良いのか悪いのだか)->
 smbclient で Windows のファイルシステムにアクセスしようとしたが smbclient パッケージに smbmount がなかった。エイ・ヤーと smbfs をインストールしたらあった。->

 ようやく apache のインストールが始められそう。先は長いかも。

Django デブロイ開始

 Django のアプリケーションが形になったので、デブロイ開始。

 開発用サーバーを用意する必要があるのだが...、古いパソコンは何台もあるし Linux をインストールしてあるのも 1-2台あるのだが、バージョンが古そうなのと、ネットワーク設定や置き場所、電源の用意を考えると面倒なので、coLinux をメインマシンにインストールすることにする。

 以前、どこかの CPU ボードのクロス開発環境に付属していた coLinxu はえらく簡単にインストールできたのだが、素の coLinux を使えるようにするのはなかなか面倒。主にこちらのページの情報で乗り切る。

 image は ubuntu を選んだ。debian 系は初めてだが...、それもまた面白い (^^;