UEC prototype appliance [was: Re: moodle appliance update]

Dustin Kirkland kirkland at canonical.com
Mon Oct 5 23:17:55 BST 2009


On Thu, 2009-09-24 at 14:02 -0700, Matt Zimmerman wrote:
> Can we move this discussion to a public mailing list?  Feel free to quote
> anything I have said below and reply on ubuntu-devel.

Cool.  CC'ing ubuntu-devel@ now.

> On Thu, Sep 24, 2009 at 01:46:58AM -0700, Dustin Kirkland wrote:
> > On Wed, 2009-09-23 at 10:38 -0700, Matt Zimmerman wrote:
> > >    + Adapting to fit the UEC storage model (non-persistent OS image)
> > > [...]
> > This helps a lot.
> > 
> > Okay, so (once again) Moodle has proven to be an exceedingly difficult
> > project to produce a web-appliance-ize.  Its preinstallation debconf
> > questions, requirements on having a running database, and database
> > population have presented a number of problems that, while perhaps
> > solvable, are most certainly non-trivial
> > 
> > Thus, I have refined the appliance target further, to something that
> > installs cleanly without critical priority debconf questions -- a gobby
> > server.
> 
> This is worth doing in order to get over the hurdle of having no appliances
> at all.  However, I think for the "big splash" at 9.10 we are going to need
> to have something which is more applicable to clients which are not running
> Ubuntu, i.e. probably a web-based application.
> 
> > Using the Jaunty UEC images at:
> >  * http://uec-images.ubuntu.com/jaunty/current/
> > I installed the gobby server package (sobby).  Note that I had to write
> > and install an init script (which I'm hoping to upload as a bug-fix to
> > karmic soon, LP: #435724).
> > 
> > This image should be relatively straight forward and work in UEC.  Users
> > of the image should simply run Gobby locally, and Join a Session located
> > at the IP address or hostname of the appliance.
> > 
> > This image is located at:
> > http://rookery.canonical.com/~kirkland/ubuntu-uec-jaunty-gobby-amd64.img.gz
> 
> What happens to the Gobby document data when the instance is terminated?

This is unaccounted in the above referenced image.  I planned on
documenting where the admin could find their gobby data in the
filesystem, and recommend retrieving that before terminating an
instance, or using shared storage instead.

Soren-

I understand from Thierry that I'm transferring the responsibility of
constructing the virtual appliance prototype to you.  Is there anything
you need from me at this point?

As a brief recap...

 1) I started with alfresco as the virtual appliance target.  This
proved difficult, as alfresco is a huge package, mostly untested in
Karmic, and dependent on the Sun Java stack, which is working its way
out of Ubuntu.  This combination of factors made alfresco an impractical
choice, in my opinion.

 2) I looked at Wordpress, since it's a totally open source stack,
web-configurable, and well used throughout the Ubuntu world.  I decided
against this one, due to the frequency of security updates necessary to
apply to a running, internet-facing Wordpress instance.

 3) I worked on Moodle quite a bit next, also because it's totally open
source, web-configurable.  However, I learned that debconf-critical
questions on package installation is generally difficult to handle in
such an appliance.

 4) I settled on Gobby as a service (provided by the sobby package).
Note that I had to patch sobby in Karmic with an init script to start
the service automatically on boot.  Gobby/sobby is particularly kind in
that it has no critical debconf questions, works perfectly out of the
box.  Perhaps less valuable than alfresco, wordpress, or moodle, but
quite functional as a demonstration of what a UEC might look like.  To
create this image, I simply downloaded the daily karmic UEC snapshot,
chrooted, installed sobby, and rebundled.

One more comment, as an addendum.  Personally, I'm not a big fan of the
tarball approach to appliance creation and deployment.  I think that
such appliances are "out of date" within hours of their creation, as
packages inevitably get updated in the Ubuntu archives.  I think a
smarter approach would consist of testing, certifying, and blessing a
base UEC Ubuntu image, and providing a suite of appliances as basically
meta packages, perhaps in a PPA, that install and configure whatever
packages and services such appliances are defined to provide.  I would
like to discuss such a concept further on this list, and perhaps at UDS
as a blueprint.


-- 
:-Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20091005/1d3976e3/attachment-0001.pgp 


More information about the ubuntu-devel mailing list