all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: Building Docker images of GuixSD
Date: Fri, 15 Dec 2017 18:30:42 -0800	[thread overview]
Message-ID: <87wp1n9zfx.fsf@gmail.com> (raw)
In-Reply-To: <87609vid4q.fsf@cbaines.net> (Christopher Baines's message of "Mon, 27 Nov 2017 22:13:25 +0000")

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> Unfortunately, while I could get a shell using "docker exec ...", I had
> to start the guix-daemon manually as the shepherd service didn't seem to
> work, at least initially. Also, when I had started it, I tried
> installing a package, and there was some promising output to start off
> with, but then it failed with:
>
>   guix package: error: build failed: cloning builder process: Operation
>   not permitted
>
> Anyway, this is all pretty great! Awesome work getting this far. I'm
> very excited to see what services will run this way, as Docker could
> provide, albeit with some overhead, a layer of interoperability between
> software that can handle Docker containers, and Guix.

I tried making the changes you suggested.  I launched a container
without using docker's --privileged option.  However, the "boot" script
failed because something couldn't mount something in the container.  I
am not excited about the idea of trying to figure out which esoteric
combination of capabilities [1] are needed to run without the
--privileged option, but I suppose that is necessary if I want to
minimize the container's access to the host system.

To be honest, I find it puzzling that Docker requires me to think so
much about the capabilities in the first place.  Perhaps I'm naive, but
I had hoped that within a Docker container, everything would be
"private" in the sense that, as root in the container, I can do anything
and everything, including mounting, including creating device nodes, and
no changes will be visible outside of the container.  The fact that that
is not the case (at least by default) comes as quite a surprise to me.

I also noticed that some services, like nscd, failed to start.  No error
messages anywhere except Shepherd saying something like "could not start
service nscd".  How do I begin to debug something like that?  All I can
think of is to inspect the Guix code that runs the service, and the
Shepherd code, commit time to learning about it, and then hopefully find
a way to insert debug statements of some kind that give me a hint about
what's going wrong.  Is there a faster, better way?

[1] https://docs.docker.com/engine/security/security/#linux-kernel-capabilities

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2017-12-16  2:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12  3:29 Guix on macOS Chris Marusich
2017-10-12  8:08 ` Konrad Hinsen
2017-10-12  8:59 ` Ludovic Courtès
2017-10-12 20:35   ` Christopher Allan Webber
2017-10-12 21:33   ` Ricardo Wurmus
2017-10-13 15:58     ` Christopher Allan Webber
2017-10-13  7:14   ` Chris Marusich
2017-10-13 11:47     ` Ricardo Wurmus
2017-10-13 12:55     ` Ludovic Courtès
2017-10-13 13:59       ` Konrad Hinsen
2017-10-13 13:59       ` Ricardo Wurmus
2017-10-13 15:59         ` Christopher Allan Webber
2017-10-13 14:08       ` Konrad Hinsen
2017-10-25 15:50         ` Adonay Felipe Nogueira
2017-10-27  4:11     ` Chris Marusich
2017-10-27  7:56       ` Hartmut Goebel
2017-10-28 20:27       ` Building Docker images of GuixSD Ludovic Courtès
2017-10-31  2:59         ` Chris Marusich
2017-11-05 15:45           ` Ludovic Courtès
2017-11-09  6:15             ` Chris Marusich
2017-11-09  6:43               ` Pjotr Prins
2017-11-09  8:23               ` Konrad Hinsen
2017-11-17 21:14               ` Ludovic Courtès
2017-11-27 22:13               ` Christopher Baines
2017-11-30  9:11                 ` Ludovic Courtès
2017-12-07  9:33                 ` Chris Marusich
2017-12-16  2:30                 ` Chris Marusich [this message]
2017-10-12 19:09 ` Guix on macOS Christopher Baines
2017-10-25 14:45 ` Adonay Felipe Nogueira
2017-10-27  1:06   ` Chris Marusich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wp1n9zfx.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.