Nix is currently supported on the following platforms: Linux (particularly on x86, x86_64, and PowerPC). Mac OS X, both on Intel and PowerPC. FreeBSD (only tested on Intel). Windows through Cygwin. On Cygwin, Nix must be installed on an NTFS partition. It will not work correctly on a FAT partition. Nix is pretty portable, so it should work on most other Unix platforms as well.

The easiest way to obtain Nix is to download a source distribution. RPMs for Red Hat, SuSE, and Fedora Core are also available. Alternatively, the most recent sources of Nix can be obtained from its Subversion repository. For example, the following command will check out the latest revision into a directory called nix: $ svn checkout https://svn.nixos.org/repos/nix/nix/trunk nix Likewise, specific releases can be obtained from the tags directory of the repository.

The following prerequisites only apply when you build from source. Binary releases (e.g., RPMs) have no prerequisites. A fairly recent version of GCC/G++ is required. Version 2.95 and higher should work. To build this manual and the man-pages you need the xmllint and xsltproc programs, which are part of the libxml2 and libxslt packages, respectively. You also need the DocBook XSL stylesheets and optionally the DocBook 5.0 RELAX NG schemas. Note that these are only required if you modify the manual sources or when you are building from the Subversion repository. To build the parser, very recent versions of Bison and Flex are required. (This is because Nix needs GLR support in Bison and reentrancy support in Flex.) For Bison, you need version 2.3 or higher (1.875 does not work), which can be obtained from the GNU FTP server. For Flex, you need version 2.5.33, which is available on SourceForge. Slightly older versions may also work, but ancient versions like the ubiquitous 2.5.4a won't. Note that these are only required if you modify the parser or when you are building from the Subversion repository. Nix uses Sleepycat's Berkeley DB, CWI's ATerm library and the bzip2 compressor (including the bzip2 library). These are included in the Nix source distribution. If you build from the Subversion repository, you must download them yourself and place them in the externals/ directory. See externals/Makefile.am for the precise URLs of these packages. Alternatively, if you already have them installed, you can use configure's --with-bdb, --with-aterm and --with-bzip2 options to point to their respective locations. Note that Berkeley DB must be version 4.5; other versions may not have compatible database formats.

After unpacking or checking out the Nix sources, issue the following commands: $ ./configure options... $ make $ make install When building from the Subversion repository, these should be preceded by the command: $ ./bootstrap The installation path can be specified by passing the --prefix=prefix to configure. The default installation directory is /nix. You can change this to any location you like. You must have write permission to the prefix path. It is best not to change the installation prefix from its default, since doing so makes it impossible to use pre-built binaries from the standard Nixpkgs channels. If you want to rebuilt the documentation, pass the full path to the DocBook RELAX NG schemas and to the DocBook XSL stylesheets using the --with-docbook-rng=path and --with-docbook-xsl=path options.

RPM packages of Nix can be downloaded from . These RPMs should work for most fairly recent releases of SuSE and Red Hat Linux. They have been known to work work on SuSE Linux 8.1 and 9.0, and Red Hat 9.0. In fact, it should work on any RPM-based Linux distribution based on glibc 2.3 or later. Once downloaded, the RPMs can be installed or upgraded using rpm -U. For example, $ rpm -U nix-0.5pre664-1.i386.rpm The RPMs install into the directory /nix. Nix can be uninstalled using rpm -e nix. After this it will be necessary to manually remove the Nix store and other auxiliary data: $ rm -rf /nix/store $ rm -rf /nix/var

You can install the latest stable version of Nix through Nix itself by subscribing to the channel , or the latest unstable version by subscribing to the channel . You can also do a one-click installation by clicking on the package links at .

Nix has two basic security models. First, it can be used in “single-user mode”, which is similar to what most other package management tools do: there is a single user (typically root) who performs all package management operations. All other users can then use the installed packages, but they cannot perform package management operations themselves. Alternatively, you can configure Nix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software without requiring root privileges. Nix ensures that this is secure. For instance, it’s not possible for one user to overwrite a package used by another user with a Trojan horse.

In single-user mode, all Nix operations that access the database in prefix/var/nix/db or modify the Nix store in prefix/store must be performed under the user ID that owns those directories. This is typically root. (If you install from RPM packages, that’s in fact the default ownership.) However, on single-user machines, it is often convenient to chown those directories to your normal user account so that you don’t have to su to root all the time.

To allow a Nix store to be shared safely among multiple users, it is important that users are not able to run builders that modify the Nix store or database in arbitrary ways, or that interfere with builds started by other users. If they could do so, they could install a Trojan horse in some package and compromise the accounts of other users. To prevent this, the Nix store and database are owned by some privileged user (usually root) and builders are executed under special user accounts (usually named nixbld1, nixbld2, etc.). When a unprivileged user runs a Nix command, actions that operate on the Nix store (such as builds) are forwarded to a Nix daemon running under the owner of the Nix store/database that performs the operation. Multi-user mode has one important limitation: only root can run nix-pull to register the availability of pre-built binaries. However, those registrations are shared by all users, so they still get the benefit from nix-pulls done by root.

The build users are the special UIDs under which builds are performed. They should all be members of the build users group (usually called nixbld). This group should have no other members. The build users should not be members of any other group. Here is a typical /etc/group definition of the build users group with 10 build users: nixbld:!:30000:nixbld1,nixbld2,nixbld3,nixbld4,nixbld5,nixbld6,nixbld7,nixbld8,nixbld9,nixbld10 In this example the nixbld group has UID 30000, but of course it can be anything that doesn’t collide with an existing group. Here is the corresponding part of /etc/passwd: nixbld1:x:30001:65534:Nix build user 1:/var/empty:/noshell nixbld2:x:30002:65534:Nix build user 2:/var/empty:/noshell nixbld3:x:30003:65534:Nix build user 3:/var/empty:/noshell ... nixbld10:x:30010:65534:Nix build user 10:/var/empty:/noshell The home directory of the build users should not exist or should be an empty directory to which they do not have write access. The build users should have write access to the Nix store, but they should not have the right to delete files. Thus the Nix store’s group should be the build users group, and it should have the sticky bit turned on (like /tmp): $ chgrp nixbld /nix/store $ chmod 1777 /nix/store Finally, you should tell Nix to use the build users by specifying the build users group in the build-users-group option in the Nix configuration file (/nix/etc/nix/nix.conf): build-users-group = nixbld

The simplest setup is to let root own the Nix store and database. I.e., $ chown -R root /nix/store /nix/var/nix The Nix daemon should be started as follows (as root): $ nix-worker --daemon You’ll want to put that line somewhere in your system’s boot scripts. To let unprivileged users use the daemon, they should set the NIX_REMOTE environment variable to daemon. So you should put a line like export NIX_REMOTE=daemon into the users’ login scripts.

It is also possible to let the Nix store and database be owned by a non-root user, which should be more secureNote however that even when the Nix daemon runs as root, not that much code is executed as root: Nix expression evaluation is performed by the calling (unprivileged) user, and builds are performed under the special build user accounts. So only the code that accesses the database and starts builds is executed as root.. Typically, this user is a special account called nix, but it can be named anything. It should own the Nix store and database: $ chown -R root /nix/store /nix/var/nix and of course nix-worker --daemon should be started under that user, e.g., $ su - nix -c "exec /nix/bin/nix-worker --daemon" There is a catch, though: non-root users cannot start builds under the build user accounts, since the setuid system call is obviously privileged. To allow a non-root Nix daemon to use the build user feature, it calls a setuid-root helper program, nix-setuid-helper. This program is installed in prefix/libexec/nix-setuid-helper. To set the permissions properly (Nix’s make install doesn’t do this, since we don’t want to ship setuid-root programs out-of-the-box): $ chown root.root /nix/libexec/nix-setuid-helper $ chmod 4755 /nix/libexec/nix-setuid-helper (This example assumes that the Nix binaries are installed in /nix.) Of course, the nix-setuid-helper command should not be usable by just anybody, since then anybody could run commands under the Nix build user accounts. For that reason there is a configuration file /etc/nix-setuid.conf that restricts the use of the helper. This file should be a text file containing precisely two lines, the first being the Nix daemon user and the second being the build users group, e.g., nix nixbld The setuid-helper barfs if it is called by a user other than the one specified on the first line, or if it is asked to execute a build under a user who is not a member of the group specified on the second line. The file /etc/nix-setuid.conf must be owned by root, and must not be group- or world-writable. The setuid-helper barfs if this is not the case.

To limit which users can perform Nix operations, you can use the permissions on the directory /nix/var/nix/daemon-socket. For instance, if you want to restrict the use of Nix to the members of a group called nix-users, do $ chgrp nix-users /nix/var/nix/daemon-socket $ chmod ug=rwx,o= /nix/var/nix/daemon-socket This way, users who are not in the nix-users group cannot connect to the Unix domain socket /nix/var/nix/daemon-socket/socket, so they cannot perform Nix operations.

To use Nix, some environment variables should be set. In particular, PATH should contain the directories prefix/bin and ~/.nix-profile/bin. The first directory contains the Nix tools themselves, while ~/.nix-profile is a symbolic link to the current user environment (an automatically generated package consisting of symlinks to installed packages). The simplest way to set the required environment variables is to include the file prefix/etc/profile.d/nix.sh in your ~/.bashrc (or similar), like this: source prefix/etc/profile.d/nix.sh