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

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Mensajes - slothy

Páginas: [1]
1
Python / Re:Problema con los "staticfiles" en django
« 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

2
Python / Re:Problema con los "staticfiles" en django
« 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!

3
Python / Re:Problema con los "staticfiles" en django
« 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.

4
Asistencia al cliente / Re:Permisos de escritura del proceso python
« en: Julio 26, 2011, 22:50:39 pm »
Este es un script pruebaescritura.wsgi de prueba, cambiad USUARIO Y DIRECTORIO_WEB por el que corresponda:

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

ruta = os.path.abspath("/home/USUARIO/tmp")
sys.path.append('/home/USUARIO/public_html/DIRECTORIO_WEB')
sys.path.append(ruta)
sys.stdout = sys.stderr


def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!\n'

    print >> environ['wsgi.errors'], "application debug #1"


    archivo = datetime.datetime.isoformat(datetime.datetime.now(),"-") + ".txt"
    try:
        output += str(path) + "\n"
    except Exception as e:
        output += "%s \n" % e
    try:
        fi = open(os.path.join(path,archivo),"w")
        chars = "".join( [random.choice(string.letters[:26]) for i in xrange(15)] )
        fi.write(chars + "\n")
        fi.close()
        output += "OK! \n"
    except Exception as e:
        output += "%s \n" % e
   
    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    print >> environ['wsgi.errors'], "application debug #2"

    return [output]

Y aquí el correspondiente .htaccess

Código: [Seleccionar]
Options +Indexes

SetHandler wsgi-script

RewriteEngine On

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


Si se añade el siguiente código nos dará el usuario con el que se ejecuta el script:

Código: [Seleccionar]
import pwd

output += str(pwd.getpwuid(os.getuid())[0]) + "\n"

5
Asistencia al cliente / Permisos de escritura del proceso python
« en: Julio 26, 2011, 20:10:17 pm »
Hola,

Estoy tratando de poner en marcha un django-cms, de momento todo es correcto, salvo la escritura de ficheros. Por lo que he estado investigando, el subinterprete que lanza mod_wsgi, corre con los permisos del usuario apache, nobody, al tratar de realizar cualquier tipo de escritura, obtengo un error, salvo, si doy permisos de escritura a+x, si es un directorio fuera del DOCUMENT_ROOT, no puedo accederlo como URL ..., si está dentro de DROOT, es "escribible" públicamente...por otro lado veo que una posible solución puede ser la escritura en /tmp, pero no se que política hay al respecto, no de escritura, ni de borrado de mantenimiento, y quedan expuestos los ficheros al acceso por parte de los procesos "nobody" del resto de users de la máquina.  La mayor parte de la problemática/solución viene de la configuración de apache de mod_wsgi,http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6 ¿es posible algo en el sentido de modificar la configuración del mod_wsgi? ¿Se me está escapando alguna otra opción?

Como añadido, en el foro se apunta a un howto sobre capturar las excepciones con middleware, en concreto con Paste, pero no está instalado en el sistema, ¿se podría instalar?

Gracias

6
Python / Re:Problema con los "staticfiles" en django
« 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?


7
Python / Re:Problema con los "staticfiles" en django
« 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...

8
Python / Re:Problema con los "staticfiles" en django
« 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.


9
Python / 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.

10
Python / virtualenv & virtualenvwrapper
« en: Julio 23, 2011, 13:01:10 pm »
Hola,

En respuesta y agradecimiento a los usuarios que han publicado guías anteriormente y a los administradores del sistema por su ayuda, voy  a publicar un mini how-to sobre como poner en marcha en una de las cuentas virtual host un sistema de "entornos aislados" para python.

¿Qué conseguimos con esto?, bien, con un poco de configuración podemos conseguir un sistema de librería python totalmente independiente del instalado en el sistema. ¿Por qué?,
puede ser que en un momento dado, necesitemos una versión concreta de una librería para un proyecto en Django, inferior a la versión utilizada en en sistema y un larguísimo etc.

Cuando en un programa python se realiza un "import" en intérprete además de buscar en el directorio local, busca en una variable llamada "PYTHONPATH", en nuestro caso práctico:
Código: [Seleccionar]
[~]# python
Python 2.6.5 (r265:79063, Feb 28 2011, 21:55:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
...

El resultado son las rutas donde el interprete python buscaría módulos.

Ejemplo práctico, modulo "pytranslate", un módulo que utiliza la api de google translate para traducción:
Código: [Seleccionar]
[~]# python
Python 2.6.5 (r265:79063, Feb 28 2011, 21:55:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pytranslate
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named pytranslate

Como vemos el intérprete de python no encuentra el módulo, de momento dejémoslo ahí y cuando hayamos instalado virtualenv volveremos a pytranslate.

virtualenv y virtualenvwrapper


La instalación no puede ser más sencilla...

Código: [Seleccionar]
[~]#pip install --install-option="--user" virtualenvwrapper
La opción
Citar
--install-option="--user"
hará que virtualenv y virtualenvwrapper se instalen en ~/.local

A partir de aquí, creamos un directorio donde almacenaremos nuestro entornos python, por ejemplo "python_envs"

Código: [Seleccionar]
cd
mkdir python_envs
export WORKON_HOME=$HOME/python_envs
source $HOME/.local/bin/virtualenvwrapper.sh

Con export y source estamos indicándole al intérprete de comandos que cree una variable WORK_ON con el path a nuestro contenedor de entornos y que ejecute un script que pone en marcha el sistema
Para que podamos automatizar este proceso editamos nuestro .bashrc, e incluimos a final:

Código: [Seleccionar]
export WORKON_HOME=$HOME/python_envs
export VIRTUALENVWRAPPER_VIRTUALENV=$HOME/.local/bin/virtualenv
source $HOME/.local/bin/virtualenvwrapper.sh
 

Ahora podemos ponernos manos a la obra, creando nuestro primer entorno:

Código: [Seleccionar]
[~]# workon
[~]# mkvirtualenv test
[~]# pip install ez_setup
[~]# pip install pytranslate

Con esto tenemos nuestro primer entorno en marcha, además hemos instalado 2 módulos en el, ahora a probarlos toca:

Código: [Seleccionar]
[~]# python
Python 2.6.5 (r265:79063, Feb 28 2011, 21:55:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pytranslate
>>> pytranslate.translate("Hola mundo!",sl="spanish",tl="english")
'Hello world!'

Et voilà!

Páginas: [1]

Página generada en 0.116 segundos con 38 consultas.