私のwsgiのiniファイルにuid/gidパラメータを使用してuWsgiを実行しようとしているため、起動後に特権アクセスが破棄されます。pid/gidを使用してuWsgiを実行する問題
注：これらの2つのパラメータをiniファイルから削除すると、すべて正常に動作します。また、ソケットに問題はありません。しかし、私は指定されたuidとgid（nginxのユーザおよびグループ）で実行したとき、私は私の仮想のenv読み込みに問題を持っていることの指標であるエラーを取得し、
Traceback (most recent call last): File "wsgi.py", line 14, in <module> from app import app as application File "/var/www/wsgi/flask-appbuilder/peds_registry/app/__init__.py", line 1, in <module> import logging ImportError: No module named logging再び
、この作品の罰金ときgid/pidなしで実行しています。また、ユーザとグループnginxが存在し、両方ともpythonプロジェクトのディレクトリ構造の所有権を持っていることに注意してください。
次のように私のnginxの設定のサーバー/場所ディレクティブは、次のとおりです。
#!/bin/sh
# chkconfig: - 99 10
FLASK_HOME=/var/www/wsgi/flask-appbuilder
export PEDS_HOME
ACTIVATE_CMD=/var/www/wsgi/flask-appbuilder/venv/bin/activate
case "$1" in
start)
cd $FLASK_HOME
source $ACTIVATE_CMD
uwsgi -s /tmp/uwsgi.sock -H ./venv/ --ini /var/www/wsgi/flask-appbuilder/test.ini --virtualenv /var/www/wsgi/flask-appbuilder/venv --chmod-socket=666 --manage-script-name --mount /test=run:app --wsgi-file wsgi.py --logto test.log &
;;
stop)
pkill uwsgi
;;
restart)
$0 stop
$0 start
;;
*)
echo "usage: $0 (start|stop|restart|help)"
esac
そして、私のuWsgi起動INIは次のとおりです：
server {
listen 80;
server_name hostname.domain;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name hostname.domain;
ssl_certificate /etc/ssl/certs/host.chained.crt;
ssl_certificate_key /etc/ssl/certs/host.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
location /test {
include uwsgi_params;
uwsgi_pass unix:/tmp/uwsgi.sock;
}
}
マイuwsgiの起動がある
[uwsgi]
socket = /tmp/uwsgi.sock
chdir = /var/www/wsgi/flask-appbuilder/peds_registry
wsgi-file = wsgi.py
pyhome = /var/www/wsgi/flask-appbuilder/venv
callable = app
manage-script-name = true
mount: /test=run.py
述べたように、これはgid/uidパラメータなしでうまくロードされますが、追加すると
uid = nginx
gid = nginx
iniファイルには、上記のエラーが表示されます。
私のすべての検索ではソケットのアクセス許可が得られますが、私の問題は仮想環境内からモジュールをロードしているようです。
私は仮想環境にpipからインストールされたuWsgiを使用しています。
あなたのvenv内のすべてのファイルとサブディレクトリ、それにつながっている親ディレクトリへのアクセス権がnginxユーザにあることを確認してください – mata
私は以前、親ディレクトリの下のディレクトリ構造全体に対してchownを行っていました。 –