Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Posts Tagged ‘perl

Smart HTTP de Git y Redmine

with 5 comments

Actualmente estoy preparando la actualización de un servidor Redmine que gestiono. Es una actualización bastante grande: no es sólo cuestión de actualizar la instancia Redmine, sino todo el sistema y herramientas de apoyo. Lleva demasiado tiempo sin tocarse y tiene una distribución antigüilla.

Una de las cosas que quería añadir en el servidor actualizado (junto con Redmine 0.9.2, la última versión estable a fecha de hoy) era soporte integrado con Git. Sin embargo, hay un problema, conocido por todos los usuarios de la red de la Universidad de Cádiz: el cortafuegos cierra el paso a prácticamente todo salvo correo y HTTP (y ocasionalmente HTTPS). Por eso, muchos de los protocolos que admite Git están fuera de la cuestión: el propio de Git (que de todos modos no serviría para los push), SSH (como lo proponga le da un patatús al CITI) y rsync (en desuso).

Git ha permitido el uso de HTTP y HTTPS desde hace tiempo sobre WebDAV, al estilo de Subversion, pero nunca me ha gustado este método. Además de sus problemas de rendimiento, de no poder usar “hooks” (manejadores de eventos) y de las molestias que origina (hay que meter un trabajo cron que ejecute “git update-server-info” periódicamente en cada repositorio), tiene una pega gravísima: la consistencia del repositorio está a completa merced de todos y cada uno de los clientes que acceden al repositorio.

Cuando di mi primer curso de Git en 2008, algunos de los asistentes me dijeron tajantemente que ni hablar de activar SSH en sus máquinas, así que probamos el acceso por HTTP. Curiosamente, el primer día que lo probamos y estuvimos mandando commits en rápida sucesión, se corrompió el repositorio varias veces. Al siguiente día, no se corrompió en absoluto, y le estábamos mandando cosas incluso más rápido que antes. Pero entonces llegó uno de los asistentes que faltaba, y dicho y hecho: a los pocos minutos estaba corrompido. El origen del problema: la versión de Curl del asistente que había venido (único usuario de MacBook en la sala, jeje) era antigua. Cuando Git trabaja sobre WebDAV, el servidor HTTP sirve de poco más que de un área de subida de ficheros. Si la versión de la biblioteca curl instalada en el cliente tiene fallos, éstos repercutirán en el repositorio (como con Curl 7.16.0). Ah, y por supuesto no hay nada de atomicidad: si el usuario pulsa Ctrl+C en mitad de la actualización o se le va la conexión, puede que el repositorio también se quede en un estado inconsistente.

Por estas razones, descarté incluso HTTP/HTTPS, y no metí Git en la instalación actual de Neptuno. Todo se quedó en una instalación de Gitosis en mi servidor doméstico. Sin embargo, Git 1.6.6 incluye “smart HTTP“, que arregla los problemas de rendimiento, llama a los “hooks”, evita la necesidad del trabajo cron con “git update-server-info” y proporciona las mismas garantías de atomicidad que el acceso por SSH. El “truco” es que ya el servidor HTTP no es una tonta área de almacenamiento WebDAV, sino un CGI que implementa los servicios que usualmente se invocan mediante SSH a través de HTTP. Lo bueno de todo esto es que además, al ser HTTP, podría integrarlo directamente con el esquema de autenticación de Redmine, con lo que un proyecto público admitiría fetch anónimo pero limitaría los push a los miembros con derecho a commit, y un proyecto privado exigiría los derechos apropiados para tanto fetch como push. La única “pega” es que hay que tener Git 1.6.6 como mínimo tanto en el cliente como en el servidor, pero bueno, los verdaderos usuarios de Git se lo compilan desde las fuentes, que no es tan difícil ;-).

Sin embargo, esta configuración de Apache que combina las instrucciones del CGI con una variación de la propuesta en la web de Redmine no sirve directamente:

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
PerlLoadModule Apache::Authn::Redmine
<Location /git>
  Order deny,allow
  Allow from all

  PerlAccessHandler Apache::Authn::Redmine::access_handler
  PerlAuthenHandler Apache::Authn::Redmine::authen_handler
  AuthType Basic
  AuthName "Redmine Git Repository"
  Require valid-user

  RedmineDSN "DBI:mysql:database=databasename;host=my.db.server"
  RedmineDbUser "usuario"
  RedmineDbPassword "contraseña"
</Location>

Cuando lo probé, no podía crear clones de forma anónima de un proyecto público: tenía siempre que introducir contraseña. Además, tampoco podía hacer push en un proyecto público, por mucho que pusiera la contraseña. La explicación es algo larga, pero es interesante (y me llevó unos buenos tirones de pelos y media mañana :-/). Está dividida en dos partes:

  • El hecho de que fallaran los clones anónimos es que el manejador de autenticación de Redmine, pensado para WebDAV como está, distingue las acciones de “sólo lectura” (las que pueden hacerse de forma anónima en proyectos públicos y que no requieren derechos de escritura para los miembros de proyectos privados) del resto a través de sus métodos HTTP. Por omisión, estos métodos son GET, PROPFIND, OPTIONS y REPORT: por definición, no deberían producir cambios en los recursos a los que acceden. Sin embargo, al hacer “fetch” con smart HTTP de Git se hace una petición POST al servicio git-upload-pack, y hace que pida contraseña: nos quedamos sin fetch anónimo.
  • El segundo problema se debe a que git-http-backend, el CGI necesario en el servidor para “smart HTTP”, obliga por omisión a que todos los push (peticiones al servicio git-receive-pack)  tengan algún tipo de autenticación. De lo contrario, los rechaza con un código de error 403 (Forbidden). Y aquí volvemos con el problema de distinguir las acciones por los métodos HTTP: el servicio git-receive-pack se utiliza en dos fases. La primera fase es un GET a /git/repositorio/info/refs?service=git-receive-pack: git-http-backend exige autenticación, pero el manejador de Redmine no se la pide al usuario, ya que es un método de sólo lectura. Resultado: un bonito Forbidden (403) para cualquiera que quiera hacer push. Los tirones de pelos en este lado vienen de que Git, al ver que el push por smart HTTP no ha ido, asume que el servidor es de tipo WebDAV, y hace más peticiones que hacen más difícil encontrar el problema. Actualización 14/03/2010: puede que en dentro de poco se deje de pedir contraseña para el GET.

¿Cómo corregir esto? Pues haciendo que el manejador de Redmine distinga las peticiones “de sólo lectura” del resto no por método HTTP, sino por dirección, tal y como viene en la página man del CGI (segundo ejemplo de configuración de Apache). Podría haber desarrollado un nuevo manejador de autenticación, pero duplicaría todo el código salvo en un par de sitios. He preferido añadir una nueva directiva que activa este comportamiento, que por omisión está deshabilitado: RedmineGitSmartHttp. Para usarla, pondríamos esta línea dentro del anterior <Location /git>:

RedmineGitSmartHttp yes

y ya todo debería ir sin problemas. Esto no afectará a los bloques <Location /svn> que tengamos en otra parte: se usan instancias distintas del manejador de autenticación, y esas instancias no tendrán esta opción activada, por lo que mantendrán el antiguo comportamiento. Bueno, por lo menos así me ha funcionado en mi servidor de pruebas y así lo indican sus registros :-D. He probado con proyectos públicos y no públicos en SVN y Git en el mismo Redmine y ha ido bien.

Para aquellos interesados en el código, he enviado un parche al proyecto Redmine, para que lo fusilen revisen más y mejores ojos que los míos. A ver qué tal lo reciben. Para aplicarlo, hay que descomprimir las fuentes de Redmine, poner el parche en su directorio principal, y ejecutar esto:

patch -p1 < 0001-Redmine.pm-add-Git-smart-HTTP-support.patch

Un último detalle: Git necesitará nuestro usuario y contraseña para autenticarse. Una opción es clonar con http://usuario@host/git/repositorio, poniendo el usuario en la URL y metiendo la contraseña cada vez que haga falta, pero es muy incómodo: por desgracia, no guarda las contraseñas automáticamente como hace SVN. Otra opción es crear un fichero ~/.netrc (¡sólo legible por nuestro usuario!) con nuestro usuario y contraseña:

machine mihost
login miusuario
password mipassword

No me termina de gustar eso de tener mi contraseña guardada en la máquina, pero bueno, ya pasaba con SVN, así que supongo que es el precio a pagar por no tirar de SSH :-/.

Written by bluezio

24 de febrero de 2010 at 9:50

Publicado en Desarrollo

Tagged with , , , ,

Usando PAR::Packer y Strawberry Perl en Windows

with 2 comments

Todos los días se aprende algo. Hoy he aprendido que tirarme hasta las 5 de la mañana peleándome con camelbox, ActivePerl, y Strawberry Perl para que funcionara PAR::Packer como $DEITY manda ha sido una gran pérdida de tiempo, y que habría sido mucho más productivo simplemente dormir :-D.

Como ya dije en el post de ayer, estuve mirando cómo mejorar la distribución de los conversores, para que el “usuario medio” no tuviera que ser “usuario que sabe instalar un entorno Perl, tirar de CPAN y llevarse un dolor de cabeza con los fallos que le salgan”. En los entornos UNIX está todo muy depurado y PAR::Packer y PAR funcionan de maravilla a la primera, pero en Windows la cosa no está tan clara.

Primero probé con ActivePerl, que con los repositorios PPM de Uwinnipeg y Bribes quedaba bastante completo. Pero por alguna razón, no incluía bien un fichero que instalaba con install_share. Con ActivePerl me pasé varias horas, y luego probé con Strawberry Perl, en sus versiones 5.8 y 5.10 de Perl, y tenía fallos al instalar desde CPAN. Otras tantas horas. Y luego, cómo no, probé con camelbox, y una vez más con Strawberry Perl. Ya me caía de sueño y harto de mirar en listas de correo y bug trackers, me fui a dormir. (Por cierto, el nombre de Strawberry Perl viene por que es una mejora sobre el Vanilla Perl. Un batido fresquito no vendría mal ahora, no señor…)

Hoy me levanto y me acuerdo de un post de ayer que decía algo de que el fallo que yo encontraba “estaba arreglado en trunk”. Trunk, ¿de qué? Pues trunk del SVN de PAR::Packer, que aunque en el $VERSION de Packer.pm decía 0.980, no era el 0.980 de CPAN que me había dado tantos dolores de cabeza. Strawberry Perl 5.10, PAR::Packer del SVN, sin problemas. Todo instalado y funcionando como la seda.

Qué momento más agridulce de mi vida :-D. Bueno, para la próxima me voy a dormir y consulto con la almohada.

Una cosa: al llamar a pp para generar un EXE en Strawberry Perl, no hace falta darle el –gui para evitar que aparezca una ventana de consola. De hecho, si se lo damos nos quedamos sin stdout y stderr :-/. Es buena idea usar ‘-r’ para pruebas, y con la opción ‘-I blib/lib’ nos aseguramos que los ficheros que instala File::ShareDir aparezcan en los PAR. También es buena idea, y no hace daño, añadir “-M PerlIO”: en ActivePerl daba problemas si no se incluía. Dejo esto apuntado por si alguien con mis problemas busca por Google :-D.

Written by bluezio

24 de junio de 2008 at 11:05

Publicado en Desarrollo

Tagged with , , ,

Mejorando la distribución de los guiones Perl

leave a comment »

Estos días he estado curioseando sobre la forma de facilitar un poco la distribución de los conversores ACL2->XML y YAML->XML. Es cierto que ACL2::Procesador está mucho mejor que antes del Concurso, ya que al cambiar a una estructura basada en los módulos de CPAN, con un instalador creado mediante Module::Install, ahora se instalan todas las dependencias automáticamente al seguir estos pasos:

perl Makefile.PL
sudo make
make test
sudo make install

Esto le resultará muy familiar a cualquiera que haya compilado e instalado un proyecto de las autotools, pero hay un problema: CPAN no es a prueba de bomba, y el “sudo make” instalará no sólo los paquetes necesarios para ejecutar ACL2::Procesador, sino también los que hacen falta para compilar y depurar el módulo. Además, dos de estas dependencias de compilación son módulos XS, con lo que necesitan un compilador C, además de las bibliotecas y cabeceras que utilizan: libxml2 y libexpat. Para un desarrollador tampoco es gran cosa, pero pedir esto a un usuario medio… pues como que no es muy realista.

Con los paquetes Debian se facilita mucho la cosa, claro, pero ¿y si no estamos bajo una distribución basada en Debian, como openSUSE? ¿O si estamos en Windows? Algún usuario potencial en Windows habrá: al fin y al cabo, estoy usando Perl y Java, que por ir tendrían que ir como mínimo en Mac OS X también. No es cosa de cerrarme en banda, tampoco.

No tengo tiempo de hacer paquetes para todo lo habido y por haber, eso está claro. Pero simplificar se puede simplificar. Module::Install tiene dos módulos llamados Module::Install::Bundle y Module::Install::Include que supuestamente permiten incluir en las distribuciones de código las dependencias, pero no me funcionan en absoluto, la verdad.

Donde sí he tenido una grata sorpresa es con los módulos PAR y PAR::Packer. Cualquiera que haya utilizado Java y visto el acrónimo tendrá una idea (JAR = Java ARchive, PAR = Perl ARchive), me imagino. PAR permite crear ficheros .par que agrupan todos los módulos no estándar y bibliotecas necesarias para que nuestro program Perl funcione. Tras instalar PAR y PAR::Packer, ejecutaremos esta orden para crear el .par:

pp -p -o acl2-proc.par script/pprocACL2

Y ejecutarlo sólo requiere el módulo PAR (que es relativamente ligero, y en las Debian se halla disponible como libpar-perl) y Perl:

perl -MPAR acl2-proc.par (fichero Lisp raíz de la demostración)

Más fácil todavía: si no ponemos el -p, se crea no un .par, sino un ejecutable completamente autocontenido, que puede distribuirse sin necesidad de que el usuario instale nada previamente. El único problema es evidentemente el tamaño del ejecutable: pasamos de un .par de 75KB a un fichero de ~2.7MB. Esto es más interesante para la gente de Windows, sobre todo.

Obviamente, los .par son específicos de la plataforma en cuanto usemos un solo módulo que no sea Perl puro. Para ACL2::Procesador no es un problema, pero YAXML::Reverse sí que usa la biblioteca libyaml. Se pueden crear .par multiplataforma, acumulando los resultados de cada plataforma sobre el mismo .par, así:

pp -m -o yaxml.par script/yaml2xml

La verdad es que distribuir un fichero .par y poder olvidarte de CPAN es una alegría, qué más decir. Incluso existe la posibilidad de distribuir un único guión Perl y hacer que se “traiga” e instale el PAR de un repositorio bajo una URL, con el módulo PAR::Repository::Client, pero este módulo es bastante pesado: quizás sea conveniente para redistribuir código entre muchas máquinas que manejemos, pero no tanto para instalarlo en una máquina del usuario.

Mi idea es reunir en varios .tar.bz2 versiones de los conversores que puedan descomprimirse directamente sobre el directorio donde tengamos XMLEye, y que incluyan los .par o ejecutables monolíticos, los descriptores de formato y las hojas de estilo. Así resultará mucho más cómodo que como está ahora.

Written by bluezio

22 de junio de 2008 at 10:38

Publicado en Desarrollo

Tagged with , , , , , , ,

Módulo YAML/JSON->YAXML y Manual de Usuario

leave a comment »

Esta semana he estado escribiendo el Manual de Usuario (está entre los documentos del proyecto de la forja), y empecé el Manual del Desarrollador. Por lo pronto ya tengo las instrucciones de compilación, pero aún queda mucho por escribir. Más que nada lo hago porque la gracia de XMLEye está precisamente en que se escriban muchos tipos de documento para él.

Se me ocurrió que sería bueno tener un ejemplo sencillo en dicho manual, ya que definitivamente ACL2::Procesador no serviría como “ejemplo sencillo”: 6000 líneas aproximadamente de código Perl orientado a objetos, fábricas y demás, y sin contar la infraestructura necesaria para que todo funcione como un módulo Perl estándar.

Dicho y hecho: se me ocurrió que YAML podría ser un buen candidato, siempre que pueda escapar la ira de sus usuarios por ensuciarlo convirtiéndolo a XML :-D. Así se pueden usar más tecnologías XML sobre él, como XML Schema o XSLT.

Así que he creado un módulo Perl basado sobre YAML::Syck (un binding Perl de la biblioteca Syck de serialización) que convierte YAML a XML, e incluye una hoja XSLT que devuelve el XML así creado a YAML. Integra pruebas de unidad para asegurarse de que no se producen pérdidas de información en el proceso YAML->XML->YAML. Todo se ha hecho siguiendo las directrices de un binding experimental de YAML para XML, YAXML, disponible en http://www.yaml.org/xml.html.

Además, tiene sus propias hojas de usuario y descriptor de tipo para preprocesamiento y visualización para XMLEye, con lo que nos saltamos algunas de las limitaciones de XML a la hora de visualizar, como no poder tener elementos como “Pepito el de mi pueblo”, que sí son claves de tabla hash válidos en YAML, o nombrar como “Elemento 0” a los elementos de una lista. La hoja de visualización es una especialización de la hoja XML que añade elementos de los elementos con atributo alias a sus anchor correspondientes.

Se encuentra también en mi repositorio Debian, junto con una versión más reciente de XMLEye que corrige algunos fallos de los que me he dado cuenta desarrollando este ejemplo, dentro del paquete libyaxml-reverse-perl. Puede usarse como un módulo más, o a través del guión yaml2xml que incluye el paquete.

Ah, y de paso: este módulo (y XMLEye por lo tanto) también acepta documentos JSON, ya que dicho estándar no es más que un subconjunto de YAML. Si alguien conoce un vocabulario estándar basado en YAML o JSON, que me lo comente y veré si me puedo montar una especialización de las hojas de usuario para YAXML.

Al final creo que no he conseguido un ejemplo sencillo de preprocesador, pero por lo menos las hojas de visualización y preprocesado sí que son bastante sencillas :-D.

Written by bluezio

9 de marzo de 2008 at 21:07

Publicado en Uncategorized

Tagged with , , , , , ,