Pattern - RPM Files

On linux, you can use the rpmbuild program to create new RPM files; you can then scp up these RPMs, and install them -or push them out to a server farm using yum or similar. This lets you manage hundreds of machines, machines that must be set up to pull down files from your central repository

RPMs can run code at install/uninstall time, so can start and stop services. They are very, very hard to get right though, especially robust uninstall scripts. I've found it easier to not put any scripts there and require the users to shut things down cleanly.

• Pattern - Kickstart Image Creation
• Pattern - Yum

Features

• Well known linux format for packages to install
• Can add install/uninstall scripts
• Can declare dependencies on other RPMs, including, through the JPackage team's work, other Java programs

Advantages

• Integrates with RedHat, SuSE and other RPM-based Linux distributions.
• Enables your application to be added to the public open source repositories (if you use the JPackage dependencies and follow the Linux Standard Base RPM rules).
• Enables your application to be served up through an in-house RPM repository, and pushed out onto existing machines as an update, or added into dynamically created virtual machine images by way of Linux Kickstart.
• Standard uninstall process.
• Gives the OS the ability to query its database to identify the owner of a specific file.
• Good audit trail of installs/uninstalls.
• Good Linux citizenship.
• The pre-install, post-install and pre-uninstall, post-uninstall scripts can be used to start and stop services and other applications.
• The installation can include symbolic links as well as physical files.
• Dependency information can include minimum version requirements of other components.
• Users cannot uninstall your application while another RPM that depends upon it is installed.
• RPM files can include the source and the information needed to build the application. This is good for open source, but also applications that need to be compiled for different CPUs/OS releases.
• Rollout can be automated with Yum

Disadvantages

• Only root can install RPMs.
• Need to test on all supported Linux Distributions.
• Only one version of your application can be installed.
• You cannot uninstall your application while another RPM that depends upon it is installed, not without making the database inconsistent.
• If the JPackage RPMs are used, only one version of any specific Java library can be installed on a target host. This may not be what you want.
• Linux Standard Base does not like pre/post scripts. As they are very hard to get right, they may have a point.
• Ant's <tar> task does not support symbolic links. You need to use the Linux ln -s command, then tar to package it up.
• RPM install/uninstall operations work at a file granularity; there is no standard way in an RPM to add or remove lines in an existing/shared file.
• The JPackage RPMs are very Fedora/RedHat centric.
• The RPM program is not outstandingly informative when things go wrong; you need to scrape the output to make sense of it.

SmartFrog support

1. We have some RPM components, currently in Avalanche, derivatives of which are being implemented in sf-rpmtools.
2. We build and release SmartFrog as RPM files, though we do not integrate with the JPackage RPMs. That is something we may do in future.
3. The sf-ssh package can be used to upload RPMs to target machines, and to issue the commands to install them.

Documenting how we build and test RPMs is on our todo list; some people should find it very interesting. We also want to enhance Ant to set up symlinks in tar files; that would simplify the build significantly.