From f04db6d3e7e6da7d843496ae1e65f25e98ccf8ce Mon Sep 17 00:00:00 2001 From: Nikolay Amiantov Date: Wed, 26 Aug 2015 19:48:42 +0300 Subject: buildFHS*Env: add documentation --- doc/functions.xml | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) (limited to 'doc/functions.xml') diff --git a/doc/functions.xml b/doc/functions.xml index aec8a57c21a9..3e4ac3f3c6b1 100644 --- a/doc/functions.xml +++ b/doc/functions.xml @@ -155,4 +155,119 @@ c = lib.makeOverridable f { a = 1; b = 2; } + +
+ buildFHSChrootEnv/buildFHSUserEnv + + + buildFHSChrootEnv and + buildFHSUserEnv provide a way to build and run + FHS-compatible lightweight sandboxes. They get their own isolated root with + binded /nix/store, so their footprint in terms of disk + space needed is quite small. This allows one to run software which is hard or + unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, + games distributed as tarballs, software with integrity checking and/or external + self-updated binaries. + + + + buildFHSChrootEnv allows to create persistent + environments, which can be constructed, deconstructed and entered by + multiple users at once. A downside is that it requires + root access for both those who create and destroy and + those who enter it. It can be useful to create environments for daemons that + one can enter and observe. + + + + buildFHSUserEnv uses Linux namespaces feature to create + temporary lightweight environments which are destroyed after all child + processes exit. It does not require root access, and can be useful to create + sandboxes and wrap applications. + + + + Those functions both rely on buildFHSEnv, which creates + an actual directory structure given a list of necessary packages and extra + build commands. + buildFHSChrootEnv and buildFHSUserEnv + both accept those arguments which are passed to + buildFHSEnv: + + + + + name + + Environment name. + + + + targetPkgs + + Packages to be installed for the main host's architecture + (i.e. x86_64 on x86_64 installations). + + + + multiPkgs + + Packages to be installed for all architectures supported by + a host (i.e. i686 and x86_64 on x86_64 installations). + + + + extraBuildCommands + + Additional commands to be executed for finalizing the + directory structure. + + + + extraBuildCommandsMulti + + Like extraBuildCommandsMulti, but + executed only on multilib architectures. + + + + + Additionally, buildFHSUserEnv accepts + runScript parameter, which is a command that would be + executed inside the sandbox and passed all the command line arguments. It + default to bash. + One can create a simple environment using a shell.nix + like that: + + + {} }: + +(pkgs.buildFHSUserEnv { + name = "simple-x11-env"; + targetPkgs = pkgs: (with pkgs; + [ udev + alsaLib + ]) ++ (with pkgs.xlibs; + [ libX11 + libXcursor + libXrandr + ]); + multiPkgs = pkgs: (with pkgs; + [ udev + alsaLib + ]) ++ (with []; + runScript = "bash"; +}).env +]]> + + + Running nix-shell would then drop you into a shell with + these libraries and binaries available. You can use this to run + closed-source applications which expect FHS structure without hassles: + simply change runScript to the application path, + e.g. ./bin/start.sh -- relative paths are supported. + +
+ -- cgit 1.4.1