Differences between revisions 2 and 3
Revision 2 as of 2009-10-31 19:25:48
Size: 5521
Editor: dslb-088-067-059-182
Revision 3 as of 2009-10-31 20:54:50
Size: 5827
Editor: dslb-088-067-059-182
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
Currently it supports the following features: Currently it implements the following features:
Line 37: Line 37:
 * Authentication (password based and maybe by SSL client certificate)
Line 40: Line 41:
 * Do interesting things that involve changing system configuration files like setting a smarthost for the systems mailserver which is used by moinmoin to send email ( could be used for such tasks)
Line 47: Line 49:
echo 'deb binary/' >> /etc/apt/sources.list sudo bash -c "echo 'deb binary/' >> /etc/apt/sources.list"


This document wants to provide some insight into the techniques that can be used to create virtual appliances as plain Debian packages and propose the development of a . It also introduces some ideas for managing appliances and closes with instructions on how to install a prototype that implements a part of those ideas.


There needs to be a reproducible way to create virtual appliances and to maintain them. It would also be a great thing if we could reuse the applications that are already available as packages in Ubuntu.

Users will also want to manage their appliances to a degree which is not possible with only the facilities provided by most of the applications we want to provide as appliances. Part of the last problem is that sometimes those tools are just not powerful enough but there also situations where managing certain aspects of an appliance needs to integrate the actual application with other software that is part of the appliance like a web or mail server. Apart from that it would also do no harm if the management of different appliances was as similar as possible so the users don't have to relearn the same stuff over and over again.


The basic idea is to use a metapackage that depends on the application and all the other packages needed to create the appliance. By installing these packages we will have all the software on the machine but the default configuration of those packages won't be the configuration we want for an appliance. Because of this the maintainer scripts of the appliance metapackage will do the final configuration and change the configuration files of these software packages (the application itself, web server, mail server, database server, etc.).

The Seeding Problem

The biggest problem with this approach is that most application package ask debconf questions during installation. We don't want the user to answer these questions and apply default answers to this questions instead. The first idea was to seed the debconf packages from within the maintainer scripts of the metapackage package. This doesn't work though, since those scripts are executed after all the other packages are already installed. The solution so far is to place a seed file into the same directory of the package repository as the appliance metapackege and use a wrapper program called "vainstall" instead of apt-get to install the appliance. This program will first download the seed file and use it to seed the debconf database and after that it will call apt-get to actually install the metapackage.

Better solutions are welcome but for the moment this seems to be the best.

Managing appliances

To allow the user to configure an appliance and do basic system maintanence tasks such as backup or installing security fixes we need such a webbased configuration interface that already supports the basic tasks common to all appliances but also allows us to write plugins that provide the functionality specific to the respective appliance. I've developed an proof-of-concept of such a program and called it "appliance-control".

There has to be a package of "appliance-control" and one for each plugin where each plugin contains all the functionality for one specific appliance and is written by the people who create the respective appliance. The plugin package will then depend on "appliance-control" and the appliance metapackage will depend on the plugin package.

Currently it implements the following features:

  • Displaying basic information about the appliance
  • Updating the package list of apt
  • Installing updates (works but user feedback missing)
  • Plugin mechanism to add appliance specific functionality
  • Plugin for a moinmoin appliance that supports backup and restore

More features would be needed for a production version:

  • Authentication (password based and maybe by SSL client certificate)
  • Displaying more system information and nicer presentation
  • Restart and Shutdown
  • More appliance specific function for the moinmoin plugin
  • Do interesting things that involve changing system configuration files like setting a smarthost for the systems mailserver which is used by moinmoin to send email ( could be used for such tasks)

  • Much more polishing

Proof of Concept

I've built a proof of concept appliance of the moinmoin wiki software. To try it out just start a fresh virtual machine image of Ubuntu Karmic Server in some hypervisor and issue the following commands:

sudo bash -c "echo 'deb binary/' >> /etc/apt/sources.list"
sudo aptitude update

bzr branch lp:~vmbuilder/vmbuilder/virtual-appliance-tools
cd virtual-appliance-tools
sudo ./vainstall moinmoin-appliance

You should now be able to access the wiki on http://<hostip>/ and on http://<hostip>:8080/ there should be an instance of appliance-control running where you see some information about the appliance and can backup and restore it.

The sourcecode can be found at lp:~vmbuilder/vmbuilder/virtual-appliance-tools and lp:~aheck/vmbuilder/appliances.

Unresolved issues

  • Some software packages that we want to turn into an appliance might ask debconf questions that we can't answer with an default answer since that would break the package.


  • Build appliances that allow the user to split an appliance into subappliances that run on multiple machines to provide the same application. This way you could build a load-balanced setup for a single application with ease. An example could be a content management appliance that can be split up into one database backend appliance and multiple frontend appliances that are configured with appliance-control to find each other

VirtualAppliancesAsPackages (last edited 2009-11-15 22:05:09 by f053214215)