Ricardo, Thanks for your complete and easy-to-understand response to my inquiries.
> > Can anyone elaborate a little on what are the obstacles to having > > `/gnu` mounted read-write network wide? > > Yes, the primary problem is that the daemon assumes that it is the only thing > writing to the store and the localstatedir. Any modification of profiles and > the store goes through the daemon. > > If so, might this be mitigated using a variant off of "Using the > > Offload Facility" > > (http://www.gnu.org/software/guix/manual/guix.html#Daemon-Offload- > Setu > > p) in which builds would still be offloaded (and thus subject to > > coordination), with the elimination of the need for " Missing > > prerequisites for the build are copied over SSH to the target machine, > > which then proceeds with the build; upon success the output(s) of the > > build are copied back to the initial machine" since they would be done > > through the shared file system? > > Something like that has been suggested before: if the daemon were to > accept authenticated connections from the outside rather than to just listen > on a local socket we could have remote guix clients connecting to the central > daemon. Hmm. So, for now, I could just teach users to, i.e., `ssh ${USER}@${GUIX_HOST} /path/to/guix package -r lua -i guile guile-cairo` and contrive for GUIX_HOST to be defined for them. Or, wrap it up even further, and contrive for everyone to have the following in their env: alias guixpkg='ssh ${USER}@${GUIX_HOST} /path/to/guix package' ?? > > Do I understand correctly that in your setup, Ricardo, that absolutely > > no `guix` commands are executed on any host other than the "single > > dedicated server". What about `guix environment p1 p2 p3` when p1 p2 > > p3 are already available in /gnu. If I understand correctly, in such > > a case, nothing need be written to /gnu... and so should not present > > any challenge to running guix off a shared mount. Or am I missing an > > aspect of what is going on? > > This is correct. Our needs are rather simple, so people don’t use any of the > guix commands on their local machines, nor on the cluster nodes. > This is not as inconvenient as this may seem when profiles don’t change > often, but it is of course a serious limitation. My first goal was to replace > traditional software *packaging* (because that’s what affected my work as a > sysadmin); the next goal is to allow users to conveniently perform software > *management*. At the moment this requires users to log on to the guix > management host (or to ask a sysadmin to perform the changes for them). I totally get your priorities. Thanks for the reveal! Are these also the priorities of the GnuSD project, do you know? > Currently our users are okay with that, probably to a large part because they > are not yet aware of all the features of Guix. They are only used to > management by sysadmins or manual compilation, so they are not > inconvenienced. > > Ultimately, the correct fix is to allow remote guix clients to communicate > with > a central guix daemon. The daemon does not even need to be aware of > remote connections if guix clients can transparently connect via SSH and send > RPCs to the socket. This is not yet implemented. Sounds great. On the roadmap? > Even then, /gnu would be mounted read-only on all but the management > host, because there would still only be one daemon writing to the store and > the localstatedir – even if it would take requests from multiple remote guix > clients. Agreed. Fingers crossed, and thanks again, ~Malcolm > > ~~ Ricardo
