Nix 2.0 started installing a multi-user setup for macOS by default, and Nix 2.1 was planned to enable it for Linux by default too. There are some known problems with the multi-user Nix installer, though: it breaks under selinux, it breaks if there are existing users in the range of users needed to created, it makes upgrades a bit challenging.
For these reasons Eelco and I are thinking about reverting the “by-default” setting on macOS and Linux and making it single-user by default, and multi-user via opt-in.
This feels big enough to get some feedback on from the community.
Breakage under certain circumstances is certainly very sad, but I feel that the multi user install is much more useful and, from observation of Nix initiates, actually easier to understand than the constraints under which single user installs operate. I’ve had my share of weirdly mangled nix stores with permissions all over the place because of this.
I personally think that multi-user install is the right default. Warnings about the potential breakage and a well-advertised opt-out is the optimal path in my opinion.
I think both of these breakages can be detected by the installer and at least for the IDs, it should be simple to give the installer a different starting point?
Single user Nix has been the source of far more post-installation problems for me. Obviously Nix should be easy to install and upgrade, but these problems aren’t as big as the problems in day-to-day single user usage IMO. We can fallback to single user on systems that we detect we can’t support, like selinux systems, and upgrading seems like a fixable problem. So I think multi-user should be the path forward as often as possible.
IMO the thing that currently makes me to lean towards the single-user mode is that undoing the installation is much simpler - just a rm -rf /nix versus… do we support/have instructions for uninstallation of the multi-user mode at all?
Regarding 'weirdly mangled nix stores with permissions all over the place ', how much does plain multi-user help here? I know that in NixOS, besides multi-user we additionally have /nix/store as a read-only bind mount which really does make it very difficult to make accidental changes to /nix/store. But without the ro bind mount, even if directories in /nix/store are root-owned and chmod’ed to 555, having root permissions overrides the lack of write permission on a directory. Which means running say, a Python script from /nix/store as root will succeed in creating pycache or .pyc files thus corrupting store paths… or am I wrong?
@ElvishJerricco Yes. But if you are running as a normal user, the 555 permissions on directories (which you get regardless of the multi-user mode) will already prevent most accidents, as the app needs to explicitly chmod the directory to have the write permissions in order for the file creation to succeed (and most apps like Python won’t). But as a root the explicit chmod isn’t needed and the file creation succeeds regardless.
Currently, none of the expected nixpkgs.foo CLI stuff works with Nix 2.0 by default with a multi-user install, but it does with single-user. I wouldn’t consider it a blocker to making multi-user the default, since the nix manual currently avoids the new nix command, but it’s very perplexing.
While I fully agree that a multi-user install is preferable for anybody actively using nix, I don’t think it’s a good default. The default installation method is much more important for new users.
Requiring only a single operation to happen as root for the installation instead of having to run a random daemon as root is a much better experience. And having rm -rf /nix as the uninstall instructions is something pretty unique to nix and a very comforting prospect for people that want to try out nix for the first time.
The fact that the nix installation itself is not managed by anything (unlike eg. nixos) also make a number of things more awkward or more difficult to understand without extra context. While nix upgrade-nix handles part of the complexity of upgrading, updating the service definition and restarting the daemon is still up to the user. Similarly installing nix with nix-env -i nix will result in client/daemon versions getting out of sync which can lead to very strange error messages that are hard to debug (eg. error: unknown serve command 9). While the daemon is generally backwards compatible when protocol versions change the reverse is not always true. Another example is distributed builds, where the user that owns store store becomes important for ssh keys / known_hosts (eg. nixops on darwin). How NIX_PATH should be configured and who owns the default nixpkgs channel also becomes a bit ambiguous for a multi-user installation.
That said we can solve most of these problems and converting a single-user install to multi-user (one way) is actually pretty straightforward, just takes a bit of time depending on the size of the store. Something like that would provide a nice migration path once people have a basic understanding of the tools.
@dezgeg Indeed, python pollutes store paths even with a multi-user setup if something runs as root.
This and @dezgeg’s are some pretty good points. I’d still prefer a world where it’s multi-user by default, but I suppose it could be problematic without significantly more streamlining.
There is yet another possibility: have no default, and force the user to
choose between single-user and multi-user modes, with a small
explanation message stating that single-user mode is easier to uninstall
but multi-user mode may be more pleasant in the long run.
The simplicity of the /nix folder in the single-user install made me first try Nix and get really enthusiastic about it. It meant that adoption was really easy for our team because nothing would stay around had we decided not to use Nix after all (but we did!). I was a bit taken aback when I had to debug a multi-user install of a colleague’s computer where the install broke; I didn’t even know there was a multi-user install available (I think it was on Sierra?) and I wished back the single-user install …
Something else that never works well is on our interns’ computers is when we delete an old intern’s account and create a new one. Somehow we always get permission issues and we uninstall Nix and reinstall, which is quite cumbersome with the multi-user install. I’m sure this would be possible to setup properly, but it’s not really something that is high on our list of work: we want to get other work done and just want to get a running Nix as painlessly as possible.
So I favor the single-user install for our specific situation (I understand it best ) and agree with @Ekleog that having to chose might be best …
I agree that’s a good idea, but it doesn’t absolve us from making a decision.
The current installation instructions result in a non-interactive script (because of the stdin pipe). Meaning we would have to either break running the current installation instructions without extra parameters or still have to decide on a default.
@edolstra and I had a call this my morning / his afternoon to talk about some pros and cons of the various options. The prompting sounds pretty good, and like a nice-to-have, but risky to execute so close to a release.
For this reason, we’ve chosen to default to single-user installations always, but bolster the websites’ advertisement of the multi-user selection switch.
I really appreciate all of the feedback here, maybe in a future (next?) release we can add a prompting for interactive users, to help guide them to a multi-user install.
I don’t think that is true. In UNIX, besides the stdin/stdout/stderr file descriptors, each process has a separate controlling terminal if interactive. So user interaction is possible even if some (or all) of the file descriptors are redirected to pipes/files. For example, this pipeline utilizing vipe from moreutils can pop up an interactive editor just fine:
) and agree with