Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Capítulo 8. RPM

Como parte de las instalaciones automatizadas los administradores suelen implementar aplicaciones personalizadas no provistas por Red Hat, tales como software de monitorización y copias de seguridad. Para hacerlo, este software debe estar empaquetado como RPM. Un entorno de creación de RPM se puede configurar en un sistema que esté ejecutando Red Hat Enterprise Linux. Observe que el sistema de creación debe contener la misma versión de paquetes utilizados en los sistemas de destino. Es decir que un sistema Red Hat Enterprise Linux 5 debe servir para construir los RPM para el sistema Red Hat Enterprise Linux 5 y un sistema de Red Hat Enterprise Linux 6 para los RPM de Red Hat Enterprise Linux 6.
El paquete rpm-build debe instalarse en el sistema construido como un requisito mínimo. También necesitará paquetes adicionales, tales como compiladores y bibliotecas.
Los paquetes RPM listos para producción deben ser firmados con una llave GPG, la cual permite a los usuarios verificar el origen e integridad de paquetes. La frase de paso de la llave GPG utilizada para firmar los RPM debe ser conocida únicamente por un grupo confiable de administradores .

Procedimiento 8.1. Creación de llave GPG

Importante

Los siguientes comandos iniciarán la creación de la llave GPG y la exportarán en un formato apto para distribuir a sistemas de cliente. Haga una copia de seguridad de la llave creada y almacénela cuidadosamente.
  1. Cree un directorio para la llave:
    mkdir -p ~/.gnupg
    
  2. Genere el par de llaves:
    gpg --gen-key
    
    Necesitará seleccionar la clase de llave, el tamaño de la llave, y el tiempo de validez (presione enter para aceptar los valores predeterminados). Necesitará especificar un nombre, comentario y dirección de correo-e:
    Real name: rpmbuild
    Email address: rpmbuild@example.com
    Comment: this is a comment
    You selected this USER-ID:
        "rpmbuild (this is a comment) <rpmbuild@example.com>"
    
    Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
    
    Presione O para aceptar la información y continuar.
  3. Liste todas las llaves con sus huellas dactilares:
    gpg --list-keys --fingerprint
    
  4. Exporte las llaves:
    gpg --export --armor "rpmbuild <rpmbuild@example.com>" > EXAMPLE-RPM-GPG-KEY
    
  5. Importe la llave para que la base de datos de RPM permita la verificación del origen e integridad de los RPM mediante gpg --import como root en todos los sistemas de destino:
    rpm --import EXAMPLE-RPM-GPG-KEY
    
    Esto ocurrirá automáticamente durante la instalación del cliente y no se necesitará ejecutar de forma manual.
  6. Una vez se haya creado un RPM puede firmarse con la llave GPG y cargarse al canal apropiado:
    rpm --resign package.rpm
    rhnpush --server=http[s]://satellite.server/APP package.rpm --channel=custom-channel-name
  7. Para verificar el paquete RPM, navegue al directorio que contiene el paquetes y ejecute los siguientes comandos:
    rpm –qip package.rpm
    rpm -K package.rpm

Procedimiento 8.2. Construir RPM

  1. Cree una cuenta de usuario sin privilegios llamada rpmbuild para construir paquetes. Así, permitirá a varios administradores compartir el entorno construido y la llave GPG.
  2. En el directorio principal para usuario rpmbuild, /home/rpmbuild, cree un archivo llamado .rpmmacros:
    touch /home/rpmbuild/.rpmmacros
    
  3. Abra el archivo .rpmmacros en su editor de texto preferido y añada las siguientes líneas. _gpg_name debe coincidir con el nombre para la llave GPG utilizada para firmar los RPM:
    %_topdir            %(echo $HOME)/rpmbuild
    %_signature         %gpg
    %_gpg_name          rpmbuild <rpmbuild@example.com>
    
    El directorio que lista el directorio de nivel superior (/home/rpmbuild/rpmbuild en el ejemplo anterior) debe tener la misma distribución del directorio presente en /usr/src/redhat.

Ejemplo 8.1. Archivo de especificación de RPM

El siguiente es un ejemplo básico de un archivo de especificación RPM. Al crearlo, deberá estar localizado en el directorio SPECS bajo _topdir como se define en el archivo .rpmmacros. La fuente y parches correspondientes deben estar situados en el directorio SOURCES.
  Name: foo
  Summary: The foo package does foo
  Version: 1.0
  Release: 1
  License: GPL
  Group: Applications/Internet
  URL: http://www.example.org/
  Source0 : foo-1.0.tar.gz
  Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root
  Requires: pam
  BuildPrereq: coreutils
  %description
  This package performs the foo operation.
  %prep
  %setup -q
  %build
  %install
  mkdir -p %{buildroot}/%{_datadir}/%{name}
  cp -p foo.spec %{buildroot}/%{_datadir}/%{name}
  %clean
  rm -fr %{buildroot}
  %pre
  # Add user/group here if needed
  %post
  /sbin/chkconfig --add food
  %preun
  if [ $1 = 0 ]; then # package is being erased, not upgraded
      /sbin/service food stop > /dev/null 2>&1
      /sbin/chkconfig --del food
  fi
  %postun
  if [ $1 = 0 ]; then # package is being erased
      # Any needed actions here on uninstalls
  else
      # Upgrade
      /sbin/service food condrestart > /dev/null 2>&1
  fi
  %files
  %defattr(-,root,root)
  %{_datadir}/%{name}
  %changelog
  * Mon Jun 16 2003 Some One <one@example.com>
  - fixed the broken frobber (#86434)