bug#20381: Interacting with a remote daemon

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

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

> What about installing Guix in /gnu/bin (say) and sharing it over NFS?
>
> I would avoid installing Guix in a profile, because if things go wrong,
> you may find yourself unable to do anything.  In practice, you can
> always roll-back by hand (it’s simply a matter of switching the
> profiles/per-user/$USER symlink), but still.
>
>> It would be great if $localstatedir could be overridden at runtime or
>> if it could default to whatever the daemon uses.
>
> Actually it can be overridden via the intentionally-undocumented
> NIX_STATE_DIR environment variable (see (guix config).)

Oh, nice.  Installing Guix somewhere into /gnu is actually a pretty good
idea.  I’ll try that and play with NIX_STATE_DIR as well.

>> This would probably work fine if I limited the socket forwarding to just
>> the cluster nodes, because only there user ids are guaranteed to be
>> correct (not on workstations).  On workstations that are not centrally
>> managed this will not work, as the user ids could be arbitrary and it
>> would thus allow anyone to change anyone else’s profile by creating a
>> local account with the appropriate uid.
>
> The only problem would be with ‘guix package’, which you haven’t
> mentioned yet.  :-)  For ‘guix package’ to work,
> /gnu/var/guix/profiles/per-user must be shared read-write (over NFS)
> with correct UID mapping.

Correct.  I haven’t tried ‘guix package’ at all because I just assumed
it would work.

> I think we should have a “Cluster Setup” section in the manual to
> explain all this.  Would you like to give it a try?

Sounds like a good idea.  I can give it a try but I’ll be on vacation
for a while and can only get around to writing in a couple of weeks.
But I think I’m a good candidate for drafting this section, given that
I’ve got a cluster to play with :)

Thanks for your helpful recommendations!

~~ Ricardo