Task 1
•
•
RPM CREATION
Set up non-root RPM build environment
Rebuild a binary package from a src.rpm
This lab will primarily be done while logged in as a non-root user. Occasionally
you will need root privileges. The lab will direct you to use the su command to
become root when required. Start by logging in —or obtaining a shell as a non-
root user.

1. The creation of RPMs requires the use of several developer tools. These
include both the standard development tools such as the GNU Compiler
Collection, GNU make, and related packages, as well as specific RPM building
12-39tools. Verify that you have the following standard development tool packages
installed:
$ rpm -q gcc
gcc-3.2.2-5
• The exact version returned on this package and others will vary
depending on what version of RHEL/FC or SLES/SL Linux you are
$ rpm -q gcc-c++
using. What matters is that the packages are installed, not the
rpm-c++-3.2.2-5
exact versions which are installed.
$ rpm -q make
make-3.79.1-17
$ rpm -q bison
bison-1.35-6
$ rpm -q binutils
binutils-2.13.90.0.18-9
Note that a full development environment will have many more related
packages installed as well. However, if the above packages are installed, it is a
strong indication that the other needed packages are also installed.
Now, verify that you have the proper RPM building utilities installed. On
RHEL/FC the utilites are part of the rpm-build RPM package which can be
optionally installed. On SLES/SL the utilties are part of the rpm package which
is always installed. Run the following command only on RHEL/FC:
[RHEL/FC]$ rpm -q rpm-build
rpm-build-4.3.2-21
Also determine which RPM version you have installed:
$ rpm -q rpm
rpm-4.3.2-21
Different RPM versions support different features and are used differently, so it
is important to determine which version of RPM is being used.
2. Remove any installed packages that will conflict with packages built manually in
upcoming steps:
[SLES/SL]# rpm -e ltris nmap lbreakout
[RHEL/FC]# rpm -e nmap nmap-frontend
3. Out of the box on RHEL/FC, the system RPM build directory structure,
/usr/src/redhat/, is only writable by the root user. On SLES/SL the RPM
12-40build directory structure is located at /usr/src/packages/ and is writable
by everyone.
The recommended practice is NOT to build RPMs as the root user, create a
RPM build directory tree in your non-root user’s home directory for isolation
from other users.
Make sure your present working directory is your home directory, and then
create the RPM build directory structure:
$ cd
$ mkdir -p rpmbuild/{SOURCES,SPECS,BUILD,SRPMS,RPMS}
$ mkdir rpmbuild/RPMS/{i386,i586,i686}
4. When building RPMs using the rpmbuild command, the RPM software must
locate the RPM build directory structure. To do this, it reads the value of the
%_topdir RPM macro. The macro container files that macros are read from
start with the RPM default /usr/lib/rpm/macros file, then the local system
override file /etc/rpm/macros is consulted (if it exists), and finally, the per-
user macro file is read, ~/.rpmmacros (if it exists). Any macro found in the
per-user macro file will override the same macro in the local system override
file, and any macro found in the local system override file will override macros
from the RPM default file.
Create a ~/.rpmmacros file and set the %_topdir RPM macro to point to • Red Hat Linux 9 and later RHEL/FC releases generate debuginfo
packages by default. These debuginfo RPMs can be installed
the directory structure you created in the previous step. Also, set the
when installing an application to get more capability to debug
%debug_package macro to turn off the automatic creation of the debuginfo
the application. They are not typically necessary, and are often
RPM.
not desired, as they are quite large.
Use your favorite text editor and create the file ~/.rpmmacros with the
following contents:
%_topdir
%(echo $HOME)/rpmbuild
%debug_package
%{nil}
• This %debug_package macro is only needed on systems with
RPM 4.2 or newer.
5. Test your non-root RPM building environment by rebuilding a binary RPM from • This is something that is commonly done when obtaining RPMs
off of the Internet. Unless you know for sure that an Internet
an existing source RPM.
binary RPM was built specifically against your version of Red Hat
The LTris game is a popular Tetris clone. Verify that your RPM build
Linux, it is preferable to download the src.rpm of the
environment works by creating a binary LTris RPM from the source RPM:
package and rebuild a binary RPM with the application linked
$ rpmbuild --rebuild /labfiles/ltris-1.0.4-2.src.rpm
against the exact versions of the libraries provided by your
Installing /labfiles/ltris-1.0.4-2.src.rpm
system, and not other, hopefully compatible libraries, or even
library versions that are not on your system.
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.2652
12-41+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ cd /home/guru/rpmbuild/BUILD
+ rm -rf ltris-1.0.4
+ /usr/bin/gzip -dc /home/guru/rpmbuild/SOURCES/ltris-
1.0.4.tar.gz
+ tar -xf -
+ STATUS=0
...Output Omitted...
After a few minutes have elapsed, look for the Wrote: line near the end of the
output:
Requires: SDL >= 1.1.4 config(ltris) = 1.0.4-2 libSDL-1.2.so.0 libSDL_mixer-1.2.so.0 libc.so.6
libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3) libm.so.6
libpthread.so.0
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/ltris-root
Wrote: /home/guru/rpmbuild/RPMS/i386/ltris-1.0.4-2.i386.rpm • This is the line you are looking for.
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.9014
+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ cd ltris-1.0.4
+ rm -rf /var/tmp/ltris-root
+ exit 0
6. Install the binary RPM which was created in the previous step. The path to the
binary RPM was displayed on the Wrote: line. Remember, you must switch to
the root user to install binary RPMs to the system.
$ su -
Password:
# rpm -Uvh /home/guru/rpmbuild/RPMS/i386/ltris-1.0.4-2.i386.rpm
# exit
$ ltris
• Test the LTris program as a non-root user. You must be working
in the GUI environment for this to work.
12-42Task 2
•
Update an existing source RPM with the latest software version
Linux distributions are a collection of software packages that have been tested
and validated together. The Linux distributions are released periodically,
typically on a 6 month interval, while the individual packages are developed
independently and released on separate release schedules.
Most Linux distribution vendors release updated packages only in two
circumstances, to fix security vulnerabilities, and to fix major bugs that impact
many people. In all other cases, Linux distribution vendors normally wait until
the next version of their distribution to upgraded to any other updated versions.
Sometimes there will be a newer version of a package available —with features
that you need— than what came with the Linux distribution version you are
using. However, this update does not meet the requirements to be released as
an official update for the Linux distribution. In such circumstances, you can
create your own RPM update for the application. This is desirable over just
downloading, compiling and installing the package to /usr/local/ in a un-
tracked state.
1. To update an RPM that shipped with your distribution, start by installing an
existing source RPM, such as one provided with your distribution. The
distribution source RPMs for Nmap have been placed in the /labfiles/
directory.
$ rpm -Uvh /labfiles/nmap-3.70-1.src.rpm
warning: /labfiles/nmap-3.70-1.src.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2
1:nmap
########################################### [100%]
Note that this may not be the actual source RPM for for Nmap for your specific
Linux distribution but for the sake of consistency in the lab, will be used as
such.
This places the pristine source and any patches for this package into the
~/rpmbuild/SOURCES/ directory, and the spec file for this package into the
~/rpmbuild/SPECS/ directory.
2. Copy the newer pristine tarball of Nmap source code into your
~/rpmbuild/SOURCES/ directory. The tarball has been placed in
/labfiles/ for you.
12-43$ cp /labfiles/nmap-3.81.tar.bz2 ~/rpmbuild/SOURCES/
List the contents of the ~rpmbuild/SOURCES/ directory. You should see the
tarball you just copied, plus the files provided by the source RPM you installed
in the previous step.
$ ls -al ~/rpmbuild/SOURCES/
total 2574
drwxrwxr-x
2 guru
guru
1024 Apr 28 12:03 .
drwxrwxr-x
7 guru
guru
1024 Apr 26 23:45 ..
-rw-rw-r--
1 guru
guru
836 Sep 9 2004 inet_aton.patch
-rw-rw-r--
1 guru
guru
324 Sep 9 2004 makefile.patch
-rw-rw-r--
1 guru
guru
922293 Sep 13 2004 nmap-3.00.tar.bz2
-rw-r--r--
1 guru
guru
871101 Mar 22 11:29 nmap-3.81.tar.bz2
$
3. The next step requires modifying the spec file. This can involve two or more
edits, depending on the differences between the older version and the current
version. The two major changes which are always necessary include updating
the version and release numbers (in one or more locations), and adding a
%changelog entry. Additional changes that may be required are forward-
porting patches to the current version, or removing patches that are no longer
required. Finally, sometimes the newer package changes which files are to be
installed, requiring adjustment of the %files section.
Open the Nmap spec file with your favorite text editor, and display the headers
of the file ~/rpmbuild/SPECS/nmap.spec. The following example uses the
nmap-3.70-1 spec file, with line numbers added for reference; small differences
may exist if you are starting from a different spec file.
1 %{!?withgtk1:%define withgtk1 1}
2
3 Summary: Network exploration tool and security scanner
4 Name: nmap
5 Version: 3.70
6 Release: 1
7 License: GPL
8 Group: Applications/System
9 Source0: http://download.insecure.org/nmap/dist/%{name}-%{version}.tar.bz2
10 #Source1: nmapfe.desktop
12-4411 Patch0: inet_aton.patch
12 Patch1: makefile.patch
13 URL: http://www.insecure.org/nmap/
14 BuildRoot: %{_tmppath}/%{name}-root
15 Epoch: 2
16 BuildRequires: openssl-devel, gtk+-devel, pcre-devel, libpcap
Change lines 5 to match the version of the newer Nmap, version 3.81.
Verify that on line 6 the release number is set to 1 since this will be the first
RPM release of version 3.81.
(SLES/SL only) Change part of line 16 from gtk+-devel to gtk-devel
since on SLES/SL this package has the needed dependencies.
(SLES/SL only) On lines 30 and 31 make a similar changing references to
gtk+ and gtk+-devel to gtk and gtk-devel.
Move to the line starting with %changelog. Add a new entry by adding the
following two lines —changing the date to today’s date— followed by a blank
line right beneath it, for example:
* Tue Mar 22 2005 Firstname Lastname <your@emailaddr.com> - 2:3.81-1
- ver 3.81
The number at the end of the first line is a common, yet not required
convention, for including the epoch, version, and release info linked to each
changelog entry.
Finally, save and exit the file.
4. The changes that have been made may be enough. The next step is to verify
that all current patches still apply to the newer source code. To find out, change
into the spec file directory, and execute the Prep stage of the build:
$ cd ~rpmbuild/SPECS/
$ rpmbuild -bp nmap.spec
...Output Omitted...
If everything works out, it should finish with no error messages or prompting for
user input .
If there were problems, be sure to read the next two steps for examples
problems and their solutions. If there were no problems, you may skip to step 8
if you wish.
12-455. You will know that the initial spec file changes are not enough if you get an error
message. The most likely problem you might encounter is that patches which
were previously applied to the older source code no longer apply against the
newer source code. This problem might be caused by any of three different
reasons:
• Perhaps the old patch has been adopted and applied by the software
maintainer, and as such should be dropped from the spec file.
• Perhaps the patch is no longer needed since the software maintainer addressed
the problem using some other mechanism, and as such should be dropped
from the spec file.
• Perhaps the old patch is still needed, but will not apply to the new source. In
this case, a new patch against the current software should be generated to
replace the old patch in the spec file.
Which of these three situations is the cause of any errors, and what action to
take, requires intelligent analysis of the patches and source code of the
software. For example, the Nmap 3.00-4 spec file includes a patch to Nmap,
nmap-3.00-nowarn.patch. When updating to 3.27 and leaving the patch in
place in the spec file, the following error is produced when trying to prepare the
new RPMs:
$ rpmbuild -bp nmap.spec
[snip]
+ echo 'Patch #2 (nmap-3.00-nowarn.patch):'
Patch #2 (nmap-3.00-nowarn.patch):
+ patch -p1 -b --suffix .nowarn -s
The text leading up to this was:
--------------------------
|--- nmap-3.00/tcpip.c.nowarn
2003-01-09 15:46:53.000000000 +0100
|+++ nmap-3.00/tcpip.c 2003-01-09 15:49:34.000000000 +0100
--------------------------
File to patch:
At this point the build process stops, with the patch command waiting for input.
Press <CTRL-C> to abort.
Examining the directory listing of the ~rpmbuild/BUILD/nmap-3.27/
directory reveals that it is likely that the file tcpip.c in the 3.00 source has
been renamed to tcpip.cc in the 3.27 source. This change prevents the
patch from applying.
12-46However, more inspection is needed. Examining the patch file itself,
~rpmbuild/SOURCE/nmap-3.00-nowarn.patch, reveals that the patch is
changing the following lines of code:
printf("Data portion:\n");
while(i < tot_len) printf("%2X%c", data[i], (++i%16)? ' ' : '\n');
To:
printf("Data portion:\n");
while(i < tot_len) {
printf("%2X%c", data[i], ((i+1)%16)? ' ' : '\n');
i++;
}
in two spots in the tcpip.c file. It is important to note that you DO NOT have
to understand the C code to analyze if the patch has already been applied.
Opening the file ~rpmbuild/BUILD/nmap-3.27/tcpip.cc and searching
for the string Data portion, we find the lines (in two different locations):
printf("Data portion:\n");
while(i < tot_len) {
printf("%2X%c", data[i], ((i+1) %16)? ' ' : '\n');
i++;
}
So, it appears as if the official 3.27 Nmap has integrated the patch that was
being applied in the RPM building process to the 3.00 Nmap. So, the proper
course of action is to remove references to this patch in our new spec file.
6. Open the file ~rpmbuild/SPECS/nmap.spec using a text editor and remove
the two lines (prefixed here by their line numbers):
12 Patch2: nmap-3.00-nowarn.patch
36 %patch2 -p 1 -b .nowarn
Save the file and exit the text editor, and re-run the Prep by running the
following command:
$ rpmbuild -bp nmap.spec
12-47Repeat this process until all patching failures are resolved.
7. Once the spec file successfully patches the software without any errors, run the
following command to compile packages of the Nmap software:
$ rpmbuild -ba nmap.spec
8. Another common problem that can prevent the successful building of the new
RPMs are difference in files installed to the virtual root filesystem. If any files
are installed in the virtual root filesystem, but are not referenced in the %files
section, RPM 4.1 and higher releases will display an error and abort the build
process. You will encounter this problem in subsequent lab sequences,
assuming you are using RPM version 4.1 or newer.
When you encounter those sorts of problems, you will have two possible
solutions:
• If the file is needed, add an entry to the %files section so that the file gets
packaged.
• If the file is not needed, use commands in the Install stanza to delete the
unwanted file from the virtual root filesystem.
On RHEL4/FC3 you will see an example of the 2nd scenario with the following
error message will be displayed:
error: Installed (but unpackaged) file(s) found:
/usr/share/applications/nmapfe.desktop
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/share/applications/nmapfe.desktop
This refers to a menu desktop file. Open the spec file with a text editor, and
examine the %install section. You will notice the following lines:
# remove unused files
rm -f $RPM_BUILD_ROOT/usr/share/gnome/apps/Utilities/nmapfe.desktop
The intent is to delete the menu desktop file, but in this newer version it is
being installed into a different location so this deletion attempt is failing.
Correct the line to point to the new location by editing the line to read:
rm -f $RPM_BUILD_ROOT/usr/share/applications/nmapfe.desktop
12-48Re-run the following command to compile packages of the Nmap software:
$ rpmbuild -ba nmap.spec
This should complete with out error.
On SLES9/SL92 you will encounter two problems. The first build attempt should
end with the following error:
RPM build errors:
File not found: /var/tmp/nmap-root/usr/share/nmap
This indicates that a required directory was not found in the virtual root. Under
the /usr/share/nmap/ directory the file nmap.dtd should exist. Do a
search to find where it is is located inside of the virtual root:
$ find /var/tmp/nmap-root -name nmap.dtd
/var/tmp/nmap-root/var/tmp/nmap-root/usr/share/nmap/nmap.dtd
If you examine the path you’ll notice that there is a var/tmp/nmap-root/
inside of /var/tmp/nmap-root/. This is likely a error that occurs during the
installation phase, open the spec file and locate the line make install line:
%makeinstall nmapdatadir=$RPM_BUILD_ROOT%{_datadir}/nmap
Edit the line and remove the extra parameter as the stock %makeinstall
macro should be sufficient. Change the line to read:
%makeinstall
Re-run the following command to compile packages of the Nmap software:
$ rpmbuild -ba nmap.spec
You will see an example of the 2nd scenario with the following error message
will be displayed:
error: Installed (but unpackaged) file(s) found:
/usr/share/applications/nmapfe.desktop
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/share/applications/nmapfe.desktop
This refers to a menu desktop file. Open the spec file with a text editor, and
examine the %install section. You will notice the following lines:
# remove unused files
rm -f $RPM_BUILD_ROOT/usr/share/gnome/apps/Utilities/nmapfe.desktop
12-49The intent is to delete the menu desktop file, but in this newer version it is
being installed into a different location so this deletion attempt is failing.
Correct the line to point to the new location by editing the line to read:
rm -f $RPM_BUILD_ROOT/usr/share/applications/nmapfe.desktop
Re-run the following command to compile packages of the Nmap software:
$ rpmbuild -ba nmap.spec
This should complete with out error.
9. Install the new updated Nmap RPMs as root:
$ su -
Password:
[RHEL4/FC3 ]# rpm -Uvh /home/guru/rpmbuild/RPMS/i386/nmap-*
[SLES9/SL92]# rpm -Uvh /home/guru/rpmbuild/RPMS/i586/nmap-*
Preparing...
########################################### [100%]
1:nmap
########################################### [ 50%]
2:nmap-frontend
########################################### [100%]
10. Newer Nmap versions supports version scans that report the version of
services. Try using this feature during a confirmation run to see that your new
Nmap RPM is working properly.
# nmap -sV 127.0.0.1
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-03-25 18:39 MST
Interesting ports on localhost (127.0.0.1):
(The 1659 ports scanned but not shown below are in state: closed)
PORT
STATE SERVICE VERSION
22/tcp open ssh
OpenSSH 3.9p1 (protocol 1.99)
25/tcp open smtp
Postfix smtpd
111/tcp open rpcbind 2 (rpc #100000)
631/tcp open ipp
CUPS 1.1
Nmap finished: 1 IP address (1 host up) scanned in 5.379 seconds
An older version of NMAP without the version scanning feature would have
returned the error:
12-50Illegal Argument to -P, use -P0, -PI, -PB, -PM, -PP, -PT, or -PT80 (or whatever number you want for
the TCP probe destination port)
QUITTING!
12-51Task 3
•
•
•
Create a spec file from scratch for an unpackaged software application.
Revise packages to correct packaging errors.
Create multiple RPMs from a single source RPM.
LBreakout2, http://lgames.sourceforge.net/index.php?project=LBreakout2, is
a popular Breakout-style game for Linux. Unfortunately, it is not provided in
RPM format, though the source code is readily available from the
http://lgames.sourceforge.net/ home page. Being a devotee of all things
Breakout and Breakout-related, you have decided to prepare an RPM of
LBreakout2 for your system.
This lab task requires that following packages are installed so that LBreakout2
can be compiled:
SDL-devel
libpng-devel
The RPM packages have the same name on RHEL/FC and SLES/SL. Verify that
the packages are installed, and if not, install them now.
1. When creating an RPM from scratch, most packagers start with a skeleton
spec file which lists common lines used in most spec files. Through a trial-and-
error process, this template file can be modified and tested until it produces a
good set of RPMs. A template spec file has been provided in your /labfiles
directory; begin by copying this spec file for use with LBreakout2:
$ cp /labfiles/template.spec ~/rpmbuild/SPECS/lbreakout2.spec
2. A copy of the source code for LBreakout2 has been provided for you. Copy this
source code into your SOURCES directory:
$ cp /labfiles/lbreakout2-2.4.1.tar.gz ~/rpmbuild/SOURCES
3. Once the source code for an application is in place and a spec file exists, the
next task is to modify the spec to compile your software. Open your spec file
for editing:
$ cd rpmbuild/SPECS/
12-52$ vim lbreakout2.spec
4. Complete the Header stanza. At a minimum, you will need Summary, Name,
Version, Release, Epoch, License, Group, Source, URL, and BuildRoot
directives. Try creating these yourself, then compare your solution with the
following possible solution:
Summary: Breakout clone
Name: lbreakout2
Version: 2.4.1
Release: 1
Epoch: 0
License: GPL
Group: Amusements/Games
Source0: http://ftp1.sourceforge.net/lgames/%{name}-%{version}.tar.gz
URL: http://lgames.sourceforge.net/index.php?project=LBreakout2
BuildRoot: %{_tmppath}/%{name}-root
5. The Header stanza also requires a %description directive which provides
users with a fuller description of the purpose of the packaged application.
Create your own %description block, similar to the following:
%description
The polished successor to LBreakout offers you a new challenge in more than 50 levels with loads of
new bonuses (goldshower, joker, explosive balls, bonus magnet ...), maluses (chaos, darkness, weak
balls, malus magnet ...) and special bricks (growing bricks, explosive bricks, regenerative bricks,
indestructible bricks, chaotic bricks).
And if you're through with all the levels you can create complete new level sets with the integrated
easy-to-use level editor!
6. Save your spec file and quit the editor. At this point, you can test your spec file
to be certain that your Header stanza works:
$ rpmbuild -bp lbreakout2.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.39167
• RPM tells you it is executing the %prep section of the spec file.
+ umask 022
+ cd /home/guru/rpmbuild/BUILD
12-53+ LANG=C
+ export LANG
+ cd /home/guru/rpmbuild/BUILD
+ rm -rf lbreakout2-2.4.1
+ /usr/bin/gzip -dc /home/guru/rpmbuild/SOURCES/lbreakout2-2.4.1.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd lbreakout2-2.4.1
++ /usr/bin/id -u
+ '[' 50016 = 0 ']'
++ /usr/bin/id -u
+ '[' 50016 = 0 ']'
+ /bin/chmod -Rf a+rX,g-w,o-w .
+ exit 0
• RPM indicates that the %prep section was processed
successfully.
$
7. The template spec file you used as a starting place has a commonly used Build
stanza already created. Try compiling your software to see if this default Build
stanza will work:
$ rpmbuild -bc lbreakout2.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.62876
• First, the %prep stanza is processed
...Output Omitted...
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.81466
• After the software is prepared, the %build stanza compiles it
...Output Omitted...
gcc -O2 -g -pipe -march=i386 -mcpu=i686 -Wall -
• This line shows the step of actually linking together the compiled
objects to produce the lbreakout2 executable.
I/usr/include/SDL -D_REENTRANT -o lbreakout2 credit.o
shine.o extras.o balls.o shrapnells.o shots.o event.o pad-
dle.o frame.o misc.o bricks.o difficulty.o player.o game.o
file.o levels.o config.o item.o menu.o manager.o value.o
chart.o editor.o help.o hint.o theme.o client.o
client_recv.o client_data.o client_game.o client_handlers.o
comm.o display.o main.o -lSDL_mixer ../common/libcommon.a
../gui/libGui.a -lpng -lz -lm -L/usr/lib -Wl,-
rpath,/usr/lib -lSDL -lpthread
make[3]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
12-54make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
Making all in docs
make[2]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[2]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
make[1]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
+ exit 0
• This exit 0 indicates that the %build completed successfully.
$
8. So far, it looks like the default Build stanza should work. Next, test out the
commonly used Install stanza which was provided in the template spec file:
On RHEL/FC run the following command and examine the output produced, on
SLES/SL skip to step 18. on page 62 (unless you want to read about the types of
problems that can occur).
$ rpmbuild -bi lbreakout2.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.89196
• First, the %prep
...Output Omitted...
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.89196
• Next, the %build
...Output Omitted...
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.70963
• Next, the %install
...Output Omitted...
Making install in client
make[1]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
Making install in gfx
make[2]: Entering directory
`/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx'
Making install in AbsoluteB
make[3]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx/AbsoluteB'
make[4]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx/AbsoluteB'
make[4]: Nothing to be done for `install-exec-am'.
/bin/sh ../../../mkinstalldirs /usr/share/games/lbreakout2/gfx/AbsoluteB
mkdir /usr/share/games/lbreakout2
mkdir: cannot create directory `/usr/share/games/lbreakout2': Permission denied
mkdir /usr/share/games/lbreakout2/gfx
12-55mkdir: cannot create directory `/usr/share/games/lbreakout2/gfx': No such file or directory
mkdir /usr/share/games/lbreakout2/gfx/AbsoluteB
mkdir: cannot create directory `/usr/share/games/lbreakout2/gfx/AbsoluteB': No such file or directory
make[4]: *** [install-data-local] Error 1
make[4]: Leaving directory
`/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx/AbsoluteB'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx/AbsoluteB'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.70963 (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.70963 (%install)
$
9. The default %install script will NOT work for this software. So, try to figure
out why. Looking at the spec file, you’ll see that the current %build script
does:
%install
rm -rf %{buildroot}
%makeinstall
The problem here is that %makeinstall is not working. Looking through the
output from the %install, you see that the %makeinstall did:
make prefix=/var/tmp/lbreakout2-root/usr
exec_prefix=/var/tmp/lbreakout2-root/usr
bindir=/var/tmp/lbreakout2-root/usr/bin
sbindir=/var/tmp/lbreakout2-root/usr/sbin syscon-
fdir=/var/tmp/lbreakout2-root/etc data-
dir=/var/tmp/lbreakout2-root/usr/share
includedir=/var/tmp/lbreakout2-root/usr/include lib-
dir=/var/tmp/lbreakout2-root/usr/lib libex-
12-56
• RPM indicates that the %install script did NOT complete
successfully.ecdir=/var/tmp/lbreakout2-root/usr/libexec
localstatedir=/var/tmp/lbreakout2-root/var sharedstate-
dir=/var/tmp/lbreakout2-root/usr/com
mandir=/var/tmp/lbreakout2-root/usr/share/man info-
dir=/var/tmp/lbreakout2-root/usr/share/info install
That is, it ran the make install command with options intented to get it to
install software to a virtual directory structure under the
/var/tmp/lbreakout2-root/ directory rather than under /. However, as
the error indicates, this failed:
make[4]: Entering directory
`/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gfx/AbsoluteB'
make[4]: Nothing to be done for `install-exec-am'.
/bin/sh ../../../mkinstalldirs /usr/share/games/lbreakout2/gfx/AbsoluteB
mkdir /usr/share/games/lbreakout2
• This should have been /var/tmp/lbreakout2-
root/usr/share/games/lbreakout2.
mkdir: cannot create directory
`/usr/share/games/lbreakout2': Permission denied
For some reason, the %makeinstall macro is not capable of getting this
software to install into the Buildroot. These sorts of problems are quite
common-place, and correcting them typically requires either a modification of
the spec file, an addition of a patch to modify the Makefiles which specify
how the software gets compiled and installed, or some combination of both
spec modifications and code patches.
10. To get this software packaged, you must figure out why it cannot currently be
installed into the Buildroot. So far, you know that executing the
make install command in the client subdirectory of the source code fails
because it tries to install software to /usr/share/games/lbreakout2/
rather than /var/tmp/lbreakout2-
root/usr/share/games/lbreakout2/. Looking at the
/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/Makefile,
you’ll see that it does:
...
hi_inst_flag = -DHI_DIR=\"/var/lib/games\"
inst_dir = /usr/share/games/lbreakout2
inst_flag = -DSRC_DIR=\"/usr/share/games/lbreakout2\"
...
12-57The problem here is this middle line, line 81. If this Makefile were written
correctly, that line would instead look something like:
inst_dir = $(datadir)/games/lbreakout2
where it uses a shell variable which can be overridden to specify where the
software gets installed.
11. Fixing this problem can be done in a couple of different ways:
• You could create a patch for the Makefile and apply it during the %prep
section. This is the “correct” solution, but is actually quite difficult, since the
Makefiles for this program, like many other Linux applications, are automatically
generated during the %build process by the autoconf software suite.
• You could add a script as the first line of the %install stanza which edits the
incorrect Makefiles. This is a little bit easier to do, but is a less “correct”
solution.
In many cases, though, a third option will also be available: you might simply be
able to modify the incorrect Makefile variable by passing the correct value to
the %makeinstall macro. If possible, that solution will be the simplest. In this
case, the value of the inst_dir variable is incorrect, so modify the spec file to
correct that variable. In the %install stanza, change the %makeinstall line
to:
• This line is too long to fit on a single 80-column line on the
%makeinstall \
screen. For readability, it can be typed on two lines, as is done
inst_dir=${RPM_BUILD_ROOT}/usr/share/games/lbreakout2
here, with a back-slash (\) at the end of the first line. This back-
slash indicates to rpm that this line continues on to a
subsequent line.
12. Once you have made this change, save the spec file and then try once again to
compile the software and install it to a virtual root directory:
$ rpmbuild -bi lbreakout2.spec
...Output Omitted...
Making install in gui_theme
make[2]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gui_theme'
make[3]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/gui_theme'
make[3]: Nothing to be done for `install-exec-am'.
/bin/sh ../../mkinstalldirs /var/tmp/lbreakout2-root/usr/share/games/lbreakout2/gui_theme
mkdir /var/tmp/lbreakout2-
• This solved the problem -- the directory is now being created in
the virtual directory tree.
root/usr/share/games/lbreakout2/gui_theme
...Output Omitted...
12-58if ! test -f /var/lib/games/lbreakout2.hscr; then \
/usr/bin/install -c -m 644 -m 666 empty.hscr /var/lib/games/lbreakout2.hscr; \
fi;
/usr/bin/install: cannot create regular file `/var/lib/games/lbreakout2.hscr': Permission denied
make[3]: *** [install-data-local] Error 1
make[3]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.72065 (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.72065 (%install)
$
13. You’ve solved the first problem, but this revealed a new problem to solve. Here,
the make install command is doing:
make[3]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client'
...
if ! test -f /var/lib/games/lbreakout2.hscr; then \
/usr/bin/install -c -m 644 -m 666 empty.hscr
/var/lib/games/lbreakout2.hscr; \
fi;
/usr/bin/install: cannot create regular file
`/var/lib/games/lbreakout2.hscr': Permission denied
make[3]: *** [install-data-local] Error 1
This is a similar problem to the previous one. If you search through the
/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/client/Makefile
file for the string /var/lib/games, you’ll see that the Makefile does:
...
doc_dir = /usr/doc
hi_dir = /var/lib/games
hi_inst_flag = -DHI_DIR=\"/var/lib/games\"
12-59...
The problem here is this middle line, line 79. If this Makefile were written
correctly, that line would instead look something like:
hi_dir = $(localstatedir)/lib/games
where it uses a shell variable which can be overridden to specify where the
software gets installed.
14. As with the previous problem, this problem can be fixed by patching the
Makefiles, modifying the Makefiles within the %install script, or by passing a
variable to the %makeinstall macro. Edit the spec file again, and modify the
%makeinstall macro so that it reads:
%makeinstall \
inst_dir=${RPM_BUILD_ROOT}/usr/share/games/lbreakout2 \
hi_dir=${RPM_BUILD_ROOT}/var/lib/games
15. Once you have made this change, save the spec file and then try once again to
compile the software and install it to a virtual root directory:
$ rpmbuild -bi lbreakout2.spec
...Output Omitted...
if ! test -f /var/tmp/lbreakout2-
• This solved the problem -- the directory is now being created in
the virtual directory tree.
root/var/lib/games/lbreakout2.hscr; then \
/usr/bin/install -c -m 644 -m 666 empty.hscr
/var/tmp/lbreakout2-root/var/lib/games/lbreakout2.hscr; \
fi;
...Output Omitted...
Making install in docs
make[1]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[2]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[2]: Nothing to be done for `install-exec-am'.
/bin/sh ../mkinstalldirs /usr/doc/lbreakout2
mkdir /usr/doc
mkdir: cannot create directory `/usr/doc': Permission denied
mkdir /usr/doc/lbreakout2
mkdir: cannot create directory `/usr/doc/lbreakout2': No such file or directory
make[2]: *** [install-data-local] Error 1
12-60make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.33062 (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.33062 (%install)
$
16. You’ve solved the second problem, but now you’ve got a new problem to solve.
Here, the make install command is doing:
make[1]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
...
/bin/sh ../mkinstalldirs /usr/doc/lbreakout2
mkdir /usr/doc
mkdir: cannot create directory `/usr/doc': Permission denied
...
If you look at the /home/guru/rpmbuild/BUILD/lbreakout2-
2.4.1/docs/Makefile file for the string /usr/doc, you’ll find that it does:
...
audio_flag = -DAUDIO_ENABLED
doc_dir = /usr/doc
hi_dir = /var/lib/games
...
17. As with the other problems, the trouble here is this middle line, line 78. It needs
to be corrected to install to the virtual directory tree. This line also has another
flaw. On RHEL/FC systems, all documentation files should be put in the
directory /usr/share/doc but this line specifies that they will be placed in
the /usr/doc directory.
As with the previous problems, this mistake could be fixed in three different
ways. To solve this problem, edit the lbreakout2 spec file again, and change
the %makeinstall line to the following:
12-61%makeinstall \
inst_dir=${RPM_BUILD_ROOT}/usr/share/games/lbreakout2 \
hi_dir=${RPM_BUILD_ROOT}/var/lib/games \
doc_dir=${RPM_BUILD_ROOT}/usr/share/doc
18. Once you have made this change, save the spec file and then try once again to
compile the software and install it to a virtual root directory:
$ rpmbuild -bi lbreakout2.spec
...Output Omitted...
mkdir /var/tmp/lbreakout2-root/usr/share/doc
• Problem solved!
mkdir /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2
/usr/bin/install -c -m 644 index.html /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2/index.html
make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[1]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1/docs'
make[1]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
make[2]: Entering directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
make[1]: Leaving directory `/home/guru/rpmbuild/BUILD/lbreakout2-2.4.1'
+ /usr/lib/rpm/redhat/brp-compress
• At this point, the %install has finished, and RPM is now
processing the %files stanza.
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-static-archive
/usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
Processing files: lbreakout2-2.4.1-1
error: File not found by glob: /var/tmp/lbreakout2-root/usr/lib/*.so.*
error: File not found: /var/tmp/lbreakout2-root/usr/share/lbreakout2
error: File not found by glob: /var/tmp/lbreakout2-root/usr/share/man/man8/*
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.22825
+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ cd lbreakout2-2.4.1
+ DOCDIR=/var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ export DOCDIR
+ rm -rf /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
12-62+ /bin/mkdir -p /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ cp -pr AUTHORS COPYING ChangeLog NEWS README TODO /var/tmp/lbreakout2-
root/usr/share/doc/lbreakout2-2.4.1
+ exit 0
RPM build errors:
File not found by glob: /var/tmp/lbreakout2-root/usr/lib/*.so.*
File not found: /var/tmp/lbreakout2-root/usr/share/lbreakout2
File not found by glob: /var/tmp/lbreakout2-root/usr/share/man/man8/*
$
19. At this point, the %build and %install sections of the spec file are correct.
Now, the RPM compile is failing because the default %files stanza in the
template file is not correct. To solve this problem, first use the ls command to
explore what files and directories are in the Buildroot,
/var/tmp/lbreakout2-root. You should find the following files and
directories:
/var/lib/games/lbreakout2.hscr
/usr/share/games/lbreakout2/{gfx,gui_theme,levels,sounds}
/usr/share/doc/lbreakout2
/usr/share/doc/lbreakout2-2.4.1
/usr/bin/lbreakout2
/usr/bin/lbreakout2server
20. There are two problems here. One is that these files and directories need to be
listed in the %files section of the spec file.
There is another, more subtle problem, however. Looking again at this ls
output, you should notice that there are two documentation directories:
RHEL/FC: /usr/share/doc/lbreakout2
RHEL/FC: /usr/share/doc/lbreakout2-2.4.1
---------
SLES/SL: /usr/doc/lbreakout2
SLES/SL: /usr/share/doc/packages/lbreakout2
There should only be one documentation directory.
12-63On RHEL/FC it should be the one with the application version,
/usr/share/doc/lbreakout2-2.4.1.
On SLES/SL it should be /usr/share/doc/packages/lbreakout2/.
21. If you look at the contents of the wrongly located documentation
directory you should discover that it's all HTML documentation. To combine
these two directories, you should put the contents of the rouge directory as
subdirectory named html in the proper documentation directory.
On RHEL/FC modify the %install stanza of the spec file to end with the line:
mv ${RPM_BUILD_ROOT}/usr/share/doc/lbreakout2 html
On SLES/SL modify the %install stanza of the spec file to end with the line:
mv ${RPM_BUILD_ROOT}/usr/doc/lbreakout2 html
On RHEL/FC When you finish, your Install stanza should read:
%install
rm -rf %{buildroot}
%makeinstall \
inst_dir=${RPM_BUILD_ROOT}/usr/share/games/lbreakout2 \
hi_dir=${RPM_BUILD_ROOT}/var/lib/games \
doc_dir=${RPM_BUILD_ROOT}/usr/share/doc
mv ${RPM_BUILD_ROOT}/usr/share/doc/lbreakout2 html
%clean
rm -rf %{buildroot}
On SLES/SL When you finish, your Install stanza should read:
%install
rm -rf %{buildroot}
%makeinstall
mv ${RPM_BUILD_ROOT}/usr/doc/lbreakout2 html
%clean
rm -rf %{buildroot}
12-6422. After modifying the contents of the documentation directory, you need to
adjust the %files section to list the newly included documentation files. Add
the html directory to the %doc macro within the %files stanza, so that it
reads:
%doc AUTHORS COPYING ChangeLog NEWS README TODO html
23. Look at the rest of your %files stanza. It currently reads:
%files
%defattr(-, root, root)
%doc AUTHORS COPYING ChangeLog NEWS README TODO html
%{_bindir}/*
%{_libdir}/*.so.*
%{_datadir}/%{name}
%{_mandir}/man8/*
Compare this with the list you obtained in step 19 of the files which you wish to
package. When you compare the two lists, you will find that the %{_bindir}
file-matching macro is needed, but that the %{_libdir} and the %{_mandir}
statements need to be deleted.
• This statement sets ownership on the packaged files and
directories.
• The files in /var/tmp/lbreakout2-root/usr/bin
• The files in /var/tmp/lbreakout2-root/usr/lib/*.so.*
• The files in /var/tmp/lbreakout2-root/usr/share/lbreakout2
• The files in /var/tmp/lbreakout2-root/usr/share/man/man8
24. Correct your %files stanza to define the correct files produced with
LBreakout2 by changing it to the following:
%files
%defattr(-, root, root)
%doc AUTHORS COPYING ChangeLog NEWS README TODO html
%{_bindir}/*
%{_datadir}/%{name}
25. Once you have made this change, save the spec file and then try once again to
compile the software and install it to a virtual root directory:
$ rpmbuild -bi lbreakout2.spec
...Output Omitted...
Processing files: lbreakout2-2.4.1-1
error: File not found: /var/tmp/lbreakout2-
• The %files stanza listed a file which could not be found.
root/usr/share/lbreakout2
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.546
12-65+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ cd lbreakout2-2.4.1
+ DOCDIR=/var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ export DOCDIR
+ rm -rf /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ /bin/mkdir -p /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ cp -pr AUTHORS COPYING ChangeLog NEWS README TODO html
/var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ exit 0
RPM build errors:
File not found: /var/tmp/lbreakout2-root/usr/share/lbreakout2
$
26. At this point, the spec file is almost working. This procedure failed because the
%files stanza is still slightly incorrect. The %files stanza is currently trying
to package the directory /usr/share/lbreakout2, which does not exist.
Looking back at the list of files and directories produced in step 19. on page 63,
you’ll see that this should instead be /usr/share/games/lbreakout2. To
fix this problem, edit the spec file and change the line:
%{_datadir}/%{name}
to:
%{_datadir}/games/%{name}
27. Once you have made this change, save the spec file and then try once again to
compile the software and install it to a virtual root directory:
$ rpmbuild -bi lbreakout2.spec
...Output Omitted...
28. If you are using RPM 4.1 or later versions, when you complete the previous
step, you will get output similar to the following:
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/lbreakout2-root
12-66error: Installed (but unpackaged) file(s) found:
/var/lib/games/lbreakout2.hscr
• This error indicates that a file is installed in the virtual root, but is
not listed in the %files stanza.
RPM build errors:
Installed (but unpackaged) file(s) found:
/var/lib/games/lbreakout2.hscr
• This is the problem mentioned in Step 8 of Task 2. RPM 4.1 and
This build attempt is getting closer to succeeding. Now, the build is exiting
later releases check for installed but unpackaged files and
because a file, /var/lib/games/lbreakout2.hscr, was found in the virtual
produce a warning or error when any are encountered.
root, but was not listed in the %files stanza. Skip the next step, and proceed
to step 30 which explains how to add this missing file to the spec file.
29. If you are using RPM 4.0 or older versions, you will not get output similar to that • If you are using RPM 4.1 or newer versions, you DO NOT have to
complete the commands in this step. Be grateful!
in the previous step. Instead, your build will actually appear to complete
successfully, producing output similar to the following:
...Output Omitted...
+ exit 0
Finding Provides: (using /usr/lib/rpm/find-provides)...
Finding Requires: (using /usr/lib/rpm/find-requires)...
PreReq: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(Com-
pressedFileNames) <= 3.0.4-1
Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
Requires: ld-linux.so.2 libartsc.so.0 libaudiofile.so.0
libc.so.6 libdl.so.2 libesd.so.0 libm.so.6 libpng.so.2
libpthread.so.0 libSDL-1.2.so.0 libX11.so.6 libXext.so.6
libz.so.1 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3) libm.so.6(GLIBC_2.0)
libpthread.so.0(GLIBC_2.0)
RPM 4.1 and later automatically “validate” installations to make sure that all
• Remember, these commands are only used if you are using RPM
4.0 or earlier releases.
files installed into the ${RPM_BUILD_ROOT}, complaining if any files were
installed but not packaged. RPM 4.0 and earlier releases do not do this, so you
must manually validate your installation. To do this, first prepare a list of the
files installed by the completed LBreakout2 install, and store these files into a
text file in your home directory:
$ find /var/tmp/lbreakout2-root | sort > ~/lbreakout2-installed-files
12-67This list of files will incorrectly prepend the ${RPM_BUILD_ROOT} at the
beginning of every file name. Strip this path off:
$ perl -pi -e 's/^\/var\/tmp\/lbreakout2-root//g' ~/lbreakout2-installed-files
Now, actually build a package:
$ rpmbuild -ba lbreakout2.spec
...Output Omitted...
Wrote: /home/guru/rpmbuild/SRPMS/lbreakout2-2.4.1-1.src.rpm
Wrote: /home/guru/rpmbuild/RPMS/i386/lbreakout2-2.4.1-
• This is the location of the built package.
1.i386.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.63876
+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ cd lbreakout2-2.4.1
+ rm -rf /var/tmp/lbreakout2-root
+ exit 0
Once your package is built, query it for the files it contains, and store those file
names in a text file in your home directory:
$ rpm -qlp ../RPMS/i386/lbreakout2-2.4.1-1.i386.rpm | sort >
~/lbreakout2-packaged-files
Finally, compare the list of packaged files with the list of installed files:
$ diff -Naur ~/lbreakout2-packaged-files ~/lbreakout2-
• In this output, a plus sign (+) indicates a file which was
installed but not packaged.
installed-files
--- /home/guru/lbreakout2-packaged-files
+++ /home/guru/lbreakout2-installed-files
@@ -1,5 +1,10 @@
+
+/usr
+/usr/bin
/usr/bin/lbreakout2
/usr/bin/lbreakout2server
+/usr/share
+/usr/share/doc
/usr/share/doc/lbreakout2-2.4.1
/usr/share/doc/lbreakout2-2.4.1/AUTHORS
12-68
Thu May 22 14:43:42 2003
Thu May 22 14:44:15 2003/usr/share/doc/lbreakout2-2.4.1/ChangeLog
@@ -42,6 +47,7 @@
/usr/share/doc/lbreakout2-2.4.1/NEWS
/usr/share/doc/lbreakout2-2.4.1/README
/usr/share/doc/lbreakout2-2.4.1/TODO
+/usr/share/games
/usr/share/games/lbreakout2
/usr/share/games/lbreakout2/gfx
/usr/share/games/lbreakout2/gfx/AbsoluteB
@@ -247,3 +253,7 @@
/usr/share/games/lbreakout2/sounds/wall.wav
/usr/share/games/lbreakout2/sounds/weak_ball.wav
/usr/share/games/lbreakout2/sounds/wontgiveup.wav
+/var
+/var/lib
+/var/lib/games
+/var/lib/games/lbreakout2.hscr
Looking over that list, you’ll see that the following files or directories are
installed, but are not included in the package:
/usr
/usr/bin
/usr/share
/usr/share/doc
/usr/share/games
/var
/var/lib
/var/lib/games
/var/lib/games/lbreakout2.hscr
Of those files and directories, most are shared directories which should NOT be
part of the package, but one file, /var/lib/games/lbreakout2.hscr, does
need to be added to the package.
12-6930. Your spec file currently correctly compiles LBreakout2, but it fails to install one
file which is needed by LBreakout2. To fix this problem, add this file to the
%files list in the spec file by adding the line:
%{_localstatedir}/lib/games/lbreakout2.hscr
When you finish, your Files stanza should now look like:
%files
%defattr(-, root, root)
%doc AUTHORS COPYING ChangeLog NEWS README TODO html
%{_bindir}/*
%{_datadir}/games/%{name}
%{_localstatedir}/lib/games/lbreakout2.hscr
31. Once you have made this change, save the spec file and then try once again to
compile the software and install it to a virtual root directory:
$ rpmbuild -bi lbreakout2.spec
...Output Omitted...
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /sbin/ldconfig libSDL-1.2.so.0 libSDL_mixer-1.2.so.0 libc.so.6
libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.3) libm.so.6 libm.so.6(GLIBC_2.0) libpng12.so.0
libpthread.so.0 libpthread.so.0(GLIBC_2.0) libz.so.1
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/lbreakout2-root
$
32. This time, the build worked! To finish packaging your software, edit the spec
file one final time and update the Changelog with contents similar to the
following:
%changelog
* Tue Apr 02 2005 John Doe <student@gurulabs.com> 2.4.1-1
- Initial package
12-7033. Once you have made this change, save the spec file and then try once again to
compile the software, install it to a virtual root directory, and package it:
$ rpmbuild -ba lbreakout2.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.1332
• First, the %prep
...Output Omitted...
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.1332
• Next, the %build
...Output Omitted...
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.41692
• Next, the %install
...Output Omitted...
Processing files: lbreakout2-2.4.1-3
• Next, the %files
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.60710
• The %doc macro in %files
+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ cd lbreakout2-2.4.1
+ DOCDIR=/var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ export DOCDIR
+ rm -rf /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ /bin/mkdir -p /var/tmp/lbreakout2-root/usr/share/doc/lbreakout2-2.4.1
+ cp -pr AUTHORS COPYING ChangeLog NEWS README TODO html /var/tmp/lbreakout2-
root/usr/share/doc/lbreakout2-2.4.1
+ exit 0
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /sbin/ldconfig libSDL-1.2.so.0 libSDL_mixer-1.2.so.0 libc.so.6 libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3) libm.so.6 libm.so.6(GLIBC_2.0)
libpng12.so.0 libpthread.so.0 libpthread.so.0(GLIBC_2.0) libz.so.1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/lbreakout2-root
Wrote: /home/guru/rpmbuild/SRPMS/lbreakout2-2.4.1-3.src.rpm • Next, build the SRPM
Wrote: /home/guru/rpmbuild/RPMS/i386/lbreakout2-2.4.1-
• Next, build all RPMs
3.i386.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.81877
• Finish by executing the %clean macro from the %install section
+ umask 022
+ cd /home/guru/rpmbuild/BUILD
+ cd lbreakout2-2.4.1
+ rm -rf /var/tmp/lbreakout2-root
+ exit 0
$
12-7134. You've now got the RPM
/home/guru/rpmbuild/RPMS/i386/lbreakout2-2.4.1-1.i386.rpm!
To try it out, install it as root:
RHEL/FC $ su -c "rpm -Uvh ../RPMS/i386/lbreakout2-2.4.1-1.i386.rpm"
SLES/SL $ su -c "rpm -Uvh ../RPMS/i586/lbreakout2-2.4.1-1.i586.rpm"
Password:
Preparing...
1:lbreakout2
$
########################## [100%]
########################## [100%]
35. Rn the LBreakout2 program to verify that it works:
$ lbreakout2
36. After playing a game of LBreakout2, verify the RPM:
$ rpmverify -V lbreakout2
S.5....T
/var/lib/games/lbreakout2.hscr
$
Here, you see that the file /var/lib/games/lbreakout2.hscr has been
modified in various ways:
• Its size is modified (S)
• Its MD5 hash is different, meaning its contents are changed (5)
• Its timestamps are changed (T)
37. Good Linux administrators periodically verify the files on their systems to make
sure they are not modified, since most installed files should never change.
However, some files (such as this high scores file) might reasonably be
modified. RPM allows files which might change to be flagged as configuration
files, so that administrators verifying the system won’t panic when they notice
changes to these files.
To accomodate your administrators, you decide to revise your lbreakout2 RPM.
Fix your lbreakout2 spec file to indicate that the high-scores file for LBreakout2
is a configuration file. To do this, edit your spec file and change the line in the
%files stanza for the high-scores file from:
%{_localstatedir}/lib/games/lbreakout2.hscr
12-72
• You must be in X for this program to run.
• This is the high-scores file. It will appear modified, as it does
here, as long as you’ve beaten one of the previous high scores.to
%config %{_localstatedir}/lib/games/lbreakout2.hscr
Also, modify the Release field in the Header stanza, changing it to:
Release: 2
Finally, document the change you’ve made to the package by adding an entry
to the %changelog section similar to the following:
* Tue Apr 02 2005 John Doe <student@gurulabs.com> 2.4.1-2
- Mark high-scores file as config file
• The %config macro in the %files section indicates that the
packaged file is a configuration file, and might reasonably
change on a production system.
38. Once you have made these three changes to revise your package, save the
spec file and then try once again to compile the software, install it to a virtual
root directory, and package it:
$ rpmbuild -ba lbreakout2.spec
...Output Omitted...
Wrote: /home/guru/rpmbuild/SRPMS/lbreakout2-2.4.1-2.src.rpm
Wrote: /home/guru/rpmbuild/RPMS/i386/lbreakout2-2.4.1-2.i386.rpm
...Output Omitted...
$
39. Now that you’ve built this revised package, upgrade using the -F option to the
rpm command and test it out:
RHEL/FC $ su -c "rpm -Fvh ../RPMS/i386/lbreakout2-2.4.1-2.i386.rpm"
SLES/SL $ su -c "rpm -Fvh ../RPMS/i586/lbreakout2-2.4.1-2.i586.rpm"
Password:
Preparing...
########################## [100%]
1:lbreakout2
########################## [100%]
$ lbreakout2
40. Play a couple more games of LBreakout2, making sure to get on the High
Scores list, then verify the RPM again:
$ rpmverify -V lbreakout2
S.5....T c /var/lib/games/lbreakout2.hscr
$
12-73The high-scores file is now correctly flagged as a configuration file (c), so your
administrators will not panic when they notice it has changed.
41. At this point, you have created an RPM from scratch for LBreakout2, and have
successfully revised it to fix a minor packaging error. Depending on how
thoroughly you have tested LBreakout2, you might have discovered one other
problem with your package -- due to a packaging mistake, your LBreakout2
game does not actually handle high score logging correctly, though you
probably will not notice this unless you play as multiple different users.
The basic mistake made here is this: when a program runs on Unix or Linux, it
normally runs as the user who executes it, which means it only has write access
to the files which that user can write. For high-score tracking to work correctly
for LBreakout2, its high-score file, /var/lib/games/lbreakout2.hscr,
must be writable by every user who runs the lbreakout2 binary.
To accomplish this, two changes are necessary:
• The /var/lib/games/lbreakout2.hscr file should have permissions of
rw-rw-r-- and be owned by the games user and games group
• The /usr/bin/lbreakout2 file should have permissions of r-xr-sr-x and
owned by the root user and the games group
To make these changes, edit your spec file and modify the %files section to
the following:
%files
%defattr(-, root, root)
%doc AUTHORS COPYING ChangeLog NEWS README TODO html
%{_bindir}/lbreakout2server
• List each binary separately, since they need different
permissions.
%attr(2555,root,games) %{_bindir}/lbreakout2
• Make /usr/bin/lbreakout2 belong to the games group and SGID.
%{_datadir}/games/%{name}
%defattr(0664,games,games)
• Make the /var/lib/games/lbreakout2.hscr file group-writable and
owned by the games group.
%config %{_localstatedir}/lib/games/lbreakout2.hscr
Also, modify the Release token in the Header stanza to:
Release: 3
Finally, document your changes in the %changelog with a new entry similar to
the following:
* Tue Apr 02 2005 John Doe <student@gurulabs.com> 2.4.1-3
- Make SGID games and fix ownership and perms of
12-74high-scores file so that high scores work
42. Once you have made these three changes to revise your package, save the
spec file and then try once again to compile the software, install it to a virtual
root directory, and package it:
$ rpmbuild -ba lbreakout2.spec
...Output Omitted...
Wrote: /home/guru/rpmbuild/SRPMS/lbreakout2-2.4.1-3.src.rpm
Wrote: /home/guru/rpmbuild/RPMS/i386/lbreakout2-2.4.1-3.i386.rpm
...Output Omitted...
$
43. Now that you’ve built this revised package, uninstall the existing package and
install the new package:
$ su -c "rpm -e lbreakout2"
Password:
$ su -c "rpm -Uvh ../RPMS/i386/lbreakout2-2.4.1-3.i386.rpm"
Password:
Preparing...
########################## [100%]
1:lbreakout2
########################## [100%]
$
44. Notice the new permissions on the files installed by your revised package:
$ ls -l /usr/bin/lbreakout2* /var/lib/games/lbreakout2.hscr
-r-xr-sr-x
1 root
games
279698 Apr 29 12:58 /usr/bin/lbreakout2
-rwxr-xr-x
1 root
root
49665 Apr 29 12:58 /usr/bin/lbreakout2server
-rw-rw-r--
1 games
games
227 Apr 29 12:58 /var/lib/games/lbreakout2.hscr
$
Congratulations! At this point you have a high-quality, usable RPM for the
LBreakout2 application which you can give to your users....
45. There is one additional customization which you can make to your LBreakout2
RPM which might be useful to some of your users. RPM supports “sub
12-75•
•
•
•
packages” -- the creation of multiple binary RPMs from a single source RPM
file. Look at the binaries installed by your current lbreakout2 RPM:
$ rpm -ql lbreakout2 | grep bin
/usr/bin/lbreakout2
/usr/bin/lbreakout2server
$
Also, examine the number and size of the graphics and sound files installed by
LBreakout2:
$ rpm -ql lbreakout2 | grep "/usr/share/games" | wc -l
205
$ du -sh /usr/share/games/lbreakout2
3.4M
/usr/share/games/lbreakout2
$
The /usr/bin/lbreakout2 binary is the stand-alone application users run
to play LBreakout2. In addition, however, LBreakout2 also provides the
/usr/bin/lbreakout2server binary. This is a network daemon which can
be run on a server. Once started on a server, clients can run
/usr/bin/lbreakout2 on their systems, connect to this server daemon,
and start a network game of LBreakout2. The directory
/usr/share/games/lbreakout2 contains 205 files consuming about 3.4
megabytes of space for artwork required by the client, but not by the server.
For convenience, you might choose to package LBreakout2 in four files:
lbreakout2, which provides the client binary
lbreakout2-server, which provides the server binary
lbreakout2-graphics, which provides the graphics and sound files needed
by the client and optionally useful on the server
lbreakout2-doc, which provides the documentation files
Splitting LBreakout2 in this fashion will provide your users more flexibility -- they
can install just the parts of LBreakout2 they need, on just the machines on
which they need them.
46. To split LBreakout2 into sub packages, edit the spec file one final time. Sub
packages are made simply by adding additional %package and
%description stanzas to the Header section, then adding additional %files
stanzas which indicate which files get put in which sub packages. First, add a
12-76line to the current %description stanza, indicating that the lbreakout2
package supplies the LBreakout2 client, like the following:
This package supplies only the lbreakout2 client, suitable
for use in single-player games.
47. After that %description stanza, add additional %package and
%description stanzas for the new sub packages:
%package server
Summary: lbreakout2 network server
Group: Amusements/Games
• The “main” %description and %package information applies to
the “base” package, in this case lbreakout2
• Create a new sub package, lbreakout2-server
%description server
This package supplies the lbreakout2server daemon, useful for creating
multi-player LBreakout2 servers
%package graphics
Summary: lbreakout2 graphics, sound, and level files
Group: Amusements/Games
• Create a new sub package, lbreakout2-graphics
%description graphics
This package supplies LBreakout2 graphics, sound, and level files. This package must be installed on
client systems, and can be installed on server systems if desired.
%package doc
Summary: lbreakout2 documentation
Group: Amusements/Games
• Create a new sub package, lbreakout2-doc
%description doc
This package supplies documentation of LBreakout2.
48. Next, split the %files section up into individual sections for each sub
package. When you finish, your %files section should look something like:
%files
%attr(2555,root,games) %{_bindir}/lbreakout2
%defattr(0664,games,games)
• Files to put in the lbreakout2 package
12-77%config %{_localstatedir}/lib/games/lbreakout2.hscr
%files server
%defattr(-, root, root)
%{_bindir}/lbreakout2server • Files to put in the lbreakout2-server package
%files graphics
%defattr(-, root, root)
%{_datadir}/games/%{name} • Files to put in the lbreakout2-graphics package
%files doc
%defattr(-, root, root)
%doc AUTHORS COPYING ChangeLog NEWS README TODO html • Files to put in the lbreakout2-doc package
49. Now, add an entry to the Changelog documenting your latest change, similar to
the following:
* Tue Apr 02 2005 John Doe <student@gurulabs.com> 2.4.1-4
- Split into multiple packages for user convenience
50. In the Header stanza, increase the Release field one more time:
Release: 4
51. One additional change is required in the Header stanza. The
/usr/bin/lbreakout2 binary will not run without the graphics, sound, and
level files installed, so the lbreakout2 package needs to require the lbreakout2-
graphics package. Change the Requires field in the Header to require the
lbreakout2-graphics package:
Requires: /sbin/ldconfig lbreakout2-graphics
• The graphics, art, and music files could just be put in the
lbreakout2 package, but then they could not be installed on the
server easily without also unnecessarily installing the client....
52. Once you have made these changes to revise your package, save the spec file
and then try once again to compile the software, install it to a virtual root
directory, and package it:
$ rpmbuild -ba lbreakout2.spec
...Output Omitted...
Wrote: /export/home/rpmtestuser/rpmbuild/SRPMS/lbreakout2-2.4.1-4.src.rpm
12-78Wrote: /export/home/rpmtestuser/rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm
Wrote: /export/home/rpmtestuser/rpmbuild/RPMS/i386/lbreakout2-server-2.4.1-4.i386.rpm
Wrote: /export/home/rpmtestuser/rpmbuild/RPMS/i386/lbreakout2-graphics-2.4.1-4.i386.rpm
Wrote: /export/home/rpmtestuser/rpmbuild/RPMS/i386/lbreakout2-doc-2.4.1-4.i386.rpm
...Output Omitted...
$
53. Congratulations! You’ve now packaged LBreakout2 from scratch, creating four
sub packages from one source package.
12-79Task 4
•
•
Create a GPG key pair.
Sign and verify your LBreakout2 RPMs.
This lab explores the functionality built into the RPM command for signing
packages, ensuring package authenticity and integrity.
1. In a previous lab task, you created an RPM for the LBreakout2 application. RPM
provides a variety of built-in integrity and authenticity signatures which can be
checked on RPM packages. First, check the existing signatures of your
lbreakout2-2.4.1-4 RPM file:
RHEL/FC $ rpmsign -K ~/rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm
SLES/SL $ rpmsign -K ~/rpmbuild/RPMS/i586/lbreakout2-2.4.1-4.i586.rpm
rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm: sha1 md5 OK • On RPM 4.1 and later, you should see both SHA-1 digests and
MD5 checksums. On RPM 4.0 and earlier, you should only see
$
MD5 checksums. Both MD5 and SHA-1 are used to provide
Here, you see that the SHA-1 and MD5 signatures of this package are correct.
digital signatures of the package.
These are both file integrity checks, assuring you that the contents of the
package have not been modified.
2. RPM also provides the capability to digitally sign packages using GPG or PGP.
GPG / PGP signatures are useful to the users who install your software because
these types of signatures allow both the integrity of the package to be verified
(much like MD5 and SHA-1), and also the authenticity of the package to be
verified -- if you sign your packages with GPG, your users can be guaranteed
that the software they install comes from you, and not from someone creating
Trojan Horses which appear to come from you.
• The output below is from GnuPG 1.2. Older releases of GnuPG,
To utilize this GPG functionality, you must first create GPG keys which will be
such as GnuPG 1.0, will produce different output, and will
used to sign your packages. To create keys, first run the gpg command to
actually exit immediately after creating initial configuration files
create the GPG configuration files in your home directory:
RHEL/FC $ mkdir ~/.gnupg; chmod 700 ~/.gnupg
$ gpg
gpg: /home/guru/.gnupg: directory created
gpg: new configuration file `/home/guru/.gnupg/gpg.conf' created
gpg: keyblock resource `/home/guru/.gnupg/secring.gpg': file open error
gpg: keyring `/home/guru/.gnupg/pubring.gpg' created
12-80gpg: Go ahead and type your message ...
CTRL-C
gpg: some signal caught ... exiting
• Press CTRL-C to exit out of gpg. You will not need to do this on
older versions of gpg.
$
3. Once the GPG configuration files have been created, generate GPG keys:
$ gpg --gen-key
gpg (GnuPG) 1.2.6; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
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.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct (y/n)? y
• Output seen here will vary slightly with GnuPG version. Select
the default on your version of GnuPG.
• Select 1 here.
• 1024 bits is fine here, or 2048 bits if you’re more paranoid.
• 0 is fine here. In production use, people typically expire keys on a
periodic basis, however.
• If you haven’t made any mistakes, say y here. If you have made
mistakes, say n and correct them.
12-81You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: RPM Test
Email address: guru@gurulabs.com
Comment: RPM Package Builder
You selected this USER-ID:
"RPM Test (RPM Package Builder) <guru@gurulabs.com>" • Enter your first and last name here.
• Enter your email address.
• If you want, enter a descriptive comment here.
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o • If you haven’t made any mistakes, say o here. If you have made
mistakes, correct them.
• Enter a password here. This password is all that prevents
someone from stealing your key file and impersonating you, so
guard it carefully.
You need a Passphrase to protect your secret key.
Enter passphrase:password
Repeat passphrase:password
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.
++++++++++.+++++++++++++++++++++++++++++++++++...++++++++++
++++++++++++++++++++..++++++++++++++++++++++++++++++.+++++.
...++++++++++....++++++++++>++++++++++..>+++++.<.+++++.....
.>+++++.....<+++++.>.+++++......<+++++...............+++++
We need to generate a lot of random bytes. It is a good idea • Entropy (sources of “random” data) are needed by GnuPG. It
uses seemingly random events like keyboard key presses or
to perform some other action (type on the keyboard, move the
mouse movement as sources of entropy. If enough entropy is
mouse, utilize the disks) during the prime generation; this
not available, it will actually prompt you to generate more
gives the random number generator a better chance to gain
entropy by carrying out activities such as moving the mouse,
enough entropy.
typing on the keyboard, or generating hard disk traffic.
+++++++++++++++++++++++++.++++++++++++++++++++.++++++++++++
+++.+++++++++++++++++++++++++++++++++++++++++++++.+++++.+++
+++++++++++++++++>+++++.......+++++^^^
gpg: /home/guru/.gnupg/trustdb.gpg: trustdb created
• The output seen here will vary slightly with GnuPG version.
public and secret key created and signed.
key marked as ultimately trusted.
12-82pub
sub
1024D/87786C00 2003-04-29 RPM Test (RPM Package Builder) <guru@gurulabs.com>
Key fingerprint = 24ED F0C7 2148 E88C 51B8 1CA2 8D2A FB9A 8778 6C00
1024g/9B24A1DC 2003-04-29
$
4. At this point, you have generated public and private GPG keys. To verify that
they were created correctly, you can view them:
$ gpg --list-keys
/home/guru/.gnupg/pubring.gpg
--------------------------
pub 1024D/87786C00 2003-04-29 RPM Test (RPM Package Builder) <guru@gurulabs.com>
sub 1024g/9B24A1DC 2003-04-29
$
5. Now that you have created a GPG key, you must configure RPM to allow you to
use it. First, configure RPM to use GPG:
$ echo "%_signature gpg" >> ~/.rpmmacros
$ echo "%_gpg_path $HOME/.gnupg" >> ~/.rpmmacros
$
Also, configure RPM to locate the GPG key you just created:
$ echo "%_gpg_name guru@gurulabs.com" >> ~/.rpmmacros
• Make sure you use the same email address here you used in
step 3 when you generated your GPG keys.
$
6. Once RPM is configured to support GPG, use it to sign a package with your
new GPG private key:
RHEL/FC $ rpmsign --addsign ~/rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm
SLES/SL $ rpmsign --addsign ~/rpmbuild/RPMS/i586/lbreakout2-2.4.1-4.i586.rpm
Enter pass phrase: password
• Enter your GPG password that you created in step 3.
Pass phrase is good.
rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm:
$
12-837. Next, examine the signatures of your freshly signed package. If you are using
RPM 4.0 or older, you will see:
RHEL/FC $ rpmsign -K ~/rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm
SLES/SL $ rpmsign -K ~/rpmbuild/RPMS/i586/lbreakout2-2.4.1-4.i586.rpm
rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm: md5 gpg OK
$
This indicates that the package has a correct MD5 signature, is signed using
• When you generated your public and private key pair in step 3,
GPG automatically added your public key to your personal public
GPG, and that the GPG signature of the package can be decrypted using a GPG
keyring. When you ran rpmsign -K, rpmsign used this
public key on your GPG keyring. Congratulations! You have signed a package,
public
key to decrypt the GPG signature within the package file.
and verified that it is correctly signed. You may skip the rest of the steps in this
lab; they are only necessary for users running RPM 4.1 and newer releases.
8. If you are using RPM 4.1 and newer releases, when you examine the signatures
of your package, you will instead see:
RHEL/FC $ rpmsign -K ~/rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm
SLES/SL $ rpmsign -K ~/rpmbuild/RPMS/i586/lbreakout2-2.4.1-4.i586.rpm
rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm: (SHA1) DSA
sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#87786c00)
$
Although your package is signed with your correct GPG key, it still shows up as
NOT OK with RPM 4.1 and newer releases. This is because RPM 4.1 and newer
releases use their own separate GPG keyring, rather than reading the keyring of
the user running the RPM command. RPM is trying to verify the signature on
your package using the RPM GPG keyring, and RPM does not yet have your
public key installed on its keyring, so it cannot verify the signature.
9. To correct this, you will first need to export your public key in a format RPM can
understand. To see your public key, use the command:
$ gpg --export --armor
• Fortunately, this output makes more sense to the GPG software
than it does to you!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.1 (GNU/Linux)
mQGiBD6u2hQRBAC1wEn+cJvjz8P94ogeE/PCwX4mUBbY4QvKiklrXgr+bpD
d9OmaM+JqbnqyBIq9KfsxVLK651VFB7jBqKwzjBVQER+xsDJW79vKE2mDv0
zNRJuxG2ull8iwwlyub3H9Jky+VXJ4upA3CxhwDRMjZ1PShhJzPSX0paHwC
12-84x29FQOTKZ6tfgDopoDbq4bUD/1rwocepHES4EOrzz4TVKXAtwASP+Z18OkI
RPmRQ2nkawnRMhIl+taTcbjBJapm1YiKAyqkGwiWtBMTQER9Ox+Uz1p4SmQ
VO0SAGpi+2jjmD79ViRAqdAd+JcgLSI8c9TEZo3D3UFWZI/8yv5PHJMgGQo
nmbFA/0XeJH5aluTFgFnJCP2JMFvMDG2SwiGmwOyDiAWZ7/RTulOt7Y8fMk
OgLlN9wsAZ6JNCmkUP/jiQFYpyMULI1Soca2h+PKYUenEjmwo1LRWUGkdLa
3t8PA92mAhcJynRG+JEEYL5x3NHDVSIzBxz3mTedWj7YQLkkCrRBVGVzdCB
YWdlIChSUE0gUGFja2FnZSBCdWlsZGVyKSA8a2Fib29tQHdpbnN1Y2tzLmd
YWJzLmNvbT6IWQQTEQIAGQUCPq7aFAQLBwMCAxUCAwMWAgECHgECF4AACgk
mod4bABO7QCfWJoP+QFploVay2FPAskbrle4DjgAnAhdbdFJ27Wbolk1xob
IPd/uQENBD6u2hUQBACOgzjL5Wz0Tg/avYSfiswAC5wwKGXTxG9RZPF3cdB
F/k2KsFpoDg/5p9nzSM/h3MjH+1Lr/ZOJgMr/Bz8TunnJg+I+vx00vh0Tw2
tV3B+0jx+ots3A+Opmn77eUGSm+lOv1PQYfQ9kwRsE7+BO9ylgHsrbx9myA
BQP/aJl2yC5H9MTyiK8PvVzr2hrAdykZYGCmJzcmSJ1guiLEgQ7qG0i3Ycm
z+YxIvon42w6EqaoDBp9RHkK2KQpuvNgQfUSMUcr5tIUf3EqDAy37wgdFPx
eh4yem1zigQ12M/Vk5BkQGBs/8Ol+7VfZ1pvgtvZiXtKSoqIRgQYEQIABgU
FQAKCRCNKvuah3hsAGH6AJ9jgyNiBSEf9a5LcetnZqQez/a9dwCfeNEmgUo
/ZxE3l/sTe5Nb+8=
=OnkZ
-----END PGP PUBLIC KEY BLOCK-----
$
10. Now, save your GPG public key to a file:
$ gpg --export --armor > /tmp/gpg-public-key.asc
$
11. Next, import your public key into RPM’s GPG keyring:
$ su -c "rpmsign --import /tmp/gpg-public-key.asc"
Password:
$
12. Once your public key is imported into the RPM GPG keyring, examine the
signed LBreakout2 package signatures again:
$ rpmsign -K ~/rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm
rpmbuild/RPMS/i386/lbreakout2-2.4.1-4.i386.rpm: (sha1) dsa sha1 md5 gpg OK
$
12-8513. This time, your GPG signature verified correctly because RPM now has your
GPG public key installed correctly. You can also give your GPG public key to
your users, and they can import it into RPM using the same process you did in
step 11. Once they have imported your public key, they can verify the
authenticity and integrity of any RPMs you create for them!
12-86