oscarmlage oscarmlage

Django + virtualenv + pip

No lo tenía claro, pero cuando entendí lo que suponía y cómo se trabajaba con virtualenv + pip me decidí a probarlo. Voy a intentar explicar como se utilizan estas herramientas de una forma genérica, para hacernos una idea de lo que significa y los casos en los que se pueden aplicar. A grandes rasgos: Django: Framework en python, creo que no necesita mucha más explicación. Virtualenv: Herramienta necesaria para crear un entorno virtual de python, con las versiones específicas de los paquetes y/o dependencias que hagan falta para el proyecto. Pip: Gestor/Instalador de esos paquetes (similar a easy_install). Con estas herramientas intentaremos instalar un entorno virtual independiente para gestionar todas las dependencias de nuestro proyecto.

¿Codeigniter-Reactor + esteroides?

Es algo que todavía no llego a entender ni asimilar. He pasado la mayor parte de la tarde para configurar la nueva versión 2.0 de CodeIgniter-Reactor con varias librerías que, para mi forma de desarrollar, son indispensables en cualquier framework de programación orientado a web: HMVC: Gracias a la librería de Wiredesignz podemos ordenar nuestro código en módulos y simplificar la lógica de la aplicación. ModulesModule: Ahora que todo será un módulo, no vendría mal un módulo encargado de ejecutar las tareas más comunes de los módulos (instalar, desinstalar, actualizar...). Un módulo de módulos. SettingsModule: No me gusta cargar la configuración desde ficheros config/*, por comodidad y para que el usuario pueda cambiar cualquier parámetro ajustable de una aplicación, prefiero hacerlo en base de datos y cachearlo a disco si es necesario. Me quedo con la librería de PyroCMS. ThemesModule: Otra característica imprescindible sería tener una aplicación themeable y que desde un interfaz de administración se pueda cambiar tranquilamente el aspecto de la misma. Para ello podemos hacer uso de este módulo capaz de instalar y desinstalar themes. TemplateLibrary y TagsLibrary: Una vez hemos decidido hacer la aplicación modular y themeable siguiendo el patrón MVC, un buen lenguaje de template para que los diseñadores no se vuelvan locos con el lenguaje dinámico sería un punto más. MigrationsLibrary: Una vez lo pruebas se convierte en musthave. Se trata de una librería para hacer migraciones de versiones en base de datos. Gestiona los cambios entre versiones de forma sencilla.

Dovecot, pequeñas peculiaridades

Desde hace algún tiempo -y después de haber lidiado con Cyrus y Courier- he optado por Dovecot como servidor POP3 e IMAP para máquinas en producción. Por varios motivos: la sencillez de configuración, sigue los estándares, soporta mbox y Maildir y algo muy importante, tiene un backend de autentificación SMTP compatible con Postfix (entre otros). Sin duda el servicio de correo electrónico es el menos agradecido y probablemente el más doloroso para el sysadmin pero el haber dado con esta combinación de elementos me ha ahorrado un montón de problemas. De todos modos en la última instalación que me ha tocado he encontrado un par de peculiaridades que me gustaría documentar por si alguien se encuentra en la misma situación.

Limitando usuarios ssh en Mercurial

Si algo bueno tiene Mercurial es que permite la autentificación de usuarios a través de SSH. Es muy sencillo agregar un nuevo usuario a un desarrollo/repositorio: adduser y con meterlo dentro del grupo correspondiente al desarrollo llegaría. Pero ¿qué ocurre si no queremos que ese usuario haga otra cosa que no sean comandos hg?. Conociendo la existencia de hg-ssh no ocurre demasiado, se trata de un script que hemos de referenciar en el authorized_keys del usuario que acabamos de crear de forma que todos los comandos entrantes pasen por este script. El script se encarga de parsear el comando que se pide en ejecución: si es de la familia de Mercurial lo ejecuta, en cualquier otro caso mostrará un error. Ejemplo de authorized_keys: command="~/hg-ssh /home/repo1 /home/repo2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA... He optado por copiar el archivo hg-ssh en el directorio home del usuario, pero se podría referenciar directamente el que trae de ejemplo la instalación de Mercurial.

Mercurial sobre Apache

Mi predilección por Mercurial ha quedado patente en algún que otro post, así que una vez estamos conforme con nuestro servidor de versiones llega el momento de dar un paso más. Intentaremos configurar un interfaz web para mostrar el código a todo el mundo (una especie de Trac solo para código y adaptado a Mercurial). El proceso es tan sencillo como crear otro VirtualHost en tu Apache con unas características un poco especiales porque en vez de tirar de archivos dinámicos (.php, .asp…) vamos a tirar de un cgi en Python, así que la configuración sería algo así:

Mercurial: automatizando al máximo

Cuando trabajamos con servidores de versiones seguro que hay muchas razones de peso de por medio, una de ellas -la que veremos- puede ser la replicación de código en diversas máquinas. Supongamos un montón de máquinas que comparten el mismo código de repositorio, el orden de propagación de un cambio en todas esas máquinas es sencillo: Programamos dicho cambio en nuestro servidor de desarrollo (devel). Hacemos un commit local (en sistemas de versionado distribuido -como Mercurial- cada repositorio también es servidor). Lo siguiente es un push al servidor donde almacenamos el código (repo código). Ahora tocaría entrar en cada una de esas máquinas en las que queremos propagar el código y ejecutar un hg pull ; hg update.