Ошибка Nginx: (13: Permission denied) при подключении к восходящему потоку

Я получаю эту ошибку в файле 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. Выходной файл 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, просто чтобы быть подробным в моих объяснениях. Если у кого-то есть какие-то идеи, я бы очень признателен им.

ИЗМЕНИТЬ

Мне было предложено предоставить мой конфигурационный файл uwsgi. Итак, я никогда не писал ни nginx, ни мой файл uwsgi. Я последовал за гидом здесь, который устанавливает все, используя использование загрузочной книги. Файл nginx.conf был сгенерирован автоматически, но в /etc/uwsgi ничего не было, кроме файла README в папках apps-enabled и apps-available. Мне нужно создать собственный файл конфигурации для uwsgi? У меня создалось впечатление, что это все позаботится обо всем этом.

Я считаю, что 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)

Ответ 1

Проблема возникает из-за того, что uwsgi сбрасывает права собственности и разрешения /tmp/uwsgi.sock на 755, а пользователь запускает uwsgi при каждом запуске uwsgi.

Правильный способ решить проблему - заставить uwsgi изменить право собственности и/или разрешение /tmp/uwsgi.sock, чтобы nginx мог писать в этот сокет. Поэтому существует три возможных решения.

Запустите uwsgi в качестве пользователя www-data, чтобы этот пользователь имел файл сокета, созданный им.
```
uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data
```
Измените право собственности на файл сокета, чтобы ему принадлежали www-данные.
```
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data
```
Измените разрешения файла сокета, чтобы www-данные могли его записать.
```
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666
```

Я предпочитаю первый подход, потому что он не оставляет uwsgi запустимым как root.

Первые две команды должны выполняться как пользователь root. Третья команда не должна запускаться как пользователь root.

Первая команда оставляет uwsgi запущенной как пользователь www-data. Вторая и третья команды оставляют uwsgi запущенным как фактический пользователь, который выполнил команду.

Первая и вторая команды позволяют только пользователю www-data записывать в сокет. Третья команда позволяет любому пользователю записывать в сокет.

Я предпочитаю первый подход, потому что он не оставляет uwsgi, запущенного как пользователь root, и он не делает файл сокета доступным для мира.

Ответ 2

Хотя принятое решение верно, 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 на Принудительное с помощью:

sudo setenforce Enforcing

Ответ 3

Вы должны установить эти разрешения (chmod/chown) в конфигурации uWSGI.

Это chmod-socket и chown-socket.

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

Ответ 4

Я знаю это слишком поздно, но это может помочь другим. Я предлагаю следовать Запуск фляги с virtualenv, uwsgi и nginx очень простой и приятной документацией.

Необходимо активировать среду, если вы запускаете проект в virtualenv.

здесь находится yolo.py

from config import application

if __name__ == "__main__":
    application.run(host='127.0.0.1')

Создайте файл uwsgi.sock в каталоге/tmp/и оставьте его пустым. Как @susanpal ответ сказал: "Проблема возникает из-за того, что uwsgi сбрасывает права собственности и разрешения /tmp/uwsgi.sock на 755, а пользователь запускает uwsgi при каждом запуске uwsgi". верно.

Таким образом, вы должны давать разрешение на сбор файлов всякий раз, когда запускается uwsgi. поэтому теперь следуйте приведенной ниже команде

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

Немного отличается от команды @susanpal. И для сохранения соединения просто добавьте конец & "

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

Ответ 5

В моем случае изменение разрешения php делает свое дело

sudo chown user:group -R /run/php

Надеюсь, это кому-нибудь поможет.

Ответ 6

Вы должны опубликовать оба файла конфигурации nginx и uwsgi для вашего приложения (те, что указаны в/etc/nginx/sites-enabled/и/etc/uwsgi/- или там, где вы их разместили).

Обычно проверьте, что в вашей конфигурации приложения nginx есть строка, похожая на следующую:

uwsgi_pass unix:///tmp/uwsgi.sock;

и то же имя сокета в файле конфигурации uwsgi:

socket=/tmp/uwsgi.sock