Quijost

Por favor ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Búsqueda Avanzada  

Noticias:

Quijost.com - Hosting Gratis al alcance de tus manos

Autor Tema: Problema con los "staticfiles" en django  (Leído 16953 veces)

0 Usuarios y 1 Visitante están viendo este tema.

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Problema con los "staticfiles" en django
« en: Julio 24, 2011, 12:03:12 pm »

Hola,

Estoy tratando de poner en marcha un django-cms, hasta ahora todo está correcto, salvo por los ficheros "static", utilizo "django-staticfiles" y en principio, lo relativo a la configuración del módulo es correcto, lanzas el comando:
Código: [Seleccionar]
python manage.py collectstatic Este te recoge los archivos de las rutas configuradas y los pone en el path correspondiente, en mi caso:
Código: [Seleccionar]
/home/slothy/public_html/diezmiluji/static/mediaQue es donde en teoría buscará los archivos, ahora bien estoy recibiendo, un "301 MOVED PERMANENTLY"...
Sospecho que el problema está en mi configuración de .htaccess:
Código: [Seleccionar]
SetHandler wsgi-script

RewriteEngine On

# RewriteLog "/home/slothy/logs/rewrite.log"
# RewriteLogLevel 4

# RewriteBase /static
RewriteRule ^(media/.*)$ - [L]
RewriteRule ^(admin/.*)$ - [L]
RewriteRule ^(static/.*)$ - [L]
# RewriteRule ^(static/.*)$ static/$1 [L]
RewriteCond %{REQUEST_URI} !(diezmiluji.wsgi)
RewriteRule ^(.*)$ diezmiluji.wsgi/$1 [L]

En la documentación de Django y mod_wsgi recomiendan crear un Alias a los archivos ej:
Código: [Seleccionar]
Alias /static/ /usr/local/wsgi/static/

<Directory /usr/local/wsgi/static>
Order deny,allow
Allow from all
</Directory>

Pero teóricamente el acceso a esos directorios lo permite las "Rules" de mi .htacces, aunque el problema podría estar tambien en la configuracióin de mi urls.py...

¿Alguien me puede arrojar un poco luz?

Gracias.
En línea

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Re:Problema con los "staticfiles" en django
« Respuesta #1 en: Julio 25, 2011, 13:55:19 pm »

Solucionado!

Aunque no de la manera que esperaba, creando un nuevo directorio accesible desde fuera, ../public_html/static
Y configurando staticfiles para que deje allí los ficheros.

En línea

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Re:Problema con los "staticfiles" en django
« Respuesta #2 en: Julio 25, 2011, 16:01:19 pm »

...ya me respondo yo... [Errno 13] Permission denied:...parece ser que el proceso python que corre como apache, no tiene permisos de escritura...
En línea

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Re:Problema con los "staticfiles" en django
« Respuesta #3 en: Julio 25, 2011, 20:55:48 pm »

Tengo 2 errores ahora mismo con las pruebas utilizando virtualenv...

1-> Acceso a los staticfiles

Esto parece provenir de una mala configuración en mi .htaccess:

Código: [Seleccionar]
SetHandler wsgi-script
RewriteEngine on

RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

Ya que cuando cambio la configuración en setting.py y hago recoger los staticfiles (imagenes/js/css) y la hago apuntar a un directorio fuere del directorio base donde se aloja el proyecto, no hay problema en recogerlas, sin embargo cuando está detrás parece que el sólo responde el script python.

Código: [Seleccionar]
../public_html/proyectodjango/static/... -> 404

../public_html/proyecto_django/
../public_htm l/static/ -> Bien

 A lo que viene mi segundo problema:

2 -> Escritura de ficheros:

Cuando la estructura de staticfiles apunta al ..public_html/static/
Si intento subir un archivo, a través de la aplicación, pej: imageField me da "IOError: [Errno 13] Permission denied:", no puede escribir, lo que parece ser que el interprete de python se ejecuta con los permisos del "nobody" del apache del servidor, con lo que no tengo permisos de escritura...ni ahí, ni en el directorio del proyecto...

Tan sólo me queda probar una instalación limpia, toda totalmente bajo ../public_html/proyecto sin utilizar virtualenv utilizando únicamente las librerías instaladas en el servidor, tal y como comentan aquí, http://quijost.com/foro/desarrollo-web/ejemplo-de-prueba-index-py-para-django-y-mysql-con-mod_wgsi/msg567/#msg567.
Eso y preguntar al resto de usuarios cómo han solucionado el tema de los staticfiles...

¿Sugerencias?

En línea

shakaran

  • Soporte
  • Administrator
  • Usuario profesional
  • *****
  • Karma: +12/-0
  • Desconectado Desconectado
  • Sexo: Masculino
  • Mensajes: 487
  • Un buen soporte lo es todo
    • Ver Perfil
    • Shakaran
Re:Problema con los "staticfiles" en django
« Respuesta #4 en: Julio 27, 2011, 21:30:03 pm »

Tengo 2 errores ahora mismo con las pruebas utilizando virtualenv...

1-> Acceso a los staticfiles

Esto parece provenir de una mala configuración en mi .htaccess:

Código: [Seleccionar]
SetHandler wsgi-script
RewriteEngine on

RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

Ya que cuando cambio la configuración en setting.py y hago recoger los staticfiles (imagenes/js/css) y la hago apuntar a un directorio fuere del directorio base donde se aloja el proyecto, no hay problema en recogerlas, sin embargo cuando está detrás parece que el sólo responde el script python.

Código: [Seleccionar]
../public_html/proyectodjango/static/... -> 404

../public_html/proyecto_django/
../public_htm l/static/ -> Bien

En el settings.py debes definir el STATIC_URL a donde desees y que este directorio sea existente, por ejemplo:

Código: [Seleccionar]
STATIC_URL = '/static/'

No olvides definir tambien el STATICFILES_DIRS:

Código: [Seleccionar]
STATICFILES_DIRS = (
                    os.path.join(os.path.dirname(__file__), 'static').replace('\\','/'),
)

A lo que viene mi segundo problema:

2 -> Escritura de ficheros:

Cuando la estructura de staticfiles apunta al ..public_html/static/
Si intento subir un archivo, a través de la aplicación, pej: imageField me da "IOError: [Errno 13] Permission denied:", no puede escribir, lo que parece ser que el interprete de python se ejecuta con los permisos del "nobody" del apache del servidor, con lo que no tengo permisos de escritura...ni ahí, ni en el directorio del proyecto...

Al utilizar virtualenv, el usuario es nobody, por lo que sólo tienes permisos de lectura (y menos en un compartido podrían otorgarse permisos de escritura como nobody,
ya que sino cualquier usuario podría escribir datos en el directorio de usuario de otro usuario que no fuera el mismo).
Con tu usuario no tendrías esos problemas, pero esto es una limitación de virtualenv.
En línea
Ángel Guzmán Maeso
Quijost Founder - Backend Engineer & Main support

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Re:Problema con los "staticfiles" en django
« Respuesta #5 en: Julio 29, 2011, 19:41:02 pm »

Ante todo agradecer la respuesta, y además puntualizar, que es  muy sencillo hacer pruebas y pruebas en tu proyecto local donde puedes hacer mil y una modificaciones como root  sin prácticamente restricciones, pero a la hora de hacerlo en un servicio más critico y además compartido, como este, se tiene que volver enormemente más complejo, el famoso "works on my machine...", como ya digo, mi experiencia con apache es poca, y me encuentro cometiendo errores de novato continuamente, así que de antemano pido disculpas y paciencia con mis errores.


Por otro lado voy a unir los 2 posts que tengo ahora mismo en marcha y que están bastante relacionados, este http://quijost.com/foro/asistencia-al-cliente/permisos-de-escritura-del-proceso-python/ continuo ambos por aquí ya que me parece más apropiado por la temática, y como la cosa es bastante larga, aprovecho para hace un pequeño tuto, con la info que he recopilado en pruebas.


Ahora ya, sigo...
Tengo 2 errores ahora mismo con las pruebas utilizando virtualenv...

1-> Acceso a los staticfiles

Esto parece provenir de una mala configuración en mi .htaccess:

Código: [Seleccionar]
SetHandler wsgi-script
RewriteEngine on

RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

Ya que cuando cambio la configuración en setting.py y hago recoger los staticfiles (imagenes/js/css) y la hago apuntar a un directorio fuere del directorio base donde se aloja el proyecto, no hay problema en recogerlas, sin embargo cuando está detrás parece que el sólo responde el script python.

Código: [Seleccionar]
../public_html/proyectodjango/static/... -> 404

../public_html/proyecto_django/
../public_htm l/static/ -> Bien

En el settings.py debes definir el STATIC_URL a donde desees y que este directorio sea existente, por ejemplo:

Código: [Seleccionar]
STATIC_URL = '/static/'

No olvides definir tambien el STATICFILES_DIRS:

Código: [Seleccionar]
STATICFILES_DIRS = (
                    os.path.join(os.path.dirname(__file__), 'static').replace('\\','/'),
)

A lo que viene mi segundo problema:

2 -> Escritura de ficheros:

Cuando la estructura de staticfiles apunta al ..public_html/static/
Si intento subir un archivo, a través de la aplicación, pej: imageField me da "IOError: [Errno 13] Permission denied:", no puede escribir, lo que parece ser que el interprete de python se ejecuta con los permisos del "nobody" del apache del servidor, con lo que no tengo permisos de escritura...ni ahí, ni en el directorio del proyecto...

Al utilizar virtualenv, el usuario es nobody, por lo que sólo tienes permisos de lectura (y menos en un compartido podrían otorgarse permisos de escritura como nobody,
ya que sino cualquier usuario podría escribir datos en el directorio de usuario de otro usuario que no fuera el mismo).
Con tu usuario no tendrías esos problemas, pero esto es una limitación de virtualenv.


En un compartido, para ejecutar WGSI debemos hacerlo con nobody. De otra forma, seria asignar un proceso WGSI por cada usuario del servidor compartido y
mantenerlo en memoria, lo que es elevado y costoso. Si tienes mayores necesidades, tal vez te conviene un VPS (http://quijost.com/vps/)

Por otro lado, acabamos de instalar Paste 1.7.5.1 en el server1 por defecto.

Para hacer las pruebas, pongo en marcha 2 subdominios, http://pythonvirtualenv.slothy.quijost.com/ & http://pythonsistema.slothy.quijost.com/, como su nombre indica, uno hará uso de las LIBRERIAS de un virtualenv y el otro de las de la instalación del sistema.

La estructura de directorios será la siguiente:
/home/usuario/public_html/pythonvirtualenv
--> .htaccess
--> app.wsgi
------------------------------------------------------
/home/usuario/public_html/pythonsistema
--> .htaccess
--> app.wsgi

Además en cada uno de los directorios creo otro subdirectorio imagenes donde meto una imagen

El contenido del .htaccess es para pythonvirtualenv, el siguiente:
Código: [Seleccionar]
## PYTHONVIRTUALENV
Options +Indexes

SetHandler wsgi-script

RewriteEngine On

RewriteRule  ^(imagenes/.+)$ - [L]

RewriteCond %{REQUEST_URI} !(app.wsgi)
RewriteRule ^(.*)$ app.wsgi/$1 [L]

Para pythonsistema:
Código: [Seleccionar]
## PYTHONSISTEMA
SetHandler wsgi-script

RewriteEngine On

RewriteCond %{REQUEST_URI} !(app.wsgi)
RewriteRule ^(.*)$ app.wsgi/$1 [L]

Ahora, sobre este .htaccess y las directivas del mod_rewrite que tiene, tengo bastantes dudas que sea lo más correcto para servir ficheros que estén detrás del .wsgi, aquí aún estoy leyendo documentación al respecto.

Teóricamente una petición a http://pythonsistema.slothy.quijost.com/imagenes/Seta_de_la_muerte.png, será interpretada siempre con el app.wsgi, y así es, una petición ahora a http://pythonvirtualenv.slothy.quijost.com/imagenes/Seta_de_la_muerte.png teóricamente debería no ser interpretada por el mod_wsgi y ser servida por apache, de ahí mis dudas respecto a servir los staticfiles, ya que si se meten "detrás" del .wsgi  que lanzaría el django, (no es el caso actual, ya que ahora servimos una app.wsgi con código de pruebas, que más adelante está publicado), cuando django está modo debug = True si está todo bien configurado, (urls.py, abajo muestro el código) los staticfiles, SI se servirán, no siendo así, cuando se supone que la aplicación está lista para "producción" y se pone en modo debug = False, entonces esa url es capturada por el .wsgi y servirá un 500 o un 404. Este es uno de mis errores/dudas, y creo que la solución está en unas reglas del .htaccess bien definidas... Aunque también se puede solucionar sirviendo los "statics" desde otro directorio fuera del path de la aplicación o anterior. Por ejemplo: /home/usuario/public_html/statics/

OJO QUE FALTAN LOS IMPORTS...
urls.py CON staticfiles
Código: [Seleccionar]
if settings.DEBUG:
    urlpatterns += staticfiles_urlpatterns()
urls.py CON appmedia
Código: [Seleccionar]
if settings.DEBUG:
    urlpatterns = patterns('',
        (r'^' + settings.MEDIA_URL.lstrip('/'), include('appmedia.urls')),
    ) + urlpatterns


Otra prueba que he hecho es con el siguiente .htacces, aunque con identicos resultados:
Código: [Seleccionar]
## PYTHONVIRTUALENV
Options +Indexes
SetHandler wsgi-script

RewriteEngine On

RewriteRule  ^(imagenes/.+)$ - [PT,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /app.wsgi/$1 [QSA,PT,L]

Continuemos ahora con el interprete de python:

El contenido de las app.wsgi es una serie de pequeños tests de escritura y variables de configuración para ver que hace mod_wsig y que está ocurriendo cuando la aplicación es interpretada por este, primero pythonsistema:

Código: [Seleccionar]
import os
import sys
import datetime
import string
import random
import pwd
import grp

base = os.path.abspath("/home/slothy/")
rutas = [os.path.join(base,"public_html/pythonsistema/"), os.path.join(base,"public_html/pythonsistema/imagenes/"), os.path.join(base,"prueba_escritura")]
map(lambda x: sys.path.append(x), rutas)
sys.stdout = sys.stderr


def application(environ, start_response):
    status = '200 OK'
    output = 'Pruebas de escritura \n'

    output +="\nTEST_ESCRITURA\n"
    archivo = datetime.datetime.isoformat(datetime.datetime.now(),"-") + ".txt"
    try:
        output += "Directorios de Escritura: \n"
        for direc in rutas:
            output += str(direc) + "\n"
    except Exception as e:
        output += "%s \n" % e
    output += "ARCHIVO: %s \n" % archivo
   
    for test in rutas:
        try:
            fi = open(os.path.join(test,archivo),"w")
            chars = "".join( [random.choice(string.letters[:26]) for i in xrange(15)] )
            fi.write(chars + "\n")
            fi.close()
            output += "Escrito %s \n" % test
        except Exception as e:
            output += "%s %s USER: %s GROUP: %s\n" % (e, test, str(pwd.getpwuid(os.stat(test).st_uid)[0]), str(grp.getgrgid(os.stat(test).st_gid)[0]))
            pass
       
    output += "\nPROCESO PYTHON\nVERSION: %s EJECUTABLE: %s PID: %s USUARIO: %s \n\n SYS_PATH\n" % (str(sys.version), str(sys.executable),str(os.getpid()), str(pwd.getpwuid(os.getuid())[0]))
    try:
        for tup in sys.path:
            output += str(tup) + "\n"
    except Exception as e:
        output += "%s \n" % e

    output += "\n\nENVIRON:\n"
    try:
        for tup in environ.items():
            output += str(tup) + "\n"
    except Exception as e:
        output += "%s \n" % e


    if 'HOME' in os.environ:
            output += "\nHOME declarada en environ: %s" % os.environ['HOME']
    else:
        output += "\nHOME no declarada en environ: %s" % pwd.getpwuid(os.getuid()).pw_dir
       
    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]



from paste.exceptions.errormiddleware import ErrorMiddleware
application = ErrorMiddleware(application, debug=True, show_exceptions_in_wsgi_errors=True)

Primero trata de escribir en un fichero en 3 directorios concretos, en el mismo directorio de app.wsgi, detrás, en imágenesy fuera del document_root. en todos falla, ya que no tiene permisos de escritura.
Después muestra información sobre el interprete python que ejecuta el script, versión, ejecutable, pid y usuario que ejecuta el proceso.
Tras esto imprime el sys.path.
Y por último imprime la variable environ al completo de la específicación wsgi

Ahora lo mismo para la app que corre USANDO LAS LIBRERIAS instaladas en el virtualenv, que no el ejecutable:
Código: [Seleccionar]
VIRTUALENV_DIR = 'pythonvirtualenv'
ALLDIRS = ['/home/slothy/.virtualenvs/pythonvirtualenv/lib/python2.6/site-packages','/home/slothy/.virtualenvs/pythonvirtualenv']

import os
import sys
import datetime
import string
import random
import pwd
import grp

import site



prev_sys_path = list(sys.path)


base = os.path.abspath("/home/slothy/")
rutas = [os.path.join(base,"public_html/pythonvirtualenv/"), os.path.join(base,"public_html/pythonvirtualenv/imagenes/"), \
    os.path.join(base,"prueba_escritura"), os.path.abspath('/home/slothy/.virtualenvs/pythonvirtualenv')]
   
map(lambda x: sys.path.append(x), rutas)
sys.stdout = sys.stderr



for directory in ALLDIRS:
  site.addsitedir(directory)

# Reorder sys.path so new directories at the front.
new_sys_path = []
for item in list(sys.path):
    if item not in prev_sys_path:
        new_sys_path.append(item)
        sys.path.remove(item)
sys.path[:0] = new_sys_path

activate_this = '/home/slothy/.virtualenvs/' + VIRTUALENV_DIR + '/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))

os.environ['PYTHON_EGG_CACHE'] = '/home/slothy/.virtualenvs/' + VIRTUALENV_DIR + '/lib/python2.6/site-packages'

import pytranslate

def application(environ, start_response):
    status = '200 OK'
    output = 'Pruebas de escritura \n'

    output +="\nTEST_ESCRITURA\n"
    archivo = datetime.datetime.isoformat(datetime.datetime.now(),"-") + ".txt"
    try:
        output += "Directorios de Escritura: \n"
        for direc in rutas:
            output += str(direc) + "\n"
    except Exception as e:
        output += "%s \n" % e
    output += "ARCHIVO: %s \n" % archivo

    for test in rutas:
        try:
            fi = open(os.path.join(test,archivo),"w")
            chars = "".join( [random.choice(string.letters[:26]) for i in xrange(15)] )
            fi.write(chars + "\n")
            fi.close()
            output += "Escrito %s \n" % test
        except Exception as e:
            output += "%s %s USER: %s GROUP: %s\n" % (e, test, str(pwd.getpwuid(os.stat(test).st_uid)[0]), str(grp.getgrgid(os.stat(test).st_gid)[0]))
            pass

    output += "\nPROCESO PYTHON\nVERSION: %s EJECUTABLE: %s PID: %s USUARIO: %s \n\n SYS_PATH\n" % (str(sys.version), str(sys.executable),str(os.getpid()), str(pwd.getpwuid(os.getuid())[0]))
    try:
        for tup in sys.path:
            output += str(tup) + "\n"
    except Exception as e:
        output += "%s \n" % e

    output += "\n\nENVIRON:\n"
    try:
        for tup in sorted(environ.items()):
            output += str(tup) + "\n"
    except Exception as e:
        output += "%s \n" % e

    if 'HOME' in os.environ:
            output += "\nHOME declarada en environ: %s" % os.environ['HOME']
    else:
        output += "\nHOME no declarada en environ: %s" % pwd.getpwuid(os.getuid()).pw_dir

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]



from paste.exceptions.errormiddleware import ErrorMiddleware
application = ErrorMiddleware(application, debug=True, show_exceptions_in_wsgi_errors=True)

La diferencia radica en reordenar el sys.path, para que el interprete utilize las librerías del virtualenv, el interprete es el mismo corriendo con los mismos permisos. De cualquier manera, si en lugar de ejecutarse el python del sistema se ejecutase el python del virtualenv, ¿correría con los permisos del usuario?, creo que igualmente no. Esto está sacado de la docu de mod_wsgi

Citar
Defining Process Groups

By default all WSGI applications will run in what is called 'embedded' mode. That is, the applications are run within Python sub interpreters hosted within the Apache child processes. Although this results in the best performance possible, there are a few down sides.

First off, embedded mode is not recommended where you are not adept at tuning Apache. This is because the default MPM settings are never usually suitable for Python web applications, instead being biased towards static file serving and PHP applications. If you run embedded mode without tuning the MPM settings, you can experience problems with memory usage, due to default number of processes being too may, and can also experience load spikes, due to how Apache performs lazy creation of processes to meet demand.

Secondly, embedded mode would not be suitable for shared web hosting environments as all applications run as the same user and through various means could interfere with each other.

Running multiple Python applications within the same process, even if separated into distinct sub interpreters also presents other challenges and problems. These include problems with Python extension modules not being implemented correctly such that they work from a secondary sub interpreter, or when used from multiple sub interpreters at the same time....

Y esto otro:

Citar
Defining Application Groups

By default each WSGI application is placed into its own distinct application group. This means that each application will be given its own distinct Python sub interpreter to run code within. Although this means that applications will be isolated and cannot in general interfere with the Python code components of each other, each will load its own copy of all Python modules it requires into memory. If you have many applications and they use a lot of different Python modules this can result in large process sizes.

To avoid large process sizes, if you know that applications within a directory can safely coexist and run together within the same Python sub interpreter, you can specify that all applications within a certain context should be placed in the same application group. This is indicated by using the WSGIApplicationGroup directive..

Ya por último, una solución "parche"  que he aplicado se crea un directorio, se le dan permisos de escritura a+w, con un script .wsgi se crea la estructura necesaria, dentro de ese directorio, de manera que lo que se cree tiene permisos nobody:nobody, una vez hecho esto, se le devuelven los permisos normales al directorio, y tiene un lugar "semi-privado" donde escribir con python.

Por cierto muchas gracias shakaran por el paste.

Un saludo a todos y disculpad el tostón.
« última modificación: Julio 29, 2011, 19:50:00 pm por slothy »
En línea

shakaran

  • Soporte
  • Administrator
  • Usuario profesional
  • *****
  • Karma: +12/-0
  • Desconectado Desconectado
  • Sexo: Masculino
  • Mensajes: 487
  • Un buen soporte lo es todo
    • Ver Perfil
    • Shakaran
Re:Problema con los "staticfiles" en django
« Respuesta #6 en: Agosto 01, 2011, 01:51:18 am »

El problema con "permission denied" es porque no aplicas la ruta completa en la ubicación del fichero de escritura.

Especificando las rutas completas, no deberías tener problema.

Sobre los static files, depende de como configures el dominio o subdominio, este hará la petición pasando por tu .htaccess y este redireccionara al app.wsgi. Pero esto debes definirlo y actuar conforme sea correcto en el comportamiento que esperas.
En línea
Ángel Guzmán Maeso
Quijost Founder - Backend Engineer & Main support

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Re:Problema con los "staticfiles" en django
« Respuesta #7 en: Agosto 02, 2011, 11:29:49 am »

El problema con "permission denied" es porque no aplicas la ruta completa en la ubicación del fichero de escritura.

Especificando las rutas completas, no deberías tener problema.

No te sigo, ¿te refieres a que intente escribir metiendo la ruta completa? "/home/slothy/public_html/pythonsistema/"
Adapto los app.wsgi para probar:

Código: [Seleccionar]
try:
        fi = open("/home/slothy/public_html/pythonsistema/pruebaescritura.txt","w")
        chars = "".join( [random.choice(string.letters[:26]) for i in xrange(15)] )
        fi.write(chars + "\n")
        fi.close()
        output += "RUTA_COMPLETA:\nEscrito %s \n" % test
    except:
        output += "RUTA_COMPLETA:\n%s %s USER: %s GROUP: %s\n" % (e, "/home/slothy/public_html/pythonsistema/",str(pwd.getpwuid(os.stat("/home/slothy/public_html/pythonsistema/").st_uid)[0]), str(grp.getgrgid(os.stat("/home/slothy/public_html/pythonsistema/").st_gid)[0]))

La salida:
Código: [Seleccionar]
RUTA_COMPLETA:
[Errno 13] Permission denied: '/home/slothy/public_html/pythonsistema/imagenes/2011-08-02-11:09:36.467874.txt' /home/slothy/public_html/pythonsistema/ USER: slothy GROUP: slothy

PROCESO PYTHON
VERSION: 2.6.5 (r265:79063, Feb 28 2011, 21:55:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] EJECUTABLE: /usr/bin/python PID: 13263 USUARIO: nobody

El proceso como comentaste es "nobody" por lo que no tiene permisos de escritura.

Por lo que he estado leyendo, parece que el único modo es que el mod_wsgi esté en modo "daemon" y definiendo grupos de procesos.

Sobre los static files, depende de como configures el dominio o subdominio, este hará la petición pasando por tu .htaccess y este redireccionara al app.wsgi. Pero esto debes definirlo y actuar conforme sea correcto en el comportamiento que esperas.

El .htaccess está sacado del tuto del foro, http://quijost.com/foro/desarrollo-web/ejemplo-de-prueba-index-py-para-django-y-mysql-con-mod_wgsi/
De todas formas tienes razón, se puede solucionar sin tener que pasar por el .htacces, sacando los statics a servir fuera del subdirectorio del .wsgi, aunque seguiré probando ;)

Un saludo!
En línea

slothy

  • Usuario nuevo
  • *
  • Karma: +1/-0
  • Desconectado Desconectado
  • Mensajes: 10
    • Ver Perfil
Re:Problema con los "staticfiles" en django
« Respuesta #8 en: Agosto 04, 2011, 19:45:37 pm »

...

1-> Acceso a los staticfiles

Esto parece provenir de una mala configuración en mi .htaccess:

Código: [Seleccionar]
SetHandler wsgi-script
RewriteEngine on

RewriteCond %{REQUEST_URI} !(django.wsgi)
RewriteRule ^(.*)$ django.wsgi/$1 [L]

La sutil diferencia entre SetHandler y AddHandler ... http://httpd.apache.org/docs/2.1/mod/core.html#sethandler...!SOLUCIONADO! Sabía que tenía que estar la cosa en el .htaccess
En línea
 

Página generada en 0.161 segundos con 24 consultas.