LinuxParty

En los primeros días de la computación, cada pieza de software (en el sentido de programa) era monolítica. Excluyendo la ROM para arrancar y el propio sistema operativo, cada aplicación se proveía siempre con todas sus bibliotecas y el código necesario para ejecutarla. Este enfoque era apropiado, en gran parte porque los ordenadores de la época no podían realizar múltiples tareas. Más tarde, sin embargo, las computadoras avanzaron a pasos agigantados para soportar tanto a múltiples usuarios simultáneos (tiempo compartido) y varias aplicaciones simultáneas. Con muchos usuarios ejecutando la misma aplicación y distribución la de los recursos del sistema, como el sistema de archivos y la memoria RAM, optimizar el intercambio entre el código se convirtió en una necesidad.

Hoy en día, casi todos los sistemas operativos separan el código de las bibliotecas (aka librerías) del código de la aplicación y se llaman entre ellas "o se casan, como algunos dicen" en tiempo de ejecución. Pero una biblioteca compartida -que es en castellano la traducción de library, si bien utilizaremos los dos nombres indistintamente- , es el nombre de aquellas bibliotecas que comparten el código, pero tiene sus pros y sus contras. En la columna del más, cada aplicación es más pequeña, porque  no tiene que ser un programa monolítico -compilado de forma estática-. Por otra parte, una corrección de errores en una biblioteca o la mejora del rendimiento reporta beneficios al común de las aplicaciones que la comparte. Sin embargo, la separación del código de la aplicación y la biblioteca es una especie de esposas: La biblioteca compartida debe estar disponible y ser compatible, o la aplicación no se puede ejecutar.

El vínculo entre una aplicación y una biblioteca es un tipo de dependencia. Si usted distribuye un código fuente y requiere de un conjunto particular de los archivos de cabecera (los include) para compilar el código, también es una dependencia. El código también puede requerir una herramienta específica, como Bison o Yacc, para compilar. Si distribuye su software en un RPM, éste, comprobará que el sistema de destino ofrece todas las dependencias antes de instalar el código. Después de todo, si un sistema no es adecuado, hay pocas razones para instalar la aplicación.

En Parte 1 de esta serie se demostró cómo distribuir su software a través de RPM. En la Parte 2 se describe el proceso de instalación y desinstalación en detalle y se explica cómo instalar los componentes cuando un paquete complementario se instala en algún momento posterior. En este artículo, el último de la serie, explora para la existencia de otras dependencias, y analiza las capacidades adicionales para controlar y personalizar su paquete de software.

Definiendo dependencias.

Cuando se crea un paquete RPM, puede declarar cuatro tipos de dependencias:

• Si tu paquete requiere una capacidad prevista por otro, defini un requisito.
• Si otros paquetes dependen de o, eventualmente, podrían depender de la capacidad de su software, declarar la capacidad que su paquete proporciona.
• Si el software (o parte de su software) no pueden coexistir simultáneamente con otro paquete, especifique un conflicto.
• Si su paquete desaprueba otro paquete o una versión antigua de su propio software, definir lo que ha quedado obsoleta. Si su paquete cambia de nombre, debe aparecer el nombre antiguo como obsoleto.

Cada dependencia es listada por separado en el archivo spec del RPM. La sintaxis es del tipo: Capability, donde Type es una de las cuatro etiquetas: (Requires, Provides, Conflicts, or Obsoletes) (En castellano, sólo a título informativo: Requiere, Proporciona, conflictos, u Obsoletos) y Capability es el nombre de un número de versión opcional. Si usted tiene más de una Capability  a listar, enumere todas en la misma línea, delimitada por un espacio o una coma.

Por ejemplo, si su aplicación requiere de Perl para ejecutarse, debe especificarlo de la siguiente manera:

Requires: perl

Si su aplicación requiere Perl y MySQL debe escribir:

Requires: perl, mysql 

A menudo, una aplicación depende de una versión específica o de una versión específica de un paquete importante. Por ejemplo, si escribes código Ruby compatible con la versión 1.9, que además dependa de que versión de éste intérprete. Para expresar la dependencia de la versión, agregue el número de la versión a la Capability::

Requires: ruby >= 1.9

Usted puede especificar los números de versión de cualquiera de los cuatro tipos de dependencias. La sintaxis es idéntica. Por ejemplo, si su aplicación no era compatible con las versiones del intérprete de comandos BASH versión 2.0 o superior, usted escribiría:

Conflicts: bash > 2.0

Las seis comparaciones entre número de versión son

• package < revision  requiere que el paquete tenga una versión menor que la revisión.
• package > revision especifica un paquete más moderno que la revisión.
• package >= revision pregunta por un paquete igual o mayor que la revisión.
• package <= revision pregunta por un paquete igual o monor que la revisión.
• package = revision especifica una revisión en concreto
• package pregunta por cualquier revisión del paquete

En general, la información para Requires y Provides se genera automáticamente en función del análisis del RPM de su código y el archivo spec, respectivamente. (Usted puede aproximarse a lo que requiere su RPM utilizando la utilidad ldd.) Sin embargo, puede modificar las dos listas, si es necesario. Los conflictos y Obsoletos suelen ser proporcionados por el desarrollador de software.

Muchos desarrolladores eligen RPM porque es fácil de usar y dispone de un amplio soporte. Sin embargo, la simplicidad también hace más fácil un mal actor para instalar RPMs, modificar su contenido, y volver a empaquetar y redistribuyendo el software como auténtico. Los sitios espejos y torrents sólo aceleran actos de auténtica "piratería" -en el sentido de que pueden secuestrar nuestro PC-. Para protegerse y proteger a los que optan por utilizar el software, firme sus RPMs con una firma única para garantizar su autenticidad. La firma se opone a la modificación: Cualquier cambio en el archivo altera la firma, que revela una falsificación.

Hay tres maneras de firmar su paquete. Usted puede firmar el paquete cuando lo construye. Se puede volver a firmar un paquete que ya ha sido firmado. Y usted puede firmar un RPM existente que no tiene firma. Las dos últimas opciones se basan en la antigua técnica, así que vamos a concentrarnos en la firma de un RPM cuando se construyó.

Para empezar, debe tener un par de claves, la clave privada GPG y la clave pública. Tal clave es fácil de generar. El primer paso es poner en marcha gpg-agent, que gestiona las claves secretas. (Los Sistemas suelen ejecutar un simple gpg-agent único para todos los usuarios. Consulte con el administrador del sistema para determinar si este paso es necesario. Si los sistemas ya ejecutan el agente, pregunte cómo conectarse a él.)
...

$ gpg-agent --daemon --enable-ssh-support 

  --write-env-file "${HOME}/.gpg-agent-info"

gpg-agent crea el fichero .gpg-agent-info dentro de su directorio home. El fichero contiene variables de entorno requeridas para conectarse al agente ejecutándose. Cargar la información con el siguiente comando (Escriba la entrada desde el prompt, o para su mayor comodidad, añádalo a su fichero de inicio de la shell) por ejemplo (.bash_profile o .bashrc, según distros)

$ if [ -f "${HOME}/.gpg-agent-info" ]; then

  . "${HOME}/.gpg-agent-info"

  export GPG_AGENT_INFO

  export SSH_AUTH_SOCK

  export SSH_AGENT_PID

fi

Por último, establezca una variable adicional para apuntar a la terminal que está utilizando actualmente. (De nuevo, puede agregar estas dos líneas en un archivo de arranque de la shell que esté disponible para todas las sesiones interactivas.)

$ GPG_TTY=$(tty)

$ export GPG_TTY

Ahora está preparado para generar la clave, también llamada llave (key). Ejecute el comando: gpg --gen-key, y responda a las preguntas desde el prompt. Un ejemplo de la sesión para la generación de la clave se muestra en el listado 1. Los datos de entrada (lo que hay que teclear) está en negrita

Listado 1: Generación de la clave.

	

$ gpg --gen-key

gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.



Please select what kind of key you want:

   (1) DSA and Elgamal (default)

   (2) DSA (sign only)

   (5) RSA (sign only)

Your selection? 1

DSA keypair will have 1024 bits.

ELG-E keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048) 1024

Requested keysize is 1024 bits

Please specify how long the key should be valid.

         0 = key does not expire

        = key expires in n days

      w = key expires in n weeks

      m = key expires in n months

      y = key expires in n years

Key is valid for? (0)  0

Key does not expire at all

Is this correct? (y/N) y



You need a user ID to identify your key; the software constructs the user ID

from the Real Name, Comment and Email Address in this form:

    "Heinrich Heine (Der Dichter) "



Real name: Martin Linuxparty

Email address: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

Comment: Ejemplo de generación de Key para RPM

You selected this USER-ID:

    "Martin Linuxparty (Ejemplo de generación de Key para RPM) "



Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

You need a Passphrase to protect your secret key.



Enter passphrase: ******

Retype passphrase: ******



We need to generate a lot of random bytes. It is a good idea to perform

some other action (type on the keyboard, move the mouse, utilize the

disks) during the prime generation; this gives the random number

generator a better chance to gain enough entropy.

+++++++++++++++++++.+++++.++++++++++++++++++++.+++++>.+++++.+++++..>+++++.+++++

El primer prompt elige el tipo de clave (por defecto es la opción preferida). El siguiente indicador establece el tamaño de la clave en bits. Aquí, los bits, cuantos más, mejor, aunque tome algo de tiempo adicional para generarla. Si lo desea, puede establecer una fecha de expiración de la llave en la próxima pregunta. Las siguientes tres preguntas piden información para identificar a esta clave. Se acostumbra a dar su nombre y dirección de correo electrónico para permitir a los usuarios contactar con usted para verificar su clave pública. Por último, se le pedirá dos veces una frase de contraseña para agregar una capa adicional de seguridad. Nadie puede firmar un RPM con la llave sin la contraseña correcta. Dependiendo de lo ocupado que su sistema esté, la generación de las claves puede tardar entre unos segundos o varios minutos.RPM.

Al finalizar, el generador de claves crea un nuevo directorio llamado $HOME/.gnupg y la rellena con los archivos que representan las claves privadas y públicas. Para ver las teclas que tienen disponibles, ejecute gpg --list-key. Tome nota del valor del uid: Contiene el nombre de la clave que debe usar para firmar el RPM.

$ gpg --list-key

/home/strike/.gnupg/pubring.gpg

-------------------------------

pub   1024D/1811A3E4 2009-11-23

uid                  Martin Linuxparty (Ejemplo de generación de Key para RPM) 

sub   1024g/15BBCF06 2009-11-23	

Para continuar, debe ahora iniciar las opciones para firmar el paquete RPM. Cree o abra el fichero: $HOME/.rpmmacros, y añada estas tres líneas:

%_signature gpg

%_gpg_path /home/strike/.gnupg

%_gpg_name Martin Linuxparty (Ejemplo de generación de Key para RPM) 

La línea %_signature selecciona el tipo de firma. En este caso, se configura en gpg. El %_gpg_name especifica el identificador de la clave para firmar. Durante la generación de las claves, el nombre fue creado con Martin Linuxparty (Ejemplo de Generación de clave párrafo RPM) (el ID de usuario [UID] Valor anterior), por lo que se repite aquí. Por último, %_gpg_path define la ruta de acceso a sus llaves.

Con las claves y la configuración estén en su lugar, la firma de un RPM requiere una opción adicional, --sign.

$ rpmbuild -v --sign -bb --clean SPECS/wget.spec

Enter pass phrase: 

Pass phrase is good.

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.46786

+ umask 022

...

El comando rpmbuild que se muestra es el mismo utilizado en la Parte 1, la única adición es --somg. Cuando se le pide su contraseña, introduzca la misma contraseña que usted proporcionó en la generación de las claves. El RPM construido resultante quedará firmado.

Usted puede verificar su firma para garantizar que su paquete es prístino. Para verificar la firma de un RPM, ejecute rpm -K con el propio archivo:

$ rpm -K wget-1.12-1.i386.rpm

wget-1.12-1.i386.rpm: (SHA1) DSA sha1 md5 (GPG) OK

Si el comando se lee bien, el archivo es legítimo. Si descarga algún RPM de otro desarrollador, considere la verificación antes de instalar el paquete.

Herramientas adicionales para el desarrollo de RPM

Si utiliza RPM con frecuencia para el empaquetar, generar los archivos de espec se habrá convertido en algo natural. Sin embargo, una gran variedad de herramientas está disponible para hacer el archivo de especificaciones de fácil edición. He aquí una muestra (ver Recursos para los enlaces a cada uno):

• rpmlint: valida los archivos RPM. La herramienta de captura de un buen número de errores tales como la instalación de un binario en /etc y un archivo de configuración en /usr ambos errores comunes que rpmlint puede detectar y se puede ampliar con módulos personalizados. rpmlint está escrito en Python y requiere un puñado de bibliotecas para desempeñar sus funciones.
• Easy RPM Builder es una herramienta del entorno de escritorio K (KDE) basada en paquetes para el montaje. La herramienta ofrece una serie de plantillas para ayudar a poner en marcha su desarrollo de RPMs y proporciona una interfaz gráfica de usuario (GUI) para generar el fichero spec. Easy RPM Builder no sustituye a rpmbuild, y con cierta familiaridad con RPM está lo utilizará de manera más eficaz.
• Si usted no usa KDE o prefieren trabajar con el archivo de especificaciones directamente, se puede extender tanto Vim como Emacs para incluir un modo especial de espec, que pone de relieve la sintaxis de fichero de especificaciones y dirige la creación y mantenimiento de un fichero de especificaciones.
• Aunque no es una herramienta en sí, la página Fedora Project's RPM Guideline, proporciona una amplia lista sobre las mejores prácticas. En efecto, si se va a distribuir su software con Fedora, preste especial atención a las necesidades de los nuevos paquetes. Además, la guía describe cómo empaquetar aplicaciones basadas en una serie de plataformas populares, como Eclipse, Perl y Ruby. el software empaquetado para un intérprete en particular requiere especial atención, ya que el software empaquetado puede incluir scripts, binarios y código fuente que debe ser reconstruido durante la instalación directamente en la máquina objeto. Por ejemplo, un módulo de Perl puede ser parte de Perl y parte del código de parte C. Usted también puede encontrar una versión de la guía de software RPM oficial en el sitio de Fedora.

Herramientas adicionales pueden ayudarle a instalar y gestionar paquetes RPM. En general, estas herramientas están destinadas a los administradores de sistemas, pero que pueden serle útiles para ayudar a validar sus instalaciones y gestionar el software de su sistema de desarrollo propio. Si usted utiliza su propio sistema de desarrollo para las pruebas, usted puede encontrar las herramientas útiles para purgar paquetes.

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