CentOS 7.4 Apache Python 連携時につまづいたところ


VPS の 移行時に、Apache Python 連携時 に 幾つかエラーが出てハマりましたので、備忘として対処法を記載します。


前提

OS、Apache、Python の Version は以下の通りです。

  • OS

    cat /etc/redhat-release 
    CentOS Linux release 7.4.1708 (Core)
    

  • Apache の Version

    apachectl -v
    Server version: Apache/2.4.29 (CentOS)
    Server built:   Oct 23 2017 14:34:32
    

  • Python の Version

    python3.6 -V
    Python 3.6.4
    


サーバ起動時に、bad group name xxxxxxxx が発生する

wsgi の設定を wsgi.conf にまとめ、作成後に Apache を起動したところ、以下のエラーが発生しました。

httpd[20990]: AH00544: httpd: bad group name xxxxxxxx
systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start The Apache HTTP Server.

これは、wsgi.conf 内に記載した WSGIDaemonProcess の group 名が存在しない group であるため、発生していました。
以下記載内容になります。

WSGIDaemonProcess name user=user_name group=group_name python-path=/usr/lib64/python3.6/site-packages

対象のグループを作成していなかったため、グループの追加、対象グループへ所属させるユーザの所属グループを変更を実施しました。

# グループを追加
groupadd group_name
# 対象ユーザーを group を設定する
usermod -g group_name user_name

Linux コマンドは以下の記事を参考にしました。
* Linux ユーザ情報の変更 - usermod


WSGI process group not yet configured.

グループ設定後に Apache を再起動すると以下のエラーが発生しました。

AH00526: Syntax error on line 10 of /etc/httpd/conf.d/wsgi.conf:
WSGI process group not yet configured.
httpd.service: main process exited, code=exited, status=1/FAILURE

これは、WSGIScriptAliasWSGIDaemonProcess よりの先に定義されていたため、発生していました。

WSGIScriptAlias / /var/www/wsgi.py process-group=group_name application-group=%{GLOBAL}
WSGIDaemonProcess name user=user_name group=group_name python-path=/usr/lib64/python3.6/site-packages

WSGIScriptAlias の定義を WSGIDaemonProcess の下へ移動しました。

WSGIDaemonProcess name user=user_name group=group_name python-path=/usr/lib64/python3.6/site-packages
WSGIScriptAlias / /var/www/wsgi.py process-group=group_name application-group=%{GLOBAL}


全角を含む URL のページ表示時に UnicodeEncodeError が発生する

全角を含む URL のページを表示すると以下のエラーが発生していました。

return origin.loader.get_contents(origin)
File "/usr/lib64/python3.6/site-packages/django/template/loaders/filesystem.py", line 24, in get_contents
with io.open(origin.name, encoding=self.engine.file_charset) as fp:
UnicodeEncodeError: 'ascii' codec can't encode character '\\u306b' in position 62: ordinal not in range(128)
最初は、DB に登録した文字列の問題かと思いましたが、調べていくと、Apache、WSGI の LANG の設定で発生することがわかりました。
Apache 経由で実行される Python の LANG 設定は、WSGIDaemonProcess で指定しているユーザの LANG 設定に従います。
ユーザの LANG 設定はあくまで、デフォルトの LANG 指定となり、ユーザの .bashrc で指定している LANG 設定で動作するわけではありません。

デフォルトの LANG 設定を変更するには、WSGIDaemonProcess に、lang パラメータを指定します。

WSGIDaemonProcess name user=user_name group=group_name python-path=/usr/lib64/python3.6/site-packages lang=ja_JP.utf8

または、/etc/sysconfig/httpd に LANG を 追加することでも指定ができます。

LANG='ja_JP.UTF-8'
これは、Apache ユーザ以外のユーザの場合に必要な設定で、Apache ユーザの場合は、HTTPD_LANG を指定することで、LANG 設定の変更が可能です。
HTTPD_LANG='ja_JP.UTF-8'

WSGIDaemonProcess に指定可能なパラメータは、以下、mod_wsgi のドキュメントが参考になりました。

Apache の 言語コード指定については、以下の記事が参考になりました。


Django を使っている場合、 400 bad request になる場合は、ALLOWED_HOSTS の設定を疑ったほうがいい

Django 、 Apache 、 wsgi を使用していて、サイトアクセス時に、400 bad requestが発生しました。
Apache の設定ファイルの内容を疑ったのですが、最終的な原因は、Django の ALLOWED_HOSTS に、自サイトの設定がないことでした。
settings.pyDEBUG = True の設定があると、このケースの場合は、エラー画面に遷移して、想定されるアクセスならば、ALLOWED_HOSTS に設定を追加したほうがいい旨のエラーメッセージが出力されます。

以下の記事にこのケースについての記載があり、参考になりました。

アプリケーションに特に変更は加えてないのですが、OS や ミドルウェアの変更は都度つまづきがあります。
以上です。

コメント