On Tue, Jun 9, 2015 at 5:28 PM, Ludovic Courtès <l...@gnu.org> wrote: > "Thompson, David" <dthomps...@worcester.edu> 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