Linux distributions can be a pain. Users have to go through the whole
process of installation, configuration, and updates, and, often, all they
really want to do is to run a single application. The vendors of that
application, meanwhile, feel the need to support as many distributions as
possible, even though the actual system running underneath their code is
nearly irrelevant. Wouldn't it be nice if users could simply get their
desired application as an "appliance" which comes with all the necessary
component parts nicely hidden inside?
As it happens, rPath has been in the appliance business for a little while
now. Recently, the company has made its appliance-building infrastructure
available to free-software products in the form of rBuilder Online. In essence,
rBuilder can be used to create and maintain a custom distribution oriented
around the delivery of a specific application. The result is a
"software appliance" which, in theory, makes the given application
available in a self-contained, standalone distribution.
There are a number of example appliances available on the site. They
- Bongo, an attempt to
revitalize work on the Hula mail client
- Gallery, a standalone photo
- LochDNS, a DNS
- Openfiler, a storage
There are several others oriented around content
management systems, telephony applications, database servers, and more.
All told, quite a few projects have shown interest in creating software
appliances for their applications.
Your editor grabbed a copy of the Openfiler appliance and installed it onto
a spare box which had been cluttering up the office. Appliances from
rBuilder start out looking like a Fedora system; they use the same Anaconda
installer. The installed system also shows a lot of Red Hat heritage, such
as /etc/sysconfig, various system-config-* commands, an
/etc/inittab file which credits Mark Ewing and Donnie Barnes,
etc. But there is a crucial difference: there is no rpm command. Instead,
these appliances are based on rPath's Conary package management
system, which takes a very different approach to the software management
problem. But there are still similarities with Fedora: your editor
attempted a conary updateall operation on
the LochDNS appliance, only to see it fail with a set of file conflict
errors; it was almost like running Rawhide again.
Appliance users are not supposed to have to dirty their fingertips with
command-line administrative operations, though. To help them avoid this
fate, rBuilder-based appliances come with the rPath
Appliance Platform Agent, otherwise known as a web-based administration
interface. Once the user gets past the usual set of obnoxious Firefox
dialogs ("this site has an SSL certificate which is not only unknown, but
certainly hostile and is ugly besides"), this interface provides a
set of administrative screens for standard tasks (networking, updating the
system, etc.) along with some specific to the Openfiler application.
In theory, it should be possible to manage one of the appliances without
ever going to the command line - or even knowing that the command line
exists. In practice, how well that works depends a lot on how the
administration screens are designed. In the Openfiler case, quite a bit of
clicking around in circles was required, but your editor did finally
succeed in setting up a volume based on a USB key, perform a software
update, and shut down the system at the end.
The creation of appliances would appear to be relatively straightforward;
details can be found in this
document. One creates an account in the rBuilder system, then puts
together a file describing which components (packages) are necessary in the
final system. Those components will presumably include at least one
application provided by the appliance builder - that application being the
reason for the creation of the software appliance in the first place. The
"rMake" system will then pull all of the pieces together, bring in any
needed dependencies, and wrap it all up inside a
minimal distribution; the resulting system image seems to run at about 300MB.
There are several possible output formats, including the Anaconda-based
installation CD image; the rPath folks would appear to have put a lot of
effort into making appliances work on a number of virtualization platforms
as well. Appliances can be built for VMWare, various forms of Xen,
VirtualIron, and Microsoft VHD. Notably absent is anything based on Lguest
or KVM. Even more notably absent is any kind of live CD appliance;
anything not running in a virtual machine must be installed onto the host
rPath's Conary servers seem to be set up to handle software updates. It is
also possible to obtain source for the packages found in an appliance
through the rBuilder site, though one must do a little digging first.
Both of these features are important: anybody creating a distribution-based
appliance has to arrange for updates and source availability somehow. One
assumes that most appliance creators have no real desire to get into the
broader distribution business, so it's nice for them to be able to offload
these tasks. Anybody distributing these appliance images should note that
rPath does not appear to have undertaken any obligation to continue to
provide these services in the future. Should rPath decide to stop, some
interesting questions on who is ultimately responsible for satisfying the
source-availability provisions of the GPL could come up.
Naturally enough, rPath offers commercial services for those who would like
stronger guarantees about long-term support, or who want to include
proprietary software in their appliances.
For the time being, this approach to software distribution would seem to be
most useful for companies which are in the business of building real,
hardware-based appliances. Distributing software in virtual machines has
the look of a new and truly impressive form of bloat; even "just enough
operating system" is a lot of baggage for an application to drag around.
For situations where one wants to try out a complex system, appliance
distribution may be worth its cost, but one would probably not want to get
every application this way.
There may be value, though, in software distributions which can run almost
anywhere, and which can be nicely isolated from the outside world. Locking
network-exposed applications - server processes or web browsers - into
their own little world could help to avoid a lot of security problems in a
way which seems more straightforward than SELinux or containers.
But, perhaps most interestingly, the appliance approach could eliminate a
number of distribution-compatibility issues by putting many more people
into the distribution business. Now anybody can throw together a
special-purpose distribution without having to deal with all of the
plumbing that makes the whole thing actually work. Something interesting
will certainly come of this idea, even if it's hard to say just what that
might be at the moment.
to post comments)