django - postgres - Permiso denegado-socket nginx y uwsgi

nginx reverse proxy django

Question

Bueno, actualmente estoy tratando de obtener mi aplicación django con nginx y uwsgi. Actualmente estoy usando un entorno virtual en el cual uwsgi está instalado. Sin embargo, actualmente estoy obteniendo un error de puerta de enlace 502 cuando intento acceder a la página.

El error que estoy experimentando.

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 es mi 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
    }
}

Aquí está mi archivo uwsgi.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

De lo que he leído en google es un problema de permisos con el grupo www-data y el directorio / tmp /. Sin embargo, soy nuevo en esto y he tratado de cambiar el nivel de permisos de la carpeta sin ningún resultado. ¿Podría alguien señalarme en la dirección correcta? Es este un problema de permisos.

¿También es una buena práctica poner el archivo sock en el directorio tmp?

Gracias

Answer 1

¡Guau, este problema me lleva casi todo un día!

Uso uwsgi 2.0.14, nginx 1.10.1, django 1.10

En resumen, lo más importante es asegurarse de que los dos usuarios de abajo tengan permiso de rwx para el archivo socket :

1. el usuario de nginx ;
2. el usuario de uWSGI ;

Entonces, puedes verificarlos uno por uno.

Primero, puede verificar si el servidor web nginx tiene permiso actualizando la URL, digamos http://192.168.201.210:8024/morning/ , sin ejecutar uwsgi. Si ve /var/log/nginx/error.log No /var/log/nginx/error.log ningún archivo o directorio 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"

Simplemente cree un archivo llamado helloworld.sock , actualice la URL y compruebe el archivo de registro nuevamente, si ve el permiso denegado en el archivo de registro, 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"

Significa que el servidor web nginx no tiene todos los permisos para leer, escribir y ejecutar. Entonces puedes otorgar permiso a este archivo:

sudo chmod 0777 helloworld.sock

Luego, actualice la url y revise el archivo de registro nuevamente, si ve Conexión rechazada en el archivo de registro, así:

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"

Esta es una buena señal, significa que su servidor web nginx tiene permiso para usar el archivo helloworld.sock partir de ahora.

Al lado de ejecutar uwsgi y verificar si el usuario de uwsgi tiene permiso para usar helloworld.sock . En primer lugar, elimine el archivo helloworld.sock que hemos creado anteriormente.

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

Si ve bind (): Permiso denegado [core / socket.c línea 230] , significa que uwsgi no tiene permiso para enlazar helloworld.sock . Este es el problema de la test directorio, el directorio principal de helloworld.sock .

sudo chmod 0777 test/

Ahora, puede ejecutar uwsgi éxito.

Pero tal vez sigas viendo 502 Bad Gateway , es terrible, lo he visto todo el día. Si error.log comprobar el archivo error.log , verá esto de nuevo:

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"

¿Qué pasa ???

Comprueba los detalles del archivo helloworld.sock , puedes ver:

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

uWSGI otorga este permiso al archivo 755 automáticamente.

Puede cambiarlo agregando --chmod-socket :

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

¡DE ACUERDO! Finalmente, puedes ver:

Mensaje de llevar :

1. la ubicación del archivo uwsgi_params no es importante;
2. Dado que mi usuario nginx y usuario uwsgi no son iguales e incluso no están en el mismo grupo, entonces debo dar permiso 777 a helloworld.sock y a su test/ dir principal test/ ;
3. Si coloca el archivo helloworld.sock en su directorio personal, siempre obtendrá el permiso denegado .
4. Hay dos lugares donde debe establecer la ruta del archivo de socket , uno en el archivo nginx conf, para mí es helloworld_nginx.conf ; uno cuando ejecuta uwsgi.
5. Compruebe SELinux

Este es mi archivo helloworld_nginx.conf :

# 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 2

Creo que solo necesita cambiar su archivo de socket a 666 (664 está bien con www-data), o eliminarlo y ejecutar el servidor uwsgi nuevamente.

En mi uwsgi.ini:

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

Answer 3

En CentOS, probé todas esas cosas pero aún así no funcionó. Finalmente, encontré este artículo:

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

Para una máquina de desarrollo, simplemente ejecutamos:

semanage permissive -a httpd_t

Pero para un servidor de producción real, no me he dado cuenta. Es posible que deba probar otras cosas descritas en el artículo anterior.

Answer 4

Este problema me volvió loco. Mi entorno es centos7 + nginx + uwsgi, usando la conexión de socket unix. La respuesta aceptada es asombrosa, solo agrega algunos puntos allí.

ROOT USER, QUICK TEST

Primero, apague selinux, luego cambie chmod-socket a 666, y finalmente inicie uwsgi usando root.

Me gusta esto

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

OTRO USUARIO

Si usa el otro usuario que creó para iniciar uwsgi, asegúrese de que los permisos de la carpeta de usuario en la carpeta de inicio sean 755 y que el propietario y el grupo sean los correspondientes.

Por ejemplo

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 5

Esto me lleva mucho tiempo para encontrar el problema con los permisos. Y el problema es con los permisos, por supuesto. El usuario predeterminado es nginx. Lo que hice: en /etc/nginx/nginx.conf cambio de usuario:

user  www-data;

A continuación, únete a tu usuario en www-data goup:

usermod -a -G www-data yourusername

Siguiente conjunto uwsgi:

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

Y luego reinicie nginx:

sudo systemctl restart nginx

Y finalmente reiniciar uwsgi.

Answer 6

Estuve lidiando con este problema por un tiempo, y descubrí que los indicadores uid y gid de mi archivo uwsgi.ini no se estaban aplicando al archivo .sock

Puedes probar esto ejecutando uwsgi, luego verificando los permisos en tu archivo .sock usando el comando de Linux ls -l .

La solución para mí fue ejecutar uwsgi con sudo:

sudo uwsgi --ini mysite_uwsgi.ini

con el archivo .ini que contiene las banderas:

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

¡Entonces los permisos en el archivo .sock fueron correctos, y el error 502 Bad Gateway finalmente desapareció!

Espero que esto ayude :)

Answer 7

necesitas descomentar

#server 127.0.0.1:8001;

desde el bloque de flujo ascendente y de manera similar hacen los cambios en uwsgi.ini como

socket = 127.0.0.1:8001

Answer 8

uwsgi.ini

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

¿Por qué? Porque a veces la aplicación necesita leer o escribir en el sistema de archivos más allá de lo que está accesible para el servidor web. No quiero cambiar un montón de propiedad y permisos solo para acomodar cada situación. Prefiero que mi aplicación se ejecute como yo y hacer lo que tiene que hacer. Establecer el grupo como www-data y cambiar el socket a 664 le permite a ese grupo escribir en él, proporcionando así la única ventana de comunicación necesaria entre el servidor web y la aplicación.