web-dev-qa-db-ja.com

ソケットのnginx(13:権限が拒否されました)

Djangoアプリをuwsgiとnginxを使用してセットアップしようとしていますが、非常に苛立たしい問題に頭を悩ませ続けています。
リファレンスガイドとして wsgi docs を使用しました。

Uwsgi(uwsgi --http :8000 --module myproject.wsgi)を介してアプリを提供する場合、すべて正常に動作しますが、nginx(uwsgi --ini myproject.ini)を使用してソケットを介して接続し、ブラウザでmyproject.com:8000/<Django-app>を開こうとすると、502エラーが発生しますそして

2018/02/07 08:25:26 [クリティカル] 30339#30339:接続中にunix:/// var/www/[myproject]/[myproject] .sockへの* 1 connect()が失敗しました(13:権限が拒否されました)アップストリームへ、クライアント:[client-ip]、サーバー:[server-ip]、リクエスト: "GET/[Django-app]/HTTP/1.1"、アップストリーム: "unix:/// var/www/[myproject] /[myproject].sock: "、ホスト:" [fqdn]:8000 "

^ [/var/log/nginx/error.log

プロジェクトフォルダーは/var/www/の下にあり、<me>:www-dataが所有し、権限として764を使用しています。すべてのサブフォルダーとファイルは(現在)この所有権とこれらのアクセス許可の下にあります。

Ubuntu 16.04仮想マシン(管理者が管理)ですべてを実行していますが、ユーザーにはSudoアクセス権があります。


明らかなものがないのですか?


更新:
当面の間、otherがソケットに対してread-write権限を持ち、プロジェクトの残りに対してread-execute権限を持っている場合、すべてが機能しています。
そのため、nginxが正しく認識されません...私は再確認しました。nginxは、プロジェクト全体のグループ所有者であるwww-dataユーザーとして実行されており、 otherと同様に、read-execute権限。


myproject_nginx.conf
(このファイルの設定に加えて、user www-data www-data;/etc/nginx/nginx.confに入れました。)

# myproject_nginx.conf

# the upstream component nginx needs to connect to
upstream Django {
    server unix:///var/www/myproject/myproject.sock;
}

# configuration of the server
server {
    # the port your site will be served on
    listen      8000;
    # the domain name it will serve for
    server_name my.ip.goes.here; # substitute your machine's IP address or FQDN
    charset     utf-8;

    # max upload size
    client_max_body_size 75M;   # adjust to taste

    # Django media
    location /media  {
        alias /var/www/myproject/media;  # your Django project's media files - amend as required
    }

    location /static {
        alias /var/www/myproject/static; # your Django project's static files - amend as required

    # Finally, send all non-media requests to the Django server.
    location / {
        uwsgi_pass  Django;
        include     /var/www/myproject/uwsgi_params; # the uwsgi_params file you installed
    }
}

myproject_uwsgi.ini

# myproject_uwsgi.ini file
[uwsgi]

# Django-related settings
# the base directory (full path)
chdir          = /var/www/myproject
# Django's wsgi file
module         = myproject.wsgi
# the virtualenv (full path)
home           = /var/www/myenv

# process-related settings
master         = true
# maximum number of worker processes
processes      = 10
# the socket (full path)
socket         = /var/www/myproject/myproject.sock
# ... with appropriate permissions - may be needed
chmod-socket   = 666
uid            = me
gid            = www-data
# clear environment on exit
vacuum         = true
2
DoTheGenes

数時間の苦痛の後、私はこの正確な問題の解決策を見つけました。

問題は2つです。1)フォルダーのアクセス許可2)仮想環境

仮想環境が許可を乱し、uwsgiがソケットを正しく作成できないようにします-venvを非アクティブ化し、システム全体でpip install Django and uwsgiを無効にします。これをvenv内で解決する方法があるかもしれません。しかし、私は知りません。

次に、Djangoプロジェクトフォルダの権限を777に設定します(またはその所有者をrootに変更します)。

フォルダーにcdし、wsgiコマンドをrootとして実行します。

Sudo uwsgi --socket mysite.sock --module mysite.wsgi --chmod-socket=664 --uid www-data --gid www-data

これにより、所有者www-dataでmysite.sockが作成され、許可拒否エラーが発生しなくなりました。

これがお役に立てば幸いです。

-edit-もう少し調査した後、私は this チュートリアルに従い、これらの問題なしにsystemdサービスとして機能させました-公式チュートリアルは当然のことと思われます。

1

同様のDigital Oceanチュートリアルに基づいて、同様の問題に遭遇しました。

https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-uwsgi-and-nginx-on-ubuntu-16-04#

私のハックはchmod a+rw mysite.sock uwsgiを起動した後。

ただし、--chmod-socket = 666を変更しても機能すると思います。

0
WilderField