guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /etc/passwd & co. in Docker images


From: Danny Milosavljevic
Subject: Re: /etc/passwd & co. in Docker images
Date: Sun, 22 Nov 2020 17:00:55 +0100

Hi Ludo,

On Fri, 20 Nov 2020 12:34:07 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> Danny Milosavljevic <dannym@scratchpost.org> skribis:
> 
> > After Ryan Prior's E-Mail I'm pretty sure my workaround of creating /tmp,
> > /etc/passwd, /etc/group etc is what Docker actually expects one to do.  
> 
> I’ve been pondering whether to create those files in ‘guix pack -f
> docker’ and…
> 
> > ADD etc/passwd /etc
> > ADD etc/group /etc
> > ADD etc/services /etc
> > ADD with-guix-daemon.scm /
> > RUN ["/usr/local/bin/guix", "repl", "/set-mtimes.scm"]  
> 
> … what you’re doing here suggest that ‘guix pack’ should indeed create
> those files.
> 
> Thoughts?

If guix pack can be used to put multiple packages into one pack,
are then packs like profiles, or would that be too much?

Because the question is what to do if you invoke

  guix pack -f docker guix postgresql

.

Both need user accounts--and thus the total required user accounts (and thus
the contents of /etc/passwd) are the union of the respective required user
accounts of both packages.

So someone needs to merge those, and for that the packages need to require
these user accounts in the first place.

But usually in Guix it's Guix *services* that require user accounts and not
Guix packages.  (which makes sense!)

So I would suggest that

  guix system docker-image ...

create /etc/passwd by merging the required user accounts like described
above, but

  guix pack -f docker a b c

really can't do that.  I mean where would it know the requirements from?

But creating /tmp with the right permissions should be easy enough (?).

That leaves how we want to do a Guix release to a Docker registry.

I think if you pack guix-the-package-manager, the question is whether
there are scenarios (100% offloading for example) that allow you to
use guix without the guix daemon also running inside the docker container.

If so, it doesn't make sense to add /etc/passwd and /etc/services and so
on for guix-daemon in the guix pack case, especially since it singles out
one Guix package, guix, for special consideration.

Then you'd use the guix pack'ed image for using guix-the-package-manager
with 100% offload.

We should release a minimal guix-the-operating-system to a docker registry
so the guix-daemon also works (i.e. built using guix system docker-image).

You'd use this Docker system image when you want to use both guix and
guix-daemon.
 
Are there any downsides to just using a trimmed-down operating-system
definition in order to have a docker image with a working guix-daemon ?

Or we can instead add a static /etc/passwd in Docker after the fact and then
release that to a Docker registry--that's what guix-on-docker does now
(though that doubles the size of the result because Docker is being silly).

Attachment: pgpc4RyNSEl1v.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]