Demostración de empaquetado en RPM y distribución de software con migasfree

Esta charla presenta un caso práctico de uso de la herramienta migasfree.

Creación de un sencillo paquete RPM, que forma parte de la distribución Linux del Ayuntamiento de Zaragoza (AZLinux), y ver cómo se integra en el sistema de distribución de software migasfree.

Se presentan también las reglas básicas de creación de paquetes y se explica por qué se ha elegido esta fórmula en migasfree para distribuir cambios de configuración y software en la organización.

No es un taller para aprender a preparar paquetes, ya que se precisaría de más tiempo, sino una introducción a los sistemas de paquetería y una demostración del uso de la solución cliente/servidor migasfree en AZLinux.

Transcript

1. @jact_abcweb #migasfree Demostración de empaquetado en RPM y distribución de software con migasfree #lswc 2011 2011-11-09 Bienvenidos a la LSWC 2011 que se celebra en esta vuestra casa. Gracias por venir y por superar nuestras mejores expectativas. ¿Cuántos de aquí: * han asistido a la charla anterior? * son administradores de sistemas? * saben programar (en lo que sea)? * sabrían decirme lo que es migasfree?
2. @jact_abcweb #migasfree Como se puede observar en el gráfico, ante todo, soy informático. (Los informáticos son como los médicos, nunca están cuando se necesita uno. Y la gente se piensa que valemos para todo: desde arreglar un enchufe o una cafetera hasta llevar una sonda espacial a Marte.) Os resumo los datos importantes de la diapositiva: * Soy desarrollador web * Soy un apasionado del SL (he colaborado en proyectos como programador y traductor) * Soy MCP de M$ (conoce a tu adversario mejor que a ti mismo, decía Sun Tzu) ¿He mencionado que soy un experto en empaquetar software para sistemas Linux? NO. Como todo lo que me ha tocado hacer, he ido aprendiendo sobre la marcha. (Pienso que eso es lo que mejor define a un informático: es un autodidacta nato y lo tiene que ser toda la vida.)
3. @jact_abcweb #migasfree El problema a resolver en cualquier organización de más de un ordenador es cómo administrar de forma fácil los equipos de trabajo. Si todos tuvieran las mismas necesidades y no hubiera nuevas peticiones que atender, todo sería muy sencillo. Pero la realidad es que, lo único constante es el cambio. Si sólo tenemos que administrar una máquina y queremos tener tiempo para otras cosas (los administradores solemos ser personas muy vagas, y esto es algo bueno, porque pensamos mucho antes de resolver un problema...), la opción adecuada es empezar a automatizar tareas en forma de scripts. Si el parque empieza a crecer y primero añadimos una máquina y luego otra..., replicamos la tarea ejecutando esos scripts en tantas máquinas como tengamos. Pero si tenemos que administrar un número de ordenadores grande (3 o más, es un buen número...), tenemos que pensar en otro sistema, una herramienta centralizada, para resolver cuestiones como: * Aplicar cambios selectivos (sólo en algunas máquinas) * Tener un control de que los cambios se han producido * Tener un historial de los cambios en cada máquina * Aplicar cambios de forma gradual para no saturar nuestra red Organizar los cambios en paquetes en lugar de en simples scripts, es la solución para administrar sistemas. Esto mismo también vale para el mundo Windows, pero os puedo asegurar que es mucho más fácil hacer paquetes de software en Linux. Tener los cambios empaquetados nos aporta las siguientes ventajas: * Gestión centralizada en repositorios (almacenes de paquetes). * Los paquetes aseguran la integridad del sistema Linux (las dependencias son controladas por el sistema). * El proceso de aplicación de los cambios es siempre controlado (instalación y actualización de paquetes). * Y es posible obtener un feedback de la operación (gestión de errores). * Además, tenemos un ingenioso control de versiones gracias a las diferentes versiones de los paquetes (y un changelog).
4. @jact_abcweb #migasfree Ahora toca hablar de la historia de AZLinux y migasfree. Responder quién fue primero (si la gallina o el huevo) es complicado, pero sí es cierto que ambos han ido evolucionando de la mano.
5. @jact_abcweb #migasfree A pesar de tantos siglos de evolución, los métodos de aprendizaje y mantenimiento, poco o nada han cambiado. En la era de la información, el mayor problema para seguir repitiendo los mismos errores, es la sobreinformación. Actualmente, hay tal cantidad de oferta que, seguramente, cuando vas a buscar algo que se adapte a tus necesidades, no encuentres nada (paradoja long tail). Esto nos ocurrió a nosotros.
6. Tranquilos, el proyector no se ha estropeado. Lo que representa la diapositiva es el comienzo de nuestro proyecto. En el principio... sólo había oscuridad. Cuando empezamos con el proyecto de hacer un escritorio basado en Linux, en nuestra lista de tareas no estaba cómo íbamos a administrar cientos de máquinas (nuestro parque de ordenadores ronda los 3000). Lo cual fue un grave error de análisis, pero bastante teníamos con aprender y adaptarnos al nuevo sistema. En estos oscuros tiempos, hacíamos cambios manuales (como los haríamos en nuestro ordenador de casa, vía interfaz gráfico) en una maqueta que servía como base para clonar uno o dos equipos que se convertían en equipos de pruebas para los usuarios más... afortunados. Cada versión de la "maqueta" tenía sólo un par semanas de vida y no había forma de actualizar las ya instaladas.
7. @jact_abcweb #migasfree En cuanto vimos que ya teníamos unas 10 máquinas en funcionamiento, con usuarios reales, tuvimos que reflexionar sobre el gran problema al que nos enfrentábamos si seguíamos haciendo las cosas así. Primero empezamos a investigar cómo hacer esos cambios de forma automatizada: ¡había que hacer un script! En realidad, esta tarea es la que lleva más tiempo: tienes una petición, y tienes que transformarla en un cambio en el sistema, que sea automatizable, para que sea gestionable.
8. @jact_abcweb #migasfree Una pequeña luz apareció sobre nuestro horizonte, cuando en lugar de tener simples scripts, empezamos a agruparlos en paquetes. Ya que los sistemas Linux están llenos de paquetes que realizan cambios, ¿por qué no íbamos nosotros a hacer lo mismo? Pero aún quedaba un asunto por responder: cómo asignar cada cambio a la máquina que lo necesita. Nuestra organización es tan diversa que no todo el mundo necesita lo mismo, ni de la misma forma. Con los paquetes habíamos resuelto sólo una parte de la ecuación. Para la otra parte, empezamos a realizar un sistema de asignación de repositorios basado en el grupo de la máquina. Pero el sistema, tal y como estaba pensado, tenía un gran problema de escalabilidad y mantenimiento.
9. @jact_abcweb #migasfree Pero de pronto, un día, Alberto Gacías nos trajo... el monolito. La pieza del puzzle que daba sentido a todo el proceso. Era un prototipo rápido y pequeño que había hecho en un par de tardes, pero que nos ofrecía exactamente lo que necesitábamos: * Asignación selectiva de cambios a equipos * Feedback de las actualizaciones * Recolección automática de datos de los equipos (software y hardware)
10. @jact_abcweb #migasfree Como ya hemos visto antes con Alberto, migasfree es una herramienta simple que combina conceptos ya inventados. Esa es su genialidad. Para que todo funcione, tan sólo hay que empaquetar. Pero eso no lo hace migasfree.
11. @jact_abcweb #migasfree El proyecto migasfree ha estado desde el primer día en producción en el Ayuntamiento y, conforme avanzábamos en número de equipos migrados a Linux, le hemos ido añadiendo nuevas funcionalidades (como el invento de los calendarios para no saturar la red, las consultas, los gráficos, ...). Pero aún quedan muchas cosas por hacer: * Instalación de dispositivos (impresoras). * Hacer un cliente para equipos con Windows (con la idea de inventariar el hardware en un principio). * Mejorar la explotación de los datos que ya tenemos en migasfree (consultas y gráficos). * Implicar a la comunidad para tener un mayor repositorio de propiedades y fallas (las necesidades de cada uno son diferentes). * Documentar, documentar, documentar... para que el proyecto pueda ser conocido y difundido por más personas.
12. @jact_abcweb #migasfree Llega el momento crítico de la presentación. El momento en el que peligra la reputación del artista. Antes de empezar a ver código, veamos algunos conceptos previos: ¿Qué se puede empaquetar? O mejor dicho, ¿qué empaquetamos nosotros? * Ficheros nuevos (nuevo software) * Cambios de configuración en el sistema (ficheros de otros paquetes, servicios, ...) * Cambios en los perfiles de los usuarios (ficheros generados por otros paquetes) (habrá que tener en cuenta estas dependencias) * Dependencias (requisitos, obsoletos, conflictos) Y las 5 reglas de oro que hay que tener en cuenta a la hora de hacer un paquete: * La instalación de un paquete es un proceso silencioso y automático (sin intervención del usuario). Esto es muy diferente al siguiente, siguiente, del mundo Windows. * Hay que evitar a toda costa los conflictos con otros paquetes que estén instalados (requisitos, obsoletos, cuidado al tocar ficheros de otros paquetes...) * Dejar todo como estaba al desinstalar un paquete (por lo menos, a nivel de sistema, en el perfil de los usuarios, ya es más complicado...) * La instalación y la actualización de un paquete, son procesos diferentes. * Puedes programar un paquete en el lenguaje de script que prefieras (bash, perl, python, php, ruby, ...) mientras tengas un intérprete instalado. Ahora, pasemos a los ejemplos.
13. Estructura de directorios Para empezar, la estructura de directorios para la creación de paquetes (/usr/src/packages/). En otros sistemas Linux, la ubicación es diferente, pero la estructura que hay a partir de ahí, es la misma. En el directorio SPECS se almacenan los ficheros con las instrucciones necesarias para crear los paquetes. Estos ficheros se llaman de especificaciones y tienen la extensión .spec. De ahí el nombre. Son ficheros de texto normales y luego veremos varios ejemplos. El directorio SOURCES sirve para contener los ficheros que tiene asociados cada paquete. Puede ocurrir que un paquete no contenga ningún fichero, pero aún así, en este directorio debe existir una carpeta con el nombre de dicho paquete. En los directorios RPMS y SRPMS se almacenarán, cuando se compile el fichero .spec, el paquete para distribuir, teniendo en cuenta la arquitectura (i386, i586, i686, noarch, etc) y el paquete fuente de dicho paquete, respectivamente. Estos paquetes fuente únicamente contienen el fichero .spec y un .tar.gz con los ficheros que haya en el directorio SOURCES correspondientes a ese paquete. Los directorios BUILD y BUILDROOT almacenan ficheros temporales cuando se compilan los paquetes. Fichero de instrucciones Seguimos con la estructura de un fichero .spec (ver fichero spec_example.spec). Diferencia entre primera instalación y actualización de un paquete Se ejecutan partes diferentes de las secciones (dependiendo del valor del parámetro $1 pasado a las distintas secciones). Ver el fichero rpm_order.txt para más detalles. Todo lo visto hasta el momento es válido para sistemas basados en paquetes RPM, pero aunque la sintaxis y la organización de ficheros no concuerde, los mismos conceptos son aplicables a los paquetes .deb. Ejemplo de aplicación Ahora, vamos a ver todo el proceso en funcionamiento. Un ejemplo de cómo es nuestro trabajo diario. Ciclo petición ­> cambio ­> liberación. (Aquí se ve un ejemplo interno a la organización, se comentan las aplicaciones usadas y el proceso seguido, pero se omiten los extractos del código fuente y de la petición en el sistema de incidencias.)
14. Petición Se abre una en el sistema de incidencias que utilizamos. Este sistema es Redmine y es también software libre. En el ejemplo propuesto, se nos informa que se ha detectado tráfico de red no deseado en las estaciones de trabajo Linux. Este tráfico de red está originado por el servicio avahi­daemon. Se recomienda la desactivación de este servicio. Cambio Siguiendo el texto de la indicencia, se informa de cómo desactivar este servicio con instrucciones de la línea de comandos. Dentro del cambio también se encuentra la creación del paquete, pero siempre lleva más tiempo investigar cómo resolver la petición, que paquetizar los cambios. Para incorporar estos cambios en un paquete (en este caso en azl­lan, por ser el que se encarga de configurar los servicios de red de la máquina), se modifican: • Directiva Release (es una nueva versión del paquete). • Sección %post (proceso de instalación del paquete). Se añaden las instrucciones para la desactivación del servicio. • Sección %postun (proceso de desinstalación del paquete para dejar todo como estaba al principio). Se incorporan las instrucciones para activar de nuevo el servicio, ya que por defecto está en ese estado antes de instalar el paquete azl­lan. • Sección %changelog. Se añade el por qué de los cambios al histórico del paquete para esta nueva versión. Liberación El código del paquete está listo, pero hay que compilarlo y subirlo al servidor de migasfree. Para hacer estos dos procesos de una sola vez, hemos creado un script llamado azl­create­package que compila el paquete RPM con el comando rpmbuild y que sube los paquetes resultantes (el .rpm y el .src.rpm) al servidor migasfree con el comando migasfree­upload (comando que incorpora el cliente de migasfree en su nueva versión). Después, vamos al servidor de migasfree (vía navegador web) y rehacemos el repositorio donde hemos asignado el nuevo paquete y verificamos que la distribución del mismo se va a producir en nuestra máquina objetivo. Demostramos que el paquete se instala a través del comando migasfree ­­update. Esta instrucción se ejecuta cada vez que se inicia una sesión gráfica en el sistema (porque nosotros, como organización, lo requerimos así). El usuario sólo advertirá un icono en el systray, pero se muestra la orden en consola para ver todo el proceso de actualización.
15. @jact_abcweb #migasfree Resumen: #lswc 2011 2011-11-09 • Los paquetes son la evolución natural para administrar sistemas • Empaquetar no es complicado y tiene ventajas • Migasfree es la herramienta ideal para gestionar los cambios y monitorizar sistemas Me gustaría que, tras esta charla, os hayáis quedado con estas 3 ideas. Sobre todo, con la idea de que "empaquetar no es complicado". En realidad, como hemos visto, lleva más tiempo hallar la solución a una petición, que empaquetarla después. Pero, si seguís pensando que empaquetar no está al alcance de todos, tenéis razón. Por eso, sería un gran avance crear un proyecto para hacer paquetes de una forma más fácil y que sirva para todos los sistemas de paquetería. Os animo a crearlo, y que sea con una licencia libre.
16. @jact_abcweb #migasfree Antes de que empecéis a aplaudir...
17. @jact_abcweb #migasfree ¿Alguna pregunta?
18. Todas las imágenes usadas tienen licencia y han sido obtenidas de flickr.com #3: larzor #5: Manuel Cernuda #7: salendron #8: RejiK #9: Brett Patterson #10: Squiggle #11: Larry Myhre #12: Josh Liba #14: humbert15 #15: Kennedy Library #16: humbert15 Esta presentación tiene licencia @jact_abcweb #migasfree #lswc 2011 2011-11-09 Gracias por vuestra atención. (ahora podéis aplaudir ) :)