rootless Guix

rootless Guix

[Ricardo Wurmus]

Hi,

it would be nice if we could simplify the case where a user does not
have root access, but the system supports user namespaces.

Currently, a user would have to perform a number of non-obvious steps to
somehow run the Guix daemon in an environment where the filesystem is
virtualized.  It would be great if we could better support this case,
maybe even simplify it to a point where the user does not have to even
start the daemon by themselves.

A user operating in this mode would lose the ability to share with other
users on the same system, of course.  By default Guix could store
everything in a subdirectory of ~/.local and map that to /gnu/store in
the container context.  Applications would also need to be run from
within that container context to ensure that /gnu/store file names are
resolved properly.

I think this would be especially useful for situations where “guix pack”
is not sufficient.  “guix pack” produces one-shot bundles, but it cannot
be composed.  A daemon+store-in-container setup would be extensible.

What do you think about this?  Can we automate the setup necessary for
this scenario and add better defaults?

--
Ricardo

Re: rootless Guix

[Pierre Neidhardt]

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

Hi,

Not answering your question, but I think it's an awesome idea!

Could this possibly be the last step needed to enable Guix as an "embeddable"
package manager, in the sense that it could be used by any project as the main
mean of distributing components? (E.g. a programming language with libraries or
a web browser with extensions.)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: rootless Guix

[Ludovic Courtès]

Hello!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> it would be nice if we could simplify the case where a user does not
> have root access, but the system supports user namespaces.
>
> Currently, a user would have to perform a number of non-obvious steps to
> somehow run the Guix daemon in an environment where the filesystem is
> virtualized.  It would be great if we could better support this case,
> maybe even simplify it to a point where the user does not have to even
> start the daemon by themselves.

For the record, here’s what needs to be done to run guix-daemon and guix
as produced by ‘guix pack --relocatable guix’:

  https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html

We could certainly arrange so that users don’t have to fiddle with
$NIX_STATE_DIR etc.

> A user operating in this mode would lose the ability to share with other
> users on the same system, of course.  By default Guix could store
> everything in a subdirectory of ~/.local and map that to /gnu/store in
> the container context.  Applications would also need to be run from
> within that container context to ensure that /gnu/store file names are
> resolved properly.

Right, I’m not sure what to do with binaries installed with this
relocatable Guix: either we let the user run them from a relocatable
shell that maps /gnu/store appropriately (as in the message above),
which works but is inconvenient, or we somehow instruct ‘guix package’
to make everything relocatable before adding it to the profile (like
what ‘guix pack -R’ does.)

As for spawning guix-daemon automatically, I’m not sure.  I’d rather
have the ‘guile-daemon’ branch ready and merged, and then use that as a
library, rather than having to spawn a full guix-daemon process behind
the scenes.  Though of course, that’s a longer-term effort.

> I think this would be especially useful for situations where “guix pack”
> is not sufficient.  “guix pack” produces one-shot bundles, but it cannot
> be composed.  A daemon+store-in-container setup would be extensible.
>
> What do you think about this?  Can we automate the setup necessary for
> this scenario and add better defaults?

I think it takes some reasonable effort, it would be nice, but I’m not
entirely sure if it’s worth the effort (maybe it is, I really don’t
know.)

WDYT?

Thanks,
Ludo’.

Re: rootless Guix

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>
>> it would be nice if we could simplify the case where a user does not
>> have root access, but the system supports user namespaces.
>>
>> Currently, a user would have to perform a number of non-obvious steps to
>> somehow run the Guix daemon in an environment where the filesystem is
>> virtualized.  It would be great if we could better support this case,
>> maybe even simplify it to a point where the user does not have to even
>> start the daemon by themselves.
>
> For the record, here’s what needs to be done to run guix-daemon and guix
> as produced by ‘guix pack --relocatable guix’:
>
>   https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html
>
> We could certainly arrange so that users don’t have to fiddle with
> $NIX_STATE_DIR etc.
>
>> A user operating in this mode would lose the ability to share with other
>> users on the same system, of course.  By default Guix could store
>> everything in a subdirectory of ~/.local and map that to /gnu/store in
>> the container context.  Applications would also need to be run from
>> within that container context to ensure that /gnu/store file names are
>> resolved properly.
>
> Right, I’m not sure what to do with binaries installed with this
> relocatable Guix: either we let the user run them from a relocatable
> shell that maps /gnu/store appropriately (as in the message above),
> which works but is inconvenient, or we somehow instruct ‘guix package’
> to make everything relocatable before adding it to the profile (like
> what ‘guix pack -R’ does.)

Installing a relocatable wrapper would be fine, too, but I think it’s a
little ugly that a profile generated with relocation enabled would
contain different binaries than one where this hasn’t been done.  I
have a slight preference for keeping the software unchanged.

FWIW running programs in a “container environment” is what Docker users
are already used to.  It would be fine to have “guix container --run …”
or a variant of the proposed “guix run” for the kinds of people who are
used to Singularity or Docker.

> As for spawning guix-daemon automatically, I’m not sure.  I’d rather
> have the ‘guile-daemon’ branch ready and merged, and then use that as a
> library, rather than having to spawn a full guix-daemon process behind
> the scenes.  Though of course, that’s a longer-term effort.

Yes, I’m not really interested in running the daemon; it would be even
better if we could avoid it of course.  But I don’t think that this can
be accomplished within a reasonable time frame.  We have that depedency
on the daemon now and it seems to me that starting it automatically (in
the presence of a ’guix’ command line flag or an environment variable)
is a solution that requires the least effort.

My goal really is to free the user from thinking about the daemon at
all.  When the user has indicated (how?) that it is preferable to keep
the store somewhere in ~/.local and use file system virtualization, then
we could take care of the daemon and everything that belongs to it.

>> I think this would be especially useful for situations where “guix pack”
>> is not sufficient.  “guix pack” produces one-shot bundles, but it cannot
>> be composed.  A daemon+store-in-container setup would be extensible.
>>
>> What do you think about this?  Can we automate the setup necessary for
>> this scenario and add better defaults?
>
> I think it takes some reasonable effort, it would be nice, but I’m not
> entirely sure if it’s worth the effort (maybe it is, I really don’t
> know.)

If it allows users on single-user systems to use Guix easily without
having to be root then I think it would very well be worth the effort.
The dependency on a daemon that runs as root is still often considered
an obstacle — you probably also know that Singularity got a big
popularity boost purely for circumventing the need for a root daemon (by
using a setuid binary, which admins seem not to worry or know about).
Allowing people in certain situations to forget about the daemon might
have a similarly positive effect on how people perceive the setup
complexity of Guix.

“guix pack” is great for using software on systems where Guix cannot be
used, but its output for one package closure cannot be composed with the
output of another package closure.  By making the daemon run in a
container we can bring more of the features of Guix to these limited
systems.

--
Ricardo

Re: rootless Guix

[Ludovic Courtès]

Hi Ricardo!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> Right, I’m not sure what to do with binaries installed with this
>> relocatable Guix: either we let the user run them from a relocatable
>> shell that maps /gnu/store appropriately (as in the message above),
>> which works but is inconvenient, or we somehow instruct ‘guix package’
>> to make everything relocatable before adding it to the profile (like
>> what ‘guix pack -R’ does.)
>
> Installing a relocatable wrapper would be fine, too, but I think it’s a
> little ugly that a profile generated with relocation enabled would
> contain different binaries than one where this hasn’t been done.  I
> have a slight preference for keeping the software unchanged.

I agree about the ugliness.

> FWIW running programs in a “container environment” is what Docker users
> are already used to.  It would be fine to have “guix container --run …”
> or a variant of the proposed “guix run” for the kinds of people who are
> used to Singularity or Docker.

Right, so we could have something like “guix enter” or even simply
./bin/sh (a wrapped shell that binds /gnu/store in its namespace.)

>> As for spawning guix-daemon automatically, I’m not sure.  I’d rather
>> have the ‘guile-daemon’ branch ready and merged, and then use that as a
>> library, rather than having to spawn a full guix-daemon process behind
>> the scenes.  Though of course, that’s a longer-term effort.
>
> Yes, I’m not really interested in running the daemon; it would be even
> better if we could avoid it of course.  But I don’t think that this can
> be accomplished within a reasonable time frame.  We have that depedency
> on the daemon now and it seems to me that starting it automatically (in
> the presence of a ’guix’ command line flag or an environment variable)
> is a solution that requires the least effort.

I see.  (Though in terms of effort, having just the bits of
the ‘guile-daemon’ branch needed for this setup may not be that much
work compared to setting up the machinery to spawn ‘guix-daemon’.)

> My goal really is to free the user from thinking about the daemon at
> all.  When the user has indicated (how?) that it is preferable to keep
> the store somewhere in ~/.local and use file system virtualization, then
> we could take care of the daemon and everything that belongs to it.

One way to configure it might be to set GUIX_DAEMON_SOCKET=internal or
something along these lines.

Something that works without config would be better, but it seems
difficult to achieve without breaking current multi-user setups.

> If it allows users on single-user systems to use Guix easily without
> having to be root then I think it would very well be worth the effort.
> The dependency on a daemon that runs as root is still often considered
> an obstacle — you probably also know that Singularity got a big
> popularity boost purely for circumventing the need for a root daemon (by
> using a setuid binary, which admins seem not to worry or know about).
> Allowing people in certain situations to forget about the daemon might
> have a similarly positive effect on how people perceive the setup
> complexity of Guix.
>
> “guix pack” is great for using software on systems where Guix cannot be
> used, but its output for one package closure cannot be composed with the
> output of another package closure.  By making the daemon run in a
> container we can bring more of the features of Guix to these limited
> systems.

OK, that makes sense.  Well, let’s see how we can get there!

Thanks,
Ludo’.