tags/trac

trac-me-tiene-los-eggs-llenos-toma-2

2009-01-22T04:24:04Z

¿Se acuerdan de la primera parte? Bueno, venía aplicando esto varias veces últimamente (nuevamente tracs y nuevamente plugins). Sé que mi jefe me va a retar, pero la verdad es que lo prefiero así. Generalizé esa idea y lo hice un script, y para marcar su diferencia con el easy_install, lo llamé useful_install:

#! /usr/bin/python

__requires__ = 'setuptools==0.6c3'
import sys

path= sys.argv.pop (1)
sys.path.append (path)

sys.argv= [sys.argv[0], '--install-dir', path, '--site-dirs', path ]+sys.argv[1:]

from pkg_resources import load_entry_point

sys.exit(
    load_entry_point('setuptools==0.6c3', 'console_scripts', 'easy_install')()
)

Como verán es idéntico al easy_install, salvo que el primer parámetro es el directorio donde vamos a instalar las cosas y que hace la magia necesaria de agregarlo al sys.path y armar los argumentos para e_i. Además, le podemos pasar más parámetros a voluntad y pasan derecho al load_entry_point del e_i. Que lo disfruten.

trac python sysadmin

trac-con-mercurial-en-etch

2009-01-22T04:24:04Z

Desde hace como dos semanas que vengo esporádicamente peleando con un problema: Tenía que poner a andar el plugin de Mercurial para Trac. Según las instrucciones de la página, sólo es cuestión de generar un .egg (¿se acuerdan?), ponerlo en el directorio plugins del environment y ya. Pero corriendo tracd y entrando con un browser me daba:

TracError: Unsupported version control system "hg"

Mi primer sospechoso era el .egg; creía que no lo estaba encontrando. Prendiendo el logging en el trac.ini descubrí que en realidad si lo levantaba. Siguiendo un par de links encontré una sugerencia de correr todos los imports que corre el backend.py del plugin. Finalmente descubrí que la línea:

from mercurial.revlog import LookupError

fallaba. Se vé que el Mercurial que viene en Etch (0.9.1-1+etch1) no es del todo compatible, a pesar que la página del plugin dice que lo es, inclusive hasta con 0.8. Para "repararlo" simplemente saué las (1) referencias a LookupError.

trac mercurial sysadmin

luchando-contra-el-spam-en-trac

2009-01-22T04:24:04Z

Como habrán notado en mi post anterior, estuve agregando un plugin anti spam en un Trac que tiene submit de tickets anómimo. Una vez que TracSpamFilter está instalado como mencioné en tal post y habiendo instalado WebAdmin también, queda andando de una.

Un comentario antes de pasar al punto de este post. El plugin funciona con un sistema de karma. Un post arranca con karma 0 y luego se le va cambiando a medida que los distintos filtros se disparan o no. El tema es que algunos suman y otros restan karma. Pero esto no se deduce fácilmente de la página de configuración, pues todos los valores son positivos. Bueno, les comento: el único positivo es el SessionFilterStrategy y el resto son negativos.

Esto quiere decir por ejemplo que por default, un usuario con login (SessionFilterStrategy, +9) puede mandar muchos links externos (ExternalLinksFilterStrategy, -2) y que además matcheen contra BadContent (ése es el RegexFilterStrategy, -5) sin que lo marque como spam.

Volviendo al punto, el problema es que una vez instalado sólo filtra spam entrante, pero no lo que ya hay. Cómo sacárselo de encima? No encontré mejor solución que hackear la base de datos. En mi caso particular, que creo que es el que está afectando a muchos, encontré que los summaries eran muy cortos, por lo que con esto alcanzó:

delete from ticket where length(summary)<11;

También es posible que les hayan llenado comentarios de tickets con spam. No es mi caso directo, sino más bien la forma en que testeaba el plugin. Habiendo hecho lo anterior, los comentarios (y en realidad, cualquier cambio sobre los mismos) de esos tickets quedaron huérfanos. Se los puede borrar con:

delete from ticket_change where ticket not in (select id from ticket);

deletes similares deberían poderse aplicar a otras partes del trac que estén abiertas.

sysadmin trac spam

trac-me-tiene-los-eggs-llenos

2009-01-22T04:24:04Z

Trac es fantástico. Tiene todo lo que quiero y más. Amo Trac...

... hasta que se me ocurre la inefable idea de ponerle plugins. Resulta que Trac es plugineable desde la versión 0.9, y que en la versdion 0.10 más aún, con más plugineabilidad que antes! Y además, existen usas cosas llamadas .egg que simplifican todo: sólo ponés un .egg en el tracenv/plugins y ya.

... y ya? I wish. Resulta que no, mirá vos, que si no hacés la danza del easy_install no anda. Esto es porque éste se las arregla para que un .egg (que a todo esto es un .zip con el paquete) se pueda cargar. Ok, tons nos proponemos a hacer dicha danza. El tema es que uno quiere ser ordenadito y en vez de ensuciar el sistema (e_i por defecto pone todo en el site-packages del python por defecto) espero que los .eggs terminen en el mencionado directorio. Así, intentamos con esto:

sudo -u www-data easy_install --install-dir /var/lib/trac/xarope/plugins/ \
--site-dirs /var/lib/trac/xarope/plugins/ TracSpamFilter
error: /var/lib/trac/xarope/plugins/ (in --site-dirs) is not on sys.path

Lindo error. Resulta que no hay forma de coercer a e_i que lo haga, por más que no esté en el PYTHONPATH (bah, en el sys.path). Y hablando de dicha envvar, no anda ni con PYTHONPATH=path comando ni con un export previo.

Comienza la hora de la negrada. Primero vemos que e_i es en realidad un wrapper de 4 líneas python:

$ cat $(which easy_install)

#!/usr/bin/python2.4
# EASY-INSTALL-ENTRY-SCRIPT: 'setuptools==0.6c3','console_scripts','easy_install'
__requires__ = 'setuptools==0.6c3'
import sys
from pkg_resources import load_entry_point

sys.exit(
load_entry_point('setuptools==0.6c3', 'console_scripts', 'easy_install')()
)

Cuál es la idea? Arrancar un intérprete python, modificar sys.path, de paso sys.argv, invocar dichas líneas de python y ya:

In [1]: import sys
In [2]: sys.path.append ("/var/lib/trac/xarope/plugins/")
In [3]: __requires__ = 'setuptools==0.6c3'
In [4]: from pkg_resources import load_entry_point
In [5]: lep= load_entry_point('setuptools==0.6c3', 'console_scripts', 'easy_install')
In [10]: sys.argv.extend (['--install-dir', '/var/lib/trac/xarope/plugins/', '--site-dirs', '/var/lib/trac/xarope/plugins/', 'TracSpamFilter'])
In [13]: lep ()
Creating /var/lib/trac/xarope/plugins/site.py
Searching for TracSpamFilter
Reading http://www.python.org/pypi/TracSpamFilter/
Reading http://trac.edgewall.org/wiki/SpamFilter
Reading http://www.python.org/pypi/TracSpamFilter/0.2dev-r4489
Best match: TracSpamFilter dev
Downloading http://svn.edgewall.com/repos/trac/sandbox/spam-filter#egg=TracSpamFilter-dev
Doing subversion checkout from http://svn.edgewall.com/repos/trac/sandbox/spam-filter to /tmp/easy_install-C5o9rL/spam-filter
Processing spam-filter
Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-C5o9rL/spam-filter/egg-dist-tmp-nVJ04Y
Adding TracSpamFilter 0.2.1dev-r6418 to easy-install.pth file

Installed /var/lib/trac/xarope/plugins/TracSpamFilter-0.2.1dev_r6418-py2.4.egg
Processing dependencies for TracSpamFilter

Voilá! De acá! Si apunto mi browser a mi trac obtengo:

[back trace]
ExtractionError: Can't extract file(s) to egg cache

The following error occurred while trying to extract file(s) to the Python egg
cache:

  [Errno 13] Permission denied: '/var/www/.python-eggs'

The Python egg cache directory is currently set to:

  /var/www/.python-eggs

Perhaps your account does not have write access to this directory?  You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.

Ah, esto es fácil, sólo agrego un SetEnv PYTHON_EGG_CACHE path en la configuración de Apache para este Trac y ahora sí, yastá!

sysadmin trac

sarge-etch-2

2009-01-22T04:24:04Z

El segundo día me amaneció a las 13. Hoy tocaba terminar con el Apache, que incuía apenas los tracs y el dotproject. Ambos implicaban upgrades.

Los trac no me hicieron renegar mucho, pues está muy bien documentado y hasta fue scripteable. Básicamente era un salto de sqlite2 a sqlite3, un trac-admin ... upgrade seguido de un trac-admin ... resync.

Con lo único con lo que renegué fue que a pesar del upgrade fue exitoso no podía entrar. En los logs encontraba esto:

(9)Bad file descriptor: Could not open password file: (null)

Google al rescate me dijo que había que apagar esa directiva que había tenido que modificar el día anterior:

AuthzLDAPAuthoritative off

También me salió esto:

Failed to load the AuthzSVNAccessFile: The character 'o' in rule '@except' is not allowed in authz rules

Eso era porque en un archivo de configuración del repo (conf.svnaccess) tenía los permisos de sólo lectura como ro en vez de r.

El dotproject me enfrentó a un viejo archienemigo: mysql. La verdad que no se a queinacarajos se le ocurre que es una excelente idea poner la configuración de acceso y permisos de una base de datos dentro de la base misma. Por un lado eso termina siendo un archivo binario no versionable y por otro obliga al sysadmin a aprender SQL (cosa que sé, pero no manejo fluidamente ni me interesa saberlo; otro de los motivos por los que amo los ORM's). Y además esta configuración termina en /var y no en etc. postgresql, en cambio, es mucho más inteligente. Y viva el SQL independiente del motor. Lástima nadie lo usa...

Bien, sólo tuve que hacer un dump del mysql anterior (chroot mediante), crear la base en el nuevo y hacer un load. Fantástico. Luego una lucha trabado con el sistema de permisos antesmencionado. Luego apuntar un browser a https://server/dotproject/install. En ese minisitio tuve primero que configurarlo (como DP no es un paquete en Debian, lo instalé de fuentes; la configuración queda en un archivo en include/config.php; ojo que las otras opciones es nukear las bases), luego volver a entrar a dicha URL, momento en el cual detecta las bases viejas y da la opción de upgradearlas. Anduvo sin problemas y ahora disfrutamos de un DP más nuevo. Yeepee!

sysadmin debian sarge etch apache trac svn mysql dotproject

trac-para-kreissy

2009-01-22T04:24:04Z

esta noche me voy a dedicar rápidamente a poner un trac para kreissy. la idea final es que el URL anterior sea la páfina oficial del proyecto, pero que no necesariamente sea el URL final; puede que haya un redirect al medio. ya explicaré porqué.

lo primero es crear un trac-env para eso:

mdione@skid:~/src/projects/kreissy$ trac-admin trac initenv kReiSSy sqlite:db/trac.db svn /home/mdione/src/projects/kreissy/svn /usr/share/trac/templates

también se puede con:

mdione@skid:~/src/projects/kreissy$ trac-admin trac

a secas, ejecutar el comando initenv y responder las preguntas, que en realidad son, en ese orden, los parámetro sde allá arriba.

el punto complicado es enganchar esto con el apache. hay varios métodos: usándolo como un cgi común y coriente, con FastCGI, con modpython y con modwsgi. hoy me siento valiente así que usaría modwsgi, pero como creo que en algún momento esto puede correr en un debian stable, me voy al más seguro modpython.

la documentación de trac es muy explícita con respecto a los pasos a seguir, así que no pienso repetirlos acá. sí voy a tratar de explicar cómo lo adapté a mi situación.

resultó ser más sencillo que antes. la última que lo probé, hará unas cuantas versiones de trac, me quedó un chancullo muy feo. pero ahora sólo bastó este archivo .htaccess en el directorio en mi public_html:

SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /home/mdione/src/projects/kreissy/trac
PythonOption TracUriRoot /~mdione/projects/kreissy

y ya tengo el trac andando! ftatico! ahora a llenar contendo y eso. pero eso mañana...

sysadmin trac kreissy [[!tagling tags/apache]]

autenticacion-para-un-trac

2009-01-22T04:24:04Z

anoche puse a andar un trac para kreissy. una de las cosas que dejé colgando fue que el trac quedó abierto como... bueno, apelen a su imaginación para terminar esa frase. esa misma noche humitos dejó su impronta, cosa que no me molesta, pero marca que esto no puede quedar así. so, a poner auth.

trac delega todo el sistema de autenticación en apache, así que es lo mismo que poner a andar tal cosa. apache tiene muy buena doc9n[1] al respecto. el desafío es hacerlo andar desde un .htpasswd.

pero, no se puede poner un bloque en un .htpasswd, lo cual imposibilita la empresa. y esto, ahora recuerdo, es lo que lo hizo imposible antes. así que no queda otra que recurrir a la configuración global de apache y dejarnos de joder.

al final el archivo /etc/apache2/sites-available/trac-kreissy quedó:

<Location /~mdione/projects/kreissy>
    SetHandler mod_python
    PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /home/mdione/src/projects/kreissy/trac
    PythonOption TracUriRoot /~mdione/projects/kreissy
</Location>

# auth
<Location /~mdione/projects/kreissy/login>
AuthType Basic
    AuthName "kReiSSy-trac"
AuthUserFile /home/mdione/src/projects/kreissy/trac/htpasswd
    Require valid-user
</Location>

luego agregamos el sitio como enabled y reiniciamos apache:

$ sudo a2ensite trac-kreissy
Site trac-kreissy installed; run /etc/init.d/apache2 reload to enable.
$ sudo /etc/init.d/apache2 reload

c'est tout! luego configuro el trac con trac-admin y listo.

sysadmin trac apache

[1] documentación.