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

Maarten Hoogendoorn maarten at moretea.nl
Mon Jun 19 11:37:14 CEST 2017


There appear to be sufficient people in favor of this feature. Time for a
RFC?

2017-06-19 11:28 GMT+02:00 Adrien Devresse <Adev at adev.name>:

> 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> 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
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
> _______________________________________________
> nix-dev mailing listnix-dev at lists.science.uu.nlhttps://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/a3e54b1d/attachment.html>


More information about the nix-dev mailing list