Re: rootless Guix

[Ricardo Wurmus]

Ludovic Courtès <address@hidden> writes:

> Hello!
>
> Ricardo Wurmus <address@hidden> 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