Django mod_wsgi apache

Cuando intento visitar mi sitio de Django en http://www.satoshi.example.com/mysite obtengo un 503 Service Temporary Unavailable.Django mod_wsgi apache

El registro de errores de Apache dice

[Tue Feb 28 07:11:09 2012] [error] [client 10.0.0.202] (13)Permission denied: mod_wsgi (pid=4756): Unable to connect to WSGI daemon process 'django' on '/etc/httpd/logs/wsgi.17555.4.1.sock' after multiple attempts.

Apache carga adecuadamente mod_wsgi

[email protected]:~/html/mysite# apachectl -M | grep wsgi 
wsgi_module (shared) 
Syntax OK

cargas Apache /var/www/html/mysite/apache/apache_django_wsgi.conf que es

WSGIDaemonProcess django 
WSGIProcessGroup django 

<Directory "/var/www/html/mysite"> 
Order allow,deny 
Options Indexes 
Allow from all 
IndexOptions FancyIndexing 
</Directory> 

WSGIScriptAlias /mysite "/var/www/html/mysite/apache/django.wsgi" 

<Directory "/var/www/html/mysite/apache"> 
Order deny,allow 
Allow from all 
</Directory>

esta es la /var/www/html/mysite/apache/django.wsgi

import os 
import sys 

paths = [ '/var/www/html/mysite', 
      '/usr/lib/python2.6/site-packages/', 
] 

for path in paths: 
    if path not in sys.path: 
     sys.path.append(path) 

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 

import django.core.handlers.wsgi 
application = django.core.handlers.wsgi.WSGIHandler()

Una cosa rara es que descubrí que ni siquiera necesito LoadModule wsgi_module modules/mod_wsgi.so en mi propia httpd.conf. Creo que mi httpd.conf es una extensión de otra configuración que ya cargó mod_wsgi. No estoy seguro si esto importa.

¿Hay algo de malo con lo que proporcioné hasta ahora? Déjeme saber si usted necesita más información. ¡Gracias por adelantado!

============================================== =======

información solicitada por

[email protected]:/var/www/html# ps aux | grep apache 
root  4564 0.0 0.2 207636 5432 pts/9 S+ 04:16 0:00 vi apache_django_wsgi.conf 
apache 6006 0.0 0.7 365140 14820 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6007 0.0 0.7 365140 14884 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6008 0.0 0.7 365140 14888 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6009 0.0 0.7 365140 14884 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6010 0.0 0.7 365008 14784 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6011 0.0 0.7 365008 14768 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6012 0.0 0.7 365008 14748 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6013 0.0 0.7 365140 14876 ?  S 09:53 0:00 /usr/sbin/httpd 
apache 6112 0.0 0.7 365008 14756 ?  S 10:05 0:00 /usr/sbin/httpd 
root  6116 0.0 0.2 207700 5492 pts/15 S+ 10:06 0:00 vi ../apache/django.wsgi 
apache 6181 0.0 1.5 713972 32136 ?  Sl 10:08 0:00 /usr/sbin/httpd 
root  8173 0.0 0.0 103300 848 pts/17 S+ 23:39 0:00 grep --color=auto apache

información del usuario @jpic (Quiso decir id? userid no fue encontrado)

[email protected]:/var/www/html# id apache 
uid=48(apache) gid=48(apache) groups=48(apache)

ls -la información

[email protected]:/var/www/html# ls -la /etc/ | grep httpd 
drwxrwxr-x. 4 root 4.0K Feb 16 18:27 httpd/ 

[email protected]:/var/www/html# ls -la /etc/httpd/ 
total 24K 
drwxrwxr-x. 4 root 4.0K Feb 16 18:27 ./ 
drwxr-xr-x. 128 root 12K Feb 28 03:45 ../ 
drwxr-xr-x. 2 root 4.0K Feb 28 08:07 conf/ 
drwxr-xr-x. 2 root 4.0K Feb 16 18:28 conf.d/ 
lrwxrwxrwx 1 root 19 Feb 16 18:27 logs -> ../../var/log/httpd/ 
lrwxrwxrwx 1 root 29 Feb 16 18:27 modules -> ../../usr/lib64/httpd/modules/ 
lrwxrwxrwx 1 root 19 Feb 16 18:27 run -> ../../var/run/httpd/ 

[email protected]:/var/www/html# ls -la /etc/httpd/logs/ 
total 528K 
drwxrwxr-x. 2 root 4.0K Feb 28 09:53 ./ 
drwxr-xr-x. 19 root 4.0K Feb 27 06:51 ../ 
-rw-r--r-- 1 root 17K Feb 28 10:08 access_log 
-rw-r--r-- 1 root 351 Feb 3 10:24 access_log-20120205 
-rw-r--r-- 1 root 1.8K Feb 7 01:39 access_log-20120212 
-rw-r--r-- 1 root 278K Feb 18 23:17 access_log-20120219 
-rw-r--r-- 1 root 85K Feb 22 08:38 access_log-20120226 
-rw-r--r-- 1 root 50K Feb 28 10:08 error_log 
-rw-r--r-- 1 root 14K Feb 5 03:28 error_log-20120205 
-rw-r--r-- 1 root 2.2K Feb 12 03:14 error_log-20120212 
-rw-r--r-- 1 root 9.4K Feb 19 03:28 error_log-20120219 
-rw-r--r-- 1 root 4.0K Feb 26 03:20 error_log-20120226 
-rw-r--r--. 1 root  0 Oct 14 15:14 ssl_access_log 
-rw-r--r-- 1 root 3.1K Feb 28 09:53 ssl_error_log 
-rw-r--r-- 1 root 1.4K Feb 3 03:25 ssl_error_log-20120205 
-rw-r--r-- 1 root 237 Feb 5 03:28 ssl_error_log-20120212 
-rw-r--r-- 1 root 1.2K Feb 17 01:52 ssl_error_log-20120219 
-rw-r--r-- 1 root 237 Feb 19 03:28 ssl_error_log-20120226 
-rw-r--r--. 1 root  0 Oct 14 15:14 ssl_request_log 
srw-rw-rw- 1 apache 0 Feb 28 09:53 wsgi.17555.14.1.sock

Fuente

2012-02-28 hobbes3

+1 por publicar registro de Apache. – jpic

Este problema se documenta en:

http://code.google.com/p/modwsgi/wiki/ConfigurationIssues#Location_Of_UNIX_Sockets

Las soluciones dadas por otros de permisos cambiantes están equivocados.

La solución correcta es cambiar dónde se guardan los archivos de socket en una ubicación donde el usuario de Apache pueda leerlos.

En los sistemas que protegen el directorio de registros, a veces tienen un sistema establecido para reestablecer esos permisos cuando se juega con ellos. Como resultado, cualquier cambio solo puede ser temporal.

Fuente

2012-02-28 21:52:25

mi experiencia es que siempre que establezca la ubicación del socket, siempre tendrá permisos más estrictos (por ejemplo, srwx ------ www-data root) y tendrá que cambiar los permisos del socket. –

No es necesario y no tiene la capacidad de establecer los permisos de socket porque el nombre del archivo de socket cambia dinámicamente a lo largo del tiempo en función del ID del proceso, la generación de la configuración de Apache y la instancia del grupo de procesos del daemon. IOW, no es un nombre inmutable. Mientras el directorio esté accesible para el usuario de Apache, todo funcionará, ya que mod_wsgi asegurará que los archivos de socket reales tengan los permisos correctos. –

@ GrahamDumpleton He cambiado la configuración según el enlace que proporcioné, pero sigo recibiendo el error "No se puede conectar al proceso del daemon de WSGI 'wsgi' en '/var/run/wsgi.12116.0.1.sock' después de varios intentos" – Harshdeep

El usuario que está ejecutando el proceso de apache no parece tener permiso para leer/escribir desde la ubicación especificada.

Por lo general, se aborda configurando las directivas WSGIDaemonProcess y WSGIProcessGroup en VirtualHost conf.

WSGIDaemonProcess process-name user=user group=group threads=10 python-path=vitrual-env-path 
WSGIProcessGroup process-group

Puede también, alternativamente, (a menos que no hay otros problemas de permiso/grupo.) Acaba de agregar la ruta relevante de lectura/escritura accesos al usuario que ejecuta el proceso de apache.

chmod [apache-user]+rw /etc/httpd/logs/

Fuente

2012-02-28 12:59:13

En realidad revisé el archivo de registro wsgi y fue 'srwx ------ 1 apache 0 Feb 28 07:14 wsgi.17555.5.1.sock'. ¿Eso no significa que 'apache' ya tiene permisos de lectura/escritura? – hobbes3

También estoy confundido en su comando 'chmod'. Puede establecer un permiso de archivo para un usuario específico, en este caso 'apache' ?? El usuario y grupo de apache es 'apache' por cierto. No sé cómo averiguar mi entorno python virtual (o si estamos usando uno). – hobbes3

Si no usa virtual-env, puede ignorar esa parte de forma segura. Si no lo sabes, probablemente no lo estés. –

he escrito este guión para manejar toma wsgi problema de permisos en apache2-mpm-ITK

#!/bin/sh 
# This script will fix apache wsgi socket permissions 
# By default use standard socket location /var/run/apache2/wsgi 
# 
# You have to add this script after success execute of start|restart|reload 
# commands in next files: 
# /usr/sbin/apache2ctrl 
# /etc/init.d/apache2 

WSGISocketPrefix="/var/run/apache2/wsgi" 

if [ "$(id -u)" != "0" ]; then 
    echo "This script must be run as root" 1>&2 
    exit 1 
fi 

echo "Wait for other processes to start" 
sleep 1 
echo "Change wsgi socket permissions" 
chmod 0766 ${WSGISocketPrefix}.*

Fuente

2013-01-03 21:10:26 rumatoest

Respuesta

Cuestiones relacionadas