[Freedombox-discuss] Virtual Machine Scripting and Tiny Tiny RSS

[Sean Alexandre]

On Mon, May 20, 2013 at 12:45:47PM +0100, Nick Hardiman wrote:
> Do you have a rundown yet of how to 
> * stick exmachina (http://gitorious.org/exmachina) at the back, 
> * proxy (http://www.privoxy.org, https://github.com/jvasile/freedombox-privoxy) in front, and 
> * various apps into LXC?

No, I wish I did.  As a first pass, though, here are some things I think a solution 
would have. As a disclaimer, I realize that this is a departure from the current
approach taken with the DreamPlug and wouldn't work for it. It seems like a natural 
evolution for the project, though, as hardware becomes more capapable.

First, some terms:

* VM - A virtual machine (VM), either a lightweight VM such as LXC or a fully
  virtualized machine such as KVM.
* Host - The machine runs the VMs.
* Guest - An instance of a VM.

An approach:

* The web app that provides the user interface (Plinth) runs in its own guest.
* Each additional app or service (e.g. Privoxy) also runs in its own guest.
* The host manages all guests: creating, starting, stopping.
* Communication between host and guests would happen through sockets; e.g. for
  KVM this might be based on something like this:
  http://www.ldlabs.org/blog/2011/02/25/communication-between-qemukvm-guest-and-host/

What would this mean for exmachina, I wonder? It seems augeas may not be an option.
The larger ideas behind exmachine would still apply, though, I think.  Instead of 
augeas, the host would read from the socket. Any parsing it does would be very locked 
down, to help prevent injection attacks from a compromised guest. The host would have 
a whitelist of things it accepts, and discard anything else. Processing would be done
in an environment such as Python versus C, to prevent memory overwrite problems.

It would be nice if this were done in a way allows a choice between KVM and LXC. So 
scripts such as "freedombox-vm create" would call out to stubs that would do one thing for 
KVM and something else for LXC. (A given FreedomBox would be based on just KVM or
LXC, and not both.)

Whether all the stubs get filled out, and for what types of VMs (Tiny Tiny RSS, 
Tor Relay, etc) would depend on the do-ocracy model that FreedomBox seems to be 
following. I know I'm interested in this. I just wish I had more time for it.

One other thought is this would ideally be a plugable architecture. A common interface 
would define how FreedomBox guests communicate with the FreedomBox host. Different 
people could be working on differerent modules. So I might be working on a Tiny Tiny 
RSS module, while someone else is working on an ownCloud module, someone else on the 
actual host, etc.