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 RPMs. 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 RHEL 4 system must be used to build RPMs for RHEL 4 based systems and a RHEL 5 system for RHEL 5 RPMs. The package rpm-build must be installed on the build system as a minimum requirement but also additional packages like compilers and libraries might be needed. Production ready RPM packages should be signed with a GPG key allowing 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.
A user account for building, e.g., rpmbuild should be created to allow several administrators to share the build environment and the GPG key. It is recommended that this non-privileged user is used when building RPMs. The home directory for the user, /home/rpmbuild by default, should contain the file .rpmmacros with at least the following content (where _gpg_name must match the name for the GPG key used for signing RPMs):
%_topdir %(echo $HOME)/rpmbuild
%_signature %gpg
%_gpg_name rpmbuild <[email protected]>
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. Appendix B contains a very basic RPM spec file which can be used a basis when starting to craft real spec files needed locally.
2.5.2. GPG Key for Signing RPMs
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, and its passphrase should be known only by trusted administrators.
mkdir -p ~/.gnupg
gpg --gen-key
gpg --list-keys --fingerprint
gpg --export --armor "rpmbuild <[email protected]>" > EXAMPLE-RPM-GPG-KEY
To import this key to the RPM database to allow RPM origin and integrity verification, the following command must be run as root on all target systems (naturally this should happen automatically during client installations):
rpm --import EXAMPLE-RPM-GPG-KEY
Once an RPM has been created it must be signed with the GPG key and uploaded to a correct channel:
rpm --resign package.rpm
rhnpush --server=http[s]://satellite.server/APP package.rpm --channel=custom-channel-name
The following commands will verify an RPM package located in the current directory:
rpm –qip pakcage.rpm
rpm -K package.rpm
2.5.3. RPM Spec File Example
The following is a basic example of an RPM spec file. When building, it should be located in the directory SPECS under the _topdir as defined in user's .rpmmacros file and the corresponding source and patch files should 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 <[email protected]>
- fixed the broken frobber (#86434)
