Ubuntu14.04でDjangoを複数動かす

Apache2.4のVirtualHost、python3.4のvenv、mod_wsgiのdaemon mode、これらを使った。手順というよりも注意点を書き留めておく。

Ubuntu14.04では、python3のvenvが失敗するという情報があったけど、大丈夫だった。venv（もしくはpyvenv）は、「apt-get install python3.4-venv」でインストールしないといけない。
venvが失敗するというのは、ensurepipモジュールが欠けていて、pipがインストールされないとのことだった。その場合に、手動でpipをインストールすれば良いとかいう情報もあった（手動でpipをインストールした場合、apt-getからインストールしたpython3-psycopg2とかpython3-lxmlとかへのパスが通っているのかは謎）。しかし、問題なくvenvを実行できた。

仮想環境をつくるときは、pyvenvではなく、python3 -m venv を呼び出すクセをつけておいた方が良さそう。複数のバージョンのpython3が入っている場合に、どのpython3を使ってvenvを実行するのかで、仮想環境で使うpythonのバージョンを選択できるからだ。pyvenvだとこれができない。

とはいえ、mod_wsgiを動かすpythonのバージョンを細かく指定することは、たぶんできない。だから本番のサーバーではpyvenvを使おうがvenvを使おうが同じことだ。

仮想環境をつくるときは、「python3 -m venv --system-site-packages --symlinks 仮想環境ディレクトリへのパス」という具合にオプションを与えておくと、activateしたときに、mod_wsgiを動かすときに近い環境になるはず。--upgradeを付けとけば、失敗してもやり直せる。（--upgrade なしでもやり直せそう。あと、--symlinks はデフォルト値だから省略していい。）

activateするには、「source 仮想環境ディレクトリへのパス/bin/activate」。 activateした後でsudoすると、環境変数が上書きされてしまうのでやってはいけない。たとえば、activateした後で「sudo pip install django」とやると、デフォルトのpython2のsite-packagesにdjangoがインストールされてしまう。そうならないように「sudo -s」としてから、activateする。で「pip install django」とやれば、仮想環境のsite-packagesにインストールされる。

Apache2.4でBasic認証の設定が効かないで困った

Apache2.4で、Basic認証を設定しようとしたんだけど、普通にアクセスできてしまって困った。Apach2.2では動作していた設定を、ほとんどそのままコピーしたつもりだったのに、何がいけないんだか悩んだ。

Basic認証のために「Require valid-user」と設定したかったのに、「Require all granted」が前の方に書かれていて、これが効いてしまっていたのが原因だった。

Ubuntu Serverでapache2の設定変更が反映されないで困った

Ubuntu Serverでapache2の設定変更が反映されないで困っていた。
a2ensiteやらa2dissiteやらで設定するのに慣れていないため、どこかにミスがあるのだろうと長時間にわたり試行錯誤。

結局のところ、

service apache2 restart

とコマンドを打つところで、sudo を忘れていただけだった。「 * Restarting web server apache2」というメッセージが出るだけだったから、権限で失敗していることに気づかずに、履歴から同じコマンドを叩きまくっていた。

なお、「apachectl restart」なら、「Permission denied」って失敗のメッセージが出る。ただし、このコマンドだと成功したときには何もメッセージが出ないから不安になる。「echo $?」とやって、戻り値が0なら成功、それ以外なら失敗と判断することもできるが。

ApacheのVirtualHostの設定で、ServerNameにもServerAliasにもヒットしない場合

ApacheのVirtualHostの設定で、ServerNameにもServerAliasにもヒットしない場合は、最初に設定されたVirtualHostが使われる。このことは公式ドキュメントにも書いてある。

リクエストが来ると、サーバはまず最初に <NameVirtualHost> にマッチする IP アドレスかどうかをチェックします。マッチすれば マッチした IP アドレスの <VirtualHost> のそれぞれのセクションの中から ServerName か ServerAlias に要求されたホスト名があるか探します。 見つかればそのサーバ用の設定を使います。マッチするバーチャルホストが見つからなければ、マッチした IP アドレスの リストの最初にあるバーチャルホスト が使われます。

 思ったように動いてくれないと思ったら、設定ミスってて
「見つからない場合は、リストの最初にバーチャルホストが使われる」っていうルルールが効いていた。

あと、複数のDjangoをVirtualHostを使って動かす場合は、mod_wsgiで、daemon modeってやつにしないといけない。これの設定がちょっと大変。

Apacheのログに処理時間を残す

Apacheのaccess_logに、レスポンスを返すまでの処理時間が記録されるようにするには、httpd.confの設定を少し変更すればよい。
LogFormatで、「%D」と指定することによって、処理時間がマイクロ秒単位で記録される。
Linuxの場合は、
　　# vi /etc/httpd/conf/httpd.conf
とやって、

　　LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" combined

と書く。httpd.confの前後の部分も抜粋すると次のようになる：

# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

# "combinedio" includes actual counts of actual bytes received (%I) and sent (%O); this
# requires the mod_logio module to be loaded.
#LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio