Los módulos de Perl están muy bien organizados en el CPAN: Son fáciles de encontrar, y, gracias a herramientas como el shell de CPAN, son fáciles de instalar y actualizar hasta por usuarios novatos. Sin embargo, cuando la gente no involucrada comienza a utilizar sistemas basados en Perl (en contraposición con utilizar Perl para escribir dichos sistemas), pedirles que se preocupen de cubrir las dependencias o que tengan en mente diferentes arquitecturas de distribución de software es una molestia por la que debemos evitar que pasen.
En mi plática, describo cómo Debian (y otras distribuciones de Software Libre) lidian con este problema, empaquetando un amplio subconjunto del archivo CPAN, cuál es la tarea y misión del equipo pkg-perl de Debian, algunas de las herramientas que utilizamos - y más importante que todo lo demás, cuál es la mejor manera en que podemos interactuar con ustedes, la comunidad de autores - respecto a nuestros sistemas de seguimiento de fallos, construcción de módulos, información de dependencias, etc.
Presenté esta plática en el YAPC::Europe 2007, Viena, agosto de 2007.

Envié el siguiente artículo corto para su publicación en la revista Software Gurú. Describe el trabajo que hacemos en el grupo pkg-perl de Debian. Esto está basado fuertemente en mi plática Integrating Perl in a wider distribution: The Debian pkg-perl group, reducido y traducido al español.

El artículo apareció en la edición agosto-octubre de 2008 de Software Gurú - Puedes ver también la versión que fue impresa.

Coordinación de esfuerzos en grupos de desarrollo e integración de Software Libre

Gunnar Eyal Wolf Iszaevich

Instituto de Investigaciones Económicas - UNAM

Acercarse a comprender el funcionamiento y la organización de las tareas dentro de las comunidades de desarrollo de software libre es una tarea harto complicada ante quien se acerca con curiosidad, proveniente del mundo del software propietario, desarrollado e integrado centralmente y dentro de compañías que operan como "cajas negras" - Sin exponer sus procesos, sin ofrecer a los clientes una ventana a cada uno de los momentos de su proceso de desarrollo. Comprender cómo funcionan las comunidades de Software Libre es una gran oportunidad para comprender distintas metodologías de ingeniería de procesos, en entornos donde todas las metodologías formales simplemente no tienen cómo ser aplicadas.

El ejemplo que presento se centra en el trabajo que realizo en el grupo de empaquetamiento de módulos de Perl (pkg-perl) para la distribución Debian GNU/Linux - Perl es un lenguaje de programación muy popular, especialmente para las tareas de administración de sistemas y de desarrollo de sitios Web, y uno de sus más importantes recursos es el CPAN (Comprehensive Perl Archive Network), una enorme biblioteca de módulos nacida en octubre de 1996, y que a febrero del 2008 cuenta con más de 13,000 módulos independientes.

CPAN ofrece a sus usuarios, además, herramientas para el desarrollo y seguimiento colaborativo, como un sistema de seguimiento de fallos y un sistema de organización, búsqueda y consulta de la documentación de dichos módulos.

El proyecto Debian, por su parte, es la distribución de software libre, hoy por hoy, más grande del mundo, con más de 15,000 paquetes fuente independientes. Su propósito es presentar una colección coherente, consistente y con un elevado nivel control de calidad.

El reto del grupo pkg-perl es empaquetar (de una manera consistente con las políticas de Debian) y dar seguimiento a los fallos que vayan apareciendo en dichos paquetes. Debian ofrece a sus usuarios un sistema de seguimiento de fallos centralizado a través del cual pueden comunicarse directamente con los "mantenedores" de cada uno de los programas. Son ellos los responsables de determinar, para cada fallo, si cae en el ámbito de la consistencia del sistema Debian (y por tanto debe ser corregido directamente por ellos) o si es relativo a la lógica de uno de los paquetes (en cuyo caso debe ser corregido en coordinación con el autor de dicho programa, para que la corrección "fluya" hacia las otras distribuciones que lo integran y, en general, hacia todos sus usuarios).

Hasta hace unos cuatro años, la norma en Debian era que cada mantenedor fuera responsable exclusivo de los paquetes que le interesaran; en 2003 nació el sistema Alioth, basado en GForge, y ofreciendo de una manera centralizada las herramientas necesarias para un verdadero desarrollo colaborativo, se comenzaron a configurar grupos amplios de mantenimiento de infraestructura - Uno de los primeros en aparecer, ante la iniciativa de Joachim Breitner, fue pkg-perl. El eje fundamental en torno al cual gira el trabajo del grupo es el depósito Subversion, donde mantenemos sobre un esquema de manejo de versiones todos nuestros paquetes, programas y documentos, así como los cambios independientes que vamos realizando sobre de ellos.

Los módulos del CPAN ofrecen varias ventajas para su mantenimiento masivo colaborativo - A diferencia de lo que ocurre en muchos lenguajes, casi la totalidad los módulos están basados en una estructura de compilación ampliamente conocida (ExtUtils::MakeMaker o Module::Build). En primer término, esto permitió la creación de dh-make-perl, un script bastante genérico cuyo objetivo original era simplificar la creación de paquetes Debian directamente a partir del CPAN para ser instalados localmente por los administradores, pero que fue extendido por el grupo pkg-perl para automatizar la creación de paquetes.

Si bien formalmente el grupo pkg-perl cuenta con 70 miembros, en todo momento hay aproximadamente 15 miembros activos. Actualmente, el grupo es responsable por 660 paquetes - Responsable de dar seguimiento a los fallos reportados, de mantenerlos al día (tanto respecto a nuevas versiones producidas por sus autores como respecto a las políticas en Debian, que van cambiando poco a poco reflejando la evolución del proyecto), de realizar operaciones transversales de control de calidad a través de todos los paquetes, y demás.

Para simplificar la coordinación de todas estas tareas, los integrantes del grupo (especialmente Martín Ferrari, de Argentina, Gregor Herrmann, de Austria, y Damyan Ivanov, de Bulgaria) hemos creado un script que compara el estado de los módulos en CPAN, los paquetes en el depósito Subversion, los reportes en el sistema de seguimiento de Debian, y los paquetes publicados en la distribución misma de Debian. Hoy en día, este script es nuestra principal herramienta, brindándonos un reporte de estado condensado y adecuado específicamente a nuestro flujo de trabajo - Y tan útil resulta este resumen que actualmente estamos adecuando este script para que lo utilicen también otros grupos con un enfoque similar; probablemente para cuando este artículo esté impreso, lo estén utilizando ya los grupos de empaquetamiento de Python y Java - habiendo varios más en el horizonte.

En resumen, el ejemplo que aquí presento es sólo uno de tantos - Pero es ilustrativo. Bajo el modelo del software libre, las barreras entre desarrollo e integración se desvanecen, y el contacto directo entre usuario final y los desarrolladores deja de ser una rara ocurrencia, y se vuelve la norma - algo que damos por supuesto en todo momento de nuestros desarrollos.

Escribí mi proyecto final de graduación implementando un wrapper genérico de conexiones que puede ser extendido para comprender y proteger protocolos específicos. Presenté mi proyecto en el YAPC::NA 2001, y publiqué un corto artículo en la revista ;login: de Usenix, en el número de Junio del 2002.

• Proyecto final completo (130 páginas, PDF)
• Proyecto final completo (convertido a HTML)
• Texto publicado en las memorias del YAPC::NA 2001 (PDF)
• Texto publicado en la revista ;login:, Junio de 2002 (PDF)
• Código de ProtoWrap 0.5, instalable como módulo de Perl. Hay pequeñas diferencias entre este código y la versión publicada en el proyecto final.

Un tutorial que presenté para el Congreso de Seguridad en Cómputo en noviembre del 2000, y tras reescribirlo en un formato libre y portable, lo presenté de nuevo en los Días de Software Libre en Guadalajara, mayo del 2002. Lo adapté y traduje junto con mi compañero de trabajo Alex Juárez, y lo presentamos en el YAPC::Europe::2002. Reviso aquí una serie de puntos importantes para no caer en importantes errores de seguridad al programar con Perl. Está tanto en inglés como en español.

• Artículo completo en español (como HTML)
• Artículo completo en español (formato nativo LyX)
• Artículo completo en inglés (HTML; escrito nativamente en este formato)
• Láminas Magicpoint en inglés (formato nativo Magicpoint)
• Láminas Magicpoint en inglés (como HTML)

Tutorial que presenté en el congreso Seguridad en Cómputo 2000, dando varios ejemplos de pequeños scripts en Perl que pueden ayudar a la seguridad de un sitio.

SmbGate es un pequeño programita escrito en Perl (usando el framework Embperl) que permite a los usuarios conectasre a sus directorios raiz de un servidor SMB (sea Samba sobre algún Unixoide o Windows), implementando acceso de sólo lectura, sobre una interfaz Web

Copyright (c) 2003,2005 Gunnar Wolf - gwolf@gwolf.org

RAZONES

Comencé a usar mutt como mi lector de correo hace un par de meses. Una de las características que más me gustaron de mutt es que los mensajes normalmente aparecen ordenados por hilo - esto ayuda realmente a seguir una conversación larga en una lista muy activa!

Para preservar el hilado de los mensajes, decidí archivar todos mis mensajes viejos - claro, tal como acostumbran hacer los usuarios de mutt. Cada lista va para un folder diferente, y la vida es bella.

Sin embargo, la vida no era perfecta. Después de un par de semanas, algunas de mis listas tenían tanto tráfico -con más de 2000 mensajes archivados- que a mutt le tomaba demasiado tiempo ya abrirlos. Y si bien parte de la culpa puedo echársela a que uso buzones en formato mbox, el cambiar a maildir no haría más que posponer este mismo problema por un par de semanas. Y no quería cortar artificialmente el buzón cada cierto tiempo, pues perdería los beneficios de mis queridos hilos.

Me encontré con el maravilloso y tremendamente completo módulo de Perl Mail::Box, y me dí cuenta que mover hilos completos era muy simple, así que escribí este programita que expirara hilos en vez de mensajes individuales.

USO

El uso es muy simple. Antes que nada, como siempre:
eot -h
te dará una lista de las opciones de EOT, todas ellas opcionales (aunque usualmente querrás especificar al menos -f y -F).

Las opciones válidas son:

eot -f <from_mailbox> -t <from_type> -F <to_mailbox> -T <to_type> -p <period>
All arguments are optional.
opt  description                                        default
======================================================================
-f   Which source mailbox to use                        mailbox
-t   What format is this mailbox in (mbox, maildir, mh) mbox
-F   Which destination mailbox to use                   mailbox.arch
-T   What format is this mailbox in (mbox, maildir, mh) mbox
-p   Period of time to declare a thread as old, in days 7
-v   Whether to report work statistics to STDOUT        0

-f and -F se refieren a un buzón -un archvio si es tipo mbox o un directorio si es tipo maildir o MH- en el directorio local, o un path completo o relativo al buzón en cuestión.

-t y -T indican el tipo de buzón a abrir - mbox, maildir or mh.

-p indicates how old (in days) should the last message in a thread be
for the whole thread to be considered inactive.

Si no especificas -v, EOT correrá en silencio. Si especificas -v un
corto resumen de actividad aparecerá después de correr.

LICENCIA

EOT is está cubierto por la GNU GPL versión 2 o superior, a tu discreción.
El texto completo de la GNU GPL puede ser encontrado aquí.

REQUISITOS

EOT fue escrito en Perl, y por tanto requiere Perl (versión 5 o
superior). Además de esto, EOT requiere de los siguientes módulos de
Perl:
Mail::Box (probado con 2.038)
Date::Parse - parte de TimeDate (probado con 1.1400)

Puedes encontrarlos en el CPAN. Si usas un sistema Debian, están respectivamente en los paquetes libmail-box-perl y libtimedate-perl.

AUTOR

EOT fue creado por Gunnar Wolf (gwolf@gwolf.org) en mayo del 2003. Puedes usarlo libremente para el propósito que sea, siempre que te
atengas a la licencia GNU GPL.

BAJARLO

Ok, veo que te interesó ;-)

Puedes bajar la versión 1.1 de EOT aquí.

Un sistema que hice cuando trabajé para la FES Iztacala. Ayuda a los administradores de redes en su ardua labor relacionando direcciones IP y MAC, generando configuraciones para el servidor de DHCP y ARP.
Varios años más tarde, ya trabajando en el IIEc UNAM, prácticamente lo re-escribí completo, más limpio, con una capa orientada a objetos, utilizando Template Toolkit para la presentación, y como módulo de Apache (con mod_perl). Ambas versiones son funcionales y usables - Aquí están ambas. Ambas están, sin embargo, en un estado de "snapshot", con pequeñas omisiones en lo que concierne a funcionalidad y documentación.
IPManage (versión de 2003, orientada a CGI)
IPManage (versión de 2007, OOP, basada en mod_perl)

Esta la preparé para el Congreso GNU/Linux 2002, preparado por el GULEV en el puerto de Veracruz, en diciembre del 2002. Presento a qué proceso de desarrollo sigue la i creación de esta nueva versión de Perl, y qué cambios principales podemos esperar para este lenguaje.
La presentación la hice en Magicpoint; puedes bajar el archivo fuente Magicpoint, o si prefieres, ver la presentación convertida en HTML

Un pequeño curso que impartí en agosto del 2002 en los Talleres de Linux en la UPN, cuyo objetivo es enseñar los principales elementos de la programación en Perl.

RAZONES

OpenBSD es un sistema operativo estable, robusto y seguro. Los administradores de sistemas que corren OpenBSD tienden a ser mas conscientes de la seguridad que los administradores corriendo otros sistemas operativos. En ocasiones, parchar un sistema OpenBSD puede volverse un proceso tedioso para muchas personas. Si una persona se encarga de muchos servidores OpenBSD, el parchar cada uno de ellos puede ser una tarea larga y repetitiva, ideal para automatizarla.
Tepatche revisará periódicamente el sitio FTP que se le indique, y si hay un nuevo parche que pueda ser aplicado, lo descarga, aplica, compila e instala. Tepatche mantiene una pequeña base de datos de estado para saber en que estado se encuentra cada uno de los parches del sistema.

REQUISITOS

• Una instalación completa de OpenBSD (incluyendo el código fuente en /usr/src y los fuentes del kernel en /usr/src/sys). Tepatche fue probado con OpenBSD versión 3.1, pero mientras se diseñaba, los parches para el 2.9 y 3.0 también fueron estudiados y, como el formato es el mismo, deben de funcionar. Es importante mencionar que la versión 2.9 y versiones mas viejas ya NO SON MANTENIDAS, no hay nuevos parches que sean liberados para ellos. Es importante que se haga una actualización en caso de que estes corriendo una versión vieja.
• Tepatche usa el módulo de Perl Net::FTP. Puedes instalarlo desde los ports (p5-libnet) ó desde CPAN. Tepatche fue diseñado y probado con p5-libnet-1.0901, la versión de los puertos 3.1.

NOTAS

• Tepatche esta liberado bajo la licencia BSD - Leer el archivo COPYING
• Este es código EXPERIMENTAL. A mi me funciona. Sin embargo, es código hecho para ser corrido como root y para modificar binarios vitales del sistema, y un error de programación puede llevar a consecuencias desastrosas.
• Tepatche asume que los parches publicados en el ftphost especificado son confiables. Si el ftphost (normalmente ftp.openbsd.org o uno de sus espejos) fueran comprometidos, cualquier cosa pudiera pasar. Si Tepatche instala un parche comprometido, puees revertirlo con la opción de parche -R (ver man patch(1)). Hay que notar que Tepatche no correrá cualquier comando que encuentre en un parche, solo los que reconozca... pero hay mucho espacio ahí.
• Si el aplicar un parche requiere una compilación del kernel, el administrador del sistema DEBE HACERLO MANUALMENTE. Tepatche parchará los fuentes, pero compilar el kernel involucra muchos pasos que requieren que se opere manualmente.
• Tepatche SOLAMENTE parchará el sistema base - Si usas ports extra, estos NO serán parchados. Por favor véase las notas referentes a los ports y a la auditoría de seguridad en: http://www.openbsd.org/ports.html

USO

Tepatche consiste en un archivo de programa (/usr/local/sbin/tepatche), un archivo de configuración (/etc/tepatche.conf) y un directorio de datos (/var/db/tepatche). El archivo de configuración contiene los siguientes campos:

• ftphost: Servidor FTP a conectarse (ej: ftp.openbsd.org)
• ftpdir: La base del directorio FTP para los parches (ej: /pub/OpenBSD/patches/3.1)
• ftppasv: Donde el modo pasivo FTP es requerido (1) o no (0)
• ftplogin: usuario y password para ingresar (separado por una coma, ej: anonymous, gwolf@gwolf.cx)
• archs: Lista separada por comas de arquitecturas a descargar (ej: i386, common) Por favor, recuerda incluir common!
• patchdir: Donde los parches serán almacenados en nuestra computadora (ej: /var/db/tepatche)
• statusfile: Localización del archivo de estado (ej: /var/db/tepatche/statusfile)

Con este archivo en su lugar, Tepatche corre simplemente sin argumentos, solo /usr/local/sbin/tepatche. Sugiero que lo corras desde tu crontab (ver man crontab(5)). Sugiero correrlo una vez al día, cuando mucho una vez por cada hora - por favor no inundes ftp.openbsd.org con peticiones cada minuto ;-)

ARCHIVO DE ESTADO

Tepatche mantiene la información que necesita acerca del estado del sistema en el 'statusfile' (por default, en /var/db/tepatche/statusfile). Este es un archivo de texto plano con el siguiente formato:
<descriptor>::<status>
Donde 'descriptor' es una cadena alfanumérica, y 'status' es un número de estado válido. Los números válidos son:

• 1: nuevo - El parche acaba de ser bajado.
• 2: aplicado - El parche ya fue aplicado al árbol de fuentes
• 3: construído - Los binarios relevantes ya fueron generados en el árbol fuente
• 4: instalado - Los binarios fueron ya instalados en su lugar. El parche ya fue completamente instalado.
• 5: kernel - El parche requiere recompilar el kernel. Cuando tepatche llega a este estado, el parche fue aplicado, pero aún no ha sido construído..
• 10: error - Ocurrió un error en algún punto del proceso de parche

El descriptor usualmente llevará el formato <arch>/<num>_<description>.patch - Indica la arquitectura para la cual fue creado, el número consecutivo de parche, una muy corta descripción acerca de su función, y el sufijo '.patch'. Esta es la nomenclatura estándar que sigue el equipo de Open:BSD. Un nombre ejemplo podría ser:
common/001_sshafs.patch
Esto indica que el parche será aplicado a todas las arquitecturas (common), que es el primer parche producido para esta versión del sistema (001), y que corrige problemas relacionados con 'sshafs'.
Si quieres modificar este archivo (claro está, BAJO TU PROPIO RIESGO), puedes seguir estas convenciones para indicar a Tepatche el nuevo estado del parche. Por ejemplo, en la versión 3.1 de OpenBSD apareció un bug muy peligroso en OpenSSH. El equipo de OpenBSD sugirió actualizar de inmediato a OpenSSH 3.4. Posteriormente, para la gente que no actualizó, publicaron un parche (common/006_sshpreauth.patch). Mucha gente ya instaló el árbol de 3.4, con lo que modificaron manualmente el directorio /usr/src/usr.bin/ssh lo cual hace necesario editar /var/db/tepatche/statusfile y reemplazar
common/006_sshpreauth.patch::10
por
common/006_sshpreauth.patch::4

POR HACER

Al menos:

• Hacer la salida mas amigable (a medio-hacer)
• Manejo mas confiable de errores (a medio-hacer)
• (tal vez) incluir un mecanismo de compilación del kernel
• Probar, probar, probar

DESCARGAS

Puedes obtener Tepatche (actualmente version 0.85) Justo aqui.
Si te interesa leer el artículo publicado en la edición de diciembre del 2003 de SysAdmin, aquí lo tienes.

¿POR QUE TEPATCHE?

Tepatche es una bebida ligeramente alcohólica en México, en donde yo vivo y donde el programa fué concebido. Tepache es el resultado de
fermentar piña en agua. Tomado de http://www.fao.org/docrep/x0560e/x0560e09.htm :
Tepache es una bebida ligera, refrescante preparada y consumida en todo México. En el pasado, el tepache era preparado con maíz, pero en la actualidad varias frutas como la piña, manzana y naranja son usados. La pulpa y el jugo de la fruta son puestos a fermentar por uno o dos días en agua con algo de azucar morena. La mezcla es puesta en barriles de madera sin tapa llamados "tepacheras", que se cubren con trapos queseros. Después de uno o dos días, el tepache es una dulce y refrescante bebida. Si se deja fermentar por mas tiempo, se convierte en una bebida alcohólica y después en vinagre. Los microorganismos asociados con el producto incluyen al Bacilo Sutbtilis, Torulopsis insconspicna, Saccharomyces cerevisiae y Candida queretana (Aidoo, 1986).
Si eres curioso, puedes encontrar recetas de como preparar tepache (en español) en http://www.chi.itesm.mx/chihuahua/arte_cultura/cocina/bebidas/tepache.ht... o http://mexico.udg.mx/cocina/bebidas/tepache.html

AGRADECIMIENTOS

Primero y sobre todo, quiero agradecer al equipo de OpenBSD por la increíble cantidad de trabajo que hay puesto en este proyecto.
En menor escala, Tepatche no hubiera sido posible sin la ayuda de OpenBSD México. En este proyecto específico, recibí una gran ayuda de Alex Juárez, César Yáñez y Karl Heinz Holtschmit.
Por supuesto, quiero agradecer a mi lugar de trabajo, UNAM FES Iztacala, por permitirme en trabajar en seguridad y software libre por casi 3 años - Y espero sean muchos mas.