django - template - (13: permiso denegado) mientras se conecta a la corriente ascendente:

load django template

Question

Estoy trabajando con la configuración del proyecto django con nginx y gunicornio. Mientras estoy accediendo a mi puerto gunicorn mysite.wsgi:application --bind=127.0.0.1:8001 en el servidor nginx recibo el siguiente error en mi archivo de registro de errores.

2014/05/30 11:59:42 [crit] 4075#0: *6 connect() to 127.0.0.1:8001 failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8001/", host: "localhost:8080"

Mi archivo nginx.conf

server {
listen 8080;
server_name localhost;
access_log /var/log/nginx/example.log;
error_log /var/log/nginx/example.error.log;
location / {
proxy_pass http://127.0.0.1:8001;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
}
}

En la página html recibo 502 Bad Gateway .

¿Qué error estoy haciendo?

Answer 1

He resuelto mi problema ejecutando mi nginx como mi usuario actual de trabajo que es mulagala . Por defecto el usuario como nginx en mi nginx.conf nginx.conf. Podemos encontrar esa línea en la parte superior del archivo nginx.conf .

user nginx;

cambie esto a su nombre de usuario de trabajo actual como

user mulagala;

Answer 2

Me he encontrado con este problema también. Estoy usando Nginx con HHVM, la solución a continuación solucionó mi problema:

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/etc/nginx/fastcgi_temp(/.*)?"
sudo restorecon -R -v /etc/nginx/fastcgi_temp

Answer 3

Me he encontrado con este problema también. Otra solución es alternar el valor booleano de SELinux para la conexión de red httpd a on (Nginx usa la etiqueta httpd).

setsebool httpd_can_network_connect on

Para que el cambio persista, use el indicador -P.

setsebool httpd_can_network_connect on -P

Puede ver una lista de todos los booleanos de SELinux disponibles para httpd usando

getsebool -a | grep httpd

Answer 4

Tuve un problema similar al hacer funcionar Fedora 20, Nginx, Node.js y Ghost (blog). Resulta que mi problema fue debido a SELinux .

Esto deberia resolver el problema:

setsebool -P httpd_can_network_connect 1

Detalles

Revisé los errores en los registros de SELinux:

sudo cat /var/log/audit/audit.log | grep nginx | grep denied

Y descubrí que ejecutar los siguientes comandos solucionó mi problema:

sudo cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M mynginx
sudo semodule -i mynginx.pp

Referencias

http://blog.frag-gustav.de/2013/07/21/nginx-selinux-me-mad/

https://wiki.gentoo.org/wiki/SELinux/Tutorials/Where_to_find_SELinux_permission_denial_details

http://wiki.gentoo.org/wiki/SELinux/Tutorials/Managing_network_port_labels

http://www.linuxproblems.org/wiki/Selinux

Answer 5

Tuve un problema similar en Centos 7. Cuando traté de aplicar la solución prescrita por Sorin, comencé a moverme en ciclos. Primero tuve un permiso {escritura} denegado. Luego, cuando resolví que tenía un permiso {connectto} denegado. Luego, vuelva al permiso {write} denied.

Siguiendo la respuesta @Sid anterior para verificar las banderas usando getsebool -a | grep httpd getsebool -a | grep httpd y alternarlos encontré que además de httpd_can_network_connect estaba desactivado. http_anon_write también falló, lo que dio como resultado el permiso denegado de escritura y el permiso denegado {connectto}

type=AVC msg=audit(1501830505.174:799183): avc:
denied { write } for pid=12144 comm="nginx" name="myroject.sock"
dev="dm-2" ino=134718735 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=sock_file

Obtenido usando sudo cat /var/log/audit/audit.log | grep nginx | grep denegado como se explicó anteriormente.

Así que los resolví uno a la vez, alternar las banderas de a una por vez.

setsebool httpd_can_network_connect on -P

Luego ejecuta los comandos especificados por @sorin y @Joseph arriba

sudo cat /var/log/audit/audit.log | grep nginx | grep denied |
audit2allow -M mynginx
sudo semodule -i mynginx.pp

Básicamente puede verificar los permisos establecidos en setsebool y correlacionarlos con el error obtenido de grepp''ing ''audit.log nginx, denied

Answer 6

sudo cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M mynginx
sudo semodule -i mynginx.pp