linux

Empaquetando software para Debian: Herramientas y procesos básicos

Submitted by gwolf on Tue, 09/11/2012 - 18:39
Written in...: 
2012

While it is true that there are many non-technical areas where you can contribute to help Debian grow, fact is how to create a Debian package is a recurring question among people interested in getting into Debian. In this talk/tutorial we will see the basic points of packaging, understanding how to build a simple package.

Points to cover:

  • What is a package?
  • What is apt's role? And dpkg's?
  • What do I need in order to create a simple package?
  • Dependencies, recommendations, and everything that surrounds it

If we have enough time, I'd like to touch some points on team maintainership (keeping packages in version control systems, schemes and tools for group coordination and communication, etc.)

Resumen: 

Si bien hay muchas áreas no técnicas con las que puedes contribuir con el desarrollo de Debian, la duda recurrente entre los interesados en acercarse a formar parte de Debian es cómo se hace un paquete. En esta charla-tutorial veremos los puntos básicos del empaquetamiento, comprendiendo cómo esta compuesto un paquete sencillo.

Puntos a cubrir:

  • ¿Qué es un paquete?
  • ¿Cuál es el rol de apt? ¿Y de dpkg?
  • ¿Qué necesito para crear un paquete sencillo?
  • Dependencias, recomendaciones, y todo lo que lo rodea

Si nos da tiempo, me gustaría tocar puntos de mantenimiento en equipos (mantener paquetes en sistemas de control de versiones, esquemas y herramientas de comunicación y coordinación en equipo, etc.)

Arquitecturas de paquetes al rescate

Submitted by gwolf on Fri, 06/18/2010 - 07:35
Wolf G.  2010.  Arquitecturas de paquetes al rescate. Software Gurú.

Modularización: Arquitecturas de paquetes al rescate

Convirtiendo a la hidra en nuestra aliada

En el número 27 de Software Gurú, Agustín Ramos presentó un artículo acerca de estrategias para lograr una modularización efectiva en Java. Varios de los puntos de su artículo me llevaron a dedicar la presente columna a explicar a qué llamamos una distribución de Linux, y cuál es su relación –y la solución que ofrece– a los problemas derivados de la complejidad derivada de la modularización, que bien describió Agustín.

Como deben ya saberlo, a diferencia de otros sistemas operativos, el entorno operativo completo al que normalmente nos referimos como Linux no es desarrollado por un sólo grupo, ni sigue un roadmap, criterios o visión en común. Mucho se ha argumentado acerca de las características que diferencían a los proyectos desarrollados desde planteamientos libres de aquellos desarrollados siguiendo metodologías tradicionales — No abordaré dicha discusión en este momento. Sin embargo, no quiero dejar de aprovechar la oportunidad de tener un artículo escrito por un colega en esta revista para ilustrar cómo abordamos la relación entre proyectos independientes –que logran una complejidad de miras mucho mayor que cualquier instancia de conjuntos de módulos desarrollados en casa– en el Software Libre, por qué enfatizamos tanto en lo prevalente que resulta dicha modularización, y cómo nos enfrentamos a su inherente complejidad.

Los sistemas basados en Linux son estructurados, pues, en distribuciones. Una distribución es un conjunto de programas –típicamente del órden de miles– que, entre todos, presentan la funcionalidad que un usuario espera ya no sólo de un sistema operativo sino que de todo un entorno operativo integrado. Además, se encargan de gestionar las relaciones de dependencia entre dichos programas, y resolver dichas dependencias, para facilitar al usuario la instalación, remoción y actualización de software.

Una instalación mínima de cualquier distribución de Linux no tiene menos de un par de centenares de paquetes individuales. El núcleo Linux, por sí mismo, no representa más que la interfaz más básica para presentar una abstracción del hardware ante los programas que corren sobre él. Formalmente, al mencionar Linux ni siquiera nos referimos a la interfaz de línea de comandos (misma que generalmente es provista por los paquetes bash, dash o sash, dependiendo de las necesidades del administrador). Son en realidad contados los paquetes que no dependen más que de paquetes esenciales. Toda distribución define un pequeño conjunto (decenas) de programas que es fundamental tener instalados como base para cualquier otro, conjunto mínimo que asumimos que siempre estará ahí para asegurarnos la funcionalidad mínima.

Si bien las primeras distribuciones tuvieron por objetivo facilitar la instalación de un sistema basado en Linux a usuarios con menor involucramiento técnico, y fueron instrumentales en la primer ola expansiva de usuarios que fuimos adoptando Linux hacia mediados de los 1990, han trascendido ya a éste rol para dar respuesta al infierno de dependencias al que se refiere en su texto Agustín Ramos: Hacia fines de los 1990, aproximadamente cuando todas las distribuciones comenzaban a contar en miles los paquetes independientes que ofrecían, comenzó a hacerse obvio que no bastaba con que cada paquete indicara de qué otros paquetes dependía (incluyendo, claro está, la información de versiones pertinente), sino que era necesario contar con una arquitectura de paquetes: Un esquema orientado a depósitos y no a paquetes individuales, que se encargara de resolver las dependencias cada que el administrador instalara o eliminara un paquete. La primera arquitectura fue introducida por la distribución Debian, bajo el nombre de apt: A Package Tool. Es definitivamente gracias a apt que, al día de hoy, la versión de desarrollo de Debian cuenta con 15640 paquetes fuente independientes, que resultan en 27886 paquetes binarios, cubriendo prácticamente todas las áreas de necesidad en cómputo, tanto a nivel de aplicaciones como de bibliotecas.

A diferencia de otras arquitecturas previas, como los ports de los Unixes BSD, Apt está además construido basado en el manejo de depósitos múltiples. Esto significa que, además de servirme para instalar los paquetes oficiales de la distribución, nos permite definir depósitos adicionales con el software que desarrollemos localmente, así como de paquetes adicionales que preparemos localmente para uso en nuestra organización.

Con esto como introducción, veamos cómo ésto se aplica al texto de Agustín. Por razones de espacio, me enfoco a cómo éste esquema reduce fuertemente los efectos negativos de la modularización, permitiendo a los desarrolladores crear software más robusto y temer menos a esta tan dificil de conciliar fuente de dolores de cabeza.

Demasiadas dependencias
El argumento principal mencionado en el texto al que hago referencia en contra de tener demasiadas dependencias es la posterior dificultad de instalación de nuestros sistemas. Sin embargo, al crear paquetes con la información de las dependencias, convertimos el fastidioso proceso de instalación (y todo el tiempo que requiere documentarlo) en una sóla instrucción al sistema.
Dependencias cíclicas
Coordinar el trabajo de cientos de voluntarios en todo el mundo, sin más factores de cohesión que su voluntad por crear un sistema de calidad trae como resultado natural el que parte importante de sus esfuerzos estén encaminados a la creación de documentos de políticas comprehensivos — y a que su comunidad de desarrolladores comprenda la importancia de dichos documentos.
Claro está, si la unidad atómica de trabajo en una distribución es el paquete, problemas tan claros como las dependencias cíclicas fueron de los primeros puntos en ser prohibidos por política. Sin embargo, conforme la complejidad de cada uno de los paquetes aumenta, se vuelve posible que aparezcan dependencias cíclicas de indirectas. Para evitar problemas como este, y otros destinados del control de calidad en sistemas complejos, se hacen revisiones periódicas de todos los procesos imaginables.
En este aspecto, si bien no hay balas de plata para evitar las dependencias cíclicas, contamos con una comunidad de desarrolladores verificando que estos problemas se mantengan al mínimo. No estamos sólos en el manejo de nuestros proyectos.

Largas cadenas de dependencias
Este fue precisamente el punto que motivó al desarrollo de las arquitecturas de paquetes. Podemos confiar en que la arquitectura que elijamos, empleando los depósitos del sistema y de nuestra organización, sepan resolver este punto sin que represente problemática alguna. Además, no tenemos por qué limitarnos al uso de este esquema para las dependencias de los componentes externos que empleemos. Si dentro de nuestra organización nos acostumbramos a empaquetar nuestro código en componentes, la reutilización de código que podamos hacer será muchísimo más simple y más natural.
Dependencias en conflicto
Nuevamente, aquí acudimos a la sabiduría de las masas, a la fuerza de la multitud. Una distribución basada en Linux no es sólo un conjunto de programas disponibles a través de un mismo depósito — La mayor parte del trabajo de sus creadores es asegurarse que todos los componentes sean mutuamente compatibles, y asegurar a los usuarios un producto de calidad, con todas las actualizaciones necesarias para asegurar su seguridad (cuidando no compormeter su estabilidad) durante su ciclo de vida.
Este puede ser un punto fundamental al elegir qué distribución vamos a usasr para determinado proyecto: Hay distribuciones principalmente orientadas al perfil de usuario de escritorio, para el cual es fundamental tener siempre soporte completo para el último hardware, aceleración gráfica compelta y demás bondades. Sin embargo, para basar nuestros desarrollos empresariales, típicamente preferiremos las distribuciones con ciclos de vida más largos, con un mayor soporte a largo plazo.

Como pueden ver, manejar una arquitectura de paquetes simplifica algunas de las tareas más complicadas (y más ingratas) del desarrollo de software, el manejo de toda la talacha creada por los componentes que, a fin de cuentas, incluimos para ahorrarnos trabajo.

Cuando veo los instaladores típicos, que crean enormes amasijos (típicamente en forma de enormes instaladores .msi o archivos .jar que incluyen copia de todas las dependencias para evitar estos problemas), no exagero: Me dan ganas de llorar. Porque además, al tener varias copias de una misma biblioteca en el sistema, tengo la certeza de que en caso de aparecer algún defecto en alguna de ellas, habrá componentes de mi sistema que reciban la corrección en cuestión — pero habrá otros que no. Acostumbrarse al manejo de dependencias externas nos reduce la tentación de acudir al tan temido ligado estático, reduce el peso de nuestras imágenes de instalación (y de nuestros sistemas ya instalados), y ayuda fuertemente a mantener un mayor control de calidad en nuestros procesos como un todo.

Mucha gente evita aprovechar la modularización como medida preventiva para no perder la razón resolviendo dependencias y bugs creados por compatibilidad incompleta entre versiones. Sin embargo, dejar de usar buen software, ya existente y probado por terceros, sólo por no contar con las herramientas de seguimiento correctas es un triste error en el que debemos evitar caer. La hidra de la modularización a la que se refiere Agustín puede ser un mounstro mortal, pero si aprendemos a hablar con ella puede ser nuestro mayor aliado. Porque si dos cabezas piensan mejor que una, ¿qué decir de decenas de cabezas?

( categories: )

Estrategias de virtualización en Linux

Submitted by gwolf on Fri, 10/24/2008 - 17:26
Written in...: 
2008

Virtualization is the technique (or rather, the set of techniques) that allow to share a single computer's resources so that, for the user, it appears as several independent computers. There are several motivations to virtualize our systems, such as:
- Ease of administration (keeping our installations as simple as possible)
- Isolation/security (limiting the damage a potential attacker can achieve to the smallest possible domain)
- Resource control (avoiding a system failure to consume too many resources in others, leading to a denial of service - Or selling our computer resources by volume)
- High availability (transparent service migration between servers for maintenance tasks)

And a very long etcetera.

Virtualization is not a new technique in computer science, not even in the personal computer world - But there are several factors that have led to its rapid popularization in Linux. Now, there are several techniques through which we can get virtualization.

In this talk, I go over the main virtualization technologies currently available (in Linux and in other operating systems), comparing the strongest and weakest points between several of the available methods, and I present some cases, showing how to resolve several needs.

Resumen: 

La virtualización es la técnica (o más bien, el conjunto de técnicas) que permiten repartir los recursos de una sóla computadora para que, ante el usuario, aparezca como varias computadoras independientes. Virtualizar nuestros sistemas puede hacerse por diversas razones, como:

- Facilidad de administración (mantener nuestras instalaciones tan sencillas como sea posible)
- Aislamiento/seguridad (limitar el daño de un atacante potencial al dominio más reducido posible)
- Control de uso de recursos (evitar que un fallo en un sistema consuma demasiados recursos en otros, llevando a negación de servicio - O venta de servicios de cómputo por volumen de recursos)
- Alta disponibilidad (migración transparente de servicios entre servidores para tareas de mantenimiento

Y, claro, un largo etcétera.

La virtualización no es una técnica nueva en el cómputo, ni siquiera en el mundo de las computadoras personales - Pero hay varios factores que han llevado a que en los últimos años se haya popularizado rápidamente en Linux. Ahora bien, hay varias técnicas que nos brindan virtualización.

En mi plática revisaré las principales metodologías de virtualización actualmente disponibles (en Linux y en otros sistemas operativos), comparando los puntos más fuertes y más débiles entre los métodos comparables, y presento brevemente algunos casos, mostrando cómo resolver diversas necesidades.

Asegurando tu red con Linux

Submitted by gwolf on Sun, 02/10/2008 - 10:25
Written in...: 
2005

Short text going over several tools that can help a system administrator work on incident prevention, network monitoring and intrusion detection in Linux. I presented this talk in UNAM's Departamento de Seguridad en Cómputo internal admin-unam seminar, in June 2005. It was also published in the August 2005 issue of PC Magazine en español.

Resumen: 

Texto corto mencionando diversas herramientas que pueden ayudar a un administrador de sistemas implementar prevención de incidentes, monitoreo de red y detección de intrusos en Linux. Presenté esta plática en el seminario interno Admin-UNAM del Departamento de Seguridad en Cómputode la UNAM, en junio de 2005. Fue publicado además en la revista de agosto de 2005 de PC Magazine en español.

Evolución de los esquemas de seguridad extendidos en Unix

Submitted by gwolf on Sun, 02/10/2008 - 09:31
Written in...: 
2003

This talk was prepared for the National Free Software Conference CONSOL 2003 and for Computer Security DGSCA/UNAM 2003 Conference. I analize the main ideas that were used for designing Multics, which of those ideas were adapted for the Unix model, which main shortcomings the traditional Unix model has, and what ideas have evolved to make Unix better.

Resumen: 

Plática preparada para el Congreso Nacional de Software Libre CONSOL 2003 y para el Congreso de Seguridad en Cómputo DGSCA/UNAM 2003. Analizo las ideas principales que fueron empleadas en Multics, cuáles de ellas fueron adaptadas para el modelo de Unix, qué carencias tiene el modelo tradicional de Unix, y qué propuestas ha habido para mejorarlo.

Implementación de seguridad con sistemas operativos y herramientas libres

Submitted by gwolf on Sat, 02/09/2008 - 20:56
Written in...: 
2001

I gave this talk at the GNU/Linux 2001 conference in Jalapa, Veracruz, in September 2001. In this article I show different characteristics and security reccomendations using free operating systems and tools.

  • PDF (fit for printing)
  • HTML (fit for online viewing)
  • LyX sources (for editing or modifying)
Resumen: 

Esta plática la dí en el Congreso GNU/Linux 2001 en Jalapa, Ver., en septiembre del 2001. En este artículo muestro diferentes características y recomendaciones de seguridad utilizando los diferentes sistemas operativos y herramientas libres.

  • PDF (apto para imprimir)
  • HTML (apto para consultar en línea)
  • Fuente en LyX (apto para editar o modificar)

Recomendaciones de seguridad en Linux

Submitted by gwolf on Sat, 02/09/2008 - 16:44
Written in...: 
2001

Once again, I was invited to the seminar, with Computer Security Department of UNAM, this time in April 2001. The topic this time: Security guidelines in a Linux installation. How you can make a newly made Linux installation a difficult target for an attacker.
This same material, although updated and enhanced, was also presented as a tutorial at Congreso de Seguridad en Cómputo 2001, also organized (of course) by DSC, UNAM.

  • PDF (fit for printing)
  • HTML (for online viewing)
  • LyX sources (if you want to edit or modify it)
Resumen: 

De nueva cuenta, me invitaron a participar en el Admin-UNAM del Departamento de Seguridad en Cómputo de la UNAM, esta vez en abril del 2001. El tema expuesto en esta ocasión: Recomendaciones de seguridad en una instalación de Linux. Cómo hacer que un Linux recién instalado sea una presa muy
difícil para cualquier atacante.
Este mismo material, aunque bastante ampliado, lo presenté también como tutorial en el Congreso
de Seguridad en Cómputo 2001
, organizado también (claro está) por el DSC de la UNAM.

  • PDF (apto para imprimir)
  • HTML (apto para consultar en línea)
  • Fuente en LyX (apto para editar o modificar)

Aprovechando a Debian para la administración de sistemas

Submitted by gwolf on Mon, 02/04/2008 - 00:09
Written in...: 
2006

Beyond what the Debian policy gives us, a highly coherent system in which everything is in its place and works as it should (for what we the system administrators are really thankful for), we can find a great amount of tools for easing the homogeneity in the administration both in the planning of its package management system as in many packages we have at our disposition. We will go through this, as well as the process of creating .deb packages, beyond the basic instructions. This talk was originally prepared for CICOL, June 2006

Resumen: 

Más allá de lo que ya nos dan las políticas de Debian, un sistema altamente coherente en el cual todo está en su sitio (lo cual bendecimos los administradores de sistemas), tanto en la planeación de su sistema de paquetes como en varios paquetes que tenemos a nuestra disposición encontraremos una gran cantidad de herramientas para facilitar la homogeneidad en la administración de sistemas. Revisamos algunas de ellas, así como el proceso de creación de paquetes .deb, más allá de las instrucciones básicas. Preparado originalmente para el CICOL, junio 2006

Aspectos sociales del Software Libre

Submitted by gwolf on Sun, 02/03/2008 - 16:40
Written in...: 
2003

What social characteristics can define the Free Software developers? Are we really a homogeneous group? Which problems can appear when facing a global project? How can we avoid them? I analize mainly the Debian project, comparing a bit with the OpenBSD and Ximian/Gnome projects.
This talk was prepared for the 2003 GULEV conference.
It is available as:

Resumen: 

¿Qué características sociales definen a los desarrolladores de Software Libre? ¿Somos realmente un grupo homogéneo? ¿Qué problemas principales pueden darse al enfrentarnos con un proyecto mundial? ¿Cómo los evitamos? Analizo principalmente al proyecto Debian, comparando un poco con los proyectos OpenBSD y Ximian/Gnome.
Esta plática fue presentada en la edición 2003 del Congreso GULEV.
Está disponible como:

IPManage

Submitted by gwolf on Sun, 02/03/2008 - 15:24
Written in...: 
2003

A system I wrote while working for FES Iztacala. It helps a network administrator on his tough job relating MAC and IP addresses, generating configurations for the DHCP server and for ARP.
Several years later, already working at IIIEc UNAM, I practically re-wrote it from scratch, cleaner, with an object-oriented layer, using the Template Toolkit for the presentation, and as an Apache module (with mod_perl). Both versions are useful and usable - here you have both. Both are, however, in a "snapshot" state, lacking smaller bits of functionality and documentation.
IPManage (2003, CGI-oriented edition)
IPManage (2007, OOP, mod_perl-driven edition)

Resumen: 

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)

Introducción a Debian GNU/Linux

Submitted by gwolf on Sun, 02/03/2008 - 12:14
Written in...: 
2002

In this presentation, I explain what is Debian GNU/Linux, and what makes it be what it is. I presented it for Departamento de Seguridad en Cómputo's GASU seminar, May 2002.

The following files are very old, dating from the 2002 seminar I gave this talk at. Anyway, in case you are interested:

Resumen: 

En esta presentación muestro qué es Debian GNU/Linux y por qué es lo que es. La presenté para el Seminario GASU del Departamento de Seguridad en Cómputo, mayo del 2002.

Los siguientes archivos son ya muy viejos, de la primera vez que presenté esta plática, en el seminario GASU, julio del 2002. Como sea, por si te interesan:

Breve introducción a los sistemas de manejo de paquetes / Brief introduction to package management systems

Submitted by gwolf on Sun, 02/03/2008 - 11:15
Written in...: 
2002

A presentation prepared for Días de Software Libre, confernce organized by Melix at CUCEI (Guadalajara, May 2002). Here I talk about what are package management systems, why are they needed in modern operating systems, the main characteristics
for the main package management systems, and briefly explain how to create .deb (Debian) packages.
This talk is available as:

Resumen: 

Plática que preparé para los Días de Software Libre, organizado por Melix en el CUCEI (Guadalajara, mayo 2002). Hablo primero acerca de qué son y por qué son necesarios los sistemas de manejo de paquetes en los sistemas operativos modernos, menciono las principales características de los principales sistemas de paquetes, y explico brevemente cómo crear paquetes en formato .deb (para Debian).
Esta plática está disponible en dos formatos:

Tutorial de programación en shell (bash / bourne) / Shell (bash/bourne) programming tutorial

Submitted by gwolf on Sun, 02/03/2008 - 10:21
Written in...: 
2002

Tutorial (not completely finished) I gave together with Rodrigo Galladro at Congreso Nacional de Software Libre (CONSOL 2002). There are many aspects in this tutorial that are just outlined, but I hope you find it useful.

Resumen: 

Tutorial (no del todo terminado) que dí junto con Rodrigo Gallardo en el Congreso Nacional de Software Libre (CONSOL 2002). Hay bastantes aspectos de este tutorial que quedaron únicamente delineados, pero aún así, espero que sea de utilidad.
Puedes bajar el documento fuente en LyX; puedes también consultarlo traducido a HTML u como un documento PDF.
Como complemento, puede interesarte también el delineado para un tutorial de Bash avanzado que preparé para una plática a fines del 2007; está basado en el tutorial de Octavio Ruiz (Tacvbo)'s. Sólo delínea los puntos que cubrí, pero de todos modos puede ser un compendio útil.

Syndicate content