[Freedombox-discuss] Virtual Machine Scripting and Tiny Tiny RSS
sean at alexan.org
Mon May 20 15:37:08 UTC 2013
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.
* 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:
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.
More information about the Freedombox-discuss