mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-27 09:23:01 +00:00
Merge pull request #98503 from jtojnar/doc-prompts
This commit is contained in:
commit
6d518ddf77
@ -132,11 +132,11 @@ buildImage {
|
||||
<para>
|
||||
By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this:
|
||||
</para>
|
||||
<screen><![CDATA[
|
||||
$ docker images
|
||||
<screen>
|
||||
<prompt>$ </prompt>docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest 08c791c7846e 48 years ago 25.2MB
|
||||
]]></screen>
|
||||
</screen>
|
||||
<para>
|
||||
You can break binary reproducibility but have a sorted, meaningful <literal>CREATED</literal> column by setting <literal>created</literal> to <literal>now</literal>.
|
||||
</para>
|
||||
@ -152,11 +152,11 @@ pkgs.dockerTools.buildImage {
|
||||
]]></programlisting>
|
||||
<para>
|
||||
and now the Docker CLI will display a reasonable date and sort the images as expected:
|
||||
<screen><![CDATA[
|
||||
$ docker images
|
||||
<screen>
|
||||
<prompt>$ </prompt>docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest de2bf4786de6 About a minute ago 25.2MB
|
||||
]]></screen>
|
||||
</screen>
|
||||
however, the produced images will not be binary reproducible.
|
||||
</para>
|
||||
</example>
|
||||
|
@ -38,8 +38,7 @@ buildContainer {
|
||||
|
||||
readonly = false; <co xml:id='ex-ociTools-buildContainer-3' />
|
||||
}
|
||||
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-ociTools-buildContainer-1'>
|
||||
<para>
|
||||
|
@ -22,10 +22,10 @@
|
||||
</para>
|
||||
<para>
|
||||
In order to set this up, you first have to <link xlink:href="https://its.uiowa.edu/support/article/102186">download the <literal>.cr</literal> file from the Netscaler Gateway</link>. After that you can configure the <command>selfservice</command> like this:
|
||||
<screen>
|
||||
<prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
|
||||
<prompt>$ </prompt>selfservice
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
|
||||
<prompt>$ </prompt>selfservice
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -18,10 +18,13 @@
|
||||
includes all available plugins. To make use of this functionality, use an
|
||||
overlay or directly install an expression that overrides its configuration,
|
||||
such as
|
||||
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
|
||||
<programlisting>
|
||||
rxvt-unicode.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
plugins = with availablePlugins; [ perls resize-font vtwheel ];
|
||||
}
|
||||
}</programlisting>
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
If the <literal>configure</literal> function returns an attrset without the
|
||||
<literal>plugins</literal> attribute, <literal>availablePlugins</literal>
|
||||
will be used automatically.
|
||||
@ -30,18 +33,22 @@
|
||||
<para>
|
||||
In order to add plugins but also keep all default plugins installed, it is
|
||||
possible to use the following method:
|
||||
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
|
||||
plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
|
||||
};
|
||||
}</programlisting>
|
||||
<programlisting>
|
||||
rxvt-unicode.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To get a list of all the plugins available, open the Nix REPL and run
|
||||
<programlisting>$ nix repl
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix repl
|
||||
:l <nixpkgs>
|
||||
map (p: p.name) pkgs.rxvt-unicode.plugins
|
||||
</programlisting>
|
||||
</screen>
|
||||
Alternatively, if your shell is bash or zsh and have completion enabled,
|
||||
simply type <literal>nixpkgs.rxvt-unicode.plugins.<tab></literal>.
|
||||
</para>
|
||||
@ -53,18 +60,24 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
|
||||
<literal>extraDeps</literal> can be used, for example, to provide
|
||||
<literal>xsel</literal> (a clipboard manager) to the clipboard plugin,
|
||||
without installing it globally:
|
||||
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
|
||||
pluginsDeps = [ xsel ];
|
||||
}
|
||||
}</programlisting>
|
||||
<programlisting>
|
||||
rxvt-unicode.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
pluginsDeps = [ xsel ];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<literal>perlDeps</literal> is a handy way to provide Perl packages to
|
||||
your custom plugins (in <literal>$HOME/.urxvt/ext</literal>). For example,
|
||||
if you need <literal>AnyEvent</literal> you can do:
|
||||
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
|
||||
perlDeps = with perlPackages; [ AnyEvent ];
|
||||
}
|
||||
}</programlisting>
|
||||
<programlisting>
|
||||
rxvt-unicode.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
perlDeps = with perlPackages; [ AnyEvent ];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
</section>
|
||||
@ -90,7 +103,8 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
|
||||
<para>
|
||||
If the plugin is itself a perl package that needs to be imported from
|
||||
other plugins or scripts, add the following passthrough:
|
||||
<programlisting>passthru.perlPackages = [ "self" ];
|
||||
<programlisting>
|
||||
passthru.perlPackages = [ "self" ];
|
||||
</programlisting>
|
||||
This will make the urxvt wrapper pick up the dependency and set up the perl
|
||||
path accordingly.
|
||||
|
@ -209,12 +209,12 @@ Additional information.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
(fetchpatch {
|
||||
name = "CVE-2019-11068.patch";
|
||||
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
|
||||
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
|
||||
})
|
||||
</programlisting>
|
||||
(fetchpatch {
|
||||
name = "CVE-2019-11068.patch";
|
||||
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
|
||||
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
|
||||
})
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.
|
||||
|
@ -72,9 +72,9 @@
|
||||
To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -f "<nixpkgs>" -iA beamPackages.rebar3
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -f "<nixpkgs>" -iA beamPackages.rebar3
|
||||
</screen>
|
||||
</section>
|
||||
|
||||
<section xml:id="packaging-beam-applications">
|
||||
|
@ -8,28 +8,28 @@
|
||||
|
||||
<para>
|
||||
When executing a Perl script, it is possible you get an error such as <literal>./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory</literal>. This happens when the script expects Perl to be installed at <filename>/usr/bin/perl</filename>, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
|
||||
<programlisting>
|
||||
#!/usr/bin/env perl
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
#!/usr/bin/env perl
|
||||
</programlisting>
|
||||
to take the Perl installation from the <literal>PATH</literal> environment variable, or invoke Perl directly with:
|
||||
<screen>
|
||||
<prompt>$ </prompt>perl ./myscript.pl
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>perl ./myscript.pl
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When the script is using a Perl library that is not installed globally, you might get an error such as <literal>Can't locate DB_File.pm in @INC (you may need to install the DB_File module)</literal>. In that case, you can use <command>nix-shell</command> to start an ad-hoc shell with that library installed, for instance:
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you are always using the script in places where <command>nix-shell</command> is available, you can embed the <command>nix-shell</command> invocation in the shebang like this:
|
||||
<programlisting>
|
||||
#!/usr/bin/env nix-shell
|
||||
#! nix-shell -i perl -p perl perlPackages.DBFile
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
#!/usr/bin/env nix-shell
|
||||
#! nix-shell -i perl -p perl perlPackages.DBFile
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
@ -44,30 +44,30 @@
|
||||
<para>
|
||||
Perl packages from CPAN are defined in <link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>, rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from <filename>perl-packages.nix</filename>. However, more complicated packages should be put in a separate file, typically in <filename>pkgs/development/perl-modules</filename>. Here is an example of the former:
|
||||
<programlisting>
|
||||
ClassC3 = buildPerlPackage rec {
|
||||
name = "Class-C3-0.21";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
|
||||
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
ClassC3 = buildPerlPackage rec {
|
||||
name = "Class-C3-0.21";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
|
||||
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
Note the use of <literal>mirror://cpan/</literal>, and the <literal>${name}</literal> in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in <filename>all-packages.nix</filename> through the variable <varname>perlPackages</varname>. For instance, if you have a package that needs <varname>ClassC3</varname>, you would typically write
|
||||
<programlisting>
|
||||
foo = import ../path/to/foo.nix {
|
||||
inherit stdenv fetchurl ...;
|
||||
inherit (perlPackages) ClassC3;
|
||||
};
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
foo = import ../path/to/foo.nix {
|
||||
inherit stdenv fetchurl ...;
|
||||
inherit (perlPackages) ClassC3;
|
||||
};
|
||||
</programlisting>
|
||||
in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
|
||||
</screen>
|
||||
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the start of the name attribute, so the package above is actually called <literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -i perl-Class-C3
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -i perl-Class-C3
|
||||
</screen>
|
||||
(Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
|
||||
</para>
|
||||
|
||||
@ -94,61 +94,61 @@
|
||||
|
||||
<para>
|
||||
<varname>buildPerlPackage</varname> is built on top of <varname>stdenv</varname>, so everything can be customised in the usual way. For instance, the <literal>BerkeleyDB</literal> module has a <varname>preConfigure</varname> hook to generate a configuration file used by <filename>Makefile.PL</filename>:
|
||||
<programlisting>
|
||||
{ buildPerlPackage, fetchurl, db }:
|
||||
<programlisting>
|
||||
{ buildPerlPackage, fetchurl, db }:
|
||||
|
||||
buildPerlPackage rec {
|
||||
name = "BerkeleyDB-0.36";
|
||||
buildPerlPackage rec {
|
||||
name = "BerkeleyDB-0.36";
|
||||
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
|
||||
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
|
||||
};
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
|
||||
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
|
||||
};
|
||||
|
||||
preConfigure = ''
|
||||
echo "LIB = ${db.out}/lib" > config.in
|
||||
echo "INCLUDE = ${db.dev}/include" >> config.in
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
preConfigure = ''
|
||||
echo "LIB = ${db.out}/lib" > config.in
|
||||
echo "INCLUDE = ${db.dev}/include" >> config.in
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Dependencies on other Perl packages can be specified in the <varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname> attributes. If something is exclusively a build-time dependency, use <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
|
||||
<programlisting>
|
||||
ClassC3Componentised = buildPerlPackage rec {
|
||||
name = "Class-C3-Componentised-1.0004";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
|
||||
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
|
||||
};
|
||||
propagatedBuildInputs = [
|
||||
ClassC3 ClassInspector TestException MROCompat
|
||||
];
|
||||
};
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
ClassC3Componentised = buildPerlPackage rec {
|
||||
name = "Class-C3-Componentised-1.0004";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
|
||||
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
|
||||
};
|
||||
propagatedBuildInputs = [
|
||||
ClassC3 ClassInspector TestException MROCompat
|
||||
];
|
||||
};
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On Darwin, if a script has too many <literal>-I<replaceable>dir</replaceable></literal> flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the <literal>shortenPerlShebang</literal> function from the <literal>postInstall</literal> phase:
|
||||
<programlisting>
|
||||
{ stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
|
||||
<programlisting>
|
||||
{ stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
|
||||
|
||||
ImageExifTool = buildPerlPackage {
|
||||
pname = "Image-ExifTool";
|
||||
version = "11.50";
|
||||
ImageExifTool = buildPerlPackage {
|
||||
pname = "Image-ExifTool";
|
||||
version = "11.50";
|
||||
|
||||
src = fetchurl {
|
||||
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
|
||||
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
|
||||
};
|
||||
src = fetchurl {
|
||||
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
|
||||
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
|
||||
};
|
||||
|
||||
buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
|
||||
postInstall = stdenv.lib.optional stdenv.isDarwin ''
|
||||
shortenPerlShebang $out/bin/exiftool
|
||||
'';
|
||||
};
|
||||
</programlisting>
|
||||
buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
|
||||
postInstall = stdenv.lib.optional stdenv.isDarwin ''
|
||||
shortenPerlShebang $out/bin/exiftool
|
||||
'';
|
||||
};
|
||||
</programlisting>
|
||||
This will remove the <literal>-I</literal> flags from the shebang line, rewrite them in the <literal>use lib</literal> form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
|
||||
</para>
|
||||
|
||||
@ -159,27 +159,27 @@
|
||||
Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program <command>nix-generate-from-cpan</command>, which can be installed as follows:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -i nix-generate-from-cpan
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -i nix-generate-from-cpan
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example:
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-generate-from-cpan XML::Simple
|
||||
XMLSimple = buildPerlPackage rec {
|
||||
name = "XML-Simple-2.22";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
|
||||
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
|
||||
};
|
||||
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
|
||||
meta = {
|
||||
description = "An API for simple XML files";
|
||||
license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
|
||||
};
|
||||
};
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-generate-from-cpan XML::Simple
|
||||
XMLSimple = buildPerlPackage rec {
|
||||
name = "XML-Simple-2.22";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
|
||||
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
|
||||
};
|
||||
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
|
||||
meta = {
|
||||
description = "An API for simple XML files";
|
||||
license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
|
||||
};
|
||||
};
|
||||
</screen>
|
||||
The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -18,7 +18,7 @@ mkDerivation { <co xml:id='qt-default-nix-co-2' />
|
||||
|
||||
buildInputs = [ qtbase ]; <co xml:id='qt-default-nix-co-3' />
|
||||
}
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<calloutlist>
|
||||
|
@ -12,14 +12,14 @@
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<![CDATA[$ cd pkgs/servers/monitoring
|
||||
$ mkdir sensu
|
||||
$ cd sensu
|
||||
$ cat > Gemfile
|
||||
<prompt>$ </prompt>cd pkgs/servers/monitoring
|
||||
<prompt>$ </prompt>mkdir sensu
|
||||
<prompt>$ </prompt>cd sensu
|
||||
<prompt>$ </prompt>cat > Gemfile
|
||||
source 'https://rubygems.org'
|
||||
gem 'sensu'
|
||||
$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
|
||||
$ cat > default.nix
|
||||
<prompt>$ </prompt>$(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
|
||||
<prompt>$ </prompt>cat > default.nix
|
||||
{ lib, bundlerEnv, ruby }:
|
||||
|
||||
bundlerEnv rec {
|
||||
@ -37,7 +37,7 @@ bundlerEnv rec {
|
||||
maintainers = with maintainers; [ theuni ];
|
||||
platforms = platforms.unix;
|
||||
};
|
||||
}]]>
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
@ -49,17 +49,16 @@ bundlerEnv rec {
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<![CDATA[$ cd pkgs/servers/monitoring/sensu
|
||||
$ nix-shell -p bundler --run 'bundle lock --update'
|
||||
$ nix-shell -p bundix --run 'bundix'
|
||||
]]>
|
||||
<prompt>$ </prompt>cd pkgs/servers/monitoring/sensu
|
||||
<prompt>$ </prompt>nix-shell -p bundler --run 'bundle lock --update'
|
||||
<prompt>$ </prompt>nix-shell -p bundix --run 'bundix'
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<programlisting>
|
||||
<![CDATA[{ lib, bundlerApp }:
|
||||
|
||||
bundlerApp {
|
||||
@ -75,7 +74,7 @@ bundlerApp {
|
||||
platforms = platforms.unix;
|
||||
};
|
||||
}]]>
|
||||
</screen>
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.
|
||||
|
@ -44,11 +44,11 @@ texlive.combine {
|
||||
<listitem>
|
||||
<para>
|
||||
You can list packages e.g. by <command>nix repl</command>.
|
||||
<programlisting><![CDATA[
|
||||
$ nix repl
|
||||
nix-repl> :l <nixpkgs>
|
||||
nix-repl> texlive.collection-<TAB>
|
||||
]]></programlisting>
|
||||
<programlisting>
|
||||
<prompt>$ </prompt>nix repl
|
||||
<prompt>nix-repl> </prompt>:l <nixpkgs>
|
||||
<prompt>nix-repl> </prompt>texlive.collection-<keycap function="tab" />
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -67,7 +67,7 @@
|
||||
<para>
|
||||
<command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example,
|
||||
</para>
|
||||
<programlisting>$ nix-env -iA nixpkgs.coreutils.info</programlisting>
|
||||
<screen><prompt>$ </prompt>nix-env -iA nixpkgs.coreutils.info</screen>
|
||||
<para>
|
||||
installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstall</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.
|
||||
</para>
|
||||
|
@ -66,7 +66,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting>
|
||||
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_BROKEN=1</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -92,7 +92,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
For allowing the build of an unsupported package once, you can use an environment variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting>
|
||||
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -122,7 +122,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting>
|
||||
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNFREE=1</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -187,7 +187,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting>
|
||||
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_INSECURE=1</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -240,7 +240,7 @@ self: super:
|
||||
lapackProvider = self.mkl;
|
||||
}
|
||||
}
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
<para>
|
||||
This overlay uses Intel’s MKL library for both BLAS and LAPACK
|
||||
interfaces. Note that the same can be accomplished at runtime
|
||||
@ -248,9 +248,9 @@ self: super:
|
||||
<literal>libblas.so.3</literal> and
|
||||
<literal>liblapack.so.3</literal>. For instance:
|
||||
</para>
|
||||
<programlisting>
|
||||
$ LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
|
||||
</screen>
|
||||
<para>
|
||||
Intel MKL requires an <literal>openmp</literal> implementation
|
||||
when running with multiple processors. By default,
|
||||
@ -288,7 +288,7 @@ assert (!blas.isILP64) && (!lapack.isILP64);
|
||||
stdenv.mkDerivation {
|
||||
...
|
||||
}
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
|
@ -14,18 +14,18 @@
|
||||
<para>
|
||||
You create a container with identifier <literal>foo</literal> as follows:
|
||||
<screen>
|
||||
# nixos-container create foo
|
||||
<prompt># </prompt>nixos-container create <replaceable>foo</replaceable>
|
||||
</screen>
|
||||
This creates the container’s root directory in
|
||||
<filename>/var/lib/containers/foo</filename> and a small configuration file
|
||||
in <filename>/etc/containers/foo.conf</filename>. It also builds the
|
||||
<filename>/var/lib/containers/<replaceable>foo</replaceable></filename> and a small configuration file
|
||||
in <filename>/etc/containers/<replaceable>foo</replaceable>.conf</filename>. It also builds the
|
||||
container’s initial system configuration and stores it in
|
||||
<filename>/nix/var/nix/profiles/per-container/foo/system</filename>. You can
|
||||
<filename>/nix/var/nix/profiles/per-container/<replaceable>foo</replaceable>/system</filename>. You can
|
||||
modify the initial configuration of the container on the command line. For
|
||||
instance, to create a container that has <command>sshd</command> running,
|
||||
with the given public key for <literal>root</literal>:
|
||||
<screen>
|
||||
# nixos-container create foo --config '
|
||||
<prompt># </prompt>nixos-container create <replaceable>foo</replaceable> --config '
|
||||
<xref linkend="opt-services.openssh.enable"/> = true;
|
||||
<link linkend="opt-users.users._name_.openssh.authorizedKeys.keys">users.users.root.openssh.authorizedKeys.keys</link> = ["ssh-dss AAAAB3N…"];
|
||||
'
|
||||
@ -34,7 +34,7 @@
|
||||
as container IP. This behavior can be altered by setting <literal>--host-address</literal> and
|
||||
<literal>--local-address</literal>:
|
||||
<screen>
|
||||
# nixos-container create test --config-file test-container.nix \
|
||||
<prompt># </prompt>nixos-container create test --config-file test-container.nix \
|
||||
--local-address 10.235.1.2 --host-address 10.235.1.1
|
||||
</screen>
|
||||
</para>
|
||||
@ -42,7 +42,7 @@
|
||||
<para>
|
||||
Creating a container does not start it. To start the container, run:
|
||||
<screen>
|
||||
# nixos-container start foo
|
||||
<prompt># </prompt>nixos-container start <replaceable>foo</replaceable>
|
||||
</screen>
|
||||
This command will return as soon as the container has booted and has reached
|
||||
<literal>multi-user.target</literal>. On the host, the container runs within
|
||||
@ -51,7 +51,7 @@
|
||||
Thus, if something went wrong, you can get status info using
|
||||
<command>systemctl</command>:
|
||||
<screen>
|
||||
# systemctl status container@foo
|
||||
<prompt># </prompt>systemctl status container@<replaceable>foo</replaceable>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
@ -59,22 +59,22 @@
|
||||
If the container has started successfully, you can log in as root using the
|
||||
<command>root-login</command> operation:
|
||||
<screen>
|
||||
# nixos-container root-login foo
|
||||
[root@foo:~]#
|
||||
<prompt># </prompt>nixos-container root-login <replaceable>foo</replaceable>
|
||||
<prompt>[root@foo:~]#</prompt>
|
||||
</screen>
|
||||
Note that only root on the host can do this (since there is no
|
||||
authentication). You can also get a regular login prompt using the
|
||||
<command>login</command> operation, which is available to all users on the
|
||||
host:
|
||||
<screen>
|
||||
# nixos-container login foo
|
||||
<prompt># </prompt>nixos-container login <replaceable>foo</replaceable>
|
||||
foo login: alice
|
||||
Password: ***
|
||||
</screen>
|
||||
With <command>nixos-container run</command>, you can execute arbitrary
|
||||
commands in the container:
|
||||
<screen>
|
||||
# nixos-container run foo -- uname -a
|
||||
<prompt># </prompt>nixos-container run <replaceable>foo</replaceable> -- uname -a
|
||||
Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
|
||||
</screen>
|
||||
</para>
|
||||
@ -85,18 +85,18 @@ Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
|
||||
<literal>/var/lib/container/<replaceable>name</replaceable>/etc/nixos/configuration.nix</literal>,
|
||||
and run
|
||||
<screen>
|
||||
# nixos-container update foo
|
||||
<prompt># </prompt>nixos-container update <replaceable>foo</replaceable>
|
||||
</screen>
|
||||
This will build and activate the new configuration. You can also specify a
|
||||
new configuration on the command line:
|
||||
<screen>
|
||||
# nixos-container update foo --config '
|
||||
<prompt># </prompt>nixos-container update <replaceable>foo</replaceable> --config '
|
||||
<xref linkend="opt-services.httpd.enable"/> = true;
|
||||
<xref linkend="opt-services.httpd.adminAddr"/> = "foo@example.org";
|
||||
<xref linkend="opt-networking.firewall.allowedTCPPorts"/> = [ 80 ];
|
||||
'
|
||||
|
||||
# curl http://$(nixos-container show-ip foo)/
|
||||
<prompt># </prompt>curl http://$(nixos-container show-ip <replaceable>foo</replaceable>)/
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">…
|
||||
</screen>
|
||||
However, note that this will overwrite the container’s
|
||||
@ -117,7 +117,7 @@ Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
|
||||
by using <command>systemctl</command> on the container’s service unit. To
|
||||
destroy a container, including its file system, do
|
||||
<screen>
|
||||
# nixos-container destroy foo
|
||||
<prompt># </prompt>nixos-container destroy <replaceable>foo</replaceable>
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -8,7 +8,7 @@
|
||||
<para>
|
||||
You can enter rescue mode by running:
|
||||
<screen>
|
||||
# systemctl rescue</screen>
|
||||
<prompt># </prompt>systemctl rescue</screen>
|
||||
This will eventually give you a single-user root shell. Systemd will stop
|
||||
(almost) all system services. To get out of maintenance mode, just exit from
|
||||
the rescue shell.
|
||||
|
@ -16,12 +16,12 @@
|
||||
disable the use of the binary cache by adding <option>--option
|
||||
use-binary-caches false</option>, e.g.
|
||||
<screen>
|
||||
# nixos-rebuild switch --option use-binary-caches false
|
||||
<prompt># </prompt>nixos-rebuild switch --option use-binary-caches false
|
||||
</screen>
|
||||
If you have an alternative binary cache at your disposal, you can use it
|
||||
instead:
|
||||
<screen>
|
||||
# nixos-rebuild switch --option binary-caches http://my-cache.example.org/
|
||||
<prompt># </prompt>nixos-rebuild switch --option binary-caches <replaceable>http://my-cache.example.org/</replaceable>
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -7,20 +7,20 @@
|
||||
<para>
|
||||
The system can be shut down (and automatically powered off) by doing:
|
||||
<screen>
|
||||
# shutdown
|
||||
<prompt># </prompt>shutdown
|
||||
</screen>
|
||||
This is equivalent to running <command>systemctl poweroff</command>.
|
||||
</para>
|
||||
<para>
|
||||
To reboot the system, run
|
||||
<screen>
|
||||
# reboot
|
||||
<prompt># </prompt>reboot
|
||||
</screen>
|
||||
which is equivalent to <command>systemctl reboot</command>. Alternatively,
|
||||
you can quickly reboot the system using <literal>kexec</literal>, which
|
||||
bypasses the BIOS by directly loading the new kernel into memory:
|
||||
<screen>
|
||||
# systemctl kexec
|
||||
<prompt># </prompt>systemctl kexec
|
||||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
|
@ -20,16 +20,16 @@
|
||||
has booted, you can make the selected configuration the default for
|
||||
subsequent boots:
|
||||
<screen>
|
||||
# /run/current-system/bin/switch-to-configuration boot</screen>
|
||||
<prompt># </prompt>/run/current-system/bin/switch-to-configuration boot</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Second, you can switch to the previous configuration in a running system:
|
||||
<screen>
|
||||
# nixos-rebuild switch --rollback</screen>
|
||||
<prompt># </prompt>nixos-rebuild switch --rollback</screen>
|
||||
This is equivalent to running:
|
||||
<screen>
|
||||
# /nix/var/nix/profiles/system-<replaceable>N</replaceable>-link/bin/switch-to-configuration switch</screen>
|
||||
<prompt># </prompt>/nix/var/nix/profiles/system-<replaceable>N</replaceable>-link/bin/switch-to-configuration switch</screen>
|
||||
where <replaceable>N</replaceable> is the number of the NixOS system
|
||||
configuration. To get a list of the available configurations, do:
|
||||
<screen>
|
||||
|
@ -58,9 +58,9 @@ Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
|
||||
<para>
|
||||
Units can be stopped, started or restarted:
|
||||
<screen>
|
||||
# systemctl stop postgresql.service
|
||||
# systemctl start postgresql.service
|
||||
# systemctl restart postgresql.service
|
||||
<prompt># </prompt>systemctl stop postgresql.service
|
||||
<prompt># </prompt>systemctl start postgresql.service
|
||||
<prompt># </prompt>systemctl restart postgresql.service
|
||||
</screen>
|
||||
These operations are synchronous: they wait until the service has finished
|
||||
starting or stopping (or has failed). Starting a unit will cause the
|
||||
|
@ -39,7 +39,7 @@ c3 - root (0)
|
||||
can terminate a session in a way that ensures that all the session’s
|
||||
processes are gone:
|
||||
<screen>
|
||||
# loginctl terminate-session c3
|
||||
<prompt># </prompt>loginctl terminate-session c3
|
||||
</screen>
|
||||
</para>
|
||||
</chapter>
|
||||
|
@ -25,7 +25,7 @@ xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs
|
||||
and you run <command>nixos-rebuild</command>, specifying your own Nixpkgs
|
||||
tree:
|
||||
<screen>
|
||||
# nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen>
|
||||
<prompt># </prompt>nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -126,13 +126,13 @@ nixpkgs.config.packageOverrides = pkgs:
|
||||
<literal>mellanox</literal> drivers.
|
||||
</para>
|
||||
|
||||
<screen><![CDATA[
|
||||
$ nix-build '<nixpkgs>' -A linuxPackages.kernel.dev
|
||||
$ nix-shell '<nixpkgs>' -A linuxPackages.kernel
|
||||
$ unpackPhase
|
||||
$ cd linux-*
|
||||
$ make -C $dev/lib/modules/*/build M=$(pwd)/drivers/net/ethernet/mellanox modules
|
||||
# insmod ./drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko
|
||||
]]></screen>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-build '<nixpkgs>' -A linuxPackages.kernel.dev
|
||||
<prompt>$ </prompt>nix-shell '<nixpkgs>' -A linuxPackages.kernel
|
||||
<prompt>$ </prompt>unpackPhase
|
||||
<prompt>$ </prompt>cd linux-*
|
||||
<prompt>$ </prompt>make -C $dev/lib/modules/*/build M=$(pwd)/drivers/net/ethernet/mellanox modules
|
||||
<prompt># </prompt>insmod ./drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko
|
||||
</screen>
|
||||
</section>
|
||||
</chapter>
|
||||
|
@ -11,7 +11,7 @@
|
||||
you create an encrypted Ext4 file system on the device
|
||||
<filename>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</filename>:
|
||||
<screen>
|
||||
# cryptsetup luksFormat /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d
|
||||
<prompt># </prompt>cryptsetup luksFormat <replaceable>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</replaceable>
|
||||
|
||||
WARNING!
|
||||
========
|
||||
@ -21,17 +21,17 @@ Are you sure? (Type uppercase yes): YES
|
||||
Enter LUKS passphrase: ***
|
||||
Verify passphrase: ***
|
||||
|
||||
# cryptsetup luksOpen /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d crypted
|
||||
<prompt># </prompt>cryptsetup luksOpen <replaceable>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</replaceable> <replaceable>crypted</replaceable>
|
||||
Enter passphrase for /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d: ***
|
||||
|
||||
# mkfs.ext4 /dev/mapper/crypted
|
||||
<prompt># </prompt>mkfs.ext4 /dev/mapper/<replaceable>crypted</replaceable>
|
||||
</screen>
|
||||
To ensure that this file system is automatically mounted at boot time as
|
||||
<filename>/</filename>, add the following to
|
||||
<filename>configuration.nix</filename>:
|
||||
<programlisting>
|
||||
<link linkend="opt-boot.initrd.luks.devices._name_.device">boot.initrd.luks.devices.crypted.device</link> = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";
|
||||
<xref linkend="opt-fileSystems"/>."/".device = "/dev/mapper/crypted";
|
||||
<link linkend="opt-boot.initrd.luks.devices._name_.device">boot.initrd.luks.devices.crypted.device</link> = "<replaceable>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</replaceable>";
|
||||
<xref linkend="opt-fileSystems"/>."/".device = "/dev/mapper/<replaceable>crypted</replaceable>";
|
||||
</programlisting>
|
||||
Should grub be used as bootloader, and <filename>/boot</filename> is located
|
||||
on an encrypted partition, it is necessary to add the following grub option:
|
||||
@ -45,11 +45,11 @@ Enter passphrase for /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d: ***
|
||||
and add it as a new key to our existing device <filename>/dev/sda2</filename>:
|
||||
|
||||
<screen>
|
||||
# export FIDO2_LABEL="/dev/sda2 @ $HOSTNAME"
|
||||
# fido2luks credential "$FIDO2_LABEL"
|
||||
<prompt># </prompt>export FIDO2_LABEL="<replaceable>/dev/sda2</replaceable> @ $HOSTNAME"
|
||||
<prompt># </prompt>fido2luks credential "$FIDO2_LABEL"
|
||||
f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7
|
||||
|
||||
# fido2luks -i add-key /dev/sda2 f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7
|
||||
<prompt># </prompt>fido2luks -i add-key <replaceable>/dev/sda2</replaceable> <replaceable>f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7</replaceable>
|
||||
Password:
|
||||
Password (again):
|
||||
Old password:
|
||||
@ -60,13 +60,13 @@ Added to key to device /dev/sda2, slot: 2
|
||||
To ensure that this file system is decrypted using the FIDO2 compatible key, add the following to <filename>configuration.nix</filename>:
|
||||
<programlisting>
|
||||
<link linkend="opt-boot.initrd.luks.fido2Support">boot.initrd.luks.fido2Support</link> = true;
|
||||
<link linkend="opt-boot.initrd.luks.devices._name_.fido2.credential">boot.initrd.luks.devices."/dev/sda2".fido2.credential</link> = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";
|
||||
<link linkend="opt-boot.initrd.luks.devices._name_.fido2.credential">boot.initrd.luks.devices."<replaceable>/dev/sda2</replaceable>".fido2.credential</link> = "<replaceable>f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7</replaceable>";
|
||||
</programlisting>
|
||||
|
||||
You can also use the FIDO2 passwordless setup, but for security reasons, you might want to enable it only when your device is PIN protected, such as <link xlink:href="https://trezor.io/">Trezor</link>.
|
||||
|
||||
<programlisting>
|
||||
<link linkend="opt-boot.initrd.luks.devices._name_.fido2.passwordLess">boot.initrd.luks.devices."/dev/sda2".fido2.passwordLess</link> = true;
|
||||
<link linkend="opt-boot.initrd.luks.devices._name_.fido2.passwordLess">boot.initrd.luks.devices."<replaceable>/dev/sda2</replaceable>".fido2.passwordLess</link> = true;
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -62,24 +62,24 @@ uid = 1000;
|
||||
<command>useradd</command>, <command>groupmod</command> and so on. For
|
||||
instance, to create a user account named <literal>alice</literal>:
|
||||
<screen>
|
||||
# useradd -m alice</screen>
|
||||
<prompt># </prompt>useradd -m <replaceable>alice</replaceable></screen>
|
||||
To make all nix tools available to this new user use `su - USER` which opens
|
||||
a login shell (==shell that loads the profile) for given user. This will
|
||||
create the ~/.nix-defexpr symlink. So run:
|
||||
<screen>
|
||||
# su - alice -c "true"</screen>
|
||||
<prompt># </prompt>su - <replaceable>alice</replaceable> -c "true"</screen>
|
||||
The flag <option>-m</option> causes the creation of a home directory for the
|
||||
new user, which is generally what you want. The user does not have an initial
|
||||
password and therefore cannot log in. A password can be set using the
|
||||
<command>passwd</command> utility:
|
||||
<screen>
|
||||
# passwd alice
|
||||
<prompt># </prompt>passwd <replaceable>alice</replaceable>
|
||||
Enter new UNIX password: ***
|
||||
Retype new UNIX password: ***
|
||||
</screen>
|
||||
A user can be deleted using <command>userdel</command>:
|
||||
<screen>
|
||||
# userdel -r alice</screen>
|
||||
<prompt># </prompt>userdel -r <replaceable>alice</replaceable></screen>
|
||||
The flag <option>-r</option> deletes the user’s home directory. Accounts
|
||||
can be modified using <command>usermod</command>. Unix groups can be managed
|
||||
using <command>groupadd</command>, <command>groupmod</command> and
|
||||
|
@ -58,7 +58,7 @@
|
||||
</programlisting>
|
||||
The X server can then be started manually:
|
||||
<screen>
|
||||
# systemctl start display-manager.service
|
||||
<prompt># </prompt>systemctl start display-manager.service
|
||||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
|
@ -57,7 +57,7 @@
|
||||
linkend="ch-configuration"/>. Changes to a module documentation
|
||||
have to be checked to not break building the NixOS manual:
|
||||
</para>
|
||||
<programlisting>$ nix-build nixos/release.nix -A manual</programlisting>
|
||||
<screen><prompt>$ </prompt>nix-build nixos/release.nix -A manual</screen>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</section>
|
||||
|
@ -24,8 +24,8 @@
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
$ cd /path/to/nixpkgs/nixos/doc/manual
|
||||
$ make
|
||||
<prompt>$ </prompt>cd /path/to/nixpkgs/nixos/doc/manual
|
||||
<prompt>$ </prompt>make
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
|
@ -27,13 +27,13 @@ networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";
|
||||
Setup the proxy environment variables in the shell where you are running
|
||||
<literal>nixos-install</literal>.
|
||||
</para>
|
||||
<programlisting>
|
||||
# proxy_url="http://user:password@proxy:port/"
|
||||
# export http_proxy="$proxy_url"
|
||||
# export HTTP_PROXY="$proxy_url"
|
||||
# export https_proxy="$proxy_url"
|
||||
# export HTTPS_PROXY="$proxy_url"
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt># </prompt>proxy_url="http://user:password@proxy:port/"
|
||||
<prompt># </prompt>export http_proxy="$proxy_url"
|
||||
<prompt># </prompt>export HTTP_PROXY="$proxy_url"
|
||||
<prompt># </prompt>export https_proxy="$proxy_url"
|
||||
<prompt># </prompt>export HTTPS_PROXY="$proxy_url"
|
||||
</screen>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
|
@ -325,14 +325,14 @@ sudo /nix/var/nix/profiles/system/bin/switch-to-configuration boot
|
||||
to boot on a USB rescue disk and do something along these lines:
|
||||
</para>
|
||||
<screen>
|
||||
# mkdir root
|
||||
# mount /dev/sdaX root
|
||||
# mkdir root/nixos-root
|
||||
# mv -v root/* root/nixos-root/
|
||||
# mv -v root/nixos-root/old-root/* root/
|
||||
# mv -v root/boot.bak root/boot # We had renamed this by hand earlier
|
||||
# umount root
|
||||
# reboot</screen>
|
||||
<prompt># </prompt>mkdir root
|
||||
<prompt># </prompt>mount /dev/sdaX root
|
||||
<prompt># </prompt>mkdir root/nixos-root
|
||||
<prompt># </prompt>mv -v root/* root/nixos-root/
|
||||
<prompt># </prompt>mv -v root/nixos-root/old-root/* root/
|
||||
<prompt># </prompt>mv -v root/boot.bak root/boot # We had renamed this by hand earlier
|
||||
<prompt># </prompt>umount root
|
||||
<prompt># </prompt>reboot</screen>
|
||||
<para>
|
||||
This may work as is or you might also need to reinstall the boot loader
|
||||
</para>
|
||||
|
@ -67,32 +67,32 @@
|
||||
<literal>nixos-20.03</literal> channel. To see which NixOS channel you’re
|
||||
subscribed to, run the following as root:
|
||||
<screen>
|
||||
# nix-channel --list | grep nixos
|
||||
<prompt># </prompt>nix-channel --list | grep nixos
|
||||
nixos https://nixos.org/channels/nixos-unstable
|
||||
</screen>
|
||||
To switch to a different NixOS channel, do
|
||||
<screen>
|
||||
# nix-channel --add https://nixos.org/channels/<replaceable>channel-name</replaceable> nixos
|
||||
<prompt># </prompt>nix-channel --add https://nixos.org/channels/<replaceable>channel-name</replaceable> nixos
|
||||
</screen>
|
||||
(Be sure to include the <literal>nixos</literal> parameter at the end.) For
|
||||
instance, to use the NixOS 20.03 stable channel:
|
||||
<screen>
|
||||
# nix-channel --add https://nixos.org/channels/nixos-20.03 nixos
|
||||
<prompt># </prompt>nix-channel --add https://nixos.org/channels/nixos-20.03 nixos
|
||||
</screen>
|
||||
If you have a server, you may want to use the “small” channel instead:
|
||||
<screen>
|
||||
# nix-channel --add https://nixos.org/channels/nixos-20.03-small nixos
|
||||
<prompt># </prompt>nix-channel --add https://nixos.org/channels/nixos-20.03-small nixos
|
||||
</screen>
|
||||
And if you want to live on the bleeding edge:
|
||||
<screen>
|
||||
# nix-channel --add https://nixos.org/channels/nixos-unstable nixos
|
||||
<prompt># </prompt>nix-channel --add https://nixos.org/channels/nixos-unstable nixos
|
||||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
You can then upgrade NixOS to the latest version in your chosen channel by
|
||||
running
|
||||
<screen>
|
||||
# nixos-rebuild switch --upgrade
|
||||
<prompt># </prompt>nixos-rebuild switch --upgrade
|
||||
</screen>
|
||||
which is equivalent to the more verbose <literal>nix-channel --update nixos;
|
||||
nixos-rebuild switch</literal>.
|
||||
|
@ -136,13 +136,13 @@
|
||||
<filename>/mnt</filename>:
|
||||
</para>
|
||||
<screen>
|
||||
# nixos-enter --root /mnt
|
||||
<prompt># </prompt>nixos-enter --root /mnt
|
||||
</screen>
|
||||
<para>
|
||||
Run a shell command:
|
||||
</para>
|
||||
<screen>
|
||||
# nixos-enter -c 'ls -l /; cat /proc/mounts'
|
||||
<prompt># </prompt>nixos-enter -c 'ls -l /; cat /proc/mounts'
|
||||
</screen>
|
||||
<para>
|
||||
Run a non-shell command:
|
||||
|
@ -33,7 +33,7 @@
|
||||
<para>
|
||||
This command shows the version of the currently active NixOS configuration.
|
||||
For example:
|
||||
<screen>$ nixos-version
|
||||
<screen><prompt>$ </prompt>nixos-version
|
||||
16.03.1011.6317da4 (Emu)
|
||||
</screen>
|
||||
The version consists of the following elements:
|
||||
@ -111,7 +111,7 @@
|
||||
<para>
|
||||
Show the full SHA1 hash of the Git commit from which this configuration
|
||||
was built, e.g.
|
||||
<screen>$ nixos-version --hash
|
||||
<screen><prompt>$ </prompt>nixos-version --hash
|
||||
6317da40006f6bc2480c6781999c52d88dde2acf
|
||||
</screen>
|
||||
</para>
|
||||
|
@ -69,10 +69,10 @@
|
||||
access this single repository. You need the output of the generate pub file.
|
||||
</para>
|
||||
<para>
|
||||
<programlisting>
|
||||
# sudo ssh-keygen -N '' -t ed25519 -f /run/keys/id_ed25519_my_borg_repo
|
||||
# cat /run/keys/id_ed25519_my_borg_repo
|
||||
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID78zmOyA+5uPG4Ot0hfAy+sLDPU1L4AiIoRYEIVbbQ/ root@nixos</programlisting>
|
||||
<screen>
|
||||
<prompt># </prompt>sudo ssh-keygen -N '' -t ed25519 -f /run/keys/id_ed25519_my_borg_repo
|
||||
<prompt># </prompt>cat /run/keys/id_ed25519_my_borg_repo
|
||||
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID78zmOyA+5uPG4Ot0hfAy+sLDPU1L4AiIoRYEIVbbQ/ root@nixos</screen>
|
||||
</para>
|
||||
<para>
|
||||
Add the following snippet to your NixOS configuration:
|
||||
|
@ -159,9 +159,9 @@ in
|
||||
To switch to a specialised configuration
|
||||
(e.g. <literal>fewJobsManyCores</literal>) at runtime, run:
|
||||
|
||||
<programlisting>
|
||||
# sudo /run/current-system/specialisation/fewJobsManyCores/bin/switch-to-configuration test
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt># </prompt>sudo /run/current-system/specialisation/fewJobsManyCores/bin/switch-to-configuration test
|
||||
</screen>
|
||||
'';
|
||||
type = types.attrsOf (types.submodule (
|
||||
{ ... }: {
|
||||
|
Loading…
Reference in New Issue
Block a user