RedHat Linux
rpm Creation and Standards
Version 0.2
Table of Contents
1. Introduction.................................................................................................................................. 4
2. Understanding the Package file................................................................................................... 4
3. Types of RPM packages............................................................................................................... 4
3.1 Binary rpms............................................................................................................................. 5
3.2 Source rpms............................................................................................................................ 5
4. The RPM Database....................................................................................................................... 5
5. Installing and Upgrading rpms..................................................................................................... 5
5.1 Upgrading/Installing................................................................................................................. 6
5.2 Removing software.................................................................................................................. 6
6. Package Dependencies................................................................................................................ 7
7. Building rpms............................................................................................................................... 7
7.1 Setting up the directory structure.............................................................................................. 7
7.2 Creating a new rpm spec file.................................................................................................... 8
7.2.1 Global variables............................................................................................................... 8
7.2.2 The Introduction Section.................................................................................................. 8
7.2.3 Dependencies................................................................................................................ 10
7.2.4 The prep section............................................................................................................ 10
7.2.5 The Build Section........................................................................................................... 11
7.2.6 The Install section........................................................................................................... 11
7.2.7 The Clean section........................................................................................................... 11
7.2.8 The Files Section............................................................................................................ 11
7.2.9 Pre and Post Install/Uninstall scripts................................................................................ 13
7.2.10 The change log............................................................................................................... 14
7.3 The Source repository........................................................................................................... 14
7.4 Notes regarding packaging binary software............................................................................ 15
7.5 Building the rpm.................................................................................................................... 15
7.6 New rpm Version or Release................................................................................................. 16
7.7 Signing RPMs....................................................................................................................... 17
8. Implementing RPMs................................................................................................................... 17
8.1 Phase 1 - User testing............................................................................................................ 17
8.2 Phase 2 - Satellite Administrator ratification............................................................................ 17
8.3 Phase 3 – Dev/Test Deployment testing.................................................................................. 18
8.4 Phase 4 – Pre Production Deployment testing........................................................................ 19
8.5 Phase 5 – Production Implementation.................................................................................... 19
9. Verifying 3rd Party RPMs............................................................................................................. 19
10. RPM Best practices................................................................................................................. 20
11. RPM SPEC File Standards Summary........................................................................................ 20
12. References.............................................................................................................................. 21
13. Useful links............................................................................................................................... 21
14. Other documents..................................................................................................................... 22
15. Document Template Revision History..................................................................................... 22
16. Appendix A: rpm database query options............................................................................... 23
17. Appendix B: rpm Install/Upgrade command options.............................................................. 24
18. Appendix C: rpm erase command options.............................................................................. 25
19. Appendix D: Example spec file................................................................................................ 26
20. Appendix E: Groups................................................................................................................. 27
Originally developed by Red Hat for its own linux distribution the RPM package (Originally standing for RedHat Package Manager) format has become the adopted software packaging standard for Linux distributions. This document details the procedures, processes and standards for creating and maintaining RPMs for deployment in the Lloyds Banking Group Linux estate.
RPM provides a mechanism for installing, upgrading and removing packages. Typically each package is an application and all the necessary files which are associated with that application. The RPM package can be split into four sections.
· Identification Area – This are marks the file as an RPM package and holds which version of RPM it was created with.
· Signature – The RPM signature helps to verify the integrity of the package. It works by performing a mathematical function on the header and payload sections of the package. In our case PGP encryption is used to sign the RPM
· Header – The header contains information such as version numbers and package summaries.
· Payload – This section contains the actual files used in the package. The data in this section is compressed in the gzip format to save space.
There are two main types of RPM package – Binary and Source.
1
2
3
A binary RPM contains files which have been pre compiled for a specific architecture. Generally binary RPMs contain a complete application. Usually they will depend on a number of system libraries which have also been provided by binary rpms.
In addition to binary rpms that hold applications or libraries which have been compiled for a specific architecture, RPM also supports the concept of a platform independent package. The “noarch” packages provide libraries or applications which are not dependent on the underlying architecture. Applications written in interpreted languages e.g. perl or python are generally not dependent on a particular architecture.
A source rpm contains all the files/commands necessary to recreate the binary rpm. By convention source rpms have a file name ending .src.rpm. This provides a package which can be installed on any architecture. However each target system will require the appropriate software to compile the source code e.g. GNU C++ Compiler etc.
From a security standpoint it is generally bad practice to install compilers etc on any system which does not specifically require it. As such the remainder of this document will concentrate on Binary rpms.
The RPM database holds information about all the RPMs which are installed on the system. This database can be used to query what is installed to help determine if the system is correctly configured with the correct software levels. The RPM database is stored in the directory /var/lib/rpm.
Of the files in this directory the only file which is essential is the “Packages” file. The Packages file contains the header tag information for each package. All the remaining files can be re created using the command “rpm --rebuild –bb”. The other files in this directory such as Name, Providename and group exist to speed access to particular types of information.
The RPM database can be queried using the command “rpm –q<option>”. The most common option you will probably use will be “rpm –qa” which lists all installed packages. For a full list of the RPM Query options see Appendix A.
The rpm command provides 3 main operations for installing and upgrading packages
· Upgrade - An upgrade operation will upgrade a current package to a later level, removing all previous versions of the same package, or install a new package.
· Freshen – A freshen operation means to install a new version of a package only if you have already installed another version.
· Install – An install operation installs a package for the first time
The following subsections provide some more details about using the rpm command. However, it should be noted that the rpm command should only be used when testing rpms, or where issues are experienced during installation/de installation. The standard method to install software on the clients is to use the yum command to pull packages from the Satellite infrastructure. Since yum also maintains a record of what it thinks is installed, yum should also be used to remove software from a client. Failure to do so could result in issues with future software installations due to package pre requisite issues.
4
5
The “rpm –U” command will install or upgrade an rpm package.
rpm –U nmon.13g-2.x86_64.rpm
Assuming that the package installs/upgrades successfully, then no output will be displayed and you will be returned to the prompt. To provide more information during the process, a –v or –vv option can be added to the command.
The upgrade procedure will remove the currently installed version and then install the new version. If you are trying to re install the same version, then the upgrade operation will fail. Adding a “--force” option to the command will ignore this version check error.
It is possible to check that an rpm will install/upgrade without actually performing the action by adding a “--test” option to the command. As with the original install/upgrade command, no output will be displayed if the check is successful.
If the already installed version of the rpm has an issue with its uninstall procedure, then you will be unable to Upgrade or erase the package. If the issue is with the pre or post uninstall scripts portion of the rpm, then it is possible to force the system to skip these sections by adding a “--noscripts” option to the command.
For more detailed information about the Upgrade/Install options of the rpm command see Appendix B.
The “rpm –e <package>” command is used to remove software from a system. The <package> name is not the full rpm package name, but can be as little as the software package name e.g. nmon, or as much as the software package plus the full release versions e.g. nmon-13g-2.
If the package has an issue with its uninstall procedure, then you will be unable to erase the package. If the issue is with the pre or post uninstall scripts portion of the rpm, then it is possible to force the system to skip these sections by adding a “--noscripts” option to the command.
For more detailed information on the erase options of the rpm command, see Appendix C.
A dependency occurs when one package depends on another. For example just about every package with an application will depend on the system C libraries, since these libraries provide common facilities that every program uses. The RPM database tracks dependency information so that it can stop the removal of packages on which other installed packages depend, or to inform the user of dependent packages upon installation.
In RPM terms, each package provides capabilities. A capability is a simple text string that the package claims it provides. In most a capability names a file or a package. So when creating a package you can list the capabilities that your package requires as well as those it provides.
You can list the capabilities provided by a package using the command “rpm –q --provides <package>”.
Although rpms can be created under any usercode, packages should never be built under the root usercode. If using the root usercode to build packages, an incorrect setting of the buildroot environment variable can result in corruption of the build system. For the remainder of this document it will be assumed that you will be using your own non root usercode to create rpms.
6
7
The RPM system expects 5 directories
Directory | Usage |
BUILD | The rpmbuild command builds software in this directory. |
RPMS | The rpmbuild command stores binary RPMs it creates in this directory. |
SOURCES | You should put the sources for the application in this directory. |
SPECS | You should place the spec file for each RPM you plan to make in this directory. |
SRPMS | The rpmbuild command places source RPMs in this directory. |
While these directories can be created anywhere, they should not be created in your home directory. The RPMS directory will hold the created rpm files, so if you are creating multiple, or large rpms, then the home file system could soon fill up. It is recommended that a separate file system is created to house the directories. The remainder of this document will assume that the file system /opt/rpmbuild has been created specifically for rpm builds.
Make a directory under /opt/rpmbuild for your usercode (the directory should be named after your usercode) and make the 5 directories above. In addition create a tmp directory. This directory will be used to hold the files which will be used when creating the rpms.
To use these directories you must create a file called “.rpmmacros” in your home directory. The file should contain the following 2 entries.
%_topdir /opt/rpmbuild/<usercode>
%_tmppath /opt/rpmbuild/<usercode>/ROOT
The spec file is a text file which defines all the actions the rpmbuild command should take to build your rpm, as well as all the actions necessary for the rpm command to install and remove the application. The following sub sections detail the spec file, and the standards to be followed when creating them.
This section only deals with the portions of the spec file which are required to build Binary rpms. For information on the sections required for Source rpms please refer to the Fedora Online documentation. A link for this can be found in the References section.
An example spec file can be found in Appendix D.
Available Macros
Various macros are defined for use within a spec file, these are defined in /usr/lib/rpm/macros, including those below. Where possible these should be used instead of hard-coded paths since this will make the resulting RPM more portable and much simpler to relocate to non-standard install locations if necessary.
%{_prefix} %{_sysconfdir}
%{_bindir} %{_sbindir}
%{_libdir} %{_mandir}
%{_infodir} %{_datadir}
For a full picture of the macros & variables available, along with the values assigned to them, use rpmbuild –showrc
At the top of the spec file we can declare global variables which can be used in the spec file.
At a minium the following should be declared so they can be re used within the introduction section
%global name <package name>
%global version <package version>
The introduction section contains information about the package. The following table shows which sections are required (and the format if necessary) to meet the Lloyds Banking Group standards
Summary: | A one line description of the package |
Name: | This is the string which defines the package name. Multiple words a permitted and should be separated by a dash. In our spec files we should use the %{name} global variable |
Version: | If packaging a vendors application, then this should be the 3rd party Vendors version number. In our spec files we should use the %{version} global variable |
Release: | Integer release number for this version. This should incremented by 1 for each new rpm created. If releasing a new Software Version (as detailed above), then this should be reset to 1 |
License: | This describes the license under which the package can be distributed. If packaging vendor software for installation in our estate, then this should be set to “Commercial”. |
Group: | This line is used to tell high level installation programs (such as Red Hat's gnorpm) where to place this particular program in its hierarchical structure. You can find the latest description in /usr/share/rpm*/GROUPS. If packaging vendor software for distribution, then this entry should be “Applications/System”. A list of available groups at the time of writing can be found in Appendix E. |
BuildRoot: | This is the pseudo root directory where the binary files to be package will be placed. Should be set to “%{_tmppath}/%{name}-%{version} “ |
Source: | |
%description | This is a multi-line field that should be used to give a comprehensive description of the package. This field begins on the line below %description and will continue until a recognised header is found. The description should be properly wrapped at 72 columns |
e.g. for the rpm package example-package.3.3.1-3.x86_64.rpm the introduction section would look like
%global name example-package
%global version 3.3.1
Name: %{name}
Version: %{version}
Release: 3
License: Commercial
Group: Applications/System
BuildRoot: %{_tmppath}/%{name}-%{version}
Source: Systems-Management/%{name}-%{version}.tgz
%description
This package deploys the example package
Dependencies are one of the most important parts of the RPM system. The RPM database tracks dependencies between packages to better allow you to manage your system. The RPM system ensures that dependencies are honoured when upgrading, installing or removing packages.
There are a number of dependency declarations which can be used in an RPM.
BuildRequires: Specifies requirements to build the package with rpmbuild
Requires: Specifies runtime requirements, needed at rpm install time
Provides: Specifies virtual capabilities provided by the package (which other packages can then depend on)
Conflicts: Specifies other packages which cannot coexist with this one
The syntax for these declarations is as follows
<Dependency>: <package/capability>
e.g.
Requires: bash
Multiple packages can be specified on the same line.
It is also possible to specify package versions and relationships e.g.
Requires: bash >= 2.0
Means that the package requires the bash package at a level of 2.0 or greater. The full range of comparisons are >, <, >=, <= and =.
The prep section is used to prepare the build area. It should be used to clear out any previous build files for the package and setup the system for building from the latest source. In this section we can use the %setup macro which will prepare the build area and extract the source files from the source archive file as defined by the “Source:” definition.
%prep
%setup
For more information on the %setup macro see the following link
The Build section is used to compile binaries if we are using actual source code. If the source code was provided with a “makefile”, then this section would be a simple make command.
%build
make
If creating an RPM from binary files, this section is omitted.
The install section is used to palace the code into the “ROOT” tree as it will be deployed by the RPM. If using source code with a makefile, then this section will likely contain “make install”.
If using binary files, this section should copy the files from the BUILD to the ROOT tree. You need to create the directory structure (from root) that your package requires within the RPM_BUILD_ROOT directory, and then copy the required files to those locations.
NB. as part of the build process the system will have changed into the “BUILD” directory.
%install
mkdir -p ${RPM_BUILD_ROOT}/usr/local/bin
cp -pr nmon ${RPM_BUILD_ROOT}/usr/local/bin/.
If we have a tar file and an installation script which will be used to install the example software, we want to deploy these files into a temporary location from where we can then run the install script. So we want these files to be placed into /var/tmp/example-package. So we need to create this directory structure in the pseudo root directory and place the files in the example-package directory. The actual directory structure will be /opt/rpmbuild/<usercode>/ROOT/example-package-root/var/tmp/example-package, but the RPM will deploy the files as if they were in /var/tmp/example-package.
The clean section is used to tidy up temporary files following a build e.g.
%clean
rm –fr %{RPM_BUILD_ROOT}
This will clean up the temporary installation “ROOT” directory ensuring the subsequent builds do not contain spurious files from previous builds.
The files section lists the files that will go into the Binary rpm, along with the defined attributes. The following is an example of a files section
%files
%defattr(755,root,root)
/usr/local/bin/example.sh
/usr/local/bin/example2.sh
%attr (750,root,sys) /usr/local/bin/example3.sh
%dir /usr/local/tmp
%config /usr/local/config/config_file.cfg
%config(noreplace) /usr/local/config/config_file2.cfg
%doc /usr/share/man/man1/example.1
The following table details the purpose of the special operators
%files | Defines the start of the files section |
%defattr | Defines the default attributes that will be applied to files extracted from the package in (mode, user, group) |
%attr | Defines specific files attributes for a file |
%dir | Designates a directory which is to be included in the package (not the contents of that directory). Specifying a directory without the %dir prefix will include the directory and all its contents in the package |
%config | Marks the file as a configuration file so that edits to config files won’t get lost during a subsequent upgrade. If a package is removed or upgraded and a configuration file has been changed it will be saved with a .rpmsave extension. |
%config(noreplace) | Slightly different from the standard %config in that, when an upgrade is applied, the replacement config file in the package is installed with the .rpmsave extension and the edited file is retained as the default name. |
%config(missingok) | Optional config files, do not need to exist, but will be removed on uninstall |
%ghost | ghost files are erased but never installed (e.g logfiles) |
%doc | Marks the file as documentation. The documents will be installed in /usr/doc/$NAME-$VERSION-$RELEASE |
The files section of the spec file must contain a %defattr specification. Failure to do so will mean that any local changes to the umask setting could alter the file permissions and cause installation failures.
If you are packaging files which are temporary and will be used by the post install scripts (see the section 7.2.4), then they should be place in a subdirectory of /var/tmp. These temporary files should be removed at the end of the post install script.
In most cases extracting files from the package and placing them into the file systems of the Linux server will not be enough to “install” the package. Similarly when uninstalling a package it may not be enough to simply remove the files. To this end the rpm can be include scripts to run before and after the install/uninstall of the files themselves.
The sections are started with an appropriate header definition and ended either by a subsequent header definition, or the end of the file. The headers for each section are
%pre | Pre installation script, also run on upgrade |
%post | Post installation script, also run on upgrade |
%preun | Runs before package removal, also when old version is removed during an upgrade |
%postun | Runs after package removal, also when old version is removed during an upgrade |
The sections themselves should be written in standard shell (sh) format and must be fully commented to explain what the code is doing.
When installing a package for the first time or removing a package, then it’s fairly easy to understand which scripts are run. However, this is not so simple for upgrades or downgrades e.g. when upgrading or downgrading a package the scripts are actually run in the following sequence
1. %pre of new package version
2. Install new files
3. %post of new package version
4. %preun of old package version
5. Delete any old files not overwritten by new version
6. %postun of old package version
Each of the scripts may want to perform different tasks depending on whether it is an install/remove or upgrade/downgrade, and this can be achieved with the single argument which is passed to each script. This argument is how many versions of the package will be installed after that action completes (refer to the sequence above!).
For example:
%pre
if [ $1 >= 2 ]
then
# This is an upgrade or downgrade
else
# This an install
useradd httpd
fi
%postun
if [ $1 = 0 ]
then
# This is an uninstall
userdel httpd
else
# This is an upgrade or downgrade
service httpd condrestart >/dev/null 2>&1
fi
When building packages we need to ensure that upgrades or downgrades don’t do anything which could break the new package e.g. a %postun script which simply removes a usercode will break the system in the event of an upgrade i.e. as the %postun section of the previous version is run it would remove the usercode required by the package. So utilizing the $1 arguments is vital.
The end of the spec file must contain a change log section. Each time an rpm is updated, an entry should be added to the changelog section specifying what changes have been made. The change log section is initiated by the header %changelog.
Each change log entry should consist of 2 or more lines. The first line should be in the following format
* <Date> <Name> <e-mail address>
Where <Date> is the date in the format returned by the command date +"%a %b %d %Y"
<Name> is the full name of the person making the change
<e-mail address> is the external e-mail address of the person making the change
The following lines are then free form text, but should be properly wrapped and organised in a coherent manner.
In a new spec file, an Initial Implementation comment should be added to the change log section e.g.
%changelog
* Wed Feb 02 2011 Euan Caldwell <euan.caldwell@lloydsbanking.com>
- Initial Implementation
In section 7.2.3 (Prep) we use the %setup macro to create the build area. If we are creating a binary RPM, we probably don’t have a source repository, so we need to create one. This is simply a gzip’d, tar archive of the files (and any required directory structure) that are required.
The archive should be created as follows
Change to the directory which contains the files for the package.
Create the source archive
tar –czvf /opt/rpmbuild/<usercode>/SOURCES/<package>-<release>.tgz *
The <package>-<release>.tgz file name should match the last node of the Source tag in the spec file.
Now when we run the rpmbuild command this archive will be extracted into the BUILD directory for the package.
When re packaging 3rd party binary software for automated installation, it is generally considered bad practice to create RPMs which contain installers which are then run as part of the post script. In this case the deployed files are not tracked by RPM, losing most of the benefits of a package Management System.
Best practice in this situation is to install the software on a system, figure out what files were installed created/modified and creating a tarball of the created files and appropriate pre/post scripts etc which perform any require system specific changes. In this situation you can specify the files being installed via the RPM in the %files section and they will be tracked by RPM.
However in reality it may be impractical to avoid creating some “bad” packages in order to enable automated installation.
Having created your rpm directory structure, rpm spec file and source file archive, all that is required is to run the rpmbuild command to generate the rpm file.
The rpmbuild command has a number of options, but to create a binary rpm, the only options we require are “-ba” and possibly “--target <platform>”. The “-ba” option tells rpmbuild to perform all stages of the build process
· Unpacks the original sources.
· Applies patches (if desired) – Only applies when code being compiled.
· Builds the software.
· Installs the software.
· Runs the test suite for the software.
· Creates the binary package file.
· Creates the source package file.
The resulting src.rpm file (created in the SRPMS directory) can then be stored in the version control repository.
The “--target <platform>” option tells rpmbuild which platform the rpm will be applicable to. By default rpms will be built with a target of the generating platform i.e. if built on a 64 bit Intel server, then by default it will have an associated target platform of x86_64. If we have a set of binaries for installing a linux package on s390 for example, then we can still package this on our Intel server, but to create a package that will install on s390, we need to specify that the target platform is different.
NB. The “--target” option is only applicable when creating a binary RPM i.e. the system cannot compile code for a different architecture.
The currently acceptable target platforms for the Lloyds Banking Group Linux estate are
x86_64
s390x
The format for the rpmbuild command is as follows
rpmbuild –ba [--target platform] <directory>/<filename>.spec
When run the rpmbuild process will check the information specified in the spec file, but it will not syntax check any pre or post scripts. Assuming the spec file is correct, and all the files specified are found, then the rpm will be generated and placed in a subdirectory of RPMS. The last couple of lines of the rpmbuild output should be the location of the generated rpms.
When you need to create an upgraded rpm, either because of a new version of the vendor packages, or to correct an issue with the current install/uninstall processes, the first step is to obtain the current source RPM. This should be obtained from your source control system.
This is then installed into your build environment using the following command
rpm –ivh <directory>/<package>.src.rpm
This will place the .spec file in the SPECS directory and the Source repository file in SOURCES. The contents of the Source repository can be extracted using the following command
tar –xzvf <directory>/<source repository>
If for some reason the original files are not available they can be extracted from the current rpm. This can be downloaded from the satellite server through the Web browser gui.
To extract the contents of the rpm change into the pseudo root directory for the package and execute the following command
rpm2cpio <rpm file> | cpio –idmv
To be installed via the Satellite infrastructure the rpms must be signed with the Lloyds Banking Group rpm GPG signature. This step will only be carried out following final ratification by the Satellite administrator.
Once you have a built RPM there are 5 phases to implementing it into production.
8
Although there are a number of ways you can attempt to test an rpm, the only real way to test it is to do a proper install/uninstall. This will require a test box with root access.
User testing must ensure the following
· Rpm installs without any errors
· Any temporary installations files are removed
· The installed package is fully functional
· Rpm uninstalls without any errors
· Once de installed all files related to the package are removed. The exception to this is any files which should be retained as part of an upgrade
· The package install/uninstall does not compromise partition security
· Package upgrade/downgrade does not break the package
Once completed the testing should be repeated by another team member for peer checking. At this point the first part of the rpm tick list should be completed and an e-mail sent to the Satellite Server Administration team.
As part of the tick list, the SRPM will be uploaded to the submission area on the Development Satellite server.
In Phase 2 the Satellite Administrator will perform the following ratification steps, note the process of verification will differ depending in
1. Copy the SRPM file from the submission area to their own local directory.
2. Install the SRPM using rpm -ivh package.src.rpm (nb. does not require root privileges!)
3. Build the package using rpmbuild –bb
This will build the RPM and also extract the Source files to the “BUILD” directory
4. Confirm any scripts in the spec file only perform actions which are related to the package installation
5. Confirm (where possible) the files/directories in the rpm are only related to the package installation
6. Check the SPEC file for any issues as per the Section 9 “Verifying 3rd Party RPMs”
The ratification process will not involve testing the install/uninstall/upgrade/downgrade of the rpm.
Once these steps have been completed, the Satellite Administrator will sign the package with the Lloyds Banking Group Linux GPG key
This will be carried out with the following command.
rpm --resign <rpm file>
The administrator will be requested for the password for the GPG key to complete this process.
Once signed the rpm will be uploaded into the rpm testing software channel on the appropriate Satellite server using the following command
rhnpush –c rpm-testing --server=<hostname> <rpm file>
<hostname> can be either the DNS name of the server, IP address or localhost if the command is being run on the required satellite server.
RPMs related to applications will be loaded into the Development Satellite server. RPMs relating to the standard build or middleware deployments will be loaded into the Infrastructure Testing Satellite server.
The Administrator will need to supply the appropriate administrator usercode/password to upload the package in the Satellite Servers.
Phase 3 involves testing the install/uninstall and upgrading (if possible) of the package using “yum” deployment from a Satellite server. The following steps are required:-
NB. The yum commands require root privilege to run. In Dev/test or Infrastructure test, non root users should prefix the commands with “sudo”.
1. Satellite Administrator will register a test Linux partition with the rpm testing channel (The partition name will be provided in the testing ticklist)
2. On the test partition clear the yum cache so it will find the updated channel definitions
yum clean all
3. If the rpm is an update, then record the current version installed
rpm –q <package>
4. Install (or update) the package using the appropriate command
yum install <package>
yum update <package>
5. Check package version installed and functionality
6. If the previous test was an update, then downgrade the package, otherwise skip to step 8
yum downgrade <package>
7. Check package version and functionality. Skip the remaining steps.
8. Remove the package
yum erase <package>
9. Ensure the package and related files are removed (as in the original testing)
Once these tests have been successfully completed, the second part of the rpm tick list should be completed and an e-mail sent to the Satellite Server Administration team. The Satellite administrators will then move the rpm from the test channel to the destination software channel (add to new channel and delete from rpm testing channel).
Once this is done, a final install/upgrade test must be performed using the destination software channel.
Update once we have a documented software promotion process
Update once we have a documented software promotion process
For testing, particularly in the case of third-party RPMs, the first phase should really be inspection of the RPM (and SPEC file/sources if available) to gain some confidence it's not horribly broken.
The things to check for:
· Check signature & checksums
· Check file permissions
· Check for chmod/chown in scripts
· Inspect any chkconfig in scripts
· Inspect any useradd/userdel in scripts
· Check for any modification of /etc files
· Analyse any firewall or selinux changes!
· Scripts which create/move/copy/delete files, these won't be tracked by the package manager.
· Are changes made by scripts going to be reversed if removed (see %preun/%postun in rpm –scripts -qp package.rpm)
· Check for unsafe permissions (filter o/p with grep):
· rpm -qp --queryformat "[%{FILEMODES:perms} %{FILENAMES}\n]" <rpmfile>
· rpm -qp –dump <rpmfile>
· Standard format for RPM filenames:name-version-release
· Increment version and release numbers when rebuilding with modifications
· Scripts must not create files which are not listed in %files
· Scripts must be non-interactive, and should produce no output
· Test installation on baseline system
· Sign your packages (mandatory for RHN Satellite)
This section summarises the standards required when creating/updating an rpm spec file. For further information please refer to each specific section within this document. Appendix D contains a sample spec file which conforms to the standards.
Introduction
The introduction section should be completed as per the following table
Summary: | A one line description of the package |
Name: | This is the string which defines the package name. Multiple words a permitted and should be separated by a dash |
Version: | If packaging a vendors application, then this should be the 3rd party Vendors version number. |
Release: | Integer release number for this version. This should incremented by 1 for each new rpm created. If releasing a new Software Version (as detailed above), then this should be reset to 1 |
License: | This describes the license under which the package can be distributed. If packaging vendor software for installation in our estate, then this should be set to “Commercial”. |
Group: | This line is used to tell high level installation programs (such as Red Hat's gnorpm) where to place this particular program in its hierarchical structure. You can find the latest description in /usr/share/rpm*/GROUPS. If packaging vendor software for distribution, then this entry should be “Applications/System”. A list of available groups at the time of writing can be found in Appendix E. |
BuildRoot: | This is the pseudo root directory where the binary files to be package will be placed. Should be set to “%{_tmppath}/<Name>-root”, where <Name> is the same as the previous Name field |
%description | This is a multi-line field that should be used to give a comprehensive description of the package. This field begins on the line below %description and will continue until a recognised header is found. The description should be properly wrapped at 72 columns |
Dependencies/Conflicts
Any know dependencies/conflicts must be defined in the spec file
Files
The spec file must have a files section and a defattr variable set. Where a small number of files (<10) is involved, each file must be listed separately in the spec file.
Pre and Post Install/Uninstall Scripts
All pre and post scripts must be fully commented to document what the scripts are meant to achieve and how they function
Change Log
All spec files must have a changelog section and must be updated with every change applied to the spec file.
The following documents were referenced: -
SH MORE LINKS
§ Red Hat Knowledge Base
§ Fedora RPM Guide (Works best with Firefox rather than IE)
· Numerous other websites & guides
RPM Website: http://www.rpm.org/ , http://www.rpm.org/wiki/Docs
Maximum RPM http://www.rpm.org/max-rpm/
Fedora RPM Guide: http://docs.fedoraproject.org/drafts/rpm-guide-en/
http://fedoranews.org/alex/tutorial/rpm/
http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo
http://www.redhat.com/magazine/002dec04/features/betterliving-part2/
http://fedoraproject.org/wiki/Packaging:Guidelines
http://fedoraproject.org/wiki/Projects/Mock
