From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Update on GuixSD containers Date: Thu, 11 Jun 2015 10:51:11 -0400 Message-ID: References: <87bngok1vt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z33p9-0003BD-VW for guix-devel@gnu.org; Thu, 11 Jun 2015 10:51:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z33p2-000356-Ki for guix-devel@gnu.org; Thu, 11 Jun 2015 10:51:19 -0400 Received: from mail-pd0-f172.google.com ([209.85.192.172]:34627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z33p2-00034h-FW for guix-devel@gnu.org; Thu, 11 Jun 2015 10:51:12 -0400 Received: by pdbki1 with SMTP id ki1so5620084pdb.1 for ; Thu, 11 Jun 2015 07:51:11 -0700 (PDT) In-Reply-To: <87bngok1vt.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel On Tue, Jun 9, 2015 at 5:28 PM, Ludovic Court=C3=A8s wrote: > "Thompson, David" 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=E2=80=99ve given it a try, and it works as advertised. ;-) > I was a bit afraid the first time I ran the =E2=80=98run-container=E2=80= =99 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 '), 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=E2=80=99s a daemon to keep track of containers, =E2=80=9Cguix= system > container=E2=80=9D could return the PID of the container=E2=80=99s 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=E2=80=99s a shame that only CLONE_NEWUSER is available to non-root use= rs. I > wonder what the rationale was. AIUI, Docker=E2=80=99s daemon performs cl= one(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