Назад | Перейти на главную страницу

nginx (13: разрешение отказано) на сокете

Я пытаюсь настроить приложение Django с помощью uwsgi и nginx, но все время сталкиваюсь с очень раздражающей проблемой.
Я использовал uwsgi 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: * 1 connect () to unix: /// var / www / [myproject] / [myproject] .sock не удалось (13: Permission denied) при подключении в восходящий поток, клиент: [client-ip], сервер: [server-ip], запрос: «GET / [django-app] / HTTP / 1.1», восходящий поток: «unix: /// var / www / [myproject] /[myproject ].sock: ", host:" [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 пользователь, который является владельцем группы всего моего проекта и который имеет read-execute разрешения, так же как other теперь есть.


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

После нескольких часов боли я нашел решение именно этой проблемы.

Проблем две: 1) права доступа к папке 2) виртуальная среда

Виртуальная среда искажает ваши разрешения и мешает uwsgi правильно создать сокет - просто отключите venv и pip install django и 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

это создает mysite.sock с www-данными владельца, и я больше не получаю ошибку отказа в разрешении.

Надеюсь, это поможет.

-edit- после дополнительного расследования я последовал этот учебник и заставил его работать как службу systemd без каких-либо из этих проблем - я думаю, что в официальном руководстве некоторые вещи принимаются как должное.

Я столкнулся с аналогичной проблемой на основе аналогичного учебника по цифровому океану.

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 также сработает.