Hello Mikhail, Mikhail Kryshen <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: > >>> a) master node running guix-daemon [1] >>> - will "guix gc" destroy guix/current profiles if /home is not >>> mounted on the master node? What if some users have local >>> home directories and some are on nfs? >> >>> [1] >>> https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/ >> >> This is what I would recommend, and as the post suggests, you’ll have to >> make sure home directories are visible to guix-daemon, which means >> having them mounted on the master node. >> >> If you don’t do that, there’s a risk that user-pulled Guixes will be >> reclaimed prematurely, simply because the GC won’t see that they are >> still “live.” > > But ~root is local on each machine, so root-pulled Guix will still not > be protected from gc. True, but in this configuration, only the root account of the master node really matters, and it’s protected from GC. > Btw, is option a) possible on GuixSD? I think so. Why wouldn’t it? >>> b) guix-daemon on every computer >>> - then /gnu/store and /var/guix/profiles will by local and user >>> profiles can be different on every computer, but >>> ~/.config/guix/current will link to nonexistent store item if >>> "guix pull" was invoked by the same user on a different machine. >> >> If this is a cluster, I would definitely recommend option a), which >> provides a single world view, shared storage, etc. > > It's for GNU/Linux workstations in university labs. I want to use Guix > to provide additional software that is not available in required > configuration in the host distro, and also give students an interesting > environment to experiment. > > I decided for now to go with the option b) for performance and > reliability. My previous attempts to deploy large software packages on > NFS (even with FS-Cache enabled) didn't work well. Also, it may be > possible to somehow exploit immutability of the store items to share and > cache them more efficiently. Yes, we use option a) on a cluster at Inria (and Roel and Ricardo have a similar setup at their institutes), and it works pretty well. >From a performance viewpoint, it’s important for the master node to have the store on a local file system, so that things like GC and deduplication run quickly enough—these would be slow over NFS. For the compute nodes, accessing packages over NFS is good enough. > The computers periodically run "guix pull" as root and I want to make > the updated Guix automatically available to all users, but > /usr/local/bin/guix can't be linked to > /root/.config/guix/current/bin/guix as the /root directory is normally > not searchable by other users — another reason to keep pulled Guix > profiles in /var. I workaround this by having the script that runs > "guix pull" to symlink /usr/local/bin/guix directly into the new profile > in /gnu/store. I see. I’ll look into treating ~/.config/guix/current similarly to ~/.guix-profile. That would help for a setup like yours. >> I agree it would be useful (the way we do it on GuixSD is by having >> /etc/profile define INFOPATH systematically, for instance), but there’s >> no clear way to have ~/.config/guix/current/etc/profile define them >> directly. > > It would be useful to have a similar script included in the guix package > to be symlinked into host distro's /etc/profile.d We could do that, though it wouldn’t help much: you’d have to add one line to /etc/profile instead of adding two lines, essentially. Thanks, Ludo’.
