yaco

¡Hoygan! Aquí están nuestras cosicas.

EasyTrac, un despliegue automatizado de Trac.

Como ya comenté en posts anteriores, en Yaco Sistemas trabajamos a diario con Trac, todas nuestras tareas están en Trac, incluyendo documentación de proyectos, etc; en Yaco Sistemas no eres nadie si no creas una wiki ;-)

Eso está muy bien, ¿pero qué es easyTrac?

EasyTrac es un instalador basado en zc.buildout que despliega un entorno de Trac de forma automatizada incluyendo dependencias necesarias.

Este instalador no solo puede ser utilizado para desarrollo sino que también podría utilizarse en un sistema de producción ya que los proyectos de Trac se despliegan bajo Nginx y uWSGI, con lo que tendremos un sistema bastante rápido, estable y liviano en nuestro sistema.

Si es cierto que para poder compilar Nginx y uWSGI, es necesario que se encuentren ciertas librerias de desarrollo en el sistema, por lo que deberemos tener instalados los siguientes paquetes en nuestro sistema:

  • libpcre3-dev
  • libssl-dev
  • libxml2-dev
  • libxslt-dev
  • libsqlite3-dev
  • libzzip-dev
  • libapr1-dev
  • libaprutil1-dev
  • python-dev

Me parece correcto... ¿pero de dónde me lo descargo?

Puedes descargarlo de forma comprimida tanto en formato zip como en formato tar.gz.

O si lo prefieres, puedes hacer un clone con Git de mi repositorio en Github ejecutando lo siguiente:

$ git clone git://github.com/mviera/easyTrac

Vale, ya lo tengo ¿y ahora cómo lo instalo?

EasyTrac se puede instalar tanto como root como con cualquier usuario sin privilegios, ya que la instalación no interferirá para nada en nuestro sistema. Personalmente, prefiero instalar con un usuario sin privilegios.

El instalador de easyTrac funciona sin tener que hacer ninguna modificación en la configuración, pero si quieres personalizar la configuración, puedes editar el fichero buildout.cfg y modificar alguno de los siguientes parámetros:

  • nginx-http-port: puerto utilizado por Nginx para escuchar las peticiones vía http.
  • nginx-https-port: puerto a través del cual Nginx escuchará las peticiones vía https (en caso de que quieras usar https).
  • supervisor-http-port: puerto utilizado por Supervisor.
  • host: IP del host o FQDN (Fully Qualified Domain Name)
  • socket-directory: directorio donde se almacenarán los sockets.
  • pid-directory: directorio donde se alojarán los ficheros pid.
  • log-directory: directorio de logs.
  • trac-projects-directory: directorio donde se crearán los proyectos de Trac. Por defecto este directorio es <installdir>/opt/trac/.
  • svn-repository-directory: directorio donde se crearán los repositorios de código SVN. Por defecto, este directorio es <installdir>/opt/svn/.

Una vez instaladas las anteriores dependencias, y configurados los parámetros de configuración, en caso de que quisieras personalizarlos, podemos seguir con la instalación, así que ejecutaremos lo siguiente:

$ python bootstrap.py

Con esto prepararemos el entorno y una vez hecho, podremos lanzar la instalación ejecutando lo siguiente:

$ ./bin/buildout

Comenzará el proceso de compilado de Nginx y uWSGI; y la instalación de los módulos de Python necesarios. Además, easyTrac compila Subversion e instala los bindings necesarios para que Trac pueda enlazarse con repositorios de código SVN.

He ido a por un café y al volver ya estaba instalado ¿ahora qué hago?

EasyTrac incluye la instalación de Supervisor. Pero ¿qué es Supervisor? Es un sistema de control de procesos que nos va a permitir arrancar, parar y reiniciar cada uno de nuestros servicios. En easyTrac tendremos dos servicios: Nginx yuWSGI.

La sintaxis de uso de Supervisor es la siguiente:

$ ./bin/supervisorctl

Por lo tanto si quisiéramos iniciar el servicio Nginx, ejecutaríamos lo siguiente:

$ ./bin/supervisorctl start nginx

En caso de querer pararlo, ejecutaremos:

$ ./bin/supervisorctl stop nginx

Y si quisiéramos reiniciarlo:

$ ./bin/supervisorctl restart nginx

Supervisor incluye una palabra especial llamada all que hace referencia a todos los servicios configurados en supervisor. Con ella podremos controlar todos los servicios al mismo tiempo. Por ejemplo, si quisiéramos reiniciar todos los servicios, ejecutaríamos lo siguiente:

$ ./bin/supervisorct restart all

Pero esto no es todo, es que además Supervisor, por si fuera poco, incluye una interfaz web desde la que podemos controlar nuestros servicios. Podremos acceder a ella accediendo a

http://localhost:9000

Por defecto, el usuario es admin y la contraseña es admin. (nótese el punto al final de admin). Es posible cambiar estos datos editando la parte [supervisor] en el fichero buildout.cfg y volveremos a ejecutar la instrucción./bin/buildout

Ya tenemos nuestro entorno listo y accederemos a él a través de

http://localhost:8080

¡Qué bien! ¿y ahora cómo creo un Trac?

Tranquilos, la creación de un proyecto Trac es muy sencilla. Utilizaremos el binario trac-admin creado por el instalador, y que se encuentra en el directorio bin/.

Crearemos un proyecto llamado demo, por lo que ejecutaremos lo siguiente:

$ ./bin/trac-admin opt/trac/demo initenv demo sqlite:db/trac.db

Y ya que estamos, vamos a crear un repositorio SVN con el mismo nombre. Para ello utilizaremos el binario llamadosvnadmin que podremos encontrar también en el directorio bin/.

$ ./bin/svnadmin create opt/svn/demo

Fiuf! ahora solo falta que pudiera hacer backups de mis Tracs

Aunque no es una solución feténica, easyTrac cuenta con un comando backup con el que podremos comprimir nuestros proyectos y guardarlos en otra localización. Para ello, simplemente ejecutaremos la siguiente instrucción:

$ ./bin/backup

y todos los proyectos Trac serán comprimidos y guardados en un directorio llamado backups/.

Vale, tengo backups, quiero restaurarlos ¿cómo lo hago?

Tan simple como ejecutar lo siguiente:

$ ./bin/restore backups/backup-file.tar.gz

y todos los tracs serán restaurados automáticamente en el directorio, por defecto, opt/trac/.

No me convence. Quiero desinstalarlo.

Solamente es necesario parar todos los servicios:

$ ./bin/supervisorctl shutdown

y borrar el directorio de instalación:

$ rm -rf easyTrac

And that's all folks!!! ;-)

Un saludo!

via blog.manuelviera.es

 

Crontab

Hoy trabajando en Yaco Sistemas he aprendido algo nuevo sobre cron. Seguramente muchos de los que os moveis entre GNU/Linux y similares, conoceréis el demonio cron.

Cron es un planificador de tareas que nos permite ejecutar una tarea en un momento determinado en el tiempo. La sintaxis para configurar una tarea cron es la siguiente:

.---------------- minuto (0 - 59)
|  .------------- hora (0 - 23)
|  |  .---------- día del mes (1 - 31)
|  |  |  .------- mes (1 - 12)
|  |  |  |  .---- día de la semana (0 - 6) (Domingo=0)
|  |  |  |  |
*  *  *  *  *  comando para ser ejecutado


De esta forma, imaginad que queremos apagar nuestro ordenador los sábados a las 21:30h, configuraríamos una tarea cron de la siguiente forma:

30 21 * * 6 /sbin/shutdown -h now


Podemos planificar tareas para un usuario utilizando el comando crontab:
crontab -l Lista las tareas cron para el usuario actual.
crontab -e Permite configurar una tarea cron para el usuario actual. Se abrirá el editor de texto configurado por defecto en el sistema.
crontab -r Elimina las tareas cron configuradas en el usuario actual.
crontab -v Muestra la última vez que se editó crontab del usuario actual.

La verdad es que no parece una sintaxis muy complicada pero a mi, personalmente, siempre se me olvida.

Como os decía al principio, hoy he descubierto los horarios predefinidos en crontab gracias a ant30. Estos horarios predefinidos son unos valores que se pueden usar para sustituir la sintaxis de las expresiones anteriores. Estos valores predefinidos son:

@yearly Se ejecuta una vez al año. Equivalente a 0 0 1 1 *
@annually (igual que @yearly). Equivalente a 0 0 1 1 *
@monthly Se ejecuta una vez al mes. Equivalente a 0 0 1 * *
@weekly Se ejecuta una vez a la semana. Equivalente a 0 0 * * 0
@daily Se ejecuta una vez al día. Equivalente a 0 0 * * *
@midnight (igual que @daily). Equivalente a 0 0 * * *
@hourly Se ejecuta una vez cada hora. Equivalente a 0 * * * *
@reboot Se ejecuta en el arranque y al reiniciar.

El que yo he utilizado hoy ha sido @reboot que me permite ejecutar un comando cuando arranca el sistema. En mi caso quería que cada vez que se arranque el sistema, se iniciara un servicio desplegado con el usuario en cuestión. Gracias a @reboot no tengo que crear un script en /etc/init.d/ y activarlo en el arranque ;-)

Un saludo!

via blog.manuelviera.es

Publicado Merengue 0.6.0

Tras más de 300 tickets cerrados y dos meses de trabajo, se ha publicado la versión 0.6.0-final de Merengue, disponible en Pypi.

Esta versión final supone la corrección de muchos errores, y sin ningun cambio funcional desde la versión 0.6.0-alpha, y pensamos está lista para su uso en webs de producción. Para el que no conozca el proyecto, recomiendo echar un ojo al overview de Merengue y entrar en la web de demostración

Algunos enlaces de interés:

Gracias a todo el equipo de Merengue, gracias a ellos el proyecto Merengue se ha hecho realidad.

Aplicaciones Django interesantes

He hecho un recorrido por el estado de algunas aplicaciones que conocía y ver otras muchas nuevas, para ver la posibilidad de integración en Merengueo en otros proyectos Django.

Para que no se quede sólo en mi cabeza os listo las que he visto más interesantes:

  • django-attachments: para crear adjuntos a cualquier modelo de forma no intrusiva (usando generic FK). Tiene:
    • un InlineModelAdmin para poder poner adjuntos en cualquier ModelAdmin que tengamos.
    • una serie de templatetags para poner enlaces a los attachments.
  • django-mediasync: para poder desarrollar con los media local, pero sincronizar con CDNs como S3 o Rackspace estando en producción, y permitiendo en la sincronización hacer cosas como comprimir CSS y JS, versionar imágenes para permitir un cacheo mucho más agresivo, etc. Creo que debemos integrarlo en Merengue.
  • django-announcements: para anunciar algo a todos los que entren en la web, o sólo a los miembros de la misma. Son anuncios como "nueva version de la web" o "mañana a las 12 habrá un corte en la web por motivos de mantenimiento". Creo que va a ser necesario para la UMA por lo que será incluido en Merengue.
  • django-uni-form, para normalizar presentación de formularios como <div> ya bien maquetados. Poniendo un simple {{ my_form|as_uni_form }} y incluyendo unos ficheros css ya preparados, tenemos unos formularios perfectos. Esto es útil para usarlo en todo proyecto que hagamos. Además permite una personalización del layout, que viene en la documentación.
  • django-frontendadmin, aplicación que permite editar el contenido en la misma página que lo ves, como nuestra inlineeditforms, pero que te muestra el formulario de edición al completo en lugar de ir editando haciendo click en el campo concreto que quieres cambiar. Puede ser útil en algunos proyectos concretos, pero creo que Merengue irá mejor si la edición es en el admin (o en el caso de la UMA Victoriano quiere los inlineeditforms).
  • django-sorting, aplicación para que el usuario pueda ordenar listados pinchando en las cabeceras de las tablas. Está hecho como django-pagination, con lo que un simple middleware y poco más se necesita para echarlo a andar, cosa que se agradece.  Se integrará con las colecciones de Merengue (en versión 0.8).
  • django-email-confirmation, para cuando necesitas verificar el correo de un cliente, para cualquier parte de la lógica de tu sistema.

 

Contribución a Trac

En Yaco Sistemas utilizamos Trac en cada uno de nuestros proyectos de desarrollo y para los que no son de desarrollo también. Trac se ha convertido una herramienta fundamental para nosotros, tanto, que sin ella nos sería mucho más complicado trabajar.

Ayer nos surgió una nueva necesidad en el Trac de uno de nuestros proyectos. Os pongo un poco en situación.

En Trac cuando se crea un ticket, normalmente lo crea una persona y es posible asignarlo a otra. En este caso, y si estuviese configurado, es posible notificar vía email tanto al creador del ticket (reporter) como a la persona a la que se le ha asignado el ticket (owner) de la creación del ticket y de las posteriores modificaciones en éste.

En la documentación de Trac referente a las notificaciones podemos ver que existen tres opciones:


  • always_notify_owner: si se establece como true, cualquier modificación en el ticket se envía al owner del ticke
  • always_notify_reporter: si se marca como true, cualquier modificación es enviada al reporter del ticket.
  • always_notify_updater: si se configura a true, se envía una notificación a la persona que ha modificado el ticket y a cualquier persona que haya modificado anteriormente el ticket.

Nuestra nueva necesidad consistía en que se notificase por correo al reporter de un ticket solamente cuando el ticket fuera cerrado, y no con cada una de las modificaciones del ticket. Con la opción always_notify_reporter no es posible, ya que se envían todas las modificaciones del ticket o ninguna, dependiendo si está o no activada esta opción en la configuración de nuestro Trac.

Busqué en la documentación de Trac a ver si había posibilidad de hacer esto. También busqué alguna otra posible solución en internet, pero no encontre nada.

En ese momento decidí ver si era posible crear yo mismo dicha funcionalidad. Así que he desarrollado una nueva opción llamada always_notify_close_reporter la cual, si establecemos a true, solamente notificaremos al reporter cuando el ticket se cierre, evitando que le lleguen correos con cada una de las modificaciones del ticket.

Creé el parche y decidimos abrir un ticket en Trac [1] para compartirlo con la comunidad. A ver si hay suerte y lo incluyen en el código de Trac :-)

[1] http://trac.edgewall.org/ticket/9977

Esto es lo bonito del software libre :-)

Un saludo.

via Posterize