Objectives
To prepare an rpmbuild directory structure to contain RPMs for different architectures
To generate an RPM specification (spec) file that defines the structure of the generated RPM package and the files and embedded scripts to be included in it
To build an RPM package that contains user generated scripts and configuration files
Introduction
I have used RPM-based package managers to install software on Red Hat, CentOS, and Fedora since I started using Linux over 20 years ago. From the RPM program itself, to YUM, and then DNF, which is a close descendant of YUM, I have used these tools to install and update packages on my Linux hosts. But that was all about installing packages. The YUM and DNF tools are wrappers around the RPM utility and provide additional functionality such as the ability to find and install package dependencies.
Over the years I have created a number of Bash scripts, some of which have separate configuration files, that I like to install on most of my new computers and virtual machines. It finally reached the point that it took a great deal of time to install all of these packages. I decided to automate that process by creating an RPM package that I could copy to the target hosts and install all of these files in their proper locations. Although the RPM tool was formerly used to build RPM packages, that function of RPM was removed and moved a new tool; RPMBUILD was created to build new RPMs.
When I started this project, I found very little information about creating RPM packages but managed to find a book, Maximum RPM, that enabled me to figure it out. That hard-copy book is now somewhat out of date as is the vast majority of information I have found. It is also out of print, and used copies go for hundreds of dollars. The online version of Maximum RPM1 is available at no charge and is apparently being kept up to date. The RPM web site also has links to other web sites that have a lot of documentation about RPM. What other information there is tends to be very brief and apparently assumes that you already have a good deal of knowledge about the process.
Another good resource for the RPM tools that I have found is at RPM.org. This web page lists most of the available online documentation for RPM. It is mostly link to other web sites and information about RPM itself. I especially like the Fedora RPM Guide.
All of the documents I found assumes that the code needs to be compiled from sources as in a development environment. I am not a developer, I am a SysAdmin, and we SysAdmins have different needs because we don’t – well shouldn’t – be compiling code to use for administrative tasks; we should be using shell scripts. So we have no source code in the sense that it is something that needs to be compiled into binary executables. What we have is source code that is also the executable.
For the most part, the experiments in this chapter should be performed as the non-root user, student. RPMs should never be built by root but only by non-privileged users.
Preparation
There are some things we need to do in order to prepare for building RPMs. This includes installing the rpmbuild software, downloading the tarball that contains the files we will be including in the RPM as well as the spec file used to build the RPM, and creating the build directory structure.
Experiment 17-1
This tarball includes all of the files and BASH scripts that will be installed by the final RPM. There is also a complete spec file which you can use to build the RPM. We will go into detail about each section of the spec file. We installed the RPM created from this tarball in Chapter 12 of Volume 1.
Change ownership of these files and directories to student.student.
The mymotd script creates a “Message Of The Day” data stream that is sent to STDOUT. The create_motd script runs the mymotd scripts and redirects the output to the /etc/motd file. This file is used to display a daily message to users who login remotely using SSH.
The die script is my own script that wraps the kill command in a bit of code that can find running programs that match a specified string and kill them. It uses kill -9 to ensure that they cannot ignore the kill message. The sysdata script can spew tens of thousands of lines of data about your computer hardware, the installed version of Linux, all installed packages, and the metadata of your hard drives. I use it to document the state of a host at a point in time. I can later use that information for reference. I used to do this to maintain a record of hosts that I installed for customers.
Most of the files and directories in this tree will be installed on Fedora systems by the RPM you create during this project. Some are used to build the RPM.
Now let’s create the build directory structure. The rpmbuild command requires a very specific directory structure. You must create this directory structure yourself because no automated way is provided to do it.
Experiment 17-2
Note that the RPM build process will create the rest of the required directories.
We did not create architecture-specific directories such as the ~/rpmbuild/RPMS/X86_64 directory because our RPM is not architecture specific. We have shell scripts that are not specific to any CPU architecture. In reality we won’t be using the SRPMS directory, either, which would contain source files for the compiler.
Examining the spec file
Each spec file has a number of sections, some of which may be ignored or omitted, depending upon the specific circumstances of the RPM build. This particular spec file is not an example of a minimal file required to work, but it is a good example of a moderately complex spec file that packages files that do not need to be compiled. If a compile were required, it would be performed in the %build section which is omitted from this spec file because it is not required.
As you proceed through this section, change the provided spec file as suggested to be specific for you.
Preamble
Comment lines are ignored by the rpmbuild program. I always like to add a comment to this section that contains the exact syntax of the rpmbuild command required to create the package. The Summary tag is a short description of the package. The Name, Version, and Release tags are used to create the name of the RPM file, as in utils-1.00-1.rpm. Incrementing the release and version numbers enables creating RPMs that can be used to update older ones.
The License tag defines the license under which the package is released. I always use a variation of the GPL. Specifying the license is important in order to prevent confusion about the fact that the software contained in the package is open source. This is also why I included the license and GPL statement in the files that will be installed.
The URL is usually the web page of the project or project owner. In this case, it is my personal web page. If you have a web page, you can change this to that URL.
The Group tag is interesting and is usually used for GUI applications. The value of the Group tag determines which group of icons in the Applications menu will contain the icon for the executable in this package. Used in conjunction with the Icon tag, which we are not using here, the Group tag allows adding the icon and the required information to launch a program into the Applications menu structure.
The Packager tag is used to specify the person or organization responsible for maintaining and creating the package.
The Requires statements define the dependencies for this RPM. Each is a package name. If one of the specified packages is not present, the dnf installation utility will try to locate it in one of the defined repositories defined in /etc/yum.repos.d and install it if it exists. If dnf cannot find one or more of the required packages, it will trow an error indicating which packages are missing and terminate.
The BuildRoot line specifies the top-level directory in which the rpmbuild tool will find the spec file and in which it will create temporary directories while it builds the package. The finished package will be stored in the noarch subdirectory that we specified earlier. The comment showing the command syntax used to build this package includes the option --target noarch which defines the target architecture. Because these are Bash scripts, they are not associated with a specific CPU architecture. If this option were omitted, the build would be targeted to the architecture of the CPU on which the build is being performed.
The rpmbuild program can target many different architectures and using the --target option allows us to build architecture specific packages on a host with a different architecture from the one on which the build is performed. So I could build a package intended for use on an i686 architecture on an x86_64 host, and vice versa.
Change the packager name to yours and the URL to your own web site, if you have one.
%description
%prep
The %prep section is a script that is the first one executed during the build process. This script is not executed during the installation of the package.
This script is just a Bash shell script. It prepares the build directory, creating directories used for the build as required and copying the appropriate files into their respective directories. This would include the sources required for a complete compile as part of the build.
The $RPM_BUILD_ROOT directory represents the root directory of an installed system. The directories created in the $RPM_BUILD_ROOT directory are fully qualified paths such as /user/local/share/utils, /usr/local/bin and so on, in a live filesystem.
Note that the exit statement at the end of this section is required.
%files
%pre
This section is empty in our lab project's spec file. This would be the place to put any scripts that are required to run during installation of the RPM but prior to the installation of the files.
%post
The comments included in this script should make its purpose clear.
%postun
This section contains a script that would be run after the RPM package is uninstalled. Using rpm or dnf to remove a package removes all of the files listed in the %files section, but it does not remove files or links created by the %post section, so we need to handle that in this section.
%clean
%changelog
Replace the data in the header line with your own name and email address.
Building the RPM
The spec file must be in the SPECS directory of the rpmbuild tree. I find it easiest to create a link to the actual spec file in that directory so that it can be edited in the development directory and there is no need to copy it to the SPEC directory.
Experiment 17-3
Testing the RPM
As root, install the RPM to verify that it installs correctly and that the files are installed in the correct directories. The exact name of the RPM will depend upon the values you used for the tags in the Preamble section, but if you used the ones in the sample, the RPM name will be as shown in the sample command below.
Experiment 17-4
The -i option specifies an install. A -u would indicate performing an upgrade of a newer package over an older one. The -v means verbose and -h means we want to display the progress hash marks.
Check /usr/local/bin to ensure that the new files are there. You should also verify that the create_motd link in /etc/cron.daily has been created.
Experimenting
Let’s do some experimenting.
Experiment 17-5
Build the package and attempt to install it. What message is displayed?
We used the rpm command to install and delete the utils package. Try installing the package with DNF. You must be in the same directory as the package or specify the full path to the package for this to work.
Rebuilding a corrupted RPM database
I have occasionally encountered errors that indicate the RPM database is corrupted when upgrading, updating, or installing RPMs. This can occur for various reasons, but I have found that I can cause it by breaking out of a running task such as an update or installation.
The RPM database can be easily rebuilt.
Experiment 17-6
Rerun the command without the -vv option.
Chapter summary
There are many tags and a couple sections that we did not cover in this look at the basics of creating an RPM package. Building RPM packages is not difficult, one just needs the right information. I hope this chapter helps you because it took me months to figure things out on my own.
We did not cover building from source code but, if you are a developer, that should be a simple step from this point.
Creating RPM packages is another good way to be a lazy SysAdmin and save time and effort. It provides an easy method for distributing and installing the scripts and other files that we as SysAdmins need to install on many hosts.
Exercises
- 1.
Try building the utils package using X86_64 as the target architecture. Remove the existing version of the package, install the X86_64 version, and test the programs. Does this cause a problem? Why? Remove this version.
- 2.
Create a short script of your own and include it in the RPM. Increment the release number and build the revised RPM.
- 3.
Install the original noarch RPM again. Then use DNF to upgrade the RPM to the new version.
- 4.
What happens if you make a change to the RPM spec file and rebuild the RPM without updating the release number? Is this also true for the version number?