[Nix-dev] [Nix-commits] SVN commit: nix - r30127 - in nixos/trunk/modules: config installer/cd-dvd installer/generations-dir installer/tools installer/tools/nixos-deploy-network misc security services/misc services/monito...

[Shea Levy]

On 11/1/11 11:34 PM, Marc Weber wrote:
> Some points:
> - nix-collect-garbage will collect garbage of the builtins /nix/store
>    path, right?

I'm not exactly sure what you mean here, but I believe 
nix-collect-garbage will respect $NIX_STORE_DIR or the storedir that nix 
was compiled with if $NIX_STORE_DIR is unset.

> - you're case 2 (recovery) could be replaced by introducing a salt
>    such as passing a dummy var to a derivation everything depends on.
>    I agree that there are use cases which this doesn't catch such as
>    other databases (eg change from filesystem based to sqlite) or
>    eventually even debug filesystem issues. Its trivial to mount
>    /dev/X to /nix-test/{var,store}

That's a good point. In most cases the salt will be better, as long as 
you trust the tarballs in your store or remove them all.

> - testing is only important if there are use cases? And several people
>    have used nixpkgs in their $HOME directory in the past so it does
>    matter

No, we need to test nixpkgs with any store dir even if we don't support 
it on NixOS. No one disputes that. My only point is that my only Linux 
is NixOS, so if I want to test nixpkgs in alternate store dirs I need a 
NixOS with alternate store dirs.

>
>    Question: Would user mode linux be an option instead?
>    I mean if you use user mode linux you can reuse hydra binaries.
>    Using user mode linux you can run most test cases on virtualized
>    hardware. The current qemu/kvm based test cases require a dedicated
>    machine.

Probably for the rebuild and testing use cases, for sure. The others, 
not so much.

>
> - About breaking: Yes it will break - but its also easy to fix in most
>    cases. And most cases can be caught by a simple grep command.
>    So we could even create a pro-commit hook or check.

Agreed. I'd be glad to write the commit hook or a NixOS automated test.

>
>> 5. Having multiple stores on a single system, each with paths built
>> using NixOS. Applications of multiple stores might include private
>> stores for sensitive configurations, having different stores with
>> different levels of trust (e.g. one store that only contains
>> locally-built packages that takes precedence in $PATH and such, but
>> another that uses substitutors so you can get stuff done while you're
>> waiting for your local build to finish), allowing non-privileged users
>> to use their own substitutors, etc.
> Can you provide more details? I still don't understand.

These were just some off-the-cuff thoughts, so please don't take them 
too seriously :)

> I mean do you want to use
> /nix/root-store/*  which may contain passwords and which root may only access?

Sure, or even /root/nix/store and /home/shlevy/nix/store. Of course, 
nixos-rebuild would need to be extended to rebuild several 
configurations and we'd have to come up with a way to share information 
between stores.

> /nix/store/* for the rest of the users?
>
> What happens if you start any service which changes user id and tries to
> access its libraries?
>
> So which kind of data do you want to protect? Looks like we should find
> a solution.

These "multiple live stores on one system" ideas require much more work 
than just what I was trying to implement with my changes, and there's no 
pressing need. If I wanted to start work on any of them, I'd definitely 
raise the specific issue on the list before trying to make any changes. 
All that being said, some more details on the ideas I raised:

1. Private info: Passwords, security-related settings, proprietary code 
(e.g. multiple developers sharing a machine working on non-OSS 
projects), etc.
2. Different levels of trust: Other than the general goodwill of mankind 
(which I probably believe in more than most) and the lack of complaint 
from others, I have little assurance that hydra actually builds what it 
claims. That being said, it's an extremely convenient resource. So when 
Firefox gets updated and I just need to use the latest version, I can 
download the substitutor then use it while building in my more trusted 
store. Of course, this is an option where salting would work as well.
3. Users using their own substitutors: I think this should be fairly 
obvious, but if I'm on a shared system but have a nice powerful desktop 
at home, I can set up my own private store and build my configurations 
on my desktop and pull the built results from home without root access.

>
>> 6. Branding. Not a big concern right now, I know, but if NixOS gets big
>> (fingers crossed!) and others want to rebrand it, why not let them use a
>> custom-branded store path?
> What do you mean?
>
> /nix/marc-store/
> /nix/shea-store/

No, a system without the word "nix" in it at all. /mac/osx/store or 
whatever. I was really unserious about this one though :)

> ? I think the strength about nix is sharing. You can share.
> The *branding* is what other distros have to do (duplicate everything
> within a chroot).
>
> Do you have this is mind or is it just a "could be done idea nobody will
> ever actually use?"

The latter, but it crossed my mind so I threw it out there just for fun.

Thanks for the review,
Shea