Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

Jose Antonio Chavarría

November 09, 2011
Tweet

More Decks by Jose Antonio Chavarría

Other Decks in How-to & DIY

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?

    View full-size slide

  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.)

    View full-size slide

  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).

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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)

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.)

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  16. @jact_abcweb #migasfree
    Antes de que empecéis a aplaudir...

    View full-size slide

  17. @jact_abcweb #migasfree
    ¿Alguna pregunta?

    View full-size slide

  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 ) :)

    View full-size slide