nginx (13: Permissão negada) no soquete

Question

Eu estou tentando criar um aplicativo Django usando o uwsgi e o nginx, mas continuo batendo minha cabeça contra um problema muito irritante.
Eu usei os documentos do uwsgi como um guia de referência.

Ao servir o aplicativo através do uwsgi ( uwsgi --http :8000 --module myproject.wsgi ) tudo funciona bem, mas quando eu tento conectar através de um socket com nginx ( uwsgi --ini myproject.ini ) e abra myproject.com:8000/<django-app> no meu navegador eu recebo um erro 502 e

2018/02/07 08:25:26 [crit] 30339#30339: *1 connect() to unix:///var/www/[myproject]/[myproject].sock failed (13: Permission denied) while connecting to upstream, client: [client-ip], server: [server-ip], request: "GET /[django-app]/ HTTP/1.1", upstream: "unix:///var/www/[myproject]/[myproject].sock:", host: "[fqdn]:8000"

este ^ em /var/log/nginx/error.log

A pasta do meu projeto está em /var/www/ , de propriedade de <me>:www-data e com 764 como permissões. Todas as subpastas e arquivos estão (atualmente) sob essa propriedade e com essas permissões.

Estou executando tudo em uma máquina virtual Ubuntu 16.04 (gerenciada pelo meu administrador) e meu usuário tem sudo access.

Eu estou sentindo falta de algo óbvio?

Atualização:
No momento, tudo está funcionando quando other tem read-write permissões no soquete e read-execute permissões no restante do projeto.
Então o nginx não é reconhecido como deveria ... Eu verifiquei duas vezes e o nginx está sendo executado como o usuário www-data , que é o proprietário do grupo de todo o meu projeto e que tem read-execute de permissões, assim como other agora tem.

myproject_nginx.conf
(Além das configurações neste arquivo, coloquei user www-data www-data; em /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

    

Answer 1

Depois de algumas horas de dor, encontrei uma solução para esse problema exato.

Os problemas são dois: 1) as permissões da pasta 2) o ambiente virtual

O ambiente virtual bagunça suas permissões e evita que o uwsgi crie o soquete corretamente - apenas desative o venv e o pip e instale o django e o uwsgi em todo o sistema. Pode haver uma maneira de resolver isso dentro do venv, mas eu não sei de nenhum.

Em seguida, defina as permissões da pasta do seu projeto django para 777 (ou altere seu proprietário para root).

cd na pasta e execute o comando wsgi como root:

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

isso cria mysite.sock com o proprietário www-data e não consigo mais o erro de permissão negada.

Espero que isso ajude.

-edit- depois de mais algumas investigações, eu segui este tutorial e ele funcionou como um serviço systemd sem nenhum desses problemas - eu acho que o tutorial oficial toma algumas coisas como garantidas.