PDF de programación - Migasfree en la Gestión de la Configuración Software

Migasfree en la Gestión de la Configuración Software

Libre Software World Conference 2011

9 noviembre de 2011

Alberto Gacías

Introducción

# 1
Me llamo Alberto Gacías y trabajo en el Servicio de Redes y Sistemas del Ayuntamiento de
Zaragoza, desarrollando y manteniendo AZLinux, el escritorio libre que usamos a día de hoy unos
600 trabajadores municipales, y voy a enseñarte a continuación el método que empleamos en
AZLinux para personalizar nuestros escritorios.

# 2
En primer lugar voy a repasar algunos conceptos básicos sobre la Gestión de la Configuración
Software (en adelante GCS).
Esto me permitirá establecer la base desde la que poder tratar las dificultades que vas a encontarte a
la hora de personalizar los escritorios GNU/Linux de tu organización, y de cómo puedes superarlas.
Finalmente veremos migasfree, la herramienta que ha sido clave en la evolución de AZLinux.

1.- La Gestión de la Configuración Software

#3
Un hombre no puede bañarse dos veces en el mismo río, porque el segundo día el río ya no es el
mismo, y ni siquiera ese hombre es el mismo. “Nada es permanente a excepción del cambio” dijo
Heráclito de Éfeso.

# 4
Dejando aparte la filosofía y centrándonos sólo en el mundo del software podemos decir que el
cambio es inevitable y además es deseable.
Inevitable porque los desarrolladores no podemos evitar cometer errores y es mediante la
modificación, o cambio en el software, que estos errores son corregidos. Son los llamados cambios
correctivos.
Por otro lado el cambio es deseable ya que a menudo queremos incorporar nuevas funcionalidades
al software o mejorar aquellas que ya existían. Mediante los cambios evolutivos es como

mejoramos el software.
Estos cambios se producen desde que concebimos, construímos y tambien mientras mantenemos un
proyecto software, es decir durante todo su ciclo de vida.

# 5
El gran reto de los proyectos software reside precisamente en gestionar, de forma controlada, dichos
cambios usando alguna estrategía que favorezca y facilite el cambio.
De esto trata precisamente la GCS, un proceso de la Ingeniería del Software que identifica, hace
seguimiento y controla cada uno de los cambios que se producen en los sistemas.

#6
El objetivo de la Gestión de la Configuración es conservar la integridad de los sistemas frente a los
cambios.
Un sistema será íntegro frente al cambio si:

• mantiene correctamente las relaciones entre los distintos cambios a medida que se van

produciendo (el típico problema de dependencias entre elementos)

•

y además permite la auditoría de cambios (conocimiento del estado de un sistema al que se
le han ido aplicando cambios sucesivamente)

#7
El proceso de la GCS es un conjunto de actividades que nos permitirá garantizar dicha integridad, y
que podemos resumir en: petición de cambio, cambio y liberación.
Peticion de cambio: Cuando se nos reporta un error o una petición de mejora, lo primero que
hacemos es identificar el elemento de configuración software (ECS) al que se refiere.
Un ECS es cualquier objeto software sometido a la GCS. Puede ser un manual de usuario, una
especificación, un conjunto de datos para realizar tests, una aplicación, una librería, incluso las
herramientas que se usan para realizar los cambios, etc.
Una vez identificado el ECS se registra la petición de cambio. Las herramientas típicas para
registrar y hacer el seguimiento del cambio son los llamados gestores de proyectos (Redmine,
Bugzilla, Tracker, etc. )
Cada petición de cambio es analizada más tarde pudiendo ser aceptada o rechazada. Si es
rechazada se avisa al informador y se cierra la petición; si es aceptada se asigna la petición a alguien
para que realice dicho cambio.
El cambio es la actividad que modifica el ECS, generando una nueva versión del ECS. En esta
actividad se utilizan un conjunto muy diverso de herramientas, desde procesadores y editores de
texto, sistemas de control de versiones, entornos de desarrollo integrados (IDE), depuradores,
compiladores...
La liberación es la actividad de situar la nueva versión del ECS generada, en un repositorio o
almacén para que posteriormente los clientes del ECS puedan acceder a él e instalarlo.

#8
Si observamos como en el mundo del software libre los distintos proyectos (Gnome, KDE,
LibreOffice, Mozilla Firefox, Gimp, … migasfree, etc.) realizan la GCS, vemos que realizan las
actividades mencionadas liberando finalmente el código fuente del proyecto en internet, pero
podemos observar cómo trabajan con distintos tipos de ECS (.png, .txt, .py, .c, .bin, etc.) usando
los Sistemas de Control de Versiones que les proporcionan las denominadas forjas de proyectos
(plataformas de desarrollo colaborativo como sourceforge.net, github.com, etc.)
Este código fuente será posteriormente compilado por los mantenedores de las Distribuciones
GNU/Linux (Fedora, Red Hat, Debian, Ubuntu, etc.) realizando su propia GCS, pero a diferencia de
los primeros, las Distribuciones GNU/Linux sólo trabajan sobre un único tipo de ECS: el paquete,
donde introducirán el programa ya compilado.
Este simple hecho permite garantizar la integridad frente a los cambios de forma eficaz y sencilla
como veremos a continuación.


#9
Un paquete es un contenedor que encapsula un ECS liberado por un determinado proyecto, más su
metainformación.

Contendrá, por tanto, el programa compilado para una determinada Distribución y arquitectura, más
un conjunto amplio de información como puede ser: el autor del programa, la dirección del
repositorio del proyecto, la versión del ECS, arquitectura, nombre del empaquetador, fecha de
empaquetado, nombre del equipo en que se produjo el empaquetado, una descripción corta del
contenido del paquete, una descripción larga, …
Pero además suelen incluir:

1. Código a ejecutar antes y después de instalar, actualizar o eliminar el paquete.
2. Dependencias con otros paquetes.

Una vez que la Distribución GNU/Linux ha compilado y creado el paquete, lo libera poniéndolo en
un repositorio público o almacén, a disposición de los clientes.

#10
¿Y cómo se actualizan los paquetes en los distintos escritorios GNU/Linux?
Los encargados de aplicar los cambios son los llamados gestores de paquetes. Un gestor de
paquetes es un programa que compara los paquetes instalados con los paquetes de los repositorios
configurados, detectando los que han sido modificados (han aumentado su versión), resolviendo sus
dependencias y finalmente, si no hay conflictos, obtienen desde los repositorios sólo los paquetes
necesarios. Ejemplos de gestores de paquetes son yum, zypper ó apt.
Una vez han descargado los paquetes, dan órdenes a los backends (rpm, dpkg, etc.) para que se
produzca la actualización. Los backends abren el paquete, y grosso modo:

1. Extraen los ficheros del programa copiándolos en el sistema, y ejecutando además el

código programado para antes y después de la actualización.

2. La metainformación es extraída del paquete y se almacena en la base de datos del

backend.

Decía Ian Murdock, fundador de Debian, que el gran aporte del software libre a la industria ha sido
precisamente la invención del sistema de paquetería (paquete, repositorio, gestor de paquetes). Y no
es para menos, ya que este sistema nos proporciona los dos requisitos necesarios que veíamos
anteriormente y que garantizarán la integridad frente a los cambios, es decir:
1. El control de dependencias, mediante el gestor de paquetes.
2. La auditoría, mediante las consultas a la base de datos a través del backend.

Si estás acostumbrado a instalar programas mediante el típico “./configure, make, install”, tienes
que hacerte consciente que estás rompiendo la integridad frente a los cambios cuando lo haces, ya
que la base de datos del backend no es actualizada con este procedimiento (en la auditoría no saldrá
reflejada este programa y además es posible que una actualización posterior del sistema podría
hacer que tu programa dejase de funcionar). Tenlo en cuenta.
Recuerda esto: Todo lo que no sea instalar programas mediante el gestor de paquetes o el
backend, rompe la integridad frente a los cambios de tu sistema.

2.- Administrando escritorios GNU/Linux

# 11
Hasta aquí, he hablado de la GCS en general, y de cómo las Distribuciones GNU/linux en particular
utilizan el sistema de paquetería para garantizar la integridad frente al cambio.
Esto está muy bien si tienes un equipo doméstico, ya que con el simple hecho de dar la orden al
gestor de paquetes para que actualice tu sistema, todos los cambios producidos por los distintos
proyectos que forman parte de tu Distribución GNU/Linux serán actualizados correctamente.
Pero en una organización, la primera dificultad importante a la que se va a enfrentar un
administrador va a ser el de la personalización.

# 12
Imagina que tienes que migrar 1000 equipos a GNU/Linux. Imagina también que tienes en tu red un
servicio NTP y se requiere que todos tus escritorios estén con la hora sincronizada con este servicio.
Vas a tener que personalizar el cliente NTP en todos tus escritorios. Una solución sería partir de una
instalación desde el DVD de la Distribución que hayas elegido, editar el fichero de configuración
del cliente NTP y configurar la IP del servidor donde se encuentra el servcio NTP. Después puedes
crear una imagen del disco duro con Clonezilla y migrar uno a uno los 1000 equipos usando dicha
imagen. Una personalización inicial usando este metodo es sencilla de realizar y puede ser muy útil.
Pero sigamos, sigamos imaginando. Un día a mitad de migración recibas una llamada como esta:

¿Alberto?

–
– Dime Félix, ¿qué pasa?
–
– Claro, yo hice en su día la personalización de los clientes.
– Verás, a partir del día 10 va a dejar de dar servicio y en su lugar vamos