[Nix-dev] In multi-user Nix, let the daemon handle creation of GC roots

[Adrien Devresse]

> Note, sharing /nix is already not really possible because the metadata
> is stored in sqlite and its locking does not play nice with nfs. (*)

Sharing is possible if you use a distributed file system that handle
consistency correctly, like GPFS, Lustre or similar.

We use Nix in shared model in production everyday in my organization.


> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.

It is not really an issue. It could be done the same way it is done
currently. The client does the GC management if configured in single
user mode, or does it through the daemon if configure in multi user mode.

The strong point here is that only ONE user should write to /nix :
- Yourself in single user mode
- The nix-daemon in multi user mode.

This is not the case currently.

>
> The features that come to mind:
> - Allows later implementing policy about GC roots/space consumption
> - Allows avoiding complicated locking around doing GC
> - Allows /nix to be put on network storage transparently
> - Allows /nix to be shared between containers transparently
>
> The network-storage-/nix use case may be the most important, since there
> seems to be a lot of people who want to put /nix on NFS.
>
> Thoughts? Has this been considered?

I strongly support your idea.

The roots / profile implementation is currently hacky, not really
reliable, and potentially a security issue.


Regards,
Adev


Le 18. 06. 17 à 07:43, Wout Mertens a écrit :
>
> Note, sharing /nix is already not really possible because the metadata
> is stored in sqlite and its locking does not play nice with nfs. (*)
>
> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.
>
> However, you can totally share /nix between multiple hosts, you just
> have to pinkie-promise not to write to it from multiple hosts at the
> same time.
>
> Wout.
>
> (*): the reason is that fnctl() locking is broken on many
> implementations. If this testing
> project https://sourceforge.net/projects/locktests/files/?source=navbar says
> it's not broken, you can totally use nix on nfs.
>
> On Sun, 18 Jun 2017, 5:10 AM , <sbaugh at catern.com
> <mailto:sbaugh at catern.com>> wrote:
>
>
>     My understanding is that currently GC roots (symlinks in
>     profiles/gcroots) are created and deleted directly by the various Nix
>     tools, even in multi-user configurations. (whether on NixOS or on
>     another Linux distribution)
>
>     It seems to me that it would be useful for the daemon to handle making
>     GC roots, and forbid users to directly create GC roots.
>
>     The features that come to mind:
>     - Allows later implementing policy about GC roots/space consumption
>     - Allows avoiding complicated locking around doing GC
>     - Allows /nix to be put on network storage transparently
>     - Allows /nix to be shared between containers transparently
>
>     The network-storage-/nix use case may be the most important, since
>     there
>     seems to be a lot of people who want to put /nix on NFS.
>
>     Thoughts? Has this been considered?
>
>     Thanks for Nix!
>
>     _______________________________________________
>     nix-dev mailing list
>     nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
>     https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170619/a7e7cb62/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170619/a7e7cb62/attachment-0001.sig>