eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Rigorous manageability is a major advantage of the Linux platform, but, as with any strict framework, necessary exceptions can threaten to upset the works.
Tools and services are available that can help administrators maintain Linuxs software management strengths without completely sacrificing flexibility.
However, the Linux community has significant standards-drafting (and adoption) work to do before well see Linux software management solutions that are as good at embracing distribution diversity and reaching out to developers as they are at managing software within the bounds of individual distros.
Every popular Linux distro ships with some sort of software package management product that governs the installation, update and removal of every piece of software on a system—from the kernel to individual user-level applications.
Since most Linux distros ship with both the operating system and a fairly complete set of applications, sites running Linux can acquire and install security fixes, feature updates and new applications—or any combination of the three—in one operation, using a single set of tools.
However, this scenario assumes that an organization is running only the applications—and specific versions of those applications—chosen by its Linux distributor.
Arranging a stable and well-implemented group of software components is a Linux distributors main job, so, for the most part, it makes sense to stick with what your distributor ships. But often there are very good reasons for administrators to blaze their own open-source trail or follow that of a third-party provider.
The easiest way to step out of the package set supported by a particular Linux distro is simply to install an application by hand—either by compiling the software from source or by extracting precompiled binaries and putting them into their appropriate locations.
However, this means giving up the distros management benefits, including figuring out dependency issues at install time, providing a view into whats installed on the system, and ensuring that libraries or applications with security vulnerabilities get replaced with patched versions as they become available.
One fairly simple solution for installing packages other than those provided by your distributor involves fetching packages from a third-party repository.
Red Hat Inc.s Red Hat Enterprise Linux and Fedora Core distros enjoy the support of an active volunteer packaging community, and acquiring packages from these projects can be as simple as altering the configuration file of those distributions up2date or Yum package-fetching applications.
At times, redundancy and conflict among the packages that these repositories provide can pose their own management challenges, but theres been movement toward better collaboration. Six volunteer packaging projects, for example, recently began combining their efforts into a project called RPMforge (www.rpmforge.net), which is still in its infancy but looks promising.
Trust is an important issue to consider when obtaining packages from third-party repositories. Volunteer repositories typically sign the packages they produce with the same GPG (GNU Privacy Guard) key mechanism as most Linux distributors. This should make administrators confident that the packages theyre installing come from the proper source, but it would be helpful if distributors offered some sort of certification for the projects that package for them.
For maximum software control, administrators can roll their own packages. Instructions for RPM package building are available at www.rpm.org/support/RPM-HOWTO-6.html; instructions for building Debian packages are available at www.debian.org/ doc/devel-manuals.
Senior Analyst Jason Brooks can be reached at [email protected].