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

[Freedombox-discuss] Program Space, a new lightweight virtualization technology



Hi Leen,

> As this makes use of the same kernel features as LXC, Docker and even
> systemd I obviously was comparing it while I'm reading.
> 
> You made some interesting choices.
> 
> I didn't see the choices you made mentioned in the blog, it's mostly an
> introduction/user manual.

That is a correct observation. It's nice that you are interested in the
ideas behind Program Space! Explaining the choices I made is difficult
because psc is just a small part of a bigger design. You have to
understand this design in order to understand why I made some choices.
But, without understanding how Program Space works it's difficult to
understand the design (yes, its the old chicken-egg problem :-) So I
thought it would be best to write an introduction and give people some
code to play with. 

> 
> The ones I noticed where:
> 
> - you basically mentioned this, by naming it the way you did, but it's
> a system for application containers (as it doesn't use init in the
> container)
> 

Correct. Running code that is already present on the host rootfs in a
safe(r) way is my first priority. Running a full userland rootfs like
SID on the STABLE release is something I will probably add later on.
But, one of my design goals (in my hidden agenda) is to use Program
Space to run programs on non privileged accounts for security reasons.
The init process runs as root and starts programs in a way that is not
*directly* controlled by the Program Space user. So I think that in the
end it will be safer not to use a full userland rootfs.

> - but it does run multiple processes, because it includes it own
> in-container daemon
> 
> - does not include networking inside the daemon, to keep it flexible
> and lean

It does include networking inside the container but does not have its
own network code like LXC. Psc makes it possible to setup the network by
using the standard ip utility.  

> 
> - uses the daemon to start commands in the namespace
> 
> - as you didn't use apt-get in your wordpress example I assume you want
> to create a Debian 'image' / container root filesystem which already
> all the packages installed. Maybe even only 1 for all the applications.

I want to avoid a separate container rootfs, instead I present the
programs inside Program Space a modified and protected version of the
host rootfs.

The ps_lamp_create script should install the software (apache, mysql
etc), I have forgotten to add this. Will correct this a.s.a.p. The
reason I did not use apt-get to install WordPress is that the last time
I installed the Debian version of WordPress I did not understand its
configuration. 

> - you build up the namespaces in small steps, by calling the
> commandline tool with different commands and keep the state in the
> kernel/daemon. It is somewhat similar to how Docker has Dockerfile. I
> guess.

Yep, this is done on purpose. A program Space can contain many programs
which you can add one-by-one. By not initializing everything at the
creation of the Program Space you can for example give some programs the
opportunity to grab some resources from outside Program Space before
switching and configuring namespaces. The psd daemon is an example of
this, it opens a listening socket in User Space before switching to a
new NET namespace.  

> 
> I'm sure there are others.
> 
> Some other thoughts I had: - not all source is included, I believe.

What sourcecode is missing? The psd and pst programs are both forks of
the psc program and are therefore included the psc.c sourcecode (they
use a little hack to change their display name right after the fork). 

> - pst runs the program with exec*() I assume ?

pst forks a short-lived psp program that does the exec.

Hope this clarifies things a bit.
Rob.
http://freedomboxblog.nl





Reply to: