web-dev-qa-db-ja.com

Nginxエラー：（13：許可が拒否されました）アップストリームへの接続中

nginx-error.logファイルでこのエラーが発生しています：

2014/02/17 03:42:20 [crit] 5455#0: *1 connect() to unix:/tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: xx.xx.x.xxx, server: localhost, request: "GET /users HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", Host: "EC2.amazonaws.com"

ブラウザには、502 Bad Gateway Errorも表示されます。 curlの出力は同じ、Bad Gateway html

/tmp/uwsgi.sockの権限を777に変更して修正しようとしましたが、うまくいきませんでした。 www-dataグループにも自分を追加しました（似たような質問がいくつかありました）。また、サイコロはありません。

これが私のnginx.confファイルです：

nginx.conf

worker_processes 1;
worker_rlimit_nofile 8192;

events {
  worker_connections  3000; 
}

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on; 
    #tcp_nopush     on; 

    keepalive_timeout  65; 

    #gzip  on; 

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

私はFlaskアプリケーションをNginsxとUwsgiで実行していますが、説明を徹底するためです。アイデアがあれば、本当に感謝します。

[〜＃〜] edit [〜＃〜]

Uwsgi構成ファイルを提供するように求められました。だから、私は個人的にnginxやuwsgiファイルを書いたことはありません。 ansible-playbookを使用してすべてを設定するガイド here に従いました。 nginx.confファイルは自動的に生成されましたが、/etc/uwsgiフォルダーとapps-enabledフォルダーの両方にあるREADMEファイルを除いて、apps-availableには何もありませんでした。 uwsgi用の独自の設定ファイルを作成する必要がありますか？ ansibleがそれらすべてのことを処理してくれたという印象を受けました。

このコマンドを実行したときから、ansible-playbookが私のuwsgi設定を見つけたと思います

uwsgi -s /tmp/uwsgi.sock -w my_app:app

起動し、これを出力します：

*** Starting uWSGI 2.0.1 (64bit) on [Mon Feb 17 20:03:08 2014] ***
compiled with version: 4.7.3 on 10 February 2014 18:26:16
os: Linux-3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014
nodename: ip-10-9-xxx-xxx
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/username/Project
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4548
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.7.5+ (default, Sep 19 2013, 13:52:09)  [GCC 4.8.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1f60260
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1f60260 pid: 26790 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 26790, cores: 1)
nginxflaskuwsgiansible-playbook
38
Alex Chumbley

Uwsgiが/tmp/uwsgi.sockの所有権とパーミッションを755にリセットし、ユーザーがuwsgiを起動するたびにuwsgiを実行するため、パーミッションの問題が発生します。

問題を解決する正しい方法は、nginxがこのソケットに書き込むことができるように、uwsgiに/tmp/uwsgi.sockの所有権や許可を変更させることです。したがって、3つの解決策があります。

  1. Www-dataユーザーとしてuwsgiを実行して、このユーザーが作成したソケットファイルを所有するようにします。

    uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data

  2. ソケットファイルの所有権を変更して、www-dataが所有するようにします。

    uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data

  3. ソケットファイルのアクセス許可を変更して、www-dataが書き込みできるようにします。

    uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666

Uwsgiをrootとして実行したままにしないため、最初のアプローチが好まれます。

最初の2つのコマンドは、rootユーザーとして実行する必要があります。 3番目のコマンドは、rootユーザーとして実行する必要はありません。

最初のコマンドは、uwsgiをwww-dataユーザーとして実行したままにします。 2番目と3番目のコマンドは、コマンドを実行した実際のユーザーとしてuwsgiを実行したままにします。

最初と2番目のコマンドでは、www-dataユーザーのみがソケットに書き込むことができます。 3番目のコマンドは、すべてのユーザーがソケットに書き込むことを許可します。

Uwsgiをrootユーザーとして実行したままにせず、ソケットファイルを誰でも書き込み可能にしないため、私は最初のアプローチを好みます。

48
Susam Pal

受け入れられている解決策は真実ですが、SELinuxがアクセスをブロックしている可能性もあります。許可を正しく設定しても、許可拒否メッセージが表示される場合：

Sudo setenforce Permissive

動作する場合、SELinuxに問題があります-または、期待どおりに動作していました！ nginxに必要な許可を追加するには：

  # to see what permissions are needed.
Sudo grep nginx /var/log/audit/audit.log | audit2allow
  # to create a nginx.pp policy file
Sudo grep nginx /var/log/audit/audit.log | audit2allow -M nginx
  # to apply the new policy
Sudo semodule -i nginx.pp

その後、SELinuxポリシーをEnforcingにリセットします：

Sudo setenforce Enforcing
7
enaut

UWSGI構成でこれらのアクセス許可（chmod/chown）を設定する必要があります。

chmod-socket そしてその chown-socket。

http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-sockethttp://uwsgi-docs.readthedocs.org/en/latest/ Options.html＃chown-socket

2
iurisilvio

私の場合、いくつかのPHPのアクセス許可を変更すると、トリックを行う

Sudo chown user:group -R /run/php

これが誰かの助けになることを願っています。

0
Florin

私はそれが遅すぎることを知っていますが、それは他の人に役立つかもしれません。 Running flask with virtualenv、uwsgi、and nginx 非常にシンプルで甘いドキュメントに従うことをお勧めします。

Virtualenvでプロジェクトを実行する場合は、環境をアクティブにする必要があります。

ここにyolo.py

from config import application

if __== "__main__":
    application.run(Host='127.0.0.1')

/ tmp /ディレクトリにuwsgi.sockファイルを作成し、空白のままにします。 @susanpalの回答では、「uwsgiが/tmp/uwsgi.sockの所有権とアクセス許可を755にリセットし、ユーザーがuwsgiを起動するたびに実行するため、アクセス許可の問題が発生します。」正しい。

そのため、uwsgiが起動するたびにファイルをsockする許可を与える必要があります。以下のコマンドに従ってください

uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666

@susanpalとは少し異なるコマンド。また、persist connectionの場合は、単に「＆」コマンドを追加します

uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
0
Mitul Shah