LinuxParty

En la industria de las telecomunicaciones, la "última milla", describe la infraestructura, la construcción, los costos y las complicaciones inherentes a la entrega de un servicio a un gran número de consumidores. Para un proveedor de cable puede resultar muy fácil vincular un extremo del país a otro vía satélite, sin embargo, es absolutamente una perspectiva diferente y onerosa el obtener los derechos de paso, cavar trincheras, y poner el cable para conectar cada casa y cada negocio. Para algunas ideas, los últimos kilómetros de una noción no son necesariamente una distancia exacta -también podrían ser de mil millones de millas.

Otras industrias frente a los equivalentes de la "última milla". Las tienda de comestibles por ejemplo, en repetidas ocasiones no están en línea, en gran parte debido a que "la última milla" es caro. El Servicio Postal de Estados Unidos continúa sufriendo fuertes pérdidas en la entrega de cartas (literalmente) del último tramo. Los desarrolladores de software frente a la última milla, también. Una vez que su software está construido, es sólo una colección de cuantos ceros necesita hasta que sea desplegado. Conceptualmente, la instalación es fácil, pero al igual que con la entrega de los cables, los plátanos, y los sobres, el diablo está en los detalles.

El primer artículo de esta serie que introdujo al RPM, un popular sistema de software. Usted puede encontrar RPMs en muchas distribuciones de Linux, y como tal, es ampliamente utilizado para desplegar tanto aplicaciones comerciales como de código abierto, por ejemplo, las variantes de Red Hat Linux y Fedora Core Linux. El primer artículo también mostró cómo construir el paquete, e instalar una aplicación desde el código fuente en un sistema limpio.

Continuando con la investigación de RPM y sus múltiples usos, en este artículo se sumerge en la actualización y desinstalación de software existente. El tercero y último artículo se verá en más escenarios inusuales, como el código fuente y la distribución de parches.


La Instalación de software para la primera vez que el caso más simple de la implementación. El sistema de destino carece de los demonios de su paquete, los archivos binarios, archivos de configuración y/o archivos de datos, por lo que una primera instalación no es necesario detener el trabajo en curso o una copia de seguridad, restaurar y, posiblemente, combinar archivos.

Sin embargo, si el sistema de destino tiene una versión anterior o actual de su software, o si su software está entrelazado con otro código y servicios, su RPM debe tener especial cuidado en mantener una configuración viable. Puede que tenga que detener los procesos, o conservar los archivos y reiniciar las aplicaciones de tu nuevo código se ha copiado en el sistema. Por supuesto, no siempre es posible mantener la compatibilidad con versiones anteriores. En esos casos, el RPM debe hacer la menor cantidad de cambios posibles para mantener el sistema funcional y seguro. En algunos casos, eso puede significar  elaborados guiones para interpretar configuración anterior y transformarlos en otros nuevos.

El RPM proporciona cuatro "ganchos" para la inyección de comandos en las secuencias de instalación y desinstalación: dos para la instalación y dos para la desinstalación. Todos los ganchos se ejecutan en el sistema de destino y son generalmente suficientes para la mayoría de las tareas domesticas. Estos cuatro ganchos son los siguientes:

    * Todos los comandos que aparecen en el gancho %pre ejecutan sentencias antes de la instalación del paquete.
    * Comandos en el gancho %post se ejecutarán después de que su paquete haya sido instalado.
    * El gancho %preun se ejecuta antes que su paquete se elimina del sistema.
    * Comandos en el gancho %postun entran en ejecución después de que su paquete es eliminado del sistema.

Por lo tanto, el orden de las operaciones durante una actualización es:

   1. Ejecute la sección %pre del RPM se instala.
   2. Instalar los archivos que ofrece el RPM.
   3. Ejecutar la sección %post del RPM.
   4. Ejecute el %preun del viejo paquete
   5. Elimine todos los archivos viejos no los sobrescriba con la versión más reciente. (Este paso elimina los archivos que el nuevo paquete no requiere.)
   6. Ejecute el gancho %postun del viejo paquete.

Los pasos 4 y 6 pueden parecer un poco sospechoso, y por buenas razones: Si está actualizando un paquete, ejecuta la desinstalación de la versión anterior con los ganchos que podría deshacer todo o parte de los pasos 1 a 3. De hecho, sin las condiciones, la desinstalación de los ganchos de la versión anterior podría destruir la versión más reciente. Para evitar clobbering no intencional, RPM pasa para cada gancho un argumento, una bandera. El valor de la bandera indica que la operación se está realizando:

• Si el primer argumento a %pre es 1, la operación de RPM es una instalación inicial. Si el argumento es 2, la operación es una actualización desde una versión existente a otra nueva
• Del mismo modo, los argumentos a un %poste son de 1 y 2 para una nueva instalación y actualización, respectivamente. (Una vez más, %pre y %post no se ejecutan durante una desinstalación.)
• Si el primer argumento de %postun %preun es 1, la acción es una actualización.
• Si el primer argumento de %postun %preun es 0, la acción es la desinstalación.

Envuelva cada uno de los ganchos con la lógica para poner a prueba el valor del argumento y ejecutar el código correcto. De forma predeterminada, cada gancho se interpreta como un intérprete de órdenes Bourne Shell (típicamente, /bin/sh) la secuencia de comandos, a menos que el nombre de otro intérprete de comandos, como Perl. Aquí es un gancho condicional %pre escrito para el Bourne Shell:

%pre 
if [ "$1" = "1" ]; then
  # Perform tasks to prepare for the initial installation
elif [ "$1" = "2" ]; then
  # Perform whatever maintenance must occur before the upgrade begins
fi

Y aquí está el mismo gancho, aunque escrito en Perl. Para utilizar otro intérprete para los scripts de su gancho, especifique la opción -p, y el nombre de la ruta completa al intérprete.

%pre -p /usr/bin/perl
if ( $ARGV[0] == 1 ) {
  print "Preparing for initial install...
"
} 
elsif ( $ARGV[0] == 2 ) {
  print "Preparing to upgrade software...
"
}

Si se especifica un intérprete que no existe en el equipo de destino, la utilidad rpm genera un error y se ve algo como esto:

$ sudo rpm -i RPMS/i386/wget-1.12-1.i386.rpm
error: Failed dependencies:
	/usr/bin/perl is needed by wget-1.12-1.i386

Si el administrador del sistema de destino ve ese mensaje, él o ella, deben instalar el RPM para la "resolver" la dependencia y volver a intentar repetir la instalación.


Manténgase alerta con desencadenadores (triggers)

En general, un RPM instala un paquete único que necesita muy poco de otros paquetes. Típicamente, un RPM tiene requisitos previos o co-requisitos, pero está aislado de otros. Dicho esto, hay algunos paquetes que afectan a los demás.

Por ejemplo, algunos editores de texto son extensibles: El añadir un paquete complementario en Ruby, por ejemplo, y el editor podrá resaltar la sintaxis de ese lenguaje de programación. Si el editor está instalado en primer lugar seguido de su complemento, las nuevas funciones no se harán esperar. Pero ¿y si el complemento se instaló por primera vez -por ejemplo, debido a las obras de ampliación de una serie de editores- y es seguido por la instalación del editor? Idealmente, la función se acaba de agregar la misma. Esa es la idea de un disparador de RPM.

Un RPM puede adjuntar un disparo a otro paquete para llevar a cabo una o más tareas si el nombre empaquetado se instala o desinstala después de que su paquete está instalado. Cada disparo es sólo una secuencia de comandos, al igual que los que escribe para %pre o %post. Incluso se puede nombrar un intérprete alternativo, si lo prefiere.

    * Un guión %triggerin se ejecuta cuando el paquete llamado está instalado.
    * %triggerun se ejecuta cuando el paquete llamado se desinstala.
    * Un guión %triggerpostun se ejecuta tras haberse desinstalado el paquete.

Por ejemplo, si desea ejecutar un script Ruby, si se instala después de su paquete ya ha sido colocado en un sistema, puede escribir:

%triggerin -p /usr/bin/perl -- ruby
# React to the addition of Ruby 

La opción -p es opcional. Debe escribir -- (dos guiones), y luego el nombre del paquete que desea supervisar.

Con las copias, ganchos, y desencadena en mente, aquí está la orden de ejecución de las acciones durante la instalación de un nuevo paquete, N. (La versión anterior del paquete se llama n.)

1. Iniciar el %pre script de N
2. Copie los nuevos archivos de N al sistema de archivos.
3. Eecución los %post Script de N.
4. Ejecutar todas las instalaciones desencadenantes (los %triggerin marcado en otros paquetes) desencadenadas por la instalación de N.
5. Ejecutar todas las instalaciónes de triggers (desencadenantes).
6. Ejecutar toda desinstalación de N (%triggerun) desencadenantes.
7. Ejecutar todo el proceso de desinstalación activo (los que se encuentran en otros paquetes) desencadenadas por la desinstalación de n.
8. Ejecutar el gancho %preun de n.
9. Borrar todos los archivos no sobrescritos por la instalación de N.
10. Ejecutar todos los factores desencadenantes de desinstalación (%triggerpostun) que se encuentren en n.

La Instalación del software puede ser compleja, sin embargo, los ganchos y los factores desencadenantes pueden adaptarse a casi cualquier escenario. Una advertencia: no trate de interactuar con un usuario durante cualquier etapa del proceso. RPM está diseñado para permitir las instalaciones de procesos por lotes, durante el cual el usuario no está necesariamente presente. Si un paquete RPM se detiene durante la instalación para hacer una pregunta y nadie ve la cuestión, la instalación aparentemente (creerán) que está colgada

Variables RPM

Los archivos RPM pueden llegar a ser largos y complejos. Como utilizar variables como abreviatura de aplicaciones, se pueden utilizar variables como marcadores de posición en un archivo spec del RPM.

Por ejemplo, puede definir una variable en la parte superior de su archivo de especificaciones y referirse a ella con %{nombre_variable} todo-e incluso en los scripts de %pre:

%define foo_dir /usr/lib/foo
%install
cp install.time.message $RPM_BUILD_ROOT/%{foo_dir}
%files
%{foo_dir}/install.time.message
%post
/bin/cat %{foo_dir}/install.time.message

Vendrán más RPM

Si usted desarrolla software para UNIX® y Linux, escribir el programa de instalación puede ser una gran tarea. Afortunadamente, no es necesario escribir la tecnología de instalación desde cero. RPM es un formato ideal para la distribución de software. Esto hace que la "última milla", sea un verdadero paseo por el parque.

:-) Espera la siguiente entrega.

• Crear y empaquetar software para Linux en RPM, parte 1, creando paquetes.
• Empaquetando el software con Linux RPM, Parte 2: Actualización y desinstalación
• Empaquetando software con Linux RPM, Parte 3: Requerimientos y dependencias.