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

[Leen Besselink]

On Mon, Dec 30, 2013 at 02:45:56PM +0100, Rob van der Hoeven wrote:
> Hi Leen,
> 

Hi Rob,

> > 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

It coincided with me thinking about how best to apply LXC and Docker on
servers. I'm currently thinking of using Docker for applications and LXC
for infrastructure that depend on static IP-addresses and other things like
that.

> 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. 
> 

I figure you figured correctly.

> > 
> > 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
> > 

I actually think this is kind of 'innovative'.

> > - 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.  
> 

Yes, that is how I understood it.

Your example used the model with bridged and DHCP-client in the container.

I wonder what would be the models which fit best for the Freedombox.

At least Program Space doesn't dictate anything, so that is good.

> > - 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.
> 

Ahh, OK (or actually in Dutch: dus toch !).

I was getting a bit tired at the end of the day, I had to stop.

> 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.  
> 

Ahh, OK that is how you do it. I hadn't checked that yet.

> > 
> > 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). 
> 

There is a ps_set_name, of course, sorry, missed that part.

> > - 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.

It does.

I suggest you keep going, I hope for you can get it into Debian and Freedombox.

Would be even better if you write down your bigger design.

> Rob.
> http://freedomboxblog.nl
>