Category: "RPMs"

RPM vs. tar for distribution for open source web applications

RPM advantages

  • Installation always puts it in the same location
  • Single copy of the source on the server, saves disk space
  • Potentially more secure, since permissions can be set to read-only
  • RPM can serve as an installation wizard, rather than writing one
  • RPM can also uninstall
  • Dependencies managed by RPM
  • Upgrades can be managed by RPM
  • Fits nicely into larger architecture
  • Can cross directories to handle configuration at different levels, for example, add an Apache .conf file.
  • Allows custom default configuration to be installed easily

RPM disadvantages

  • Single copy means application shouldn’t be customized once installed, all accounts will have to run the same
  • Single copy also means there may be additional filesystem architecture adaptations, for example a compiled template directory normally placed under the application would have to be accommodated. Application may have to be modified
  • May require root access
  • Filesystem architecture should be known
  • Requires installer to have some knowledge of RPM, usually more complex than tar
  • Requires installer to understand more filesystem commands (how to link into installed application, rather than install it
  • If application is normally distributed as a tar/gz file, RPM will be outside the documentation
  • Creating RPMs is far more complex than creating tars. Learning curve.
  • Development team and environment. If everyone is working on a single server, it may be difficult for them to share a single copy of an application. Consider VMWare.

Deciding Factors

  • Installation type - single application on the server, or multiple. Single is best with RPM, multiple is probably better with tar
  • Application source - custom applications may be better with RPM, outside/open source applications are probably better with tar
  • Dependencies and type - RPM really does a nice job with dependencies
  • Upgrades - RPM allows yum/up2date management of upgrades, with dependency observation
  • Skill/experience/education level of team
  • Servers in use - tar may be slightly more portable
  • Flexibility of target system
  • Updates during development are very easy to apply with RPMs

RIA Hosting

Using RPMs to install open source toolkits such as dojo, Smarty, and Zend Framework allows hosting companies to create a cost-efficient architecture to offer clients servers ready to support RIAs and sophisticated sites.

This may improve security by allowing the hosting company to prevent clients from modifying open source products. Access to the code can be provided easily through the use of symlinks. Account setup can be automated with server management/admin software like WebHostManager and Plesk - by customizing the account setup scripts with additional RPMs.

Advantages:

  • Significant savings in disk space
  • Elimination of installation at the account level
  • Permission management performed at the server level
  • Ease of toolkit maintenance, a single installation can be upgraded for the whole server
  • Offering an RIA ready server is a valuable service that may be delivered in a cost effective manner. It may be an offering that makes one hosting company more attractive to clients than another, in other words, good business sense.

Disadvantages:

  • Changes to the toolkits will affect every site, thus they cannot be changed easily, and upgrades may be disruptive. However, based on the assumption that this code should not be modified, and upgrades are often security related, synchronizing the toolkits across the server is reasonable.
  • An excellent understanding of the server architecture, software, and RIA toolkits is required for a graceful implementation.

Open Source RPM .spec file

This is an RPM .spec file for dojo, that will install it in /opt/os/dojo

.rpmmacros

%_topdir /home/account
%_buildroot %{_topdir}/BUILD
%_tmppath %{_topdir}/tmp

dojo.spec


%define targetdir opt/os/dojo
%define version 1.1
%define release 1
%define name dojo
%define dojo %{name}-release-%{version}.%{release}

Summary: dojo Toolkit
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: GPL
Group: Development/Tools
#Source: dojo-release-1.1.1.tar.gz
Source: http://download.dojotoolkit.org/release-1.1.1/dojo-release-1.1.1.tar.gz
Provides: %{name}
BuildRoot: %{_buildroot}
%description
dojo Toolkit

%prep
%setup -q -n%{dojo}
tar tzf %{_topdir}/SOURCES/%{dojo}.tar.gz | grep -v "/$" | sed "s/dojo-release-1
.1.1//"| awk '{ print "\"/%{targetdir}"$0"\""; }' > %{_topdir}/outfile
mkdir -p $RPM_BUILD_ROOT/%{targetdir}
rm -rf $RPM_BUILD_ROOT/%{targetdir}/*
%build -n%{dojo}
%install -n%{dojo}
mv * $RPM_BUILD_ROOT/%{targetdir}
%clean -n%{dojo}
rm -rf $RPM_BUILD_ROOT

%files -f %{_topdir}/outfile

The same general approach will work for Zend, Smarty, Drupal and many others. Expect to have to adapt the name of the tar/gzip/zip file - hence the use of the %{dojo} macro. The tar tzf command allows the RPM to be installed in a directory with other code. Although it is unlikely dojo would be placed in a directory with other code, the tar listing allows you to place several tars in the same directory, and still manage them with RPMS.

Download: http://wirehopper.com/dojo-1.1-1.i386.rpm
Source RPM: http://wirehopper.com/dojo-1.1-1.src.rpm

If you use the RPM to install dojo, use a symlink (ln -s /opt/os/dojo dojo) from DocumentRoot. This will allow a single installation of dojo to support all your sites.

RPMs with web applications and version control

Any large web application requires version control. Whether it is subversion or CVS, ClearCase, or some other tool, a system must be in place to manage the software changes and updates, especially if more than one person is working on the code.

The organization of the code within the version control system should reflect the anticipated deployment approach. Many web applications have varying levels of functionality. One approach is to place th core code in a single directory. This includes the foundation architecture, default language and configuration, core functionality, and shared class definitions, as well as anything else that is required to support the system. Other modules can be in separate directories, which makes it easy to build RPMs.

Thus, the core RPM is created with the core files, and the other system components require the core for installation.

Since the RPMs use tar files to get the source, and tar files are a convenient way to update the code for development, scripts that generate the tar files, then the RPMs can support both development and distribution, by updating the internal/informal and external/formal deliverables. One script can extract the latest versions of the code from version control, create tar files, make them accessible to the RPMs and build the RPMs. The same script could also copy the new RPMs to a target server, which could then install them with little effort.

This approach may be too rigid for small applications or those that will be distributed to a larger community, as tar files are more flexible.

RPM BuildRoot

The BuildRoot setting in an RPM spec file is what allows you to indicate the target directory for the files you are including in the package.

1 2 3