···
159
+
<section xml:id="sec-fhs-environments">
160
+
<title>buildFHSChrootEnv/buildFHSUserEnv</title>
163
+
<function>buildFHSChrootEnv</function> and
164
+
<function>buildFHSUserEnv</function> provide a way to build and run
165
+
FHS-compatible lightweight sandboxes. They get their own isolated root with
166
+
binded <filename>/nix/store</filename>, so their footprint in terms of disk
167
+
space needed is quite small. This allows one to run software which is hard or
168
+
unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
169
+
games distributed as tarballs, software with integrity checking and/or external
170
+
self-updated binaries.
174
+
<function>buildFHSChrootEnv</function> allows to create persistent
175
+
environments, which can be constructed, deconstructed and entered by
176
+
multiple users at once. A downside is that it requires
177
+
<literal>root</literal> access for both those who create and destroy and
178
+
those who enter it. It can be useful to create environments for daemons that
179
+
one can enter and observe.
183
+
<function>buildFHSUserEnv</function> uses Linux namespaces feature to create
184
+
temporary lightweight environments which are destroyed after all child
185
+
processes exit. It does not require root access, and can be useful to create
186
+
sandboxes and wrap applications.
190
+
Those functions both rely on <function>buildFHSEnv</function>, which creates
191
+
an actual directory structure given a list of necessary packages and extra
193
+
<function>buildFHSChrootEnv</function> and <function>buildFHSUserEnv</function>
194
+
both accept those arguments which are passed to
195
+
<function>buildFHSEnv</function>:
200
+
<term><literal>name</literal></term>
202
+
<listitem><para>Environment name.</para></listitem>
206
+
<term><literal>targetPkgs</literal></term>
208
+
<listitem><para>Packages to be installed for the main host's architecture
209
+
(i.e. x86_64 on x86_64 installations).</para></listitem>
213
+
<term><literal>multiPkgs</literal></term>
215
+
<listitem><para>Packages to be installed for all architectures supported by
216
+
a host (i.e. i686 and x86_64 on x86_64 installations).</para></listitem>
220
+
<term><literal>extraBuildCommands</literal></term>
222
+
<listitem><para>Additional commands to be executed for finalizing the
223
+
directory structure.</para></listitem>
227
+
<term><literal>extraBuildCommandsMulti</literal></term>
229
+
<listitem><para>Like <literal>extraBuildCommandsMulti</literal>, but
230
+
executed only on multilib architectures.</para></listitem>
235
+
Additionally, <function>buildFHSUserEnv</function> accepts
236
+
<literal>runScript</literal> parameter, which is a command that would be
237
+
executed inside the sandbox and passed all the command line arguments. It
238
+
default to <literal>bash</literal>.
239
+
One can create a simple environment using a <literal>shell.nix</literal>
243
+
<programlisting><![CDATA[
244
+
{ pkgs ? import <nixpkgs> {} }:
246
+
(pkgs.buildFHSUserEnv {
247
+
name = "simple-x11-env";
248
+
targetPkgs = pkgs: (with pkgs;
251
+
]) ++ (with pkgs.xlibs;
256
+
multiPkgs = pkgs: (with pkgs;
260
+
runScript = "bash";
262
+
]]></programlisting>
265
+
Running <literal>nix-shell</literal> would then drop you into a shell with
266
+
these libraries and binaries available. You can use this to run
267
+
closed-source applications which expect FHS structure without hassles:
268
+
simply change <literal>runScript</literal> to the application path,
269
+
e.g. <filename>./bin/start.sh</filename> -- relative paths are supported.
pyrox.dev