Re: Update on GuixSD containers

[Thompson, David]

On Tue, Jun 9, 2015 at 5:28 PM, Ludovic Courtès <address@hidden> wrote:
> "Thompson, David" <address@hidden> skribis:
>
>> I'd like to give a quick update on the state of wip-container branch.
>> As of this morning, one can run the below commands and have a somewhat
>> functional GuixSD container:
>>
>>   # Hardcoded /tmp/container as the container root directory until I
>>   # add a command line switch.
>>   mkdir /tmp/container
>>   guix system container container-config.scm
>
> Wonderful!  I’ve given it a try, and it works as advertised. ;-)
> I was a bit afraid the first time I ran the ‘run-container’ script as
> root, but everything went like a charm.

Yeah, running as root is a bit scary.  With working user namespaces it
should become less scary.  I just don't know how to reasonably start a
system with users of its own that are allowed to write to the file
system.  Everything I've tried thus far has failed.  I thought that
mapping the uid/gid 0 in the namespace to uid/gid 0 outside of the
namespace would be enough to boot the system, but it didn't work.

> I tried adding this dummy service:
>
>   (define (bash-service)
>     (with-monad %store-monad
>       (return (service
>                (documentation "Run Bash from PID 1.")
>                (provision '(shell))
>                (start #~(make-forkexec-constructor
>                          (string-append #$bash "/bin/bash")))
>                (stop #~(make-kill-destructor))
>                (respawn? #t)))))
>
> ... but it dies for some reason.  So no shell prompt.

I wouldn't expect that to work because bash isn't actually run in your
tty.  To create an interactive environment within the container (or
run any arbitrary program), we need a tool that calls setns() with
open file descriptors for all of the container's namespaces and then
exec() the desired command.  I threw together a tool to do this
quickly, but for some reason joining the mount namespace fails with
EINVAL.  I have no idea why.  Joining the IPC, UTS, PID, and network
namespaces isn't a problem.  Enlightenment needed!

>> For the long term, we'll need a container daemon to keep track of all
>> containers on the system to allow for easily starting and stopping
>> them (right now you have to 'sudo kill -9 <dmd pid>'), spawning new
>> processes within them (for example, launching bash for an interactive
>> environment), and whatever else we might want.
>
> Having launched a bunch of containers and then hacked to kill all the
> dmds, I can see why keeping track of containers matters.  :-)
>
> Until there’s a daemon to keep track of containers, “guix system
> container” could return the PID of the container’s PID1, to make it
> easier to kill it later?

I'm actually unsure how to acquire the PID of the container's init
process since I clone and exec.  Any ideas?

> It’s a shame that only CLONE_NEWUSER is available to non-root users.  I
> wonder what the rationale was.  AIUI, Docker’s daemon performs clone(2)
> on behalf of clients, right?

Yeah, our daemon would do the same thing.  We could maybe even have a
little Guile library that allows one to evaluate arbitrary scheme code
from within the container. :)

- Dave