Chapter 8. RPMs

As part of automated installations, administrators will often deploy custom applications not provided by Red Hat, such as backup and monitoring software. In order to do this, this software must be packaged as an RPM. An RPM build environment can be set up on a system running Red Hat Enterprise Linux. It should be noted that the build system must contain the same version of packages which are used in target systems. This means that a Red Hat Enterprise Linux 5 system must be used to build RPMs for Red Hat Enterprise Linux 5 based systems and a Red Hat Enterprise Linux 6 system for Red Hat Enterprise Linux 6 RPMs.
The rpm-build package must be installed on the build system as a minimum requirement. Additional packages such as compilers and libraries may also be needed.
Production-ready RPM packages should be signed with a GPG key, which allows users to verify the origin and integrity of packages. The passphrase of the GPG key used for signing RPMs should be known only to a trusted group of administrators.

Procedure 8.1. Creating a GPG Key

Important

The following commands will initiate GPG key creation and export it in a format suitable for distributing to client systems. The created key should be stored safely and backed up.
  1. Make a directory for creating the key: 
    mkdir -p ~/.gnupg
  2. Generate the key pair: 
    gpg --gen-key
    You will need to select the kind of key, the keysize, and how long the key should be valid for (press enter to accept the default values). You will also need to specify a name, comment, and email address: 
    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?
    Press O to accept the details and continue.
  3. List all keys with their fingerprints: 
    gpg --list-keys --fingerprint
  4. Export the keys: 
    gpg --export --armor "rpmbuild <rpmbuild@example.com>" > EXAMPLE-RPM-GPG-KEY
  5. Import the key to the RPM database to allow RPM origin and integrity verification by running the gpg --import as root on all target systems: 
    rpm --import EXAMPLE-RPM-GPG-KEY
    This will occur automatically during client installations, and should not need to be run manually.
  6. Once an RPM has been created it can be signed with the GPG key and uploaded to the correct channel: 
    rpm --resign package.rpm
rhnpush --server=http[s]://satellite.server/APP package.rpm --channel=custom-channel-name
  7. To verify an RPM package, navigate to the directory that contains the package, and run the following commands: 
    rpm –qip package.rpm
rpm -K package.rpm

Procedure 8.2. Building RPMs

  1. Create a non-privileged user account called rpmbuild for building packages. This will allow several administrators to share the build environment and the GPG key.
  2. In the home directory for the rpmbuild user, /home/rpmbuild, create a file called .rpmmacros: 
    touch /home/rpmbuild/.rpmmacros
  3. Open the .rpmmacros file in your preferred text editor, and add the following lines. The _gpg_name must match the name for the GPG key used for signing RPMs: 
    %_topdir            %(echo $HOME)/rpmbuild
%_signature         %gpg
%_gpg_name          rpmbuild <rpmbuild@example.com>
    The directory listing for the defined top level directory (/home/rpmbuild/rpmbuild in the example above) must have the same directory layout that is present under /usr/src/redhat.

Example 8.1. RPM Specification File

The following is a basic example of an RPM spec file. When building, it should be located in the SPECS directory under the _topdir as defined in user's .rpmmacros file. The corresponding source and patch files should be located in the SOURCES directory. 
  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)