Permissão negada - nginx e fenix soquete

Question

Bem, eu estou atualmente tentando obter minha aplicação django servido usando o nginx e fenix.Atualmente, estou usando um ambiente virtual para o qual fenix está instalado.No entanto, atualmente, estou recebendo um erro 502 bad gateway de erro quando tentar acessar a página.

O Erro que eu estou enfrentando.

2014/02/27 14:20:48 [crit] 29947#0: *20 connect() to unix:///tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 144.136.65.176, server: domainname.com.au, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "www.domainname.com.au"

Este é o meu nginx.conf

    # mysite_nginx.conf

# the upstream component nginx needs to connect to
upstream django {
    server unix:///tmp/uwsgi.sock; # for a file socket
    #server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}

# configuration of the server
server {
    # the port your site will be served on
    listen      80;
    # the domain name it will serve for
    server_name .domainname.com.au; # 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 /home/deepc/media;  # your Django project's media files - amend as required
    }

    location /static {
        alias /home/deepc/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     /home/deepc/.virtualenvs/dcwebproj/dcweb/uwsgi_params; # the uwsgi_params file you installed
    }
}

Aqui é o meu fenix.arquivo ini

[uwsgi]
socket=/tmp/uwsgi.sock
chmod-socket=644
uid = www-data
gid = www-data

chdir=/home/deepc/.virtualenvs/dcwebproj/dcweb
module=dcweb.wsgi:application
pidfile=/home/deepc/.virtualenvs/dcwebproj/dcweb.pid
vacuum=true

Pelo que tenho lido no google um problema de permissões com o www-data group e /tmp/ diretório.No entanto, eu sou novo para isso e tentei para trocar o nível de permissão de pasta sem sucesso.Alguém poderia me apontar na direção certa?É este um problema de permissões.

Também é ok prática para colocar o meia arquivo no diretório tmp?

Obrigado

Answer 1

Eu acho que você só precisa alterar o seu arquivo de soquete para 666(664 está ok com o www-data), ou removê-lo e executar fenix servidor novamente.

No meu fenix.ini:

chmod-socket = 664
uid = www-data
gid = www-data

Answer 2

Wow, esse problema me leva quase um dia inteiro!

Eu uso uwsgi 2.0.14, nginx 1.10.1, django 1.10

Para resumir, a coisa mais importante é certificar-se de ambos abaixo de dois usuários tem rwx permissão para socket arquivo:

1. o usuário de nginx;
2. o usuário de uWSGI;

Assim, você pode verificá-los um por um.

---

Primeiro, você pode verificar se o servidor web nginx tem permissão de atualizar a url, dizer http://192.168.201.210:8024/morning/, sem a execução de fenix.Se você ver /var/log/nginx/error.log Não existe tal arquivo ou diretório, como este:

2016/10/14 16:53:49 [crit] 17099#0: *19 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Basta criar um arquivo chamado helloworld.sock, e atualize a url e verifique o arquivo de log novamente, se você ver Permissão negada no arquivo de log, como este:

2016/10/14 17:00:45 [crit] 17099#0: *22 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Isso significa servidor web nginx não tem toda a permissão para ler, gravar e executar.Assim, você pode conceder a permissão para este ficheiro:

sudo chmod 0777 helloworld.sock

Em seguida, atualize a url e verifique o arquivo de log novamente, se você ver Conexão recusada no arquivo de log, como este:

2016/10/14 17:09:28 [error] 17099#0: *25 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

Este é um bom sinal, significa que o servidor web nginx tem a permissão para usar helloworld.sock arquivo a partir de agora.

---

Avançar para executar uwsgi e verificar se o usuário do uwsgi tem permissão para usar helloworld.sock.Em primeiro lugar, remova o arquivo helloworld.sock nós criamos antes.

Executar feh: uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py

Se você ver bind():Permissão negada [core/socket.c linha de 230], isso significa uwsgi não tem permissão para ligar helloworld.sock.Este é o problema do diretório test, o diretório pai do helloworld.sock.

sudo chmod 0777 test/

Agora, você pode executar uwsgi bem-sucedido.

Mas talvez você ainda veja 502 Bad Gateway, é terrível, eu a vi o dia todo.Se você verificar error.log arquivo novamente, você vai ver isso de novo:

2016/10/14 17:33:00 [crit] 17099#0: *28 connect() to unix:///usr/share/nginx/html/test/helloworld.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.201.140, server: belter-tuesday.com, request: "GET /morning/ HTTP/1.1", upstream: "uwsgi://unix:///usr/share/nginx/html/test/helloworld.sock:", host: "192.168.201.210:8024"

O que há de errado???

Verifique os detalhes do helloworld.sock arquivo, você pode ver:

srwxr-xr-x. 1 belter mslab       0 Oct 14 17:32 helloworld.sock

uWSGI dá esse arquivo 755 permissão automaticamente.

Você pode alterá-lo adicionando --chmod-socket:

uwsgi --socket /usr/share/nginx/html/test/helloworld.sock --wsgi-file wsgi.py --chmod-socket=777

OK!Finalmente, você pode ver:

---

Levar mensagem:

1. uwsgi_params local do arquivo não é importante;
2. Desde a minha nginx usuário e uwsgi o usuário não mesmo e mesmo que não no mesmo grupo, então eu preciso dar 777 permissão para helloworld.sock e seu pai dir test/;
3. Se você colocar o helloworld.sock arquivo em seu diretório home, você sempre terá Permissão negada.
4. Há dois locais que você precisa para definir o socket caminho do arquivo, uma na nginx conf arquivo, para mim ele é helloworld_nginx.conf;quando você executar o fenix.
5. Verifique O SELinux

Esta é a minha helloworld_nginx.conf arquivo:

# helloworld_nginx.conf
upstream django {
    server unix:///usr/share/nginx/html/test/helloworld.sock; # for a file socket
    # server 127.0.0.1:5902; # for a web port socket (we'll use this first)
}

# configuration of the server
server {
    # the port your site will be served on
    listen      8024;
    # the domain name it will serve for
    server_name .belter-tuesday.com; # substitute your machine's IP address or FQDN
    charset     utf-8;

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

    # Finally, send all non-media requests to the Django server.
    location /morning {
        include     uwsgi_params;
        uwsgi_pass  django;
    }
}

Answer 3

No CentOS, eu tentei de todas essas coisas, mas ainda não funcionou.Finalmente, eu encontrei este artigo:

https://www.nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/

Para uma máquina de desenvolvimento, nós simplesmente execute:

semanage permissive -a httpd_t

Mas, para um verdadeiro servidor de produção, eu ainda não descobri.Você pode precisar de tentar outras coisas descritas no artigo acima.

Answer 4

Esta é me levar muito tempo para encontrar o problema com as permissões.E o problema é com permissões de curso.Usuário padrão é nginx.O que eu fiz:no /etc/nginx/nginx.conf alterar utilizador:

user  www-data;

Próximo junte o usuário www-data goup:

usermod -a -G www-data yourusername

Próximo conjunto feh:

[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 660

E, em seguida, reinicie o nginx:

sudo systemctl restart nginx

E, finalmente, reinicie o fenix.

Answer 5

Eu lidado com este problema por um tempo, e descobriu que a uid e gid bandeiras do meu uwsgi.ini arquivo não estavam sendo aplicados para a .sock arquivo

Você pode testar isso executando fenix, em seguida, verificar as permissões no seu .sock arquivo usando o comando linux ls -l.

A solução, para mim, era para executar uwsgi com o sudo:

sudo uwsgi --ini mysite_uwsgi.ini

com o .ini arquivo que contém as bandeiras:

chmod-socket = 664
uid = www-data
gid = www-data

Em seguida, as permissões no .sock arquivo estavam corretas, e o 502 Bad Gateway erro finalmente desapareceu!

Espero que isso ajude :)

Answer 6

Esse problema fez-me louco.Meu ambiente é centos7+nginx+fenix, usando socket de conexão.Aceito resposta é incrível, basta adicionar alguns pontos de lá.

USUÁRIO RAIZ, TESTE RÁPIDO

Primeiro, desligue o, em seguida, alterar chmod-soquete para 666, e, finalmente, começa a fenix usando raiz.

Como este

setenforce 0 #turn off selinux
chmod-socket = 666
uwsgi --ini uwsgi.ini

DE OUTRO USUÁRIO

Se você usar outro usuário que você criou para iniciar fenix, certifique-se de que as permissões da pasta de usuário na pasta base são 755, e que o dono e grupo são correspondentes.

Por exemplo

chmod-socket = 666
usermod -a -G nginx webuser #add webuser to nginx's group
cd /home/
chmod -R 755 webuser
chown -R webuser:webuser webuser
uwsgi --ini uwsgi.ini --gid webuser --uid webuser

Answer 7

fenix.ini

[uwsgi]
uid = yourusername
gid = www-data
chmod-socket = 664

Por quê?Porque, às vezes, o aplicativo precisa para ler ou gravar no sistema de arquivos além do que é acessível para o servidor web.Eu não quero mudar um monte de propriedade e as permissões apenas para acomodar cada situação.Eu prefiro ter o meu aplicativo execute como eu e fazer o que ele precisa fazer.Definir o grupo como www-data e o comando chmod a tomada 664 permite que o grupo de escrever, fornecendo, assim, o único necessário janela de comunicação entre o servidor web e o aplicativo.

Answer 8

Outro ótimo artigo para CentOS usuários:

https://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/

Embora as respostas são úteis sobre o CentOS, o problema se encontra sob o SELinux.

Eu segui todo o artigo, mas o que resolveu o problema, eu acreditava que os seguintes comandos:

yum install -y policycoreutils-{python,devel}
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp
usermod -a -G user nginx
chmod g+rx /home/user/

Por favor, substitua usuário com seu usuário real para a concessão de permissões.O mesmo se aplica para o diretório sob o comando chmod.

Answer 9

você precisa descomentar

#server 127.0.0.1:8001;

a montante do bloco e, do mesmo modo, faça as alterações no fenix.ini como

socket = 127.0.0.1:8001