[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] A software architecture for the FreedomBox



On Mon, 2011-04-18 at 10:49 -0600, Bdale Garbee wrote: 
> On Thu, 14 Apr 2011 11:06:46 -0500, Charles N Wyble <charles at knownelement.com> wrote:
> > Yes of course. You are absolutely right. I was thinking of having the 
> > stack be remixed, but I like your idea of having a base stack and then 
> > folks deploy on top of it via some sort of "app store" interface. The 
> > main reason for having a stack that gets remixed is that it would let 
> > you know everything works together.
> 
> This is exactly the experience that Debian already provides.  All
> software is packaged, packages can be installed and removed as desired,
> and the packaging includes strong dependency management.  And shared
> libraries are versioned and multiple versions can be installed at once
> if needed, so different daemons can easily be updated at different times
> without the need for virtualized containers.
> 

I agree, Debian has excellent package management. It should be possible
to install for example a fully configured Wordpress stack (Wordpress,
MySQL, PHP, Apache2 nicely preconfigured and ready to go). The
virtualized containers in my design have the following purposes:

1) Isolation of data/configuration. In my FreedomBox architecture
virtualized web hosting is possible. Each user can have full SSH access
to his/her own container. It should be impossible for one user to
see/change the data and configuration of an other user. 

2) Resource management. As i understand it (must look into this more)
LXC containers can do sophisticated resource management (via cgroups).  

3) Ease of installation/upgrading. A package can be contain just the
root filesystem of an LXC container. The Debian package management can
be used to build one for each processor architecture. Upgrading of a
container involves both data and programs. Something like:

a) make a backup op the data and configuration of a container (via a
data interface, still to be specified)

b) override the root filesystem of the container with the updated
version.

c) restore the data and configuration to the new version.

It is of course still possible to let each user system build the rootfs
using the Debian packaging system. 

4) Isolation of programs that are not in the Debian packaging system.
For example: I needed a newer version of nginx in combination with
uwsgi. By running these programs in a container they can not "damage" my
stable Debian system. 

> I'd suggest anyone working on Freedombox who doesn't already understand
> how Debian's packaging system works spend some time learning about it so
> we don't end up reinventing things that already exist...

I will certainly learn more in the future.   

> To make real progress towards delivering a reference implementation, we
> need to focus attention on mapping feature desires to package names, and
> the generation of wiki-documented recipes for configuring said packages.
> That's the information we need to get together now, regardless of what
> the ultimate configuration user interface looks like.

I think this is a good idea. 
But the architecture and the user interface of the system are important too.
Without work on architecture and user interface the reference implementation
will just be like any other GNU/Linux system: Good for geeks, not for the
average Joe.  

Rob van der Hoeven.





Reply to: