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 _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
