You Can Go Your Own (Linux) Way

 
 
By Jason Brooks  |  Posted 2005-05-09 Email Print this article Print
 
 
 
 
 
 
 

How to stray from your Linux distribution without getting lost.

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.

Click here to read a review of Red Hat Enterprise Linux 4. 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 jason_brooks@ziffdavis.com.

Check out eWEEK.coms for the latest open-source news, reviews and analysis.
 
 
 
 
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. Jason's coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel