nixos docs: format =)
This commit is contained in:
parent
77161de454
commit
eca5c99bf8
@ -3,63 +3,83 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-boot-problems">
|
xml:id="sec-boot-problems">
|
||||||
|
<title>Boot Problems</title>
|
||||||
|
|
||||||
<title>Boot Problems</title>
|
<para>
|
||||||
|
If NixOS fails to boot, there are a number of kernel command line parameters
|
||||||
|
that may help you to identify or fix the issue. You can add these parameters
|
||||||
|
in the GRUB boot menu by pressing “e” to modify the selected boot entry
|
||||||
|
and editing the line starting with <literal>linux</literal>. The following
|
||||||
|
are some useful kernel command line parameters that are recognised by the
|
||||||
|
NixOS boot scripts or by systemd:
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>boot.shell_on_fail</literal>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Start a root shell if something goes wrong in stage 1 of the boot process
|
||||||
|
(the initial ramdisk). This is disabled by default because there is no
|
||||||
|
authentication for the root shell.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>boot.debug1</literal>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Start an interactive shell in stage 1 before anything useful has been
|
||||||
|
done. That is, no modules have been loaded and no file systems have been
|
||||||
|
mounted, except for <filename>/proc</filename> and
|
||||||
|
<filename>/sys</filename>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>boot.trace</literal>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Print every shell command executed by the stage 1 and 2 boot scripts.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>single</literal>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Boot into rescue mode (a.k.a. single user mode). This will cause systemd
|
||||||
|
to start nothing but the unit <literal>rescue.target</literal>, which
|
||||||
|
runs <command>sulogin</command> to prompt for the root password and start
|
||||||
|
a root login shell. Exiting the shell causes the system to continue with
|
||||||
|
the normal boot process.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>systemd.log_level=debug systemd.log_target=console</literal>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Make systemd very verbose and send log messages to the console instead of
|
||||||
|
the journal.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
For more parameters recognised by systemd, see <citerefentry>
|
||||||
|
<refentrytitle>systemd</refentrytitle>
|
||||||
|
<manvolnum>1</manvolnum></citerefentry>.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>If NixOS fails to boot, there are a number of kernel command
|
<para>
|
||||||
line parameters that may help you to identify or fix the issue. You
|
If no login prompts or X11 login screens appear (e.g. due to hanging
|
||||||
can add these parameters in the GRUB boot menu by pressing “e” to
|
dependencies), you can press Alt+ArrowUp. If you’re lucky, this will start
|
||||||
modify the selected boot entry and editing the line starting with
|
rescue mode (described above). (Also note that since most units have a
|
||||||
<literal>linux</literal>. The following are some useful kernel command
|
90-second timeout before systemd gives up on them, the
|
||||||
line parameters that are recognised by the NixOS boot scripts or by
|
<command>agetty</command> login prompts should appear eventually unless
|
||||||
systemd:
|
something is very wrong.)
|
||||||
|
</para>
|
||||||
<variablelist>
|
</section>
|
||||||
|
|
||||||
<varlistentry><term><literal>boot.shell_on_fail</literal></term>
|
|
||||||
<listitem><para>Start a root shell if something goes wrong in
|
|
||||||
stage 1 of the boot process (the initial ramdisk). This is
|
|
||||||
disabled by default because there is no authentication for the
|
|
||||||
root shell.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term><literal>boot.debug1</literal></term>
|
|
||||||
<listitem><para>Start an interactive shell in stage 1 before
|
|
||||||
anything useful has been done. That is, no modules have been
|
|
||||||
loaded and no file systems have been mounted, except for
|
|
||||||
<filename>/proc</filename> and
|
|
||||||
<filename>/sys</filename>.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term><literal>boot.trace</literal></term>
|
|
||||||
<listitem><para>Print every shell command executed by the stage 1
|
|
||||||
and 2 boot scripts.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term><literal>single</literal></term>
|
|
||||||
<listitem><para>Boot into rescue mode (a.k.a. single user mode).
|
|
||||||
This will cause systemd to start nothing but the unit
|
|
||||||
<literal>rescue.target</literal>, which runs
|
|
||||||
<command>sulogin</command> to prompt for the root password and
|
|
||||||
start a root login shell. Exiting the shell causes the system to
|
|
||||||
continue with the normal boot process.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term><literal>systemd.log_level=debug systemd.log_target=console</literal></term>
|
|
||||||
<listitem><para>Make systemd very verbose and send log messages to
|
|
||||||
the console instead of the journal.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
</variablelist>
|
|
||||||
|
|
||||||
For more parameters recognised by systemd, see
|
|
||||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
|
||||||
|
|
||||||
<para>If no login prompts or X11 login screens appear (e.g. due to
|
|
||||||
hanging dependencies), you can press Alt+ArrowUp. If you’re lucky,
|
|
||||||
this will start rescue mode (described above). (Also note that since
|
|
||||||
most units have a 90-second timeout before systemd gives up on them,
|
|
||||||
the <command>agetty</command> login prompts should appear eventually
|
|
||||||
unless something is very wrong.)</para>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
@ -3,60 +3,51 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-nix-gc">
|
xml:id="sec-nix-gc">
|
||||||
|
<title>Cleaning the Nix Store</title>
|
||||||
<title>Cleaning the Nix Store</title>
|
<para>
|
||||||
|
Nix has a purely functional model, meaning that packages are never upgraded
|
||||||
<para>Nix has a purely functional model, meaning that packages are
|
in place. Instead new versions of packages end up in a different location in
|
||||||
never upgraded in place. Instead new versions of packages end up in a
|
the Nix store (<filename>/nix/store</filename>). You should periodically run
|
||||||
different location in the Nix store (<filename>/nix/store</filename>).
|
Nix’s <emphasis>garbage collector</emphasis> to remove old, unreferenced
|
||||||
You should periodically run Nix’s <emphasis>garbage
|
packages. This is easy:
|
||||||
collector</emphasis> to remove old, unreferenced packages. This is
|
|
||||||
easy:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-collect-garbage
|
$ nix-collect-garbage
|
||||||
</screen>
|
</screen>
|
||||||
|
Alternatively, you can use a systemd unit that does the same in the
|
||||||
Alternatively, you can use a systemd unit that does the same in the
|
background:
|
||||||
background:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl start nix-gc.service
|
# systemctl start nix-gc.service
|
||||||
</screen>
|
</screen>
|
||||||
|
You can tell NixOS in <filename>configuration.nix</filename> to run this unit
|
||||||
You can tell NixOS in <filename>configuration.nix</filename> to run
|
automatically at certain points in time, for instance, every night at 03:15:
|
||||||
this unit automatically at certain points in time, for instance, every
|
|
||||||
night at 03:15:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-nix.gc.automatic"/> = true;
|
<xref linkend="opt-nix.gc.automatic"/> = true;
|
||||||
<xref linkend="opt-nix.gc.dates"/> = "03:15";
|
<xref linkend="opt-nix.gc.dates"/> = "03:15";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
The commands above do not remove garbage collector roots, such as old system
|
||||||
<para>The commands above do not remove garbage collector roots, such
|
configurations. Thus they do not remove the ability to roll back to previous
|
||||||
as old system configurations. Thus they do not remove the ability to
|
configurations. The following command deletes old roots, removing the ability
|
||||||
roll back to previous configurations. The following command deletes
|
to roll back to them:
|
||||||
old roots, removing the ability to roll back to them:
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-collect-garbage -d
|
$ nix-collect-garbage -d
|
||||||
</screen>
|
</screen>
|
||||||
You can also do this for specific profiles, e.g.
|
You can also do this for specific profiles, e.g.
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -p /nix/var/nix/profiles/per-user/eelco/profile --delete-generations old
|
$ nix-env -p /nix/var/nix/profiles/per-user/eelco/profile --delete-generations old
|
||||||
</screen>
|
</screen>
|
||||||
Note that NixOS system configurations are stored in the profile
|
Note that NixOS system configurations are stored in the profile
|
||||||
<filename>/nix/var/nix/profiles/system</filename>.</para>
|
<filename>/nix/var/nix/profiles/system</filename>.
|
||||||
|
</para>
|
||||||
<para>Another way to reclaim disk space (often as much as 40% of the
|
<para>
|
||||||
size of the Nix store) is to run Nix’s store optimiser, which seeks
|
Another way to reclaim disk space (often as much as 40% of the size of the
|
||||||
out identical files in the store and replaces them with hard links to
|
Nix store) is to run Nix’s store optimiser, which seeks out identical files
|
||||||
a single copy.
|
in the store and replaces them with hard links to a single copy.
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-store --optimise
|
$ nix-store --optimise
|
||||||
</screen>
|
</screen>
|
||||||
Since this command needs to read the entire Nix store, it can take
|
Since this command needs to read the entire Nix store, it can take quite a
|
||||||
quite a while to finish.</para>
|
while to finish.
|
||||||
|
</para>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,15 +3,13 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-container-networking">
|
xml:id="sec-container-networking">
|
||||||
|
<title>Container Networking</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
<title>Container Networking</title>
|
When you create a container using <literal>nixos-container create</literal>,
|
||||||
|
it gets it own private IPv4 address in the range
|
||||||
<para>When you create a container using <literal>nixos-container
|
<literal>10.233.0.0/16</literal>. You can get the container’s IPv4 address
|
||||||
create</literal>, it gets it own private IPv4 address in the range
|
as follows:
|
||||||
<literal>10.233.0.0/16</literal>. You can get the container’s IPv4
|
|
||||||
address as follows:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container show-ip foo
|
# nixos-container show-ip foo
|
||||||
10.233.4.2
|
10.233.4.2
|
||||||
@ -19,40 +17,39 @@ address as follows:
|
|||||||
$ ping -c1 10.233.4.2
|
$ ping -c1 10.233.4.2
|
||||||
64 bytes from 10.233.4.2: icmp_seq=1 ttl=64 time=0.106 ms
|
64 bytes from 10.233.4.2: icmp_seq=1 ttl=64 time=0.106 ms
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
Networking is implemented using a pair of virtual Ethernet devices. The
|
||||||
<para>Networking is implemented using a pair of virtual Ethernet
|
network interface in the container is called <literal>eth0</literal>, while
|
||||||
devices. The network interface in the container is called
|
the matching interface in the host is called
|
||||||
<literal>eth0</literal>, while the matching interface in the host is
|
<literal>ve-<replaceable>container-name</replaceable></literal> (e.g.,
|
||||||
called <literal>ve-<replaceable>container-name</replaceable></literal>
|
<literal>ve-foo</literal>). The container has its own network namespace and
|
||||||
(e.g., <literal>ve-foo</literal>). The container has its own network
|
the <literal>CAP_NET_ADMIN</literal> capability, so it can perform arbitrary
|
||||||
namespace and the <literal>CAP_NET_ADMIN</literal> capability, so it
|
network configuration such as setting up firewall rules, without affecting or
|
||||||
can perform arbitrary network configuration such as setting up
|
having access to the host’s network.
|
||||||
firewall rules, without affecting or having access to the host’s
|
</para>
|
||||||
network.</para>
|
|
||||||
|
|
||||||
<para>By default, containers cannot talk to the outside network. If
|
|
||||||
you want that, you should set up Network Address Translation (NAT)
|
|
||||||
rules on the host to rewrite container traffic to use your external
|
|
||||||
IP address. This can be accomplished using the following configuration
|
|
||||||
on the host:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
By default, containers cannot talk to the outside network. If you want that,
|
||||||
|
you should set up Network Address Translation (NAT) rules on the host to
|
||||||
|
rewrite container traffic to use your external IP address. This can be
|
||||||
|
accomplished using the following configuration on the host:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.nat.enable"/> = true;
|
<xref linkend="opt-networking.nat.enable"/> = true;
|
||||||
<xref linkend="opt-networking.nat.internalInterfaces"/> = ["ve-+"];
|
<xref linkend="opt-networking.nat.internalInterfaces"/> = ["ve-+"];
|
||||||
<xref linkend="opt-networking.nat.externalInterface"/> = "eth0";
|
<xref linkend="opt-networking.nat.externalInterface"/> = "eth0";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
where <literal>eth0</literal> should be replaced with the desired
|
where <literal>eth0</literal> should be replaced with the desired external
|
||||||
external interface. Note that <literal>ve-+</literal> is a wildcard
|
interface. Note that <literal>ve-+</literal> is a wildcard that matches all
|
||||||
that matches all container interfaces.</para>
|
container interfaces.
|
||||||
|
</para>
|
||||||
<para>If you are using Network Manager, you need to explicitly prevent
|
|
||||||
it from managing container interfaces:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you are using Network Manager, you need to explicitly prevent it from
|
||||||
|
managing container interfaces:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
|
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,32 +3,32 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-containers">
|
xml:id="ch-containers">
|
||||||
|
<title>Container Management</title>
|
||||||
<title>Container Management</title>
|
<para>
|
||||||
|
NixOS allows you to easily run other NixOS instances as
|
||||||
<para>NixOS allows you to easily run other NixOS instances as
|
<emphasis>containers</emphasis>. Containers are a light-weight approach to
|
||||||
<emphasis>containers</emphasis>. Containers are a light-weight
|
virtualisation that runs software in the container at the same speed as in
|
||||||
approach to virtualisation that runs software in the container at the
|
the host system. NixOS containers share the Nix store of the host, making
|
||||||
same speed as in the host system. NixOS containers share the Nix store
|
container creation very efficient.
|
||||||
of the host, making container creation very efficient.</para>
|
</para>
|
||||||
|
<warning>
|
||||||
<warning><para>Currently, NixOS containers are not perfectly isolated
|
<para>
|
||||||
from the host system. This means that a user with root access to the
|
Currently, NixOS containers are not perfectly isolated from the host system.
|
||||||
container can do things that affect the host. So you should not give
|
This means that a user with root access to the container can do things that
|
||||||
container root access to untrusted users.</para></warning>
|
affect the host. So you should not give container root access to untrusted
|
||||||
|
users.
|
||||||
<para>NixOS containers can be created in two ways: imperatively, using
|
</para>
|
||||||
the command <command>nixos-container</command>, and declaratively, by
|
</warning>
|
||||||
specifying them in your <filename>configuration.nix</filename>. The
|
<para>
|
||||||
declarative approach implies that containers get upgraded along with
|
NixOS containers can be created in two ways: imperatively, using the command
|
||||||
your host system when you run <command>nixos-rebuild</command>, which
|
<command>nixos-container</command>, and declaratively, by specifying them in
|
||||||
is often not what you want. By contrast, in the imperative approach,
|
your <filename>configuration.nix</filename>. The declarative approach implies
|
||||||
containers are configured and updated independently from the host
|
that containers get upgraded along with your host system when you run
|
||||||
system.</para>
|
<command>nixos-rebuild</command>, which is often not what you want. By
|
||||||
|
contrast, in the imperative approach, containers are configured and updated
|
||||||
<xi:include href="imperative-containers.xml" />
|
independently from the host system.
|
||||||
<xi:include href="declarative-containers.xml" />
|
</para>
|
||||||
<xi:include href="container-networking.xml" />
|
<xi:include href="imperative-containers.xml" />
|
||||||
|
<xi:include href="declarative-containers.xml" />
|
||||||
|
<xi:include href="container-networking.xml" />
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
@ -3,20 +3,18 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-cgroups">
|
xml:id="sec-cgroups">
|
||||||
|
<title>Control Groups</title>
|
||||||
<title>Control Groups</title>
|
<para>
|
||||||
|
To keep track of the processes in a running system, systemd uses
|
||||||
<para>To keep track of the processes in a running system, systemd uses
|
<emphasis>control groups</emphasis> (cgroups). A control group is a set of
|
||||||
<emphasis>control groups</emphasis> (cgroups). A control group is a
|
processes used to allocate resources such as CPU, memory or I/O bandwidth.
|
||||||
set of processes used to allocate resources such as CPU, memory or I/O
|
There can be multiple control group hierarchies, allowing each kind of
|
||||||
bandwidth. There can be multiple control group hierarchies, allowing
|
resource to be managed independently.
|
||||||
each kind of resource to be managed independently.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>The command <command>systemd-cgls</command> lists all control
|
The command <command>systemd-cgls</command> lists all control groups in the
|
||||||
groups in the <literal>systemd</literal> hierarchy, which is what
|
<literal>systemd</literal> hierarchy, which is what systemd uses to keep
|
||||||
systemd uses to keep track of the processes belonging to each service
|
track of the processes belonging to each service or user session:
|
||||||
or user session:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ systemd-cgls
|
$ systemd-cgls
|
||||||
├─user
|
├─user
|
||||||
@ -34,40 +32,34 @@ $ systemd-cgls
|
|||||||
│ └─2376 dhcpcd --config /nix/store/f8dif8dsi2yaa70n03xir8r653776ka6-dhcpcd.conf
|
│ └─2376 dhcpcd --config /nix/store/f8dif8dsi2yaa70n03xir8r653776ka6-dhcpcd.conf
|
||||||
└─ <replaceable>...</replaceable>
|
└─ <replaceable>...</replaceable>
|
||||||
</screen>
|
</screen>
|
||||||
|
Similarly, <command>systemd-cgls cpu</command> shows the cgroups in the CPU
|
||||||
Similarly, <command>systemd-cgls cpu</command> shows the cgroups in
|
hierarchy, which allows per-cgroup CPU scheduling priorities. By default,
|
||||||
the CPU hierarchy, which allows per-cgroup CPU scheduling priorities.
|
every systemd service gets its own CPU cgroup, while all user sessions are in
|
||||||
By default, every systemd service gets its own CPU cgroup, while all
|
the top-level CPU cgroup. This ensures, for instance, that a thousand
|
||||||
user sessions are in the top-level CPU cgroup. This ensures, for
|
run-away processes in the <literal>httpd.service</literal> cgroup cannot
|
||||||
instance, that a thousand run-away processes in the
|
starve the CPU for one process in the <literal>postgresql.service</literal>
|
||||||
<literal>httpd.service</literal> cgroup cannot starve the CPU for one
|
cgroup. (By contrast, it they were in the same cgroup, then the PostgreSQL
|
||||||
process in the <literal>postgresql.service</literal> cgroup. (By
|
process would get 1/1001 of the cgroup’s CPU time.) You can limit a
|
||||||
contrast, it they were in the same cgroup, then the PostgreSQL process
|
service’s CPU share in <filename>configuration.nix</filename>:
|
||||||
would get 1/1001 of the cgroup’s CPU time.) You can limit a service’s
|
|
||||||
CPU share in <filename>configuration.nix</filename>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.CPUShares = 512;
|
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.CPUShares = 512;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
By default, every cgroup has 1024 CPU shares, so this will halve the CPU
|
||||||
By default, every cgroup has 1024 CPU shares, so this will halve the
|
allocation of the <literal>httpd.service</literal> cgroup.
|
||||||
CPU allocation of the <literal>httpd.service</literal> cgroup.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>There also is a <literal>memory</literal> hierarchy that
|
There also is a <literal>memory</literal> hierarchy that controls memory
|
||||||
controls memory allocation limits; by default, all processes are in
|
allocation limits; by default, all processes are in the top-level cgroup, so
|
||||||
the top-level cgroup, so any service or session can exhaust all
|
any service or session can exhaust all available memory. Per-cgroup memory
|
||||||
available memory. Per-cgroup memory limits can be specified in
|
limits can be specified in <filename>configuration.nix</filename>; for
|
||||||
<filename>configuration.nix</filename>; for instance, to limit
|
instance, to limit <literal>httpd.service</literal> to 512 MiB of RAM
|
||||||
<literal>httpd.service</literal> to 512 MiB of RAM (excluding swap):
|
(excluding swap):
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.MemoryLimit = "512M";
|
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.MemoryLimit = "512M";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
The command <command>systemd-cgtop</command> shows a continuously updated
|
||||||
<para>The command <command>systemd-cgtop</command> shows a
|
list of all cgroups with their CPU and memory usage.
|
||||||
continuously updated list of all cgroups with their CPU and memory
|
</para>
|
||||||
usage.</para>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,14 +3,13 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-declarative-containers">
|
xml:id="sec-declarative-containers">
|
||||||
|
<title>Declarative Container Specification</title>
|
||||||
|
|
||||||
<title>Declarative Container Specification</title>
|
<para>
|
||||||
|
You can also specify containers and their configuration in the host’s
|
||||||
<para>You can also specify containers and their configuration in the
|
<filename>configuration.nix</filename>. For example, the following specifies
|
||||||
host’s <filename>configuration.nix</filename>. For example, the
|
that there shall be a container named <literal>database</literal> running
|
||||||
following specifies that there shall be a container named
|
PostgreSQL:
|
||||||
<literal>database</literal> running PostgreSQL:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
containers.database =
|
containers.database =
|
||||||
{ config =
|
{ config =
|
||||||
@ -20,18 +19,18 @@ containers.database =
|
|||||||
};
|
};
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
If you run <literal>nixos-rebuild switch</literal>, the container will be
|
||||||
|
built. If the container was already running, it will be updated in place,
|
||||||
|
without rebooting. The container can be configured to start automatically by
|
||||||
|
setting <literal>containers.database.autoStart = true</literal> in its
|
||||||
|
configuration.
|
||||||
|
</para>
|
||||||
|
|
||||||
If you run <literal>nixos-rebuild switch</literal>, the container will
|
<para>
|
||||||
be built. If the container was already running, it will be
|
By default, declarative containers share the network namespace of the host,
|
||||||
updated in place, without rebooting. The container can be configured to
|
meaning that they can listen on (privileged) ports. However, they cannot
|
||||||
start automatically by setting <literal>containers.database.autoStart = true</literal>
|
change the network configuration. You can give a container its own network as
|
||||||
in its configuration.</para>
|
follows:
|
||||||
|
|
||||||
<para>By default, declarative containers share the network namespace
|
|
||||||
of the host, meaning that they can listen on (privileged)
|
|
||||||
ports. However, they cannot change the network configuration. You can
|
|
||||||
give a container its own network as follows:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
containers.database = {
|
containers.database = {
|
||||||
<link linkend="opt-containers._name_.privateNetwork">privateNetwork</link> = true;
|
<link linkend="opt-containers._name_.privateNetwork">privateNetwork</link> = true;
|
||||||
@ -39,22 +38,23 @@ containers.database = {
|
|||||||
<link linkend="opt-containers._name_.localAddress">localAddress</link> = "192.168.100.11";
|
<link linkend="opt-containers._name_.localAddress">localAddress</link> = "192.168.100.11";
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This gives the container a private virtual Ethernet interface with IP address
|
||||||
|
<literal>192.168.100.11</literal>, which is hooked up to a virtual Ethernet
|
||||||
|
interface on the host with IP address <literal>192.168.100.10</literal>. (See
|
||||||
|
the next section for details on container networking.)
|
||||||
|
</para>
|
||||||
|
|
||||||
This gives the container a private virtual Ethernet interface with IP
|
<para>
|
||||||
address <literal>192.168.100.11</literal>, which is hooked up to a
|
To disable the container, just remove it from
|
||||||
virtual Ethernet interface on the host with IP address
|
<filename>configuration.nix</filename> and run <literal>nixos-rebuild
|
||||||
<literal>192.168.100.10</literal>. (See the next section for details
|
switch</literal>. Note that this will not delete the root directory of the
|
||||||
on container networking.)</para>
|
container in <literal>/var/lib/containers</literal>. Containers can be
|
||||||
|
destroyed using the imperative method: <literal>nixos-container destroy
|
||||||
<para>To disable the container, just remove it from
|
foo</literal>.
|
||||||
<filename>configuration.nix</filename> and run <literal>nixos-rebuild
|
</para>
|
||||||
switch</literal>. Note that this will not delete the root directory of
|
|
||||||
the container in <literal>/var/lib/containers</literal>. Containers can be
|
|
||||||
destroyed using the imperative method: <literal>nixos-container destroy
|
|
||||||
foo</literal>.</para>
|
|
||||||
|
|
||||||
<para>Declarative containers can be started and stopped using the
|
|
||||||
corresponding systemd service, e.g. <literal>systemctl start
|
|
||||||
container@database</literal>.</para>
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Declarative containers can be started and stopped using the corresponding
|
||||||
|
systemd service, e.g. <literal>systemctl start container@database</literal>.
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,101 +3,85 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-imperative-containers">
|
xml:id="sec-imperative-containers">
|
||||||
|
<title>Imperative Container Management</title>
|
||||||
|
|
||||||
<title>Imperative Container Management</title>
|
<para>
|
||||||
|
We’ll cover imperative container management using
|
||||||
<para>We’ll cover imperative container management using
|
<command>nixos-container</command> first. Be aware that container management
|
||||||
<command>nixos-container</command> first.
|
is currently only possible as <literal>root</literal>.
|
||||||
Be aware that container management is currently only possible
|
</para>
|
||||||
as <literal>root</literal>.</para>
|
|
||||||
|
|
||||||
<para>You create a container with
|
|
||||||
identifier <literal>foo</literal> as follows:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
You create a container with identifier <literal>foo</literal> as follows:
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container create foo
|
# nixos-container create foo
|
||||||
</screen>
|
</screen>
|
||||||
|
This creates the container’s root directory in
|
||||||
This creates the container’s root directory in
|
<filename>/var/lib/containers/foo</filename> and a small configuration file
|
||||||
<filename>/var/lib/containers/foo</filename> and a small configuration
|
in <filename>/etc/containers/foo.conf</filename>. It also builds the
|
||||||
file in <filename>/etc/containers/foo.conf</filename>. It also builds
|
container’s initial system configuration and stores it in
|
||||||
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/foo/system</filename>. You
|
modify the initial configuration of the container on the command line. For
|
||||||
can modify the initial configuration of the container on the command
|
instance, to create a container that has <command>sshd</command> running,
|
||||||
line. For instance, to create a container that has
|
with the given public key for <literal>root</literal>:
|
||||||
<command>sshd</command> running, with the given public key for
|
|
||||||
<literal>root</literal>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container create foo --config '
|
# nixos-container create foo --config '
|
||||||
<xref linkend="opt-services.openssh.enable"/> = true;
|
<xref linkend="opt-services.openssh.enable"/> = true;
|
||||||
<link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">users.extraUsers.root.openssh.authorizedKeys.keys</link> = ["ssh-dss AAAAB3N…"];
|
<link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">users.extraUsers.root.openssh.authorizedKeys.keys</link> = ["ssh-dss AAAAB3N…"];
|
||||||
'
|
'
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
Creating a container does not start it. To start the container, run:
|
||||||
<para>Creating a container does not start it. To start the container,
|
|
||||||
run:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container start foo
|
# nixos-container start foo
|
||||||
</screen>
|
</screen>
|
||||||
|
This command will return as soon as the container has booted and has reached
|
||||||
This command will return as soon as the container has booted and has
|
<literal>multi-user.target</literal>. On the host, the container runs within
|
||||||
reached <literal>multi-user.target</literal>. On the host, the
|
a systemd unit called
|
||||||
container runs within a systemd unit called
|
<literal>container@<replaceable>container-name</replaceable>.service</literal>.
|
||||||
<literal>container@<replaceable>container-name</replaceable>.service</literal>.
|
Thus, if something went wrong, you can get status info using
|
||||||
Thus, if something went wrong, you can get status info using
|
<command>systemctl</command>:
|
||||||
<command>systemctl</command>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl status container@foo
|
# systemctl status container@foo
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
If the container has started successfully, you can log in as root using the
|
||||||
<para>If the container has started successfully, you can log in as
|
<command>root-login</command> operation:
|
||||||
root using the <command>root-login</command> operation:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container root-login foo
|
# nixos-container root-login foo
|
||||||
[root@foo:~]#
|
[root@foo:~]#
|
||||||
</screen>
|
</screen>
|
||||||
|
Note that only root on the host can do this (since there is no
|
||||||
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
|
||||||
authentication). You can also get a regular login prompt using the
|
<command>login</command> operation, which is available to all users on the
|
||||||
<command>login</command> operation, which is available to all users on
|
host:
|
||||||
the host:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container login foo
|
# nixos-container login foo
|
||||||
foo login: alice
|
foo login: alice
|
||||||
Password: ***
|
Password: ***
|
||||||
</screen>
|
</screen>
|
||||||
|
With <command>nixos-container run</command>, you can execute arbitrary
|
||||||
With <command>nixos-container run</command>, you can execute arbitrary
|
commands in the container:
|
||||||
commands in the container:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container run foo -- uname -a
|
# nixos-container run foo -- uname -a
|
||||||
Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
|
Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
There are several ways to change the configuration of the container. First,
|
||||||
<para>There are several ways to change the configuration of the
|
on the host, you can edit
|
||||||
container. First, on the host, you can edit
|
<literal>/var/lib/container/<replaceable>name</replaceable>/etc/nixos/configuration.nix</literal>,
|
||||||
<literal>/var/lib/container/<replaceable>name</replaceable>/etc/nixos/configuration.nix</literal>,
|
and run
|
||||||
and run
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container update foo
|
# nixos-container update foo
|
||||||
</screen>
|
</screen>
|
||||||
|
This will build and activate the new configuration. You can also specify a
|
||||||
This will build and activate the new configuration. You can also
|
new configuration on the command line:
|
||||||
specify a new configuration on the command line:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container update foo --config '
|
# nixos-container update foo --config '
|
||||||
<xref linkend="opt-services.httpd.enable"/> = true;
|
<xref linkend="opt-services.httpd.enable"/> = true;
|
||||||
@ -108,26 +92,25 @@ specify a new configuration on the command line:
|
|||||||
# curl http://$(nixos-container show-ip foo)/
|
# curl http://$(nixos-container show-ip foo)/
|
||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">…
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">…
|
||||||
</screen>
|
</screen>
|
||||||
|
However, note that this will overwrite the container’s
|
||||||
|
<filename>/etc/nixos/configuration.nix</filename>.
|
||||||
|
</para>
|
||||||
|
|
||||||
However, note that this will overwrite the container’s
|
<para>
|
||||||
<filename>/etc/nixos/configuration.nix</filename>.</para>
|
Alternatively, you can change the configuration from within the container
|
||||||
|
itself by running <command>nixos-rebuild switch</command> inside the
|
||||||
<para>Alternatively, you can change the configuration from within the
|
container. Note that the container by default does not have a copy of the
|
||||||
container itself by running <command>nixos-rebuild switch</command>
|
NixOS channel, so you should run <command>nix-channel --update</command>
|
||||||
inside the container. Note that the container by default does not have
|
first.
|
||||||
a copy of the NixOS channel, so you should run <command>nix-channel
|
</para>
|
||||||
--update</command> first.</para>
|
|
||||||
|
|
||||||
<para>Containers can be stopped and started using
|
|
||||||
<literal>nixos-container stop</literal> and <literal>nixos-container
|
|
||||||
start</literal>, respectively, or by using
|
|
||||||
<command>systemctl</command> on the container’s service unit. To
|
|
||||||
destroy a container, including its file system, do
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Containers can be stopped and started using <literal>nixos-container
|
||||||
|
stop</literal> and <literal>nixos-container start</literal>, respectively, or
|
||||||
|
by using <command>systemctl</command> on the container’s service unit. To
|
||||||
|
destroy a container, including its file system, do
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-container destroy foo
|
# nixos-container destroy foo
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,26 +3,20 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-logging">
|
xml:id="sec-logging">
|
||||||
|
<title>Logging</title>
|
||||||
<title>Logging</title>
|
<para>
|
||||||
|
System-wide logging is provided by systemd’s <emphasis>journal</emphasis>,
|
||||||
<para>System-wide logging is provided by systemd’s
|
which subsumes traditional logging daemons such as syslogd and klogd. Log
|
||||||
<emphasis>journal</emphasis>, which subsumes traditional logging
|
entries are kept in binary files in <filename>/var/log/journal/</filename>.
|
||||||
daemons such as syslogd and klogd. Log entries are kept in binary
|
The command <literal>journalctl</literal> allows you to see the contents of
|
||||||
files in <filename>/var/log/journal/</filename>. The command
|
the journal. For example,
|
||||||
<literal>journalctl</literal> allows you to see the contents of the
|
|
||||||
journal. For example,
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ journalctl -b
|
$ journalctl -b
|
||||||
</screen>
|
</screen>
|
||||||
|
shows all journal entries since the last reboot. (The output of
|
||||||
shows all journal entries since the last reboot. (The output of
|
<command>journalctl</command> is piped into <command>less</command> by
|
||||||
<command>journalctl</command> is piped into <command>less</command> by
|
default.) You can use various options and match operators to restrict output
|
||||||
default.) You can use various options and match operators to restrict
|
to messages of interest. For instance, to get all messages from PostgreSQL:
|
||||||
output to messages of interest. For instance, to get all messages
|
|
||||||
from PostgreSQL:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ journalctl -u postgresql.service
|
$ journalctl -u postgresql.service
|
||||||
-- Logs begin at Mon, 2013-01-07 13:28:01 CET, end at Tue, 2013-01-08 01:09:57 CET. --
|
-- Logs begin at Mon, 2013-01-07 13:28:01 CET, end at Tue, 2013-01-08 01:09:57 CET. --
|
||||||
@ -32,21 +26,18 @@ Jan 07 15:44:14 hagbard postgres[2681]: [2-1] LOG: database system is shut down
|
|||||||
Jan 07 15:45:10 hagbard postgres[2532]: [1-1] LOG: database system was shut down at 2013-01-07 15:44:14 CET
|
Jan 07 15:45:10 hagbard postgres[2532]: [1-1] LOG: database system was shut down at 2013-01-07 15:44:14 CET
|
||||||
Jan 07 15:45:13 hagbard postgres[2500]: [1-1] LOG: database system is ready to accept connections
|
Jan 07 15:45:13 hagbard postgres[2500]: [1-1] LOG: database system is ready to accept connections
|
||||||
</screen>
|
</screen>
|
||||||
|
Or to get all messages since the last reboot that have at least a
|
||||||
Or to get all messages since the last reboot that have at least a
|
“critical” severity level:
|
||||||
“critical” severity level:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ journalctl -b -p crit
|
$ journalctl -b -p crit
|
||||||
Dec 17 21:08:06 mandark sudo[3673]: pam_unix(sudo:auth): auth could not identify password for [alice]
|
Dec 17 21:08:06 mandark sudo[3673]: pam_unix(sudo:auth): auth could not identify password for [alice]
|
||||||
Dec 29 01:30:22 mandark kernel[6131]: [1053513.909444] CPU6: Core temperature above threshold, cpu clock throttled (total events = 1)
|
Dec 29 01:30:22 mandark kernel[6131]: [1053513.909444] CPU6: Core temperature above threshold, cpu clock throttled (total events = 1)
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
The system journal is readable by root and by users in the
|
||||||
<para>The system journal is readable by root and by users in the
|
<literal>wheel</literal> and <literal>systemd-journal</literal> groups. All
|
||||||
<literal>wheel</literal> and <literal>systemd-journal</literal>
|
users have a private journal that can be read using
|
||||||
groups. All users have a private journal that can be read using
|
<command>journalctl</command>.
|
||||||
<command>journalctl</command>.</para>
|
</para>
|
||||||
|
</chapter>
|
||||||
</chapter>
|
|
||||||
|
@ -3,16 +3,14 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-maintenance-mode">
|
xml:id="sec-maintenance-mode">
|
||||||
|
<title>Maintenance Mode</title>
|
||||||
|
|
||||||
<title>Maintenance Mode</title>
|
<para>
|
||||||
|
You can enter rescue mode by running:
|
||||||
<para>You can enter rescue mode by running:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl rescue</screen>
|
# systemctl rescue</screen>
|
||||||
|
This will eventually give you a single-user root shell. Systemd will stop
|
||||||
This will eventually give you a single-user root shell. Systemd will
|
(almost) all system services. To get out of maintenance mode, just exit from
|
||||||
stop (almost) all system services. To get out of maintenance mode,
|
the rescue shell.
|
||||||
just exit from the rescue shell.</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,31 +3,25 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-nix-network-issues">
|
xml:id="sec-nix-network-issues">
|
||||||
|
<title>Network Problems</title>
|
||||||
|
|
||||||
<title>Network Problems</title>
|
<para>
|
||||||
|
Nix uses a so-called <emphasis>binary cache</emphasis> to optimise building a
|
||||||
<para>Nix uses a so-called <emphasis>binary cache</emphasis> to
|
package from source into downloading it as a pre-built binary. That is,
|
||||||
optimise building a package from source into downloading it as a
|
whenever a command like <command>nixos-rebuild</command> needs a path in the
|
||||||
pre-built binary. That is, whenever a command like
|
Nix store, Nix will try to download that path from the Internet rather than
|
||||||
<command>nixos-rebuild</command> needs a path in the Nix store, Nix
|
build it from source. The default binary cache is
|
||||||
will try to download that path from the Internet rather than build it
|
<uri>https://cache.nixos.org/</uri>. If this cache is unreachable, Nix
|
||||||
from source. The default binary cache is
|
operations may take a long time due to HTTP connection timeouts. You can
|
||||||
<uri>https://cache.nixos.org/</uri>. If this cache is unreachable,
|
disable the use of the binary cache by adding <option>--option
|
||||||
Nix operations may take a long time due to HTTP connection timeouts.
|
use-binary-caches false</option>, e.g.
|
||||||
You can disable the use of the binary cache by adding <option>--option
|
|
||||||
use-binary-caches false</option>, e.g.
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch --option use-binary-caches false
|
# nixos-rebuild switch --option use-binary-caches false
|
||||||
</screen>
|
</screen>
|
||||||
|
If you have an alternative binary cache at your disposal, you can use it
|
||||||
If you have an alternative binary cache at your disposal, you can use
|
instead:
|
||||||
it instead:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch --option binary-caches http://my-cache.example.org/
|
# nixos-rebuild switch --option binary-caches http://my-cache.example.org/
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,42 +3,33 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-rebooting">
|
xml:id="sec-rebooting">
|
||||||
|
<title>Rebooting and Shutting Down</title>
|
||||||
<title>Rebooting and Shutting Down</title>
|
<para>
|
||||||
|
The system can be shut down (and automatically powered off) by doing:
|
||||||
<para>The system can be shut down (and automatically powered off) by
|
|
||||||
doing:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# shutdown
|
# shutdown
|
||||||
</screen>
|
</screen>
|
||||||
|
This is equivalent to running <command>systemctl poweroff</command>.
|
||||||
This is equivalent to running <command>systemctl
|
</para>
|
||||||
poweroff</command>.</para>
|
<para>
|
||||||
|
To reboot the system, run
|
||||||
<para>To reboot the system, run
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# reboot
|
# reboot
|
||||||
</screen>
|
</screen>
|
||||||
|
which is equivalent to <command>systemctl reboot</command>. Alternatively,
|
||||||
which is equivalent to <command>systemctl reboot</command>.
|
you can quickly reboot the system using <literal>kexec</literal>, which
|
||||||
Alternatively, you can quickly reboot the system using
|
bypasses the BIOS by directly loading the new kernel into memory:
|
||||||
<literal>kexec</literal>, which bypasses the BIOS by directly loading
|
|
||||||
the new kernel into memory:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl kexec
|
# systemctl kexec
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
The machine can be suspended to RAM (if supported) using <command>systemctl
|
||||||
<para>The machine can be suspended to RAM (if supported) using
|
suspend</command>, and suspended to disk using <command>systemctl
|
||||||
<command>systemctl suspend</command>, and suspended to disk using
|
hibernate</command>.
|
||||||
<command>systemctl hibernate</command>.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>These commands can be run by any user who is logged in locally,
|
These commands can be run by any user who is logged in locally, i.e. on a
|
||||||
i.e. on a virtual console or in X11; otherwise, the user is asked for
|
virtual console or in X11; otherwise, the user is asked for authentication.
|
||||||
authentication.</para>
|
</para>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,46 +3,39 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-rollback">
|
xml:id="sec-rollback">
|
||||||
|
<title>Rolling Back Configuration Changes</title>
|
||||||
|
|
||||||
<title>Rolling Back Configuration Changes</title>
|
<para>
|
||||||
|
After running <command>nixos-rebuild</command> to switch to a new
|
||||||
<para>After running <command>nixos-rebuild</command> to switch to a
|
configuration, you may find that the new configuration doesn’t work very
|
||||||
new configuration, you may find that the new configuration doesn’t
|
well. In that case, there are several ways to return to a previous
|
||||||
work very well. In that case, there are several ways to return to a
|
configuration.
|
||||||
previous configuration.</para>
|
</para>
|
||||||
|
|
||||||
<para>First, the GRUB boot manager allows you to boot into any
|
|
||||||
previous configuration that hasn’t been garbage-collected. These
|
|
||||||
configurations can be found under the GRUB submenu “NixOS - All
|
|
||||||
configurations”. This is especially useful if the new configuration
|
|
||||||
fails to boot. After the system has booted, you can make the selected
|
|
||||||
configuration the default for subsequent boots:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
First, the GRUB boot manager allows you to boot into any previous
|
||||||
|
configuration that hasn’t been garbage-collected. These configurations can
|
||||||
|
be found under the GRUB submenu “NixOS - All configurations”. This is
|
||||||
|
especially useful if the new configuration fails to boot. After the system
|
||||||
|
has booted, you can make the selected configuration the default for
|
||||||
|
subsequent boots:
|
||||||
<screen>
|
<screen>
|
||||||
# /run/current-system/bin/switch-to-configuration boot</screen>
|
# /run/current-system/bin/switch-to-configuration boot</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
Second, you can switch to the previous configuration in a running system:
|
||||||
<para>Second, you can switch to the previous configuration in a running
|
|
||||||
system:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch --rollback</screen>
|
# nixos-rebuild switch --rollback</screen>
|
||||||
|
This is equivalent to running:
|
||||||
This is equivalent to running:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# /nix/var/nix/profiles/system-<replaceable>N</replaceable>-link/bin/switch-to-configuration switch</screen>
|
# /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
|
||||||
where <replaceable>N</replaceable> is the number of the NixOS system
|
configuration. To get a list of the available configurations, do:
|
||||||
configuration. To get a list of the available configurations, do:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ ls -l /nix/var/nix/profiles/system-*-link
|
$ ls -l /nix/var/nix/profiles/system-*-link
|
||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
lrwxrwxrwx 1 root root 78 Aug 12 13:54 /nix/var/nix/profiles/system-268-link -> /nix/store/202b...-nixos-13.07pre4932_5a676e4-4be1055
|
lrwxrwxrwx 1 root root 78 Aug 12 13:54 /nix/var/nix/profiles/system-268-link -> /nix/store/202b...-nixos-13.07pre4932_5a676e4-4be1055
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,22 +3,19 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-running">
|
xml:id="ch-running">
|
||||||
|
<title>Administration</title>
|
||||||
<title>Administration</title>
|
<partintro>
|
||||||
|
<para>
|
||||||
<partintro>
|
This chapter describes various aspects of managing a running NixOS system,
|
||||||
<para>This chapter describes various aspects of managing a running
|
such as how to use the <command>systemd</command> service manager.
|
||||||
NixOS system, such as how to use the <command>systemd</command>
|
</para>
|
||||||
service manager.</para>
|
</partintro>
|
||||||
</partintro>
|
<xi:include href="service-mgmt.xml" />
|
||||||
|
<xi:include href="rebooting.xml" />
|
||||||
<xi:include href="service-mgmt.xml" />
|
<xi:include href="user-sessions.xml" />
|
||||||
<xi:include href="rebooting.xml" />
|
<xi:include href="control-groups.xml" />
|
||||||
<xi:include href="user-sessions.xml" />
|
<xi:include href="logging.xml" />
|
||||||
<xi:include href="control-groups.xml" />
|
<xi:include href="cleaning-store.xml" />
|
||||||
<xi:include href="logging.xml" />
|
<xi:include href="containers.xml" />
|
||||||
<xi:include href="cleaning-store.xml" />
|
<xi:include href="troubleshooting.xml" />
|
||||||
<xi:include href="containers.xml" />
|
|
||||||
<xi:include href="troubleshooting.xml" />
|
|
||||||
|
|
||||||
</part>
|
</part>
|
||||||
|
@ -3,26 +3,23 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-systemctl">
|
xml:id="sec-systemctl">
|
||||||
|
<title>Service Management</title>
|
||||||
<title>Service Management</title>
|
<para>
|
||||||
|
In NixOS, all system services are started and monitored using the systemd
|
||||||
<para>In NixOS, all system services are started and monitored using
|
program. Systemd is the “init” process of the system (i.e. PID 1), the
|
||||||
the systemd program. Systemd is the “init” process of the system
|
parent of all other processes. It manages a set of so-called “units”,
|
||||||
(i.e. PID 1), the parent of all other processes. It manages a set of
|
which can be things like system services (programs), but also mount points,
|
||||||
so-called “units”, which can be things like system services
|
swap files, devices, targets (groups of units) and more. Units can have
|
||||||
(programs), but also mount points, swap files, devices, targets
|
complex dependencies; for instance, one unit can require that another unit
|
||||||
(groups of units) and more. Units can have complex dependencies; for
|
must be successfully started before the first unit can be started. When the
|
||||||
instance, one unit can require that another unit must be successfully
|
system boots, it starts a unit named <literal>default.target</literal>; the
|
||||||
started before the first unit can be started. When the system boots,
|
dependencies of this unit cause all system services to be started, file
|
||||||
it starts a unit named <literal>default.target</literal>; the
|
systems to be mounted, swap files to be activated, and so on.
|
||||||
dependencies of this unit cause all system services to be started,
|
</para>
|
||||||
file systems to be mounted, swap files to be activated, and so
|
<para>
|
||||||
on.</para>
|
The command <command>systemctl</command> is the main way to interact with
|
||||||
|
<command>systemd</command>. Without any arguments, it shows the status of
|
||||||
<para>The command <command>systemctl</command> is the main way to
|
active units:
|
||||||
interact with <command>systemd</command>. Without any arguments, it
|
|
||||||
shows the status of active units:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ systemctl
|
$ systemctl
|
||||||
-.mount loaded active mounted /
|
-.mount loaded active mounted /
|
||||||
@ -31,12 +28,10 @@ sshd.service loaded active running SSH Daemon
|
|||||||
graphical.target loaded active active Graphical Interface
|
graphical.target loaded active active Graphical Interface
|
||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
You can ask for detailed status information about a unit, for instance, the
|
||||||
<para>You can ask for detailed status information about a unit, for
|
PostgreSQL database service:
|
||||||
instance, the PostgreSQL database service:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ systemctl status postgresql.service
|
$ systemctl status postgresql.service
|
||||||
postgresql.service - PostgreSQL Server
|
postgresql.service - PostgreSQL Server
|
||||||
@ -56,28 +51,22 @@ Jan 07 15:55:57 hagbard postgres[2390]: [1-1] LOG: database system is ready to
|
|||||||
Jan 07 15:55:57 hagbard postgres[2420]: [1-1] LOG: autovacuum launcher started
|
Jan 07 15:55:57 hagbard postgres[2420]: [1-1] LOG: autovacuum launcher started
|
||||||
Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
|
Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
|
||||||
</screen>
|
</screen>
|
||||||
|
Note that this shows the status of the unit (active and running), all the
|
||||||
Note that this shows the status of the unit (active and running), all
|
processes belonging to the service, as well as the most recent log messages
|
||||||
the processes belonging to the service, as well as the most recent log
|
from the service.
|
||||||
messages from the service.
|
</para>
|
||||||
|
<para>
|
||||||
</para>
|
Units can be stopped, started or restarted:
|
||||||
|
|
||||||
<para>Units can be stopped, started or restarted:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl stop postgresql.service
|
# systemctl stop postgresql.service
|
||||||
# systemctl start postgresql.service
|
# systemctl start postgresql.service
|
||||||
# systemctl restart postgresql.service
|
# systemctl restart postgresql.service
|
||||||
</screen>
|
</screen>
|
||||||
|
These operations are synchronous: they wait until the service has finished
|
||||||
These operations are synchronous: they wait until the service has
|
starting or stopping (or has failed). Starting a unit will cause the
|
||||||
finished starting or stopping (or has failed). Starting a unit will
|
dependencies of that unit to be started as well (if necessary).
|
||||||
cause the dependencies of that unit to be started as well (if
|
</para>
|
||||||
necessary).</para>
|
|
||||||
|
|
||||||
<!-- - cgroups: each service and user session is a cgroup
|
<!-- - cgroups: each service and user session is a cgroup
|
||||||
|
|
||||||
- cgroup resource management -->
|
- cgroup resource management -->
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,35 +3,34 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-nix-store-corruption">
|
xml:id="sec-nix-store-corruption">
|
||||||
|
<title>Nix Store Corruption</title>
|
||||||
|
|
||||||
<title>Nix Store Corruption</title>
|
<para>
|
||||||
|
After a system crash, it’s possible for files in the Nix store to become
|
||||||
<para>After a system crash, it’s possible for files in the Nix store
|
corrupted. (For instance, the Ext4 file system has the tendency to replace
|
||||||
to become corrupted. (For instance, the Ext4 file system has the
|
un-synced files with zero bytes.) NixOS tries hard to prevent this from
|
||||||
tendency to replace un-synced files with zero bytes.) NixOS tries
|
happening: it performs a <command>sync</command> before switching to a new
|
||||||
hard to prevent this from happening: it performs a
|
configuration, and Nix’s database is fully transactional. If corruption
|
||||||
<command>sync</command> before switching to a new configuration, and
|
still occurs, you may be able to fix it automatically.
|
||||||
Nix’s database is fully transactional. If corruption still occurs,
|
</para>
|
||||||
you may be able to fix it automatically.</para>
|
|
||||||
|
|
||||||
<para>If the corruption is in a path in the closure of the NixOS
|
|
||||||
system configuration, you can fix it by doing
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If the corruption is in a path in the closure of the NixOS system
|
||||||
|
configuration, you can fix it by doing
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch --repair
|
# nixos-rebuild switch --repair
|
||||||
</screen>
|
</screen>
|
||||||
|
This will cause Nix to check every path in the closure, and if its
|
||||||
|
cryptographic hash differs from the hash recorded in Nix’s database, the
|
||||||
|
path is rebuilt or redownloaded.
|
||||||
|
</para>
|
||||||
|
|
||||||
This will cause Nix to check every path in the closure, and if its
|
<para>
|
||||||
cryptographic hash differs from the hash recorded in Nix’s database,
|
You can also scan the entire Nix store for corrupt paths:
|
||||||
the path is rebuilt or redownloaded.</para>
|
|
||||||
|
|
||||||
<para>You can also scan the entire Nix store for corrupt paths:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nix-store --verify --check-contents --repair
|
# nix-store --verify --check-contents --repair
|
||||||
</screen>
|
</screen>
|
||||||
|
Any corrupt paths will be redownloaded if they’re available in a binary
|
||||||
Any corrupt paths will be redownloaded if they’re available in a
|
cache; otherwise, they cannot be repaired.
|
||||||
binary cache; otherwise, they cannot be repaired.</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,16 +3,14 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-troubleshooting">
|
xml:id="ch-troubleshooting">
|
||||||
|
<title>Troubleshooting</title>
|
||||||
<title>Troubleshooting</title>
|
<para>
|
||||||
|
This chapter describes solutions to common problems you might encounter when
|
||||||
<para>This chapter describes solutions to common problems you might
|
you manage your NixOS system.
|
||||||
encounter when you manage your NixOS system.</para>
|
</para>
|
||||||
|
<xi:include href="boot-problems.xml" />
|
||||||
<xi:include href="boot-problems.xml" />
|
<xi:include href="maintenance-mode.xml" />
|
||||||
<xi:include href="maintenance-mode.xml" />
|
<xi:include href="rollback.xml" />
|
||||||
<xi:include href="rollback.xml" />
|
<xi:include href="store-corruption.xml" />
|
||||||
<xi:include href="store-corruption.xml" />
|
<xi:include href="network-problems.xml" />
|
||||||
<xi:include href="network-problems.xml" />
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,14 +3,12 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-user-sessions">
|
xml:id="sec-user-sessions">
|
||||||
|
<title>User Sessions</title>
|
||||||
<title>User Sessions</title>
|
<para>
|
||||||
|
Systemd keeps track of all users who are logged into the system (e.g. on a
|
||||||
<para>Systemd keeps track of all users who are logged into the system
|
virtual console or remotely via SSH). The command <command>loginctl</command>
|
||||||
(e.g. on a virtual console or remotely via SSH). The command
|
allows querying and manipulating user sessions. For instance, to list all
|
||||||
<command>loginctl</command> allows querying and manipulating user
|
user sessions:
|
||||||
sessions. For instance, to list all user sessions:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ loginctl
|
$ loginctl
|
||||||
SESSION UID USER SEAT
|
SESSION UID USER SEAT
|
||||||
@ -18,12 +16,10 @@ $ loginctl
|
|||||||
c3 0 root seat0
|
c3 0 root seat0
|
||||||
c4 500 alice
|
c4 500 alice
|
||||||
</screen>
|
</screen>
|
||||||
|
This shows that two users are logged in locally, while another is logged in
|
||||||
This shows that two users are logged in locally, while another is
|
remotely. (“Seats” are essentially the combinations of displays and input
|
||||||
logged in remotely. (“Seats” are essentially the combinations of
|
devices attached to the system; usually, there is only one seat.) To get
|
||||||
displays and input devices attached to the system; usually, there is
|
information about a session:
|
||||||
only one seat.) To get information about a session:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ loginctl session-status c3
|
$ loginctl session-status c3
|
||||||
c3 - root (0)
|
c3 - root (0)
|
||||||
@ -38,16 +34,12 @@ c3 - root (0)
|
|||||||
├─10339 -bash
|
├─10339 -bash
|
||||||
└─10355 w3m nixos.org
|
└─10355 w3m nixos.org
|
||||||
</screen>
|
</screen>
|
||||||
|
This shows that the user is logged in on virtual console 3. It also lists the
|
||||||
This shows that the user is logged in on virtual console 3. It also
|
processes belonging to this session. Since systemd keeps track of this, you
|
||||||
lists the processes belonging to this session. Since systemd keeps
|
can terminate a session in a way that ensures that all the session’s
|
||||||
track of this, you can terminate a session in a way that ensures that
|
processes are gone:
|
||||||
all the session’s processes are gone:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# loginctl terminate-session c3
|
# loginctl terminate-session c3
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,12 +3,11 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-module-abstractions">
|
xml:id="sec-module-abstractions">
|
||||||
|
<title>Abstractions</title>
|
||||||
|
|
||||||
<title>Abstractions</title>
|
<para>
|
||||||
|
If you find yourself repeating yourself over and over, it’s time to
|
||||||
<para>If you find yourself repeating yourself over and over, it’s time
|
abstract. Take, for instance, this Apache HTTP Server configuration:
|
||||||
to abstract. Take, for instance, this Apache HTTP Server configuration:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{
|
{
|
||||||
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
||||||
@ -28,11 +27,9 @@ to abstract. Take, for instance, this Apache HTTP Server configuration:
|
|||||||
];
|
];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
It defines two virtual hosts with nearly identical configuration; the only
|
||||||
It defines two virtual hosts with nearly identical configuration; the
|
difference is that the second one has SSL enabled. To prevent this
|
||||||
only difference is that the second one has SSL enabled. To prevent
|
duplication, we can use a <literal>let</literal>:
|
||||||
this duplication, we can use a <literal>let</literal>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
let
|
let
|
||||||
exampleOrgCommon =
|
exampleOrgCommon =
|
||||||
@ -53,17 +50,16 @@ in
|
|||||||
];
|
];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The <literal>let exampleOrgCommon = <replaceable>...</replaceable></literal>
|
||||||
|
defines a variable named <literal>exampleOrgCommon</literal>. The
|
||||||
|
<literal>//</literal> operator merges two attribute sets, so the
|
||||||
|
configuration of the second virtual host is the set
|
||||||
|
<literal>exampleOrgCommon</literal> extended with the SSL options.
|
||||||
|
</para>
|
||||||
|
|
||||||
The <literal>let exampleOrgCommon =
|
<para>
|
||||||
<replaceable>...</replaceable></literal> defines a variable named
|
You can write a <literal>let</literal> wherever an expression is allowed.
|
||||||
<literal>exampleOrgCommon</literal>. The <literal>//</literal>
|
Thus, you also could have written:
|
||||||
operator merges two attribute sets, so the configuration of the second
|
|
||||||
virtual host is the set <literal>exampleOrgCommon</literal> extended
|
|
||||||
with the SSL options.</para>
|
|
||||||
|
|
||||||
<para>You can write a <literal>let</literal> wherever an expression is
|
|
||||||
allowed. Thus, you also could have written:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{
|
{
|
||||||
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
||||||
@ -73,17 +69,16 @@ allowed. Thus, you also could have written:
|
|||||||
];
|
];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
but not <literal>{ let exampleOrgCommon = <replaceable>...</replaceable>; in
|
||||||
|
<replaceable>...</replaceable>; }</literal> since attributes (as opposed to
|
||||||
|
attribute values) are not expressions.
|
||||||
|
</para>
|
||||||
|
|
||||||
but not <literal>{ let exampleOrgCommon =
|
<para>
|
||||||
<replaceable>...</replaceable>; in <replaceable>...</replaceable>;
|
<emphasis>Functions</emphasis> provide another method of abstraction. For
|
||||||
}</literal> since attributes (as opposed to attribute values) are not
|
instance, suppose that we want to generate lots of different virtual hosts,
|
||||||
expressions.</para>
|
all with identical configuration except for the host name. This can be done
|
||||||
|
as follows:
|
||||||
<para><emphasis>Functions</emphasis> provide another method of
|
|
||||||
abstraction. For instance, suppose that we want to generate lots of
|
|
||||||
different virtual hosts, all with identical configuration except for
|
|
||||||
the host name. This can be done as follows:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{
|
{
|
||||||
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
||||||
@ -101,16 +96,15 @@ the host name. This can be done as follows:
|
|||||||
];
|
];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Here, <varname>makeVirtualHost</varname> is a function that takes a single
|
||||||
|
argument <literal>name</literal> and returns the configuration for a virtual
|
||||||
|
host. That function is then called for several names to produce the list of
|
||||||
|
virtual host configurations.
|
||||||
|
</para>
|
||||||
|
|
||||||
Here, <varname>makeVirtualHost</varname> is a function that takes a
|
<para>
|
||||||
single argument <literal>name</literal> and returns the configuration
|
We can further improve on this by using the function <varname>map</varname>,
|
||||||
for a virtual host. That function is then called for several names to
|
which applies another function to every element in a list:
|
||||||
produce the list of virtual host configurations.</para>
|
|
||||||
|
|
||||||
<para>We can further improve on this by using the function
|
|
||||||
<varname>map</varname>, which applies another function to every
|
|
||||||
element in a list:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{
|
{
|
||||||
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
||||||
@ -120,16 +114,15 @@ element in a list:
|
|||||||
[ "example.org" "example.com" "example.gov" "example.nl" ];
|
[ "example.org" "example.com" "example.gov" "example.nl" ];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
(The function <literal>map</literal> is called a <emphasis>higher-order
|
||||||
|
function</emphasis> because it takes another function as an argument.)
|
||||||
|
</para>
|
||||||
|
|
||||||
(The function <literal>map</literal> is called a
|
<para>
|
||||||
<emphasis>higher-order function</emphasis> because it takes another
|
What if you need more than one argument, for instance, if we want to use a
|
||||||
function as an argument.)</para>
|
different <literal>documentRoot</literal> for each virtual host? Then we can
|
||||||
|
make <varname>makeVirtualHost</varname> a function that takes a
|
||||||
<para>What if you need more than one argument, for instance, if we
|
<emphasis>set</emphasis> as its argument, like this:
|
||||||
want to use a different <literal>documentRoot</literal> for each
|
|
||||||
virtual host? Then we can make <varname>makeVirtualHost</varname> a
|
|
||||||
function that takes a <emphasis>set</emphasis> as its argument, like this:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{
|
{
|
||||||
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
<xref linkend="opt-services.httpd.virtualHosts"/> =
|
||||||
@ -147,10 +140,9 @@ function that takes a <emphasis>set</emphasis> as its argument, like this:
|
|||||||
];
|
];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
But in this case (where every root is a subdirectory of
|
||||||
But in this case (where every root is a subdirectory of
|
<filename>/sites</filename> named after the virtual host), it would have been
|
||||||
<filename>/sites</filename> named after the virtual host), it would
|
shorter to define <varname>makeVirtualHost</varname> as
|
||||||
have been shorter to define <varname>makeVirtualHost</varname> as
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
makeVirtualHost = name:
|
makeVirtualHost = name:
|
||||||
{ hostName = name;
|
{ hostName = name;
|
||||||
@ -158,9 +150,7 @@ makeVirtualHost = name:
|
|||||||
adminAddr = "alice@example.org";
|
adminAddr = "alice@example.org";
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Here, the construct <literal>${<replaceable>...</replaceable>}</literal>
|
||||||
Here, the construct
|
allows the result of an expression to be spliced into a string.
|
||||||
<literal>${<replaceable>...</replaceable>}</literal> allows the result
|
</para>
|
||||||
of an expression to be spliced into a string.</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,22 +3,18 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ad-hoc-network-config">
|
xml:id="ad-hoc-network-config">
|
||||||
|
<title>Ad-Hoc Configuration</title>
|
||||||
|
|
||||||
<title>Ad-Hoc Configuration</title>
|
<para>
|
||||||
|
You can use <xref linkend="opt-networking.localCommands"/> to specify shell
|
||||||
<para>You can use <xref linkend="opt-networking.localCommands"/> to specify
|
commands to be run at the end of <literal>network-setup.service</literal>.
|
||||||
shell commands to be run at the end of
|
This is useful for doing network configuration not covered by the existing
|
||||||
<literal>network-setup.service</literal>. This is useful for doing
|
NixOS modules. For instance, to statically configure an IPv6 address:
|
||||||
network configuration not covered by the existing NixOS modules. For
|
|
||||||
instance, to statically configure an IPv6 address:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.localCommands"/> =
|
<xref linkend="opt-networking.localCommands"/> =
|
||||||
''
|
''
|
||||||
ip -6 addr add 2001:610:685:1::1/64 dev eth0
|
ip -6 addr add 2001:610:685:1::1/64 dev eth0
|
||||||
'';
|
'';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,61 +3,59 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-ad-hoc-packages">
|
xml:id="sec-ad-hoc-packages">
|
||||||
|
<title>Ad-Hoc Package Management</title>
|
||||||
|
|
||||||
<title>Ad-Hoc Package Management</title>
|
<para>
|
||||||
|
With the command <command>nix-env</command>, you can install and uninstall
|
||||||
<para>With the command <command>nix-env</command>, you can install and
|
packages from the command line. For instance, to install Mozilla Thunderbird:
|
||||||
uninstall packages from the command line. For instance, to install
|
|
||||||
Mozilla Thunderbird:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -iA nixos.thunderbird</screen>
|
$ nix-env -iA nixos.thunderbird</screen>
|
||||||
|
If you invoke this as root, the package is installed in the Nix profile
|
||||||
|
<filename>/nix/var/nix/profiles/default</filename> and visible to all users
|
||||||
|
of the system; otherwise, the package ends up in
|
||||||
|
<filename>/nix/var/nix/profiles/per-user/<replaceable>username</replaceable>/profile</filename>
|
||||||
|
and is not visible to other users. The <option>-A</option> flag specifies the
|
||||||
|
package by its attribute name; without it, the package is installed by
|
||||||
|
matching against its package name (e.g. <literal>thunderbird</literal>). The
|
||||||
|
latter is slower because it requires matching against all available Nix
|
||||||
|
packages, and is ambiguous if there are multiple matching packages.
|
||||||
|
</para>
|
||||||
|
|
||||||
If you invoke this as root, the package is installed in the Nix
|
<para>
|
||||||
profile <filename>/nix/var/nix/profiles/default</filename> and visible
|
Packages come from the NixOS channel. You typically upgrade a package by
|
||||||
to all users of the system; otherwise, the package ends up in
|
updating to the latest version of the NixOS channel:
|
||||||
<filename>/nix/var/nix/profiles/per-user/<replaceable>username</replaceable>/profile</filename>
|
|
||||||
and is not visible to other users. The <option>-A</option> flag
|
|
||||||
specifies the package by its attribute name; without it, the package
|
|
||||||
is installed by matching against its package name
|
|
||||||
(e.g. <literal>thunderbird</literal>). The latter is slower because
|
|
||||||
it requires matching against all available Nix packages, and is
|
|
||||||
ambiguous if there are multiple matching packages.</para>
|
|
||||||
|
|
||||||
<para>Packages come from the NixOS channel. You typically upgrade a
|
|
||||||
package by updating to the latest version of the NixOS channel:
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-channel --update nixos
|
$ nix-channel --update nixos
|
||||||
</screen>
|
</screen>
|
||||||
and then running <literal>nix-env -i</literal> again. Other packages
|
and then running <literal>nix-env -i</literal> again. Other packages in the
|
||||||
in the profile are <emphasis>not</emphasis> affected; this is the
|
profile are <emphasis>not</emphasis> affected; this is the crucial difference
|
||||||
crucial difference with the declarative style of package management,
|
with the declarative style of package management, where running
|
||||||
where running <command>nixos-rebuild switch</command> causes all
|
<command>nixos-rebuild switch</command> causes all packages to be updated to
|
||||||
packages to be updated to their current versions in the NixOS channel.
|
their current versions in the NixOS channel. You can however upgrade all
|
||||||
You can however upgrade all packages for which there is a newer
|
packages for which there is a newer version by doing:
|
||||||
version by doing:
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -u '*'
|
$ nix-env -u '*'
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>A package can be uninstalled using the <option>-e</option>
|
<para>
|
||||||
flag:
|
A package can be uninstalled using the <option>-e</option> flag:
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -e thunderbird
|
$ nix-env -e thunderbird
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>Finally, you can roll back an undesirable
|
<para>
|
||||||
<command>nix-env</command> action:
|
Finally, you can roll back an undesirable <command>nix-env</command> action:
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env --rollback
|
$ nix-env --rollback
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para><command>nix-env</command> has many more flags. For details,
|
|
||||||
see the
|
|
||||||
<citerefentry><refentrytitle>nix-env</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
||||||
manpage or the Nix manual.</para>
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
<command>nix-env</command> has many more flags. For details, see the
|
||||||
|
<citerefentry>
|
||||||
|
<refentrytitle>nix-env</refentrytitle>
|
||||||
|
<manvolnum>1</manvolnum></citerefentry> manpage or the Nix manual.
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,43 +3,36 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-custom-packages">
|
xml:id="sec-custom-packages">
|
||||||
|
<title>Adding Custom Packages</title>
|
||||||
|
|
||||||
<title>Adding Custom Packages</title>
|
<para>
|
||||||
|
It’s possible that a package you need is not available in NixOS. In that
|
||||||
<para>It’s possible that a package you need is not available in NixOS.
|
case, you can do two things. First, you can clone the Nixpkgs repository, add
|
||||||
In that case, you can do two things. First, you can clone the Nixpkgs
|
the package to your clone, and (optionally) submit a patch or pull request to
|
||||||
repository, add the package to your clone, and (optionally) submit a
|
have it accepted into the main Nixpkgs repository. This is described in
|
||||||
patch or pull request to have it accepted into the main Nixpkgs
|
detail in the <link
|
||||||
repository. This is described in detail in the <link
|
xlink:href="http://nixos.org/nixpkgs/manual">Nixpkgs
|
||||||
xlink:href="http://nixos.org/nixpkgs/manual">Nixpkgs manual</link>.
|
manual</link>. In short, you clone Nixpkgs:
|
||||||
In short, you clone Nixpkgs:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ git clone git://github.com/NixOS/nixpkgs.git
|
$ git clone git://github.com/NixOS/nixpkgs.git
|
||||||
$ cd nixpkgs
|
$ cd nixpkgs
|
||||||
</screen>
|
</screen>
|
||||||
|
Then you write and test the package as described in the Nixpkgs manual.
|
||||||
Then you write and test the package as described in the Nixpkgs
|
Finally, you add it to <literal>environment.systemPackages</literal>, e.g.
|
||||||
manual. Finally, you add it to
|
|
||||||
<literal>environment.systemPackages</literal>, e.g.
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> = [ pkgs.my-package ];
|
<xref linkend="opt-environment.systemPackages"/> = [ pkgs.my-package ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
and you run <command>nixos-rebuild</command>, specifying your own Nixpkgs
|
||||||
and you run <command>nixos-rebuild</command>, specifying your own
|
tree:
|
||||||
Nixpkgs tree:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen>
|
# nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
The second possibility is to add the package outside of the Nixpkgs tree. For
|
||||||
<para>The second possibility is to add the package outside of the
|
instance, here is how you specify a build of the
|
||||||
Nixpkgs tree. For instance, here is how you specify a build of the
|
<link xlink:href="http://www.gnu.org/software/hello/">GNU Hello</link>
|
||||||
<link xlink:href="http://www.gnu.org/software/hello/">GNU Hello</link>
|
package directly in <filename>configuration.nix</filename>:
|
||||||
package directly in <filename>configuration.nix</filename>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> =
|
<xref linkend="opt-environment.systemPackages"/> =
|
||||||
let
|
let
|
||||||
@ -53,13 +46,12 @@ package directly in <filename>configuration.nix</filename>:
|
|||||||
in
|
in
|
||||||
[ my-hello ];
|
[ my-hello ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Of course, you can also move the definition of <literal>my-hello</literal>
|
||||||
Of course, you can also move the definition of
|
into a separate Nix expression, e.g.
|
||||||
<literal>my-hello</literal> into a separate Nix expression, e.g.
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> = [ (import ./my-hello.nix) ];
|
<xref linkend="opt-environment.systemPackages"/> = [ (import ./my-hello.nix) ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
where <filename>my-hello.nix</filename> contains:
|
where <filename>my-hello.nix</filename> contains:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
with import <nixpkgs> {}; # bring all of Nixpkgs into scope
|
with import <nixpkgs> {}; # bring all of Nixpkgs into scope
|
||||||
|
|
||||||
@ -71,14 +63,11 @@ stdenv.mkDerivation rec {
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This allows testing the package easily:
|
||||||
This allows testing the package easily:
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build my-hello.nix
|
$ nix-build my-hello.nix
|
||||||
$ ./result/bin/hello
|
$ ./result/bin/hello
|
||||||
Hello, world!
|
Hello, world!
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,28 +3,25 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-configuration-file">
|
xml:id="sec-configuration-file">
|
||||||
|
<title>NixOS Configuration File</title>
|
||||||
|
|
||||||
<title>NixOS Configuration File</title>
|
<para>
|
||||||
|
The NixOS configuration file generally looks like this:
|
||||||
<para>The NixOS configuration file generally looks like this:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
{ <replaceable>option definitions</replaceable>
|
{ <replaceable>option definitions</replaceable>
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The first line (<literal>{ config, pkgs, ... }:</literal>) denotes that this
|
||||||
The first line (<literal>{ config, pkgs, ... }:</literal>) denotes
|
is actually a function that takes at least the two arguments
|
||||||
that this is actually a function that takes at least the two arguments
|
<varname>config</varname> and <varname>pkgs</varname>. (These are explained
|
||||||
<varname>config</varname> and <varname>pkgs</varname>. (These are
|
later.) The function returns a <emphasis>set</emphasis> of option definitions
|
||||||
explained later.) The function returns a <emphasis>set</emphasis> of
|
(<literal>{ <replaceable>...</replaceable> }</literal>). These definitions
|
||||||
option definitions (<literal>{ <replaceable>...</replaceable> }</literal>). These definitions have the
|
have the form <literal><replaceable>name</replaceable> =
|
||||||
form <literal><replaceable>name</replaceable> =
|
<replaceable>value</replaceable></literal>, where
|
||||||
<replaceable>value</replaceable></literal>, where
|
<replaceable>name</replaceable> is the name of an option and
|
||||||
<replaceable>name</replaceable> is the name of an option and
|
<replaceable>value</replaceable> is its value. For example,
|
||||||
<replaceable>value</replaceable> is its value. For example,
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
@ -33,19 +30,19 @@ form <literal><replaceable>name</replaceable> =
|
|||||||
<xref linkend="opt-services.httpd.documentRoot"/> = "/webroot";
|
<xref linkend="opt-services.httpd.documentRoot"/> = "/webroot";
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
defines a configuration with three option definitions that together enable
|
||||||
|
the Apache HTTP Server with <filename>/webroot</filename> as the document
|
||||||
|
root.
|
||||||
|
</para>
|
||||||
|
|
||||||
defines a configuration with three option definitions that together
|
<para>
|
||||||
enable the Apache HTTP Server with <filename>/webroot</filename> as
|
Sets can be nested, and in fact dots in option names are shorthand for
|
||||||
the document root.</para>
|
defining a set containing another set. For instance,
|
||||||
|
<xref linkend="opt-services.httpd.enable"/> defines a set named
|
||||||
<para>Sets can be nested, and in fact dots in option names are
|
<varname>services</varname> that contains a set named
|
||||||
shorthand for defining a set containing another set. For instance,
|
<varname>httpd</varname>, which in turn contains an option definition named
|
||||||
<xref linkend="opt-services.httpd.enable"/> defines a set named
|
<varname>enable</varname> with value <literal>true</literal>. This means that
|
||||||
<varname>services</varname> that contains a set named
|
the example above can also be written as:
|
||||||
<varname>httpd</varname>, which in turn contains an option definition
|
|
||||||
named <varname>enable</varname> with value <literal>true</literal>.
|
|
||||||
This means that the example above can also be written as:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
@ -58,46 +55,44 @@ This means that the example above can also be written as:
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
which may be more convenient if you have lots of option definitions that
|
||||||
|
share the same prefix (such as <literal>services.httpd</literal>).
|
||||||
|
</para>
|
||||||
|
|
||||||
which may be more convenient if you have lots of option definitions
|
<para>
|
||||||
that share the same prefix (such as
|
NixOS checks your option definitions for correctness. For instance, if you
|
||||||
<literal>services.httpd</literal>).</para>
|
try to define an option that doesn’t exist (that is, doesn’t have a
|
||||||
|
corresponding <emphasis>option declaration</emphasis>),
|
||||||
<para>NixOS checks your option definitions for correctness. For
|
<command>nixos-rebuild</command> will give an error like:
|
||||||
instance, if you try to define an option that doesn’t exist (that is,
|
|
||||||
doesn’t have a corresponding <emphasis>option declaration</emphasis>),
|
|
||||||
<command>nixos-rebuild</command> will give an error like:
|
|
||||||
<screen>
|
<screen>
|
||||||
The option `services.httpd.enable' defined in `/etc/nixos/configuration.nix' does not exist.
|
The option `services.httpd.enable' defined in `/etc/nixos/configuration.nix' does not exist.
|
||||||
</screen>
|
</screen>
|
||||||
Likewise, values in option definitions must have a correct type. For
|
Likewise, values in option definitions must have a correct type. For
|
||||||
instance, <option>services.httpd.enable</option> must be a Boolean
|
instance, <option>services.httpd.enable</option> must be a Boolean
|
||||||
(<literal>true</literal> or <literal>false</literal>). Trying to give
|
(<literal>true</literal> or <literal>false</literal>). Trying to give it a
|
||||||
it a value of another type, such as a string, will cause an error:
|
value of another type, such as a string, will cause an error:
|
||||||
<screen>
|
<screen>
|
||||||
The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is not a boolean.
|
The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is not a boolean.
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
Options have various types of values. The most important are:
|
||||||
<para>Options have various types of values. The most important are:
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term>Strings</term>
|
<term>Strings</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Strings are enclosed in double quotes, e.g.
|
<para>
|
||||||
|
Strings are enclosed in double quotes, e.g.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.hostName"/> = "dexter";
|
<xref linkend="opt-networking.hostName"/> = "dexter";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Special characters can be escaped by prefixing them with a backslash
|
||||||
Special characters can be escaped by prefixing them with a
|
(e.g. <literal>\"</literal>).
|
||||||
backslash (e.g. <literal>\"</literal>).</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>Multi-line strings can be enclosed in <emphasis>double
|
Multi-line strings can be enclosed in <emphasis>double single
|
||||||
single quotes</emphasis>, e.g.
|
quotes</emphasis>, e.g.
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.extraHosts"/> =
|
<xref linkend="opt-networking.extraHosts"/> =
|
||||||
''
|
''
|
||||||
@ -105,58 +100,52 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
|
|||||||
10.0.0.1 server
|
10.0.0.1 server
|
||||||
'';
|
'';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The main difference is that it strips from each line a number of spaces
|
||||||
The main difference is that it strips from each line
|
equal to the minimal indentation of the string as a whole (disregarding
|
||||||
a number of spaces equal to the minimal indentation of
|
the indentation of empty lines), and that characters like
|
||||||
the string as a whole (disregarding the indentation of
|
<literal>"</literal> and <literal>\</literal> are not special (making it
|
||||||
empty lines), and that characters like
|
more convenient for including things like shell code). See more info
|
||||||
<literal>"</literal> and <literal>\</literal> are not special
|
about this in the Nix manual
|
||||||
(making it more convenient for including things like shell
|
<link
|
||||||
code).
|
xlink:href="https://nixos.org/nix/manual/#ssec-values">here</link>.
|
||||||
See more info about this in the Nix manual <link
|
</para>
|
||||||
xlink:href="https://nixos.org/nix/manual/#ssec-values">here</link>.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
|
||||||
<term>Booleans</term>
|
<term>Booleans</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>These can be <literal>true</literal> or
|
<para>
|
||||||
<literal>false</literal>, e.g.
|
These can be <literal>true</literal> or <literal>false</literal>, e.g.
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.firewall.enable"/> = true;
|
<xref linkend="opt-networking.firewall.enable"/> = true;
|
||||||
<xref linkend="opt-networking.firewall.allowPing"/> = false;
|
<xref linkend="opt-networking.firewall.allowPing"/> = false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
|
||||||
<term>Integers</term>
|
<term>Integers</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>For example,
|
<para>
|
||||||
|
For example,
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernel.sysctl"/>."net.ipv4.tcp_keepalive_time" = 60;
|
<xref linkend="opt-boot.kernel.sysctl"/>."net.ipv4.tcp_keepalive_time" = 60;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
(Note that here the attribute name
|
(Note that here the attribute name
|
||||||
<literal>net.ipv4.tcp_keepalive_time</literal> is enclosed in
|
<literal>net.ipv4.tcp_keepalive_time</literal> is enclosed in quotes to
|
||||||
quotes to prevent it from being interpreted as a set named
|
prevent it from being interpreted as a set named <literal>net</literal>
|
||||||
<literal>net</literal> containing a set named
|
containing a set named <literal>ipv4</literal>, and so on. This is
|
||||||
<literal>ipv4</literal>, and so on. This is because it’s not a
|
because it’s not a NixOS option but the literal name of a Linux kernel
|
||||||
NixOS option but the literal name of a Linux kernel
|
setting.)
|
||||||
setting.)</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
|
||||||
<term>Sets</term>
|
<term>Sets</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Sets were introduced above. They are name/value pairs
|
<para>
|
||||||
enclosed in braces, as in the option definition
|
Sets were introduced above. They are name/value pairs enclosed in braces,
|
||||||
|
as in the option definition
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-fileSystems"/>."/boot" =
|
<xref linkend="opt-fileSystems"/>."/boot" =
|
||||||
{ device = "/dev/sda1";
|
{ device = "/dev/sda1";
|
||||||
@ -164,36 +153,32 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
|
|||||||
options = [ "rw" "data=ordered" "relatime" ];
|
options = [ "rw" "data=ordered" "relatime" ];
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
|
||||||
<term>Lists</term>
|
<term>Lists</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The important thing to note about lists is that list
|
<para>
|
||||||
elements are separated by whitespace, like this:
|
The important thing to note about lists is that list elements are
|
||||||
|
separated by whitespace, like this:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernelModules"/> = [ "fuse" "kvm-intel" "coretemp" ];
|
<xref linkend="opt-boot.kernelModules"/> = [ "fuse" "kvm-intel" "coretemp" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
List elements can be any other type, e.g. sets:
|
List elements can be any other type, e.g. sets:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
|
||||||
<term>Packages</term>
|
<term>Packages</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Usually, the packages you need are already part of the Nix
|
<para>
|
||||||
Packages collection, which is a set that can be accessed through
|
Usually, the packages you need are already part of the Nix Packages
|
||||||
the function argument <varname>pkgs</varname>. Typical uses:
|
collection, which is a set that can be accessed through the function
|
||||||
|
argument <varname>pkgs</varname>. Typical uses:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> =
|
<xref linkend="opt-environment.systemPackages"/> =
|
||||||
[ pkgs.thunderbird
|
[ pkgs.thunderbird
|
||||||
@ -202,16 +187,12 @@ swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
|||||||
|
|
||||||
<xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql90;
|
<xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql90;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The latter option definition changes the default PostgreSQL package used
|
||||||
The latter option definition changes the default PostgreSQL
|
by NixOS’s PostgreSQL service to 9.0. For more information on packages,
|
||||||
package used by NixOS’s PostgreSQL service to 9.0. For more
|
including how to add new ones, see <xref linkend="sec-custom-packages"/>.
|
||||||
information on packages, including how to add new ones, see
|
</para>
|
||||||
<xref linkend="sec-custom-packages"/>.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</variablelist>
|
</para>
|
||||||
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,25 +3,23 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-configuration-syntax">
|
xml:id="sec-configuration-syntax">
|
||||||
|
<title>Configuration Syntax</title>
|
||||||
<title>Configuration Syntax</title>
|
<para>
|
||||||
|
The NixOS configuration file
|
||||||
<para>The NixOS configuration file
|
<filename>/etc/nixos/configuration.nix</filename> is actually a <emphasis>Nix
|
||||||
<filename>/etc/nixos/configuration.nix</filename> is actually a
|
expression</emphasis>, which is the Nix package manager’s purely functional
|
||||||
<emphasis>Nix expression</emphasis>, which is the Nix package
|
language for describing how to build packages and configurations. This means
|
||||||
manager’s purely functional language for describing how to build
|
you have all the expressive power of that language at your disposal,
|
||||||
packages and configurations. This means you have all the expressive
|
including the ability to abstract over common patterns, which is very useful
|
||||||
power of that language at your disposal, including the ability to
|
when managing complex systems. The syntax and semantics of the Nix language
|
||||||
abstract over common patterns, which is very useful when managing
|
are fully described in the
|
||||||
complex systems. The syntax and semantics of the Nix language are
|
<link
|
||||||
fully described in the <link
|
|
||||||
xlink:href="http://nixos.org/nix/manual/#chap-writing-nix-expressions">Nix
|
xlink:href="http://nixos.org/nix/manual/#chap-writing-nix-expressions">Nix
|
||||||
manual</link>, but here we give a short overview of the most important
|
manual</link>, but here we give a short overview of the most important
|
||||||
constructs useful in NixOS configuration files.</para>
|
constructs useful in NixOS configuration files.
|
||||||
|
</para>
|
||||||
<xi:include href="config-file.xml" />
|
<xi:include href="config-file.xml" />
|
||||||
<xi:include href="abstractions.xml" />
|
<xi:include href="abstractions.xml" />
|
||||||
<xi:include href="modularity.xml" />
|
<xi:include href="modularity.xml" />
|
||||||
<xi:include href="summary.xml" />
|
<xi:include href="summary.xml" />
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,30 +3,24 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-configuration">
|
xml:id="ch-configuration">
|
||||||
|
<title>Configuration</title>
|
||||||
<title>Configuration</title>
|
<partintro>
|
||||||
|
<para>
|
||||||
<partintro>
|
This chapter describes how to configure various aspects of a NixOS machine
|
||||||
|
through the configuration file
|
||||||
<para>This chapter describes how to configure various aspects of a
|
<filename>/etc/nixos/configuration.nix</filename>. As described in
|
||||||
NixOS machine through the configuration file
|
<xref linkend="sec-changing-config" />, changes to this file only take
|
||||||
<filename>/etc/nixos/configuration.nix</filename>. As described in
|
effect after you run <command>nixos-rebuild</command>.
|
||||||
<xref linkend="sec-changing-config" />, changes to this file only take
|
</para>
|
||||||
effect after you run <command>nixos-rebuild</command>.</para>
|
</partintro>
|
||||||
|
<xi:include href="config-syntax.xml" />
|
||||||
</partintro>
|
<xi:include href="package-mgmt.xml" />
|
||||||
|
<xi:include href="user-mgmt.xml" />
|
||||||
<xi:include href="config-syntax.xml" />
|
<xi:include href="file-systems.xml" />
|
||||||
<xi:include href="package-mgmt.xml" />
|
<xi:include href="x-windows.xml" />
|
||||||
<xi:include href="user-mgmt.xml" />
|
<xi:include href="xfce.xml" />
|
||||||
<xi:include href="file-systems.xml" />
|
<xi:include href="networking.xml" />
|
||||||
<xi:include href="x-windows.xml" />
|
<xi:include href="linux-kernel.xml" />
|
||||||
<xi:include href="xfce.xml" />
|
<xi:include href="../generated/modules.xml" xpointer="xpointer(//section[@id='modules']/*)" />
|
||||||
<xi:include href="networking.xml" />
|
|
||||||
<xi:include href="linux-kernel.xml" />
|
|
||||||
|
|
||||||
<xi:include href="../generated/modules.xml" xpointer="xpointer(//section[@id='modules']/*)" />
|
|
||||||
|
|
||||||
<!-- Apache; libvirtd virtualisation -->
|
<!-- Apache; libvirtd virtualisation -->
|
||||||
|
|
||||||
</part>
|
</part>
|
||||||
|
@ -3,53 +3,50 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-customising-packages">
|
xml:id="sec-customising-packages">
|
||||||
|
<title>Customising Packages</title>
|
||||||
|
|
||||||
<title>Customising Packages</title>
|
<para>
|
||||||
|
Some packages in Nixpkgs have options to enable or disable optional
|
||||||
|
functionality or change other aspects of the package. For instance, the
|
||||||
|
Firefox wrapper package (which provides Firefox with a set of plugins such as
|
||||||
|
the Adobe Flash player) has an option to enable the Google Talk plugin. It
|
||||||
|
can be set in <filename>configuration.nix</filename> as follows: <filename>
|
||||||
|
nixpkgs.config.firefox.enableGoogleTalkPlugin = true; </filename>
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>Some packages in Nixpkgs have options to enable or disable
|
<warning>
|
||||||
optional functionality or change other aspects of the package. For
|
<para>
|
||||||
instance, the Firefox wrapper package (which provides Firefox with a
|
Unfortunately, Nixpkgs currently lacks a way to query available
|
||||||
set of plugins such as the Adobe Flash player) has an option to enable
|
configuration options.
|
||||||
the Google Talk plugin. It can be set in
|
</para>
|
||||||
<filename>configuration.nix</filename> as follows:
|
</warning>
|
||||||
|
|
||||||
<filename>
|
|
||||||
nixpkgs.config.firefox.enableGoogleTalkPlugin = true;
|
|
||||||
</filename>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<warning><para>Unfortunately, Nixpkgs currently lacks a way to query
|
|
||||||
available configuration options.</para></warning>
|
|
||||||
|
|
||||||
<para>Apart from high-level options, it’s possible to tweak a package
|
|
||||||
in almost arbitrary ways, such as changing or disabling dependencies
|
|
||||||
of a package. For instance, the Emacs package in Nixpkgs by default
|
|
||||||
has a dependency on GTK+ 2. If you want to build it against GTK+ 3,
|
|
||||||
you can specify that as follows:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Apart from high-level options, it’s possible to tweak a package in almost
|
||||||
|
arbitrary ways, such as changing or disabling dependencies of a package. For
|
||||||
|
instance, the Emacs package in Nixpkgs by default has a dependency on GTK+ 2.
|
||||||
|
If you want to build it against GTK+ 3, you can specify that as follows:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
|
<xref linkend="opt-environment.systemPackages"/> = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The function <varname>override</varname> performs the call to the Nix
|
||||||
|
function that produces Emacs, with the original arguments amended by the set
|
||||||
|
of arguments specified by you. So here the function argument
|
||||||
|
<varname>gtk</varname> gets the value <literal>pkgs.gtk3</literal>, causing
|
||||||
|
Emacs to depend on GTK+ 3. (The parentheses are necessary because in Nix,
|
||||||
|
function application binds more weakly than list construction, so without
|
||||||
|
them, <xref linkend="opt-environment.systemPackages"/> would be a list with
|
||||||
|
two elements.)
|
||||||
|
</para>
|
||||||
|
|
||||||
The function <varname>override</varname> performs the call to the Nix
|
<para>
|
||||||
function that produces Emacs, with the original arguments amended by
|
Even greater customisation is possible using the function
|
||||||
the set of arguments specified by you. So here the function argument
|
<varname>overrideAttrs</varname>. While the <varname>override</varname>
|
||||||
<varname>gtk</varname> gets the value <literal>pkgs.gtk3</literal>,
|
mechanism above overrides the arguments of a package function,
|
||||||
causing Emacs to depend on GTK+ 3. (The parentheses are necessary
|
<varname>overrideAttrs</varname> allows changing the
|
||||||
because in Nix, function application binds more weakly than list
|
<emphasis>attributes</emphasis> passed to <literal>mkDerivation</literal>.
|
||||||
construction, so without them,
|
This permits changing any aspect of the package, such as the source code. For
|
||||||
<xref linkend="opt-environment.systemPackages"/> would be a list with two
|
instance, if you want to override the source code of Emacs, you can say:
|
||||||
elements.)</para>
|
|
||||||
|
|
||||||
<para>Even greater customisation is possible using the function
|
|
||||||
<varname>overrideAttrs</varname>. While the
|
|
||||||
<varname>override</varname> mechanism above overrides the arguments of
|
|
||||||
a package function, <varname>overrideAttrs</varname> allows
|
|
||||||
changing the <emphasis>attributes</emphasis> passed to <literal>mkDerivation</literal>.
|
|
||||||
This permits changing any aspect of the package, such as the source code.
|
|
||||||
For instance, if you want to override the source code of Emacs, you
|
|
||||||
can say:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> = [
|
<xref linkend="opt-environment.systemPackages"/> = [
|
||||||
(pkgs.emacs.overrideAttrs (oldAttrs: {
|
(pkgs.emacs.overrideAttrs (oldAttrs: {
|
||||||
@ -58,36 +55,32 @@ can say:
|
|||||||
}))
|
}))
|
||||||
];
|
];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Here, <varname>overrideAttrs</varname> takes the Nix derivation specified by
|
||||||
|
<varname>pkgs.emacs</varname> and produces a new derivation in which the
|
||||||
|
original’s <literal>name</literal> and <literal>src</literal> attribute
|
||||||
|
have been replaced by the given values by re-calling
|
||||||
|
<literal>stdenv.mkDerivation</literal>. The original attributes are
|
||||||
|
accessible via the function argument, which is conventionally named
|
||||||
|
<varname>oldAttrs</varname>.
|
||||||
|
</para>
|
||||||
|
|
||||||
Here, <varname>overrideAttrs</varname> takes the Nix derivation
|
<para>
|
||||||
specified by <varname>pkgs.emacs</varname> and produces a new
|
The overrides shown above are not global. They do not affect the original
|
||||||
derivation in which the original’s <literal>name</literal> and
|
package; other packages in Nixpkgs continue to depend on the original rather
|
||||||
<literal>src</literal> attribute have been replaced by the given
|
than the customised package. This means that if another package in your
|
||||||
values by re-calling <literal>stdenv.mkDerivation</literal>.
|
system depends on the original package, you end up with two instances of the
|
||||||
The original attributes are accessible via the function argument,
|
package. If you want to have everything depend on your customised instance,
|
||||||
which is conventionally named <varname>oldAttrs</varname>.</para>
|
you can apply a <emphasis>global</emphasis> override as follows:
|
||||||
|
|
||||||
<para>The overrides shown above are not global. They do not affect
|
|
||||||
the original package; other packages in Nixpkgs continue to depend on
|
|
||||||
the original rather than the customised package. This means that if
|
|
||||||
another package in your system depends on the original package, you
|
|
||||||
end up with two instances of the package. If you want to have
|
|
||||||
everything depend on your customised instance, you can apply a
|
|
||||||
<emphasis>global</emphasis> override as follows:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
nixpkgs.config.packageOverrides = pkgs:
|
nixpkgs.config.packageOverrides = pkgs:
|
||||||
{ emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
|
{ emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
|
||||||
};
|
};
|
||||||
</screen>
|
</screen>
|
||||||
|
The effect of this definition is essentially equivalent to modifying the
|
||||||
The effect of this definition is essentially equivalent to modifying
|
<literal>emacs</literal> attribute in the Nixpkgs source tree. Any package in
|
||||||
the <literal>emacs</literal> attribute in the Nixpkgs source tree.
|
Nixpkgs that depends on <literal>emacs</literal> will be passed your
|
||||||
Any package in Nixpkgs that depends on <literal>emacs</literal> will
|
customised instance. (However, the value <literal>pkgs.emacs</literal> in
|
||||||
be passed your customised instance. (However, the value
|
<varname>nixpkgs.config.packageOverrides</varname> refers to the original
|
||||||
<literal>pkgs.emacs</literal> in
|
rather than overridden instance, to prevent an infinite recursion.)
|
||||||
<varname>nixpkgs.config.packageOverrides</varname> refers to the
|
</para>
|
||||||
original rather than overridden instance, to prevent an infinite
|
|
||||||
recursion.)</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,41 +3,41 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-declarative-package-mgmt">
|
xml:id="sec-declarative-package-mgmt">
|
||||||
|
<title>Declarative Package Management</title>
|
||||||
|
|
||||||
<title>Declarative Package Management</title>
|
<para>
|
||||||
|
With declarative package management, you specify which packages you want on
|
||||||
<para>With declarative package management, you specify which packages
|
your system by setting the option
|
||||||
you want on your system by setting the option
|
<xref linkend="opt-environment.systemPackages"/>. For instance, adding the
|
||||||
<xref linkend="opt-environment.systemPackages"/>. For instance, adding the
|
following line to <filename>configuration.nix</filename> enables the Mozilla
|
||||||
following line to <filename>configuration.nix</filename> enables the
|
Thunderbird email application:
|
||||||
Mozilla Thunderbird email application:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-environment.systemPackages"/> = [ pkgs.thunderbird ];
|
<xref linkend="opt-environment.systemPackages"/> = [ pkgs.thunderbird ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The effect of this specification is that the Thunderbird package from Nixpkgs
|
||||||
|
will be built or downloaded as part of the system when you run
|
||||||
|
<command>nixos-rebuild switch</command>.
|
||||||
|
</para>
|
||||||
|
|
||||||
The effect of this specification is that the Thunderbird package from
|
<para>
|
||||||
Nixpkgs will be built or downloaded as part of the system when you run
|
You can get a list of the available packages as follows:
|
||||||
<command>nixos-rebuild switch</command>.</para>
|
|
||||||
|
|
||||||
<para>You can get a list of the available packages as follows:
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -qaP '*' --description
|
$ nix-env -qaP '*' --description
|
||||||
nixos.firefox firefox-23.0 Mozilla Firefox - the browser, reloaded
|
nixos.firefox firefox-23.0 Mozilla Firefox - the browser, reloaded
|
||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
</screen>
|
</screen>
|
||||||
|
The first column in the output is the <emphasis>attribute name</emphasis>,
|
||||||
|
such as <literal>nixos.thunderbird</literal>. (The <literal>nixos</literal>
|
||||||
|
prefix allows distinguishing between different channels that you might have.)
|
||||||
|
</para>
|
||||||
|
|
||||||
The first column in the output is the <emphasis>attribute
|
<para>
|
||||||
name</emphasis>, such as
|
To “uninstall” a package, simply remove it from
|
||||||
<literal>nixos.thunderbird</literal>. (The
|
<xref linkend="opt-environment.systemPackages"/> and run
|
||||||
<literal>nixos</literal> prefix allows distinguishing between
|
<command>nixos-rebuild switch</command>.
|
||||||
different channels that you might have.)</para>
|
</para>
|
||||||
|
|
||||||
<para>To “uninstall” a package, simply remove it from
|
<xi:include href="customizing-packages.xml" />
|
||||||
<xref linkend="opt-environment.systemPackages"/> and run
|
|
||||||
<command>nixos-rebuild switch</command>.</para>
|
|
||||||
|
|
||||||
<xi:include href="customizing-packages.xml" />
|
|
||||||
<xi:include href="adding-custom-packages.xml" />
|
|
||||||
|
|
||||||
|
<xi:include href="adding-custom-packages.xml" />
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,44 +3,44 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-file-systems">
|
xml:id="ch-file-systems">
|
||||||
|
<title>File Systems</title>
|
||||||
<title>File Systems</title>
|
<para>
|
||||||
|
You can define file systems using the <option>fileSystems</option>
|
||||||
<para>You can define file systems using the
|
configuration option. For instance, the following definition causes NixOS to
|
||||||
<option>fileSystems</option> configuration option. For instance, the
|
mount the Ext4 file system on device
|
||||||
following definition causes NixOS to mount the Ext4 file system on
|
<filename>/dev/disk/by-label/data</filename> onto the mount point
|
||||||
device <filename>/dev/disk/by-label/data</filename> onto the mount
|
<filename>/data</filename>:
|
||||||
point <filename>/data</filename>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-fileSystems"/>."/data" =
|
<xref linkend="opt-fileSystems"/>."/data" =
|
||||||
{ device = "/dev/disk/by-label/data";
|
{ device = "/dev/disk/by-label/data";
|
||||||
fsType = "ext4";
|
fsType = "ext4";
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Mount points are created automatically if they don’t already exist. For
|
||||||
Mount points are created automatically if they don’t already exist.
|
<option><link linkend="opt-fileSystems._name__.device">device</link></option>,
|
||||||
For <option><link linkend="opt-fileSystems._name__.device">device</link></option>, it’s best to use the topology-independent
|
it’s best to use the topology-independent device aliases in
|
||||||
device aliases in <filename>/dev/disk/by-label</filename> and
|
<filename>/dev/disk/by-label</filename> and
|
||||||
<filename>/dev/disk/by-uuid</filename>, as these don’t change if the
|
<filename>/dev/disk/by-uuid</filename>, as these don’t change if the
|
||||||
topology changes (e.g. if a disk is moved to another IDE
|
topology changes (e.g. if a disk is moved to another IDE controller).
|
||||||
controller).</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>You can usually omit the file system type
|
You can usually omit the file system type
|
||||||
(<option><link linkend="opt-fileSystems._name__.fsType">fsType</link></option>), since <command>mount</command> can usually
|
(<option><link linkend="opt-fileSystems._name__.fsType">fsType</link></option>),
|
||||||
detect the type and load the necessary kernel module automatically.
|
since <command>mount</command> can usually detect the type and load the
|
||||||
However, if the file system is needed at early boot (in the initial
|
necessary kernel module automatically. However, if the file system is needed
|
||||||
ramdisk) and is not <literal>ext2</literal>, <literal>ext3</literal>
|
at early boot (in the initial ramdisk) and is not <literal>ext2</literal>,
|
||||||
or <literal>ext4</literal>, then it’s best to specify
|
<literal>ext3</literal> or <literal>ext4</literal>, then it’s best to
|
||||||
<option>fsType</option> to ensure that the kernel module is
|
specify <option>fsType</option> to ensure that the kernel module is
|
||||||
available.</para>
|
available.
|
||||||
|
</para>
|
||||||
<note><para>System startup will fail if any of the filesystems fails to mount,
|
<note>
|
||||||
dropping you to the emergency shell.
|
<para>
|
||||||
You can make a mount asynchronous and non-critical by adding
|
System startup will fail if any of the filesystems fails to mount, dropping
|
||||||
<literal><link linkend="opt-fileSystems._name__.options">options</link> = [ "nofail" ];</literal>.
|
you to the emergency shell. You can make a mount asynchronous and
|
||||||
</para></note>
|
non-critical by adding
|
||||||
|
<literal><link linkend="opt-fileSystems._name__.options">options</link> = [
|
||||||
<xi:include href="luks-file-systems.xml" />
|
"nofail" ];</literal>.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
<xi:include href="luks-file-systems.xml" />
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,49 +3,44 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-firewall">
|
xml:id="sec-firewall">
|
||||||
|
<title>Firewall</title>
|
||||||
|
|
||||||
<title>Firewall</title>
|
<para>
|
||||||
|
NixOS has a simple stateful firewall that blocks incoming connections and
|
||||||
<para>NixOS has a simple stateful firewall that blocks incoming
|
other unexpected packets. The firewall applies to both IPv4 and IPv6 traffic.
|
||||||
connections and other unexpected packets. The firewall applies to
|
It is enabled by default. It can be disabled as follows:
|
||||||
both IPv4 and IPv6 traffic. It is enabled by default. It can be
|
|
||||||
disabled as follows:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.firewall.enable"/> = false;
|
<xref linkend="opt-networking.firewall.enable"/> = false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
If the firewall is enabled, you can open specific TCP ports to the outside
|
||||||
If the firewall is enabled, you can open specific TCP ports to the
|
world:
|
||||||
outside world:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.firewall.allowedTCPPorts"/> = [ 80 443 ];
|
<xref linkend="opt-networking.firewall.allowedTCPPorts"/> = [ 80 443 ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Note that TCP port 22 (ssh) is opened automatically if the SSH daemon is
|
||||||
|
enabled (<option><xref linkend="opt-services.openssh.enable"/> =
|
||||||
|
true</option>). UDP ports can be opened through
|
||||||
|
<xref linkend="opt-networking.firewall.allowedUDPPorts"/>.
|
||||||
|
</para>
|
||||||
|
|
||||||
Note that TCP port 22 (ssh) is opened automatically if the SSH daemon
|
<para>
|
||||||
is enabled (<option><xref linkend="opt-services.openssh.enable"/> = true</option>). UDP
|
To open ranges of TCP ports:
|
||||||
ports can be opened through
|
|
||||||
<xref linkend="opt-networking.firewall.allowedUDPPorts"/>.</para>
|
|
||||||
|
|
||||||
<para>To open ranges of TCP ports:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.firewall.allowedTCPPortRanges"/> = [
|
<xref linkend="opt-networking.firewall.allowedTCPPortRanges"/> = [
|
||||||
{ from = 4000; to = 4007; }
|
{ from = 4000; to = 4007; }
|
||||||
{ from = 8000; to = 8010; }
|
{ from = 8000; to = 8010; }
|
||||||
];
|
];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Similarly, UDP port ranges can be opened through
|
||||||
|
<xref linkend="opt-networking.firewall.allowedUDPPortRanges"/>.
|
||||||
|
</para>
|
||||||
|
|
||||||
Similarly, UDP port ranges can be opened through
|
<para>
|
||||||
<xref linkend="opt-networking.firewall.allowedUDPPortRanges"/>.</para>
|
Also of interest is
|
||||||
|
|
||||||
<para>Also of interest is
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.firewall.allowPing"/> = true;
|
<xref linkend="opt-networking.firewall.allowPing"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
to allow the machine to respond to ping requests. (ICMPv6 pings are always
|
||||||
to allow the machine to respond to ping requests. (ICMPv6 pings are
|
allowed.)
|
||||||
always allowed.)</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,45 +3,41 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-ipv4">
|
xml:id="sec-ipv4">
|
||||||
|
<title>IPv4 Configuration</title>
|
||||||
|
|
||||||
<title>IPv4 Configuration</title>
|
<para>
|
||||||
|
By default, NixOS uses DHCP (specifically, <command>dhcpcd</command>) to
|
||||||
<para>By default, NixOS uses DHCP (specifically,
|
automatically configure network interfaces. However, you can configure an
|
||||||
<command>dhcpcd</command>) to automatically configure network
|
interface manually as follows:
|
||||||
interfaces. However, you can configure an interface manually as
|
|
||||||
follows:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<link linkend="opt-networking.interfaces._name__.ipv4.addresses">networking.interfaces.eth0.ipv4.addresses</link> = [ {
|
<link linkend="opt-networking.interfaces._name__.ipv4.addresses">networking.interfaces.eth0.ipv4.addresses</link> = [ {
|
||||||
address = "192.168.1.2";
|
address = "192.168.1.2";
|
||||||
prefixLength = 24;
|
prefixLength = 24;
|
||||||
} ];
|
} ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Typically you’ll also want to set a default gateway and set of name
|
||||||
Typically you’ll also want to set a default gateway and set of name
|
servers:
|
||||||
servers:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.defaultGateway"/> = "192.168.1.1";
|
<xref linkend="opt-networking.defaultGateway"/> = "192.168.1.1";
|
||||||
<xref linkend="opt-networking.nameservers"/> = [ "8.8.8.8" ];
|
<xref linkend="opt-networking.nameservers"/> = [ "8.8.8.8" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<note>
|
||||||
|
<para>
|
||||||
<note><para>Statically configured interfaces are set up by the systemd
|
Statically configured interfaces are set up by the systemd service
|
||||||
service
|
<replaceable>interface-name</replaceable><literal>-cfg.service</literal>.
|
||||||
<replaceable>interface-name</replaceable><literal>-cfg.service</literal>.
|
The default gateway and name server configuration is performed by
|
||||||
The default gateway and name server configuration is performed by
|
<literal>network-setup.service</literal>.
|
||||||
<literal>network-setup.service</literal>.</para></note>
|
</para>
|
||||||
|
</note>
|
||||||
<para>The host name is set using <xref linkend="opt-networking.hostName"/>:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The host name is set using <xref linkend="opt-networking.hostName"/>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.hostName"/> = "cartman";
|
<xref linkend="opt-networking.hostName"/> = "cartman";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The default host name is <literal>nixos</literal>. Set it to the empty string
|
||||||
The default host name is <literal>nixos</literal>. Set it to the
|
(<literal>""</literal>) to allow the DHCP server to provide the host name.
|
||||||
empty string (<literal>""</literal>) to allow the DHCP server to
|
</para>
|
||||||
provide the host name.</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,47 +3,48 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-ipv6">
|
xml:id="sec-ipv6">
|
||||||
|
<title>IPv6 Configuration</title>
|
||||||
|
|
||||||
<title>IPv6 Configuration</title>
|
<para>
|
||||||
|
IPv6 is enabled by default. Stateless address autoconfiguration is used to
|
||||||
<para>IPv6 is enabled by default. Stateless address autoconfiguration
|
automatically assign IPv6 addresses to all interfaces. You can disable IPv6
|
||||||
is used to automatically assign IPv6 addresses to all interfaces. You
|
support globally by setting:
|
||||||
can disable IPv6 support globally by setting:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.enableIPv6"/> = false;
|
<xref linkend="opt-networking.enableIPv6"/> = false;
|
||||||
</programlisting></para>
|
</programlisting>
|
||||||
|
</para>
|
||||||
<para>You can disable IPv6 on a single interface using a normal sysctl (in this
|
|
||||||
example, we use interface <varname>eth0</varname>):
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
You can disable IPv6 on a single interface using a normal sysctl (in this
|
||||||
|
example, we use interface <varname>eth0</varname>):
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernel.sysctl"/>."net.ipv6.conf.eth0.disable_ipv6" = true;
|
<xref linkend="opt-boot.kernel.sysctl"/>."net.ipv6.conf.eth0.disable_ipv6" = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>As with IPv4 networking interfaces are automatically configured via
|
|
||||||
DHCPv6. You can configure an interface manually:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
As with IPv4 networking interfaces are automatically configured via DHCPv6.
|
||||||
|
You can configure an interface manually:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<link linkend="opt-networking.interfaces._name__.ipv6.addresses">networking.interfaces.eth0.ipv6.addresses</link> = [ {
|
<link linkend="opt-networking.interfaces._name__.ipv6.addresses">networking.interfaces.eth0.ipv6.addresses</link> = [ {
|
||||||
address = "fe00:aa:bb:cc::2";
|
address = "fe00:aa:bb:cc::2";
|
||||||
prefixLength = 64;
|
prefixLength = 64;
|
||||||
} ];
|
} ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>For configuring a gateway, optionally with explicitly specified interface:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
For configuring a gateway, optionally with explicitly specified interface:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.defaultGateway6"/> = {
|
<xref linkend="opt-networking.defaultGateway6"/> = {
|
||||||
address = "fe00::1";
|
address = "fe00::1";
|
||||||
interface = "enp0s3";
|
interface = "enp0s3";
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>See <xref linkend='sec-ipv4' /> for similar examples and additional information.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
See <xref linkend='sec-ipv4' /> for similar examples and additional
|
||||||
|
information.
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,29 +3,29 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-kernel-config">
|
xml:id="sec-kernel-config">
|
||||||
|
<title>Linux Kernel</title>
|
||||||
<title>Linux Kernel</title>
|
<para>
|
||||||
|
You can override the Linux kernel and associated packages using the option
|
||||||
<para>You can override the Linux kernel and associated packages using
|
<option>boot.kernelPackages</option>. For instance, this selects the Linux
|
||||||
the option <option>boot.kernelPackages</option>. For instance, this
|
3.10 kernel:
|
||||||
selects the Linux 3.10 kernel:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernelPackages"/> = pkgs.linuxPackages_3_10;
|
<xref linkend="opt-boot.kernelPackages"/> = pkgs.linuxPackages_3_10;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Note that this not only replaces the kernel, but also packages that
|
Note that this not only replaces the kernel, but also packages that are
|
||||||
are specific to the kernel version, such as the NVIDIA video drivers.
|
specific to the kernel version, such as the NVIDIA video drivers. This
|
||||||
This ensures that driver packages are consistent with the
|
ensures that driver packages are consistent with the kernel.
|
||||||
kernel.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>The default Linux kernel configuration should be fine for most users. You can see the configuration of your current kernel with the following command:
|
The default Linux kernel configuration should be fine for most users. You can
|
||||||
|
see the configuration of your current kernel with the following command:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
zcat /proc/config.gz
|
zcat /proc/config.gz
|
||||||
</programlisting>
|
</programlisting>
|
||||||
If you want to change the kernel configuration, you can use the
|
If you want to change the kernel configuration, you can use the
|
||||||
<option>packageOverrides</option> feature (see <xref
|
<option>packageOverrides</option> feature (see
|
||||||
linkend="sec-customising-packages" />). For instance, to enable
|
<xref
|
||||||
support for the kernel debugger KGDB:
|
linkend="sec-customising-packages" />). For instance, to enable support
|
||||||
|
for the kernel debugger KGDB:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
nixpkgs.config.packageOverrides = pkgs:
|
nixpkgs.config.packageOverrides = pkgs:
|
||||||
{ linux_3_4 = pkgs.linux_3_4.override {
|
{ linux_3_4 = pkgs.linux_3_4.override {
|
||||||
@ -36,47 +36,46 @@ nixpkgs.config.packageOverrides = pkgs:
|
|||||||
};
|
};
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
<varname>extraConfig</varname> takes a list of Linux kernel configuration
|
||||||
<varname>extraConfig</varname> takes a list of Linux kernel
|
options, one per line. The name of the option should not include the prefix
|
||||||
configuration options, one per line. The name of the option should
|
<literal>CONFIG_</literal>. The option value is typically
|
||||||
not include the prefix <literal>CONFIG_</literal>. The option value
|
<literal>y</literal>, <literal>n</literal> or <literal>m</literal> (to build
|
||||||
is typically <literal>y</literal>, <literal>n</literal> or
|
something as a kernel module).
|
||||||
<literal>m</literal> (to build something as a kernel module).</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>Kernel modules for hardware devices are generally loaded
|
Kernel modules for hardware devices are generally loaded automatically by
|
||||||
automatically by <command>udev</command>. You can force a module to
|
<command>udev</command>. You can force a module to be loaded via
|
||||||
be loaded via <xref linkend="opt-boot.kernelModules"/>, e.g.
|
<xref linkend="opt-boot.kernelModules"/>, e.g.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernelModules"/> = [ "fuse" "kvm-intel" "coretemp" ];
|
<xref linkend="opt-boot.kernelModules"/> = [ "fuse" "kvm-intel" "coretemp" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
If the module is required early during the boot (e.g. to mount the
|
If the module is required early during the boot (e.g. to mount the root file
|
||||||
root file system), you can use
|
system), you can use <xref linkend="opt-boot.initrd.extraKernelModules"/>:
|
||||||
<xref linkend="opt-boot.initrd.extraKernelModules"/>:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.initrd.extraKernelModules"/> = [ "cifs" ];
|
<xref linkend="opt-boot.initrd.extraKernelModules"/> = [ "cifs" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
This causes the specified modules and their dependencies to be added
|
This causes the specified modules and their dependencies to be added to the
|
||||||
to the initial ramdisk.</para>
|
initial ramdisk.
|
||||||
|
</para>
|
||||||
<para>Kernel runtime parameters can be set through
|
<para>
|
||||||
<xref linkend="opt-boot.kernel.sysctl"/>, e.g.
|
Kernel runtime parameters can be set through
|
||||||
|
<xref linkend="opt-boot.kernel.sysctl"/>, e.g.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernel.sysctl"/>."net.ipv4.tcp_keepalive_time" = 120;
|
<xref linkend="opt-boot.kernel.sysctl"/>."net.ipv4.tcp_keepalive_time" = 120;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
sets the kernel’s TCP keepalive time to 120 seconds. To see the
|
sets the kernel’s TCP keepalive time to 120 seconds. To see the available
|
||||||
available parameters, run <command>sysctl -a</command>.</para>
|
parameters, run <command>sysctl -a</command>.
|
||||||
|
</para>
|
||||||
<section>
|
<section>
|
||||||
<title>Developing kernel modules</title>
|
<title>Developing kernel modules</title>
|
||||||
|
|
||||||
<para>When developing kernel modules it's often convenient to run
|
<para>
|
||||||
edit-compile-run loop as quickly as possible.
|
When developing kernel modules it's often convenient to run edit-compile-run
|
||||||
|
loop as quickly as possible. See below snippet as an example of developing
|
||||||
See below snippet as an example of developing <literal>mellanox</literal>
|
<literal>mellanox</literal> drivers.
|
||||||
drivers.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<screen><![CDATA[
|
<screen><![CDATA[
|
||||||
$ nix-build '<nixpkgs>' -A linuxPackages.kernel.dev
|
$ nix-build '<nixpkgs>' -A linuxPackages.kernel.dev
|
||||||
$ nix-shell '<nixpkgs>' -A linuxPackages.kernel
|
$ nix-shell '<nixpkgs>' -A linuxPackages.kernel
|
||||||
$ unpackPhase
|
$ unpackPhase
|
||||||
@ -84,7 +83,5 @@ $ cd linux-*
|
|||||||
$ make -C $dev/lib/modules/*/build M=$(pwd)/drivers/net/ethernet/mellanox modules
|
$ make -C $dev/lib/modules/*/build M=$(pwd)/drivers/net/ethernet/mellanox modules
|
||||||
# insmod ./drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko
|
# insmod ./drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko
|
||||||
]]></screen>
|
]]></screen>
|
||||||
|
</section>
|
||||||
</section>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,14 +3,13 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-luks-file-systems">
|
xml:id="sec-luks-file-systems">
|
||||||
|
<title>LUKS-Encrypted File Systems</title>
|
||||||
|
|
||||||
<title>LUKS-Encrypted File Systems</title>
|
<para>
|
||||||
|
NixOS supports file systems that are encrypted using
|
||||||
<para>NixOS supports file systems that are encrypted using
|
<emphasis>LUKS</emphasis> (Linux Unified Key Setup). For example, here is how
|
||||||
<emphasis>LUKS</emphasis> (Linux Unified Key Setup). For example,
|
you create an encrypted Ext4 file system on the device
|
||||||
here is how you create an encrypted Ext4 file system on the device
|
<filename>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</filename>:
|
||||||
<filename>/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d</filename>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# cryptsetup luksFormat /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d
|
# cryptsetup luksFormat /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d
|
||||||
|
|
||||||
@ -27,20 +26,15 @@ Enter passphrase for /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d: ***
|
|||||||
|
|
||||||
# mkfs.ext4 /dev/mapper/crypted
|
# mkfs.ext4 /dev/mapper/crypted
|
||||||
</screen>
|
</screen>
|
||||||
|
To ensure that this file system is automatically mounted at boot time as
|
||||||
To ensure that this file system is automatically mounted at boot time
|
<filename>/</filename>, add the following to
|
||||||
as <filename>/</filename>, add the following to
|
<filename>configuration.nix</filename>:
|
||||||
<filename>configuration.nix</filename>:
|
|
||||||
|
|
||||||
<programlisting>
|
<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";
|
<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";
|
<xref linkend="opt-fileSystems"/>."/".device = "/dev/mapper/crypted";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Should grub be used as bootloader, and <filename>/boot</filename> is located
|
||||||
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:
|
||||||
on an encrypted partition, it is necessary to add the following grub option:
|
|
||||||
<programlisting><xref linkend="opt-boot.loader.grub.enableCryptodisk"/> = true;</programlisting>
|
<programlisting><xref linkend="opt-boot.loader.grub.enableCryptodisk"/> = true;</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,21 +3,21 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-modularity">
|
xml:id="sec-modularity">
|
||||||
|
<title>Modularity</title>
|
||||||
|
|
||||||
<title>Modularity</title>
|
<para>
|
||||||
|
The NixOS configuration mechanism is modular. If your
|
||||||
<para>The NixOS configuration mechanism is modular. If your
|
<filename>configuration.nix</filename> becomes too big, you can split it into
|
||||||
<filename>configuration.nix</filename> becomes too big, you can split
|
multiple files. Likewise, if you have multiple NixOS configurations (e.g. for
|
||||||
it into multiple files. Likewise, if you have multiple NixOS
|
different computers) with some commonality, you can move the common
|
||||||
configurations (e.g. for different computers) with some commonality,
|
configuration into a shared file.
|
||||||
you can move the common configuration into a shared file.</para>
|
</para>
|
||||||
|
|
||||||
<para>Modules have exactly the same syntax as
|
|
||||||
<filename>configuration.nix</filename>. In fact,
|
|
||||||
<filename>configuration.nix</filename> is itself a module. You can
|
|
||||||
use other modules by including them from
|
|
||||||
<filename>configuration.nix</filename>, e.g.:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Modules have exactly the same syntax as
|
||||||
|
<filename>configuration.nix</filename>. In fact,
|
||||||
|
<filename>configuration.nix</filename> is itself a module. You can use other
|
||||||
|
modules by including them from <filename>configuration.nix</filename>, e.g.:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
@ -27,11 +27,9 @@ use other modules by including them from
|
|||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Here, we include two modules from the same directory,
|
||||||
Here, we include two modules from the same directory,
|
<filename>vpn.nix</filename> and <filename>kde.nix</filename>. The latter
|
||||||
<filename>vpn.nix</filename> and <filename>kde.nix</filename>. The
|
might look like this:
|
||||||
latter might look like this:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
@ -40,59 +38,55 @@ latter might look like this:
|
|||||||
<xref linkend="opt-services.xserver.desktopManager.plasma5.enable"/> = true;
|
<xref linkend="opt-services.xserver.desktopManager.plasma5.enable"/> = true;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Note that both <filename>configuration.nix</filename> and
|
||||||
Note that both <filename>configuration.nix</filename> and
|
<filename>kde.nix</filename> define the option
|
||||||
<filename>kde.nix</filename> define the option
|
<xref linkend="opt-environment.systemPackages"/>. When multiple modules
|
||||||
<xref linkend="opt-environment.systemPackages"/>. When multiple modules
|
define an option, NixOS will try to <emphasis>merge</emphasis> the
|
||||||
define an option, NixOS will try to <emphasis>merge</emphasis> the
|
definitions. In the case of <xref linkend="opt-environment.systemPackages"/>,
|
||||||
definitions. In the case of
|
that’s easy: the lists of packages can simply be concatenated. The value in
|
||||||
<xref linkend="opt-environment.systemPackages"/>, that’s easy: the lists of
|
<filename>configuration.nix</filename> is merged last, so for list-type
|
||||||
packages can simply be concatenated. The value in
|
options, it will appear at the end of the merged list. If you want it to
|
||||||
<filename>configuration.nix</filename> is merged last, so for
|
appear first, you can use <varname>mkBefore</varname>:
|
||||||
list-type options, it will appear at the end of the merged list. If
|
|
||||||
you want it to appear first, you can use <varname>mkBefore</varname>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.kernelModules"/> = mkBefore [ "kvm-intel" ];
|
<xref linkend="opt-boot.kernelModules"/> = mkBefore [ "kvm-intel" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This causes the <literal>kvm-intel</literal> kernel module to be loaded
|
||||||
|
before any other kernel modules.
|
||||||
|
</para>
|
||||||
|
|
||||||
This causes the <literal>kvm-intel</literal> kernel module to be
|
<para>
|
||||||
loaded before any other kernel modules.</para>
|
For other types of options, a merge may not be possible. For instance, if two
|
||||||
|
modules define <xref linkend="opt-services.httpd.adminAddr"/>,
|
||||||
<para>For other types of options, a merge may not be possible. For
|
<command>nixos-rebuild</command> will give an error:
|
||||||
instance, if two modules define
|
|
||||||
<xref linkend="opt-services.httpd.adminAddr"/>,
|
|
||||||
<command>nixos-rebuild</command> will give an error:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
The unique option `services.httpd.adminAddr' is defined multiple times, in `/etc/nixos/httpd.nix' and `/etc/nixos/configuration.nix'.
|
The unique option `services.httpd.adminAddr' is defined multiple times, in `/etc/nixos/httpd.nix' and `/etc/nixos/configuration.nix'.
|
||||||
</screen>
|
</screen>
|
||||||
|
When that happens, it’s possible to force one definition take precedence
|
||||||
When that happens, it’s possible to force one definition take
|
over the others:
|
||||||
precedence over the others:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.httpd.adminAddr"/> = pkgs.lib.mkForce "bob@example.org";
|
<xref linkend="opt-services.httpd.adminAddr"/> = pkgs.lib.mkForce "bob@example.org";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
When using multiple modules, you may need to access configuration values
|
||||||
<para>When using multiple modules, you may need to access
|
defined in other modules. This is what the <varname>config</varname> function
|
||||||
configuration values defined in other modules. This is what the
|
argument is for: it contains the complete, merged system configuration. That
|
||||||
<varname>config</varname> function argument is for: it contains the
|
is, <varname>config</varname> is the result of combining the configurations
|
||||||
complete, merged system configuration. That is,
|
returned by every module
|
||||||
<varname>config</varname> is the result of combining the
|
<footnote>
|
||||||
configurations returned by every module<footnote><para>If you’re
|
<para>
|
||||||
wondering how it’s possible that the (indirect)
|
If you’re wondering how it’s possible that the (indirect)
|
||||||
<emphasis>result</emphasis> of a function is passed as an
|
<emphasis>result</emphasis> of a function is passed as an
|
||||||
<emphasis>input</emphasis> to that same function: that’s because Nix
|
<emphasis>input</emphasis> to that same function: that’s because Nix is a
|
||||||
is a “lazy” language — it only computes values when they are needed.
|
“lazy” language — it only computes values when they are needed. This
|
||||||
This works as long as no individual configuration value depends on
|
works as long as no individual configuration value depends on itself.
|
||||||
itself.</para></footnote>. For example, here is a module that adds
|
</para>
|
||||||
some packages to <xref linkend="opt-environment.systemPackages"/> only if
|
</footnote>
|
||||||
<xref linkend="opt-services.xserver.enable"/> is set to
|
. For example, here is a module that adds some packages to
|
||||||
<literal>true</literal> somewhere else:
|
<xref linkend="opt-environment.systemPackages"/> only if
|
||||||
|
<xref linkend="opt-services.xserver.enable"/> is set to
|
||||||
|
<literal>true</literal> somewhere else:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
@ -105,13 +99,12 @@ some packages to <xref linkend="opt-environment.systemPackages"/> only if
|
|||||||
[ ];
|
[ ];
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
With multiple modules, it may not be obvious what the final value of a
|
||||||
<para>With multiple modules, it may not be obvious what the final
|
configuration option is. The command <option>nixos-option</option> allows you
|
||||||
value of a configuration option is. The command
|
to find out:
|
||||||
<option>nixos-option</option> allows you to find out:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-option <xref linkend="opt-services.xserver.enable"/>
|
$ nixos-option <xref linkend="opt-services.xserver.enable"/>
|
||||||
true
|
true
|
||||||
@ -119,14 +112,11 @@ true
|
|||||||
$ nixos-option <xref linkend="opt-boot.kernelModules"/>
|
$ nixos-option <xref linkend="opt-boot.kernelModules"/>
|
||||||
[ "tun" "ipv6" "loop" <replaceable>...</replaceable> ]
|
[ "tun" "ipv6" "loop" <replaceable>...</replaceable> ]
|
||||||
</screen>
|
</screen>
|
||||||
|
Interactive exploration of the configuration is possible using
|
||||||
Interactive exploration of the configuration is possible using
|
<command
|
||||||
<command
|
|
||||||
xlink:href="https://github.com/edolstra/nix-repl">nix-repl</command>,
|
xlink:href="https://github.com/edolstra/nix-repl">nix-repl</command>,
|
||||||
a read-eval-print loop for Nix expressions. It’s not installed by
|
a read-eval-print loop for Nix expressions. It’s not installed by default;
|
||||||
default; run <literal>nix-env -i nix-repl</literal> to get it. A
|
run <literal>nix-env -i nix-repl</literal> to get it. A typical use:
|
||||||
typical use:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-repl '<nixpkgs/nixos>'
|
$ nix-repl '<nixpkgs/nixos>'
|
||||||
|
|
||||||
@ -136,7 +126,5 @@ nix-repl> config.<xref linkend="opt-networking.hostName"/>
|
|||||||
nix-repl> map (x: x.hostName) config.<xref linkend="opt-services.httpd.virtualHosts"/>
|
nix-repl> map (x: x.hostName) config.<xref linkend="opt-services.httpd.virtualHosts"/>
|
||||||
[ "example.org" "example.gov" ]
|
[ "example.org" "example.gov" ]
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,39 +3,42 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-networkmanager">
|
xml:id="sec-networkmanager">
|
||||||
|
<title>NetworkManager</title>
|
||||||
|
|
||||||
<title>NetworkManager</title>
|
<para>
|
||||||
|
To facilitate network configuration, some desktop environments use
|
||||||
<para>To facilitate network configuration, some desktop environments
|
NetworkManager. You can enable NetworkManager by setting:
|
||||||
use NetworkManager. You can enable NetworkManager by setting:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.networkmanager.enable"/> = true;
|
<xref linkend="opt-networking.networkmanager.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
some desktop managers (e.g., GNOME) enable NetworkManager automatically for
|
||||||
|
you.
|
||||||
|
</para>
|
||||||
|
|
||||||
some desktop managers (e.g., GNOME) enable NetworkManager
|
<para>
|
||||||
automatically for you.</para>
|
All users that should have permission to change network settings must belong
|
||||||
|
to the <code>networkmanager</code> group:
|
||||||
<para>All users that should have permission to change network settings must
|
|
||||||
belong to the <code>networkmanager</code> group:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<link linkend="opt-users.users._name__.extraGroups">users.extraUsers.youruser.extraGroups</link> = [ "networkmanager" ];
|
<link linkend="opt-users.users._name__.extraGroups">users.extraUsers.youruser.extraGroups</link> = [ "networkmanager" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>NetworkManager is controlled using either <command>nmcli</command> or
|
<para>
|
||||||
<command>nmtui</command> (curses-based terminal user interface). See their
|
NetworkManager is controlled using either <command>nmcli</command> or
|
||||||
manual pages for details on their usage. Some desktop environments (GNOME, KDE)
|
<command>nmtui</command> (curses-based terminal user interface). See their
|
||||||
have their own configuration tools for NetworkManager. On XFCE, there is no
|
manual pages for details on their usage. Some desktop environments (GNOME,
|
||||||
configuration tool for NetworkManager by default: by adding
|
KDE) have their own configuration tools for NetworkManager. On XFCE, there is
|
||||||
<code>networkmanagerapplet</code> to the list of system packages, the graphical
|
no configuration tool for NetworkManager by default: by adding
|
||||||
applet will be installed and will launch automatically when XFCE is starting
|
<code>networkmanagerapplet</code> to the list of system packages, the
|
||||||
(and will show in the status tray).</para>
|
graphical applet will be installed and will launch automatically when XFCE is
|
||||||
|
starting (and will show in the status tray).
|
||||||
<note><para><code>networking.networkmanager</code> and
|
</para>
|
||||||
<code>networking.wireless</code> (WPA Supplicant) cannot be enabled at the same
|
|
||||||
time: you can still connect to the wireless networks using
|
|
||||||
NetworkManager.</para></note>
|
|
||||||
|
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
<code>networking.networkmanager</code> and <code>networking.wireless</code>
|
||||||
|
(WPA Supplicant) cannot be enabled at the same time: you can still connect
|
||||||
|
to the wireless networks using NetworkManager.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,20 +3,17 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-networking">
|
xml:id="sec-networking">
|
||||||
|
<title>Networking</title>
|
||||||
<title>Networking</title>
|
<para>
|
||||||
|
This section describes how to configure networking components on your NixOS
|
||||||
<para>This section describes how to configure networking components on
|
machine.
|
||||||
your NixOS machine.</para>
|
</para>
|
||||||
|
<xi:include href="network-manager.xml" />
|
||||||
<xi:include href="network-manager.xml" />
|
<xi:include href="ssh.xml" />
|
||||||
<xi:include href="ssh.xml" />
|
<xi:include href="ipv4-config.xml" />
|
||||||
<xi:include href="ipv4-config.xml" />
|
<xi:include href="ipv6-config.xml" />
|
||||||
<xi:include href="ipv6-config.xml" />
|
<xi:include href="firewall.xml" />
|
||||||
<xi:include href="firewall.xml" />
|
<xi:include href="wireless.xml" />
|
||||||
<xi:include href="wireless.xml" />
|
<xi:include href="ad-hoc-network-config.xml" />
|
||||||
<xi:include href="ad-hoc-network-config.xml" />
|
|
||||||
|
|
||||||
<!-- TODO: OpenVPN, NAT -->
|
<!-- TODO: OpenVPN, NAT -->
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,32 +3,29 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-package-management">
|
xml:id="sec-package-management">
|
||||||
|
<title>Package Management</title>
|
||||||
<title>Package Management</title>
|
<para>
|
||||||
|
This section describes how to add additional packages to your system. NixOS
|
||||||
<para>This section describes how to add additional packages to your
|
has two distinct styles of package management:
|
||||||
system. NixOS has two distinct styles of package management:
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
<itemizedlist>
|
<para>
|
||||||
|
<emphasis>Declarative</emphasis>, where you declare what packages you want
|
||||||
<listitem><para><emphasis>Declarative</emphasis>, where you declare
|
in your <filename>configuration.nix</filename>. Every time you run
|
||||||
what packages you want in your
|
<command>nixos-rebuild</command>, NixOS will ensure that you get a
|
||||||
<filename>configuration.nix</filename>. Every time you run
|
consistent set of binaries corresponding to your specification.
|
||||||
<command>nixos-rebuild</command>, NixOS will ensure that you get a
|
</para>
|
||||||
consistent set of binaries corresponding to your
|
</listitem>
|
||||||
specification.</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para><emphasis>Ad hoc</emphasis>, where you install,
|
<emphasis>Ad hoc</emphasis>, where you install, upgrade and uninstall
|
||||||
upgrade and uninstall packages via the <command>nix-env</command>
|
packages via the <command>nix-env</command> command. This style allows
|
||||||
command. This style allows mixing packages from different Nixpkgs
|
mixing packages from different Nixpkgs versions. It’s the only choice
|
||||||
versions. It’s the only choice for non-root
|
for non-root users.
|
||||||
users.</para></listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
</para>
|
<xi:include href="declarative-packages.xml" />
|
||||||
|
<xi:include href="ad-hoc-packages.xml" />
|
||||||
<xi:include href="declarative-packages.xml" />
|
|
||||||
<xi:include href="ad-hoc-packages.xml" />
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,30 +3,25 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-ssh">
|
xml:id="sec-ssh">
|
||||||
|
<title>Secure Shell Access</title>
|
||||||
|
|
||||||
<title>Secure Shell Access</title>
|
<para>
|
||||||
|
Secure shell (SSH) access to your machine can be enabled by setting:
|
||||||
<para>Secure shell (SSH) access to your machine can be enabled by
|
|
||||||
setting:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.openssh.enable"/> = true;
|
<xref linkend="opt-services.openssh.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
By default, root logins using a password are disallowed. They can be disabled
|
||||||
|
entirely by setting <xref linkend="opt-services.openssh.permitRootLogin"/> to
|
||||||
|
<literal>"no"</literal>.
|
||||||
|
</para>
|
||||||
|
|
||||||
By default, root logins using a password are disallowed. They can be
|
<para>
|
||||||
disabled entirely by setting
|
You can declaratively specify authorised RSA/DSA public keys for a user as
|
||||||
<xref linkend="opt-services.openssh.permitRootLogin"/> to
|
follows:
|
||||||
<literal>"no"</literal>.</para>
|
|
||||||
|
|
||||||
<para>You can declaratively specify authorised RSA/DSA public keys for
|
|
||||||
a user as follows:
|
|
||||||
|
|
||||||
<!-- FIXME: this might not work if the user is unmanaged. -->
|
<!-- FIXME: this might not work if the user is unmanaged. -->
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">users.extraUsers.alice.openssh.authorizedKeys.keys</link> =
|
<link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">users.extraUsers.alice.openssh.authorizedKeys.keys</link> =
|
||||||
[ "ssh-dss AAAAB3NzaC1kc3MAAACBAPIkGWVEt4..." ];
|
[ "ssh-dss AAAAB3NzaC1kc3MAAACBAPIkGWVEt4..." ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,190 +3,225 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-nix-syntax-summary">
|
xml:id="sec-nix-syntax-summary">
|
||||||
|
<title>Syntax Summary</title>
|
||||||
|
|
||||||
<title>Syntax Summary</title>
|
<para>
|
||||||
|
Below is a summary of the most important syntactic constructs in the Nix
|
||||||
<para>Below is a summary of the most important syntactic constructs in
|
expression language. It’s not complete. In particular, there are many other
|
||||||
the Nix expression language. It’s not complete. In particular, there
|
built-in functions. See the
|
||||||
are many other built-in functions. See the <link
|
<link
|
||||||
xlink:href="http://nixos.org/nix/manual/#chap-writing-nix-expressions">Nix
|
xlink:href="http://nixos.org/nix/manual/#chap-writing-nix-expressions">Nix
|
||||||
manual</link> for the rest.</para>
|
manual</link> for the rest.
|
||||||
|
</para>
|
||||||
|
|
||||||
<informaltable frame='none'>
|
<informaltable frame='none'>
|
||||||
<tgroup cols='2'>
|
<tgroup cols='2'>
|
||||||
<colspec colname='c1' rowsep='1' colsep='1' />
|
<colspec colname='c1' rowsep='1' colsep='1' />
|
||||||
<colspec colname='c2' rowsep='1' />
|
<colspec colname='c2' rowsep='1' />
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
<entry>Example</entry>
|
<entry>Example</entry>
|
||||||
<entry>Description</entry>
|
<entry>Description</entry>
|
||||||
</row>
|
</row>
|
||||||
</thead>
|
</thead>
|
||||||
<tbody>
|
<tbody>
|
||||||
|
<row>
|
||||||
<row>
|
<entry namest="c1" nameend="c2"><emphasis>Basic values</emphasis>
|
||||||
<entry namest="c1" nameend="c2"><emphasis>Basic values</emphasis></entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>"Hello world"</literal></entry>
|
<entry><literal>"Hello world"</literal>
|
||||||
<entry>A string</entry>
|
</entry>
|
||||||
</row>
|
<entry>A string</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>"${pkgs.bash}/bin/sh"</literal></entry>
|
<row>
|
||||||
<entry>A string containing an expression (expands to <literal>"/nix/store/<replaceable>hash</replaceable>-bash-<replaceable>version</replaceable>/bin/sh"</literal>)</entry>
|
<entry><literal>"${pkgs.bash}/bin/sh"</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>A string containing an expression (expands to <literal>"/nix/store/<replaceable>hash</replaceable>-bash-<replaceable>version</replaceable>/bin/sh"</literal>)</entry>
|
||||||
<entry><literal>true</literal>, <literal>false</literal></entry>
|
</row>
|
||||||
<entry>Booleans</entry>
|
<row>
|
||||||
</row>
|
<entry><literal>true</literal>, <literal>false</literal>
|
||||||
<row>
|
</entry>
|
||||||
<entry><literal>123</literal></entry>
|
<entry>Booleans</entry>
|
||||||
<entry>An integer</entry>
|
</row>
|
||||||
</row>
|
<row>
|
||||||
<row>
|
<entry><literal>123</literal>
|
||||||
<entry><literal>./foo.png</literal></entry>
|
</entry>
|
||||||
<entry>A path (relative to the containing Nix expression)</entry>
|
<entry>An integer</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
<row>
|
<entry><literal>./foo.png</literal>
|
||||||
<entry namest="c1" nameend="c2"><emphasis>Compound values</emphasis></entry>
|
</entry>
|
||||||
</row>
|
<entry>A path (relative to the containing Nix expression)</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>{ x = 1; y = 2; }</literal></entry>
|
<row>
|
||||||
<entry>A set with attributes named <literal>x</literal> and <literal>y</literal></entry>
|
<entry namest="c1" nameend="c2"><emphasis>Compound values</emphasis>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>{ foo.bar = 1; }</literal></entry>
|
<row>
|
||||||
<entry>A nested set, equivalent to <literal>{ foo = { bar = 1; }; }</literal></entry>
|
<entry><literal>{ x = 1; y = 2; }</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>A set with attributes named <literal>x</literal> and <literal>y</literal>
|
||||||
<entry><literal>rec { x = "foo"; y = x + "bar"; }</literal></entry>
|
</entry>
|
||||||
<entry>A recursive set, equivalent to <literal>{ x = "foo"; y = "foobar"; }</literal></entry>
|
</row>
|
||||||
</row>
|
<row>
|
||||||
<row>
|
<entry><literal>{ foo.bar = 1; }</literal>
|
||||||
<entry><literal>[ "foo" "bar" ]</literal></entry>
|
</entry>
|
||||||
<entry>A list with two elements</entry>
|
<entry>A nested set, equivalent to <literal>{ foo = { bar = 1; }; }</literal>
|
||||||
</row>
|
</entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry namest="c1" nameend="c2"><emphasis>Operators</emphasis></entry>
|
<entry><literal>rec { x = "foo"; y = x + "bar"; }</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>A recursive set, equivalent to <literal>{ x = "foo"; y = "foobar"; }</literal>
|
||||||
<entry><literal>"foo" + "bar"</literal></entry>
|
</entry>
|
||||||
<entry>String concatenation</entry>
|
</row>
|
||||||
</row>
|
<row>
|
||||||
<row>
|
<entry><literal>[ "foo" "bar" ]</literal>
|
||||||
<entry><literal>1 + 2</literal></entry>
|
</entry>
|
||||||
<entry>Integer addition</entry>
|
<entry>A list with two elements</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>"foo" == "f" + "oo"</literal></entry>
|
<entry namest="c1" nameend="c2"><emphasis>Operators</emphasis>
|
||||||
<entry>Equality test (evaluates to <literal>true</literal>)</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>"foo" != "bar"</literal></entry>
|
<entry><literal>"foo" + "bar"</literal>
|
||||||
<entry>Inequality test (evaluates to <literal>true</literal>)</entry>
|
</entry>
|
||||||
</row>
|
<entry>String concatenation</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>!true</literal></entry>
|
<row>
|
||||||
<entry>Boolean negation</entry>
|
<entry><literal>1 + 2</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>Integer addition</entry>
|
||||||
<entry><literal>{ x = 1; y = 2; }.x</literal></entry>
|
</row>
|
||||||
<entry>Attribute selection (evaluates to <literal>1</literal>)</entry>
|
<row>
|
||||||
</row>
|
<entry><literal>"foo" == "f" + "oo"</literal>
|
||||||
<row>
|
</entry>
|
||||||
<entry><literal>{ x = 1; y = 2; }.z or 3</literal></entry>
|
<entry>Equality test (evaluates to <literal>true</literal>)</entry>
|
||||||
<entry>Attribute selection with default (evaluates to <literal>3</literal>)</entry>
|
</row>
|
||||||
</row>
|
<row>
|
||||||
<row>
|
<entry><literal>"foo" != "bar"</literal>
|
||||||
<entry><literal>{ x = 1; y = 2; } // { z = 3; }</literal></entry>
|
</entry>
|
||||||
<entry>Merge two sets (attributes in the right-hand set taking precedence)</entry>
|
<entry>Inequality test (evaluates to <literal>true</literal>)</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
<row>
|
<entry><literal>!true</literal>
|
||||||
<entry namest="c1" nameend="c2"><emphasis>Control structures</emphasis></entry>
|
</entry>
|
||||||
</row>
|
<entry>Boolean negation</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>if 1 + 1 == 2 then "yes!" else "no!"</literal></entry>
|
<row>
|
||||||
<entry>Conditional expression</entry>
|
<entry><literal>{ x = 1; y = 2; }.x</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>Attribute selection (evaluates to <literal>1</literal>)</entry>
|
||||||
<entry><literal>assert 1 + 1 == 2; "yes!"</literal></entry>
|
</row>
|
||||||
<entry>Assertion check (evaluates to <literal>"yes!"</literal>). See <xref
|
<row>
|
||||||
|
<entry><literal>{ x = 1; y = 2; }.z or 3</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>Attribute selection with default (evaluates to <literal>3</literal>)</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><literal>{ x = 1; y = 2; } // { z = 3; }</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>Merge two sets (attributes in the right-hand set taking precedence)</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry namest="c1" nameend="c2"><emphasis>Control structures</emphasis>
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><literal>if 1 + 1 == 2 then "yes!" else "no!"</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>Conditional expression</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><literal>assert 1 + 1 == 2; "yes!"</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>Assertion check (evaluates to <literal>"yes!"</literal>). See <xref
|
||||||
linkend="sec-assertions"/> for using assertions in modules</entry>
|
linkend="sec-assertions"/> for using assertions in modules</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>let x = "foo"; y = "bar"; in x + y</literal></entry>
|
<entry><literal>let x = "foo"; y = "bar"; in x + y</literal>
|
||||||
<entry>Variable definition</entry>
|
</entry>
|
||||||
</row>
|
<entry>Variable definition</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>with pkgs.lib; head [ 1 2 3 ]</literal></entry>
|
<row>
|
||||||
<entry>Add all attributes from the given set to the scope
|
<entry><literal>with pkgs.lib; head [ 1 2 3 ]</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>Add all attributes from the given set to the scope
|
||||||
(evaluates to <literal>1</literal>)</entry>
|
(evaluates to <literal>1</literal>)</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
<row>
|
<entry namest="c1" nameend="c2"><emphasis>Functions (lambdas)</emphasis>
|
||||||
<entry namest="c1" nameend="c2"><emphasis>Functions (lambdas)</emphasis></entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>x: x + 1</literal></entry>
|
<entry><literal>x: x + 1</literal>
|
||||||
<entry>A function that expects an integer and returns it increased by 1</entry>
|
</entry>
|
||||||
</row>
|
<entry>A function that expects an integer and returns it increased by 1</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>(x: x + 1) 100</literal></entry>
|
<row>
|
||||||
<entry>A function call (evaluates to 101)</entry>
|
<entry><literal>(x: x + 1) 100</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>A function call (evaluates to 101)</entry>
|
||||||
<entry><literal>let inc = x: x + 1; in inc (inc (inc 100))</literal></entry>
|
</row>
|
||||||
<entry>A function bound to a variable and subsequently called by name (evaluates to 103)</entry>
|
<row>
|
||||||
</row>
|
<entry><literal>let inc = x: x + 1; in inc (inc (inc 100))</literal>
|
||||||
<row>
|
</entry>
|
||||||
<entry><literal>{ x, y }: x + y</literal></entry>
|
<entry>A function bound to a variable and subsequently called by name (evaluates to 103)</entry>
|
||||||
<entry>A function that expects a set with required attributes
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><literal>{ x, y }: x + y</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>A function that expects a set with required attributes
|
||||||
<literal>x</literal> and <literal>y</literal> and concatenates
|
<literal>x</literal> and <literal>y</literal> and concatenates
|
||||||
them</entry>
|
them</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>{ x, y ? "bar" }: x + y</literal></entry>
|
<entry><literal>{ x, y ? "bar" }: x + y</literal>
|
||||||
<entry>A function that expects a set with required attribute
|
</entry>
|
||||||
|
<entry>A function that expects a set with required attribute
|
||||||
<literal>x</literal> and optional <literal>y</literal>, using
|
<literal>x</literal> and optional <literal>y</literal>, using
|
||||||
<literal>"bar"</literal> as default value for
|
<literal>"bar"</literal> as default value for
|
||||||
<literal>y</literal></entry>
|
<literal>y</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>{ x, y, ... }: x + y</literal></entry>
|
<row>
|
||||||
<entry>A function that expects a set with required attributes
|
<entry><literal>{ x, y, ... }: x + y</literal>
|
||||||
|
</entry>
|
||||||
|
<entry>A function that expects a set with required attributes
|
||||||
<literal>x</literal> and <literal>y</literal> and ignores any
|
<literal>x</literal> and <literal>y</literal> and ignores any
|
||||||
other attributes</entry>
|
other attributes</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>{ x, y } @ args: x + y</literal></entry>
|
<entry><literal>{ x, y } @ args: x + y</literal>
|
||||||
<entry>A function that expects a set with required attributes
|
</entry>
|
||||||
|
<entry>A function that expects a set with required attributes
|
||||||
<literal>x</literal> and <literal>y</literal>, and binds the
|
<literal>x</literal> and <literal>y</literal>, and binds the
|
||||||
whole set to <literal>args</literal></entry>
|
whole set to <literal>args</literal>
|
||||||
</row>
|
</entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry namest="c1" nameend="c2"><emphasis>Built-in functions</emphasis></entry>
|
<entry namest="c1" nameend="c2"><emphasis>Built-in functions</emphasis>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
</row>
|
||||||
<entry><literal>import ./foo.nix</literal></entry>
|
<row>
|
||||||
<entry>Load and return Nix expression in given file</entry>
|
<entry><literal>import ./foo.nix</literal>
|
||||||
</row>
|
</entry>
|
||||||
<row>
|
<entry>Load and return Nix expression in given file</entry>
|
||||||
<entry><literal>map (x: x + x) [ 1 2 3 ]</literal></entry>
|
</row>
|
||||||
<entry>Apply a function to every element of a list (evaluates to <literal>[ 2 4 6 ]</literal>)</entry>
|
<row>
|
||||||
</row>
|
<entry><literal>map (x: x + x) [ 1 2 3 ]</literal>
|
||||||
<!--
|
</entry>
|
||||||
|
<entry>Apply a function to every element of a list (evaluates to <literal>[ 2 4 6 ]</literal>)</entry>
|
||||||
|
</row>
|
||||||
|
<!--
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>throw "Urgh"</literal></entry>
|
<entry><literal>throw "Urgh"</literal></entry>
|
||||||
<entry>Raise an error condition</entry>
|
<entry>Raise an error condition</entry>
|
||||||
</row>
|
</row>
|
||||||
-->
|
-->
|
||||||
|
</tbody>
|
||||||
</tbody>
|
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</informaltable>
|
</informaltable>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,14 +3,12 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-user-management">
|
xml:id="sec-user-management">
|
||||||
|
<title>User Management</title>
|
||||||
<title>User Management</title>
|
<para>
|
||||||
|
NixOS supports both declarative and imperative styles of user management. In
|
||||||
<para>NixOS supports both declarative and imperative styles of user
|
the declarative style, users are specified in
|
||||||
management. In the declarative style, users are specified in
|
<filename>configuration.nix</filename>. For instance, the following states
|
||||||
<filename>configuration.nix</filename>. For instance, the following
|
that a user account named <literal>alice</literal> shall exist:
|
||||||
states that a user account named <literal>alice</literal> shall exist:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-users.users"/>.alice = {
|
<xref linkend="opt-users.users"/>.alice = {
|
||||||
<link linkend="opt-users.users._name__.isNormalUser">isNormalUser</link> = true;
|
<link linkend="opt-users.users._name__.isNormalUser">isNormalUser</link> = true;
|
||||||
@ -20,81 +18,71 @@ states that a user account named <literal>alice</literal> shall exist:
|
|||||||
<link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">openssh.authorizedKeys.keys</link> = [ "ssh-dss AAAAB3Nza... alice@foobar" ];
|
<link linkend="opt-users.users._name__.openssh.authorizedKeys.keys">openssh.authorizedKeys.keys</link> = [ "ssh-dss AAAAB3Nza... alice@foobar" ];
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Note that <literal>alice</literal> is a member of the
|
||||||
Note that <literal>alice</literal> is a member of the
|
<literal>wheel</literal> and <literal>networkmanager</literal> groups, which
|
||||||
<literal>wheel</literal> and <literal>networkmanager</literal> groups,
|
allows her to use <command>sudo</command> to execute commands as
|
||||||
which allows her to use <command>sudo</command> to execute commands as
|
<literal>root</literal> and to configure the network, respectively. Also note
|
||||||
<literal>root</literal> and to configure the network, respectively.
|
the SSH public key that allows remote logins with the corresponding private
|
||||||
Also note the SSH public key that allows remote logins with the
|
key. Users created in this way do not have a password by default, so they
|
||||||
corresponding private key. Users created in this way do not have a
|
cannot log in via mechanisms that require a password. However, you can use
|
||||||
password by default, so they cannot log in via mechanisms that require
|
the <command>passwd</command> program to set a password, which is retained
|
||||||
a password. However, you can use the <command>passwd</command> program
|
across invocations of <command>nixos-rebuild</command>.
|
||||||
to set a password, which is retained across invocations of
|
</para>
|
||||||
<command>nixos-rebuild</command>.</para>
|
<para>
|
||||||
|
If you set <xref linkend="opt-users.mutableUsers"/> to false, then the
|
||||||
<para>If you set <xref linkend="opt-users.mutableUsers"/> to false, then the contents of
|
contents of <literal>/etc/passwd</literal> and <literal>/etc/group</literal>
|
||||||
<literal>/etc/passwd</literal> and <literal>/etc/group</literal> will be congruent to
|
will be congruent to your NixOS configuration. For instance, if you remove a
|
||||||
your NixOS configuration. For instance, if you remove a user from <xref linkend="opt-users.users"/>
|
user from <xref linkend="opt-users.users"/> and run nixos-rebuild, the user
|
||||||
and run nixos-rebuild, the user account will cease to exist. Also, imperative commands for managing users
|
account will cease to exist. Also, imperative commands for managing users and
|
||||||
and groups, such as useradd, are no longer available. Passwords may still be
|
groups, such as useradd, are no longer available. Passwords may still be
|
||||||
assigned by setting the user's <link linkend="opt-users.users._name__.hashedPassword">hashedPassword</link>
|
assigned by setting the user's
|
||||||
option. A hashed password can be generated using <command>mkpasswd -m sha-512</command>
|
<link linkend="opt-users.users._name__.hashedPassword">hashedPassword</link>
|
||||||
after installing the <literal>mkpasswd</literal> package.</para>
|
option. A hashed password can be generated using <command>mkpasswd -m
|
||||||
|
sha-512</command> after installing the <literal>mkpasswd</literal> package.
|
||||||
<para>A user ID (uid) is assigned automatically. You can also specify
|
</para>
|
||||||
a uid manually by adding
|
<para>
|
||||||
|
A user ID (uid) is assigned automatically. You can also specify a uid
|
||||||
|
manually by adding
|
||||||
<programlisting>
|
<programlisting>
|
||||||
uid = 1000;
|
uid = 1000;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
to the user specification.
|
||||||
to the user specification.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>Groups can be specified similarly. The following states that a
|
Groups can be specified similarly. The following states that a group named
|
||||||
group named <literal>students</literal> shall exist:
|
<literal>students</literal> shall exist:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-users.groups"/>.students.gid = 1000;
|
<xref linkend="opt-users.groups"/>.students.gid = 1000;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
As with users, the group ID (gid) is optional and will be assigned
|
||||||
As with users, the group ID (gid) is optional and will be assigned
|
automatically if it’s missing.
|
||||||
automatically if it’s missing.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>In the imperative style, users and groups are managed by
|
In the imperative style, users and groups are managed by commands such as
|
||||||
commands such as <command>useradd</command>,
|
<command>useradd</command>, <command>groupmod</command> and so on. For
|
||||||
<command>groupmod</command> and so on. For instance, to create a user
|
instance, to create a user account named <literal>alice</literal>:
|
||||||
account named <literal>alice</literal>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# useradd -m alice</screen>
|
# useradd -m alice</screen>
|
||||||
|
To make all nix tools available to this new user use `su - USER` which opens
|
||||||
To make all nix tools available to this new user use `su - USER` which
|
a login shell (==shell that loads the profile) for given user. This will
|
||||||
opens a login shell (==shell that loads the profile) for given user.
|
create the ~/.nix-defexpr symlink. So run:
|
||||||
This will create the ~/.nix-defexpr symlink. So run:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# su - alice -c "true"</screen>
|
# su - alice -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
|
||||||
The flag <option>-m</option> causes the creation of a home directory
|
password and therefore cannot log in. A password can be set using the
|
||||||
for the new user, which is generally what you want. The user does not
|
<command>passwd</command> utility:
|
||||||
have an initial password and therefore cannot log in. A password can
|
|
||||||
be set using the <command>passwd</command> utility:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# passwd alice
|
# passwd alice
|
||||||
Enter new UNIX password: ***
|
Enter new UNIX password: ***
|
||||||
Retype new UNIX password: ***
|
Retype new UNIX password: ***
|
||||||
</screen>
|
</screen>
|
||||||
|
A user can be deleted using <command>userdel</command>:
|
||||||
A user can be deleted using <command>userdel</command>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# userdel -r alice</screen>
|
# userdel -r alice</screen>
|
||||||
|
The flag <option>-r</option> deletes the user’s home directory. Accounts
|
||||||
The flag <option>-r</option> deletes the user’s home directory.
|
can be modified using <command>usermod</command>. Unix groups can be managed
|
||||||
Accounts can be modified using <command>usermod</command>. Unix
|
using <command>groupadd</command>, <command>groupmod</command> and
|
||||||
groups can be managed using <command>groupadd</command>,
|
<command>groupdel</command>.
|
||||||
<command>groupmod</command> and <command>groupdel</command>.</para>
|
</para>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,22 +3,20 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-wireless">
|
xml:id="sec-wireless">
|
||||||
|
<title>Wireless Networks</title>
|
||||||
|
|
||||||
<title>Wireless Networks</title>
|
<para>
|
||||||
|
For a desktop installation using NetworkManager (e.g., GNOME), you just have
|
||||||
<para>For a desktop installation using NetworkManager (e.g., GNOME),
|
to make sure the user is in the <code>networkmanager</code> group and you can
|
||||||
you just have to make sure the user is in the
|
skip the rest of this section on wireless networks.
|
||||||
<code>networkmanager</code> group and you can skip the rest of this
|
</para>
|
||||||
section on wireless networks.</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
NixOS will start wpa_supplicant for you if you enable this setting:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
NixOS will start wpa_supplicant for you if you enable this setting:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.wireless.enable"/> = true;
|
<xref linkend="opt-networking.wireless.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
NixOS lets you specify networks for wpa_supplicant declaratively:
|
||||||
NixOS lets you specify networks for wpa_supplicant declaratively:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-networking.wireless.networks"/> = {
|
<xref linkend="opt-networking.wireless.networks"/> = {
|
||||||
echelon = {
|
echelon = {
|
||||||
@ -27,27 +25,21 @@ NixOS lets you specify networks for wpa_supplicant declaratively:
|
|||||||
"free.wifi" = {};
|
"free.wifi" = {};
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Be aware that keys will be written to the nix store in plaintext! When no
|
||||||
|
networks are set, it will default to using a configuration file at
|
||||||
|
<literal>/etc/wpa_supplicant.conf</literal>. You should edit this file
|
||||||
|
yourself to define wireless networks, WPA keys and so on (see
|
||||||
|
wpa_supplicant.conf(5)).
|
||||||
|
</para>
|
||||||
|
|
||||||
Be aware that keys will be written to the nix store in plaintext!
|
<para>
|
||||||
|
If you are using WPA2 the <command>wpa_passphrase</command> tool might be
|
||||||
When no networks are set, it will default to using a configuration file at
|
useful to generate the <literal>wpa_supplicant.conf</literal>.
|
||||||
<literal>/etc/wpa_supplicant.conf</literal>. You should edit this file
|
|
||||||
yourself to define wireless networks, WPA keys and so on (see
|
|
||||||
wpa_supplicant.conf(5)).
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If you are using WPA2 the <command>wpa_passphrase</command> tool might be useful
|
|
||||||
to generate the <literal>wpa_supplicant.conf</literal>.
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# wpa_passphrase ESSID PSK > /etc/wpa_supplicant.conf</screen>
|
# wpa_passphrase ESSID PSK > /etc/wpa_supplicant.conf</screen>
|
||||||
|
After you have edited the <literal>wpa_supplicant.conf</literal>, you need to
|
||||||
After you have edited the <literal>wpa_supplicant.conf</literal>,
|
restart the wpa_supplicant service.
|
||||||
you need to restart the wpa_supplicant service.
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl restart wpa_supplicant.service</screen>
|
# systemctl restart wpa_supplicant.service</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,27 +3,25 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-x11">
|
xml:id="sec-x11">
|
||||||
|
<title>X Window System</title>
|
||||||
<title>X Window System</title>
|
<para>
|
||||||
|
The X Window System (X11) provides the basis of NixOS’ graphical user
|
||||||
<para>The X Window System (X11) provides the basis of NixOS’ graphical
|
interface. It can be enabled as follows:
|
||||||
user interface. It can be enabled as follows:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.enable"/> = true;
|
<xref linkend="opt-services.xserver.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The X server will automatically detect and use the appropriate video
|
The X server will automatically detect and use the appropriate video driver
|
||||||
driver from a set of X.org drivers (such as <literal>vesa</literal>
|
from a set of X.org drivers (such as <literal>vesa</literal> and
|
||||||
and <literal>intel</literal>). You can also specify a driver
|
<literal>intel</literal>). You can also specify a driver manually, e.g.
|
||||||
manually, e.g.
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "r128" ];
|
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "r128" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
to enable X.org’s <literal>xf86-video-r128</literal> driver.</para>
|
to enable X.org’s <literal>xf86-video-r128</literal> driver.
|
||||||
|
</para>
|
||||||
<para>You also need to enable at least one desktop or window manager.
|
<para>
|
||||||
Otherwise, you can only log into a plain undecorated
|
You also need to enable at least one desktop or window manager. Otherwise,
|
||||||
<command>xterm</command> window. Thus you should pick one or more of
|
you can only log into a plain undecorated <command>xterm</command> window.
|
||||||
the following lines:
|
Thus you should pick one or more of the following lines:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.desktopManager.plasma5.enable"/> = true;
|
<xref linkend="opt-services.xserver.desktopManager.plasma5.enable"/> = true;
|
||||||
<xref linkend="opt-services.xserver.desktopManager.xfce.enable"/> = true;
|
<xref linkend="opt-services.xserver.desktopManager.xfce.enable"/> = true;
|
||||||
@ -33,108 +31,105 @@ the following lines:
|
|||||||
<xref linkend="opt-services.xserver.windowManager.icewm.enable"/> = true;
|
<xref linkend="opt-services.xserver.windowManager.icewm.enable"/> = true;
|
||||||
<xref linkend="opt-services.xserver.windowManager.i3.enable"/> = true;
|
<xref linkend="opt-services.xserver.windowManager.i3.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>NixOS’s default <emphasis>display manager</emphasis> (the
|
NixOS’s default <emphasis>display manager</emphasis> (the program that
|
||||||
program that provides a graphical login prompt and manages the X
|
provides a graphical login prompt and manages the X server) is SLiM. You can
|
||||||
server) is SLiM. You can select an alternative one by picking one
|
select an alternative one by picking one of the following lines:
|
||||||
of the following lines:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.displayManager.sddm.enable"/> = true;
|
<xref linkend="opt-services.xserver.displayManager.sddm.enable"/> = true;
|
||||||
<xref linkend="opt-services.xserver.displayManager.lightdm.enable"/> = true;
|
<xref linkend="opt-services.xserver.displayManager.lightdm.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>You can set the keyboard layout (and optionally the layout variant):
|
You can set the keyboard layout (and optionally the layout variant):
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.layout"/> = "de";
|
<xref linkend="opt-services.xserver.layout"/> = "de";
|
||||||
<xref linkend="opt-services.xserver.xkbVariant"/> = "neo";
|
<xref linkend="opt-services.xserver.xkbVariant"/> = "neo";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>The X server is started automatically at boot time. If you
|
The X server is started automatically at boot time. If you don’t want this
|
||||||
don’t want this to happen, you can set:
|
to happen, you can set:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.autorun"/> = false;
|
<xref linkend="opt-services.xserver.autorun"/> = false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The X server can then be started manually:
|
The X server can then be started manually:
|
||||||
<screen>
|
<screen>
|
||||||
# systemctl start display-manager.service
|
# systemctl start display-manager.service
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
<simplesect>
|
||||||
|
<title>NVIDIA Graphics Cards</title>
|
||||||
<simplesect><title>NVIDIA Graphics Cards</title>
|
<para>
|
||||||
|
NVIDIA provides a proprietary driver for its graphics cards that has better
|
||||||
<para>NVIDIA provides a proprietary driver for its graphics cards that
|
3D performance than the X.org drivers. It is not enabled by default because
|
||||||
has better 3D performance than the X.org drivers. It is not enabled
|
it’s not free software. You can enable it as follows:
|
||||||
by default because it’s not free software. You can enable it as follows:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidia" ];
|
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidia" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Or if you have an older card, you may have to use one of the legacy drivers:
|
Or if you have an older card, you may have to use one of the legacy drivers:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidiaLegacy340" ];
|
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidiaLegacy340" ];
|
||||||
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidiaLegacy304" ];
|
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidiaLegacy304" ];
|
||||||
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidiaLegacy173" ];
|
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "nvidiaLegacy173" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
You may need to reboot after enabling this driver to prevent a clash
|
You may need to reboot after enabling this driver to prevent a clash with
|
||||||
with other kernel modules.</para>
|
other kernel modules.
|
||||||
|
</para>
|
||||||
<para>On 64-bit systems, if you want full acceleration for 32-bit
|
<para>
|
||||||
programs such as Wine, you should also set the following:
|
On 64-bit systems, if you want full acceleration for 32-bit programs such as
|
||||||
|
Wine, you should also set the following:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-hardware.opengl.driSupport32Bit"/> = true;
|
<xref linkend="opt-hardware.opengl.driSupport32Bit"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
</simplesect>
|
||||||
</simplesect>
|
<simplesect>
|
||||||
|
<title>AMD Graphics Cards</title>
|
||||||
<simplesect><title>AMD Graphics Cards</title>
|
<para>
|
||||||
|
AMD provides a proprietary driver for its graphics cards that has better 3D
|
||||||
<para>AMD provides a proprietary driver for its graphics cards that
|
performance than the X.org drivers. It is not enabled by default because
|
||||||
has better 3D performance than the X.org drivers. It is not enabled
|
it’s not free software. You can enable it as follows:
|
||||||
by default because it’s not free software. You can enable it as follows:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "ati_unfree" ];
|
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "ati_unfree" ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
You will need to reboot after enabling this driver to prevent a clash
|
You will need to reboot after enabling this driver to prevent a clash with
|
||||||
with other kernel modules.</para>
|
other kernel modules.
|
||||||
|
</para>
|
||||||
<para>On 64-bit systems, if you want full acceleration for 32-bit
|
<para>
|
||||||
programs such as Wine, you should also set the following:
|
On 64-bit systems, if you want full acceleration for 32-bit programs such as
|
||||||
|
Wine, you should also set the following:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-hardware.opengl.driSupport32Bit"/> = true;
|
<xref linkend="opt-hardware.opengl.driSupport32Bit"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
</simplesect>
|
||||||
</simplesect>
|
<simplesect>
|
||||||
|
<title>Touchpads</title>
|
||||||
<simplesect><title>Touchpads</title>
|
<para>
|
||||||
|
Support for Synaptics touchpads (found in many laptops such as the Dell
|
||||||
<para>Support for Synaptics touchpads (found in many laptops such as
|
Latitude series) can be enabled as follows:
|
||||||
the Dell Latitude series) can be enabled as follows:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.libinput.enable"/> = true;
|
<xref linkend="opt-services.xserver.libinput.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The driver has many options (see <xref linkend="ch-options"/>). For
|
The driver has many options (see <xref linkend="ch-options"/>). For
|
||||||
instance, the following disables tap-to-click behavior:
|
instance, the following disables tap-to-click behavior:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-services.xserver.libinput.tapping"/> = false;
|
<xref linkend="opt-services.xserver.libinput.tapping"/> = false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Note: the use of <literal>services.xserver.synaptics</literal> is deprecated since NixOS 17.09.
|
Note: the use of <literal>services.xserver.synaptics</literal> is deprecated
|
||||||
</para>
|
since NixOS 17.09.
|
||||||
|
</para>
|
||||||
</simplesect>
|
</simplesect>
|
||||||
|
<simplesect>
|
||||||
<simplesect><title>GTK/Qt themes</title>
|
<title>GTK/Qt themes</title>
|
||||||
|
<para>
|
||||||
<para>GTK themes can be installed either to user profile or system-wide (via
|
GTK themes can be installed either to user profile or system-wide (via
|
||||||
<literal>environment.systemPackages</literal>). To make Qt 5 applications look similar
|
<literal>environment.systemPackages</literal>). To make Qt 5 applications
|
||||||
to GTK2 ones, you can install <literal>qt5.qtbase.gtk</literal> package into your
|
look similar to GTK2 ones, you can install <literal>qt5.qtbase.gtk</literal>
|
||||||
system environment. It should work for all Qt 5 library versions.
|
package into your system environment. It should work for all Qt 5 library
|
||||||
</para>
|
versions.
|
||||||
|
</para>
|
||||||
</simplesect>
|
</simplesect>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,23 +3,20 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-xfce">
|
xml:id="sec-xfce">
|
||||||
|
<title>Xfce Desktop Environment</title>
|
||||||
<title>Xfce Desktop Environment</title>
|
<para>
|
||||||
|
To enable the Xfce Desktop Environment, set
|
||||||
<para>
|
<programlisting>
|
||||||
To enable the Xfce Desktop Environment, set
|
|
||||||
<programlisting>
|
|
||||||
<link linkend="opt-services.xserver.desktopManager.default">services.xserver.desktopManager</link> = {
|
<link linkend="opt-services.xserver.desktopManager.default">services.xserver.desktopManager</link> = {
|
||||||
<link linkend="opt-services.xserver.desktopManager.xfce.enable">xfce.enable</link> = true;
|
<link linkend="opt-services.xserver.desktopManager.xfce.enable">xfce.enable</link> = true;
|
||||||
<link linkend="opt-services.xserver.desktopManager.default">default</link> = "xfce";
|
<link linkend="opt-services.xserver.desktopManager.default">default</link> = "xfce";
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>
|
Optionally, <emphasis>compton</emphasis> can be enabled for nice graphical
|
||||||
Optionally, <emphasis>compton</emphasis>
|
effects, some example settings:
|
||||||
can be enabled for nice graphical effects, some example settings:
|
<programlisting>
|
||||||
<programlisting>
|
|
||||||
<link linkend="opt-services.compton.enable">services.compton</link> = {
|
<link linkend="opt-services.compton.enable">services.compton</link> = {
|
||||||
<link linkend="opt-services.compton.enable">enable</link> = true;
|
<link linkend="opt-services.compton.enable">enable</link> = true;
|
||||||
<link linkend="opt-services.compton.fade">fade</link> = true;
|
<link linkend="opt-services.compton.fade">fade</link> = true;
|
||||||
@ -28,67 +25,48 @@
|
|||||||
<link linkend="opt-services.compton.fadeDelta">fadeDelta</link> = 4;
|
<link linkend="opt-services.compton.fadeDelta">fadeDelta</link> = 4;
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>
|
Some Xfce programs are not installed automatically. To install them manually
|
||||||
Some Xfce programs are not installed automatically.
|
(system wide), put them into your
|
||||||
To install them manually (system wide), put them into your
|
<xref linkend="opt-environment.systemPackages"/>.
|
||||||
<xref linkend="opt-environment.systemPackages"/>.
|
</para>
|
||||||
</para>
|
<simplesect>
|
||||||
|
<title>Thunar Volume Support</title>
|
||||||
<simplesect>
|
<para>
|
||||||
<title>Thunar Volume Support</title>
|
To enable <emphasis>Thunar</emphasis> volume support, put
|
||||||
|
<programlisting>
|
||||||
<para>
|
|
||||||
To enable
|
|
||||||
<emphasis>Thunar</emphasis>
|
|
||||||
volume support, put
|
|
||||||
<programlisting>
|
|
||||||
<xref linkend="opt-services.xserver.desktopManager.xfce.enable"/> = true;
|
<xref linkend="opt-services.xserver.desktopManager.xfce.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
into your <emphasis>configuration.nix</emphasis>.
|
into your <emphasis>configuration.nix</emphasis>.
|
||||||
</para>
|
</para>
|
||||||
|
</simplesect>
|
||||||
</simplesect>
|
<simplesect>
|
||||||
|
<title>Polkit Authentication Agent</title>
|
||||||
<simplesect>
|
<para>
|
||||||
<title>Polkit Authentication Agent</title>
|
There is no authentication agent automatically installed alongside Xfce. To
|
||||||
|
allow mounting of local (non-removable) filesystems, you will need to
|
||||||
<para>
|
install one. Installing <emphasis>polkit_gnome</emphasis>, a rebuild, logout
|
||||||
There is no authentication agent automatically installed alongside
|
and login did the trick.
|
||||||
Xfce. To allow mounting of local (non-removable) filesystems, you
|
</para>
|
||||||
will need to install one.
|
</simplesect>
|
||||||
|
<simplesect>
|
||||||
Installing <emphasis>polkit_gnome</emphasis>, a rebuild, logout and
|
<title>Troubleshooting</title>
|
||||||
login did the trick.
|
<para>
|
||||||
</para>
|
Even after enabling udisks2, volume management might not work. Thunar and/or
|
||||||
|
the desktop takes time to show up. Thunar will spit out this kind of message
|
||||||
</simplesect>
|
on start (look at <command>journalctl --user -b</command>).
|
||||||
|
<programlisting>
|
||||||
<simplesect>
|
|
||||||
<title>Troubleshooting</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Even after enabling udisks2, volume management might not work.
|
|
||||||
Thunar and/or the desktop takes time to show up.
|
|
||||||
|
|
||||||
Thunar will spit out this kind of message on start
|
|
||||||
(look at <command>journalctl --user -b</command>).
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with dbus name org.gtk.Private.UDisks2VolumeMonitor is not supported
|
Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with dbus name org.gtk.Private.UDisks2VolumeMonitor is not supported
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This is caused by some needed GNOME services not running. This is all fixed
|
||||||
This is caused by some needed GNOME services not running.
|
by enabling "Launch GNOME services on startup" in the Advanced tab of the
|
||||||
This is all fixed by enabling "Launch GNOME services on startup" in
|
Session and Startup settings panel. Alternatively, you can run this command
|
||||||
the Advanced tab of the Session and Startup settings panel.
|
to do the same thing.
|
||||||
Alternatively, you can run this command to do the same thing.
|
<programlisting>
|
||||||
<programlisting>
|
|
||||||
$ xfconf-query -c xfce4-session -p /compat/LaunchGNOME -s true
|
$ xfconf-query -c xfce4-session -p /compat/LaunchGNOME -s true
|
||||||
</programlisting>
|
</programlisting>
|
||||||
A log-out and re-log will be needed for this to take effect.
|
A log-out and re-log will be needed for this to take effect.
|
||||||
</para>
|
</para>
|
||||||
|
</simplesect>
|
||||||
</simplesect>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,30 +3,29 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-assertions">
|
xml:id="sec-assertions">
|
||||||
|
<title>Warnings and Assertions</title>
|
||||||
|
|
||||||
<title>Warnings and Assertions</title>
|
<para>
|
||||||
|
When configuration problems are detectable in a module, it is a good idea to
|
||||||
|
write an assertion or warning. Doing so provides clear feedback to the user
|
||||||
|
and prevents errors after the build.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When configuration problems are detectable in a module, it is a good
|
|
||||||
idea to write an assertion or warning. Doing so provides clear
|
|
||||||
feedback to the user and prevents errors after the build.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Although Nix has the <literal>abort</literal> and
|
Although Nix has the <literal>abort</literal> and
|
||||||
<literal>builtins.trace</literal> <link xlink:href="https://nixos.org/nix/manual/#ssec-builtins">functions</link> to perform such tasks,
|
<literal>builtins.trace</literal>
|
||||||
they are not ideally suited for NixOS modules. Instead of these
|
<link xlink:href="https://nixos.org/nix/manual/#ssec-builtins">functions</link>
|
||||||
functions, you can declare your warnings and assertions using the
|
to perform such tasks, they are not ideally suited for NixOS modules. Instead
|
||||||
|
of these functions, you can declare your warnings and assertions using the
|
||||||
NixOS module system.
|
NixOS module system.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
|
<title>Warnings</title>
|
||||||
|
|
||||||
<title>Warnings</title>
|
<para>
|
||||||
|
This is an example of using <literal>warnings</literal>.
|
||||||
<para>
|
</para>
|
||||||
This is an example of using <literal>warnings</literal>.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<![CDATA[
|
<![CDATA[
|
||||||
@ -43,22 +42,19 @@
|
|||||||
}
|
}
|
||||||
]]>
|
]]>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</section>
|
||||||
|
|
||||||
</section>
|
<section>
|
||||||
|
<title>Assertions</title>
|
||||||
|
|
||||||
<section>
|
<para>
|
||||||
|
This example, extracted from the
|
||||||
<title>Assertions</title>
|
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/release-17.09/nixos/modules/services/logging/syslogd.nix">
|
||||||
|
<literal>syslogd</literal> module </link> shows how to use
|
||||||
|
<literal>assertions</literal>. Since there can only be one active syslog
|
||||||
<para>
|
daemon at a time, an assertion is useful to prevent such a broken system
|
||||||
This example, extracted from the
|
from being built.
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/release-17.09/nixos/modules/services/logging/syslogd.nix">
|
</para>
|
||||||
<literal>syslogd</literal> module
|
|
||||||
</link> shows how to use <literal>assertions</literal>. Since there
|
|
||||||
can only be one active syslog daemon at a time, an assertion is useful to
|
|
||||||
prevent such a broken system from being built.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<![CDATA[
|
<![CDATA[
|
||||||
@ -74,7 +70,5 @@
|
|||||||
}
|
}
|
||||||
]]>
|
]]>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</section>
|
||||||
</section>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,30 +3,25 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-building-cd">
|
xml:id="sec-building-cd">
|
||||||
|
<title>Building Your Own NixOS CD</title>
|
||||||
<title>Building Your Own NixOS CD</title>
|
<para>
|
||||||
|
Building a NixOS CD is as easy as configuring your own computer. The idea is
|
||||||
<para>Building a NixOS CD is as easy as configuring your own computer. The
|
to use another module which will replace your
|
||||||
idea is to use another module which will replace
|
<filename>configuration.nix</filename> to configure the system that would be
|
||||||
your <filename>configuration.nix</filename> to configure the system that
|
installed on the CD.
|
||||||
would be installed on the CD.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>Default CD/DVD configurations are available
|
Default CD/DVD configurations are available inside
|
||||||
inside <filename>nixos/modules/installer/cd-dvd</filename>.
|
<filename>nixos/modules/installer/cd-dvd</filename>.
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ git clone https://github.com/NixOS/nixpkgs.git
|
$ git clone https://github.com/NixOS/nixpkgs.git
|
||||||
$ cd nixpkgs/nixos
|
$ cd nixpkgs/nixos
|
||||||
$ nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal.nix default.nix</screen>
|
$ nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal.nix default.nix</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
Before burning your CD/DVD, you can check the content of the image by
|
||||||
<para>Before burning your CD/DVD, you can check the content of the image by mounting anywhere like
|
mounting anywhere like suggested by the following command:
|
||||||
suggested by the following command:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# mount -o loop -t iso9660 ./result/iso/cd.iso /mnt/iso</screen>
|
# mount -o loop -t iso9660 ./result/iso/cd.iso /mnt/iso</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,111 +3,110 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-building-parts">
|
xml:id="sec-building-parts">
|
||||||
|
<title>Building Specific Parts of NixOS</title>
|
||||||
<title>Building Specific Parts of NixOS</title>
|
<para>
|
||||||
|
With the command <command>nix-build</command>, you can build specific parts
|
||||||
<para>With the command <command>nix-build</command>, you can build
|
of your NixOS configuration. This is done as follows:
|
||||||
specific parts of your NixOS configuration. This is done as follows:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ cd <replaceable>/path/to/nixpkgs/nixos</replaceable>
|
$ cd <replaceable>/path/to/nixpkgs/nixos</replaceable>
|
||||||
$ nix-build -A config.<replaceable>option</replaceable></screen>
|
$ nix-build -A config.<replaceable>option</replaceable></screen>
|
||||||
|
where <replaceable>option</replaceable> is a NixOS option with type
|
||||||
where <replaceable>option</replaceable> is a NixOS option with type
|
“derivation” (i.e. something that can be built). Attributes of interest
|
||||||
“derivation” (i.e. something that can be built). Attributes of
|
include:
|
||||||
interest include:
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><varname>system.build.toplevel</varname>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
|
||||||
<term><varname>system.build.toplevel</varname></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The top-level option that builds the entire NixOS system.
|
<para>
|
||||||
Everything else in your configuration is indirectly pulled in by
|
The top-level option that builds the entire NixOS system. Everything else
|
||||||
this option. This is what <command>nixos-rebuild</command>
|
in your configuration is indirectly pulled in by this option. This is
|
||||||
builds and what <filename>/run/current-system</filename> points
|
what <command>nixos-rebuild</command> builds and what
|
||||||
to afterwards.</para>
|
<filename>/run/current-system</filename> points to afterwards.
|
||||||
|
</para>
|
||||||
<para>A shortcut to build this is:
|
<para>
|
||||||
|
A shortcut to build this is:
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build -A system</screen>
|
$ nix-build -A system</screen>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><varname>system.build.manual.manual</varname>
|
||||||
<term><varname>system.build.manual.manual</varname></term>
|
</term>
|
||||||
<listitem><para>The NixOS manual.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>system.build.etc</varname></term>
|
|
||||||
<listitem><para>A tree of symlinks that form the static parts of
|
|
||||||
<filename>/etc</filename>.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>system.build.initialRamdisk</varname></term>
|
|
||||||
<term><varname>system.build.kernel</varname></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The initial ramdisk and kernel of the system. This allows
|
<para>
|
||||||
a quick way to test whether the kernel and the initial ramdisk
|
The NixOS manual.
|
||||||
boot correctly, by using QEMU’s <option>-kernel</option> and
|
</para>
|
||||||
<option>-initrd</option> options:
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><varname>system.build.etc</varname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
A tree of symlinks that form the static parts of
|
||||||
|
<filename>/etc</filename>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><varname>system.build.initialRamdisk</varname>
|
||||||
|
</term>
|
||||||
|
<term><varname>system.build.kernel</varname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The initial ramdisk and kernel of the system. This allows a quick way to
|
||||||
|
test whether the kernel and the initial ramdisk boot correctly, by using
|
||||||
|
QEMU’s <option>-kernel</option> and <option>-initrd</option> options:
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build -A config.system.build.initialRamdisk -o initrd
|
$ nix-build -A config.system.build.initialRamdisk -o initrd
|
||||||
$ nix-build -A config.system.build.kernel -o kernel
|
$ nix-build -A config.system.build.kernel -o kernel
|
||||||
$ qemu-system-x86_64 -kernel ./kernel/bzImage -initrd ./initrd/initrd -hda /dev/null
|
$ qemu-system-x86_64 -kernel ./kernel/bzImage -initrd ./initrd/initrd -hda /dev/null
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><varname>system.build.nixos-rebuild</varname>
|
||||||
<term><varname>system.build.nixos-rebuild</varname></term>
|
</term>
|
||||||
<term><varname>system.build.nixos-install</varname></term>
|
<term><varname>system.build.nixos-install</varname>
|
||||||
<term><varname>system.build.nixos-generate-config</varname></term>
|
</term>
|
||||||
|
<term><varname>system.build.nixos-generate-config</varname>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>These build the corresponding NixOS commands.</para>
|
<para>
|
||||||
|
These build the corresponding NixOS commands.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><varname>systemd.units.<replaceable>unit-name</replaceable>.unit</varname>
|
||||||
<term><varname>systemd.units.<replaceable>unit-name</replaceable>.unit</varname></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>This builds the unit with the specified name. Note that
|
<para>
|
||||||
since unit names contain dots
|
This builds the unit with the specified name. Note that since unit names
|
||||||
(e.g. <literal>httpd.service</literal>), you need to put them
|
contain dots (e.g. <literal>httpd.service</literal>), you need to put
|
||||||
between quotes, like this:
|
them between quotes, like this:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build -A 'config.systemd.units."httpd.service".unit'
|
$ nix-build -A 'config.systemd.units."httpd.service".unit'
|
||||||
</screen>
|
</screen>
|
||||||
|
You can also test individual units, without rebuilding the whole system,
|
||||||
You can also test individual units, without rebuilding the whole
|
by putting them in <filename>/run/systemd/system</filename>:
|
||||||
system, by putting them in
|
|
||||||
<filename>/run/systemd/system</filename>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ cp $(nix-build -A 'config.systemd.units."httpd.service".unit')/httpd.service \
|
$ cp $(nix-build -A 'config.systemd.units."httpd.service".unit')/httpd.service \
|
||||||
/run/systemd/system/tmp-httpd.service
|
/run/systemd/system/tmp-httpd.service
|
||||||
# systemctl daemon-reload
|
# systemctl daemon-reload
|
||||||
# systemctl start tmp-httpd.service
|
# systemctl start tmp-httpd.service
|
||||||
</screen>
|
</screen>
|
||||||
|
|
||||||
Note that the unit must not have the same name as any unit in
|
Note that the unit must not have the same name as any unit in
|
||||||
<filename>/etc/systemd/system</filename> since those take
|
<filename>/etc/systemd/system</filename> since those take precedence over
|
||||||
precedence over <filename>/run/systemd/system</filename>.
|
<filename>/run/systemd/system</filename>. That’s why the unit is
|
||||||
That’s why the unit is installed as
|
installed as <filename>tmp-httpd.service</filename> here.
|
||||||
<filename>tmp-httpd.service</filename> here.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</variablelist>
|
</para>
|
||||||
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,21 +3,18 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-development">
|
xml:id="ch-development">
|
||||||
|
<title>Development</title>
|
||||||
<title>Development</title>
|
<partintro>
|
||||||
|
<para>
|
||||||
<partintro>
|
This chapter describes how you can modify and extend NixOS.
|
||||||
<para>This chapter describes how you can modify and extend
|
</para>
|
||||||
NixOS.</para>
|
</partintro>
|
||||||
</partintro>
|
<xi:include href="sources.xml" />
|
||||||
|
<xi:include href="writing-modules.xml" />
|
||||||
<xi:include href="sources.xml" />
|
<xi:include href="building-parts.xml" />
|
||||||
<xi:include href="writing-modules.xml" />
|
<xi:include href="writing-documentation.xml" />
|
||||||
<xi:include href="building-parts.xml" />
|
<xi:include href="building-nixos.xml" />
|
||||||
<xi:include href="writing-documentation.xml" />
|
<xi:include href="nixos-tests.xml" />
|
||||||
<xi:include href="building-nixos.xml" />
|
<xi:include href="testing-installer.xml" />
|
||||||
<xi:include href="nixos-tests.xml" />
|
<xi:include href="releases.xml" />
|
||||||
<xi:include href="testing-installer.xml" />
|
|
||||||
<xi:include href="releases.xml" />
|
|
||||||
|
|
||||||
</part>
|
</part>
|
||||||
|
@ -3,13 +3,12 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-importing-modules">
|
xml:id="sec-importing-modules">
|
||||||
|
<title>Importing Modules</title>
|
||||||
|
|
||||||
<title>Importing Modules</title>
|
<para>
|
||||||
|
Sometimes NixOS modules need to be used in configuration but exist outside of
|
||||||
<para>
|
Nixpkgs. These modules can be imported:
|
||||||
Sometimes NixOS modules need to be used in configuration but exist
|
</para>
|
||||||
outside of Nixpkgs. These modules can be imported:
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, lib, pkgs, ... }:
|
{ config, lib, pkgs, ... }:
|
||||||
@ -25,12 +24,11 @@
|
|||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The environment variable <literal>NIXOS_EXTRA_MODULE_PATH</literal> is
|
The environment variable <literal>NIXOS_EXTRA_MODULE_PATH</literal> is an
|
||||||
an absolute path to a NixOS module that is included alongside the
|
absolute path to a NixOS module that is included alongside the Nixpkgs NixOS
|
||||||
Nixpkgs NixOS modules. Like any NixOS module, this module can import
|
modules. Like any NixOS module, this module can import additional modules:
|
||||||
additional modules:
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
# ./module-list/default.nix
|
# ./module-list/default.nix
|
||||||
@ -55,5 +53,4 @@
|
|||||||
services.exampleModule1.enable = true;
|
services.exampleModule1.enable = true;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,22 +3,26 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-meta-attributes">
|
xml:id="sec-meta-attributes">
|
||||||
|
<title>Meta Attributes</title>
|
||||||
|
|
||||||
<title>Meta Attributes</title>
|
<para>
|
||||||
|
Like Nix packages, NixOS modules can declare meta-attributes to provide extra
|
||||||
<para>Like Nix packages, NixOS modules can declare meta-attributes to provide
|
information. Module meta attributes are defined in the
|
||||||
extra information. Module meta attributes are defined in the
|
|
||||||
<filename
|
<filename
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/meta.nix">meta.nix</filename>
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/meta.nix">meta.nix</filename>
|
||||||
special module.</para>
|
special module.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para><literal>meta</literal> is a top level attribute like
|
<para>
|
||||||
|
<literal>meta</literal> is a top level attribute like
|
||||||
<literal>options</literal> and <literal>config</literal>. Available
|
<literal>options</literal> and <literal>config</literal>. Available
|
||||||
meta-attributes are <literal>maintainers</literal> and
|
meta-attributes are <literal>maintainers</literal> and
|
||||||
<literal>doc</literal>.</para>
|
<literal>doc</literal>.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>Each of the meta-attributes must be defined at most once per module
|
<para>
|
||||||
file.</para>
|
Each of the meta-attributes must be defined at most once per module file.
|
||||||
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, lib, pkgs, ... }:
|
{ config, lib, pkgs, ... }:
|
||||||
@ -39,24 +43,21 @@
|
|||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<calloutlist>
|
<calloutlist>
|
||||||
<callout arearefs='modules-meta-1'>
|
<callout arearefs='modules-meta-1'>
|
||||||
<para>
|
<para>
|
||||||
<varname>maintainers</varname> contains a list of the module maintainers.
|
<varname>maintainers</varname> contains a list of the module maintainers.
|
||||||
</para>
|
</para>
|
||||||
</callout>
|
</callout>
|
||||||
|
<callout arearefs='modules-meta-2'>
|
||||||
<callout arearefs='modules-meta-2'>
|
<para>
|
||||||
<para>
|
|
||||||
<varname>doc</varname> points to a valid DocBook file containing the module
|
<varname>doc</varname> points to a valid DocBook file containing the module
|
||||||
documentation. Its contents is automatically added to <xref
|
documentation. Its contents is automatically added to
|
||||||
linkend="ch-configuration"/>.
|
<xref
|
||||||
Changes to a module documentation have to be checked to not break
|
linkend="ch-configuration"/>. Changes to a module documentation
|
||||||
building the NixOS manual:
|
have to be checked to not break building the NixOS manual:
|
||||||
</para>
|
</para>
|
||||||
<programlisting>$ nix-build nixos/release.nix -A manual</programlisting>
|
<programlisting>$ nix-build nixos/release.nix -A manual</programlisting>
|
||||||
</callout>
|
</callout>
|
||||||
|
</calloutlist>
|
||||||
</calloutlist>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,18 +3,17 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-nixos-tests">
|
xml:id="sec-nixos-tests">
|
||||||
|
<title>NixOS Tests</title>
|
||||||
<title>NixOS Tests</title>
|
<para>
|
||||||
|
When you add some feature to NixOS, you should write a test for it. NixOS
|
||||||
<para>When you add some feature to NixOS, you should write a test for
|
tests are kept in the directory
|
||||||
it. NixOS tests are kept in the directory <filename
|
<filename
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/tests">nixos/tests</filename>,
|
xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/tests">nixos/tests</filename>,
|
||||||
and are executed (using Nix) by a testing framework that automatically
|
and are executed (using Nix) by a testing framework that automatically starts
|
||||||
starts one or more virtual machines containing the NixOS system(s)
|
one or more virtual machines containing the NixOS system(s) required for the
|
||||||
required for the test.</para>
|
test.
|
||||||
|
</para>
|
||||||
<xi:include href="writing-nixos-tests.xml" />
|
<xi:include href="writing-nixos-tests.xml" />
|
||||||
<xi:include href="running-nixos-tests.xml" />
|
<xi:include href="running-nixos-tests.xml" />
|
||||||
<xi:include href="running-nixos-tests-interactively.xml" />
|
<xi:include href="running-nixos-tests-interactively.xml" />
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,14 +3,12 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-option-declarations">
|
xml:id="sec-option-declarations">
|
||||||
|
<title>Option Declarations</title>
|
||||||
|
|
||||||
<title>Option Declarations</title>
|
<para>
|
||||||
|
An option declaration specifies the name, type and description of a NixOS
|
||||||
<para>An option declaration specifies the name, type and description
|
configuration option. It is invalid to define an option that hasn’t been
|
||||||
of a NixOS configuration option. It is invalid to define an option
|
declared in any module. An option declaration generally looks like this:
|
||||||
that hasn’t been declared in any module. An option declaration
|
|
||||||
generally looks like this:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
options = {
|
options = {
|
||||||
<replaceable>name</replaceable> = mkOption {
|
<replaceable>name</replaceable> = mkOption {
|
||||||
@ -21,146 +19,177 @@ options = {
|
|||||||
};
|
};
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The attribute names within the <replaceable>name</replaceable> attribute path
|
||||||
The attribute names within the <replaceable>name</replaceable>
|
must be camel cased in general but should, as an exception, match the
|
||||||
attribute path must be camel cased in general but should, as an
|
<link
|
||||||
exception, match the
|
|
||||||
<link
|
|
||||||
xlink:href="https://nixos.org/nixpkgs/manual/#sec-package-naming">
|
xlink:href="https://nixos.org/nixpkgs/manual/#sec-package-naming">
|
||||||
package attribute name</link> when referencing a Nixpkgs package. For
|
package attribute name</link> when referencing a Nixpkgs package. For
|
||||||
example, the option <varname>services.nix-serve.bindAddress</varname>
|
example, the option <varname>services.nix-serve.bindAddress</varname>
|
||||||
references the <varname>nix-serve</varname> Nixpkgs package.
|
references the <varname>nix-serve</varname> Nixpkgs package.
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
The function <varname>mkOption</varname> accepts the following arguments.
|
||||||
<para>The function <varname>mkOption</varname> accepts the following arguments.
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><varname>type</varname>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
|
||||||
<term><varname>type</varname></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The type of the option (see <xref linkend='sec-option-types' />).
|
<para>
|
||||||
It may be omitted, but that’s not advisable since it may lead to errors
|
The type of the option (see <xref linkend='sec-option-types' />). It may
|
||||||
that are hard to diagnose.</para>
|
be omitted, but that’s not advisable since it may lead to errors that
|
||||||
|
are hard to diagnose.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><varname>default</varname>
|
||||||
<term><varname>default</varname></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The default value used if no value is defined by any
|
<para>
|
||||||
module. A default is not required; but if a default is not given,
|
The default value used if no value is defined by any module. A default is
|
||||||
then users of the module will have to define the value of the
|
not required; but if a default is not given, then users of the module
|
||||||
option, otherwise an error will be thrown.</para>
|
will have to define the value of the option, otherwise an error will be
|
||||||
|
thrown.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><varname>example</varname>
|
||||||
<term><varname>example</varname></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>An example value that will be shown in the NixOS manual.</para>
|
<para>
|
||||||
|
An example value that will be shown in the NixOS manual.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><varname>description</varname>
|
||||||
<term><varname>description</varname></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>A textual description of the option, in DocBook format,
|
<para>
|
||||||
that will be included in the NixOS manual.</para>
|
A textual description of the option, in DocBook format, that will be
|
||||||
|
included in the NixOS manual.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</para>
|
||||||
|
|
||||||
</variablelist>
|
<section xml:id="sec-option-declarations-eot">
|
||||||
|
<title>Extensible Option Types</title>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
Extensible option types is a feature that allow to extend certain types
|
||||||
<section xml:id="sec-option-declarations-eot"><title>Extensible Option
|
declaration through multiple module files. This feature only work with a
|
||||||
Types</title>
|
restricted set of types, namely <literal>enum</literal> and
|
||||||
|
<literal>submodules</literal> and any composed forms of them.
|
||||||
<para>Extensible option types is a feature that allow to extend certain types
|
|
||||||
declaration through multiple module files.
|
|
||||||
This feature only work with a restricted set of types, namely
|
|
||||||
<literal>enum</literal> and <literal>submodules</literal> and any composed
|
|
||||||
forms of them.</para>
|
|
||||||
|
|
||||||
<para>Extensible option types can be used for <literal>enum</literal> options
|
|
||||||
that affects multiple modules, or as an alternative to related
|
|
||||||
<literal>enable</literal> options.</para>
|
|
||||||
|
|
||||||
<para>As an example, we will take the case of display managers. There is a
|
|
||||||
central display manager module for generic display manager options and a
|
|
||||||
module file per display manager backend (slim, sddm, gdm ...).
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>There are two approach to this module structure:
|
<para>
|
||||||
|
Extensible option types can be used for <literal>enum</literal> options that
|
||||||
<itemizedlist>
|
affects multiple modules, or as an alternative to related
|
||||||
<listitem><para>Managing the display managers independently by adding an
|
<literal>enable</literal> options.
|
||||||
enable option to every display manager module backend. (NixOS)</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem><para>Managing the display managers in the central module by
|
|
||||||
adding an option to select which display manager backend to use.</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>Both approaches have problems.</para>
|
<para>
|
||||||
|
As an example, we will take the case of display managers. There is a central
|
||||||
|
display manager module for generic display manager options and a module file
|
||||||
|
per display manager backend (slim, sddm, gdm ...).
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>Making backends independent can quickly become hard to manage. For
|
<para>
|
||||||
display managers, there can be only one enabled at a time, but the type
|
There are two approach to this module structure:
|
||||||
system can not enforce this restriction as there is no relation between
|
<itemizedlist>
|
||||||
each backend <literal>enable</literal> option. As a result, this restriction
|
<listitem>
|
||||||
has to be done explicitely by adding assertions in each display manager
|
<para>
|
||||||
backend module.</para>
|
Managing the display managers independently by adding an enable option to
|
||||||
|
every display manager module backend. (NixOS)
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Managing the display managers in the central module by adding an option
|
||||||
|
to select which display manager backend to use.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>On the other hand, managing the display managers backends in the
|
<para>
|
||||||
central module will require to change the central module option every time
|
Both approaches have problems.
|
||||||
a new backend is added or removed.</para>
|
</para>
|
||||||
|
|
||||||
<para>By using extensible option types, it is possible to create a placeholder
|
<para>
|
||||||
option in the central module (<xref linkend='ex-option-declaration-eot-service'
|
Making backends independent can quickly become hard to manage. For display
|
||||||
/>), and to extend it in each backend module (<xref
|
managers, there can be only one enabled at a time, but the type system can
|
||||||
linkend='ex-option-declaration-eot-backend-slim' />, <xref
|
not enforce this restriction as there is no relation between each backend
|
||||||
linkend='ex-option-declaration-eot-backend-sddm' />).</para>
|
<literal>enable</literal> option. As a result, this restriction has to be
|
||||||
|
done explicitely by adding assertions in each display manager backend
|
||||||
|
module.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>As a result, <literal>displayManager.enable</literal> option values can
|
<para>
|
||||||
be added without changing the main service module file and the type system
|
On the other hand, managing the display managers backends in the central
|
||||||
automatically enforce that there can only be a single display manager
|
module will require to change the central module option every time a new
|
||||||
enabled.</para>
|
backend is added or removed.
|
||||||
|
</para>
|
||||||
|
|
||||||
<example xml:id='ex-option-declaration-eot-service'><title>Extensible type
|
<para>
|
||||||
placeholder in the service module</title>
|
By using extensible option types, it is possible to create a placeholder
|
||||||
|
option in the central module
|
||||||
|
(<xref linkend='ex-option-declaration-eot-service'
|
||||||
|
/>), and to extend
|
||||||
|
it in each backend module
|
||||||
|
(<xref
|
||||||
|
linkend='ex-option-declaration-eot-backend-slim' />,
|
||||||
|
<xref
|
||||||
|
linkend='ex-option-declaration-eot-backend-sddm' />).
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
As a result, <literal>displayManager.enable</literal> option values can be
|
||||||
|
added without changing the main service module file and the type system
|
||||||
|
automatically enforce that there can only be a single display manager
|
||||||
|
enabled.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<example xml:id='ex-option-declaration-eot-service'>
|
||||||
|
<title>Extensible type placeholder in the service module</title>
|
||||||
<screen>
|
<screen>
|
||||||
services.xserver.displayManager.enable = mkOption {
|
services.xserver.displayManager.enable = mkOption {
|
||||||
description = "Display manager to use";
|
description = "Display manager to use";
|
||||||
type = with types; nullOr (enum [ ]);
|
type = with types; nullOr (enum [ ]);
|
||||||
};</screen></example>
|
};</screen>
|
||||||
|
</example>
|
||||||
|
|
||||||
<example xml:id='ex-option-declaration-eot-backend-slim'><title>Extending
|
<example xml:id='ex-option-declaration-eot-backend-slim'>
|
||||||
<literal>services.xserver.displayManager.enable</literal> in the
|
<title>Extending <literal>services.xserver.displayManager.enable</literal> in the <literal>slim</literal> module</title>
|
||||||
<literal>slim</literal> module</title>
|
|
||||||
<screen>
|
<screen>
|
||||||
services.xserver.displayManager.enable = mkOption {
|
services.xserver.displayManager.enable = mkOption {
|
||||||
type = with types; nullOr (enum [ "slim" ]);
|
type = with types; nullOr (enum [ "slim" ]);
|
||||||
};</screen></example>
|
};</screen>
|
||||||
|
</example>
|
||||||
|
|
||||||
<example xml:id='ex-option-declaration-eot-backend-sddm'><title>Extending
|
<example xml:id='ex-option-declaration-eot-backend-sddm'>
|
||||||
<literal>services.xserver.displayManager.enable</literal> in the
|
<title>Extending <literal>services.xserver.displayManager.enable</literal> in the <literal>sddm</literal> module</title>
|
||||||
<literal>sddm</literal> module</title>
|
|
||||||
<screen>
|
<screen>
|
||||||
services.xserver.displayManager.enable = mkOption {
|
services.xserver.displayManager.enable = mkOption {
|
||||||
type = with types; nullOr (enum [ "sddm" ]);
|
type = with types; nullOr (enum [ "sddm" ]);
|
||||||
};</screen></example>
|
};</screen>
|
||||||
|
</example>
|
||||||
|
|
||||||
<para>The placeholder declaration is a standard <literal>mkOption</literal>
|
<para>
|
||||||
declaration, but it is important that extensible option declarations only use
|
The placeholder declaration is a standard <literal>mkOption</literal>
|
||||||
the <literal>type</literal> argument.</para>
|
declaration, but it is important that extensible option declarations only
|
||||||
|
use the <literal>type</literal> argument.
|
||||||
<para>Extensible option types work with any of the composed variants of
|
</para>
|
||||||
<literal>enum</literal> such as
|
|
||||||
<literal>with types; nullOr (enum [ "foo" "bar" ])</literal>
|
|
||||||
or <literal>with types; listOf (enum [ "foo" "bar" ])</literal>.</para>
|
|
||||||
|
|
||||||
</section>
|
<para>
|
||||||
|
Extensible option types work with any of the composed variants of
|
||||||
|
<literal>enum</literal> such as <literal>with types; nullOr (enum [ "foo"
|
||||||
|
"bar" ])</literal> or <literal>with types; listOf (enum [ "foo" "bar"
|
||||||
|
])</literal>.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,39 +3,36 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-option-definitions">
|
xml:id="sec-option-definitions">
|
||||||
|
<title>Option Definitions</title>
|
||||||
|
|
||||||
<title>Option Definitions</title>
|
<para>
|
||||||
|
Option definitions are generally straight-forward bindings of values to
|
||||||
<para>Option definitions are generally straight-forward bindings of values to option names, like
|
option names, like
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
config = {
|
config = {
|
||||||
services.httpd.enable = true;
|
services.httpd.enable = true;
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
However, sometimes you need to wrap an option definition or set of option
|
||||||
|
definitions in a <emphasis>property</emphasis> to achieve certain effects:
|
||||||
|
</para>
|
||||||
|
|
||||||
However, sometimes you need to wrap an option definition or set of
|
<simplesect>
|
||||||
option definitions in a <emphasis>property</emphasis> to achieve
|
<title>Delaying Conditionals</title>
|
||||||
certain effects:</para>
|
<para>
|
||||||
|
If a set of option definitions is conditional on the value of another
|
||||||
<simplesect><title>Delaying Conditionals</title>
|
option, you may need to use <varname>mkIf</varname>. Consider, for instance:
|
||||||
|
|
||||||
<para>If a set of option definitions is conditional on the value of
|
|
||||||
another option, you may need to use <varname>mkIf</varname>.
|
|
||||||
Consider, for instance:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
config = if config.services.httpd.enable then {
|
config = if config.services.httpd.enable then {
|
||||||
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
} else {};
|
} else {};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This definition will cause Nix to fail with an “infinite recursion”
|
||||||
This definition will cause Nix to fail with an “infinite recursion”
|
error. Why? Because the value of
|
||||||
error. Why? Because the value of
|
<option>config.services.httpd.enable</option> depends on the value being
|
||||||
<option>config.services.httpd.enable</option> depends on the value
|
constructed here. After all, you could also write the clearly circular and
|
||||||
being constructed here. After all, you could also write the clearly
|
contradictory:
|
||||||
circular and contradictory:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
config = if config.services.httpd.enable then {
|
config = if config.services.httpd.enable then {
|
||||||
services.httpd.enable = false;
|
services.httpd.enable = false;
|
||||||
@ -43,56 +40,49 @@ config = if config.services.httpd.enable then {
|
|||||||
services.httpd.enable = true;
|
services.httpd.enable = true;
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The solution is to write:
|
||||||
The solution is to write:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
config = mkIf config.services.httpd.enable {
|
config = mkIf config.services.httpd.enable {
|
||||||
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The special function <varname>mkIf</varname> causes the evaluation of the
|
||||||
The special function <varname>mkIf</varname> causes the evaluation of
|
conditional to be “pushed down” into the individual definitions, as if
|
||||||
the conditional to be “pushed down” into the individual definitions,
|
you had written:
|
||||||
as if you had written:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
config = {
|
config = {
|
||||||
environment.systemPackages = if config.services.httpd.enable then [ <replaceable>...</replaceable> ] else [];
|
environment.systemPackages = if config.services.httpd.enable then [ <replaceable>...</replaceable> ] else [];
|
||||||
<replaceable>...</replaceable>
|
<replaceable>...</replaceable>
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
</simplesect>
|
||||||
|
|
||||||
</para>
|
<simplesect>
|
||||||
|
<title>Setting Priorities</title>
|
||||||
</simplesect>
|
<para>
|
||||||
|
A module can override the definitions of an option in other modules by
|
||||||
<simplesect><title>Setting Priorities</title>
|
setting a <emphasis>priority</emphasis>. All option definitions that do not
|
||||||
|
have the lowest priority value are discarded. By default, option definitions
|
||||||
<para>A module can override the definitions of an option in other
|
have priority 1000. You can specify an explicit priority by using
|
||||||
modules by setting a <emphasis>priority</emphasis>. All option
|
<varname>mkOverride</varname>, e.g.
|
||||||
definitions that do not have the lowest priority value are discarded.
|
|
||||||
By default, option definitions have priority 1000. You can specify an
|
|
||||||
explicit priority by using <varname>mkOverride</varname>, e.g.
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
services.openssh.enable = mkOverride 10 false;
|
services.openssh.enable = mkOverride 10 false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This definition causes all other definitions with priorities above 10 to be
|
||||||
|
discarded. The function <varname>mkForce</varname> is equal to
|
||||||
|
<varname>mkOverride 50</varname>.
|
||||||
|
</para>
|
||||||
|
</simplesect>
|
||||||
|
|
||||||
This definition causes all other definitions with priorities above 10
|
<simplesect>
|
||||||
to be discarded. The function <varname>mkForce</varname> is
|
<title>Merging Configurations</title>
|
||||||
equal to <varname>mkOverride 50</varname>.</para>
|
<para>
|
||||||
|
In conjunction with <literal>mkIf</literal>, it is sometimes useful for a
|
||||||
</simplesect>
|
module to return multiple sets of option definitions, to be merged together
|
||||||
|
as if they were declared in separate modules. This can be done using
|
||||||
<simplesect><title>Merging Configurations</title>
|
<varname>mkMerge</varname>:
|
||||||
|
|
||||||
<para>In conjunction with <literal>mkIf</literal>, it is sometimes
|
|
||||||
useful for a module to return multiple sets of option definitions, to
|
|
||||||
be merged together as if they were declared in separate modules. This
|
|
||||||
can be done using <varname>mkMerge</varname>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
config = mkMerge
|
config = mkMerge
|
||||||
[ # Unconditional stuff.
|
[ # Unconditional stuff.
|
||||||
@ -104,9 +94,6 @@ config = mkMerge
|
|||||||
})
|
})
|
||||||
];
|
];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
</simplesect>
|
||||||
|
</section>
|
||||||
</simplesect>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -3,252 +3,258 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-releases">
|
xml:id="ch-releases">
|
||||||
|
<title>Releases</title>
|
||||||
<title>Releases</title>
|
<section xml:id="release-process">
|
||||||
|
|
||||||
<section xml:id="release-process">
|
|
||||||
<title>Release process</title>
|
<title>Release process</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Going through an example of releasing NixOS 17.09:
|
Going through an example of releasing NixOS 17.09:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<section xml:id="one-month-before-the-beta">
|
<section xml:id="one-month-before-the-beta">
|
||||||
<title>One month before the beta</title>
|
<title>One month before the beta</title>
|
||||||
<itemizedlist spacing="compact">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Send an email to the nix-devel mailinglist as a warning about upcoming beta "feature freeze" in a month.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Discuss with Eelco Dolstra and the community (via IRC, ML) about what will reach the deadline.
|
|
||||||
Any issue or Pull Request targeting the release should be included in the release milestone.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section xml:id="at-beta-release-time">
|
|
||||||
<title>At beta release time</title>
|
|
||||||
<itemizedlist spacing="compact">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/issues/13559">Create
|
|
||||||
an issue for tracking Zero Hydra Failures progress. ZHF is an effort
|
|
||||||
to get build failures down to zero.</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<literal>git tag -a -s -m "Release 17.09-beta" 17.09-beta && git push --tags</literal>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
From the master branch run <literal>git checkout -B release-17.09</literal>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixos-org-configurations/pull/18">
|
|
||||||
Make sure a channel is created at http://nixos.org/channels/.
|
|
||||||
</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/settings/branches">
|
|
||||||
Let a GitHub nixpkgs admin lock the branch on github for you.
|
|
||||||
(so developers can’t force push)
|
|
||||||
</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/compare/bdf161ed8d21...6b63c4616790">
|
|
||||||
Bump the <literal>system.defaultChannel</literal> attribute in
|
|
||||||
<literal>nixos/modules/misc/version.nix</literal>
|
|
||||||
</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/d6b08acd1ccac0d9d502c4b635e00b04d3387f06">
|
|
||||||
Update <literal>versionSuffix</literal> in
|
|
||||||
<literal>nixos/release.nix</literal></link>, use
|
|
||||||
<literal>git log --format=%an|wc -l</literal> to get the commit
|
|
||||||
count
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<literal>echo -n "18.03" > .version</literal> on
|
|
||||||
master.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/b8a4095003e27659092892a4708bb3698231a842">
|
|
||||||
Pick a new name for the unstable branch.
|
|
||||||
</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Create a new release notes file for the upcoming release + 1, in this
|
|
||||||
case <literal>rl-1803.xml</literal>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Create two Hydra jobsets: release-17.09 and release-17.09-small with <literal>stableBranch</literal> set to false.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Edit changelog at
|
|
||||||
<literal>nixos/doc/manual/release-notes/rl-1709.xml</literal>
|
|
||||||
(double check desktop versions are noted)
|
|
||||||
</para>
|
|
||||||
<itemizedlist spacing="compact">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Get all new NixOS modules
|
|
||||||
<literal>git diff release-17.03..release-17.09 nixos/modules/module-list.nix|grep ^+</literal>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Note systemd, kernel, glibc and Nix upgrades.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section xml:id="during-beta">
|
|
||||||
<title>During Beta</title>
|
|
||||||
<itemizedlist spacing="compact">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Monitor the master branch for bugfixes and minor updates
|
|
||||||
and cherry-pick them to the release branch.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section xml:id="before-the-final-release">
|
|
||||||
<title>Before the final release</title>
|
|
||||||
<itemizedlist spacing="compact">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Re-check that the release notes are complete.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Release Nix (currently only Eelco Dolstra can do that).
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/53710c752a85f00658882531bc90a23a3d1287e4">
|
|
||||||
Make sure fallback is updated.
|
|
||||||
</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/40fd9ae3ac8048758abdcfc7d28a78b5f22fe97e">
|
|
||||||
Update README.md with new stable NixOS version information.
|
|
||||||
</link>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Change <literal>stableBranch</literal> to true and wait for channel to update.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section xml:id="at-final-release-time">
|
|
||||||
<title>At final release time</title>
|
|
||||||
<itemizedlist spacing="compact">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
<literal>git tag -s -a -m "Release 15.09" 15.09</literal>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Update http://nixos.org/nixos/download.html and http://nixos.org/nixos/manual in https://github.com/NixOS/nixos-org-configurations
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Get number of commits for the release:
|
|
||||||
<literal>git log release-14.04..release-14.12 --format=%an|wc -l</literal>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Commits by contributor:
|
|
||||||
<literal>git log release-14.04..release-14.12 --format=%an|sort|uniq -c|sort -rn</literal>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Send an email to nix-dev to announce the release with above information. Best to check how previous email was formulated
|
|
||||||
to see what needs to be included.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section xml:id="release-schedule">
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Send an email to the nix-devel mailinglist as a warning about upcoming
|
||||||
|
beta "feature freeze" in a month.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Discuss with Eelco Dolstra and the community (via IRC, ML) about what
|
||||||
|
will reach the deadline. Any issue or Pull Request targeting the release
|
||||||
|
should be included in the release milestone.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section xml:id="at-beta-release-time">
|
||||||
|
<title>At beta release time</title>
|
||||||
|
|
||||||
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/issues/13559">Create
|
||||||
|
an issue for tracking Zero Hydra Failures progress. ZHF is an effort to
|
||||||
|
get build failures down to zero.</link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>git tag -a -s -m "Release 17.09-beta" 17.09-beta
|
||||||
|
&& git push --tags</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
From the master branch run <literal>git checkout -B
|
||||||
|
release-17.09</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixos-org-configurations/pull/18">
|
||||||
|
Make sure a channel is created at http://nixos.org/channels/. </link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/settings/branches">
|
||||||
|
Let a GitHub nixpkgs admin lock the branch on github for you. (so
|
||||||
|
developers can’t force push) </link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/compare/bdf161ed8d21...6b63c4616790">
|
||||||
|
Bump the <literal>system.defaultChannel</literal> attribute in
|
||||||
|
<literal>nixos/modules/misc/version.nix</literal> </link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/d6b08acd1ccac0d9d502c4b635e00b04d3387f06">
|
||||||
|
Update <literal>versionSuffix</literal> in
|
||||||
|
<literal>nixos/release.nix</literal></link>, use <literal>git log
|
||||||
|
--format=%an|wc -l</literal> to get the commit count
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>echo -n "18.03" > .version</literal> on master.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/b8a4095003e27659092892a4708bb3698231a842">
|
||||||
|
Pick a new name for the unstable branch. </link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Create a new release notes file for the upcoming release + 1, in this
|
||||||
|
case <literal>rl-1803.xml</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Create two Hydra jobsets: release-17.09 and release-17.09-small with
|
||||||
|
<literal>stableBranch</literal> set to false.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Edit changelog at
|
||||||
|
<literal>nixos/doc/manual/release-notes/rl-1709.xml</literal> (double
|
||||||
|
check desktop versions are noted)
|
||||||
|
</para>
|
||||||
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Get all new NixOS modules <literal>git diff
|
||||||
|
release-17.03..release-17.09 nixos/modules/module-list.nix|grep
|
||||||
|
^+</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Note systemd, kernel, glibc and Nix upgrades.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section xml:id="during-beta">
|
||||||
|
<title>During Beta</title>
|
||||||
|
|
||||||
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Monitor the master branch for bugfixes and minor updates and cherry-pick
|
||||||
|
them to the release branch.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section xml:id="before-the-final-release">
|
||||||
|
<title>Before the final release</title>
|
||||||
|
|
||||||
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Re-check that the release notes are complete.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Release Nix (currently only Eelco Dolstra can do that).
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/53710c752a85f00658882531bc90a23a3d1287e4">
|
||||||
|
Make sure fallback is updated. </link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/40fd9ae3ac8048758abdcfc7d28a78b5f22fe97e">
|
||||||
|
Update README.md with new stable NixOS version information. </link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Change <literal>stableBranch</literal> to true and wait for channel to
|
||||||
|
update.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section xml:id="at-final-release-time">
|
||||||
|
<title>At final release time</title>
|
||||||
|
|
||||||
|
<itemizedlist spacing="compact">
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>git tag -s -a -m "Release 15.09" 15.09</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Update http://nixos.org/nixos/download.html and
|
||||||
|
http://nixos.org/nixos/manual in
|
||||||
|
https://github.com/NixOS/nixos-org-configurations
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Get number of commits for the release: <literal>git log
|
||||||
|
release-14.04..release-14.12 --format=%an|wc -l</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Commits by contributor: <literal>git log release-14.04..release-14.12
|
||||||
|
--format=%an|sort|uniq -c|sort -rn</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Send an email to nix-dev to announce the release with above information.
|
||||||
|
Best to check how previous email was formulated to see what needs to be
|
||||||
|
included.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section xml:id="release-schedule">
|
||||||
<title>Release schedule</title>
|
<title>Release schedule</title>
|
||||||
|
|
||||||
<informaltable>
|
<informaltable>
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
<colspec align="left" />
|
<colspec align="left" />
|
||||||
<colspec align="left" />
|
<colspec align="left" />
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
<entry>
|
<entry>
|
||||||
Date
|
Date
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
Event
|
Event
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
</thead>
|
</thead>
|
||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry>
|
<entry>
|
||||||
2016-07-25
|
2016-07-25
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
Send email to nix-dev about upcoming branch-off
|
Send email to nix-dev about upcoming branch-off
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>
|
<entry>
|
||||||
2016-09-01
|
2016-09-01
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry><literal>release-16.09</literal> branch and corresponding jobsets are created,
|
||||||
<literal>release-16.09</literal> branch and corresponding jobsets are created,
|
|
||||||
change freeze
|
change freeze
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>
|
<entry>
|
||||||
2016-09-30
|
2016-09-30
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
NixOS 16.09 released
|
NixOS 16.09 released
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</informaltable>
|
</informaltable>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,27 +3,31 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-replace-modules">
|
xml:id="sec-replace-modules">
|
||||||
|
<title>Replace Modules</title>
|
||||||
|
|
||||||
<title>Replace Modules</title>
|
<para>
|
||||||
|
Modules that are imported can also be disabled. The option declarations and
|
||||||
|
config implementation of a disabled module will be ignored, allowing another
|
||||||
|
to take it's place. This can be used to import a set of modules from another
|
||||||
|
channel while keeping the rest of the system on a stable release.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>Modules that are imported can also be disabled. The option
|
<para>
|
||||||
declarations and config implementation of a disabled module will be
|
<literal>disabledModules</literal> is a top level attribute like
|
||||||
ignored, allowing another to take it's place. This can be used to
|
|
||||||
import a set of modules from another channel while keeping the rest
|
|
||||||
of the system on a stable release.</para>
|
|
||||||
<para><literal>disabledModules</literal> is a top level attribute like
|
|
||||||
<literal>imports</literal>, <literal>options</literal> and
|
<literal>imports</literal>, <literal>options</literal> and
|
||||||
<literal>config</literal>. It contains a list of modules that will
|
<literal>config</literal>. It contains a list of modules that will be
|
||||||
be disabled. This can either be the full path to the module or a
|
disabled. This can either be the full path to the module or a string with the
|
||||||
string with the filename relative to the modules path
|
filename relative to the modules path (eg. <nixpkgs/nixos/modules> for
|
||||||
(eg. <nixpkgs/nixos/modules> for nixos).
|
nixos).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>This example will replace the existing postgresql module with
|
<para>
|
||||||
the version defined in the nixos-unstable channel while keeping the
|
This example will replace the existing postgresql module with the version
|
||||||
rest of the modules and packages from the original nixos channel.
|
defined in the nixos-unstable channel while keeping the rest of the modules
|
||||||
This only overrides the module definition, this won't use postgresql
|
and packages from the original nixos channel. This only overrides the module
|
||||||
from nixos-unstable unless explicitly configured to do so.</para>
|
definition, this won't use postgresql from nixos-unstable unless explicitly
|
||||||
|
configured to do so.
|
||||||
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, lib, pkgs, ... }:
|
{ config, lib, pkgs, ... }:
|
||||||
@ -41,10 +45,11 @@
|
|||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>This example shows how to define a custom module as a
|
<para>
|
||||||
replacement for an existing module. Importing this module will
|
This example shows how to define a custom module as a replacement for an
|
||||||
disable the original module without having to know it's
|
existing module. Importing this module will disable the original module
|
||||||
implementation details.</para>
|
without having to know it's implementation details.
|
||||||
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, lib, pkgs, ... }:
|
{ config, lib, pkgs, ... }:
|
||||||
@ -71,5 +76,4 @@ in
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,41 +3,38 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-running-nixos-tests">
|
xml:id="sec-running-nixos-tests">
|
||||||
<title>Running Tests interactively</title>
|
<title>Running Tests interactively</title>
|
||||||
|
|
||||||
<para>The test itself can be run interactively. This is
|
|
||||||
particularly useful when developing or debugging a test:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The test itself can be run interactively. This is particularly useful when
|
||||||
|
developing or debugging a test:
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build nixos/tests/login.nix -A driver
|
$ nix-build nixos/tests/login.nix -A driver
|
||||||
$ ./result/bin/nixos-test-driver
|
$ ./result/bin/nixos-test-driver
|
||||||
starting VDE switch for network 1
|
starting VDE switch for network 1
|
||||||
>
|
>
|
||||||
</screen>
|
</screen>
|
||||||
|
You can then take any Perl statement, e.g.
|
||||||
You can then take any Perl statement, e.g.
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
> startAll
|
> startAll
|
||||||
> testScript
|
> testScript
|
||||||
> $machine->succeed("touch /tmp/foo")
|
> $machine->succeed("touch /tmp/foo")
|
||||||
</screen>
|
</screen>
|
||||||
|
The function <command>testScript</command> executes the entire test script
|
||||||
|
and drops you back into the test driver command line upon its completion.
|
||||||
|
This allows you to inspect the state of the VMs after the test (e.g. to debug
|
||||||
|
the test script).
|
||||||
|
</para>
|
||||||
|
|
||||||
The function <command>testScript</command> executes the entire test
|
<para>
|
||||||
script and drops you back into the test driver command line upon its
|
To just start and experiment with the VMs, run:
|
||||||
completion. This allows you to inspect the state of the VMs after the
|
|
||||||
test (e.g. to debug the test script).</para>
|
|
||||||
|
|
||||||
<para>To just start and experiment with the VMs, run:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build nixos/tests/login.nix -A driver
|
$ nix-build nixos/tests/login.nix -A driver
|
||||||
$ ./result/bin/nixos-run-vms
|
$ ./result/bin/nixos-run-vms
|
||||||
</screen>
|
</screen>
|
||||||
|
The script <command>nixos-run-vms</command> starts the virtual machines
|
||||||
The script <command>nixos-run-vms</command> starts the virtual
|
defined by test. The root file system of the VMs is created on the fly and
|
||||||
machines defined by test. The root file system of the VMs is created
|
kept across VM restarts in
|
||||||
on the fly and kept across VM restarts in
|
<filename>./</filename><varname>hostname</varname><filename>.qcow2</filename>.
|
||||||
<filename>./</filename><varname>hostname</varname><filename>.qcow2</filename>.</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,20 +3,18 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-running-nixos-tests-interactively">
|
xml:id="sec-running-nixos-tests-interactively">
|
||||||
|
<title>Running Tests</title>
|
||||||
|
|
||||||
<title>Running Tests</title>
|
<para>
|
||||||
|
You can run tests using <command>nix-build</command>. For example, to run the
|
||||||
<para>You can run tests using <command>nix-build</command>. For
|
test
|
||||||
example, to run the test <filename
|
<filename
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/login.nix">login.nix</filename>,
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/login.nix">login.nix</filename>,
|
||||||
you just do:
|
you just do:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build '<nixpkgs/nixos/tests/login.nix>'
|
$ nix-build '<nixpkgs/nixos/tests/login.nix>'
|
||||||
</screen>
|
</screen>
|
||||||
|
or, if you don’t want to rely on <envar>NIX_PATH</envar>:
|
||||||
or, if you don’t want to rely on <envar>NIX_PATH</envar>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ cd /my/nixpkgs/nixos/tests
|
$ cd /my/nixpkgs/nixos/tests
|
||||||
$ nix-build login.nix
|
$ nix-build login.nix
|
||||||
@ -26,16 +24,13 @@ machine: QEMU running (pid 8841)
|
|||||||
…
|
…
|
||||||
6 out of 6 tests succeeded
|
6 out of 6 tests succeeded
|
||||||
</screen>
|
</screen>
|
||||||
|
After building/downloading all required dependencies, this will perform a
|
||||||
After building/downloading all required dependencies, this will
|
build that starts a QEMU/KVM virtual machine containing a NixOS system. The
|
||||||
perform a build that starts a QEMU/KVM virtual machine containing a
|
virtual machine mounts the Nix store of the host; this makes VM creation very
|
||||||
NixOS system. The virtual machine mounts the Nix store of the host;
|
fast, as no disk image needs to be created. Afterwards, you can view a
|
||||||
this makes VM creation very fast, as no disk image needs to be
|
pretty-printed log of the test:
|
||||||
created. Afterwards, you can view a pretty-printed log of the test:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ firefox result/log.html
|
$ firefox result/log.html
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,101 +3,84 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-getting-sources">
|
xml:id="sec-getting-sources">
|
||||||
|
<title>Getting the Sources</title>
|
||||||
<title>Getting the Sources</title>
|
<para>
|
||||||
|
By default, NixOS’s <command>nixos-rebuild</command> command uses the NixOS
|
||||||
<para>By default, NixOS’s <command>nixos-rebuild</command> command
|
and Nixpkgs sources provided by the <literal>nixos</literal> channel (kept in
|
||||||
uses the NixOS and Nixpkgs sources provided by the
|
<filename>/nix/var/nix/profiles/per-user/root/channels/nixos</filename>). To
|
||||||
<literal>nixos</literal> channel (kept in
|
modify NixOS, however, you should check out the latest sources from Git. This
|
||||||
<filename>/nix/var/nix/profiles/per-user/root/channels/nixos</filename>).
|
is as follows:
|
||||||
To modify NixOS, however, you should check out the latest sources from
|
|
||||||
Git. This is as follows:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ git clone git://github.com/NixOS/nixpkgs.git
|
$ git clone git://github.com/NixOS/nixpkgs.git
|
||||||
$ cd nixpkgs
|
$ cd nixpkgs
|
||||||
$ git remote add channels git://github.com/NixOS/nixpkgs-channels.git
|
$ git remote add channels git://github.com/NixOS/nixpkgs-channels.git
|
||||||
$ git remote update channels
|
$ git remote update channels
|
||||||
</screen>
|
</screen>
|
||||||
|
This will check out the latest Nixpkgs sources to
|
||||||
This will check out the latest Nixpkgs sources to
|
<filename>./nixpkgs</filename> the NixOS sources to
|
||||||
<filename>./nixpkgs</filename> the NixOS sources to
|
<filename>./nixpkgs/nixos</filename>. (The NixOS source tree lives in a
|
||||||
<filename>./nixpkgs/nixos</filename>. (The NixOS source tree lives in
|
subdirectory of the Nixpkgs repository.) The remote
|
||||||
a subdirectory of the Nixpkgs repository.) The remote
|
<literal>channels</literal> refers to a read-only repository that tracks the
|
||||||
<literal>channels</literal> refers to a read-only repository that
|
Nixpkgs/NixOS channels (see <xref linkend="sec-upgrading"/> for more
|
||||||
tracks the Nixpkgs/NixOS channels (see <xref linkend="sec-upgrading"/>
|
information about channels). Thus, the Git branch
|
||||||
for more information about channels). Thus, the Git branch
|
<literal>channels/nixos-17.03</literal> will contain the latest built and
|
||||||
<literal>channels/nixos-17.03</literal> will contain the latest built
|
tested version available in the <literal>nixos-17.03</literal> channel.
|
||||||
and tested version available in the <literal>nixos-17.03</literal>
|
</para>
|
||||||
channel.</para>
|
<para>
|
||||||
|
It’s often inconvenient to develop directly on the master branch, since if
|
||||||
<para>It’s often inconvenient to develop directly on the master
|
somebody has just committed (say) a change to GCC, then the binary cache may
|
||||||
branch, since if somebody has just committed (say) a change to GCC,
|
not have caught up yet and you’ll have to rebuild everything from source.
|
||||||
then the binary cache may not have caught up yet and you’ll have to
|
So you may want to create a local branch based on your current NixOS version:
|
||||||
rebuild everything from source. So you may want to create a local
|
|
||||||
branch based on your current NixOS version:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-version
|
$ nixos-version
|
||||||
17.09pre104379.6e0b727 (Hummingbird)
|
17.09pre104379.6e0b727 (Hummingbird)
|
||||||
|
|
||||||
$ git checkout -b local 6e0b727
|
$ git checkout -b local 6e0b727
|
||||||
</screen>
|
</screen>
|
||||||
|
Or, to base your local branch on the latest version available in a NixOS
|
||||||
Or, to base your local branch on the latest version available in a
|
channel:
|
||||||
NixOS channel:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ git remote update channels
|
$ git remote update channels
|
||||||
$ git checkout -b local channels/nixos-17.03
|
$ git checkout -b local channels/nixos-17.03
|
||||||
</screen>
|
</screen>
|
||||||
|
(Replace <literal>nixos-17.03</literal> with the name of the channel you want
|
||||||
(Replace <literal>nixos-17.03</literal> with the name of the channel
|
to use.) You can use <command>git merge</command> or <command>git
|
||||||
you want to use.) You can use <command>git merge</command> or
|
rebase</command> to keep your local branch in sync with the channel, e.g.
|
||||||
<command>git rebase</command> to keep your local branch in sync with
|
|
||||||
the channel, e.g.
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ git remote update channels
|
$ git remote update channels
|
||||||
$ git merge channels/nixos-17.03
|
$ git merge channels/nixos-17.03
|
||||||
</screen>
|
</screen>
|
||||||
|
You can use <command>git cherry-pick</command> to copy commits from your
|
||||||
You can use <command>git cherry-pick</command> to copy commits from
|
local branch to the upstream branch.
|
||||||
your local branch to the upstream branch.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>If you want to rebuild your system using your (modified)
|
If you want to rebuild your system using your (modified) sources, you need to
|
||||||
sources, you need to tell <command>nixos-rebuild</command> about them
|
tell <command>nixos-rebuild</command> about them using the
|
||||||
using the <option>-I</option> flag:
|
<option>-I</option> flag:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch -I nixpkgs=<replaceable>/my/sources</replaceable>/nixpkgs
|
# nixos-rebuild switch -I nixpkgs=<replaceable>/my/sources</replaceable>/nixpkgs
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
If you want <command>nix-env</command> to use the expressions in
|
||||||
<para>If you want <command>nix-env</command> to use the expressions in
|
<replaceable>/my/sources</replaceable>, use <command>nix-env -f
|
||||||
<replaceable>/my/sources</replaceable>, use <command>nix-env -f
|
<replaceable>/my/sources</replaceable>/nixpkgs</command>, or change the
|
||||||
<replaceable>/my/sources</replaceable>/nixpkgs</command>, or change
|
default by adding a symlink in <filename>~/.nix-defexpr</filename>:
|
||||||
the default by adding a symlink in
|
|
||||||
<filename>~/.nix-defexpr</filename>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ ln -s <replaceable>/my/sources</replaceable>/nixpkgs ~/.nix-defexpr/nixpkgs
|
$ ln -s <replaceable>/my/sources</replaceable>/nixpkgs ~/.nix-defexpr/nixpkgs
|
||||||
</screen>
|
</screen>
|
||||||
|
You may want to delete the symlink
|
||||||
You may want to delete the symlink
|
<filename>~/.nix-defexpr/channels_root</filename> to prevent root’s NixOS
|
||||||
<filename>~/.nix-defexpr/channels_root</filename> to prevent root’s
|
channel from clashing with your own tree (this may break the
|
||||||
NixOS channel from clashing with your own tree (this may break the
|
command-not-found utility though). If you want to go back to the default
|
||||||
command-not-found utility though). If you want to go back to the default
|
state, you may just remove the <filename>~/.nix-defexpr</filename> directory
|
||||||
state, you may just remove the <filename>~/.nix-defexpr</filename>
|
completely, log out and log in again and it should have been recreated with a
|
||||||
directory completely, log out and log in again and it should have been
|
link to the root channels.
|
||||||
recreated with a link to the root channels.</para>
|
</para>
|
||||||
|
|
||||||
<!-- FIXME: not sure what this means.
|
<!-- FIXME: not sure what this means.
|
||||||
<para>You should not pass the base directory
|
<para>You should not pass the base directory
|
||||||
<filename><replaceable>/my/sources</replaceable></filename>
|
<filename><replaceable>/my/sources</replaceable></filename>
|
||||||
to <command>nix-env</command>, as it will break after interpreting expressions
|
to <command>nix-env</command>, as it will break after interpreting expressions
|
||||||
in <filename>nixos/</filename> as packages.</para>
|
in <filename>nixos/</filename> as packages.</para>
|
||||||
-->
|
-->
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,27 +3,20 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-testing-installer">
|
xml:id="ch-testing-installer">
|
||||||
|
<title>Testing the Installer</title>
|
||||||
<title>Testing the Installer</title>
|
<para>
|
||||||
|
Building, burning, and booting from an installation CD is rather tedious, so
|
||||||
<para>Building, burning, and booting from an installation CD is rather
|
here is a quick way to see if the installer works properly:
|
||||||
tedious, so here is a quick way to see if the installer works
|
|
||||||
properly:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# mount -t tmpfs none /mnt
|
# mount -t tmpfs none /mnt
|
||||||
# nixos-generate-config --root /mnt
|
# nixos-generate-config --root /mnt
|
||||||
$ nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-install
|
$ nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-install
|
||||||
# ./result/bin/nixos-install</screen>
|
# ./result/bin/nixos-install</screen>
|
||||||
|
To start a login shell in the new NixOS installation in
|
||||||
To start a login shell in the new NixOS installation in
|
<filename>/mnt</filename>:
|
||||||
<filename>/mnt</filename>:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-enter
|
$ nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-enter
|
||||||
# ./result/bin/nixos-enter
|
# ./result/bin/nixos-enter
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,157 +3,147 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-writing-documentation">
|
xml:id="sec-writing-documentation">
|
||||||
|
<title>Writing NixOS Documentation</title>
|
||||||
|
<para>
|
||||||
|
As NixOS grows, so too does the need for a catalogue and explanation of its
|
||||||
|
extensive functionality. Collecting pertinent information from disparate
|
||||||
|
sources and presenting it in an accessible style would be a worthy
|
||||||
|
contribution to the project.
|
||||||
|
</para>
|
||||||
|
<section>
|
||||||
|
<title>Building the Manual</title>
|
||||||
|
|
||||||
<title>Writing NixOS Documentation</title>
|
<para>
|
||||||
|
The DocBook sources of the <xref linkend="book-nixos-manual"/> are in the
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual"><filename>nixos/doc/manual</filename></link>
|
||||||
|
subdirectory of the Nixpkgs repository.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
As NixOS grows, so too does the need for a catalogue and explanation
|
You can quickly validate your edits with <command>make</command>:
|
||||||
of its extensive functionality. Collecting pertinent information
|
</para>
|
||||||
from disparate sources and presenting it in an accessible style
|
|
||||||
would be a worthy contribution to the project.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<section>
|
|
||||||
<title>Building the Manual</title>
|
|
||||||
<para>
|
|
||||||
The DocBook sources of the <xref linkend="book-nixos-manual"/> are in the
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual"><filename>nixos/doc/manual</filename></link>
|
|
||||||
subdirectory of the Nixpkgs repository.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
You can quickly validate your edits with <command>make</command>:
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ cd /path/to/nixpkgs/nixos/doc/manual
|
$ cd /path/to/nixpkgs/nixos/doc/manual
|
||||||
$ make
|
$ make
|
||||||
</screen>
|
</screen>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Once you are done making modifications to the manual, it's important
|
Once you are done making modifications to the manual, it's important to
|
||||||
to build it before committing. You can do that as follows:
|
build it before committing. You can do that as follows:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<screen>nix-build nixos/release.nix -A manual.x86_64-linux</screen>
|
<screen>nix-build nixos/release.nix -A manual.x86_64-linux</screen>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When this command successfully finishes, it will tell you where the
|
When this command successfully finishes, it will tell you where the manual
|
||||||
manual got generated. The HTML will be accessible through the
|
got generated. The HTML will be accessible through the
|
||||||
<filename>result</filename> symlink at
|
<filename>result</filename> symlink at
|
||||||
<filename>./result/share/doc/nixos/index.html</filename>.
|
<filename>./result/share/doc/nixos/index.html</filename>.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
<section>
|
||||||
|
<title>Editing DocBook XML</title>
|
||||||
|
|
||||||
<section>
|
<para>
|
||||||
<title>Editing DocBook XML</title>
|
For general information on how to write in DocBook, see
|
||||||
|
<link xlink:href="http://www.docbook.org/tdg5/en/html/docbook.html"> DocBook
|
||||||
|
5: The Definitive Guide</link>.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For general information on how to write in DocBook, see
|
Emacs nXML Mode is very helpful for editing DocBook XML because it validates
|
||||||
<link xlink:href="http://www.docbook.org/tdg5/en/html/docbook.html">
|
the document as you write, and precisely locates errors. To use it, see
|
||||||
DocBook 5: The Definitive Guide</link>.
|
<xref linkend="sec-emacs-docbook-xml"/>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Emacs nXML Mode is very helpful for editing DocBook XML because it
|
<link xlink:href="http://pandoc.org">Pandoc</link> can generate DocBook XML
|
||||||
validates the document as you write, and precisely locates
|
from a multitude of formats, which makes a good starting point.
|
||||||
errors. To use it, see <xref linkend="sec-emacs-docbook-xml"/>.
|
<example xml:id="ex-pandoc-xml-conv">
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
<link xlink:href="http://pandoc.org">Pandoc</link> can generate
|
|
||||||
DocBook XML from a multitude of formats, which makes a good starting
|
|
||||||
point.
|
|
||||||
|
|
||||||
<example xml:id="ex-pandoc-xml-conv">
|
|
||||||
<title>Pandoc invocation to convert GitHub-Flavoured MarkDown to DocBook 5 XML</title>
|
<title>Pandoc invocation to convert GitHub-Flavoured MarkDown to DocBook 5 XML</title>
|
||||||
<screen>pandoc -f markdown_github -t docbook5 docs.md -o my-section.md</screen>
|
<screen>pandoc -f markdown_github -t docbook5 docs.md -o my-section.md</screen>
|
||||||
</example>
|
</example>
|
||||||
|
Pandoc can also quickly convert a single <filename>section.xml</filename> to
|
||||||
|
HTML, which is helpful when drafting.
|
||||||
|
</para>
|
||||||
|
|
||||||
Pandoc can also quickly convert a single
|
<para>
|
||||||
<filename>section.xml</filename> to HTML, which is helpful when
|
Sometimes writing valid DocBook is simply too difficult. In this case,
|
||||||
drafting.
|
submit your documentation updates in a
|
||||||
</para>
|
<link
|
||||||
|
|
||||||
<para>
|
|
||||||
Sometimes writing valid DocBook is simply too difficult. In this
|
|
||||||
case, submit your documentation updates in a <link
|
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/issues/new">GitHub
|
xlink:href="https://github.com/NixOS/nixpkgs/issues/new">GitHub
|
||||||
Issue</link> and someone will handle the conversion to XML for you.
|
Issue</link> and someone will handle the conversion to XML for you.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
<section>
|
||||||
|
<title>Creating a Topic</title>
|
||||||
|
|
||||||
<section>
|
<para>
|
||||||
<title>Creating a Topic</title>
|
You can use an existing topic as a basis for the new topic or create a topic
|
||||||
|
from scratch.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
You can use an existing topic as a basis for the new topic or create a topic from scratch.
|
Keep the following guidelines in mind when you create and add a topic:
|
||||||
</para>
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The NixOS
|
||||||
|
<link xlink:href="http://www.docbook.org/tdg5/en/html/book.html"><tag>book</tag></link>
|
||||||
|
element is in <filename>nixos/doc/manual/manual.xml</filename>. It
|
||||||
|
includes several
|
||||||
|
<link xlink:href="http://www.docbook.org/tdg5/en/html/book.html"><tag>part</tag>s</link>
|
||||||
|
which are in subdirectories.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Store the topic file in the same directory as the <tag>part</tag> to
|
||||||
|
which it belongs. If your topic is about configuring a NixOS module, then
|
||||||
|
the XML file can be stored alongside the module definition
|
||||||
|
<filename>nix</filename> file.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
If you include multiple words in the file name, separate the words with a
|
||||||
|
dash. For example: <filename>ipv6-config.xml</filename>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Make sure that the <tag>xml:id</tag> value is unique. You can use
|
||||||
|
abbreviations if the ID is too long. For example:
|
||||||
|
<varname>nixos-config</varname>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Determine whether your topic is a chapter or a section. If you are
|
||||||
|
unsure, open an existing topic file and check whether the main element is
|
||||||
|
chapter or section.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section>
|
||||||
|
<title>Adding a Topic to the Book</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Keep the following guidelines in mind when you create and add a topic:
|
Open the parent XML file and add an <varname>xi:include</varname> element to
|
||||||
|
the list of chapters with the file name of the topic that you created. If
|
||||||
|
you created a <tag>section</tag>, you add the file to the <tag>chapter</tag>
|
||||||
|
file. If you created a <tag>chapter</tag>, you add the file to the
|
||||||
|
<tag>part</tag> file.
|
||||||
|
</para>
|
||||||
|
|
||||||
<itemizedlist>
|
<para>
|
||||||
<listitem><para>
|
If the topic is about configuring a NixOS module, it can be automatically
|
||||||
The NixOS <link xlink:href="http://www.docbook.org/tdg5/en/html/book.html"><tag>book</tag></link>
|
included in the manual by using the <varname>meta.doc</varname> attribute.
|
||||||
element is in <filename>nixos/doc/manual/manual.xml</filename>.
|
See <xref
|
||||||
It includes several
|
|
||||||
<link xlink:href="http://www.docbook.org/tdg5/en/html/book.html"><tag>part</tag>s</link>
|
|
||||||
which are in subdirectories.
|
|
||||||
</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>
|
|
||||||
Store the topic file in the same directory as the <tag>part</tag>
|
|
||||||
to which it belongs. If your topic is about configuring a NixOS
|
|
||||||
module, then the XML file can be stored alongside the module
|
|
||||||
definition <filename>nix</filename> file.
|
|
||||||
</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>
|
|
||||||
If you include multiple words in the file name, separate the words
|
|
||||||
with a dash. For example: <filename>ipv6-config.xml</filename>.
|
|
||||||
</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>
|
|
||||||
Make sure that the <tag>xml:id</tag> value is unique. You can use
|
|
||||||
abbreviations if the ID is too long. For example:
|
|
||||||
<varname>nixos-config</varname>.
|
|
||||||
</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>
|
|
||||||
Determine whether your topic is a chapter or a section. If you are
|
|
||||||
unsure, open an existing topic file and check whether the main
|
|
||||||
element is chapter or section.
|
|
||||||
</para></listitem>
|
|
||||||
|
|
||||||
</itemizedlist>
|
|
||||||
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section>
|
|
||||||
<title>Adding a Topic to the Book</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Open the parent XML file and add an <varname>xi:include</varname>
|
|
||||||
element to the list of chapters with the file name of the topic that
|
|
||||||
you created. If you created a <tag>section</tag>, you add the file to
|
|
||||||
the <tag>chapter</tag> file. If you created a <tag>chapter</tag>, you
|
|
||||||
add the file to the <tag>part</tag> file.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If the topic is about configuring a NixOS module, it can be
|
|
||||||
automatically included in the manual by using the
|
|
||||||
<varname>meta.doc</varname> attribute. See <xref
|
|
||||||
linkend="sec-meta-attributes"/> for an explanation.
|
linkend="sec-meta-attributes"/> for an explanation.
|
||||||
</para>
|
</para>
|
||||||
|
</section>
|
||||||
</section>
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,52 +3,54 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-writing-modules">
|
xml:id="sec-writing-modules">
|
||||||
|
<title>Writing NixOS Modules</title>
|
||||||
<title>Writing NixOS Modules</title>
|
<para>
|
||||||
|
NixOS has a modular system for declarative configuration. This system
|
||||||
<para>NixOS has a modular system for declarative configuration. This
|
combines multiple <emphasis>modules</emphasis> to produce the full system
|
||||||
system combines multiple <emphasis>modules</emphasis> to produce the
|
configuration. One of the modules that constitute the configuration is
|
||||||
full system configuration. One of the modules that constitute the
|
<filename>/etc/nixos/configuration.nix</filename>. Most of the others live in
|
||||||
configuration is <filename>/etc/nixos/configuration.nix</filename>.
|
the
|
||||||
Most of the others live in the <link
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/modules"><filename>nixos/modules</filename></link>
|
xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/modules"><filename>nixos/modules</filename></link>
|
||||||
subdirectory of the Nixpkgs tree.</para>
|
subdirectory of the Nixpkgs tree.
|
||||||
|
</para>
|
||||||
<para>Each NixOS module is a file that handles one logical aspect of
|
<para>
|
||||||
the configuration, such as a specific kind of hardware, a service, or
|
Each NixOS module is a file that handles one logical aspect of the
|
||||||
network settings. A module configuration does not have to handle
|
configuration, such as a specific kind of hardware, a service, or network
|
||||||
everything from scratch; it can use the functionality provided by
|
settings. A module configuration does not have to handle everything from
|
||||||
other modules for its implementation. Thus a module can
|
scratch; it can use the functionality provided by other modules for its
|
||||||
<emphasis>declare</emphasis> options that can be used by other
|
implementation. Thus a module can <emphasis>declare</emphasis> options that
|
||||||
modules, and conversely can <emphasis>define</emphasis> options
|
can be used by other modules, and conversely can <emphasis>define</emphasis>
|
||||||
provided by other modules in its own implementation. For example, the
|
options provided by other modules in its own implementation. For example, the
|
||||||
module <link
|
module
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/pam.nix"><filename>pam.nix</filename></link>
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/pam.nix"><filename>pam.nix</filename></link>
|
||||||
declares the option <option>security.pam.services</option> that allows
|
declares the option <option>security.pam.services</option> that allows other
|
||||||
other modules (e.g. <link
|
modules (e.g.
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/ssh/sshd.nix"><filename>sshd.nix</filename></link>)
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/ssh/sshd.nix"><filename>sshd.nix</filename></link>)
|
||||||
to define PAM services; and it defines the option
|
to define PAM services; and it defines the option
|
||||||
<option>environment.etc</option> (declared by <link
|
<option>environment.etc</option> (declared by
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/etc/etc.nix"><filename>etc.nix</filename></link>)
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/etc/etc.nix"><filename>etc.nix</filename></link>)
|
||||||
to cause files to be created in
|
to cause files to be created in <filename>/etc/pam.d</filename>.
|
||||||
<filename>/etc/pam.d</filename>.</para>
|
</para>
|
||||||
|
<para xml:id="para-module-syn">
|
||||||
<para xml:id="para-module-syn">In <xref
|
In <xref
|
||||||
linkend="sec-configuration-syntax"/>, we saw the following structure
|
linkend="sec-configuration-syntax"/>, we saw the following structure
|
||||||
of NixOS modules:
|
of NixOS modules:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }:
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
{ <replaceable>option definitions</replaceable>
|
{ <replaceable>option definitions</replaceable>
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This is actually an <emphasis>abbreviated</emphasis> form of module that only
|
||||||
This is actually an <emphasis>abbreviated</emphasis> form of module
|
defines options, but does not declare any. The structure of full NixOS
|
||||||
that only defines options, but does not declare any. The structure of
|
modules is shown in <xref linkend='ex-module-syntax' />.
|
||||||
full NixOS modules is shown in <xref linkend='ex-module-syntax' />.</para>
|
</para>
|
||||||
|
<example xml:id='ex-module-syntax'>
|
||||||
<example xml:id='ex-module-syntax'><title>Structure of NixOS Modules</title>
|
<title>Structure of NixOS Modules</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ... }: <co xml:id='module-syntax-1' />
|
{ config, pkgs, ... }: <co xml:id='module-syntax-1' />
|
||||||
|
|
||||||
@ -65,56 +67,56 @@ full NixOS modules is shown in <xref linkend='ex-module-syntax' />.</para>
|
|||||||
<replaceable>option definitions</replaceable> <co xml:id='module-syntax-4' />
|
<replaceable>option definitions</replaceable> <co xml:id='module-syntax-4' />
|
||||||
};
|
};
|
||||||
}</programlisting>
|
}</programlisting>
|
||||||
</example>
|
</example>
|
||||||
|
<para>
|
||||||
<para>The meaning of each part is as follows.
|
The meaning of each part is as follows.
|
||||||
|
<calloutlist>
|
||||||
<calloutlist>
|
<callout arearefs='module-syntax-1'>
|
||||||
<callout arearefs='module-syntax-1'>
|
<para>
|
||||||
<para>This line makes the current Nix expression a function. The
|
This line makes the current Nix expression a function. The variable
|
||||||
variable <varname>pkgs</varname> contains Nixpkgs, while
|
<varname>pkgs</varname> contains Nixpkgs, while <varname>config</varname>
|
||||||
<varname>config</varname> contains the full system configuration.
|
contains the full system configuration. This line can be omitted if there
|
||||||
This line can be omitted if there is no reference to
|
is no reference to <varname>pkgs</varname> and <varname>config</varname>
|
||||||
<varname>pkgs</varname> and <varname>config</varname> inside the
|
inside the module.
|
||||||
module.</para>
|
</para>
|
||||||
</callout>
|
</callout>
|
||||||
|
<callout arearefs='module-syntax-2'>
|
||||||
<callout arearefs='module-syntax-2'>
|
<para>
|
||||||
<para>This list enumerates the paths to other NixOS modules that
|
This list enumerates the paths to other NixOS modules that should be
|
||||||
should be included in the evaluation of the system configuration.
|
included in the evaluation of the system configuration. A default set of
|
||||||
A default set of modules is defined in the file
|
modules is defined in the file
|
||||||
<filename>modules/module-list.nix</filename>. These don't need to
|
<filename>modules/module-list.nix</filename>. These don't need to be added
|
||||||
be added in the import list.</para>
|
in the import list.
|
||||||
</callout>
|
</para>
|
||||||
|
</callout>
|
||||||
<callout arearefs='module-syntax-3'>
|
<callout arearefs='module-syntax-3'>
|
||||||
<para>The attribute <varname>options</varname> is a nested set of
|
<para>
|
||||||
<emphasis>option declarations</emphasis> (described below).</para>
|
The attribute <varname>options</varname> is a nested set of
|
||||||
</callout>
|
<emphasis>option declarations</emphasis> (described below).
|
||||||
|
</para>
|
||||||
<callout arearefs='module-syntax-4'>
|
</callout>
|
||||||
<para>The attribute <varname>config</varname> is a nested set of
|
<callout arearefs='module-syntax-4'>
|
||||||
<emphasis>option definitions</emphasis> (also described
|
<para>
|
||||||
below).</para>
|
The attribute <varname>config</varname> is a nested set of
|
||||||
</callout>
|
<emphasis>option definitions</emphasis> (also described below).
|
||||||
</calloutlist>
|
</para>
|
||||||
|
</callout>
|
||||||
</para>
|
</calloutlist>
|
||||||
|
</para>
|
||||||
<para><xref linkend='locate-example' /> shows a module that handles
|
<para>
|
||||||
the regular update of the “locate” database, an index of all files in
|
<xref linkend='locate-example' /> shows a module that handles the regular
|
||||||
the file system. This module declares two options that can be defined
|
update of the “locate” database, an index of all files in the file
|
||||||
by other modules (typically the user’s
|
system. This module declares two options that can be defined by other modules
|
||||||
<filename>configuration.nix</filename>):
|
(typically the user’s <filename>configuration.nix</filename>):
|
||||||
<option>services.locate.enable</option> (whether the database should
|
<option>services.locate.enable</option> (whether the database should be
|
||||||
be updated) and <option>services.locate.interval</option> (when the
|
updated) and <option>services.locate.interval</option> (when the update
|
||||||
update should be done). It implements its functionality by defining
|
should be done). It implements its functionality by defining two options
|
||||||
two options declared by other modules:
|
declared by other modules: <option>systemd.services</option> (the set of all
|
||||||
<option>systemd.services</option> (the set of all systemd services)
|
systemd services) and <option>systemd.timers</option> (the list of commands
|
||||||
and <option>systemd.timers</option> (the list of commands to be
|
to be executed periodically by <command>systemd</command>).
|
||||||
executed periodically by <command>systemd</command>).</para>
|
</para>
|
||||||
|
<example xml:id='locate-example'>
|
||||||
<example xml:id='locate-example'><title>NixOS Module for the “locate” Service</title>
|
<title>NixOS Module for the “locate” Service</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, lib, pkgs, ... }:
|
{ config, lib, pkgs, ... }:
|
||||||
|
|
||||||
@ -173,14 +175,12 @@ in {
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
|
<xi:include href="option-declarations.xml" />
|
||||||
<xi:include href="option-declarations.xml" />
|
<xi:include href="option-types.xml" />
|
||||||
<xi:include href="option-types.xml" />
|
<xi:include href="option-def.xml" />
|
||||||
<xi:include href="option-def.xml" />
|
<xi:include href="assertions.xml" />
|
||||||
<xi:include href="assertions.xml" />
|
<xi:include href="meta-attributes.xml" />
|
||||||
<xi:include href="meta-attributes.xml" />
|
<xi:include href="importing-modules.xml" />
|
||||||
<xi:include href="importing-modules.xml" />
|
<xi:include href="replace-modules.xml" />
|
||||||
<xi:include href="replace-modules.xml" />
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,11 +3,10 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-writing-nixos-tests">
|
xml:id="sec-writing-nixos-tests">
|
||||||
|
<title>Writing Tests</title>
|
||||||
|
|
||||||
<title>Writing Tests</title>
|
<para>
|
||||||
|
A NixOS test is a Nix expression that has the following structure:
|
||||||
<para>A NixOS test is a Nix expression that has the following structure:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
import ./make-test.nix {
|
import ./make-test.nix {
|
||||||
|
|
||||||
@ -32,277 +31,364 @@ import ./make-test.nix {
|
|||||||
'';
|
'';
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The attribute <literal>testScript</literal> is a bit of Perl code that
|
||||||
The attribute <literal>testScript</literal> is a bit of Perl code that
|
executes the test (described below). During the test, it will start one or
|
||||||
executes the test (described below). During the test, it will start
|
more virtual machines, the configuration of which is described by the
|
||||||
one or more virtual machines, the configuration of which is described
|
attribute <literal>machine</literal> (if you need only one machine in your
|
||||||
by the attribute <literal>machine</literal> (if you need only one
|
test) or by the attribute <literal>nodes</literal> (if you need multiple
|
||||||
machine in your test) or by the attribute <literal>nodes</literal> (if
|
machines). For instance,
|
||||||
you need multiple machines). For instance, <filename
|
<filename
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/login.nix">login.nix</filename>
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/login.nix">login.nix</filename>
|
||||||
only needs a single machine to test whether users can log in on the
|
only needs a single machine to test whether users can log in on the virtual
|
||||||
virtual console, whether device ownership is correctly maintained when
|
console, whether device ownership is correctly maintained when switching
|
||||||
switching between consoles, and so on. On the other hand, <filename
|
between consoles, and so on. On the other hand,
|
||||||
|
<filename
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/nfs.nix">nfs.nix</filename>,
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/nfs.nix">nfs.nix</filename>,
|
||||||
which tests NFS client and server functionality in the Linux kernel
|
which tests NFS client and server functionality in the Linux kernel
|
||||||
(including whether locks are maintained across server crashes),
|
(including whether locks are maintained across server crashes), requires
|
||||||
requires three machines: a server and two clients.</para>
|
three machines: a server and two clients.
|
||||||
|
</para>
|
||||||
<para>There are a few special NixOS configuration options for test
|
|
||||||
VMs:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
There are a few special NixOS configuration options for test VMs:
|
||||||
<!-- FIXME: would be nice to generate this automatically. -->
|
<!-- FIXME: would be nice to generate this automatically. -->
|
||||||
|
<variablelist>
|
||||||
<variablelist>
|
<varlistentry>
|
||||||
|
<term><option>virtualisation.memorySize</option>
|
||||||
<varlistentry>
|
</term>
|
||||||
<term><option>virtualisation.memorySize</option></term>
|
<listitem>
|
||||||
<listitem><para>The memory of the VM in
|
<para>
|
||||||
megabytes.</para></listitem>
|
The memory of the VM in megabytes.
|
||||||
</varlistentry>
|
</para>
|
||||||
|
</listitem>
|
||||||
<varlistentry>
|
</varlistentry>
|
||||||
<term><option>virtualisation.vlans</option></term>
|
<varlistentry>
|
||||||
<listitem><para>The virtual networks to which the VM is
|
<term><option>virtualisation.vlans</option>
|
||||||
connected. See <filename
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The virtual networks to which the VM is connected. See
|
||||||
|
<filename
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/nat.nix">nat.nix</filename>
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/nat.nix">nat.nix</filename>
|
||||||
for an example.</para></listitem>
|
for an example.
|
||||||
</varlistentry>
|
</para>
|
||||||
|
</listitem>
|
||||||
<varlistentry>
|
</varlistentry>
|
||||||
<term><option>virtualisation.writableStore</option></term>
|
<varlistentry>
|
||||||
<listitem><para>By default, the Nix store in the VM is not
|
<term><option>virtualisation.writableStore</option>
|
||||||
writable. If you enable this option, a writable union file system
|
</term>
|
||||||
is mounted on top of the Nix store to make it appear
|
<listitem>
|
||||||
writable. This is necessary for tests that run Nix operations that
|
<para>
|
||||||
modify the store.</para></listitem>
|
By default, the Nix store in the VM is not writable. If you enable this
|
||||||
</varlistentry>
|
option, a writable union file system is mounted on top of the Nix store
|
||||||
|
to make it appear writable. This is necessary for tests that run Nix
|
||||||
</variablelist>
|
operations that modify the store.
|
||||||
|
</para>
|
||||||
For more options, see the module <filename
|
</listitem>
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/qemu-vm.nix">qemu-vm.nix</filename>.</para>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
<para>The test script is a sequence of Perl statements that perform
|
For more options, see the module
|
||||||
various actions, such as starting VMs, executing commands in the VMs,
|
<filename
|
||||||
and so on. Each virtual machine is represented as an object stored in
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/qemu-vm.nix">qemu-vm.nix</filename>.
|
||||||
the variable <literal>$<replaceable>name</replaceable></literal>,
|
</para>
|
||||||
where <replaceable>name</replaceable> is the identifier of the machine
|
|
||||||
(which is just <literal>machine</literal> if you didn’t specify
|
|
||||||
multiple machines using the <literal>nodes</literal> attribute). For
|
|
||||||
instance, the following starts the machine, waits until it has
|
|
||||||
finished booting, then executes a command and checks that the output
|
|
||||||
is more-or-less correct:
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The test script is a sequence of Perl statements that perform various
|
||||||
|
actions, such as starting VMs, executing commands in the VMs, and so on. Each
|
||||||
|
virtual machine is represented as an object stored in the variable
|
||||||
|
<literal>$<replaceable>name</replaceable></literal>, where
|
||||||
|
<replaceable>name</replaceable> is the identifier of the machine (which is
|
||||||
|
just <literal>machine</literal> if you didn’t specify multiple machines
|
||||||
|
using the <literal>nodes</literal> attribute). For instance, the following
|
||||||
|
starts the machine, waits until it has finished booting, then executes a
|
||||||
|
command and checks that the output is more-or-less correct:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
$machine->start;
|
$machine->start;
|
||||||
$machine->waitForUnit("default.target");
|
$machine->waitForUnit("default.target");
|
||||||
$machine->succeed("uname") =~ /Linux/;
|
$machine->succeed("uname") =~ /Linux/;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
The first line is actually unnecessary; machines are implicitly started when
|
||||||
The first line is actually unnecessary; machines are implicitly
|
you first execute an action on them (such as <literal>waitForUnit</literal>
|
||||||
started when you first execute an action on them (such as
|
or <literal>succeed</literal>). If you have multiple machines, you can speed
|
||||||
<literal>waitForUnit</literal> or <literal>succeed</literal>). If you
|
up the test by starting them in parallel:
|
||||||
have multiple machines, you can speed up the test by starting them in
|
|
||||||
parallel:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
startAll;
|
startAll;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para>
|
<para>
|
||||||
|
The following methods are available on machine objects:
|
||||||
<para>The following methods are available on machine objects:
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><methodname>start</methodname>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>start</methodname></term>
|
|
||||||
<listitem><para>Start the virtual machine. This method is
|
|
||||||
asynchronous — it does not wait for the machine to finish
|
|
||||||
booting.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>shutdown</methodname></term>
|
|
||||||
<listitem><para>Shut down the machine, waiting for the VM to
|
|
||||||
exit.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>crash</methodname></term>
|
|
||||||
<listitem><para>Simulate a sudden power failure, by telling the VM
|
|
||||||
to exit immediately.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>block</methodname></term>
|
|
||||||
<listitem><para>Simulate unplugging the Ethernet cable that
|
|
||||||
connects the machine to the other machines.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>unblock</methodname></term>
|
|
||||||
<listitem><para>Undo the effect of
|
|
||||||
<methodname>block</methodname>.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>screenshot</methodname></term>
|
|
||||||
<listitem><para>Take a picture of the display of the virtual
|
|
||||||
machine, in PNG format. The screenshot is linked from the HTML
|
|
||||||
log.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>getScreenText</methodname></term>
|
|
||||||
<listitem><para>Return a textual representation of what is currently
|
|
||||||
visible on the machine's screen using optical character
|
|
||||||
recognition.</para>
|
|
||||||
<note><para>This requires passing <option>enableOCR</option> to the test
|
|
||||||
attribute set.</para></note></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>sendMonitorCommand</methodname></term>
|
|
||||||
<listitem><para>Send a command to the QEMU monitor. This is rarely
|
|
||||||
used, but allows doing stuff such as attaching virtual USB disks
|
|
||||||
to a running machine.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>sendKeys</methodname></term>
|
|
||||||
<listitem><para>Simulate pressing keys on the virtual keyboard,
|
|
||||||
e.g., <literal>sendKeys("ctrl-alt-delete")</literal>.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>sendChars</methodname></term>
|
|
||||||
<listitem><para>Simulate typing a sequence of characters on the
|
|
||||||
virtual keyboard, e.g., <literal>sendKeys("foobar\n")</literal>
|
|
||||||
will type the string <literal>foobar</literal> followed by the
|
|
||||||
Enter key.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>execute</methodname></term>
|
|
||||||
<listitem><para>Execute a shell command, returning a list
|
|
||||||
<literal>(<replaceable>status</replaceable>,
|
|
||||||
<replaceable>stdout</replaceable>)</literal>.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>succeed</methodname></term>
|
|
||||||
<listitem><para>Execute a shell command, raising an exception if
|
|
||||||
the exit status is not zero, otherwise returning the standard
|
|
||||||
output.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>fail</methodname></term>
|
|
||||||
<listitem><para>Like <methodname>succeed</methodname>, but raising
|
|
||||||
an exception if the command returns a zero status.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitUntilSucceeds</methodname></term>
|
|
||||||
<listitem><para>Repeat a shell command with 1-second intervals
|
|
||||||
until it succeeds.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitUntilFails</methodname></term>
|
|
||||||
<listitem><para>Repeat a shell command with 1-second intervals
|
|
||||||
until it fails.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForUnit</methodname></term>
|
|
||||||
<listitem><para>Wait until the specified systemd unit has reached
|
|
||||||
the “active” state.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForFile</methodname></term>
|
|
||||||
<listitem><para>Wait until the specified file
|
|
||||||
exists.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForOpenPort</methodname></term>
|
|
||||||
<listitem><para>Wait until a process is listening on the given TCP
|
|
||||||
port (on <literal>localhost</literal>, at least).</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForClosedPort</methodname></term>
|
|
||||||
<listitem><para>Wait until nobody is listening on the given TCP
|
|
||||||
port.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForX</methodname></term>
|
|
||||||
<listitem><para>Wait until the X11 server is accepting
|
|
||||||
connections.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForText</methodname></term>
|
|
||||||
<listitem><para>Wait until the supplied regular expressions matches
|
|
||||||
the textual contents of the screen by using optical character recognition
|
|
||||||
(see <methodname>getScreenText</methodname>).</para>
|
|
||||||
<note><para>This requires passing <option>enableOCR</option> to the test
|
|
||||||
attribute set.</para></note></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>waitForWindow</methodname></term>
|
|
||||||
<listitem><para>Wait until an X11 window has appeared whose name
|
|
||||||
matches the given regular expression, e.g.,
|
|
||||||
<literal>waitForWindow(qr/Terminal/)</literal>.</para></listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>copyFileFromHost</methodname></term>
|
|
||||||
<listitem><para>Copies a file from host to machine, e.g.,
|
|
||||||
<literal>copyFileFromHost("myfile", "/etc/my/important/file")</literal>.</para>
|
|
||||||
<para>The first argument is the file on the host. The file needs to be
|
|
||||||
accessible while building the nix derivation. The second argument is
|
|
||||||
the location of the file on the machine.</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><methodname>systemctl</methodname></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Runs <literal>systemctl</literal> commands with optional support for
|
<para>
|
||||||
<literal>systemctl --user</literal></para>
|
Start the virtual machine. This method is asynchronous — it does not
|
||||||
<para>
|
wait for the machine to finish booting.
|
||||||
<programlisting>
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>shutdown</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Shut down the machine, waiting for the VM to exit.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>crash</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Simulate a sudden power failure, by telling the VM to exit immediately.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>block</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Simulate unplugging the Ethernet cable that connects the machine to the
|
||||||
|
other machines.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>unblock</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Undo the effect of <methodname>block</methodname>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>screenshot</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Take a picture of the display of the virtual machine, in PNG format. The
|
||||||
|
screenshot is linked from the HTML log.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>getScreenText</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Return a textual representation of what is currently visible on the
|
||||||
|
machine's screen using optical character recognition.
|
||||||
|
</para>
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
This requires passing <option>enableOCR</option> to the test attribute
|
||||||
|
set.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>sendMonitorCommand</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Send a command to the QEMU monitor. This is rarely used, but allows doing
|
||||||
|
stuff such as attaching virtual USB disks to a running machine.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>sendKeys</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Simulate pressing keys on the virtual keyboard, e.g.,
|
||||||
|
<literal>sendKeys("ctrl-alt-delete")</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>sendChars</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Simulate typing a sequence of characters on the virtual keyboard, e.g.,
|
||||||
|
<literal>sendKeys("foobar\n")</literal> will type the string
|
||||||
|
<literal>foobar</literal> followed by the Enter key.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>execute</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Execute a shell command, returning a list
|
||||||
|
<literal>(<replaceable>status</replaceable>,
|
||||||
|
<replaceable>stdout</replaceable>)</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>succeed</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Execute a shell command, raising an exception if the exit status is not
|
||||||
|
zero, otherwise returning the standard output.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>fail</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Like <methodname>succeed</methodname>, but raising an exception if the
|
||||||
|
command returns a zero status.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitUntilSucceeds</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Repeat a shell command with 1-second intervals until it succeeds.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitUntilFails</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Repeat a shell command with 1-second intervals until it fails.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForUnit</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until the specified systemd unit has reached the “active” state.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForFile</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until the specified file exists.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForOpenPort</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until a process is listening on the given TCP port (on
|
||||||
|
<literal>localhost</literal>, at least).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForClosedPort</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until nobody is listening on the given TCP port.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForX</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until the X11 server is accepting connections.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForText</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until the supplied regular expressions matches the textual contents
|
||||||
|
of the screen by using optical character recognition (see
|
||||||
|
<methodname>getScreenText</methodname>).
|
||||||
|
</para>
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
This requires passing <option>enableOCR</option> to the test attribute
|
||||||
|
set.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>waitForWindow</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Wait until an X11 window has appeared whose name matches the given
|
||||||
|
regular expression, e.g., <literal>waitForWindow(qr/Terminal/)</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>copyFileFromHost</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Copies a file from host to machine, e.g.,
|
||||||
|
<literal>copyFileFromHost("myfile", "/etc/my/important/file")</literal>.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The first argument is the file on the host. The file needs to be
|
||||||
|
accessible while building the nix derivation. The second argument is the
|
||||||
|
location of the file on the machine.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><methodname>systemctl</methodname>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Runs <literal>systemctl</literal> commands with optional support for
|
||||||
|
<literal>systemctl --user</literal>
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
<programlisting>
|
||||||
$machine->systemctl("list-jobs --no-pager"); // runs `systemctl list-jobs --no-pager`
|
$machine->systemctl("list-jobs --no-pager"); // runs `systemctl list-jobs --no-pager`
|
||||||
$machine->systemctl("list-jobs --no-pager", "any-user"); // spawns a shell for `any-user` and runs `systemctl --user list-jobs --no-pager`
|
$machine->systemctl("list-jobs --no-pager", "any-user"); // spawns a shell for `any-user` and runs `systemctl --user list-jobs --no-pager`
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</para>
|
||||||
|
|
||||||
</variablelist>
|
<para>
|
||||||
|
To test user units declared by <literal>systemd.user.services</literal> the
|
||||||
</para>
|
optional <literal>$user</literal> argument can be used:
|
||||||
|
<programlisting>
|
||||||
<para>
|
|
||||||
To test user units declared by <literal>systemd.user.services</literal> the optional <literal>$user</literal>
|
|
||||||
argument can be used:
|
|
||||||
|
|
||||||
<programlisting>
|
|
||||||
$machine->start;
|
$machine->start;
|
||||||
$machine->waitForX;
|
$machine->waitForX;
|
||||||
$machine->waitForUnit("xautolock.service", "x-session-user");
|
$machine->waitForUnit("xautolock.service", "x-session-user");
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
This applies to <literal>systemctl</literal>, <literal>getUnitInfo</literal>,
|
This applies to <literal>systemctl</literal>, <literal>getUnitInfo</literal>,
|
||||||
<literal>waitForUnit</literal>, <literal>startJob</literal>
|
<literal>waitForUnit</literal>, <literal>startJob</literal> and
|
||||||
and <literal>stopJob</literal>.
|
<literal>stopJob</literal>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -2,101 +2,84 @@
|
|||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-changing-config">
|
xml:id="sec-changing-config">
|
||||||
|
<title>Changing the Configuration</title>
|
||||||
<title>Changing the Configuration</title>
|
<para>
|
||||||
|
The file <filename>/etc/nixos/configuration.nix</filename> contains the
|
||||||
<para>The file <filename>/etc/nixos/configuration.nix</filename>
|
current configuration of your machine. Whenever you’ve
|
||||||
contains the current configuration of your machine. Whenever you’ve
|
<link linkend="ch-configuration">changed something</link> in that file, you
|
||||||
<link linkend="ch-configuration">changed something</link> in that file, you should do
|
should do
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch</screen>
|
# nixos-rebuild switch</screen>
|
||||||
|
to build the new configuration, make it the default configuration for
|
||||||
to build the new configuration, make it the default configuration for
|
booting, and try to realise the configuration in the running system (e.g., by
|
||||||
booting, and try to realise the configuration in the running system
|
restarting system services).
|
||||||
(e.g., by restarting system services).</para>
|
</para>
|
||||||
|
<warning>
|
||||||
<warning><para>These commands must be executed as root, so you should
|
<para>
|
||||||
either run them from a root shell or by prefixing them with
|
These commands must be executed as root, so you should either run them from
|
||||||
<literal>sudo -i</literal>.</para></warning>
|
a root shell or by prefixing them with <literal>sudo -i</literal>.
|
||||||
|
</para>
|
||||||
<para>You can also do
|
</warning>
|
||||||
|
<para>
|
||||||
|
You can also do
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild test</screen>
|
# nixos-rebuild test</screen>
|
||||||
|
to build the configuration and switch the running system to it, but without
|
||||||
to build the configuration and switch the running system to it, but
|
making it the boot default. So if (say) the configuration locks up your
|
||||||
without making it the boot default. So if (say) the configuration
|
machine, you can just reboot to get back to a working configuration.
|
||||||
locks up your machine, you can just reboot to get back to a working
|
</para>
|
||||||
configuration.</para>
|
<para>
|
||||||
|
There is also
|
||||||
<para>There is also
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild boot</screen>
|
# nixos-rebuild boot</screen>
|
||||||
|
to build the configuration and make it the boot default, but not switch to it
|
||||||
to build the configuration and make it the boot default, but not
|
now (so it will only take effect after the next reboot).
|
||||||
switch to it now (so it will only take effect after the next
|
</para>
|
||||||
reboot).</para>
|
<para>
|
||||||
|
You can make your configuration show up in a different submenu of the GRUB 2
|
||||||
<para>You can make your configuration show up in a different submenu
|
boot screen by giving it a different <emphasis>profile name</emphasis>, e.g.
|
||||||
of the GRUB 2 boot screen by giving it a different <emphasis>profile
|
|
||||||
name</emphasis>, e.g.
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch -p test </screen>
|
# nixos-rebuild switch -p test </screen>
|
||||||
|
which causes the new configuration (and previous ones created using
|
||||||
which causes the new configuration (and previous ones created using
|
<literal>-p test</literal>) to show up in the GRUB submenu “NixOS - Profile
|
||||||
<literal>-p test</literal>) to show up in the GRUB submenu “NixOS -
|
'test'”. This can be useful to separate test configurations from
|
||||||
Profile 'test'”. This can be useful to separate test configurations
|
“stable” configurations.
|
||||||
from “stable” configurations.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>Finally, you can do
|
Finally, you can do
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-rebuild build</screen>
|
$ nixos-rebuild build</screen>
|
||||||
|
to build the configuration but nothing more. This is useful to see whether
|
||||||
to build the configuration but nothing more. This is useful to see
|
everything compiles cleanly.
|
||||||
whether everything compiles cleanly.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>If you have a machine that supports hardware virtualisation, you
|
If you have a machine that supports hardware virtualisation, you can also
|
||||||
can also test the new configuration in a sandbox by building and
|
test the new configuration in a sandbox by building and running a QEMU
|
||||||
running a QEMU <emphasis>virtual machine</emphasis> that contains the
|
<emphasis>virtual machine</emphasis> that contains the desired configuration.
|
||||||
desired configuration. Just do
|
Just do
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-rebuild build-vm
|
$ nixos-rebuild build-vm
|
||||||
$ ./result/bin/run-*-vm
|
$ ./result/bin/run-*-vm
|
||||||
</screen>
|
</screen>
|
||||||
|
The VM does not have any data from your host system, so your existing user
|
||||||
The VM does not have any data from your host system, so your existing
|
accounts and home directories will not be available unless you have set
|
||||||
user accounts and home directories will not be available unless you
|
<literal>mutableUsers = false</literal>. Another way is to temporarily add
|
||||||
have set <literal>mutableUsers = false</literal>. Another way is to
|
the following to your configuration:
|
||||||
temporarily add the following to your configuration:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
<link linkend="opt-users.users._name__.initialHashedPassword">users.extraUsers.your-user.initialHashedPassword</link> = "test";
|
<link linkend="opt-users.users._name__.initialHashedPassword">users.extraUsers.your-user.initialHashedPassword</link> = "test";
|
||||||
</screen>
|
</screen>
|
||||||
|
<emphasis>Important:</emphasis> delete the $hostname.qcow2 file if you have
|
||||||
<emphasis>Important:</emphasis> delete the $hostname.qcow2 file if you
|
started the virtual machine at least once without the right users, otherwise
|
||||||
have started the virtual machine at least once without the right
|
the changes will not get picked up. You can forward ports on the host to the
|
||||||
users, otherwise the changes will not get picked up.
|
guest. For instance, the following will forward host port 2222 to guest port
|
||||||
|
22 (SSH):
|
||||||
You can forward ports on the host to the guest. For
|
|
||||||
instance, the following will forward host port 2222 to guest port 22
|
|
||||||
(SSH):
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ QEMU_NET_OPTS="hostfwd=tcp::2222-:22" ./result/bin/run-*-vm
|
$ QEMU_NET_OPTS="hostfwd=tcp::2222-:22" ./result/bin/run-*-vm
|
||||||
</screen>
|
</screen>
|
||||||
|
allowing you to log in via SSH (assuming you have set the appropriate
|
||||||
allowing you to log in via SSH (assuming you have set the appropriate
|
passwords or SSH authorized keys):
|
||||||
passwords or SSH authorized keys):
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ ssh -p 2222 localhost
|
$ ssh -p 2222 localhost
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,19 +3,15 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-installation">
|
xml:id="ch-installation">
|
||||||
|
<title>Installation</title>
|
||||||
<title>Installation</title>
|
<partintro>
|
||||||
|
<para>
|
||||||
<partintro>
|
This section describes how to obtain, install, and configure NixOS for
|
||||||
|
first-time use.
|
||||||
<para>This section describes how to obtain, install, and configure
|
</para>
|
||||||
NixOS for first-time use.</para>
|
</partintro>
|
||||||
|
<xi:include href="obtaining.xml" />
|
||||||
</partintro>
|
<xi:include href="installing.xml" />
|
||||||
|
<xi:include href="changing-config.xml" />
|
||||||
<xi:include href="obtaining.xml" />
|
<xi:include href="upgrading.xml" />
|
||||||
<xi:include href="installing.xml" />
|
|
||||||
<xi:include href="changing-config.xml" />
|
|
||||||
<xi:include href="upgrading.xml" />
|
|
||||||
|
|
||||||
</part>
|
</part>
|
||||||
|
@ -5,284 +5,325 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-installing-from-other-distro">
|
xml:id="sec-installing-from-other-distro">
|
||||||
|
<title>Installing from another Linux distribution</title>
|
||||||
|
|
||||||
<title>Installing from another Linux distribution</title>
|
<para>
|
||||||
|
Because Nix (the package manager) & Nixpkgs (the Nix packages collection)
|
||||||
|
can both be installed on any (most?) Linux distributions, they can be used to
|
||||||
|
install NixOS in various creative ways. You can, for instance:
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<orderedlist>
|
||||||
Because Nix (the package manager) & Nixpkgs (the Nix packages
|
<listitem>
|
||||||
collection) can both be installed on any (most?) Linux distributions,
|
<para>
|
||||||
they can be used to install NixOS in various creative ways. You can,
|
Install NixOS on another partition, from your existing Linux distribution
|
||||||
for instance:
|
(without the use of a USB or optical device!)
|
||||||
</para>
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Install NixOS on the same partition (in place!), from your existing
|
||||||
|
non-NixOS Linux distribution using <literal>NIXOS_LUSTRATE</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Install NixOS on your hard drive from the Live CD of any Linux
|
||||||
|
distribution.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
|
||||||
<orderedlist>
|
<para>
|
||||||
<listitem><para>Install NixOS on another partition, from your existing
|
The first steps to all these are the same:
|
||||||
Linux distribution (without the use of a USB or optical
|
</para>
|
||||||
device!)</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>Install NixOS on the same partition (in place!), from
|
<orderedlist>
|
||||||
your existing non-NixOS Linux distribution using
|
<listitem>
|
||||||
<literal>NIXOS_LUSTRATE</literal>.</para></listitem>
|
<para>
|
||||||
|
Install the Nix package manager:
|
||||||
<listitem><para>Install NixOS on your hard drive from the Live CD of
|
</para>
|
||||||
any Linux distribution.</para></listitem>
|
<para>
|
||||||
</orderedlist>
|
Short version:
|
||||||
|
</para>
|
||||||
<para>The first steps to all these are the same:</para>
|
<screen>
|
||||||
|
|
||||||
<orderedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>Install the Nix package manager:</para>
|
|
||||||
|
|
||||||
<para>Short version:</para>
|
|
||||||
|
|
||||||
<screen>
|
|
||||||
$ bash <(curl https://nixos.org/nix/install)
|
$ bash <(curl https://nixos.org/nix/install)
|
||||||
$ . $HOME/.nix-profile/etc/profile.d/nix.sh # …or open a fresh shell</screen>
|
$ . $HOME/.nix-profile/etc/profile.d/nix.sh # …or open a fresh shell</screen>
|
||||||
|
<para>
|
||||||
<para>More details in the <link
|
More details in the
|
||||||
|
<link
|
||||||
xlink:href="https://nixos.org/nix/manual/#chap-quick-start">
|
xlink:href="https://nixos.org/nix/manual/#chap-quick-start">
|
||||||
Nix manual</link></para>
|
Nix manual</link>
|
||||||
</listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Switch to the NixOS channel:</para>
|
<para>
|
||||||
|
Switch to the NixOS channel:
|
||||||
<para>If you've just installed Nix on a non-NixOS distribution, you
|
</para>
|
||||||
will be on the <literal>nixpkgs</literal> channel by
|
<para>
|
||||||
default.</para>
|
If you've just installed Nix on a non-NixOS distribution, you will be on
|
||||||
|
the <literal>nixpkgs</literal> channel by default.
|
||||||
<screen>
|
</para>
|
||||||
|
<screen>
|
||||||
$ nix-channel --list
|
$ nix-channel --list
|
||||||
nixpkgs https://nixos.org/channels/nixpkgs-unstable</screen>
|
nixpkgs https://nixos.org/channels/nixpkgs-unstable</screen>
|
||||||
|
<para>
|
||||||
<para>As that channel gets released without running the NixOS
|
As that channel gets released without running the NixOS tests, it will be
|
||||||
tests, it will be safer to use the <literal>nixos-*</literal>
|
safer to use the <literal>nixos-*</literal> channels instead:
|
||||||
channels instead:</para>
|
</para>
|
||||||
|
<screen>
|
||||||
<screen>
|
|
||||||
$ nix-channel --add https://nixos.org/channels/nixos-<replaceable>version</replaceable> nixpkgs</screen>
|
$ nix-channel --add https://nixos.org/channels/nixos-<replaceable>version</replaceable> nixpkgs</screen>
|
||||||
|
<para>
|
||||||
<para>You may want to throw in a <literal>nix-channel
|
You may want to throw in a <literal>nix-channel --update</literal> for good
|
||||||
--update</literal> for good measure.</para>
|
measure.
|
||||||
</listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Install the NixOS installation tools:</para>
|
<para>
|
||||||
|
Install the NixOS installation tools:
|
||||||
<para>You'll need <literal>nixos-generate-config</literal> and
|
</para>
|
||||||
<literal>nixos-install</literal> and we'll throw in some man
|
<para>
|
||||||
pages and <literal>nixos-enter</literal> just in case you want
|
You'll need <literal>nixos-generate-config</literal> and
|
||||||
to chroot into your NixOS partition. They are installed by
|
<literal>nixos-install</literal> and we'll throw in some man pages and
|
||||||
default on NixOS, but you don't have NixOS yet..</para>
|
<literal>nixos-enter</literal> just in case you want to chroot into your
|
||||||
|
NixOS partition. They are installed by default on NixOS, but you don't have
|
||||||
<screen>$ nix-env -iE "_: with import <nixpkgs/nixos> { configuration = {}; }; with config.system.build; [ nixos-generate-config nixos-install nixos-enter manual.manpages ]"</screen>
|
NixOS yet..
|
||||||
</listitem>
|
</para>
|
||||||
|
<screen>$ nix-env -iE "_: with import <nixpkgs/nixos> { configuration = {}; }; with config.system.build; [ nixos-generate-config nixos-install nixos-enter manual.manpages ]"</screen>
|
||||||
<listitem>
|
</listitem>
|
||||||
<note><para>The following 5 steps are only for installing NixOS to
|
<listitem>
|
||||||
another partition. For installing NixOS in place using
|
<note>
|
||||||
<literal>NIXOS_LUSTRATE</literal>, skip ahead.</para></note>
|
<para>
|
||||||
|
The following 5 steps are only for installing NixOS to another partition.
|
||||||
<para>Prepare your target partition:</para>
|
For installing NixOS in place using <literal>NIXOS_LUSTRATE</literal>,
|
||||||
|
skip ahead.
|
||||||
<para>At this point it is time to prepare your target partition.
|
</para>
|
||||||
Please refer to the partitioning, file-system creation, and
|
</note>
|
||||||
mounting steps of <xref linkend="sec-installation" /></para>
|
<para>
|
||||||
|
Prepare your target partition:
|
||||||
<para>If you're about to install NixOS in place using
|
</para>
|
||||||
<literal>NIXOS_LUSTRATE</literal> there is nothing to do for
|
<para>
|
||||||
this step.</para>
|
At this point it is time to prepare your target partition. Please refer to
|
||||||
</listitem>
|
the partitioning, file-system creation, and mounting steps of
|
||||||
|
<xref linkend="sec-installation" />
|
||||||
<listitem>
|
</para>
|
||||||
<para>Generate your NixOS configuration:</para>
|
<para>
|
||||||
|
If you're about to install NixOS in place using
|
||||||
<screen>$ sudo `which nixos-generate-config` --root /mnt</screen>
|
<literal>NIXOS_LUSTRATE</literal> there is nothing to do for this step.
|
||||||
|
</para>
|
||||||
<para>You'll probably want to edit the configuration files. Refer
|
</listitem>
|
||||||
to the <literal>nixos-generate-config</literal> step in <xref
|
<listitem>
|
||||||
linkend="sec-installation" /> for more information.</para>
|
<para>
|
||||||
|
Generate your NixOS configuration:
|
||||||
<para>Consider setting up the NixOS bootloader to give you the
|
</para>
|
||||||
ability to boot on your existing Linux partition. For instance,
|
<screen>$ sudo `which nixos-generate-config` --root /mnt</screen>
|
||||||
if you're using GRUB and your existing distribution is running
|
<para>
|
||||||
Ubuntu, you may want to add something like this to your
|
You'll probably want to edit the configuration files. Refer to the
|
||||||
<literal>configuration.nix</literal>:</para>
|
<literal>nixos-generate-config</literal> step in
|
||||||
|
<xref
|
||||||
<programlisting>
|
linkend="sec-installation" /> for more
|
||||||
|
information.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Consider setting up the NixOS bootloader to give you the ability to boot on
|
||||||
|
your existing Linux partition. For instance, if you're using GRUB and your
|
||||||
|
existing distribution is running Ubuntu, you may want to add something like
|
||||||
|
this to your <literal>configuration.nix</literal>:
|
||||||
|
</para>
|
||||||
|
<programlisting>
|
||||||
<xref linkend="opt-boot.loader.grub.extraEntries"/> = ''
|
<xref linkend="opt-boot.loader.grub.extraEntries"/> = ''
|
||||||
menuentry "Ubuntu" {
|
menuentry "Ubuntu" {
|
||||||
search --set=ubuntu --fs-uuid 3cc3e652-0c1f-4800-8451-033754f68e6e
|
search --set=ubuntu --fs-uuid 3cc3e652-0c1f-4800-8451-033754f68e6e
|
||||||
configfile "($ubuntu)/boot/grub/grub.cfg"
|
configfile "($ubuntu)/boot/grub/grub.cfg"
|
||||||
}
|
}
|
||||||
'';</programlisting>
|
'';</programlisting>
|
||||||
|
<para>
|
||||||
<para>(You can find the appropriate UUID for your partition in
|
(You can find the appropriate UUID for your partition in
|
||||||
<literal>/dev/disk/by-uuid</literal>)</para>
|
<literal>/dev/disk/by-uuid</literal>)
|
||||||
</listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Create the <literal>nixbld</literal> group and user on your
|
<para>
|
||||||
original distribution:</para>
|
Create the <literal>nixbld</literal> group and user on your original
|
||||||
|
distribution:
|
||||||
<screen>
|
</para>
|
||||||
|
<screen>
|
||||||
$ sudo groupadd -g 30000 nixbld
|
$ sudo groupadd -g 30000 nixbld
|
||||||
$ sudo useradd -u 30000 -g nixbld -G nixbld nixbld</screen>
|
$ sudo useradd -u 30000 -g nixbld -G nixbld nixbld</screen>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Download/build/install NixOS:</para>
|
Download/build/install NixOS:
|
||||||
|
</para>
|
||||||
<warning><para>Once you complete this step, you might no longer be
|
<warning>
|
||||||
able to boot on existing systems without the help of a
|
<para>
|
||||||
rescue USB drive or similar.</para></warning>
|
Once you complete this step, you might no longer be able to boot on
|
||||||
|
existing systems without the help of a rescue USB drive or similar.
|
||||||
<screen>$ sudo PATH="$PATH" NIX_PATH="$NIX_PATH" `which nixos-install` --root /mnt</screen>
|
</para>
|
||||||
|
</warning>
|
||||||
<para>Again, please refer to the <literal>nixos-install</literal>
|
<screen>$ sudo PATH="$PATH" NIX_PATH="$NIX_PATH" `which nixos-install` --root /mnt</screen>
|
||||||
step in <xref linkend="sec-installation" /> for more
|
<para>
|
||||||
information.</para>
|
Again, please refer to the <literal>nixos-install</literal> step in
|
||||||
|
<xref linkend="sec-installation" /> for more information.
|
||||||
<para>That should be it for installation to another partition!</para>
|
</para>
|
||||||
</listitem>
|
<para>
|
||||||
|
That should be it for installation to another partition!
|
||||||
<listitem>
|
</para>
|
||||||
<para>Optionally, you may want to clean up your non-NixOS distribution:</para>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<screen>
|
<para>
|
||||||
|
Optionally, you may want to clean up your non-NixOS distribution:
|
||||||
|
</para>
|
||||||
|
<screen>
|
||||||
$ sudo userdel nixbld
|
$ sudo userdel nixbld
|
||||||
$ sudo groupdel nixbld</screen>
|
$ sudo groupdel nixbld</screen>
|
||||||
|
<para>
|
||||||
<para>If you do not wish to keep the Nix package manager
|
If you do not wish to keep the Nix package manager installed either, run
|
||||||
installed either, run something like <literal>sudo rm -rv
|
something like <literal>sudo rm -rv ~/.nix-* /nix</literal> and remove the
|
||||||
~/.nix-* /nix</literal> and remove the line that the Nix
|
line that the Nix installer added to your <literal>~/.profile</literal>.
|
||||||
installer added to your <literal>~/.profile</literal>.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<note>
|
||||||
<note><para>The following steps are only for installing NixOS in
|
<para>
|
||||||
place using
|
The following steps are only for installing NixOS in place using
|
||||||
<literal>NIXOS_LUSTRATE</literal>:</para></note>
|
<literal>NIXOS_LUSTRATE</literal>:
|
||||||
|
</para>
|
||||||
<para>Generate your NixOS configuration:</para>
|
</note>
|
||||||
|
<para>
|
||||||
<screen>$ sudo `which nixos-generate-config` --root /</screen>
|
Generate your NixOS configuration:
|
||||||
|
</para>
|
||||||
<para>Note that this will place the generated configuration files
|
<screen>$ sudo `which nixos-generate-config` --root /</screen>
|
||||||
in <literal>/etc/nixos</literal>. You'll probably want to edit
|
<para>
|
||||||
the configuration files. Refer to the
|
Note that this will place the generated configuration files in
|
||||||
<literal>nixos-generate-config</literal> step in <xref
|
<literal>/etc/nixos</literal>. You'll probably want to edit the
|
||||||
linkend="sec-installation" /> for more information.</para>
|
configuration files. Refer to the <literal>nixos-generate-config</literal>
|
||||||
|
step in <xref
|
||||||
<para>You'll likely want to set a root password for your first boot
|
linkend="sec-installation" /> for more
|
||||||
using the configuration files because you won't have a chance
|
information.
|
||||||
to enter a password until after you reboot. You can initalize
|
</para>
|
||||||
the root password to an empty one with this line: (and of course
|
<para>
|
||||||
don't forget to set one once you've rebooted or to lock the
|
You'll likely want to set a root password for your first boot using the
|
||||||
account with <literal>sudo passwd -l root</literal> if you use
|
configuration files because you won't have a chance to enter a password
|
||||||
<literal>sudo</literal>)</para>
|
until after you reboot. You can initalize the root password to an empty one
|
||||||
|
with this line: (and of course don't forget to set one once you've rebooted
|
||||||
<programlisting>
|
or to lock the account with <literal>sudo passwd -l root</literal> if you
|
||||||
|
use <literal>sudo</literal>)
|
||||||
|
</para>
|
||||||
|
<programlisting>
|
||||||
<link linkend="opt-users.users._name__.initialHashedPassword">users.extraUsers.root.initialHashedPassword</link> = "";
|
<link linkend="opt-users.users._name__.initialHashedPassword">users.extraUsers.root.initialHashedPassword</link> = "";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Build the NixOS closure and install it in the
|
Build the NixOS closure and install it in the <literal>system</literal>
|
||||||
<literal>system</literal> profile:</para>
|
profile:
|
||||||
|
</para>
|
||||||
<screen>$ nix-env -p /nix/var/nix/profiles/system -f '<nixpkgs/nixos>' -I nixos-config=/etc/nixos/configuration.nix -iA system</screen>
|
<screen>$ nix-env -p /nix/var/nix/profiles/system -f '<nixpkgs/nixos>' -I nixos-config=/etc/nixos/configuration.nix -iA system</screen>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Change ownership of the <literal>/nix</literal> tree to root
|
Change ownership of the <literal>/nix</literal> tree to root (since your
|
||||||
(since your Nix install was probably single user):</para>
|
Nix install was probably single user):
|
||||||
|
</para>
|
||||||
<screen>$ sudo chown -R 0.0 /nix</screen>
|
<screen>$ sudo chown -R 0.0 /nix</screen>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Set up the <literal>/etc/NIXOS</literal> and
|
Set up the <literal>/etc/NIXOS</literal> and
|
||||||
<literal>/etc/NIXOS_LUSTRATE</literal> files:</para>
|
<literal>/etc/NIXOS_LUSTRATE</literal> files:
|
||||||
|
</para>
|
||||||
<para><literal>/etc/NIXOS</literal> officializes that this is now a
|
<para>
|
||||||
NixOS partition (the bootup scripts require its presence).</para>
|
<literal>/etc/NIXOS</literal> officializes that this is now a NixOS
|
||||||
|
partition (the bootup scripts require its presence).
|
||||||
<para><literal>/etc/NIXOS_LUSTRATE</literal> tells the NixOS bootup
|
</para>
|
||||||
scripts to move <emphasis>everything</emphasis> that's in the
|
<para>
|
||||||
root partition to <literal>/old-root</literal>. This will move
|
<literal>/etc/NIXOS_LUSTRATE</literal> tells the NixOS bootup scripts to
|
||||||
your existing distribution out of the way in the very early
|
move <emphasis>everything</emphasis> that's in the root partition to
|
||||||
stages of the NixOS bootup. There are exceptions (we do need to
|
<literal>/old-root</literal>. This will move your existing distribution out
|
||||||
keep NixOS there after all), so the NixOS lustrate process will
|
of the way in the very early stages of the NixOS bootup. There are
|
||||||
not touch:</para>
|
exceptions (we do need to keep NixOS there after all), so the NixOS
|
||||||
|
lustrate process will not touch:
|
||||||
<itemizedlist>
|
</para>
|
||||||
<listitem><para>The <literal>/nix</literal>
|
<itemizedlist>
|
||||||
directory</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>The <literal>/boot</literal>
|
The <literal>/nix</literal> directory
|
||||||
directory</para></listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem><para>Any file or directory listed in
|
<listitem>
|
||||||
<literal>/etc/NIXOS_LUSTRATE</literal> (one per
|
<para>
|
||||||
line)</para></listitem>
|
The <literal>/boot</literal> directory
|
||||||
</itemizedlist>
|
</para>
|
||||||
|
</listitem>
|
||||||
<note><para>Support for <literal>NIXOS_LUSTRATE</literal> was added
|
<listitem>
|
||||||
in NixOS 16.09. The act of "lustrating" refers to the
|
<para>
|
||||||
wiping of the existing distribution. Creating
|
Any file or directory listed in <literal>/etc/NIXOS_LUSTRATE</literal>
|
||||||
<literal>/etc/NIXOS_LUSTRATE</literal> can also be used on
|
(one per line)
|
||||||
NixOS to remove all mutable files from your root partition
|
</para>
|
||||||
(anything that's not in <literal>/nix</literal> or
|
</listitem>
|
||||||
<literal>/boot</literal> gets "lustrated" on the next
|
</itemizedlist>
|
||||||
boot.</para>
|
<note>
|
||||||
<para>lustrate /ˈlʌstreɪt/ verb.</para>
|
<para>
|
||||||
<para>purify by expiatory sacrifice, ceremonial washing, or
|
Support for <literal>NIXOS_LUSTRATE</literal> was added in NixOS 16.09.
|
||||||
some other ritual action.</para></note>
|
The act of "lustrating" refers to the wiping of the existing distribution.
|
||||||
|
Creating <literal>/etc/NIXOS_LUSTRATE</literal> can also be used on NixOS
|
||||||
<para>Let's create the files:</para>
|
to remove all mutable files from your root partition (anything that's not
|
||||||
|
in <literal>/nix</literal> or <literal>/boot</literal> gets "lustrated" on
|
||||||
<screen>
|
the next boot.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
lustrate /ˈlʌstreɪt/ verb.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
purify by expiatory sacrifice, ceremonial washing, or some other ritual
|
||||||
|
action.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
<para>
|
||||||
|
Let's create the files:
|
||||||
|
</para>
|
||||||
|
<screen>
|
||||||
$ sudo touch /etc/NIXOS
|
$ sudo touch /etc/NIXOS
|
||||||
$ sudo touch /etc/NIXOS_LUSTRATE
|
$ sudo touch /etc/NIXOS_LUSTRATE
|
||||||
</screen>
|
</screen>
|
||||||
|
<para>
|
||||||
<para>Let's also make sure the NixOS configuration files are kept
|
Let's also make sure the NixOS configuration files are kept once we reboot
|
||||||
once we reboot on NixOS:</para>
|
on NixOS:
|
||||||
|
</para>
|
||||||
<screen>
|
<screen>
|
||||||
$ echo etc/nixos | sudo tee -a /etc/NIXOS_LUSTRATE
|
$ echo etc/nixos | sudo tee -a /etc/NIXOS_LUSTRATE
|
||||||
</screen>
|
</screen>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Finally, move the <literal>/boot</literal> directory of your
|
Finally, move the <literal>/boot</literal> directory of your current
|
||||||
current distribution out of the way (the lustrate process will
|
distribution out of the way (the lustrate process will take care of the
|
||||||
take care of the rest once you reboot, but this one must be
|
rest once you reboot, but this one must be moved out now because NixOS
|
||||||
moved out now because NixOS needs to install its own boot
|
needs to install its own boot files:
|
||||||
files:</para>
|
</para>
|
||||||
|
<warning>
|
||||||
<warning><para>Once you complete this step, your current
|
<para>
|
||||||
distribution will no longer be bootable! If you didn't get
|
Once you complete this step, your current distribution will no longer be
|
||||||
all the NixOS configuration right, especially those
|
bootable! If you didn't get all the NixOS configuration right, especially
|
||||||
settings pertaining to boot loading and root partition,
|
those settings pertaining to boot loading and root partition, NixOS may
|
||||||
NixOS may not be bootable either. Have a USB rescue device
|
not be bootable either. Have a USB rescue device ready in case this
|
||||||
ready in case this happens. </para></warning>
|
happens.
|
||||||
|
</para>
|
||||||
<screen>
|
</warning>
|
||||||
|
<screen>
|
||||||
$ sudo mv -v /boot /boot.bak &&
|
$ sudo mv -v /boot /boot.bak &&
|
||||||
sudo /nix/var/nix/profiles/system/bin/switch-to-configuration boot</screen>
|
sudo /nix/var/nix/profiles/system/bin/switch-to-configuration boot</screen>
|
||||||
|
<para>
|
||||||
<para>Cross your fingers, reboot, hopefully you should get a NixOS
|
Cross your fingers, reboot, hopefully you should get a NixOS prompt!
|
||||||
prompt!</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>If for some reason you want to revert to the old
|
<para>
|
||||||
distribution, you'll need to boot on a USB rescue disk and do
|
If for some reason you want to revert to the old distribution, you'll need
|
||||||
something along these lines:</para>
|
to boot on a USB rescue disk and do something along these lines:
|
||||||
|
</para>
|
||||||
<screen>
|
<screen>
|
||||||
# mkdir root
|
# mkdir root
|
||||||
# mount /dev/sdaX root
|
# mount /dev/sdaX root
|
||||||
# mkdir root/nixos-root
|
# mkdir root/nixos-root
|
||||||
@ -291,23 +332,25 @@ $ sudo mv -v /boot /boot.bak &&
|
|||||||
# mv -v root/boot.bak root/boot # We had renamed this by hand earlier
|
# mv -v root/boot.bak root/boot # We had renamed this by hand earlier
|
||||||
# umount root
|
# umount root
|
||||||
# reboot</screen>
|
# reboot</screen>
|
||||||
|
<para>
|
||||||
<para>This may work as is or you might also need to reinstall the
|
This may work as is or you might also need to reinstall the boot loader
|
||||||
boot loader</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>And of course, if you're happy with NixOS and no longer need
|
And of course, if you're happy with NixOS and no longer need the old
|
||||||
the old distribution:</para>
|
distribution:
|
||||||
|
</para>
|
||||||
<screen>sudo rm -rf /old-root</screen>
|
<screen>sudo rm -rf /old-root</screen>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>It's also worth noting that this whole process can be
|
It's also worth noting that this whole process can be automated. This is
|
||||||
automated. This is especially useful for Cloud VMs, where
|
especially useful for Cloud VMs, where provider do not provide NixOS. For
|
||||||
provider do not provide NixOS. For instance, <link
|
instance,
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/elitak/nixos-infect">nixos-infect</link>
|
xlink:href="https://github.com/elitak/nixos-infect">nixos-infect</link>
|
||||||
uses the lustrate process to convert Digital Ocean droplets to
|
uses the lustrate process to convert Digital Ocean droplets to NixOS from
|
||||||
NixOS from other distributions automatically.</para>
|
other distributions automatically.
|
||||||
</listitem>
|
</para>
|
||||||
</orderedlist>
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,46 +3,48 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-booting-from-pxe">
|
xml:id="sec-booting-from-pxe">
|
||||||
|
<title>Booting from the <quote>netboot</quote> media (PXE)</title>
|
||||||
|
|
||||||
<title>Booting from the <quote>netboot</quote> media (PXE)</title>
|
<para>
|
||||||
<para>
|
Advanced users may wish to install NixOS using an existing PXE or iPXE setup.
|
||||||
Advanced users may wish to install NixOS using an existing PXE or
|
</para>
|
||||||
iPXE setup.
|
|
||||||
</para>
|
<para>
|
||||||
<para>
|
|
||||||
These instructions assume that you have an existing PXE or iPXE
|
These instructions assume that you have an existing PXE or iPXE
|
||||||
infrastructure and simply want to add the NixOS installer as another
|
infrastructure and simply want to add the NixOS installer as another option.
|
||||||
option. To build the necessary files from a recent version of
|
To build the necessary files from a recent version of nixpkgs, you can run:
|
||||||
nixpkgs, you can run:
|
</para>
|
||||||
</para>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
nix-build -A netboot nixos/release.nix
|
nix-build -A netboot nixos/release.nix
|
||||||
</programlisting>
|
</programlisting>
|
||||||
<para>
|
|
||||||
This will create a <literal>result</literal> directory containing: *
|
|
||||||
<literal>bzImage</literal> – the Linux kernel *
|
|
||||||
<literal>initrd</literal> – the initrd file *
|
|
||||||
<literal>netboot.ipxe</literal> – an example ipxe script
|
|
||||||
demonstrating the appropriate kernel command line arguments for this
|
|
||||||
image
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
If you’re using plain PXE, configure your boot loader to use the
|
|
||||||
<literal>bzImage</literal> and <literal>initrd</literal> files and
|
|
||||||
have it provide the same kernel command line arguments found in
|
|
||||||
<literal>netboot.ipxe</literal>.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
If you’re using iPXE, depending on how your HTTP/FTP/etc. server is
|
|
||||||
configured you may be able to use <literal>netboot.ipxe</literal>
|
|
||||||
unmodified, or you may need to update the paths to the files to
|
|
||||||
match your server’s directory layout
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
In the future we may begin making these files available as build
|
|
||||||
products from hydra at which point we will update this documentation
|
|
||||||
with instructions on how to obtain them either for placing on a
|
|
||||||
dedicated TFTP server or to boot them directly over the internet.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This will create a <literal>result</literal> directory containing: *
|
||||||
|
<literal>bzImage</literal> – the Linux kernel * <literal>initrd</literal>
|
||||||
|
– the initrd file * <literal>netboot.ipxe</literal> – an example ipxe
|
||||||
|
script demonstrating the appropriate kernel command line arguments for this
|
||||||
|
image
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you’re using plain PXE, configure your boot loader to use the
|
||||||
|
<literal>bzImage</literal> and <literal>initrd</literal> files and have it
|
||||||
|
provide the same kernel command line arguments found in
|
||||||
|
<literal>netboot.ipxe</literal>.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If you’re using iPXE, depending on how your HTTP/FTP/etc. server is
|
||||||
|
configured you may be able to use <literal>netboot.ipxe</literal> unmodified,
|
||||||
|
or you may need to update the paths to the files to match your server’s
|
||||||
|
directory layout
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
In the future we may begin making these files available as build products
|
||||||
|
from hydra at which point we will update this documentation with instructions
|
||||||
|
on how to obtain them either for placing on a dedicated TFTP server or to
|
||||||
|
boot them directly over the internet.
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,17 +3,19 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-booting-from-usb">
|
xml:id="sec-booting-from-usb">
|
||||||
|
<title>Booting from a USB Drive</title>
|
||||||
|
|
||||||
<title>Booting from a USB Drive</title>
|
<para>
|
||||||
|
For systems without CD drive, the NixOS live CD can be booted from a USB
|
||||||
|
stick. You can use the <command>dd</command> utility to write the image:
|
||||||
|
<command>dd if=<replaceable>path-to-image</replaceable>
|
||||||
|
of=<replaceable>/dev/sdb</replaceable></command>. Be careful about specifying
|
||||||
|
the correct drive; you can use the <command>lsblk</command> command to get a
|
||||||
|
list of block devices.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>For systems without CD drive, the NixOS live CD can be booted from
|
<para>
|
||||||
a USB stick. You can use the <command>dd</command> utility to write the image:
|
On macOS:
|
||||||
<command>dd if=<replaceable>path-to-image</replaceable>
|
|
||||||
of=<replaceable>/dev/sdb</replaceable></command>. Be careful about specifying the
|
|
||||||
correct drive; you can use the <command>lsblk</command> command to get a list of
|
|
||||||
block devices.</para>
|
|
||||||
|
|
||||||
<para>On macOS:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
$ diskutil list
|
$ diskutil list
|
||||||
[..]
|
[..]
|
||||||
@ -24,36 +26,43 @@ $ diskutil unmountDisk diskN
|
|||||||
Unmount of all volumes on diskN was successful
|
Unmount of all volumes on diskN was successful
|
||||||
$ sudo dd bs=1m if=nix.iso of=/dev/rdiskN
|
$ sudo dd bs=1m if=nix.iso of=/dev/rdiskN
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Using the 'raw' <command>rdiskN</command> device instead of <command>diskN</command>
|
Using the 'raw' <command>rdiskN</command> device instead of
|
||||||
completes in minutes instead of hours. After <command>dd</command> completes, a GUI
|
<command>diskN</command> completes in minutes instead of hours. After
|
||||||
dialog "The disk you inserted was not readable by this computer" will pop up, which
|
<command>dd</command> completes, a GUI dialog "The disk you inserted was not
|
||||||
can be ignored.</para>
|
readable by this computer" will pop up, which can be ignored.
|
||||||
|
</para>
|
||||||
<para>The <command>dd</command> utility will write the image verbatim to the drive,
|
|
||||||
making it the recommended option for both UEFI and non-UEFI installations. For
|
|
||||||
non-UEFI installations, you can alternatively use
|
|
||||||
<link xlink:href="http://unetbootin.sourceforge.net/">unetbootin</link>. If you
|
|
||||||
cannot use <command>dd</command> for a UEFI installation, you can also mount the
|
|
||||||
ISO, copy its contents verbatim to your drive, then either:
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>Change the label of the disk partition to the label of the ISO
|
|
||||||
(visible with the blkid command), or</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>Edit <filename>loader/entries/nixos-livecd.conf</filename> on the drive
|
|
||||||
and change the <literal>root=</literal> field in the <literal>options</literal>
|
|
||||||
line to point to your drive (see the documentation on <literal>root=</literal>
|
|
||||||
in <link xlink:href="https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt">
|
|
||||||
the kernel documentation</link> for more details).</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>If you want to load the contents of the ISO to ram after bootin
|
|
||||||
(So you can remove the stick after bootup) you can append the parameter
|
|
||||||
<literal>copytoram</literal> to the <literal>options</literal> field.</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The <command>dd</command> utility will write the image verbatim to the drive,
|
||||||
|
making it the recommended option for both UEFI and non-UEFI installations.
|
||||||
|
For non-UEFI installations, you can alternatively use
|
||||||
|
<link xlink:href="http://unetbootin.sourceforge.net/">unetbootin</link>. If
|
||||||
|
you cannot use <command>dd</command> for a UEFI installation, you can also
|
||||||
|
mount the ISO, copy its contents verbatim to your drive, then either:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Change the label of the disk partition to the label of the ISO (visible
|
||||||
|
with the blkid command), or
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Edit <filename>loader/entries/nixos-livecd.conf</filename> on the drive
|
||||||
|
and change the <literal>root=</literal> field in the
|
||||||
|
<literal>options</literal> line to point to your drive (see the
|
||||||
|
documentation on <literal>root=</literal> in
|
||||||
|
<link xlink:href="https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt">
|
||||||
|
the kernel documentation</link> for more details).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
If you want to load the contents of the ISO to ram after bootin (So you
|
||||||
|
can remove the stick after bootup) you can append the parameter
|
||||||
|
<literal>copytoram</literal> to the <literal>options</literal> field.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,63 +3,82 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-instaling-virtualbox-guest">
|
xml:id="sec-instaling-virtualbox-guest">
|
||||||
|
<title>Installing in a VirtualBox guest</title>
|
||||||
|
|
||||||
<title>Installing in a VirtualBox guest</title>
|
<para>
|
||||||
<para>
|
|
||||||
Installing NixOS into a VirtualBox guest is convenient for users who want to
|
Installing NixOS into a VirtualBox guest is convenient for users who want to
|
||||||
try NixOS without installing it on bare metal. If you want to use a pre-made
|
try NixOS without installing it on bare metal. If you want to use a pre-made
|
||||||
VirtualBox appliance, it is available at <link
|
VirtualBox appliance, it is available at
|
||||||
xlink:href="https://nixos.org/nixos/download.html">the downloads page</link>.
|
<link
|
||||||
If you want to set up a VirtualBox guest manually, follow these instructions:
|
xlink:href="https://nixos.org/nixos/download.html">the downloads
|
||||||
</para>
|
page</link>. If you want to set up a VirtualBox guest manually, follow these
|
||||||
|
instructions:
|
||||||
|
</para>
|
||||||
|
|
||||||
<orderedlist>
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Add a New Machine in VirtualBox with OS Type "Linux / Other Linux"
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Base Memory Size: 768 MB or higher.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
New Hard Disk of 8 GB or higher.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Mount the CD-ROM with the NixOS ISO (by clicking on CD/DVD-ROM)
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Click on Settings / System / Processor and enable PAE/NX
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Click on Settings / System / Acceleration and enable "VT-x/AMD-V"
|
||||||
|
acceleration
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Save the settings, start the virtual machine, and continue installation
|
||||||
|
like normal
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
|
||||||
<listitem><para>Add a New Machine in VirtualBox with OS Type "Linux / Other
|
<para>
|
||||||
Linux"</para></listitem>
|
There are a few modifications you should make in configuration.nix. Enable
|
||||||
|
booting:
|
||||||
<listitem><para>Base Memory Size: 768 MB or higher.</para></listitem>
|
</para>
|
||||||
|
|
||||||
<listitem><para>New Hard Disk of 8 GB or higher.</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>Mount the CD-ROM with the NixOS ISO (by clicking on
|
|
||||||
CD/DVD-ROM)</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>Click on Settings / System / Processor and enable
|
|
||||||
PAE/NX</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>Click on Settings / System / Acceleration and enable
|
|
||||||
"VT-x/AMD-V" acceleration</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>Save the settings, start the virtual machine, and continue
|
|
||||||
installation like normal</para></listitem>
|
|
||||||
|
|
||||||
</orderedlist>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
There are a few modifications you should make in configuration.nix.
|
|
||||||
Enable booting:
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.loader.grub.device"/> = "/dev/sda";
|
<xref linkend="opt-boot.loader.grub.device"/> = "/dev/sda";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Also remove the fsck that runs at startup. It will always fail to run,
|
Also remove the fsck that runs at startup. It will always fail to run,
|
||||||
stopping your boot until you press <literal>*</literal>.
|
stopping your boot until you press <literal>*</literal>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-boot.initrd.checkJournalingFS"/> = false;
|
<xref linkend="opt-boot.initrd.checkJournalingFS"/> = false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Shared folders can be given a name and a path in the host system in the
|
Shared folders can be given a name and a path in the host system in the
|
||||||
VirtualBox settings (Machine / Settings / Shared Folders, then click on the
|
VirtualBox settings (Machine / Settings / Shared Folders, then click on the
|
||||||
"Add" icon). Add the following to the
|
"Add" icon). Add the following to the
|
||||||
<literal>/etc/nixos/configuration.nix</literal> to auto-mount them:
|
<literal>/etc/nixos/configuration.nix</literal> to auto-mount them:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
{ config, pkgs, ...} :
|
{ config, pkgs, ...} :
|
||||||
@ -74,8 +93,7 @@
|
|||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The folder will be available directly under the root directory.
|
The folder will be available directly under the root directory.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,66 +3,92 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-installation">
|
xml:id="sec-installation">
|
||||||
|
<title>Installing NixOS</title>
|
||||||
<title>Installing NixOS</title>
|
<para>
|
||||||
|
NixOS can be installed on BIOS or UEFI systems. The procedure for a UEFI
|
||||||
<para>NixOS can be installed on BIOS or UEFI systems. The procedure
|
installation is by and large the same as a BIOS installation. The differences
|
||||||
for a UEFI installation is by and large the same as a BIOS installation. The differences are mentioned in the steps that follow.</para>
|
are mentioned in the steps that follow.
|
||||||
|
</para>
|
||||||
<orderedlist>
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
<listitem><para>Boot from the CD.</para>
|
<para>
|
||||||
<variablelist>
|
Boot from the CD.
|
||||||
<varlistentry><term>UEFI systems</term>
|
</para>
|
||||||
<listitem><para>You should boot the live CD in UEFI mode
|
<variablelist>
|
||||||
(consult your specific hardware's documentation for instructions).
|
<varlistentry>
|
||||||
You may find the <link xlink:href="http://www.rodsbooks.com/refind">rEFInd boot
|
<term>UEFI systems</term>
|
||||||
manager</link> useful.</para></listitem></varlistentry></variablelist></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>The CD contains a basic NixOS installation. (It
|
You should boot the live CD in UEFI mode (consult your specific
|
||||||
also contains Memtest86+, useful if you want to test new hardware).
|
hardware's documentation for instructions). You may find the
|
||||||
When it’s finished booting, it should have detected most of your
|
<link xlink:href="http://www.rodsbooks.com/refind">rEFInd boot
|
||||||
hardware.</para></listitem>
|
manager</link> useful.
|
||||||
|
</para>
|
||||||
<listitem><para>The NixOS manual is available on virtual console 8
|
</listitem>
|
||||||
(press Alt+F8 to access) or by running <command>nixos-help</command>.
|
</varlistentry>
|
||||||
</para></listitem>
|
</variablelist>
|
||||||
|
</listitem>
|
||||||
<listitem><para>You get logged in as <literal>root</literal>
|
<listitem>
|
||||||
(with empty password).</para></listitem>
|
<para>
|
||||||
|
The CD contains a basic NixOS installation. (It also contains Memtest86+,
|
||||||
<listitem><para>If you downloaded the graphical ISO image, you can
|
useful if you want to test new hardware). When it’s finished booting, it
|
||||||
run <command>systemctl start display-manager</command> to start KDE. If you
|
should have detected most of your hardware.
|
||||||
want to continue on the terminal, you can use
|
</para>
|
||||||
<command>loadkeys</command> to switch to your preferred keyboard layout.
|
</listitem>
|
||||||
(We even provide neo2 via <command>loadkeys de neo</command>!)</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>The boot process should have brought up networking (check
|
The NixOS manual is available on virtual console 8 (press Alt+F8 to access)
|
||||||
<command>ip a</command>). Networking is necessary for the
|
or by running <command>nixos-help</command>.
|
||||||
installer, since it will download lots of stuff (such as source
|
</para>
|
||||||
tarballs or Nixpkgs channel binaries). It’s best if you have a DHCP
|
</listitem>
|
||||||
server on your network. Otherwise configure networking manually
|
<listitem>
|
||||||
using <command>ifconfig</command>.</para>
|
<para>
|
||||||
<para>To manually configure the network on the graphical installer,
|
You get logged in as <literal>root</literal> (with empty password).
|
||||||
first disable network-manager with
|
</para>
|
||||||
<command>systemctl stop network-manager</command>.</para>
|
</listitem>
|
||||||
<para>To manually configure the wifi on the minimal installer, run
|
<listitem>
|
||||||
<command>wpa_supplicant -B -i interface -c <(wpa_passphrase 'SSID' 'key')</command>.</para></listitem>
|
<para>
|
||||||
|
If you downloaded the graphical ISO image, you can run <command>systemctl
|
||||||
|
start display-manager</command> to start KDE. If you want to continue on
|
||||||
<listitem><para>If you would like to continue the installation from a different
|
the terminal, you can use <command>loadkeys</command> to switch to your
|
||||||
machine you need to activate the SSH daemon via <literal>systemctl start sshd</literal>.
|
preferred keyboard layout. (We even provide neo2 via <command>loadkeys de
|
||||||
In order to be able to login you also need to set a password for
|
neo</command>!)
|
||||||
<literal>root</literal> using <literal>passwd</literal>.</para></listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem><para>The NixOS installer doesn’t do any partitioning or
|
<listitem>
|
||||||
formatting yet, so you need to do that yourself. Use the following
|
<para>
|
||||||
commands:
|
The boot process should have brought up networking (check <command>ip
|
||||||
|
a</command>). Networking is necessary for the installer, since it will
|
||||||
<itemizedlist>
|
download lots of stuff (such as source tarballs or Nixpkgs channel
|
||||||
|
binaries). It’s best if you have a DHCP server on your network. Otherwise
|
||||||
<listitem><para>For partitioning:
|
configure networking manually using <command>ifconfig</command>.
|
||||||
<command>fdisk</command>.
|
</para>
|
||||||
|
<para>
|
||||||
|
To manually configure the network on the graphical installer, first disable
|
||||||
|
network-manager with <command>systemctl stop network-manager</command>.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
To manually configure the wifi on the minimal installer, run
|
||||||
|
<command>wpa_supplicant -B -i interface -c <(wpa_passphrase 'SSID'
|
||||||
|
'key')</command>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
If you would like to continue the installation from a different machine you
|
||||||
|
need to activate the SSH daemon via <literal>systemctl start
|
||||||
|
sshd</literal>. In order to be able to login you also need to set a
|
||||||
|
password for <literal>root</literal> using <literal>passwd</literal>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The NixOS installer doesn’t do any partitioning or formatting yet, so you
|
||||||
|
need to do that yourself. Use the following commands:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
For partitioning: <command>fdisk</command>.
|
||||||
<screen>
|
<screen>
|
||||||
# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
|
# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
|
||||||
-- for UEFI systems only
|
-- for UEFI systems only
|
||||||
@ -86,257 +112,266 @@ for a UEFI installation is by and large the same as a BIOS installation. The dif
|
|||||||
> x # <lineannotation>(enter expert mode)</lineannotation>
|
> x # <lineannotation>(enter expert mode)</lineannotation>
|
||||||
> f # <lineannotation>(fix up the partition ordering)</lineannotation>
|
> f # <lineannotation>(fix up the partition ordering)</lineannotation>
|
||||||
> r # <lineannotation>(exit expert mode)</lineannotation>
|
> r # <lineannotation>(exit expert mode)</lineannotation>
|
||||||
> w # <lineannotation>(write the partition table to disk and exit)</lineannotation></screen></para></listitem>
|
> w # <lineannotation>(write the partition table to disk and exit)</lineannotation></screen>
|
||||||
|
</para>
|
||||||
<listitem><para>For initialising Ext4 partitions:
|
</listitem>
|
||||||
<command>mkfs.ext4</command>. It is recommended that you assign a
|
<listitem>
|
||||||
unique symbolic label to the file system using the option
|
<para>
|
||||||
<option>-L <replaceable>label</replaceable></option>, since this
|
For initialising Ext4 partitions: <command>mkfs.ext4</command>. It is
|
||||||
makes the file system configuration independent from device
|
recommended that you assign a unique symbolic label to the file system
|
||||||
changes. For example:
|
using the option <option>-L <replaceable>label</replaceable></option>,
|
||||||
|
since this makes the file system configuration independent from device
|
||||||
|
changes. For example:
|
||||||
<screen>
|
<screen>
|
||||||
# mkfs.ext4 -L nixos /dev/sda1</screen>
|
# mkfs.ext4 -L nixos /dev/sda1</screen>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>For creating swap partitions:
|
<para>
|
||||||
<command>mkswap</command>. Again it’s recommended to assign a
|
For creating swap partitions: <command>mkswap</command>. Again it’s
|
||||||
label to the swap partition: <option>-L
|
recommended to assign a label to the swap partition: <option>-L
|
||||||
<replaceable>label</replaceable></option>. For example:
|
<replaceable>label</replaceable></option>. For example:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# mkswap -L swap /dev/sda2</screen>
|
# mkswap -L swap /dev/sda2</screen>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<variablelist>
|
||||||
<variablelist>
|
<varlistentry>
|
||||||
<varlistentry><term>UEFI systems</term>
|
<term>UEFI systems</term>
|
||||||
<listitem><para>For creating boot partitions:
|
<listitem>
|
||||||
<command>mkfs.fat</command>. Again it’s recommended to assign a
|
<para>
|
||||||
label to the boot partition: <option>-n
|
For creating boot partitions: <command>mkfs.fat</command>. Again
|
||||||
<replaceable>label</replaceable></option>. For example:
|
it’s recommended to assign a label to the boot partition:
|
||||||
|
<option>-n <replaceable>label</replaceable></option>. For example:
|
||||||
<screen>
|
<screen>
|
||||||
# mkfs.fat -F 32 -n boot /dev/sda3</screen>
|
# mkfs.fat -F 32 -n boot /dev/sda3</screen>
|
||||||
|
</para>
|
||||||
</para></listitem></varlistentry></variablelist></listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
<listitem><para>For creating LVM volumes, the LVM commands, e.g.,
|
</variablelist>
|
||||||
<command>pvcreate</command>, <command>vgcreate</command>, and
|
</listitem>
|
||||||
<command>lvcreate</command>.</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>For creating software RAID devices, use
|
For creating LVM volumes, the LVM commands, e.g.,
|
||||||
<command>mdadm</command>.</para></listitem>
|
<command>pvcreate</command>, <command>vgcreate</command>, and
|
||||||
|
<command>lvcreate</command>.
|
||||||
</itemizedlist>
|
</para>
|
||||||
|
</listitem>
|
||||||
</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>Mount the target file system on which NixOS should
|
For creating software RAID devices, use <command>mdadm</command>.
|
||||||
be installed on <filename>/mnt</filename>, e.g.
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Mount the target file system on which NixOS should be installed on
|
||||||
|
<filename>/mnt</filename>, e.g.
|
||||||
<screen>
|
<screen>
|
||||||
# mount /dev/disk/by-label/nixos /mnt
|
# mount /dev/disk/by-label/nixos /mnt
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry><term>UEFI systems</term>
|
<varlistentry>
|
||||||
<listitem><para>Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
|
<term>UEFI systems</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
|
||||||
<screen>
|
<screen>
|
||||||
# mkdir -p /mnt/boot
|
# mkdir -p /mnt/boot
|
||||||
# mount /dev/disk/by-label/boot /mnt/boot
|
# mount /dev/disk/by-label/boot /mnt/boot
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para></listitem></varlistentry></variablelist></listitem>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
<listitem><para>If your machine has a limited amount of memory, you
|
</variablelist>
|
||||||
may want to activate swap devices now (<command>swapon
|
</listitem>
|
||||||
<replaceable>device</replaceable></command>). The installer (or
|
<listitem>
|
||||||
rather, the build actions that it may spawn) may need quite a bit of
|
<para>
|
||||||
RAM, depending on your configuration.
|
If your machine has a limited amount of memory, you may want to activate
|
||||||
|
swap devices now (<command>swapon
|
||||||
|
<replaceable>device</replaceable></command>). The installer (or rather, the
|
||||||
|
build actions that it may spawn) may need quite a bit of RAM, depending on
|
||||||
|
your configuration.
|
||||||
<screen>
|
<screen>
|
||||||
# swapon /dev/sda2</screen>
|
# swapon /dev/sda2</screen>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<para>You now need to create a file
|
You now need to create a file
|
||||||
<filename>/mnt/etc/nixos/configuration.nix</filename> that
|
<filename>/mnt/etc/nixos/configuration.nix</filename> that specifies the
|
||||||
specifies the intended configuration of the system. This is
|
intended configuration of the system. This is because NixOS has a
|
||||||
because NixOS has a <emphasis>declarative</emphasis> configuration
|
<emphasis>declarative</emphasis> configuration model: you create or edit a
|
||||||
model: you create or edit a description of the desired
|
description of the desired configuration of your system, and then NixOS
|
||||||
configuration of your system, and then NixOS takes care of making
|
takes care of making it happen. The syntax of the NixOS configuration file
|
||||||
it happen. The syntax of the NixOS configuration file is
|
is described in <xref linkend="sec-configuration-syntax"/>, while a list of
|
||||||
described in <xref linkend="sec-configuration-syntax"/>, while a
|
available configuration options appears in
|
||||||
list of available configuration options appears in <xref
|
<xref
|
||||||
linkend="ch-options"/>. A minimal example is shown in <xref
|
linkend="ch-options"/>. A minimal example is shown in
|
||||||
linkend="ex-config"/>.</para>
|
<xref
|
||||||
|
linkend="ex-config"/>.
|
||||||
<para>The command <command>nixos-generate-config</command> can
|
</para>
|
||||||
generate an initial configuration file for you:
|
<para>
|
||||||
|
The command <command>nixos-generate-config</command> can generate an
|
||||||
|
initial configuration file for you:
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-generate-config --root /mnt</screen>
|
# nixos-generate-config --root /mnt</screen>
|
||||||
|
You should then edit <filename>/mnt/etc/nixos/configuration.nix</filename>
|
||||||
You should then edit
|
to suit your needs:
|
||||||
<filename>/mnt/etc/nixos/configuration.nix</filename> to suit your
|
|
||||||
needs:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nano /mnt/etc/nixos/configuration.nix
|
# nano /mnt/etc/nixos/configuration.nix
|
||||||
</screen>
|
</screen>
|
||||||
|
If you’re using the graphical ISO image, other editors may be available
|
||||||
If you’re using the graphical ISO image, other editors may be
|
(such as <command>vim</command>). If you have network access, you can also
|
||||||
available (such as <command>vim</command>). If you have network
|
install other editors — for instance, you can install Emacs by running
|
||||||
access, you can also install other editors — for instance, you can
|
<literal>nix-env -i emacs</literal>.
|
||||||
install Emacs by running <literal>nix-env -i
|
</para>
|
||||||
emacs</literal>.</para>
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term>BIOS systems</term>
|
||||||
|
<listitem>
|
||||||
<varlistentry><term>BIOS systems</term>
|
<para>
|
||||||
<listitem><para>You <emphasis>must</emphasis> set the option
|
You <emphasis>must</emphasis> set the option
|
||||||
<xref linkend="opt-boot.loader.grub.device"/> to specify on which disk
|
<xref linkend="opt-boot.loader.grub.device"/> to specify on which disk
|
||||||
the GRUB boot loader is to be installed. Without it, NixOS cannot
|
the GRUB boot loader is to be installed. Without it, NixOS cannot boot.
|
||||||
boot.</para></listitem></varlistentry>
|
</para>
|
||||||
|
</listitem>
|
||||||
<varlistentry><term>UEFI systems</term>
|
</varlistentry>
|
||||||
<listitem><para>You <emphasis>must</emphasis> set the option
|
<varlistentry>
|
||||||
<xref linkend="opt-boot.loader.systemd-boot.enable"/> to <literal>true</literal>.
|
<term>UEFI systems</term>
|
||||||
<command>nixos-generate-config</command> should do this automatically for new
|
<listitem>
|
||||||
configurations when booted in
|
<para>
|
||||||
UEFI mode.</para>
|
You <emphasis>must</emphasis> set the option
|
||||||
<para>You may want to look at the options starting with
|
<xref linkend="opt-boot.loader.systemd-boot.enable"/> to
|
||||||
<option><link linkend="opt-boot.loader.efi.canTouchEfiVariables">boot.loader.efi</link></option> and
|
<literal>true</literal>. <command>nixos-generate-config</command> should
|
||||||
<option><link linkend="opt-boot.loader.systemd-boot.enable">boot.loader.systemd</link></option> as well.
|
do this automatically for new configurations when booted in UEFI mode.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
<para>
|
||||||
</varlistentry>
|
You may want to look at the options starting with
|
||||||
|
<option><link linkend="opt-boot.loader.efi.canTouchEfiVariables">boot.loader.efi</link></option>
|
||||||
</variablelist>
|
and
|
||||||
|
<option><link linkend="opt-boot.loader.systemd-boot.enable">boot.loader.systemd</link></option>
|
||||||
<para>If there are other operating systems running on the machine before
|
as well.
|
||||||
installing NixOS, the
|
</para>
|
||||||
<xref linkend="opt-boot.loader.grub.useOSProber"/> option can be set to
|
</listitem>
|
||||||
<literal>true</literal> to automatically add them to the grub menu.</para>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
<para>Another critical option is <option>fileSystems</option>,
|
<para>
|
||||||
specifying the file systems that need to be mounted by NixOS.
|
If there are other operating systems running on the machine before
|
||||||
However, you typically don’t need to set it yourself, because
|
installing NixOS, the <xref linkend="opt-boot.loader.grub.useOSProber"/>
|
||||||
|
option can be set to <literal>true</literal> to automatically add them to
|
||||||
|
the grub menu.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Another critical option is <option>fileSystems</option>, specifying the
|
||||||
|
file systems that need to be mounted by NixOS. However, you typically
|
||||||
|
don’t need to set it yourself, because
|
||||||
<command>nixos-generate-config</command> sets it automatically in
|
<command>nixos-generate-config</command> sets it automatically in
|
||||||
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename>
|
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename> from your
|
||||||
from your currently mounted file systems. (The configuration file
|
currently mounted file systems. (The configuration file
|
||||||
<filename>hardware-configuration.nix</filename> is included from
|
<filename>hardware-configuration.nix</filename> is included from
|
||||||
<filename>configuration.nix</filename> and will be overwritten by
|
<filename>configuration.nix</filename> and will be overwritten by future
|
||||||
future invocations of <command>nixos-generate-config</command>;
|
invocations of <command>nixos-generate-config</command>; thus, you
|
||||||
thus, you generally should not modify it.)</para>
|
generally should not modify it.)
|
||||||
|
</para>
|
||||||
<note><para>Depending on your hardware configuration or type of
|
<note>
|
||||||
file system, you may need to set the option
|
<para>
|
||||||
<option>boot.initrd.kernelModules</option> to include the kernel
|
Depending on your hardware configuration or type of file system, you may
|
||||||
modules that are necessary for mounting the root file system,
|
need to set the option <option>boot.initrd.kernelModules</option> to
|
||||||
otherwise the installed system will not be able to boot. (If this
|
include the kernel modules that are necessary for mounting the root file
|
||||||
happens, boot from the CD again, mount the target file system on
|
system, otherwise the installed system will not be able to boot. (If this
|
||||||
<filename>/mnt</filename>, fix
|
happens, boot from the CD again, mount the target file system on
|
||||||
<filename>/mnt/etc/nixos/configuration.nix</filename> and rerun
|
<filename>/mnt</filename>, fix
|
||||||
<filename>nixos-install</filename>.) In most cases,
|
<filename>/mnt/etc/nixos/configuration.nix</filename> and rerun
|
||||||
<command>nixos-generate-config</command> will figure out the
|
<filename>nixos-install</filename>.) In most cases,
|
||||||
required modules.</para></note>
|
<command>nixos-generate-config</command> will figure out the required
|
||||||
|
modules.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>Do the installation:
|
<para>
|
||||||
|
Do the installation:
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-install</screen>
|
# nixos-install</screen>
|
||||||
|
Cross fingers. If this fails due to a temporary problem (such as a network
|
||||||
Cross fingers. If this fails due to a temporary problem (such as
|
issue while downloading binaries from the NixOS binary cache), you can just
|
||||||
a network issue while downloading binaries from the NixOS binary
|
re-run <command>nixos-install</command>. Otherwise, fix your
|
||||||
cache), you can just re-run <command>nixos-install</command>.
|
<filename>configuration.nix</filename> and then re-run
|
||||||
Otherwise, fix your <filename>configuration.nix</filename> and
|
<command>nixos-install</command>.
|
||||||
then re-run <command>nixos-install</command>.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>As the last step, <command>nixos-install</command> will ask
|
As the last step, <command>nixos-install</command> will ask you to set the
|
||||||
you to set the password for the <literal>root</literal> user, e.g.
|
password for the <literal>root</literal> user, e.g.
|
||||||
|
<screen>
|
||||||
<screen>
|
|
||||||
setting root password...
|
setting root password...
|
||||||
Enter new UNIX password: ***
|
Enter new UNIX password: ***
|
||||||
Retype new UNIX password: ***
|
Retype new UNIX password: ***
|
||||||
</screen>
|
</screen>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
To prevent the password prompt, set <code><xref linkend="opt-users.mutableUsers"/> = false;</code> in
|
To prevent the password prompt, set
|
||||||
<filename>configuration.nix</filename>, which allows unattended installation
|
<code><xref linkend="opt-users.mutableUsers"/> = false;</code> in
|
||||||
necessary in automation.
|
<filename>configuration.nix</filename>, which allows unattended
|
||||||
</para>
|
installation necessary in automation.
|
||||||
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>If everything went well:
|
<para>
|
||||||
|
If everything went well:
|
||||||
<screen>
|
<screen>
|
||||||
# reboot</screen>
|
# reboot</screen>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<para>You should now be able to boot into the installed NixOS. The
|
You should now be able to boot into the installed NixOS. The GRUB boot menu
|
||||||
GRUB boot menu shows a list of <emphasis>available
|
shows a list of <emphasis>available configurations</emphasis> (initially
|
||||||
configurations</emphasis> (initially just one). Every time you
|
just one). Every time you change the NixOS configuration (see
|
||||||
change the NixOS configuration (see <link
|
<link
|
||||||
linkend="sec-changing-config">Changing Configuration</link> ), a
|
linkend="sec-changing-config">Changing Configuration</link>
|
||||||
new item is added to the menu. This allows you to easily roll back
|
), a new item is added to the menu. This allows you to easily roll back to
|
||||||
to a previous configuration if something goes wrong.</para>
|
a previous configuration if something goes wrong.
|
||||||
|
</para>
|
||||||
<para>You should log in and change the <literal>root</literal>
|
<para>
|
||||||
password with <command>passwd</command>.</para>
|
You should log in and change the <literal>root</literal> password with
|
||||||
|
<command>passwd</command>.
|
||||||
<para>You’ll probably want to create some user accounts as well,
|
</para>
|
||||||
which can be done with <command>useradd</command>:
|
<para>
|
||||||
|
You’ll probably want to create some user accounts as well, which can be
|
||||||
|
done with <command>useradd</command>:
|
||||||
<screen>
|
<screen>
|
||||||
$ useradd -c 'Eelco Dolstra' -m eelco
|
$ useradd -c 'Eelco Dolstra' -m eelco
|
||||||
$ passwd eelco</screen>
|
$ passwd eelco</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
You may also want to install some software. For instance,
|
||||||
<para>You may also want to install some software. For instance,
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -qa \*</screen>
|
$ nix-env -qa \*</screen>
|
||||||
|
|
||||||
shows what packages are available, and
|
shows what packages are available, and
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-env -i w3m</screen>
|
$ nix-env -i w3m</screen>
|
||||||
|
install the <literal>w3m</literal> browser.
|
||||||
install the <literal>w3m</literal> browser.</para>
|
</para>
|
||||||
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
</orderedlist>
|
<para>
|
||||||
|
To summarise, <xref linkend="ex-install-sequence" /> shows a typical sequence
|
||||||
<para>To summarise, <xref linkend="ex-install-sequence" /> shows a
|
of commands for installing NixOS on an empty hard drive (here
|
||||||
typical sequence of commands for installing NixOS on an empty hard
|
<filename>/dev/sda</filename>). <xref linkend="ex-config"
|
||||||
drive (here <filename>/dev/sda</filename>). <xref linkend="ex-config"
|
/> shows a
|
||||||
/> shows a corresponding configuration Nix expression.</para>
|
corresponding configuration Nix expression.
|
||||||
|
</para>
|
||||||
<example xml:id='ex-install-sequence'><title>Commands for Installing NixOS on <filename>/dev/sda</filename></title>
|
<example xml:id='ex-install-sequence'>
|
||||||
|
<title>Commands for Installing NixOS on <filename>/dev/sda</filename></title>
|
||||||
<screen>
|
<screen>
|
||||||
# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
|
# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
|
||||||
-- for UEFI systems only
|
-- for UEFI systems only
|
||||||
@ -372,10 +407,10 @@ drive (here <filename>/dev/sda</filename>). <xref linkend="ex-config"
|
|||||||
# nano /mnt/etc/nixos/configuration.nix
|
# nano /mnt/etc/nixos/configuration.nix
|
||||||
# nixos-install
|
# nixos-install
|
||||||
# reboot</screen>
|
# reboot</screen>
|
||||||
</example>
|
</example>
|
||||||
|
<example xml:id='ex-config'>
|
||||||
<example xml:id='ex-config'><title>NixOS Configuration</title>
|
<title>NixOS Configuration</title>
|
||||||
<screen>
|
<screen>
|
||||||
{ config, pkgs, ... }: {
|
{ config, pkgs, ... }: {
|
||||||
imports = [
|
imports = [
|
||||||
# Include the results of the hardware scan.
|
# Include the results of the hardware scan.
|
||||||
@ -394,11 +429,9 @@ drive (here <filename>/dev/sda</filename>). <xref linkend="ex-config"
|
|||||||
services.sshd.enable = true;
|
services.sshd.enable = true;
|
||||||
}
|
}
|
||||||
</screen>
|
</screen>
|
||||||
</example>
|
</example>
|
||||||
|
<xi:include href="installing-usb.xml" />
|
||||||
<xi:include href="installing-usb.xml" />
|
<xi:include href="installing-pxe.xml" />
|
||||||
<xi:include href="installing-pxe.xml" />
|
<xi:include href="installing-virtualbox-guest.xml" />
|
||||||
<xi:include href="installing-virtualbox-guest.xml" />
|
<xi:include href="installing-from-other-distro.xml" />
|
||||||
<xi:include href="installing-from-other-distro.xml" />
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -3,46 +3,52 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-obtaining">
|
xml:id="sec-obtaining">
|
||||||
|
<title>Obtaining NixOS</title>
|
||||||
<title>Obtaining NixOS</title>
|
<para>
|
||||||
|
NixOS ISO images can be downloaded from the
|
||||||
<para>NixOS ISO images can be downloaded from the <link
|
<link
|
||||||
xlink:href="http://nixos.org/nixos/download.html">NixOS
|
xlink:href="http://nixos.org/nixos/download.html">NixOS download
|
||||||
download page</link>. There are a number of installation options. If
|
page</link>. There are a number of installation options. If you happen to
|
||||||
you happen to have an optical drive and a spare CD, burning the
|
have an optical drive and a spare CD, burning the image to CD and booting
|
||||||
image to CD and booting from that is probably the easiest option.
|
from that is probably the easiest option. Most people will need to prepare a
|
||||||
Most people will need to prepare a USB stick to boot from.
|
USB stick to boot from. <xref linkend="sec-booting-from-usb"/> describes the
|
||||||
<xref linkend="sec-booting-from-usb"/> describes the preferred method
|
preferred method to prepare a USB stick. A number of alternative methods are
|
||||||
to prepare a USB stick.
|
presented in the
|
||||||
A number of alternative methods are presented in the <link
|
<link
|
||||||
xlink:href="https://nixos.wiki/wiki/NixOS_Installation_Guide#Making_the_installation_media">NixOS
|
xlink:href="https://nixos.wiki/wiki/NixOS_Installation_Guide#Making_the_installation_media">NixOS
|
||||||
Wiki</link>.</para>
|
Wiki</link>.
|
||||||
|
</para>
|
||||||
<para>As an alternative to installing NixOS yourself, you can get a
|
<para>
|
||||||
running NixOS system through several other means:
|
As an alternative to installing NixOS yourself, you can get a running NixOS
|
||||||
|
system through several other means:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Using virtual appliances in Open Virtualization Format (OVF)
|
<para>
|
||||||
that can be imported into VirtualBox. These are available from
|
Using virtual appliances in Open Virtualization Format (OVF) that can be
|
||||||
the <link xlink:href="http://nixos.org/nixos/download.html">NixOS
|
imported into VirtualBox. These are available from the
|
||||||
download page</link>.</para>
|
<link xlink:href="http://nixos.org/nixos/download.html">NixOS download
|
||||||
</listitem>
|
page</link>.
|
||||||
<listitem>
|
</para>
|
||||||
<para>Using AMIs for Amazon’s EC2. To find one for your region
|
</listitem>
|
||||||
and instance type, please refer to the <link
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Using AMIs for Amazon’s EC2. To find one for your region and instance
|
||||||
|
type, please refer to the
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/ec2-amis.nix">list
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/ec2-amis.nix">list
|
||||||
of most recent AMIs</link>.</para>
|
of most recent AMIs</link>.
|
||||||
</listitem>
|
</para>
|
||||||
<listitem>
|
</listitem>
|
||||||
<para>Using NixOps, the NixOS-based cloud deployment tool, which
|
<listitem>
|
||||||
allows you to provision VirtualBox and EC2 NixOS instances from
|
<para>
|
||||||
declarative specifications. Check out the <link
|
Using NixOps, the NixOS-based cloud deployment tool, which allows you to
|
||||||
|
provision VirtualBox and EC2 NixOS instances from declarative
|
||||||
|
specifications. Check out the
|
||||||
|
<link
|
||||||
xlink:href="https://nixos.org/nixops">NixOps homepage</link> for
|
xlink:href="https://nixos.org/nixops">NixOps homepage</link> for
|
||||||
details.</para>
|
details.
|
||||||
</listitem>
|
</para>
|
||||||
</itemizedlist>
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -2,140 +2,130 @@
|
|||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-upgrading">
|
xml:id="sec-upgrading">
|
||||||
|
<title>Upgrading NixOS</title>
|
||||||
<title>Upgrading NixOS</title>
|
<para>
|
||||||
|
The best way to keep your NixOS installation up to date is to use one of the
|
||||||
<para>The best way to keep your NixOS installation up to date is to
|
NixOS <emphasis>channels</emphasis>. A channel is a Nix mechanism for
|
||||||
use one of the NixOS <emphasis>channels</emphasis>. A channel is a
|
distributing Nix expressions and associated binaries. The NixOS channels are
|
||||||
Nix mechanism for distributing Nix expressions and associated
|
updated automatically from NixOS’s Git repository after certain tests have
|
||||||
binaries. The NixOS channels are updated automatically from NixOS’s
|
passed and all packages have been built. These channels are:
|
||||||
Git repository after certain tests have passed and all packages have
|
<itemizedlist>
|
||||||
been built. These channels are:
|
<listitem>
|
||||||
|
<para>
|
||||||
<itemizedlist>
|
<emphasis>Stable channels</emphasis>, such as
|
||||||
<listitem>
|
<literal
|
||||||
<para><emphasis>Stable channels</emphasis>, such as <literal
|
|
||||||
xlink:href="https://nixos.org/channels/nixos-17.03">nixos-17.03</literal>.
|
xlink:href="https://nixos.org/channels/nixos-17.03">nixos-17.03</literal>.
|
||||||
These only get conservative bug fixes and package upgrades. For
|
These only get conservative bug fixes and package upgrades. For instance,
|
||||||
instance, a channel update may cause the Linux kernel on your
|
a channel update may cause the Linux kernel on your system to be upgraded
|
||||||
system to be upgraded from 4.9.16 to 4.9.17 (a minor bug fix), but
|
from 4.9.16 to 4.9.17 (a minor bug fix), but not from
|
||||||
not from 4.9.<replaceable>x</replaceable> to
|
4.9.<replaceable>x</replaceable> to 4.11.<replaceable>x</replaceable> (a
|
||||||
4.11.<replaceable>x</replaceable> (a major change that has the
|
major change that has the potential to break things). Stable channels are
|
||||||
potential to break things). Stable channels are generally
|
generally maintained until the next stable branch is created.
|
||||||
maintained until the next stable branch is created.</para>
|
</para>
|
||||||
<para></para>
|
<para></para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The <emphasis>unstable channel</emphasis>, <literal
|
<para>
|
||||||
|
The <emphasis>unstable channel</emphasis>,
|
||||||
|
<literal
|
||||||
xlink:href="https://nixos.org/channels/nixos-unstable">nixos-unstable</literal>.
|
xlink:href="https://nixos.org/channels/nixos-unstable">nixos-unstable</literal>.
|
||||||
This corresponds to NixOS’s main development branch, and may thus
|
This corresponds to NixOS’s main development branch, and may thus see
|
||||||
see radical changes between channel updates. It’s not recommended
|
radical changes between channel updates. It’s not recommended for
|
||||||
for production systems.</para>
|
production systems.
|
||||||
</listitem>
|
</para>
|
||||||
<listitem>
|
</listitem>
|
||||||
<para><emphasis>Small channels</emphasis>, such as <literal
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<emphasis>Small channels</emphasis>, such as
|
||||||
|
<literal
|
||||||
xlink:href="https://nixos.org/channels/nixos-17.03-small">nixos-17.03-small</literal>
|
xlink:href="https://nixos.org/channels/nixos-17.03-small">nixos-17.03-small</literal>
|
||||||
or <literal
|
or
|
||||||
xlink:href="https://nixos.org/channels/nixos-unstable-small">nixos-unstable-small</literal>. These
|
<literal
|
||||||
are identical to the stable and unstable channels described above,
|
xlink:href="https://nixos.org/channels/nixos-unstable-small">nixos-unstable-small</literal>.
|
||||||
except that they contain fewer binary packages. This means they
|
These are identical to the stable and unstable channels described above,
|
||||||
get updated faster than the regular channels (for instance, when a
|
except that they contain fewer binary packages. This means they get
|
||||||
critical security patch is committed to NixOS’s source tree), but
|
updated faster than the regular channels (for instance, when a critical
|
||||||
may require more packages to be built from source than
|
security patch is committed to NixOS’s source tree), but may require
|
||||||
usual. They’re mostly intended for server environments and as such
|
more packages to be built from source than usual. They’re mostly
|
||||||
contain few GUI applications.</para>
|
intended for server environments and as such contain few GUI applications.
|
||||||
</listitem>
|
</para>
|
||||||
</itemizedlist>
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
To see what channels are available, go to <link
|
To see what channels are available, go to
|
||||||
xlink:href="https://nixos.org/channels"/>. (Note that the URIs of the
|
<link
|
||||||
various channels redirect to a directory that contains the channel’s
|
xlink:href="https://nixos.org/channels"/>. (Note that the URIs of the
|
||||||
latest version and includes ISO images and VirtualBox
|
various channels redirect to a directory that contains the channel’s latest
|
||||||
appliances.)</para>
|
version and includes ISO images and VirtualBox appliances.)
|
||||||
|
</para>
|
||||||
<para>When you first install NixOS, you’re automatically subscribed to
|
<para>
|
||||||
the NixOS channel that corresponds to your installation source. For
|
When you first install NixOS, you’re automatically subscribed to the NixOS
|
||||||
instance, if you installed from a 17.03 ISO, you will be subscribed to
|
channel that corresponds to your installation source. For instance, if you
|
||||||
the <literal>nixos-17.03</literal> channel. To see which NixOS
|
installed from a 17.03 ISO, you will be subscribed to the
|
||||||
channel you’re subscribed to, run the following as root:
|
<literal>nixos-17.03</literal> channel. To see which NixOS channel you’re
|
||||||
|
subscribed to, run the following as root:
|
||||||
<screen>
|
<screen>
|
||||||
# nix-channel --list | grep nixos
|
# nix-channel --list | grep nixos
|
||||||
nixos https://nixos.org/channels/nixos-unstable
|
nixos https://nixos.org/channels/nixos-unstable
|
||||||
</screen>
|
</screen>
|
||||||
|
To switch to a different NixOS channel, do
|
||||||
To switch to a different NixOS channel, do
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nix-channel --add https://nixos.org/channels/<replaceable>channel-name</replaceable> nixos
|
# nix-channel --add https://nixos.org/channels/<replaceable>channel-name</replaceable> nixos
|
||||||
</screen>
|
</screen>
|
||||||
|
(Be sure to include the <literal>nixos</literal> parameter at the end.) For
|
||||||
(Be sure to include the <literal>nixos</literal> parameter at the
|
instance, to use the NixOS 17.03 stable channel:
|
||||||
end.) For instance, to use the NixOS 17.03 stable channel:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nix-channel --add https://nixos.org/channels/nixos-17.03 nixos
|
# nix-channel --add https://nixos.org/channels/nixos-17.03 nixos
|
||||||
</screen>
|
</screen>
|
||||||
|
If you have a server, you may want to use the “small” channel instead:
|
||||||
If you have a server, you may want to use the “small” channel instead:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nix-channel --add https://nixos.org/channels/nixos-17.03-small nixos
|
# nix-channel --add https://nixos.org/channels/nixos-17.03-small nixos
|
||||||
</screen>
|
</screen>
|
||||||
|
And if you want to live on the bleeding edge:
|
||||||
And if you want to live on the bleeding edge:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nix-channel --add https://nixos.org/channels/nixos-unstable nixos
|
# nix-channel --add https://nixos.org/channels/nixos-unstable nixos
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
<para>
|
||||||
|
You can then upgrade NixOS to the latest version in your chosen channel by
|
||||||
<para>You can then upgrade NixOS to the latest version in your chosen
|
running
|
||||||
channel by running
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-rebuild switch --upgrade
|
# nixos-rebuild switch --upgrade
|
||||||
</screen>
|
</screen>
|
||||||
|
which is equivalent to the more verbose <literal>nix-channel --update nixos;
|
||||||
|
nixos-rebuild switch</literal>.
|
||||||
|
</para>
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
Channels are set per user. This means that running <literal> nix-channel
|
||||||
|
--add</literal> as a non root user (or without sudo) will not affect
|
||||||
|
configuration in <literal>/etc/nixos/configuration.nix</literal>
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
<warning>
|
||||||
|
<para>
|
||||||
|
It is generally safe to switch back and forth between channels. The only
|
||||||
|
exception is that a newer NixOS may also have a newer Nix version, which may
|
||||||
|
involve an upgrade of Nix’s database schema. This cannot be undone easily,
|
||||||
|
so in that case you will not be able to go back to your original channel.
|
||||||
|
</para>
|
||||||
|
</warning>
|
||||||
|
<section>
|
||||||
|
<title>Automatic Upgrades</title>
|
||||||
|
|
||||||
which is equivalent to the more verbose <literal>nix-channel --update
|
<para>
|
||||||
nixos; nixos-rebuild switch</literal>.</para>
|
You can keep a NixOS system up-to-date automatically by adding the following
|
||||||
|
to <filename>configuration.nix</filename>:
|
||||||
<note><para>Channels are set per user. This means that running <literal>
|
|
||||||
nix-channel --add</literal> as a non root user (or without sudo) will not
|
|
||||||
affect configuration in <literal>/etc/nixos/configuration.nix</literal>
|
|
||||||
</para></note>
|
|
||||||
|
|
||||||
<warning><para>It is generally safe to switch back and forth between
|
|
||||||
channels. The only exception is that a newer NixOS may also have a
|
|
||||||
newer Nix version, which may involve an upgrade of Nix’s database
|
|
||||||
schema. This cannot be undone easily, so in that case you will not be
|
|
||||||
able to go back to your original channel.</para></warning>
|
|
||||||
|
|
||||||
|
|
||||||
<section><title>Automatic Upgrades</title>
|
|
||||||
|
|
||||||
<para>You can keep a NixOS system up-to-date automatically by adding
|
|
||||||
the following to <filename>configuration.nix</filename>:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-system.autoUpgrade.enable"/> = true;
|
<xref linkend="opt-system.autoUpgrade.enable"/> = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This enables a periodically executed systemd service named
|
||||||
This enables a periodically executed systemd service named
|
<literal>nixos-upgrade.service</literal>. It runs <command>nixos-rebuild
|
||||||
<literal>nixos-upgrade.service</literal>. It runs
|
switch --upgrade</command> to upgrade NixOS to the latest version in the
|
||||||
<command>nixos-rebuild switch --upgrade</command> to upgrade NixOS to
|
current channel. (To see when the service runs, see <command>systemctl
|
||||||
the latest version in the current channel. (To see when the service
|
list-timers</command>.) You can also specify a channel explicitly, e.g.
|
||||||
runs, see <command>systemctl list-timers</command>.) You can also
|
|
||||||
specify a channel explicitly, e.g.
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<xref linkend="opt-system.autoUpgrade.channel"/> = https://nixos.org/channels/nixos-17.03;
|
<xref linkend="opt-system.autoUpgrade.channel"/> = https://nixos.org/channels/nixos-17.03;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
</section>
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
@ -1,39 +1,31 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><filename>configuration.nix</filename>
|
||||||
<refentrytitle><filename>configuration.nix</filename></refentrytitle>
|
</refentrytitle><manvolnum>5</manvolnum>
|
||||||
<manvolnum>5</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><filename>configuration.nix</filename>
|
||||||
<refname><filename>configuration.nix</filename></refname>
|
</refname><refpurpose>NixOS system configuration specification</refpurpose>
|
||||||
<refpurpose>NixOS system configuration specification</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsection>
|
||||||
|
<title>Description</title>
|
||||||
|
<para>
|
||||||
<refsection><title>Description</title>
|
The file <filename>/etc/nixos/configuration.nix</filename> contains the
|
||||||
|
declarative specification of your NixOS system configuration. The command
|
||||||
<para>The file <filename>/etc/nixos/configuration.nix</filename>
|
<command>nixos-rebuild</command> takes this file and realises the system
|
||||||
contains the declarative specification of your NixOS system
|
configuration specified therein.
|
||||||
configuration. The command <command>nixos-rebuild</command> takes
|
</para>
|
||||||
this file and realises the system configuration specified
|
</refsection>
|
||||||
therein.</para>
|
<refsection>
|
||||||
|
<title>Options</title>
|
||||||
</refsection>
|
<para>
|
||||||
|
You can use the following options in <filename>configuration.nix</filename>.
|
||||||
|
</para>
|
||||||
<refsection><title>Options</title>
|
<xi:include href="./generated/options-db.xml"
|
||||||
|
|
||||||
<para>You can use the following options in
|
|
||||||
<filename>configuration.nix</filename>.</para>
|
|
||||||
|
|
||||||
<xi:include href="./generated/options-db.xml"
|
|
||||||
xpointer="configuration-variable-list" />
|
xpointer="configuration-variable-list" />
|
||||||
|
</refsection>
|
||||||
</refsection>
|
|
||||||
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,40 +1,39 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-build-vms</command>
|
||||||
<refentrytitle><command>nixos-build-vms</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-build-vms</command>
|
||||||
<refname><command>nixos-build-vms</command></refname>
|
</refname><refpurpose>build a network of virtual machines from a network of NixOS configurations</refpurpose>
|
||||||
<refpurpose>build a network of virtual machines from a network of NixOS configurations</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-build-vms</command>
|
||||||
<refsynopsisdiv>
|
<arg><option>--show-trace</option>
|
||||||
<cmdsynopsis>
|
</arg>
|
||||||
<command>nixos-build-vms</command>
|
<arg><option>--no-out-link</option>
|
||||||
<arg><option>--show-trace</option></arg>
|
</arg>
|
||||||
<arg><option>--no-out-link</option></arg>
|
<arg><option>--help</option>
|
||||||
<arg><option>--help</option></arg>
|
</arg>
|
||||||
<arg choice="plain"><replaceable>network.nix</replaceable></arg>
|
<arg choice="plain"><replaceable>network.nix</replaceable>
|
||||||
|
</arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
<refsection><title>Description</title>
|
<title>Description</title>
|
||||||
|
<para>
|
||||||
<para>This command builds a network of QEMU-KVM virtual machines of a Nix expression
|
This command builds a network of QEMU-KVM virtual machines of a Nix
|
||||||
specifying a network of NixOS machines. The virtual network can be started by
|
expression specifying a network of NixOS machines. The virtual network can
|
||||||
executing the <filename>bin/run-vms</filename> shell script that is generated by
|
be started by executing the <filename>bin/run-vms</filename> shell script
|
||||||
this command. By default, a <filename>result</filename> symlink is produced that
|
that is generated by this command. By default, a <filename>result</filename>
|
||||||
points to the generated virtual network.
|
symlink is produced that points to the generated virtual network.
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>A network Nix expression has the following structure:
|
A network Nix expression has the following structure:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
{
|
{
|
||||||
test1 = {pkgs, config, ...}:
|
test1 = {pkgs, config, ...}:
|
||||||
@ -58,53 +57,53 @@ points to the generated virtual network.
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
</screen>
|
</screen>
|
||||||
|
Each attribute in the expression represents a machine in the network (e.g.
|
||||||
Each attribute in the expression represents a machine in the network
|
<varname>test1</varname> and <varname>test2</varname>) referring to a
|
||||||
(e.g. <varname>test1</varname> and <varname>test2</varname>)
|
function defining a NixOS configuration. In each NixOS configuration, two
|
||||||
referring to a function defining a NixOS configuration.
|
attributes have a special meaning. The
|
||||||
In each NixOS configuration, two attributes have a special meaning.
|
<varname>deployment.targetHost</varname> specifies the address (domain name
|
||||||
The <varname>deployment.targetHost</varname> specifies the address
|
or IP address) of the system which is used by <command>ssh</command> to
|
||||||
(domain name or IP address)
|
perform remote deployment operations. The
|
||||||
of the system which is used by <command>ssh</command> to perform
|
<varname>nixpkgs.localSystem.system</varname> attribute can be used to
|
||||||
remote deployment operations. The <varname>nixpkgs.localSystem.system</varname>
|
specify an architecture for the target machine, such as
|
||||||
attribute can be used to specify an architecture for the target machine,
|
<varname>i686-linux</varname> which builds a 32-bit NixOS configuration.
|
||||||
such as <varname>i686-linux</varname> which builds a 32-bit NixOS
|
Omitting this property will build the configuration for the same
|
||||||
configuration. Omitting this property will build the configuration
|
architecture as the host system.
|
||||||
for the same architecture as the host system.
|
</para>
|
||||||
</para>
|
</refsection>
|
||||||
|
<refsection>
|
||||||
</refsection>
|
<title>Options</title>
|
||||||
|
<para>
|
||||||
<refsection><title>Options</title>
|
This command accepts the following options:
|
||||||
|
</para>
|
||||||
<para>This command accepts the following options:</para>
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><option>--show-trace</option>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
|
||||||
<term><option>--show-trace</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Shows a trace of the output.</para>
|
<para>
|
||||||
|
Shows a trace of the output.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--no-out-link</option>
|
||||||
<term><option>--no-out-link</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Do not create a 'result' symlink.</para>
|
<para>
|
||||||
|
Do not create a 'result' symlink.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>-h</option>, <option>--help</option>
|
||||||
<term><option>-h</option>, <option>--help</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Shows the usage of this command to the user.</para>
|
<para>
|
||||||
|
Shows the usage of this command to the user.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</variablelist>
|
</refsection>
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,119 +1,119 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-enter</command>
|
||||||
<refentrytitle><command>nixos-enter</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-enter</command>
|
||||||
<refname><command>nixos-enter</command></refname>
|
</refname><refpurpose>run a command in a NixOS chroot environment</refpurpose>
|
||||||
<refpurpose>run a command in a NixOS chroot environment</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-enter</command>
|
||||||
<refsynopsisdiv>
|
<arg>
|
||||||
<cmdsynopsis>
|
<arg choice='plain'><option>--root</option>
|
||||||
<command>nixos-enter</command>
|
</arg><replaceable>root</replaceable>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>--root</option></arg>
|
<arg>
|
||||||
<replaceable>root</replaceable>
|
<arg choice='plain'><option>--system</option>
|
||||||
</arg>
|
</arg><replaceable>system</replaceable>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>--system</option></arg>
|
<arg>
|
||||||
<replaceable>system</replaceable>
|
<arg choice='plain'><option>-c</option>
|
||||||
</arg>
|
</arg><replaceable>shell-command</replaceable>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>-c</option></arg>
|
<arg>
|
||||||
<replaceable>shell-command</replaceable>
|
<arg choice='plain'><option>--help</option>
|
||||||
</arg>
|
|
||||||
<arg>
|
|
||||||
<arg choice='plain'><option>--help</option></arg>
|
|
||||||
</arg>
|
|
||||||
<arg>
|
|
||||||
<arg choice='plain'><option>--</option></arg>
|
|
||||||
<replaceable>arguments</replaceable>
|
|
||||||
</arg>
|
</arg>
|
||||||
|
</arg>
|
||||||
|
<arg>
|
||||||
|
<arg choice='plain'><option>--</option>
|
||||||
|
</arg><replaceable>arguments</replaceable>
|
||||||
|
</arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
|
<title>Description</title>
|
||||||
<refsection><title>Description</title>
|
<para>
|
||||||
|
This command runs a command in a NixOS chroot environment, that is, in a
|
||||||
<para>This command runs a command in a NixOS chroot environment, that
|
filesystem hierarchy previously prepared using
|
||||||
is, in a filesystem hierarchy previously prepared using
|
<command>nixos-install</command>.
|
||||||
<command>nixos-install</command>.</para>
|
</para>
|
||||||
|
</refsection>
|
||||||
</refsection>
|
<refsection>
|
||||||
|
<title>Options</title>
|
||||||
<refsection><title>Options</title>
|
<para>
|
||||||
|
This command accepts the following options:
|
||||||
<para>This command accepts the following options:</para>
|
</para>
|
||||||
|
<variablelist>
|
||||||
<variablelist>
|
<varlistentry>
|
||||||
|
<term><option>--root</option>
|
||||||
<varlistentry>
|
</term>
|
||||||
<term><option>--root</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The path to the NixOS system you want to enter. It defaults to <filename>/mnt</filename>.</para>
|
<para>
|
||||||
|
The path to the NixOS system you want to enter. It defaults to
|
||||||
|
<filename>/mnt</filename>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--system</option>
|
||||||
<term><option>--system</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The NixOS system configuration to use. It defaults to
|
<para>
|
||||||
<filename>/nix/var/nix/profiles/system</filename>. You can enter
|
The NixOS system configuration to use. It defaults to
|
||||||
a previous NixOS configuration by specifying a path such as
|
<filename>/nix/var/nix/profiles/system</filename>. You can enter a
|
||||||
<filename>/nix/var/nix/profiles/system-106-link</filename>.</para>
|
previous NixOS configuration by specifying a path such as
|
||||||
|
<filename>/nix/var/nix/profiles/system-106-link</filename>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--command</option>
|
||||||
<term><option>--command</option></term>
|
</term>
|
||||||
<term><option>-c</option></term>
|
<term><option>-c</option>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The bash command to execute.</para>
|
<para>
|
||||||
|
The bash command to execute.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--</option>
|
||||||
<term><option>--</option></term>
|
</term>
|
||||||
|
<listitem>
|
||||||
<listitem><para>Interpret the remaining arguments as the program
|
<para>
|
||||||
name and arguments to be invoked. The program is not executed in a
|
Interpret the remaining arguments as the program name and arguments to be
|
||||||
shell.</para></listitem>
|
invoked. The program is not executed in a shell.
|
||||||
|
</para>
|
||||||
</varlistentry>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
</refsection>
|
||||||
</refsection>
|
<refsection>
|
||||||
|
<title>Examples</title>
|
||||||
|
<para>
|
||||||
<refsection><title>Examples</title>
|
Start an interactive shell in the NixOS installation in
|
||||||
|
<filename>/mnt</filename>:
|
||||||
<para>Start an interactive shell in the NixOS installation in
|
</para>
|
||||||
<filename>/mnt</filename>:</para>
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-enter /mnt
|
# nixos-enter /mnt
|
||||||
</screen>
|
</screen>
|
||||||
|
<para>
|
||||||
<para>Run a shell command:</para>
|
Run a shell command:
|
||||||
|
</para>
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-enter -c 'ls -l /; cat /proc/mounts'
|
# nixos-enter -c 'ls -l /; cat /proc/mounts'
|
||||||
</screen>
|
</screen>
|
||||||
|
<para>
|
||||||
<para>Run a non-shell command:</para>
|
Run a non-shell command:
|
||||||
|
</para>
|
||||||
<screen>
|
<screen>
|
||||||
# nixos-enter -- cat /proc/mounts
|
# nixos-enter -- cat /proc/mounts
|
||||||
</screen>
|
</screen>
|
||||||
|
</refsection>
|
||||||
</refsection>
|
|
||||||
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,152 +1,149 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-generate-config</command>
|
||||||
<refentrytitle><command>nixos-generate-config</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-generate-config</command>
|
||||||
<refname><command>nixos-generate-config</command></refname>
|
</refname><refpurpose>generate NixOS configuration modules</refpurpose>
|
||||||
<refpurpose>generate NixOS configuration modules</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-generate-config</command>
|
||||||
<refsynopsisdiv>
|
<arg><option>--force</option>
|
||||||
<cmdsynopsis>
|
</arg>
|
||||||
<command>nixos-generate-config</command>
|
<arg>
|
||||||
<arg><option>--force</option></arg>
|
<arg choice='plain'><option>--root</option>
|
||||||
<arg>
|
</arg><replaceable>root</replaceable>
|
||||||
<arg choice='plain'><option>--root</option></arg>
|
</arg>
|
||||||
<replaceable>root</replaceable>
|
<arg>
|
||||||
</arg>
|
<arg choice='plain'><option>--dir</option>
|
||||||
<arg>
|
</arg><replaceable>dir</replaceable>
|
||||||
<arg choice='plain'><option>--dir</option></arg>
|
</arg>
|
||||||
<replaceable>dir</replaceable>
|
|
||||||
</arg>
|
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
|
<title>Description</title>
|
||||||
<refsection><title>Description</title>
|
<para>
|
||||||
|
This command writes two NixOS configuration modules:
|
||||||
<para>This command writes two NixOS configuration modules:
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><option>/etc/nixos/hardware-configuration.nix</option>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
<listitem>
|
||||||
<term><option>/etc/nixos/hardware-configuration.nix</option></term>
|
<para>
|
||||||
|
This module sets NixOS configuration options based on your current
|
||||||
|
hardware configuration. In particular, it sets the
|
||||||
|
<option>fileSystem</option> option to reflect all currently mounted file
|
||||||
|
systems, the <option>swapDevices</option> option to reflect active swap
|
||||||
|
devices, and the <option>boot.initrd.*</option> options to ensure that
|
||||||
|
the initial ramdisk contains any kernel modules necessary for mounting
|
||||||
|
the root file system.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
If this file already exists, it is overwritten. Thus, you should not
|
||||||
|
modify it manually. Rather, you should include it from your
|
||||||
|
<filename>/etc/nixos/configuration.nix</filename>, and re-run
|
||||||
|
<command>nixos-generate-config</command> to update it whenever your
|
||||||
|
hardware configuration changes.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>/etc/nixos/configuration.nix</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
This is the main NixOS system configuration module. If it already
|
||||||
|
exists, it’s left unchanged. Otherwise,
|
||||||
|
<command>nixos-generate-config</command> will write a template for you
|
||||||
|
to customise.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</para>
|
||||||
|
</refsection>
|
||||||
|
<refsection>
|
||||||
|
<title>Options</title>
|
||||||
|
<para>
|
||||||
|
This command accepts the following options:
|
||||||
|
</para>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--root</option>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>This module sets NixOS configuration options based on your
|
<para>
|
||||||
current hardware configuration. In particular, it sets the
|
If this option is given, treat the directory
|
||||||
<option>fileSystem</option> option to reflect all currently
|
<replaceable>root</replaceable> as the root of the file system. This
|
||||||
mounted file systems, the <option>swapDevices</option> option to
|
means that configuration files will be written to
|
||||||
reflect active swap devices, and the
|
<filename><replaceable>root</replaceable>/etc/nixos</filename>, and that
|
||||||
<option>boot.initrd.*</option> options to ensure that the
|
any file systems outside of <replaceable>root</replaceable> are ignored
|
||||||
initial ramdisk contains any kernel modules necessary for
|
for the purpose of generating the <option>fileSystems</option> option.
|
||||||
mounting the root file system.</para>
|
</para>
|
||||||
|
|
||||||
<para>If this file already exists, it is overwritten. Thus, you
|
|
||||||
should not modify it manually. Rather, you should include it
|
|
||||||
from your <filename>/etc/nixos/configuration.nix</filename>, and
|
|
||||||
re-run <command>nixos-generate-config</command> to update it
|
|
||||||
whenever your hardware configuration changes.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--dir</option>
|
||||||
<term><option>/etc/nixos/configuration.nix</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>This is the main NixOS system configuration module. If it
|
<para>
|
||||||
already exists, it’s left unchanged. Otherwise,
|
If this option is given, write the configuration files to the directory
|
||||||
<command>nixos-generate-config</command> will write a template
|
<replaceable>dir</replaceable> instead of
|
||||||
for you to customise.</para>
|
<filename>/etc/nixos</filename>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
</variablelist>
|
<term><option>--force</option>
|
||||||
|
</term>
|
||||||
</para>
|
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
|
|
||||||
<refsection><title>Options</title>
|
|
||||||
|
|
||||||
<para>This command accepts the following options:</para>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>--root</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>If this option is given, treat the directory
|
<para>
|
||||||
<replaceable>root</replaceable> as the root of the file system.
|
Overwrite <filename>/etc/nixos/configuration.nix</filename> if it already
|
||||||
This means that configuration files will be written to
|
exists.
|
||||||
<filename><replaceable>root</replaceable>/etc/nixos</filename>,
|
</para>
|
||||||
and that any file systems outside of
|
|
||||||
<replaceable>root</replaceable> are ignored for the purpose of
|
|
||||||
generating the <option>fileSystems</option> option.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--no-filesystems</option>
|
||||||
<term><option>--dir</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>If this option is given, write the configuration files to
|
<para>
|
||||||
the directory <replaceable>dir</replaceable> instead of
|
Omit everything concerning file systems and swap devices from the
|
||||||
<filename>/etc/nixos</filename>.</para>
|
hardware configuration.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--show-hardware-config</option>
|
||||||
<term><option>--force</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Overwrite
|
<para>
|
||||||
<filename>/etc/nixos/configuration.nix</filename> if it already
|
Don't generate <filename>configuration.nix</filename> or
|
||||||
exists.</para>
|
<filename>hardware-configuration.nix</filename> and print the hardware
|
||||||
|
configuration to stdout only.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
<varlistentry>
|
</refsection>
|
||||||
<term><option>--no-filesystems</option></term>
|
<refsection>
|
||||||
<listitem>
|
<title>Examples</title>
|
||||||
<para>Omit everything concerning file systems and swap devices
|
<para>
|
||||||
from the hardware configuration.</para>
|
This command is typically used during NixOS installation to write initial
|
||||||
</listitem>
|
configuration modules. For example, if you created and mounted the target
|
||||||
</varlistentry>
|
file systems on <filename>/mnt</filename> and
|
||||||
|
<filename>/mnt/boot</filename>, you would run:
|
||||||
<varlistentry>
|
|
||||||
<term><option>--show-hardware-config</option></term>
|
|
||||||
<listitem>
|
|
||||||
<para>Don't generate <filename>configuration.nix</filename> or
|
|
||||||
<filename>hardware-configuration.nix</filename> and print the
|
|
||||||
hardware configuration to stdout only.</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
</variablelist>
|
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
|
|
||||||
<refsection><title>Examples</title>
|
|
||||||
|
|
||||||
<para>This command is typically used during NixOS installation to
|
|
||||||
write initial configuration modules. For example, if you created and
|
|
||||||
mounted the target file systems on <filename>/mnt</filename> and
|
|
||||||
<filename>/mnt/boot</filename>, you would run:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-generate-config --root /mnt
|
$ nixos-generate-config --root /mnt
|
||||||
</screen>
|
</screen>
|
||||||
|
The resulting file
|
||||||
The resulting file
|
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename> might look
|
||||||
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename> might
|
like this:
|
||||||
look like this:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
# Do not modify this file! It was generated by ‘nixos-generate-config’
|
# Do not modify this file! It was generated by ‘nixos-generate-config’
|
||||||
# and may be overwritten by future invocations. Please make changes
|
# and may be overwritten by future invocations. Please make changes
|
||||||
@ -181,28 +178,22 @@ look like this:
|
|||||||
nix.maxJobs = 8;
|
nix.maxJobs = 8;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
It will also create a basic
|
||||||
It will also create a basic
|
<filename>/mnt/etc/nixos/configuration.nix</filename>, which you should edit
|
||||||
<filename>/mnt/etc/nixos/configuration.nix</filename>, which you
|
to customise the logical configuration of your system. This file includes
|
||||||
should edit to customise the logical configuration of your system.
|
the result of the hardware scan as follows:
|
||||||
This file includes the result of the hardware scan as follows:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
imports = [ ./hardware-configuration.nix ];
|
imports = [ ./hardware-configuration.nix ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>After installation, if your hardware configuration changes, you
|
After installation, if your hardware configuration changes, you can run:
|
||||||
can run:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-generate-config
|
$ nixos-generate-config
|
||||||
</screen>
|
</screen>
|
||||||
|
to update <filename>/etc/nixos/hardware-configuration.nix</filename>. Your
|
||||||
to update <filename>/etc/nixos/hardware-configuration.nix</filename>.
|
<filename>/etc/nixos/configuration.nix</filename> will
|
||||||
Your <filename>/etc/nixos/configuration.nix</filename> will
|
<emphasis>not</emphasis> be overwritten.
|
||||||
<emphasis>not</emphasis> be overwritten.</para>
|
</para>
|
||||||
|
</refsection>
|
||||||
</refsection>
|
|
||||||
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,201 +1,221 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-install</command>
|
||||||
<refentrytitle><command>nixos-install</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-install</command>
|
||||||
<refname><command>nixos-install</command></refname>
|
</refname><refpurpose>install bootloader and NixOS</refpurpose>
|
||||||
<refpurpose>install bootloader and NixOS</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-install</command>
|
||||||
<refsynopsisdiv>
|
<arg>
|
||||||
<cmdsynopsis>
|
<arg choice='plain'><option>-I</option>
|
||||||
<command>nixos-install</command>
|
</arg><replaceable>path</replaceable>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>-I</option></arg>
|
<arg>
|
||||||
<replaceable>path</replaceable>
|
<arg choice='plain'><option>--root</option>
|
||||||
|
</arg><replaceable>root</replaceable>
|
||||||
|
</arg>
|
||||||
|
<arg>
|
||||||
|
<arg choice='plain'><option>--system</option>
|
||||||
|
</arg><replaceable>path</replaceable>
|
||||||
|
</arg>
|
||||||
|
<arg>
|
||||||
|
<arg choice='plain'><option>--no-channel-copy</option>
|
||||||
</arg>
|
</arg>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>--root</option></arg>
|
<arg>
|
||||||
<replaceable>root</replaceable>
|
<arg choice='plain'><option>--no-root-passwd</option>
|
||||||
</arg>
|
</arg>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>--system</option></arg>
|
<arg>
|
||||||
<replaceable>path</replaceable>
|
<arg choice='plain'><option>--no-bootloader</option>
|
||||||
</arg>
|
</arg>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>--no-channel-copy</option></arg>
|
<arg><group choice='req'>
|
||||||
|
<arg choice='plain'><option>--max-jobs</option>
|
||||||
</arg>
|
</arg>
|
||||||
<arg>
|
<arg choice='plain'><option>-j</option>
|
||||||
<arg choice='plain'><option>--no-root-passwd</option></arg>
|
</arg></group><replaceable>number</replaceable>
|
||||||
|
</arg>
|
||||||
|
<arg><option>--cores</option><replaceable>number</replaceable>
|
||||||
|
</arg>
|
||||||
|
<arg><option>--option</option><replaceable>name</replaceable><replaceable>value</replaceable>
|
||||||
|
</arg>
|
||||||
|
<arg>
|
||||||
|
<arg choice='plain'><option>--show-trace</option>
|
||||||
</arg>
|
</arg>
|
||||||
<arg>
|
</arg>
|
||||||
<arg choice='plain'><option>--no-bootloader</option></arg>
|
<arg>
|
||||||
</arg>
|
<arg choice='plain'><option>--help</option>
|
||||||
<arg>
|
|
||||||
<group choice='req'>
|
|
||||||
<arg choice='plain'><option>--max-jobs</option></arg>
|
|
||||||
<arg choice='plain'><option>-j</option></arg>
|
|
||||||
</group>
|
|
||||||
<replaceable>number</replaceable>
|
|
||||||
</arg>
|
|
||||||
<arg>
|
|
||||||
<option>--cores</option>
|
|
||||||
<replaceable>number</replaceable>
|
|
||||||
</arg>
|
|
||||||
<arg>
|
|
||||||
<option>--option</option>
|
|
||||||
<replaceable>name</replaceable>
|
|
||||||
<replaceable>value</replaceable>
|
|
||||||
</arg>
|
|
||||||
<arg>
|
|
||||||
<arg choice='plain'><option>--show-trace</option></arg>
|
|
||||||
</arg>
|
|
||||||
<arg>
|
|
||||||
<arg choice='plain'><option>--help</option></arg>
|
|
||||||
</arg>
|
</arg>
|
||||||
|
</arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
|
<title>Description</title>
|
||||||
<refsection><title>Description</title>
|
<para>
|
||||||
|
This command installs NixOS in the file system mounted on
|
||||||
<para>This command installs NixOS in the file system mounted on
|
<filename>/mnt</filename>, based on the NixOS configuration specified in
|
||||||
<filename>/mnt</filename>, based on the NixOS configuration specified
|
<filename>/mnt/etc/nixos/configuration.nix</filename>. It performs the
|
||||||
in <filename>/mnt/etc/nixos/configuration.nix</filename>. It performs
|
following steps:
|
||||||
the following steps:
|
<itemizedlist>
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
<listitem><para>It copies Nix and its dependencies to
|
|
||||||
<filename>/mnt/nix/store</filename>.</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>It runs Nix in <filename>/mnt</filename> to build
|
|
||||||
the NixOS configuration specified in
|
|
||||||
<filename>/mnt/etc/nixos/configuration.nix</filename>.</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>It installs the GRUB boot loader on the device
|
|
||||||
specified in the option <option>boot.loader.grub.device</option>
|
|
||||||
(unless <option>--no-bootloader</option> is specified),
|
|
||||||
and generates a GRUB configuration file that boots into the NixOS
|
|
||||||
configuration just installed.</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>It prompts you for a password for the root account
|
|
||||||
(unless <option>--no-root-passwd</option> is specified).</para></listitem>
|
|
||||||
|
|
||||||
</itemizedlist>
|
|
||||||
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>This command is idempotent: if it is interrupted or fails due to
|
|
||||||
a temporary problem (e.g. a network issue), you can safely re-run
|
|
||||||
it.</para>
|
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
<refsection><title>Options</title>
|
|
||||||
|
|
||||||
<para>This command accepts the following options:</para>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>--root</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Defaults to <filename>/mnt</filename>. If this option is given, treat the directory
|
<para>
|
||||||
<replaceable>root</replaceable> as the root of the NixOS installation.
|
It copies Nix and its dependencies to
|
||||||
</para>
|
<filename>/mnt/nix/store</filename>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>--system</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>If this option is provided, <command>nixos-install</command> will install the specified closure
|
<para>
|
||||||
rather than attempt to build one from <filename>/mnt/etc/nixos/configuration.nix</filename>.</para>
|
It runs Nix in <filename>/mnt</filename> to build the NixOS configuration
|
||||||
|
specified in <filename>/mnt/etc/nixos/configuration.nix</filename>.
|
||||||
<para>The closure must be an appropriately configured NixOS system, with boot loader and partition
|
</para>
|
||||||
configuration that fits the target host. Such a closure is typically obtained with a command such as
|
|
||||||
<command>nix-build -I nixos-config=./configuration.nix '<nixos>' -A system --no-out-link</command>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>-I</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Add a path to the Nix expression search path. This option may be given multiple times.
|
<para>
|
||||||
See the NIX_PATH environment variable for information on the semantics of the Nix search path.
|
It installs the GRUB boot loader on the device specified in the option
|
||||||
Paths added through <replaceable>-I</replaceable> take precedence over NIX_PATH.</para>
|
<option>boot.loader.grub.device</option> (unless
|
||||||
|
<option>--no-bootloader</option> is specified), and generates a GRUB
|
||||||
|
configuration file that boots into the NixOS configuration just
|
||||||
|
installed.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term><option>--max-jobs</option></term>
|
|
||||||
<term><option>-j</option></term>
|
|
||||||
|
|
||||||
<listitem><para>Sets the maximum number of build jobs that Nix will
|
|
||||||
perform in parallel to the specified number. The default is <literal>1</literal>.
|
|
||||||
A higher value is useful on SMP systems or to exploit I/O latency.</para></listitem>
|
|
||||||
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
|
|
||||||
<varlistentry><term><option>--cores</option></term>
|
|
||||||
|
|
||||||
<listitem><para>Sets the value of the <envar>NIX_BUILD_CORES</envar>
|
|
||||||
environment variable in the invocation of builders. Builders can
|
|
||||||
use this variable at their discretion to control the maximum amount
|
|
||||||
of parallelism. For instance, in Nixpkgs, if the derivation
|
|
||||||
attribute <varname>enableParallelBuilding</varname> is set to
|
|
||||||
<literal>true</literal>, the builder passes the
|
|
||||||
<option>-j<replaceable>N</replaceable></option> flag to GNU Make.
|
|
||||||
The value <literal>0</literal> means that the builder should use all
|
|
||||||
available CPU cores in the system.</para></listitem>
|
|
||||||
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term><option>--option</option> <replaceable>name</replaceable> <replaceable>value</replaceable></term>
|
|
||||||
|
|
||||||
<listitem><para>Set the Nix configuration option
|
|
||||||
<replaceable>name</replaceable> to <replaceable>value</replaceable>.</para></listitem>
|
|
||||||
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>--show-trace</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Causes Nix to print out a stack trace in case of Nix expression evaluation errors.</para>
|
<para>
|
||||||
|
It prompts you for a password for the root account (unless
|
||||||
|
<option>--no-root-passwd</option> is specified).
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
<varlistentry>
|
<para>
|
||||||
<term><option>--help</option></term>
|
This command is idempotent: if it is interrupted or fails due to a temporary
|
||||||
|
problem (e.g. a network issue), you can safely re-run it.
|
||||||
|
</para>
|
||||||
|
</refsection>
|
||||||
|
<refsection>
|
||||||
|
<title>Options</title>
|
||||||
|
<para>
|
||||||
|
This command accepts the following options:
|
||||||
|
</para>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--root</option>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Synonym for <command>man nixos-install</command>.</para>
|
<para>
|
||||||
|
Defaults to <filename>/mnt</filename>. If this option is given, treat the
|
||||||
|
directory <replaceable>root</replaceable> as the root of the NixOS
|
||||||
|
installation.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
</variablelist>
|
<term><option>--system</option>
|
||||||
|
</term>
|
||||||
</refsection>
|
<listitem>
|
||||||
|
<para>
|
||||||
|
If this option is provided, <command>nixos-install</command> will install
|
||||||
<refsection><title>Examples</title>
|
the specified closure rather than attempt to build one from
|
||||||
|
<filename>/mnt/etc/nixos/configuration.nix</filename>.
|
||||||
<para>A typical NixOS installation is done by creating and mounting a
|
</para>
|
||||||
file system on <filename>/mnt</filename>, generating a NixOS
|
<para>
|
||||||
configuration in
|
The closure must be an appropriately configured NixOS system, with boot
|
||||||
<filename>/mnt/etc/nixos/configuration.nix</filename>, and running
|
loader and partition configuration that fits the target host. Such a
|
||||||
<command>nixos-install</command>. For instance, if we want to install
|
closure is typically obtained with a command such as <command>nix-build
|
||||||
NixOS on an <literal>ext4</literal> file system created in
|
-I nixos-config=./configuration.nix '<nixos>' -A system
|
||||||
<filename>/dev/sda1</filename>:
|
--no-out-link</command>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>-I</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Add a path to the Nix expression search path. This option may be given
|
||||||
|
multiple times. See the NIX_PATH environment variable for information on
|
||||||
|
the semantics of the Nix search path. Paths added through
|
||||||
|
<replaceable>-I</replaceable> take precedence over NIX_PATH.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--max-jobs</option>
|
||||||
|
</term>
|
||||||
|
<term><option>-j</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Sets the maximum number of build jobs that Nix will perform in parallel
|
||||||
|
to the specified number. The default is <literal>1</literal>. A higher
|
||||||
|
value is useful on SMP systems or to exploit I/O latency.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--cores</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Sets the value of the <envar>NIX_BUILD_CORES</envar> environment variable
|
||||||
|
in the invocation of builders. Builders can use this variable at their
|
||||||
|
discretion to control the maximum amount of parallelism. For instance, in
|
||||||
|
Nixpkgs, if the derivation attribute
|
||||||
|
<varname>enableParallelBuilding</varname> is set to
|
||||||
|
<literal>true</literal>, the builder passes the
|
||||||
|
<option>-j<replaceable>N</replaceable></option> flag to GNU Make. The
|
||||||
|
value <literal>0</literal> means that the builder should use all
|
||||||
|
available CPU cores in the system.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--option</option><replaceable>name</replaceable><replaceable>value</replaceable>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Set the Nix configuration option <replaceable>name</replaceable> to
|
||||||
|
<replaceable>value</replaceable>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--show-trace</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Causes Nix to print out a stack trace in case of Nix expression
|
||||||
|
evaluation errors.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--help</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Synonym for <command>man nixos-install</command>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</refsection>
|
||||||
|
<refsection>
|
||||||
|
<title>Examples</title>
|
||||||
|
<para>
|
||||||
|
A typical NixOS installation is done by creating and mounting a file system
|
||||||
|
on <filename>/mnt</filename>, generating a NixOS configuration in
|
||||||
|
<filename>/mnt/etc/nixos/configuration.nix</filename>, and running
|
||||||
|
<command>nixos-install</command>. For instance, if we want to install NixOS
|
||||||
|
on an <literal>ext4</literal> file system created in
|
||||||
|
<filename>/dev/sda1</filename>:
|
||||||
<screen>
|
<screen>
|
||||||
$ mkfs.ext4 /dev/sda1
|
$ mkfs.ext4 /dev/sda1
|
||||||
$ mount /dev/sda1 /mnt
|
$ mount /dev/sda1 /mnt
|
||||||
@ -204,9 +224,6 @@ $ # edit /mnt/etc/nixos/configuration.nix
|
|||||||
$ nixos-install
|
$ nixos-install
|
||||||
$ reboot
|
$ reboot
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para>
|
</refsection>
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,103 +1,96 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-option</command>
|
||||||
<refentrytitle><command>nixos-option</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-option</command>
|
||||||
<refname><command>nixos-option</command></refname>
|
</refname><refpurpose>inspect a NixOS configuration</refpurpose>
|
||||||
<refpurpose>inspect a NixOS configuration</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-option</command>
|
||||||
<refsynopsisdiv>
|
<arg><option>-I</option><replaceable>path</replaceable>
|
||||||
<cmdsynopsis>
|
</arg>
|
||||||
<command>nixos-option</command>
|
<arg><option>--verbose</option>
|
||||||
<arg>
|
</arg>
|
||||||
<option>-I</option>
|
<arg><option>--xml</option>
|
||||||
<replaceable>path</replaceable>
|
</arg>
|
||||||
</arg>
|
<arg choice="plain"><replaceable>option.name</replaceable>
|
||||||
<arg><option>--verbose</option></arg>
|
</arg>
|
||||||
<arg><option>--xml</option></arg>
|
|
||||||
<arg choice="plain"><replaceable>option.name</replaceable></arg>
|
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
<refsection><title>Description</title>
|
<title>Description</title>
|
||||||
|
<para>
|
||||||
<para>This command evaluates the configuration specified in
|
This command evaluates the configuration specified in
|
||||||
<filename>/etc/nixos/configuration.nix</filename> and returns the properties
|
<filename>/etc/nixos/configuration.nix</filename> and returns the properties
|
||||||
of the option name given as argument.</para>
|
of the option name given as argument.
|
||||||
|
</para>
|
||||||
<para>When the option name is not an option, the command prints the list of
|
<para>
|
||||||
attributes contained in the attribute set.</para>
|
When the option name is not an option, the command prints the list of
|
||||||
|
attributes contained in the attribute set.
|
||||||
</refsection>
|
</para>
|
||||||
|
</refsection>
|
||||||
<refsection><title>Options</title>
|
<refsection>
|
||||||
|
<title>Options</title>
|
||||||
<para>This command accepts the following options:</para>
|
<para>
|
||||||
|
This command accepts the following options:
|
||||||
<variablelist>
|
</para>
|
||||||
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><option>-I</option> <replaceable>path</replaceable></term>
|
<term><option>-I</option><replaceable>path</replaceable>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This option is passed to the underlying
|
This option is passed to the underlying
|
||||||
<command>nix-instantiate</command> invocation.
|
<command>nix-instantiate</command> invocation.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--verbose</option>
|
||||||
<term><option>--verbose</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This option enables verbose mode, which currently is just
|
This option enables verbose mode, which currently is just the Bash
|
||||||
the Bash <command>set</command> <option>-x</option> debug mode.
|
<command>set</command> <option>-x</option> debug mode.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--xml</option>
|
||||||
<term><option>--xml</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This option causes the output to be rendered as XML.
|
This option causes the output to be rendered as XML.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</variablelist>
|
</refsection>
|
||||||
|
<refsection>
|
||||||
</refsection>
|
<title>Environment</title>
|
||||||
|
<variablelist>
|
||||||
<refsection><title>Environment</title>
|
<varlistentry>
|
||||||
|
<term><envar>NIXOS_CONFIG</envar>
|
||||||
<variablelist>
|
</term>
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><envar>NIXOS_CONFIG</envar></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Path to the main NixOS configuration module. Defaults to
|
<para>
|
||||||
<filename>/etc/nixos/configuration.nix</filename>.</para>
|
Path to the main NixOS configuration module. Defaults to
|
||||||
|
<filename>/etc/nixos/configuration.nix</filename>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</variablelist>
|
</refsection>
|
||||||
|
<refsection>
|
||||||
</refsection>
|
<title>Examples</title>
|
||||||
|
<para>
|
||||||
|
Investigate option values:
|
||||||
<refsection><title>Examples</title>
|
|
||||||
|
|
||||||
<para>Investigate option values:
|
|
||||||
|
|
||||||
<screen>$ nixos-option boot.loader
|
<screen>$ nixos-option boot.loader
|
||||||
This attribute set contains:
|
This attribute set contains:
|
||||||
generationsDir
|
generationsDir
|
||||||
@ -119,16 +112,14 @@ Declared by:
|
|||||||
|
|
||||||
Defined by:
|
Defined by:
|
||||||
"/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/loader/grub/grub.nix"
|
"/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/loader/grub/grub.nix"
|
||||||
</screen></para>
|
</screen>
|
||||||
|
</para>
|
||||||
</refsection>
|
</refsection>
|
||||||
|
<refsection>
|
||||||
<refsection><title>Bugs</title>
|
<title>Bugs</title>
|
||||||
|
<para>
|
||||||
<para>The author listed in the following section is wrong. If there is any
|
The author listed in the following section is wrong. If there is any other
|
||||||
other bug, please report to Nicolas Pierron.</para>
|
bug, please report to Nicolas Pierron.
|
||||||
|
</para>
|
||||||
</refsection>
|
</refsection>
|
||||||
|
|
||||||
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,399 +1,415 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-rebuild</command>
|
||||||
<refentrytitle><command>nixos-rebuild</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-rebuild</command>
|
||||||
<refname><command>nixos-rebuild</command></refname>
|
</refname><refpurpose>reconfigure a NixOS machine</refpurpose>
|
||||||
<refpurpose>reconfigure a NixOS machine</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-rebuild</command><group choice='req'>
|
||||||
<refsynopsisdiv>
|
<arg choice='plain'><option>switch</option>
|
||||||
<cmdsynopsis>
|
</arg>
|
||||||
<command>nixos-rebuild</command>
|
<arg choice='plain'><option>boot</option>
|
||||||
<group choice='req'>
|
</arg>
|
||||||
<arg choice='plain'><option>switch</option></arg>
|
<arg choice='plain'><option>test</option>
|
||||||
<arg choice='plain'><option>boot</option></arg>
|
</arg>
|
||||||
<arg choice='plain'><option>test</option></arg>
|
<arg choice='plain'><option>build</option>
|
||||||
<arg choice='plain'><option>build</option></arg>
|
</arg>
|
||||||
<arg choice='plain'><option>dry-build</option></arg>
|
<arg choice='plain'><option>dry-build</option>
|
||||||
<arg choice='plain'><option>dry-activate</option></arg>
|
</arg>
|
||||||
<arg choice='plain'><option>build-vm</option></arg>
|
<arg choice='plain'><option>dry-activate</option>
|
||||||
<arg choice='plain'><option>build-vm-with-bootloader</option></arg>
|
</arg>
|
||||||
</group>
|
<arg choice='plain'><option>build-vm</option>
|
||||||
<sbr />
|
</arg>
|
||||||
<arg><option>--upgrade</option></arg>
|
<arg choice='plain'><option>build-vm-with-bootloader</option>
|
||||||
<arg><option>--install-bootloader</option></arg>
|
</arg></group>
|
||||||
<arg><option>--no-build-nix</option></arg>
|
<sbr />
|
||||||
<arg><option>--fast</option></arg>
|
<arg><option>--upgrade</option>
|
||||||
<arg><option>--rollback</option></arg>
|
</arg>
|
||||||
<sbr />
|
<arg><option>--install-bootloader</option>
|
||||||
<arg>
|
</arg>
|
||||||
<group choice='req'>
|
<arg><option>--no-build-nix</option>
|
||||||
<arg choice='plain'><option>--profile-name</option></arg>
|
</arg>
|
||||||
<arg choice='plain'><option>-p</option></arg>
|
<arg><option>--fast</option>
|
||||||
</group>
|
</arg>
|
||||||
<replaceable>name</replaceable>
|
<arg><option>--rollback</option>
|
||||||
|
</arg>
|
||||||
|
<sbr />
|
||||||
|
<arg><group choice='req'>
|
||||||
|
<arg choice='plain'><option>--profile-name</option>
|
||||||
</arg>
|
</arg>
|
||||||
<sbr />
|
<arg choice='plain'><option>-p</option>
|
||||||
<arg><option>--show-trace</option></arg>
|
</arg></group><replaceable>name</replaceable>
|
||||||
|
</arg>
|
||||||
|
<sbr />
|
||||||
|
<arg><option>--show-trace</option>
|
||||||
|
</arg>
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
|
<title>Description</title>
|
||||||
<refsection><title>Description</title>
|
<para>
|
||||||
|
This command updates the system so that it corresponds to the configuration
|
||||||
<para>This command updates the system so that it corresponds to the
|
specified in <filename>/etc/nixos/configuration.nix</filename>. Thus, every
|
||||||
configuration specified in
|
time you modify <filename>/etc/nixos/configuration.nix</filename> or any
|
||||||
<filename>/etc/nixos/configuration.nix</filename>. Thus, every time
|
NixOS module, you must run <command>nixos-rebuild</command> to make the
|
||||||
you modify <filename>/etc/nixos/configuration.nix</filename> or any
|
changes take effect. It builds the new system in
|
||||||
NixOS module, you must run <command>nixos-rebuild</command> to make
|
<filename>/nix/store</filename>, runs its activation script, and stop and
|
||||||
the changes take effect. It builds the new system in
|
(re)starts any system services if needed.
|
||||||
<filename>/nix/store</filename>, runs its activation script, and stop
|
</para>
|
||||||
and (re)starts any system services if needed.</para>
|
<para>
|
||||||
|
This command has one required argument, which specifies the desired
|
||||||
<para>This command has one required argument, which specifies the
|
operation. It must be one of the following:
|
||||||
desired operation. It must be one of the following:
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><option>switch</option>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
<listitem>
|
||||||
<term><option>switch</option></term>
|
<para>
|
||||||
<listitem>
|
Build and activate the new configuration, and make it the boot default.
|
||||||
<para>Build and activate the new configuration, and make it the
|
That is, the configuration is added to the GRUB boot menu as the default
|
||||||
boot default. That is, the configuration is added to the GRUB
|
menu entry, so that subsequent reboots will boot the system into the new
|
||||||
boot menu as the default menu entry, so that subsequent reboots
|
configuration. Previous configurations activated with
|
||||||
will boot the system into the new configuration. Previous
|
<command>nixos-rebuild switch</command> or <command>nixos-rebuild
|
||||||
configurations activated with <command>nixos-rebuild
|
boot</command> remain available in the GRUB menu.
|
||||||
switch</command> or <command>nixos-rebuild boot</command> remain
|
</para>
|
||||||
available in the GRUB menu.</para>
|
</listitem>
|
||||||
</listitem>
|
</varlistentry>
|
||||||
</varlistentry>
|
<varlistentry>
|
||||||
|
<term><option>boot</option>
|
||||||
<varlistentry>
|
</term>
|
||||||
<term><option>boot</option></term>
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Build the new configuration and make it the boot default
|
Build the new configuration and make it the boot default (as with
|
||||||
(as with <command>nixos-rebuild switch</command>), but do not
|
<command>nixos-rebuild switch</command>), but do not activate it. That
|
||||||
activate it. That is, the system continues to run the previous
|
is, the system continues to run the previous configuration until the
|
||||||
configuration until the next reboot.</para>
|
next reboot.
|
||||||
</listitem>
|
</para>
|
||||||
</varlistentry>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><option>test</option></term>
|
<term><option>test</option>
|
||||||
<listitem>
|
</term>
|
||||||
<para>Build and activate the new configuration, but do not add
|
<listitem>
|
||||||
it to the GRUB boot menu. Thus, if you reboot the system (or if
|
<para>
|
||||||
it crashes), you will automatically revert to the default
|
Build and activate the new configuration, but do not add it to the GRUB
|
||||||
configuration (i.e. the configuration resulting from the last
|
boot menu. Thus, if you reboot the system (or if it crashes), you will
|
||||||
call to <command>nixos-rebuild switch</command> or
|
automatically revert to the default configuration (i.e. the
|
||||||
<command>nixos-rebuild boot</command>).</para>
|
configuration resulting from the last call to <command>nixos-rebuild
|
||||||
</listitem>
|
switch</command> or <command>nixos-rebuild boot</command>).
|
||||||
</varlistentry>
|
</para>
|
||||||
|
</listitem>
|
||||||
<varlistentry>
|
</varlistentry>
|
||||||
<term><option>build</option></term>
|
<varlistentry>
|
||||||
<listitem>
|
<term><option>build</option>
|
||||||
<para>Build the new configuration, but neither activate it nor
|
</term>
|
||||||
add it to the GRUB boot menu. It leaves a symlink named
|
<listitem>
|
||||||
<filename>result</filename> in the current directory, which
|
<para>
|
||||||
points to the output of the top-level “system” derivation. This
|
Build the new configuration, but neither activate it nor add it to the
|
||||||
is essentially the same as doing
|
GRUB boot menu. It leaves a symlink named <filename>result</filename> in
|
||||||
|
the current directory, which points to the output of the top-level
|
||||||
|
“system” derivation. This is essentially the same as doing
|
||||||
<screen>
|
<screen>
|
||||||
$ nix-build /path/to/nixpkgs/nixos -A system
|
$ nix-build /path/to/nixpkgs/nixos -A system
|
||||||
</screen>
|
</screen>
|
||||||
Note that you do not need to be <literal>root</literal> to run
|
Note that you do not need to be <literal>root</literal> to run
|
||||||
<command>nixos-rebuild build</command>.</para>
|
<command>nixos-rebuild build</command>.
|
||||||
</listitem>
|
</para>
|
||||||
</varlistentry>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><option>dry-build</option></term>
|
<term><option>dry-build</option>
|
||||||
<listitem>
|
</term>
|
||||||
<para>Show what store paths would be built or downloaded by any
|
<listitem>
|
||||||
of the operations above, but otherwise do nothing.</para>
|
<para>
|
||||||
</listitem>
|
Show what store paths would be built or downloaded by any of the
|
||||||
</varlistentry>
|
operations above, but otherwise do nothing.
|
||||||
|
</para>
|
||||||
<varlistentry>
|
</listitem>
|
||||||
<term><option>dry-activate</option></term>
|
</varlistentry>
|
||||||
<listitem>
|
<varlistentry>
|
||||||
<para>Build the new configuration, but instead of activating it,
|
<term><option>dry-activate</option>
|
||||||
show what changes would be performed by the activation (i.e. by
|
</term>
|
||||||
<command>nixos-rebuild test</command>). For
|
<listitem>
|
||||||
instance, this command will print which systemd units would be
|
<para>
|
||||||
restarted. The list of changes is not guaranteed to be
|
Build the new configuration, but instead of activating it, show what
|
||||||
complete.</para>
|
changes would be performed by the activation (i.e. by
|
||||||
</listitem>
|
<command>nixos-rebuild test</command>). For instance, this command will
|
||||||
</varlistentry>
|
print which systemd units would be restarted. The list of changes is not
|
||||||
|
guaranteed to be complete.
|
||||||
<varlistentry>
|
</para>
|
||||||
<term><option>build-vm</option></term>
|
</listitem>
|
||||||
<listitem>
|
</varlistentry>
|
||||||
<para>Build a script that starts a NixOS virtual machine with
|
<varlistentry>
|
||||||
the desired configuration. It leaves a symlink
|
<term><option>build-vm</option>
|
||||||
<filename>result</filename> in the current directory that points
|
</term>
|
||||||
(under
|
<listitem>
|
||||||
<filename>result/bin/run-<replaceable>hostname</replaceable>-vm</filename>)
|
<para>
|
||||||
at the script that starts the VM. Thus, to test a NixOS
|
Build a script that starts a NixOS virtual machine with the desired
|
||||||
configuration in a virtual machine, you should do the following:
|
configuration. It leaves a symlink <filename>result</filename> in the
|
||||||
|
current directory that points (under
|
||||||
|
<filename>result/bin/run-<replaceable>hostname</replaceable>-vm</filename>)
|
||||||
|
at the script that starts the VM. Thus, to test a NixOS configuration in
|
||||||
|
a virtual machine, you should do the following:
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-rebuild build-vm
|
$ nixos-rebuild build-vm
|
||||||
$ ./result/bin/run-*-vm
|
$ ./result/bin/run-*-vm
|
||||||
</screen></para>
|
</screen>
|
||||||
|
|
||||||
<para>The VM is implemented using the <literal>qemu</literal>
|
|
||||||
package. For best performance, you should load the
|
|
||||||
<literal>kvm-intel</literal> or <literal>kvm-amd</literal>
|
|
||||||
kernel modules to get hardware virtualisation.</para>
|
|
||||||
|
|
||||||
<para>The VM mounts the Nix store of the host through the 9P
|
|
||||||
file system. The host Nix store is read-only, so Nix commands
|
|
||||||
that modify the Nix store will not work in the VM. This
|
|
||||||
includes commands such as <command>nixos-rebuild</command>; to
|
|
||||||
change the VM’s configuration, you must halt the VM and re-run
|
|
||||||
the commands above.
|
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>The VM has its own <literal>ext3</literal> root file
|
The VM is implemented using the <literal>qemu</literal> package. For
|
||||||
system, which is automatically created when the VM is first
|
best performance, you should load the <literal>kvm-intel</literal> or
|
||||||
started, and is persistent across reboots of the VM. It is
|
<literal>kvm-amd</literal> kernel modules to get hardware
|
||||||
stored in
|
virtualisation.
|
||||||
<literal>./<replaceable>hostname</replaceable>.qcow2</literal>.
|
|
||||||
<!-- The entire file system hierarchy of the host is available in
|
|
||||||
the VM under <filename>/hostfs</filename>.--></para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>build-vm-with-bootloader</option></term>
|
|
||||||
<listitem>
|
|
||||||
<para>Like <option>build-vm</option>, but boots using the
|
|
||||||
regular boot loader of your configuration (e.g., GRUB 1 or 2),
|
|
||||||
rather than booting directly into the kernel and initial ramdisk
|
|
||||||
of the system. This allows you to test whether the boot loader
|
|
||||||
works correctly. However, it does not guarantee that your NixOS
|
|
||||||
configuration will boot successfully on the host hardware (i.e.,
|
|
||||||
after running <command>nixos-rebuild switch</command>), because
|
|
||||||
the hardware and boot loader configuration in the VM are
|
|
||||||
different. The boot loader is installed on an automatically
|
|
||||||
generated virtual disk containing a <filename>/boot</filename>
|
|
||||||
partition, which is mounted read-only in the VM.</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
</variablelist>
|
|
||||||
|
|
||||||
</para>
|
|
||||||
|
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
|
|
||||||
<refsection><title>Options</title>
|
|
||||||
|
|
||||||
<para>This command accepts the following options:</para>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>--upgrade</option></term>
|
|
||||||
<listitem>
|
|
||||||
<para>Fetch the latest version of NixOS from the NixOS
|
|
||||||
channel.</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><option>--install-bootloader</option></term>
|
|
||||||
<listitem>
|
|
||||||
<para>Causes the boot loader to be (re)installed on the
|
|
||||||
device specified by the relevant configuration options.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
<para>
|
||||||
</varlistentry>
|
The VM mounts the Nix store of the host through the 9P file system. The
|
||||||
|
host Nix store is read-only, so Nix commands that modify the Nix store
|
||||||
<varlistentry>
|
will not work in the VM. This includes commands such as
|
||||||
<term><option>--no-build-nix</option></term>
|
<command>nixos-rebuild</command>; to change the VM’s configuration,
|
||||||
|
you must halt the VM and re-run the commands above.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The VM has its own <literal>ext3</literal> root file system, which is
|
||||||
|
automatically created when the VM is first started, and is persistent
|
||||||
|
across reboots of the VM. It is stored in
|
||||||
|
<literal>./<replaceable>hostname</replaceable>.qcow2</literal>.
|
||||||
|
<!-- The entire file system hierarchy of the host is available in
|
||||||
|
the VM under <filename>/hostfs</filename>.-->
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>build-vm-with-bootloader</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Like <option>build-vm</option>, but boots using the regular boot loader
|
||||||
|
of your configuration (e.g., GRUB 1 or 2), rather than booting directly
|
||||||
|
into the kernel and initial ramdisk of the system. This allows you to
|
||||||
|
test whether the boot loader works correctly. However, it does not
|
||||||
|
guarantee that your NixOS configuration will boot successfully on the
|
||||||
|
host hardware (i.e., after running <command>nixos-rebuild
|
||||||
|
switch</command>), because the hardware and boot loader configuration in
|
||||||
|
the VM are different. The boot loader is installed on an automatically
|
||||||
|
generated virtual disk containing a <filename>/boot</filename>
|
||||||
|
partition, which is mounted read-only in the VM.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
|
</para>
|
||||||
|
</refsection>
|
||||||
|
<refsection>
|
||||||
|
<title>Options</title>
|
||||||
|
<para>
|
||||||
|
This command accepts the following options:
|
||||||
|
</para>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--upgrade</option>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Normally, <command>nixos-rebuild</command> first builds
|
<para>
|
||||||
the <varname>nixUnstable</varname> attribute in Nixpkgs, and
|
Fetch the latest version of NixOS from the NixOS channel.
|
||||||
uses the resulting instance of the Nix package manager to build
|
</para>
|
||||||
the new system configuration. This is necessary if the NixOS
|
|
||||||
modules use features not provided by the currently installed
|
|
||||||
version of Nix. This option disables building a new Nix.</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--install-bootloader</option>
|
||||||
<term><option>--fast</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Equivalent to <option>--no-build-nix</option>
|
<para>
|
||||||
<option>--show-trace</option>. This option is useful if you
|
Causes the boot loader to be (re)installed on the device specified by the
|
||||||
call <command>nixos-rebuild</command> frequently (e.g. if you’re
|
relevant configuration options.
|
||||||
hacking on a NixOS module).</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--no-build-nix</option>
|
||||||
<term><option>--rollback</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Instead of building a new configuration as specified by
|
<para>
|
||||||
<filename>/etc/nixos/configuration.nix</filename>, roll back to
|
Normally, <command>nixos-rebuild</command> first builds the
|
||||||
the previous configuration. (The previous configuration is
|
<varname>nixUnstable</varname> attribute in Nixpkgs, and uses the
|
||||||
defined as the one before the “current” generation of the
|
resulting instance of the Nix package manager to build the new system
|
||||||
Nix profile <filename>/nix/var/nix/profiles/system</filename>.)</para>
|
configuration. This is necessary if the NixOS modules use features not
|
||||||
|
provided by the currently installed version of Nix. This option disables
|
||||||
|
building a new Nix.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--fast</option>
|
||||||
<term><option>--profile-name</option></term>
|
</term>
|
||||||
<term><option>-p</option></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Instead of using the Nix profile
|
<para>
|
||||||
<filename>/nix/var/nix/profiles/system</filename> to keep track
|
Equivalent to <option>--no-build-nix</option>
|
||||||
of the current and previous system configurations, use
|
<option>--show-trace</option>. This option is useful if you call
|
||||||
|
<command>nixos-rebuild</command> frequently (e.g. if you’re hacking on
|
||||||
|
a NixOS module).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--rollback</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Instead of building a new configuration as specified by
|
||||||
|
<filename>/etc/nixos/configuration.nix</filename>, roll back to the
|
||||||
|
previous configuration. (The previous configuration is defined as the one
|
||||||
|
before the “current” generation of the Nix profile
|
||||||
|
<filename>/nix/var/nix/profiles/system</filename>.)
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--profile-name</option>
|
||||||
|
</term>
|
||||||
|
<term><option>-p</option>
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Instead of using the Nix profile
|
||||||
|
<filename>/nix/var/nix/profiles/system</filename> to keep track of the
|
||||||
|
current and previous system configurations, use
|
||||||
<filename>/nix/var/nix/profiles/system-profiles/<replaceable>name</replaceable></filename>.
|
<filename>/nix/var/nix/profiles/system-profiles/<replaceable>name</replaceable></filename>.
|
||||||
When you use GRUB 2, for every system profile created with this
|
When you use GRUB 2, for every system profile created with this flag,
|
||||||
flag, NixOS will create a submenu named “NixOS - Profile
|
NixOS will create a submenu named “NixOS - Profile
|
||||||
'<replaceable>name</replaceable>'” in GRUB’s boot menu,
|
'<replaceable>name</replaceable>'” in GRUB’s boot menu, containing
|
||||||
containing the current and previous configurations of this
|
the current and previous configurations of this profile.
|
||||||
profile.</para>
|
</para>
|
||||||
|
<para>
|
||||||
<para>For instance, if you want to test a configuration file
|
For instance, if you want to test a configuration file named
|
||||||
named <filename>test.nix</filename> without affecting the
|
<filename>test.nix</filename> without affecting the default system
|
||||||
default system profile, you would do:
|
profile, you would do:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
$ nixos-rebuild switch -p test -I nixos-config=./test.nix
|
$ nixos-rebuild switch -p test -I nixos-config=./test.nix
|
||||||
</screen>
|
</screen>
|
||||||
|
The new configuration will appear in the GRUB 2 submenu “NixOS -
|
||||||
The new configuration will appear in the GRUB 2 submenu “NixOS - Profile
|
Profile 'test'”.
|
||||||
'test'”.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--build-host</option>
|
||||||
<term><option>--build-host</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Instead of building the new configuration locally, use the
|
<para>
|
||||||
specified host to perform the build. The host needs to be accessible
|
Instead of building the new configuration locally, use the specified host
|
||||||
with ssh, and must be able to perform Nix builds. If the option
|
to perform the build. The host needs to be accessible with ssh, and must
|
||||||
|
be able to perform Nix builds. If the option
|
||||||
<option>--target-host</option> is not set, the build will be copied back
|
<option>--target-host</option> is not set, the build will be copied back
|
||||||
to the local machine when done.</para>
|
to the local machine when done.
|
||||||
|
</para>
|
||||||
<para>Note that, if <option>--no-build-nix</option> is not specified,
|
<para>
|
||||||
Nix will be built both locally and remotely. This is because the
|
Note that, if <option>--no-build-nix</option> is not specified, Nix will
|
||||||
configuration will always be evaluated locally even though the building
|
be built both locally and remotely. This is because the configuration
|
||||||
might be performed remotely.</para>
|
will always be evaluated locally even though the building might be
|
||||||
|
performed remotely.
|
||||||
<para>You can include a remote user name in
|
</para>
|
||||||
the host name (<replaceable>user@host</replaceable>). You can also set
|
<para>
|
||||||
ssh options by defining the <envar>NIX_SSHOPTS</envar> environment
|
You can include a remote user name in the host name
|
||||||
variable.</para>
|
(<replaceable>user@host</replaceable>). You can also set ssh options by
|
||||||
|
defining the <envar>NIX_SSHOPTS</envar> environment variable.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry>
|
<term><option>--target-host</option>
|
||||||
<term><option>--target-host</option></term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Specifies the NixOS target host. By setting this to something other
|
<para>
|
||||||
than <replaceable>localhost</replaceable>, the system activation will
|
Specifies the NixOS target host. By setting this to something other than
|
||||||
happen on the remote host instead of the local machine. The remote host
|
<replaceable>localhost</replaceable>, the system activation will happen
|
||||||
needs to be accessible over ssh, and for the commands
|
on the remote host instead of the local machine. The remote host needs to
|
||||||
<option>switch</option>, <option>boot</option> and <option>test</option>
|
be accessible over ssh, and for the commands <option>switch</option>,
|
||||||
you need root access.</para>
|
<option>boot</option> and <option>test</option> you need root access.
|
||||||
|
</para>
|
||||||
<para>If <option>--build-host</option> is not explicitly
|
<para>
|
||||||
specified, <option>--build-host</option> will implicitly be set to the
|
If <option>--build-host</option> is not explicitly specified,
|
||||||
same value as <option>--target-host</option>. So, if you only specify
|
<option>--build-host</option> will implicitly be set to the same value as
|
||||||
|
<option>--target-host</option>. So, if you only specify
|
||||||
<option>--target-host</option> both building and activation will take
|
<option>--target-host</option> both building and activation will take
|
||||||
place remotely (and no build artifacts will be copied to the local
|
place remotely (and no build artifacts will be copied to the local
|
||||||
machine).</para>
|
machine).
|
||||||
|
</para>
|
||||||
<para>You can include a remote user name in
|
<para>
|
||||||
the host name (<replaceable>user@host</replaceable>). You can also set
|
You can include a remote user name in the host name
|
||||||
ssh options by defining the <envar>NIX_SSHOPTS</envar> environment
|
(<replaceable>user@host</replaceable>). You can also set ssh options by
|
||||||
variable.</para>
|
defining the <envar>NIX_SSHOPTS</envar> environment variable.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</variablelist>
|
<para>
|
||||||
|
In addition, <command>nixos-rebuild</command> accepts various Nix-related
|
||||||
<para>In addition, <command>nixos-rebuild</command> accepts various
|
flags, including <option>--max-jobs</option> / <option>-j</option>,
|
||||||
Nix-related flags, including <option>--max-jobs</option> /
|
<option>--show-trace</option>, <option>--keep-failed</option>,
|
||||||
<option>-j</option>, <option>--show-trace</option>,
|
<option>--keep-going</option> and <option>--verbose</option> /
|
||||||
<option>--keep-failed</option>, <option>--keep-going</option> and
|
<option>-v</option>. See the Nix manual for details.
|
||||||
<option>--verbose</option> / <option>-v</option>. See
|
</para>
|
||||||
the Nix manual for details.</para>
|
</refsection>
|
||||||
|
<refsection>
|
||||||
</refsection>
|
<title>Environment</title>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<refsection><title>Environment</title>
|
<term><envar>NIXOS_CONFIG</envar>
|
||||||
|
</term>
|
||||||
<variablelist>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><envar>NIXOS_CONFIG</envar></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Path to the main NixOS configuration module. Defaults to
|
<para>
|
||||||
<filename>/etc/nixos/configuration.nix</filename>.</para>
|
Path to the main NixOS configuration module. Defaults to
|
||||||
|
<filename>/etc/nixos/configuration.nix</filename>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
<varlistentry><term><envar>NIX_SSHOPTS</envar></term>
|
<term><envar>NIX_SSHOPTS</envar>
|
||||||
|
</term>
|
||||||
<listitem><para>Additional options to be passed to
|
|
||||||
<command>ssh</command> on the command line.</para></listitem>
|
|
||||||
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
</variablelist>
|
|
||||||
|
|
||||||
</refsection>
|
|
||||||
|
|
||||||
|
|
||||||
<refsection><title>Files</title>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><filename>/run/current-system</filename></term>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>A symlink to the currently active system configuration in
|
<para>
|
||||||
the Nix store.</para>
|
Additional options to be passed to <command>ssh</command> on the command
|
||||||
|
line.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
<varlistentry>
|
</refsection>
|
||||||
<term><filename>/nix/var/nix/profiles/system</filename></term>
|
<refsection>
|
||||||
|
<title>Files</title>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term><filename>/run/current-system</filename>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The Nix profile that contains the current and previous
|
<para>
|
||||||
system configurations. Used to generate the GRUB boot
|
A symlink to the currently active system configuration in the Nix store.
|
||||||
menu.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
</variablelist>
|
<term><filename>/nix/var/nix/profiles/system</filename>
|
||||||
|
</term>
|
||||||
</refsection>
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The Nix profile that contains the current and previous system
|
||||||
<refsection><title>Bugs</title>
|
configurations. Used to generate the GRUB boot menu.
|
||||||
|
</para>
|
||||||
<para>This command should be renamed to something more
|
</listitem>
|
||||||
descriptive.</para>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
</refsection>
|
</refsection>
|
||||||
|
<refsection>
|
||||||
|
<title>Bugs</title>
|
||||||
|
<para>
|
||||||
|
This command should be renamed to something more descriptive.
|
||||||
|
</para>
|
||||||
|
</refsection>
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,97 +1,102 @@
|
|||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<refmeta>
|
||||||
<refmeta>
|
<refentrytitle><command>nixos-version</command>
|
||||||
<refentrytitle><command>nixos-version</command></refentrytitle>
|
</refentrytitle><manvolnum>8</manvolnum>
|
||||||
<manvolnum>8</manvolnum>
|
|
||||||
<refmiscinfo class="source">NixOS</refmiscinfo>
|
<refmiscinfo class="source">NixOS</refmiscinfo>
|
||||||
</refmeta>
|
</refmeta>
|
||||||
|
<refnamediv>
|
||||||
<refnamediv>
|
<refname><command>nixos-version</command>
|
||||||
<refname><command>nixos-version</command></refname>
|
</refname><refpurpose>show the NixOS version</refpurpose>
|
||||||
<refpurpose>show the NixOS version</refpurpose>
|
</refnamediv>
|
||||||
</refnamediv>
|
<refsynopsisdiv>
|
||||||
|
<cmdsynopsis><command>nixos-version</command>
|
||||||
<refsynopsisdiv>
|
<arg><option>--hash</option>
|
||||||
<cmdsynopsis>
|
</arg>
|
||||||
<command>nixos-version</command>
|
<arg><option>--revision</option>
|
||||||
<arg><option>--hash</option></arg>
|
</arg>
|
||||||
<arg><option>--revision</option></arg>
|
|
||||||
</cmdsynopsis>
|
</cmdsynopsis>
|
||||||
</refsynopsisdiv>
|
</refsynopsisdiv>
|
||||||
|
<refsection>
|
||||||
<refsection><title>Description</title>
|
<title>Description</title>
|
||||||
|
<para>
|
||||||
<para>This command shows the version of the currently active NixOS
|
This command shows the version of the currently active NixOS configuration.
|
||||||
configuration. For example:
|
For example:
|
||||||
|
|
||||||
<screen>$ nixos-version
|
<screen>$ nixos-version
|
||||||
16.03.1011.6317da4 (Emu)
|
16.03.1011.6317da4 (Emu)
|
||||||
</screen>
|
</screen>
|
||||||
|
The version consists of the following elements:
|
||||||
The version consists of the following elements:
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
<variablelist>
|
<term><literal>16.03</literal>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
<listitem>
|
||||||
<term><literal>16.03</literal></term>
|
<para>
|
||||||
<listitem><para>The NixOS release, indicating the year and month
|
The NixOS release, indicating the year and month in which it was
|
||||||
in which it was released (e.g. March 2016).</para></listitem>
|
released (e.g. March 2016).
|
||||||
</varlistentry>
|
</para>
|
||||||
|
</listitem>
|
||||||
<varlistentry>
|
</varlistentry>
|
||||||
<term><literal>1011</literal></term>
|
<varlistentry>
|
||||||
<listitem><para>The number of commits in the Nixpkgs Git
|
<term><literal>1011</literal>
|
||||||
repository between the start of the release branch and the commit
|
</term>
|
||||||
from which this version was built. This ensures that NixOS
|
<listitem>
|
||||||
versions are monotonically increasing. It is
|
<para>
|
||||||
<literal>git</literal> when the current NixOS configuration was
|
The number of commits in the Nixpkgs Git repository between the start of
|
||||||
built from a checkout of the Nixpkgs Git repository rather than
|
the release branch and the commit from which this version was built.
|
||||||
from a NixOS channel.</para></listitem>
|
This ensures that NixOS versions are monotonically increasing. It is
|
||||||
</varlistentry>
|
<literal>git</literal> when the current NixOS configuration was built
|
||||||
|
from a checkout of the Nixpkgs Git repository rather than from a NixOS
|
||||||
<varlistentry>
|
channel.
|
||||||
<term><literal>6317da4</literal></term>
|
</para>
|
||||||
<listitem><para>The first 7 characters of the commit in the
|
</listitem>
|
||||||
Nixpkgs Git repository from which this version was
|
</varlistentry>
|
||||||
built.</para></listitem>
|
<varlistentry>
|
||||||
</varlistentry>
|
<term><literal>6317da4</literal>
|
||||||
|
</term>
|
||||||
<varlistentry>
|
<listitem>
|
||||||
<term><literal>Emu</literal></term>
|
<para>
|
||||||
<listitem><para>The code name of the NixOS release. The first
|
The first 7 characters of the commit in the Nixpkgs Git repository from
|
||||||
letter of the code name indicates that this is the N'th stable
|
which this version was built.
|
||||||
NixOS release; for example, Emu is the fifth
|
</para>
|
||||||
release.</para></listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
</variablelist>
|
<term><literal>Emu</literal>
|
||||||
|
</term>
|
||||||
</para>
|
<listitem>
|
||||||
|
<para>
|
||||||
</refsection>
|
The code name of the NixOS release. The first letter of the code name
|
||||||
|
indicates that this is the N'th stable NixOS release; for example, Emu
|
||||||
|
is the fifth release.
|
||||||
<refsection><title>Options</title>
|
</para>
|
||||||
|
</listitem>
|
||||||
<para>This command accepts the following options:</para>
|
</varlistentry>
|
||||||
|
</variablelist>
|
||||||
<variablelist>
|
</para>
|
||||||
|
</refsection>
|
||||||
<varlistentry>
|
<refsection>
|
||||||
<term><option>--hash</option></term>
|
<title>Options</title>
|
||||||
<term><option>--revision</option></term>
|
<para>
|
||||||
|
This command accepts the following options:
|
||||||
|
</para>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>--hash</option>
|
||||||
|
</term>
|
||||||
|
<term><option>--revision</option>
|
||||||
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Show the full SHA1 hash of the Git commit from which this
|
<para>
|
||||||
configuration was built, e.g.
|
Show the full SHA1 hash of the Git commit from which this configuration
|
||||||
|
was built, e.g.
|
||||||
<screen>$ nixos-version --hash
|
<screen>$ nixos-version --hash
|
||||||
6317da40006f6bc2480c6781999c52d88dde2acf
|
6317da40006f6bc2480c6781999c52d88dde2acf
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
</refsection>
|
||||||
</refsection>
|
|
||||||
</refentry>
|
</refentry>
|
||||||
|
@ -1,33 +1,20 @@
|
|||||||
<reference xmlns="http://docbook.org/ns/docbook"
|
<reference xmlns="http://docbook.org/ns/docbook"
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||||
|
<title>NixOS Reference Pages</title>
|
||||||
<title>NixOS Reference Pages</title>
|
<info>
|
||||||
|
<author><personname><firstname>Eelco</firstname><surname>Dolstra</surname></personname>
|
||||||
<info>
|
<contrib>Author</contrib>
|
||||||
|
</author>
|
||||||
<author>
|
<copyright><year>2007-2018</year><holder>Eelco Dolstra</holder>
|
||||||
<personname>
|
</copyright>
|
||||||
<firstname>Eelco</firstname>
|
</info>
|
||||||
<surname>Dolstra</surname>
|
<xi:include href="man-configuration.xml" />
|
||||||
</personname>
|
<xi:include href="man-nixos-build-vms.xml" />
|
||||||
<contrib>Author</contrib>
|
<xi:include href="man-nixos-generate-config.xml" />
|
||||||
</author>
|
<xi:include href="man-nixos-install.xml" />
|
||||||
|
<xi:include href="man-nixos-enter.xml" />
|
||||||
<copyright>
|
<xi:include href="man-nixos-option.xml" />
|
||||||
<year>2007-2018</year>
|
<xi:include href="man-nixos-rebuild.xml" />
|
||||||
<holder>Eelco Dolstra</holder>
|
<xi:include href="man-nixos-version.xml" />
|
||||||
</copyright>
|
|
||||||
|
|
||||||
</info>
|
|
||||||
|
|
||||||
<xi:include href="man-configuration.xml" />
|
|
||||||
<xi:include href="man-nixos-build-vms.xml" />
|
|
||||||
<xi:include href="man-nixos-generate-config.xml" />
|
|
||||||
<xi:include href="man-nixos-install.xml" />
|
|
||||||
<xi:include href="man-nixos-enter.xml" />
|
|
||||||
<xi:include href="man-nixos-option.xml" />
|
|
||||||
<xi:include href="man-nixos-rebuild.xml" />
|
|
||||||
<xi:include href="man-nixos-version.xml" />
|
|
||||||
|
|
||||||
</reference>
|
</reference>
|
||||||
|
@ -3,46 +3,46 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="book-nixos-manual">
|
xml:id="book-nixos-manual">
|
||||||
|
<info>
|
||||||
<info>
|
<title>NixOS Manual</title>
|
||||||
<title>NixOS Manual</title>
|
<subtitle>Version <xi:include href="./generated/version" parse="text" />
|
||||||
<subtitle>Version <xi:include href="./generated/version" parse="text" /></subtitle>
|
</subtitle>
|
||||||
</info>
|
</info>
|
||||||
|
<preface>
|
||||||
<preface>
|
<title>Preface</title>
|
||||||
<title>Preface</title>
|
<para>
|
||||||
|
This manual describes how to install, use and extend NixOS, a Linux
|
||||||
<para>This manual describes how to install, use and extend NixOS,
|
distribution based on the purely functional package management system Nix.
|
||||||
a Linux distribution based on the purely functional package
|
</para>
|
||||||
management system Nix.</para>
|
<para>
|
||||||
|
If you encounter problems, please report them on the
|
||||||
<para>If you encounter problems, please report them on the
|
<literal
|
||||||
<literal
|
|
||||||
xlink:href="https://groups.google.com/forum/#!forum/nix-devel">nix-devel</literal>
|
xlink:href="https://groups.google.com/forum/#!forum/nix-devel">nix-devel</literal>
|
||||||
mailing list or on the <link
|
mailing list or on the <link
|
||||||
xlink:href="irc://irc.freenode.net/#nixos">
|
xlink:href="irc://irc.freenode.net/#nixos">
|
||||||
<literal>#nixos</literal> channel on Freenode</link>. Bugs should
|
<literal>#nixos</literal> channel on Freenode</link>. Bugs should be
|
||||||
be reported in <link
|
reported in
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/issues">NixOS’ GitHub
|
<link
|
||||||
issue tracker</link>.</para>
|
xlink:href="https://github.com/NixOS/nixpkgs/issues">NixOS’
|
||||||
|
GitHub issue tracker</link>.
|
||||||
<note><para>Commands prefixed with <literal>#</literal> have to be run as
|
</para>
|
||||||
root, either requiring to login as root user or temporarily switching
|
<note>
|
||||||
to it using <literal>sudo</literal> for example.</para></note>
|
<para>
|
||||||
</preface>
|
Commands prefixed with <literal>#</literal> have to be run as root, either
|
||||||
|
requiring to login as root user or temporarily switching to it using
|
||||||
<xi:include href="installation/installation.xml" />
|
<literal>sudo</literal> for example.
|
||||||
<xi:include href="configuration/configuration.xml" />
|
</para>
|
||||||
<xi:include href="administration/running.xml" />
|
</note>
|
||||||
<!-- <xi:include href="userconfiguration.xml" /> -->
|
</preface>
|
||||||
<xi:include href="development/development.xml" />
|
<xi:include href="installation/installation.xml" />
|
||||||
|
<xi:include href="configuration/configuration.xml" />
|
||||||
<appendix xml:id="ch-options">
|
<xi:include href="administration/running.xml" />
|
||||||
<title>Configuration Options</title>
|
<!-- <xi:include href="userconfiguration.xml" /> -->
|
||||||
<xi:include href="./generated/options-db.xml"
|
<xi:include href="development/development.xml" />
|
||||||
|
<appendix xml:id="ch-options">
|
||||||
|
<title>Configuration Options</title>
|
||||||
|
<xi:include href="./generated/options-db.xml"
|
||||||
xpointer="configuration-variable-list" />
|
xpointer="configuration-variable-list" />
|
||||||
</appendix>
|
</appendix>
|
||||||
|
<xi:include href="release-notes/release-notes.xml" />
|
||||||
<xi:include href="release-notes/release-notes.xml" />
|
|
||||||
|
|
||||||
</book>
|
</book>
|
||||||
|
@ -3,21 +3,19 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="ch-release-notes">
|
xml:id="ch-release-notes">
|
||||||
|
<title>Release Notes</title>
|
||||||
<title>Release Notes</title>
|
<para>
|
||||||
|
This section lists the release notes for each stable version of NixOS and
|
||||||
<para>This section lists the release notes for each stable version of NixOS
|
current unstable revision.
|
||||||
and current unstable revision.</para>
|
</para>
|
||||||
|
<xi:include href="rl-1809.xml" />
|
||||||
<xi:include href="rl-1809.xml" />
|
<xi:include href="rl-1803.xml" />
|
||||||
<xi:include href="rl-1803.xml" />
|
<xi:include href="rl-1709.xml" />
|
||||||
<xi:include href="rl-1709.xml" />
|
<xi:include href="rl-1703.xml" />
|
||||||
<xi:include href="rl-1703.xml" />
|
<xi:include href="rl-1609.xml" />
|
||||||
<xi:include href="rl-1609.xml" />
|
<xi:include href="rl-1603.xml" />
|
||||||
<xi:include href="rl-1603.xml" />
|
<xi:include href="rl-1509.xml" />
|
||||||
<xi:include href="rl-1509.xml" />
|
<xi:include href="rl-1412.xml" />
|
||||||
<xi:include href="rl-1412.xml" />
|
<xi:include href="rl-1404.xml" />
|
||||||
<xi:include href="rl-1404.xml" />
|
<xi:include href="rl-1310.xml" />
|
||||||
<xi:include href="rl-1310.xml" />
|
|
||||||
|
|
||||||
</appendix>
|
</appendix>
|
||||||
|
@ -3,9 +3,9 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-13.10">
|
xml:id="sec-release-13.10">
|
||||||
|
<title>Release 13.10 (“Aardvark”, 2013/10/31)</title>
|
||||||
|
|
||||||
<title>Release 13.10 (“Aardvark”, 2013/10/31)</title>
|
<para>
|
||||||
|
This is the first stable release branch of NixOS.
|
||||||
<para>This is the first stable release branch of NixOS.</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,158 +3,177 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-14.04">
|
xml:id="sec-release-14.04">
|
||||||
|
<title>Release 14.04 (“Baboon”, 2014/04/30)</title>
|
||||||
|
|
||||||
<title>Release 14.04 (“Baboon”, 2014/04/30)</title>
|
<para>
|
||||||
|
This is the second stable release branch of NixOS. In addition to numerous
|
||||||
<para>This is the second stable release branch of NixOS. In addition
|
new and upgraded packages and modules, this release has the following
|
||||||
to numerous new and upgraded packages and modules, this release has
|
highlights:
|
||||||
the following highlights:
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
<itemizedlist>
|
<para>
|
||||||
|
Installation on UEFI systems is now supported. See
|
||||||
<listitem><para>Installation on UEFI systems is now supported. See
|
<xref linkend="sec-installation"/> for details.
|
||||||
<xref linkend="sec-installation"/> for
|
</para>
|
||||||
details.</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>Systemd has been updated to version 212, which has
|
<para>
|
||||||
<link xlink:href="http://cgit.freedesktop.org/systemd/systemd/plain/NEWS?id=v212">numerous
|
Systemd has been updated to version 212, which has
|
||||||
improvements</link>. NixOS now automatically starts systemd user
|
<link xlink:href="http://cgit.freedesktop.org/systemd/systemd/plain/NEWS?id=v212">numerous
|
||||||
instances when you log in. You can define global user units through
|
improvements</link>. NixOS now automatically starts systemd user instances
|
||||||
the <option>systemd.unit.*</option> options.</para></listitem>
|
when you log in. You can define global user units through the
|
||||||
|
<option>systemd.unit.*</option> options.
|
||||||
<listitem><para>NixOS is now based on Glibc 2.19 and GCC
|
</para>
|
||||||
4.8.</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>The default Linux kernel has been updated to
|
<para>
|
||||||
3.12.</para></listitem>
|
NixOS is now based on Glibc 2.19 and GCC 4.8.
|
||||||
|
</para>
|
||||||
<listitem><para>KDE has been updated to 4.12.</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>GNOME 3.10 experimental support has been added.</para></listitem>
|
<para>
|
||||||
|
The default Linux kernel has been updated to 3.12.
|
||||||
<listitem><para>Nix has been updated to 1.7 (<link
|
</para>
|
||||||
xlink:href="http://nixos.org/nix/manual/#ssec-relnotes-1.7">details</link>).</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>NixOS now supports fully declarative management of
|
<para>
|
||||||
users and groups. If you set <option>users.mutableUsers</option> to
|
KDE has been updated to 4.12.
|
||||||
<literal>false</literal>, then the contents of
|
</para>
|
||||||
<filename>/etc/passwd</filename> and <filename>/etc/group</filename>
|
</listitem>
|
||||||
will be <link
|
<listitem>
|
||||||
|
<para>
|
||||||
|
GNOME 3.10 experimental support has been added.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Nix has been updated to 1.7
|
||||||
|
(<link
|
||||||
|
xlink:href="http://nixos.org/nix/manual/#ssec-relnotes-1.7">details</link>).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
NixOS now supports fully declarative management of users and groups. If
|
||||||
|
you set <option>users.mutableUsers</option> to <literal>false</literal>,
|
||||||
|
then the contents of <filename>/etc/passwd</filename> and
|
||||||
|
<filename>/etc/group</filename> will be
|
||||||
|
<link
|
||||||
xlink:href="https://www.usenix.org/legacy/event/lisa02/tech/full_papers/traugott/traugott_html/">congruent</link>
|
xlink:href="https://www.usenix.org/legacy/event/lisa02/tech/full_papers/traugott/traugott_html/">congruent</link>
|
||||||
to your NixOS configuration. For instance, if you remove a user from
|
to your NixOS configuration. For instance, if you remove a user from
|
||||||
<option>users.extraUsers</option> and run
|
<option>users.extraUsers</option> and run
|
||||||
<command>nixos-rebuild</command>, the user account will cease to
|
<command>nixos-rebuild</command>, the user account will cease to exist.
|
||||||
exist. Also, imperative commands for managing users and groups, such
|
Also, imperative commands for managing users and groups, such as
|
||||||
as <command>useradd</command>, are no longer available. If
|
<command>useradd</command>, are no longer available. If
|
||||||
<option>users.mutableUsers</option> is <literal>true</literal> (the
|
<option>users.mutableUsers</option> is <literal>true</literal> (the
|
||||||
default), then behaviour is unchanged from NixOS
|
default), then behaviour is unchanged from NixOS 13.10.
|
||||||
13.10.</para></listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem><para>NixOS now has basic container support, meaning you
|
<listitem>
|
||||||
can easily run a NixOS instance as a container in a NixOS host
|
<para>
|
||||||
system. These containers are suitable for testing and
|
NixOS now has basic container support, meaning you can easily run a NixOS
|
||||||
experimentation but not production use, since they’re not fully
|
instance as a container in a NixOS host system. These containers are
|
||||||
isolated from the host. See <xref linkend="ch-containers"/> for
|
suitable for testing and experimentation but not production use, since
|
||||||
details.</para></listitem>
|
they’re not fully isolated from the host. See
|
||||||
|
<xref linkend="ch-containers"/> for details.
|
||||||
<listitem><para>Systemd units provided by packages can now be
|
</para>
|
||||||
overridden from the NixOS configuration. For instance, if a package
|
</listitem>
|
||||||
<literal>foo</literal> provides systemd units, you can say:
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Systemd units provided by packages can now be overridden from the NixOS
|
||||||
|
configuration. For instance, if a package <literal>foo</literal> provides
|
||||||
|
systemd units, you can say:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
systemd.packages = [ pkgs.foo ];
|
systemd.packages = [ pkgs.foo ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
to enable those units. You can then set or override unit options in the
|
||||||
to enable those units. You can then set or override unit options in
|
usual way, e.g.
|
||||||
the usual way, e.g.
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
systemd.services.foo.wantedBy = [ "multi-user.target" ];
|
systemd.services.foo.wantedBy = [ "multi-user.target" ];
|
||||||
systemd.services.foo.serviceConfig.MemoryLimit = "512M";
|
systemd.services.foo.serviceConfig.MemoryLimit = "512M";
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
</para></listitem>
|
<para>
|
||||||
|
When upgrading from a previous release, please be aware of the following
|
||||||
</itemizedlist>
|
incompatible changes:
|
||||||
|
<itemizedlist>
|
||||||
</para>
|
<listitem>
|
||||||
|
<para>
|
||||||
<para>When upgrading from a previous release, please be aware of the
|
Nixpkgs no longer exposes unfree packages by default. If your NixOS
|
||||||
following incompatible changes:
|
configuration requires unfree packages from Nixpkgs, you need to enable
|
||||||
|
support for them explicitly by setting:
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
<listitem><para>Nixpkgs no longer exposes unfree packages by
|
|
||||||
default. If your NixOS configuration requires unfree packages from
|
|
||||||
Nixpkgs, you need to enable support for them explicitly by setting:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
nixpkgs.config.allowUnfree = true;
|
nixpkgs.config.allowUnfree = true;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
Otherwise, you get an error message such as:
|
||||||
Otherwise, you get an error message such as:
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
error: package ‘nvidia-x11-331.49-3.12.17’ in ‘…/nvidia-x11/default.nix:56’
|
error: package ‘nvidia-x11-331.49-3.12.17’ in ‘…/nvidia-x11/default.nix:56’
|
||||||
has an unfree license, refusing to evaluate
|
has an unfree license, refusing to evaluate
|
||||||
</screen>
|
</screen>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>The Adobe Flash player is no longer enabled by
|
<para>
|
||||||
default in the Firefox and Chromium wrappers. To enable it, you must
|
The Adobe Flash player is no longer enabled by default in the Firefox and
|
||||||
set:
|
Chromium wrappers. To enable it, you must set:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
nixpkgs.config.allowUnfree = true;
|
nixpkgs.config.allowUnfree = true;
|
||||||
nixpkgs.config.firefox.enableAdobeFlash = true; # for Firefox
|
nixpkgs.config.firefox.enableAdobeFlash = true; # for Firefox
|
||||||
nixpkgs.config.chromium.enableAdobeFlash = true; # for Chromium
|
nixpkgs.config.chromium.enableAdobeFlash = true; # for Chromium
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>The firewall is now enabled by default. If you don’t
|
<para>
|
||||||
want this, you need to disable it explicitly:
|
The firewall is now enabled by default. If you don’t want this, you need
|
||||||
|
to disable it explicitly:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
networking.firewall.enable = false;
|
networking.firewall.enable = false;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>The option
|
<para>
|
||||||
<option>boot.loader.grub.memtest86</option> has been renamed to
|
The option <option>boot.loader.grub.memtest86</option> has been renamed to
|
||||||
<option>boot.loader.grub.memtest86.enable</option>.</para></listitem>
|
<option>boot.loader.grub.memtest86.enable</option>.
|
||||||
|
</para>
|
||||||
<listitem><para>The <literal>mysql55</literal> service has been
|
</listitem>
|
||||||
merged into the <literal>mysql</literal> service, which no longer
|
<listitem>
|
||||||
sets a default for the option
|
<para>
|
||||||
<option>services.mysql.package</option>.</para></listitem>
|
The <literal>mysql55</literal> service has been merged into the
|
||||||
|
<literal>mysql</literal> service, which no longer sets a default for the
|
||||||
<listitem><para>Package variants are now differentiated by suffixing
|
option <option>services.mysql.package</option>.
|
||||||
the name, rather than the version. For instance,
|
</para>
|
||||||
<filename>sqlite-3.8.4.3-interactive</filename> is now called
|
</listitem>
|
||||||
<filename>sqlite-interactive-3.8.4.3</filename>. This ensures that
|
<listitem>
|
||||||
<literal>nix-env -i sqlite</literal> is unambiguous, and that
|
<para>
|
||||||
<literal>nix-env -u</literal> won’t “upgrade”
|
Package variants are now differentiated by suffixing the name, rather than
|
||||||
<literal>sqlite</literal> to <literal>sqlite-interactive</literal>
|
the version. For instance, <filename>sqlite-3.8.4.3-interactive</filename>
|
||||||
or vice versa. Notably, this change affects the Firefox wrapper
|
is now called <filename>sqlite-interactive-3.8.4.3</filename>. This
|
||||||
(which provides plugins), as it is now called
|
ensures that <literal>nix-env -i sqlite</literal> is unambiguous, and that
|
||||||
<literal>firefox-wrapper</literal>. So when using
|
<literal>nix-env -u</literal> won’t “upgrade”
|
||||||
<command>nix-env</command>, you should do <literal>nix-env -e
|
<literal>sqlite</literal> to <literal>sqlite-interactive</literal> or vice
|
||||||
firefox; nix-env -i firefox-wrapper</literal> if you want to keep
|
versa. Notably, this change affects the Firefox wrapper (which provides
|
||||||
using the wrapper. This change does not affect declarative package
|
plugins), as it is now called <literal>firefox-wrapper</literal>. So when
|
||||||
management, since attribute names like
|
using <command>nix-env</command>, you should do <literal>nix-env -e
|
||||||
<literal>pkgs.firefoxWrapper</literal> were already
|
firefox; nix-env -i firefox-wrapper</literal> if you want to keep using
|
||||||
unambiguous.</para></listitem>
|
the wrapper. This change does not affect declarative package management,
|
||||||
|
since attribute names like <literal>pkgs.firefoxWrapper</literal> were
|
||||||
<listitem><para>The symlink <filename>/etc/ca-bundle.crt</filename>
|
already unambiguous.
|
||||||
is gone. Programs should instead use the environment variable
|
</para>
|
||||||
<envar>OPENSSL_X509_CERT_FILE</envar> (which points to
|
</listitem>
|
||||||
<filename>/etc/ssl/certs/ca-bundle.crt</filename>).</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
</itemizedlist>
|
The symlink <filename>/etc/ca-bundle.crt</filename> is gone. Programs
|
||||||
|
should instead use the environment variable
|
||||||
</para>
|
<envar>OPENSSL_X509_CERT_FILE</envar> (which points to
|
||||||
|
<filename>/etc/ssl/certs/ca-bundle.crt</filename>).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,175 +3,465 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-14.12">
|
xml:id="sec-release-14.12">
|
||||||
|
<title>Release 14.12 (“Caterpillar”, 2014/12/30)</title>
|
||||||
|
|
||||||
<title>Release 14.12 (“Caterpillar”, 2014/12/30)</title>
|
<para>
|
||||||
|
In addition to numerous new and upgraded packages, this release has the
|
||||||
|
following highlights:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Systemd has been updated to version 217, which has numerous
|
||||||
|
<link xlink:href="http://lists.freedesktop.org/archives/systemd-devel/2014-October/024662.html">improvements.</link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<link xlink:href="http://thread.gmane.org/gmane.linux.distributions.nixos/15165">
|
||||||
|
Nix has been updated to 1.8.</link>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
NixOS is now based on Glibc 2.20.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
KDE has been updated to 4.14.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The default Linux kernel has been updated to 3.14.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
If <option>users.mutableUsers</option> is enabled (the default), changes
|
||||||
|
made to the declaration of a user or group will be correctly realised when
|
||||||
|
running <command>nixos-rebuild</command>. For instance, removing a user
|
||||||
|
specification from <filename>configuration.nix</filename> will cause the
|
||||||
|
actual user account to be deleted. If <option>users.mutableUsers</option>
|
||||||
|
is disabled, it is no longer necessary to specify UIDs or GIDs; if
|
||||||
|
omitted, they are allocated dynamically.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>In addition to numerous new and upgraded packages, this release has the following highlights:
|
<para>
|
||||||
|
Following new services were added since the last release:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>atftpd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>bosun</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>bspwm</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>chronos</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>collectd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>consul</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>cpuminer-cryptonight</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>crashplan</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>dnscrypt-proxy</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>docker-registry</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>docker</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>etcd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>fail2ban</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>fcgiwrap</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>fleet</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>fluxbox</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gdm</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>geoclue2</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gitlab</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gitolite</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gnome3.gnome-documents</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gnome3.gnome-online-miners</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gnome3.gvfs</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>gnome3.seahorse</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>hbase</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>i2pd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>influxdb</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>kubernetes</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>liquidsoap</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>lxc</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>mailpile</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>mesos</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>mlmmj</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>monetdb</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>mopidy</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>neo4j</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>nsd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>openntpd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>opentsdb</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>openvswitch</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>parallels-guest</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>peerflix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>phd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>polipo</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>prosody</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>radicale</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>redmine</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>riemann</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>scollector</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>seeks</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>siproxd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>strongswan</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>tcsd</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>teamspeak3</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>thermald</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>torque/mrom</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>torque/server</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>uhub</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>unifi</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>znc</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>zookeeper</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
<itemizedlist>
|
<para>
|
||||||
|
When upgrading from a previous release, please be aware of the following
|
||||||
<listitem><para>Systemd has been updated to version 217, which has numerous
|
incompatible changes:
|
||||||
<link xlink:href="http://lists.freedesktop.org/archives/systemd-devel/2014-October/024662.html">improvements.</link></para></listitem>
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
<listitem><para><link xlink:href="http://thread.gmane.org/gmane.linux.distributions.nixos/15165">
|
<para>
|
||||||
Nix has been updated to 1.8.</link></para></listitem>
|
The default version of Apache httpd is now 2.4. If you use the
|
||||||
|
<option>extraConfig</option> option to pass literal Apache configuration
|
||||||
<listitem><para>NixOS is now based on Glibc 2.20.</para></listitem>
|
text, you may need to update it — see
|
||||||
|
<link
|
||||||
<listitem><para>KDE has been updated to 4.14.</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>The default Linux kernel has been updated to 3.14.</para></listitem>
|
|
||||||
|
|
||||||
<listitem><para>If <option>users.mutableUsers</option> is enabled (the
|
|
||||||
default), changes made to the declaration of a user or group will be
|
|
||||||
correctly realised when running <command>nixos-rebuild</command>. For
|
|
||||||
instance, removing a user specification from
|
|
||||||
<filename>configuration.nix</filename> will cause the actual user
|
|
||||||
account to be deleted. If <option>users.mutableUsers</option> is
|
|
||||||
disabled, it is no longer necessary to specify UIDs or GIDs; if
|
|
||||||
omitted, they are allocated dynamically.</para></listitem>
|
|
||||||
|
|
||||||
</itemizedlist></para>
|
|
||||||
|
|
||||||
<para>Following new services were added since the last release:
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem><para><literal>atftpd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>bosun</literal></para></listitem>
|
|
||||||
<listitem><para><literal>bspwm</literal></para></listitem>
|
|
||||||
<listitem><para><literal>chronos</literal></para></listitem>
|
|
||||||
<listitem><para><literal>collectd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>consul</literal></para></listitem>
|
|
||||||
<listitem><para><literal>cpuminer-cryptonight</literal></para></listitem>
|
|
||||||
<listitem><para><literal>crashplan</literal></para></listitem>
|
|
||||||
<listitem><para><literal>dnscrypt-proxy</literal></para></listitem>
|
|
||||||
<listitem><para><literal>docker-registry</literal></para></listitem>
|
|
||||||
<listitem><para><literal>docker</literal></para></listitem>
|
|
||||||
<listitem><para><literal>etcd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>fail2ban</literal></para></listitem>
|
|
||||||
<listitem><para><literal>fcgiwrap</literal></para></listitem>
|
|
||||||
<listitem><para><literal>fleet</literal></para></listitem>
|
|
||||||
<listitem><para><literal>fluxbox</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gdm</literal></para></listitem>
|
|
||||||
<listitem><para><literal>geoclue2</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gitlab</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gitolite</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gnome3.gnome-documents</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gnome3.gnome-online-miners</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gnome3.gvfs</literal></para></listitem>
|
|
||||||
<listitem><para><literal>gnome3.seahorse</literal></para></listitem>
|
|
||||||
<listitem><para><literal>hbase</literal></para></listitem>
|
|
||||||
<listitem><para><literal>i2pd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>influxdb</literal></para></listitem>
|
|
||||||
<listitem><para><literal>kubernetes</literal></para></listitem>
|
|
||||||
<listitem><para><literal>liquidsoap</literal></para></listitem>
|
|
||||||
<listitem><para><literal>lxc</literal></para></listitem>
|
|
||||||
<listitem><para><literal>mailpile</literal></para></listitem>
|
|
||||||
<listitem><para><literal>mesos</literal></para></listitem>
|
|
||||||
<listitem><para><literal>mlmmj</literal></para></listitem>
|
|
||||||
<listitem><para><literal>monetdb</literal></para></listitem>
|
|
||||||
<listitem><para><literal>mopidy</literal></para></listitem>
|
|
||||||
<listitem><para><literal>neo4j</literal></para></listitem>
|
|
||||||
<listitem><para><literal>nsd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>openntpd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>opentsdb</literal></para></listitem>
|
|
||||||
<listitem><para><literal>openvswitch</literal></para></listitem>
|
|
||||||
<listitem><para><literal>parallels-guest</literal></para></listitem>
|
|
||||||
<listitem><para><literal>peerflix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>phd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>polipo</literal></para></listitem>
|
|
||||||
<listitem><para><literal>prosody</literal></para></listitem>
|
|
||||||
<listitem><para><literal>radicale</literal></para></listitem>
|
|
||||||
<listitem><para><literal>redmine</literal></para></listitem>
|
|
||||||
<listitem><para><literal>riemann</literal></para></listitem>
|
|
||||||
<listitem><para><literal>scollector</literal></para></listitem>
|
|
||||||
<listitem><para><literal>seeks</literal></para></listitem>
|
|
||||||
<listitem><para><literal>siproxd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>strongswan</literal></para></listitem>
|
|
||||||
<listitem><para><literal>tcsd</literal></para></listitem>
|
|
||||||
<listitem><para><literal>teamspeak3</literal></para></listitem>
|
|
||||||
<listitem><para><literal>thermald</literal></para></listitem>
|
|
||||||
<listitem><para><literal>torque/mrom</literal></para></listitem>
|
|
||||||
<listitem><para><literal>torque/server</literal></para></listitem>
|
|
||||||
<listitem><para><literal>uhub</literal></para></listitem>
|
|
||||||
<listitem><para><literal>unifi</literal></para></listitem>
|
|
||||||
<listitem><para><literal>znc</literal></para></listitem>
|
|
||||||
<listitem><para><literal>zookeeper</literal></para></listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>When upgrading from a previous release, please be aware of the
|
|
||||||
following incompatible changes:
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
<listitem><para>The default version of Apache httpd is now 2.4. If
|
|
||||||
you use the <option>extraConfig</option> option to pass literal
|
|
||||||
Apache configuration text, you may need to update it — see <link
|
|
||||||
xlink:href="http://httpd.apache.org/docs/2.4/upgrading.html">Apache’s
|
xlink:href="http://httpd.apache.org/docs/2.4/upgrading.html">Apache’s
|
||||||
documentation</link> for details. If you wish to continue to use
|
documentation</link> for details. If you wish to continue to use httpd
|
||||||
httpd 2.2, add the following line to your NixOS configuration:
|
2.2, add the following line to your NixOS configuration:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
services.httpd.package = pkgs.apacheHttpd_2_2;
|
services.httpd.package = pkgs.apacheHttpd_2_2;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>PHP 5.3 has been removed because it is no longer
|
<para>
|
||||||
supported by the PHP project. A <link
|
PHP 5.3 has been removed because it is no longer supported by the PHP
|
||||||
xlink:href="http://php.net/migration54">migration guide</link> is
|
project. A <link
|
||||||
available.</para></listitem>
|
xlink:href="http://php.net/migration54">migration
|
||||||
|
guide</link> is available.
|
||||||
<listitem><para>The host side of a container virtual Ethernet pair
|
</para>
|
||||||
is now called <literal>ve-<replaceable>container-name</replaceable></literal>
|
</listitem>
|
||||||
rather than <literal>c-<replaceable>container-name</replaceable></literal>.</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>GNOME 3.10 support has been dropped. The default GNOME version is now 3.12.</para></listitem>
|
The host side of a container virtual Ethernet pair is now called
|
||||||
|
<literal>ve-<replaceable>container-name</replaceable></literal> rather
|
||||||
<listitem><para>VirtualBox has been upgraded to 4.3.20 release. Users
|
than <literal>c-<replaceable>container-name</replaceable></literal>.
|
||||||
may be required to run <command>rm -rf /tmp/.vbox*</command>. The line
|
</para>
|
||||||
<literal>imports = [ <nixpkgs/nixos/modules/programs/virtualbox.nix> ]</literal> is
|
</listitem>
|
||||||
no longer necessary, use <literal>services.virtualboxHost.enable =
|
<listitem>
|
||||||
true</literal> instead.
|
<para>
|
||||||
</para>
|
GNOME 3.10 support has been dropped. The default GNOME version is now
|
||||||
<para>Also, hardening mode is now enabled by default, which means that unless you want to use
|
3.12.
|
||||||
USB support, you no longer need to be a member of the <literal>vboxusers</literal> group.
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>Chromium has been updated to 39.0.2171.65. <option>enablePepperPDF</option> is now enabled by default.
|
<para>
|
||||||
<literal>chromium*Wrapper</literal> packages no longer exist, because upstream removed NSAPI support.
|
VirtualBox has been upgraded to 4.3.20 release. Users may be required to
|
||||||
<literal>chromium-stable</literal> has been renamed to <literal>chromium</literal>.
|
run <command>rm -rf /tmp/.vbox*</command>. The line <literal>imports = [
|
||||||
</para></listitem>
|
<nixpkgs/nixos/modules/programs/virtualbox.nix> ]</literal> is no
|
||||||
|
longer necessary, use <literal>services.virtualboxHost.enable =
|
||||||
<listitem><para>Python packaging documentation is now part of nixpkgs manual. To override
|
true</literal> instead.
|
||||||
the python packages available to a custom python you now use <literal>pkgs.pythonFull.buildEnv.override</literal>
|
</para>
|
||||||
instead of <literal>pkgs.pythonFull.override</literal>.
|
<para>
|
||||||
</para></listitem>
|
Also, hardening mode is now enabled by default, which means that unless
|
||||||
|
you want to use USB support, you no longer need to be a member of the
|
||||||
<listitem><para><literal>boot.resumeDevice = "8:6"</literal> is no longer supported. Most users will
|
<literal>vboxusers</literal> group.
|
||||||
want to leave it undefined, which takes the swap partitions automatically. There is an evaluation
|
</para>
|
||||||
assertion to ensure that the string starts with a slash.
|
</listitem>
|
||||||
</para></listitem>
|
<listitem>
|
||||||
|
<para>
|
||||||
<listitem><para>The system-wide default timezone for NixOS installations
|
Chromium has been updated to 39.0.2171.65.
|
||||||
changed from <literal>CET</literal> to <literal>UTC</literal>. To choose
|
<option>enablePepperPDF</option> is now enabled by default.
|
||||||
a different timezone for your system, configure
|
<literal>chromium*Wrapper</literal> packages no longer exist, because
|
||||||
<literal>time.timeZone</literal> in
|
upstream removed NSAPI support. <literal>chromium-stable</literal> has
|
||||||
<literal>configuration.nix</literal>. A fairly complete list of possible
|
been renamed to <literal>chromium</literal>.
|
||||||
values for that setting is available at <link
|
</para>
|
||||||
xlink:href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones"/>.</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>GNU screen has been updated to 4.2.1, which breaks
|
<para>
|
||||||
the ability to connect to sessions created by older versions of
|
Python packaging documentation is now part of nixpkgs manual. To override
|
||||||
screen.</para></listitem>
|
the python packages available to a custom python you now use
|
||||||
|
<literal>pkgs.pythonFull.buildEnv.override</literal> instead of
|
||||||
<listitem><para>The Intel GPU driver was updated to the 3.x prerelease
|
<literal>pkgs.pythonFull.override</literal>.
|
||||||
version (used by most distributions) and supports DRI3
|
</para>
|
||||||
now.</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
</itemizedlist>
|
<para>
|
||||||
|
<literal>boot.resumeDevice = "8:6"</literal> is no longer supported. Most
|
||||||
</para>
|
users will want to leave it undefined, which takes the swap partitions
|
||||||
|
automatically. There is an evaluation assertion to ensure that the string
|
||||||
|
starts with a slash.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The system-wide default timezone for NixOS installations changed from
|
||||||
|
<literal>CET</literal> to <literal>UTC</literal>. To choose a different
|
||||||
|
timezone for your system, configure <literal>time.timeZone</literal> in
|
||||||
|
<literal>configuration.nix</literal>. A fairly complete list of possible
|
||||||
|
values for that setting is available at
|
||||||
|
<link
|
||||||
|
xlink:href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones"/>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
GNU screen has been updated to 4.2.1, which breaks the ability to connect
|
||||||
|
to sessions created by older versions of screen.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The Intel GPU driver was updated to the 3.x prerelease version (used by
|
||||||
|
most distributions) and supports DRI3 now.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -3,250 +3,471 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-16.03">
|
xml:id="sec-release-16.03">
|
||||||
|
<title>Release 16.03 (“Emu”, 2016/03/31)</title>
|
||||||
|
|
||||||
<title>Release 16.03 (“Emu”, 2016/03/31)</title>
|
<para>
|
||||||
|
In addition to numerous new and upgraded packages, this release has the
|
||||||
<para>In addition to numerous new and upgraded packages, this release
|
following highlights:
|
||||||
has the following highlights:</para>
|
</para>
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Systemd 229, bringing <link
|
<para>
|
||||||
|
Systemd 229, bringing
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/systemd/systemd/blob/v229/NEWS">numerous
|
xlink:href="https://github.com/systemd/systemd/blob/v229/NEWS">numerous
|
||||||
improvements</link> over 217.</para>
|
improvements</link> over 217.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Linux 4.4 (was 3.18).</para>
|
<para>
|
||||||
|
Linux 4.4 (was 3.18).
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>GCC 5.3 (was 4.9). Note that GCC 5 <link
|
<para>
|
||||||
|
GCC 5.3 (was 4.9). Note that GCC 5
|
||||||
|
<link
|
||||||
xlink:href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html">changes
|
xlink:href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html">changes
|
||||||
the C++ ABI in an incompatible way</link>; this may cause problems
|
the C++ ABI in an incompatible way</link>; this may cause problems if you
|
||||||
if you try to link objects compiled with different versions of
|
try to link objects compiled with different versions of GCC.
|
||||||
GCC.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Glibc 2.23 (was 2.21).</para>
|
<para>
|
||||||
|
Glibc 2.23 (was 2.21).
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Binutils 2.26 (was 2.23.1). See #909</para>
|
<para>
|
||||||
|
Binutils 2.26 (was 2.23.1). See #909
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Improved support for ensuring <link
|
<para>
|
||||||
xlink:href="https://reproducible-builds.org/">bitwise reproducible
|
Improved support for ensuring
|
||||||
builds</link>. For example, <literal>stdenv</literal> now sets the
|
<link
|
||||||
environment variable <envar
|
xlink:href="https://reproducible-builds.org/">bitwise
|
||||||
|
reproducible builds</link>. For example, <literal>stdenv</literal> now sets
|
||||||
|
the environment variable
|
||||||
|
<envar
|
||||||
xlink:href="https://reproducible-builds.org/specs/source-date-epoch/">SOURCE_DATE_EPOCH</envar>
|
xlink:href="https://reproducible-builds.org/specs/source-date-epoch/">SOURCE_DATE_EPOCH</envar>
|
||||||
to a deterministic value, and Nix has <link
|
to a deterministic value, and Nix has
|
||||||
|
<link
|
||||||
xlink:href="http://nixos.org/nix/manual/#ssec-relnotes-1.11">gained
|
xlink:href="http://nixos.org/nix/manual/#ssec-relnotes-1.11">gained
|
||||||
an option</link> to repeat a build a number of times to test
|
an option</link> to repeat a build a number of times to test determinism.
|
||||||
determinism. An ongoing project, the goal of exact reproducibility
|
An ongoing project, the goal of exact reproducibility is to allow binaries
|
||||||
is to allow binaries to be verified independently (e.g., a user
|
to be verified independently (e.g., a user might only trust binaries that
|
||||||
might only trust binaries that appear in three independent binary
|
appear in three independent binary caches).
|
||||||
caches).</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Perl 5.22.</para>
|
<para>
|
||||||
|
Perl 5.22.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
</itemizedlist>
|
<para>
|
||||||
|
The following new services were added since the last release:
|
||||||
<para>The following new services were added since the last release:
|
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><literal>services/monitoring/longview.nix</literal></para></listitem>
|
<listitem>
|
||||||
<listitem><para><literal>hardware/video/webcam/facetimehd.nix</literal></para></listitem>
|
<para>
|
||||||
<listitem><para><literal>i18n/input-method/default.nix</literal></para></listitem>
|
<literal>services/monitoring/longview.nix</literal>
|
||||||
<listitem><para><literal>i18n/input-method/fcitx.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>i18n/input-method/ibus.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>i18n/input-method/nabi.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>i18n/input-method/uim.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>programs/fish.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>security/acme.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>security/audit.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>security/oath.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/hardware/irqbalance.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/mail/dspam.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/mail/opendkim.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/mail/postsrsd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/mail/rspamd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/mail/rmilter.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/autofs.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/bepasty.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/calibre-server.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/cfdyndns.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/gammu-smsd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/mathics.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/matrix-synapse.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/misc/octoprint.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/monitoring/hdaps.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/monitoring/heapster.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/monitoring/longview.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/network-filesystems/netatalk.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/network-filesystems/xtreemfs.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/autossh.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/dnschain.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/gale.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/miniupnpd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/namecoind.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/ostinato.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/pdnsd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/shairport-sync.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/networking/supplicant.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/search/kibana.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/security/haka.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/security/physlock.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/web-apps/pump.io.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/x11/hardware/libinput.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>services/x11/window-managers/windowlab.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>system/boot/initrd-network.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>system/boot/initrd-ssh.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>system/boot/loader/loader.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>system/boot/networkd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>system/boot/resolved.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>virtualisation/lxd.nix</literal></para></listitem>
|
|
||||||
<listitem><para><literal>virtualisation/rkt.nix</literal></para></listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>When upgrading from a previous release, please be aware of the
|
|
||||||
following incompatible changes:</para>
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>We no longer produce graphical ISO images and VirtualBox
|
|
||||||
images for <literal>i686-linux</literal>. A minimal ISO image is
|
|
||||||
still provided.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>Firefox and similar browsers are now <emphasis>wrapped by default</emphasis>.
|
|
||||||
The package and attribute names are plain <literal>firefox</literal>
|
|
||||||
or <literal>midori</literal>, etc. Backward-compatibility attributes were set up,
|
|
||||||
but note that <command>nix-env -u</command> will <emphasis>not</emphasis> update
|
|
||||||
your current <literal>firefox-with-plugins</literal>;
|
|
||||||
you have to uninstall it and install <literal>firefox</literal> instead.</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para><command>wmiiSnap</command> has been replaced with
|
|
||||||
<command>wmii_hg</command>, but
|
|
||||||
<command>services.xserver.windowManager.wmii.enable</command> has
|
|
||||||
been updated respectively so this only affects you if you have
|
|
||||||
explicitly installed <command>wmiiSnap</command>.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>hardware/video/webcam/facetimehd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>i18n/input-method/default.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>i18n/input-method/fcitx.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>i18n/input-method/ibus.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>i18n/input-method/nabi.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>i18n/input-method/uim.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>programs/fish.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>security/acme.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>security/audit.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>security/oath.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/hardware/irqbalance.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/mail/dspam.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/mail/opendkim.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/mail/postsrsd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/mail/rspamd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/mail/rmilter.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/autofs.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/bepasty.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/calibre-server.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/cfdyndns.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/gammu-smsd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/mathics.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/matrix-synapse.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/misc/octoprint.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/monitoring/hdaps.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/monitoring/heapster.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/monitoring/longview.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/network-filesystems/netatalk.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/network-filesystems/xtreemfs.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/autossh.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/dnschain.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/gale.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/miniupnpd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/namecoind.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/ostinato.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/pdnsd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/shairport-sync.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/networking/supplicant.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/search/kibana.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/security/haka.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/security/physlock.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/web-apps/pump.io.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/x11/hardware/libinput.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>services/x11/window-managers/windowlab.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>system/boot/initrd-network.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>system/boot/initrd-ssh.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>system/boot/loader/loader.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>system/boot/networkd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>system/boot/resolved.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>virtualisation/lxd.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>virtualisation/rkt.nix</literal>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When upgrading from a previous release, please be aware of the following
|
||||||
|
incompatible changes:
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>jobs</literal> NixOS option has been removed. It served as
|
<para>
|
||||||
|
We no longer produce graphical ISO images and VirtualBox images for
|
||||||
|
<literal>i686-linux</literal>. A minimal ISO image is still provided.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Firefox and similar browsers are now <emphasis>wrapped by
|
||||||
|
default</emphasis>. The package and attribute names are plain
|
||||||
|
<literal>firefox</literal> or <literal>midori</literal>, etc.
|
||||||
|
Backward-compatibility attributes were set up, but note that
|
||||||
|
<command>nix-env -u</command> will <emphasis>not</emphasis> update your
|
||||||
|
current <literal>firefox-with-plugins</literal>; you have to uninstall it
|
||||||
|
and install <literal>firefox</literal> instead.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<command>wmiiSnap</command> has been replaced with
|
||||||
|
<command>wmii_hg</command>, but
|
||||||
|
<command>services.xserver.windowManager.wmii.enable</command> has been
|
||||||
|
updated respectively so this only affects you if you have explicitly
|
||||||
|
installed <command>wmiiSnap</command>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<literal>jobs</literal> NixOS option has been removed. It served as
|
||||||
compatibility layer between Upstart jobs and SystemD services. All services
|
compatibility layer between Upstart jobs and SystemD services. All services
|
||||||
have been rewritten to use <literal>systemd.services</literal></para>
|
have been rewritten to use <literal>systemd.services</literal>
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><command>wmiimenu</command> is removed, as it has been
|
<para>
|
||||||
removed by the developers upstream. Use <command>wimenu</command>
|
<command>wmiimenu</command> is removed, as it has been removed by the
|
||||||
from the <command>wmii-hg</command> package.</para>
|
developers upstream. Use <command>wimenu</command> from the
|
||||||
|
<command>wmii-hg</command> package.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Gitit is no longer automatically added to the module list in
|
<para>
|
||||||
NixOS and as such there will not be any manual entries for it. You
|
Gitit is no longer automatically added to the module list in NixOS and as
|
||||||
will need to add an import statement to your NixOS configuration
|
such there will not be any manual entries for it. You will need to add an
|
||||||
in order to use it, e.g.
|
import statement to your NixOS configuration in order to use it, e.g.
|
||||||
|
|
||||||
<programlisting><![CDATA[
|
<programlisting><![CDATA[
|
||||||
{
|
{
|
||||||
imports = [ <nixpkgs/nixos/modules/services/misc/gitit.nix> ];
|
imports = [ <nixpkgs/nixos/modules/services/misc/gitit.nix> ];
|
||||||
}
|
}
|
||||||
]]></programlisting>
|
]]></programlisting>
|
||||||
|
will include the Gitit service configuration options.
|
||||||
will include the Gitit service configuration options.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><command>nginx</command> does not accept flags for enabling and
|
<para>
|
||||||
disabling modules anymore. Instead it accepts <literal>modules</literal>
|
<command>nginx</command> does not accept flags for enabling and disabling
|
||||||
argument, which is a list of modules to be built in. All modules now
|
modules anymore. Instead it accepts <literal>modules</literal> argument,
|
||||||
reside in <literal>nginxModules</literal> set. Example configuration:
|
which is a list of modules to be built in. All modules now reside in
|
||||||
|
<literal>nginxModules</literal> set. Example configuration:
|
||||||
<programlisting><![CDATA[
|
<programlisting><![CDATA[
|
||||||
nginx.override {
|
nginx.override {
|
||||||
modules = [ nginxModules.rtmp nginxModules.dav nginxModules.moreheaders ];
|
modules = [ nginxModules.rtmp nginxModules.dav nginxModules.moreheaders ];
|
||||||
}
|
}
|
||||||
]]></programlisting>
|
]]></programlisting>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><command>s3sync</command> is removed, as it hasn't been
|
<para>
|
||||||
developed by upstream for 4 years and only runs with ruby 1.8.
|
<command>s3sync</command> is removed, as it hasn't been developed by
|
||||||
For an actively-developer alternative look at
|
upstream for 4 years and only runs with ruby 1.8. For an actively-developer
|
||||||
<command>tarsnap</command> and others.
|
alternative look at <command>tarsnap</command> and others.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><command>ruby_1_8</command> has been removed as it's not
|
<para>
|
||||||
supported from upstream anymore and probably contains security
|
<command>ruby_1_8</command> has been removed as it's not supported from
|
||||||
issues.
|
upstream anymore and probably contains security issues.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>tidy-html5</literal> package is removed.
|
<para>
|
||||||
Upstream only provided <literal>(lib)tidy5</literal> during development,
|
<literal>tidy-html5</literal> package is removed. Upstream only provided
|
||||||
and now they went back to <literal>(lib)tidy</literal> to work as a drop-in
|
<literal>(lib)tidy5</literal> during development, and now they went back to
|
||||||
replacement of the original package that has been unmaintained for years.
|
<literal>(lib)tidy</literal> to work as a drop-in replacement of the
|
||||||
You can (still) use the <literal>html-tidy</literal> package, which got updated
|
original package that has been unmaintained for years. You can (still) use
|
||||||
to a stable release from this new upstream.</para>
|
the <literal>html-tidy</literal> package, which got updated to a stable
|
||||||
|
release from this new upstream.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>extraDeviceOptions</literal> argument is removed
|
<para>
|
||||||
from <literal>bumblebee</literal> package. Instead there are
|
<literal>extraDeviceOptions</literal> argument is removed from
|
||||||
now two separate arguments: <literal>extraNvidiaDeviceOptions</literal>
|
<literal>bumblebee</literal> package. Instead there are now two separate
|
||||||
and <literal>extraNouveauDeviceOptions</literal> for setting
|
arguments: <literal>extraNvidiaDeviceOptions</literal> and
|
||||||
extra X11 options for nvidia and nouveau drivers, respectively.
|
<literal>extraNouveauDeviceOptions</literal> for setting extra X11 options
|
||||||
</para>
|
for nvidia and nouveau drivers, respectively.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The <literal>Ctrl+Alt+Backspace</literal> key combination
|
<para>
|
||||||
no longer kills the X server by default.
|
The <literal>Ctrl+Alt+Backspace</literal> key combination no longer kills
|
||||||
There's a new option <option>services.xserver.enableCtrlAltBackspace</option>
|
the X server by default. There's a new option
|
||||||
allowing to enable the combination again.
|
<option>services.xserver.enableCtrlAltBackspace</option> allowing to enable
|
||||||
</para>
|
the combination again.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>emacsPackagesNg</literal> now contains all packages
|
<para>
|
||||||
from the ELPA, MELPA, and MELPA Stable repositories.
|
<literal>emacsPackagesNg</literal> now contains all packages from the ELPA,
|
||||||
</para>
|
MELPA, and MELPA Stable repositories.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Data directory for Postfix MTA server is moved from
|
<para>
|
||||||
|
Data directory for Postfix MTA server is moved from
|
||||||
<filename>/var/postfix</filename> to <filename>/var/lib/postfix</filename>.
|
<filename>/var/postfix</filename> to <filename>/var/lib/postfix</filename>.
|
||||||
Old configurations are migrated automatically. <literal>service.postfix</literal>
|
Old configurations are migrated automatically.
|
||||||
module has also received many improvements, such as correct directories' access
|
<literal>service.postfix</literal> module has also received many
|
||||||
rights, new <literal>aliasFiles</literal> and <literal>mapFiles</literal>
|
improvements, such as correct directories' access rights, new
|
||||||
options and more.</para>
|
<literal>aliasFiles</literal> and <literal>mapFiles</literal> options and
|
||||||
|
more.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Filesystem options should now be configured as a list of strings, not
|
<para>
|
||||||
a comma-separated string. The old style will continue to work, but print a
|
Filesystem options should now be configured as a list of strings, not a
|
||||||
|
comma-separated string. The old style will continue to work, but print a
|
||||||
warning, until the 16.09 release. An example of the new style:
|
warning, until the 16.09 release. An example of the new style:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
fileSystems."/example" = {
|
fileSystems."/example" = {
|
||||||
device = "/dev/sdc";
|
device = "/dev/sdc";
|
||||||
@ -254,103 +475,103 @@ fileSystems."/example" = {
|
|||||||
options = [ "noatime" "compress=lzo" "space_cache" "autodefrag" ];
|
options = [ "noatime" "compress=lzo" "space_cache" "autodefrag" ];
|
||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>CUPS, installed by <literal>services.printing</literal> module, now
|
<para>
|
||||||
has its data directory in <filename>/var/lib/cups</filename>. Old
|
CUPS, installed by <literal>services.printing</literal> module, now has its
|
||||||
configurations from <filename>/etc/cups</filename> are moved there
|
data directory in <filename>/var/lib/cups</filename>. Old configurations
|
||||||
automatically, but there might be problems. Also configuration options
|
from <filename>/etc/cups</filename> are moved there automatically, but
|
||||||
|
there might be problems. Also configuration options
|
||||||
<literal>services.printing.cupsdConf</literal> and
|
<literal>services.printing.cupsdConf</literal> and
|
||||||
<literal>services.printing.cupsdFilesConf</literal> were removed
|
<literal>services.printing.cupsdFilesConf</literal> were removed because
|
||||||
because they had been allowing one to override configuration variables
|
they had been allowing one to override configuration variables required for
|
||||||
required for CUPS to work at all on NixOS. For most use cases,
|
CUPS to work at all on NixOS. For most use cases,
|
||||||
<literal>services.printing.extraConf</literal> and new option
|
<literal>services.printing.extraConf</literal> and new option
|
||||||
<literal>services.printing.extraFilesConf</literal> should be enough;
|
<literal>services.printing.extraFilesConf</literal> should be enough; if
|
||||||
if you encounter a situation when they are not, please file a bug.</para>
|
you encounter a situation when they are not, please file a bug.
|
||||||
|
</para>
|
||||||
<para>There are also Gutenprint improvements; in particular, a new option
|
<para>
|
||||||
<literal>services.printing.gutenprint</literal> is added to enable automatic
|
There are also Gutenprint improvements; in particular, a new option
|
||||||
updating of Gutenprint PPMs; it's greatly recommended to enable it instead
|
<literal>services.printing.gutenprint</literal> is added to enable
|
||||||
of adding <literal>gutenprint</literal> to the <literal>drivers</literal> list.
|
automatic updating of Gutenprint PPMs; it's greatly recommended to enable
|
||||||
</para>
|
it instead of adding <literal>gutenprint</literal> to the
|
||||||
|
<literal>drivers</literal> list.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>services.xserver.vaapiDrivers</literal> has been removed. Use
|
<para>
|
||||||
<literal>hardware.opengl.extraPackages{,32}</literal> instead. You can
|
<literal>services.xserver.vaapiDrivers</literal> has been removed. Use
|
||||||
also specify VDPAU drivers there.</para>
|
<literal>hardware.opengl.extraPackages{,32}</literal> instead. You can also
|
||||||
|
specify VDPAU drivers there.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>programs.ibus</literal> moved to <literal>i18n.inputMethod.ibus</literal>.
|
<literal>programs.ibus</literal> moved to
|
||||||
The option <literal>programs.ibus.plugins</literal> changed to <literal>i18n.inputMethod.ibus.engines</literal>
|
<literal>i18n.inputMethod.ibus</literal>. The option
|
||||||
and the option to enable ibus changed from <literal>programs.ibus.enable</literal> to
|
<literal>programs.ibus.plugins</literal> changed to
|
||||||
|
<literal>i18n.inputMethod.ibus.engines</literal> and the option to enable
|
||||||
|
ibus changed from <literal>programs.ibus.enable</literal> to
|
||||||
<literal>i18n.inputMethod.enabled</literal>.
|
<literal>i18n.inputMethod.enabled</literal>.
|
||||||
<literal>i18n.inputMethod.enabled</literal> should be set to the used input method name,
|
<literal>i18n.inputMethod.enabled</literal> should be set to the used input
|
||||||
<literal>"ibus"</literal> for ibus.
|
method name, <literal>"ibus"</literal> for ibus. An example of the new
|
||||||
An example of the new style:
|
style:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
i18n.inputMethod.enabled = "ibus";
|
i18n.inputMethod.enabled = "ibus";
|
||||||
i18n.inputMethod.ibus.engines = with pkgs.ibus-engines; [ anthy mozc ];
|
i18n.inputMethod.ibus.engines = with pkgs.ibus-engines; [ anthy mozc ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
That is equivalent to the old version:
|
||||||
That is equivalent to the old version:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
programs.ibus.enable = true;
|
programs.ibus.enable = true;
|
||||||
programs.ibus.plugins = with pkgs; [ ibus-anthy mozc ];
|
programs.ibus.plugins = with pkgs; [ ibus-anthy mozc ];
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>services.udev.extraRules</literal> option now writes rules
|
<para>
|
||||||
to <filename>99-local.rules</filename> instead of <filename>10-local.rules</filename>.
|
<literal>services.udev.extraRules</literal> option now writes rules to
|
||||||
This makes all the user rules apply after others, so their results wouldn't be
|
<filename>99-local.rules</filename> instead of
|
||||||
overriden by anything else.</para>
|
<filename>10-local.rules</filename>. This makes all the user rules apply
|
||||||
|
after others, so their results wouldn't be overriden by anything else.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Large parts of the <literal>services.gitlab</literal> module has been
|
<para>
|
||||||
been rewritten. There are new configuration options available. The
|
Large parts of the <literal>services.gitlab</literal> module has been been
|
||||||
|
rewritten. There are new configuration options available. The
|
||||||
<literal>stateDir</literal> option was renamned to
|
<literal>stateDir</literal> option was renamned to
|
||||||
<literal>statePath</literal> and the <literal>satellitesDir</literal> option
|
<literal>statePath</literal> and the <literal>satellitesDir</literal>
|
||||||
was removed. Please review the currently available options.</para>
|
option was removed. Please review the currently available options.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The option <option>services.nsd.zones.<name>.data</option> no
|
The option <option>services.nsd.zones.<name>.data</option> no longer
|
||||||
longer interpret the dollar sign ($) as a shell variable, as such it
|
interpret the dollar sign ($) as a shell variable, as such it should not be
|
||||||
should not be escaped anymore. Thus the following zone data:
|
escaped anymore. Thus the following zone data:
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
\$ORIGIN example.com.
|
\$ORIGIN example.com.
|
||||||
\$TTL 1800
|
\$TTL 1800
|
||||||
@ IN SOA ns1.vpn.nbp.name. admin.example.com. (
|
@ IN SOA ns1.vpn.nbp.name. admin.example.com. (
|
||||||
</programlisting>
|
</programlisting>
|
||||||
<para>
|
<para>
|
||||||
Should modified to look like the actual file expected by nsd:
|
Should modified to look like the actual file expected by nsd:
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
$ORIGIN example.com.
|
$ORIGIN example.com.
|
||||||
$TTL 1800
|
$TTL 1800
|
||||||
@ IN SOA ns1.vpn.nbp.name. admin.example.com. (
|
@ IN SOA ns1.vpn.nbp.name. admin.example.com. (
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>service.syncthing.dataDir</literal> options now has to point
|
<literal>service.syncthing.dataDir</literal> options now has to point to
|
||||||
to exact folder where syncthing is writing to. Example configuration should
|
exact folder where syncthing is writing to. Example configuration should
|
||||||
look something like:
|
look something like:
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
services.syncthing = {
|
services.syncthing = {
|
||||||
enable = true;
|
enable = true;
|
||||||
dataDir = "/home/somebody/.syncthing";
|
dataDir = "/home/somebody/.syncthing";
|
||||||
@ -358,76 +579,73 @@ services.syncthing = {
|
|||||||
};
|
};
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>networking.firewall.allowPing</literal> is now enabled by
|
<literal>networking.firewall.allowPing</literal> is now enabled by default.
|
||||||
default. Users are encouraged to configure an appropriate rate limit for
|
Users are encouraged to configure an appropriate rate limit for their
|
||||||
their machines using the Kernel interface at
|
machines using the Kernel interface at
|
||||||
<filename>/proc/sys/net/ipv4/icmp_ratelimit</filename> and
|
<filename>/proc/sys/net/ipv4/icmp_ratelimit</filename> and
|
||||||
<filename>/proc/sys/net/ipv6/icmp/ratelimit</filename> or using the
|
<filename>/proc/sys/net/ipv6/icmp/ratelimit</filename> or using the
|
||||||
firewall itself, i.e. by setting the NixOS option
|
firewall itself, i.e. by setting the NixOS option
|
||||||
<literal>networking.firewall.pingLimit</literal>.
|
<literal>networking.firewall.pingLimit</literal>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Systems with some broadcom cards used to result into a generated config
|
Systems with some broadcom cards used to result into a generated config
|
||||||
that is no longer accepted. If you get errors like
|
that is no longer accepted. If you get errors like
|
||||||
<screen>error: path ‘/nix/store/*-broadcom-sta-*’ does not exist and cannot be created</screen>
|
<screen>error: path ‘/nix/store/*-broadcom-sta-*’ does not exist and cannot be created</screen>
|
||||||
you should either re-run <command>nixos-generate-config</command> or manually replace
|
you should either re-run <command>nixos-generate-config</command> or
|
||||||
<literal>"${config.boot.kernelPackages.broadcom_sta}"</literal>
|
manually replace
|
||||||
by
|
<literal>"${config.boot.kernelPackages.broadcom_sta}"</literal> by
|
||||||
<literal>config.boot.kernelPackages.broadcom_sta</literal>
|
<literal>config.boot.kernelPackages.broadcom_sta</literal> in your
|
||||||
in your <filename>/etc/nixos/hardware-configuration.nix</filename>.
|
<filename>/etc/nixos/hardware-configuration.nix</filename>. More discussion
|
||||||
More discussion is on <link xlink:href="https://github.com/NixOS/nixpkgs/pull/12595">
|
is on <link xlink:href="https://github.com/NixOS/nixpkgs/pull/12595"> the
|
||||||
the github issue</link>.
|
github issue</link>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The <literal>services.xserver.startGnuPGAgent</literal> option has been removed.
|
The <literal>services.xserver.startGnuPGAgent</literal> option has been
|
||||||
GnuPG 2.1.x changed the way the gpg-agent works, and that new approach no
|
removed. GnuPG 2.1.x changed the way the gpg-agent works, and that new
|
||||||
longer requires (or even supports) the "start everything as a child of the
|
approach no longer requires (or even supports) the "start everything as a
|
||||||
agent" scheme we've implemented in NixOS for older versions.
|
child of the agent" scheme we've implemented in NixOS for older versions.
|
||||||
To configure the gpg-agent for your X session, add the following code to
|
To configure the gpg-agent for your X session, add the following code to
|
||||||
<filename>~/.bashrc</filename> or some file that’s sourced when your shell is started:
|
<filename>~/.bashrc</filename> or some file that’s sourced when your
|
||||||
<programlisting>
|
shell is started:
|
||||||
|
<programlisting>
|
||||||
GPG_TTY=$(tty)
|
GPG_TTY=$(tty)
|
||||||
export GPG_TTY
|
export GPG_TTY
|
||||||
</programlisting>
|
</programlisting>
|
||||||
If you want to use gpg-agent for SSH, too, add the following to your session
|
If you want to use gpg-agent for SSH, too, add the following to your
|
||||||
initialization (e.g. <literal>displayManager.sessionCommands</literal>)
|
session initialization (e.g.
|
||||||
<programlisting>
|
<literal>displayManager.sessionCommands</literal>)
|
||||||
|
<programlisting>
|
||||||
gpg-connect-agent /bye
|
gpg-connect-agent /bye
|
||||||
unset SSH_AGENT_PID
|
unset SSH_AGENT_PID
|
||||||
export SSH_AUTH_SOCK="''${HOME}/.gnupg/S.gpg-agent.ssh"
|
export SSH_AUTH_SOCK="''${HOME}/.gnupg/S.gpg-agent.ssh"
|
||||||
</programlisting>
|
</programlisting>
|
||||||
and make sure that
|
and make sure that
|
||||||
<programlisting>
|
<programlisting>
|
||||||
enable-ssh-support
|
enable-ssh-support
|
||||||
</programlisting>
|
</programlisting>
|
||||||
is included in your <filename>~/.gnupg/gpg-agent.conf</filename>.
|
is included in your <filename>~/.gnupg/gpg-agent.conf</filename>. You will
|
||||||
You will need to use <command>ssh-add</command> to re-add your ssh keys.
|
need to use <command>ssh-add</command> to re-add your ssh keys. If gpg’s
|
||||||
If gpg’s automatic transformation of the private keys to the new format fails,
|
automatic transformation of the private keys to the new format fails, you
|
||||||
you will need to re-import your private keyring as well:
|
will need to re-import your private keyring as well:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
gpg --import ~/.gnupg/secring.gpg
|
gpg --import ~/.gnupg/secring.gpg
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The <command>gpg-agent(1)</command> man page has more details about this subject,
|
The <command>gpg-agent(1)</command> man page has more details about this
|
||||||
i.e. in the "EXAMPLES" section.
|
subject, i.e. in the "EXAMPLES" section.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>
|
||||||
<para>Other notable improvements:
|
Other notable improvements:
|
||||||
|
<itemizedlist>
|
||||||
<itemizedlist>
|
<!--
|
||||||
|
|
||||||
<!--
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The <command>command-not-found</command> hook was extended.
|
<para>The <command>command-not-found</command> hook was extended.
|
||||||
Apart from <literal>$NIX_AUTO_INSTALL</literal> variable,
|
Apart from <literal>$NIX_AUTO_INSTALL</literal> variable,
|
||||||
@ -436,18 +654,18 @@ gpg --import ~/.gnupg/secring.gpg
|
|||||||
<command>nix-shell</command> (without installing anything).</para>
|
<command>nix-shell</command> (without installing anything).</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
-->
|
-->
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para><literal>ejabberd</literal> module is brought back and now works on
|
<literal>ejabberd</literal> module is brought back and now works on NixOS.
|
||||||
NixOS.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem>
|
<para>
|
||||||
<para>Input method support was improved. New NixOS modules (fcitx, nabi and uim),
|
Input method support was improved. New NixOS modules (fcitx, nabi and
|
||||||
fcitx engines (chewing, hangul, m17n, mozc and table-other) and ibus engines (hangul and m17n)
|
uim), fcitx engines (chewing, hangul, m17n, mozc and table-other) and ibus
|
||||||
have been added.</para>
|
engines (hangul and m17n) have been added.
|
||||||
</listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
</itemizedlist></para>
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -3,237 +3,275 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-16.09">
|
xml:id="sec-release-16.09">
|
||||||
|
<title>Release 16.09 (“Flounder”, 2016/09/30)</title>
|
||||||
|
|
||||||
<title>Release 16.09 (“Flounder”, 2016/09/30)</title>
|
<para>
|
||||||
|
In addition to numerous new and upgraded packages, this release has the
|
||||||
<para>In addition to numerous new and upgraded packages, this release
|
following highlights:
|
||||||
has the following highlights: </para>
|
</para>
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Many NixOS configurations and Nix packages now use
|
<para>
|
||||||
significantly less disk space, thanks to the <link
|
Many NixOS configurations and Nix packages now use significantly less disk
|
||||||
|
space, thanks to the
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/issues/7117">extensive
|
xlink:href="https://github.com/NixOS/nixpkgs/issues/7117">extensive
|
||||||
work on closure size reduction</link>. For example, the closure
|
work on closure size reduction</link>. For example, the closure size of a
|
||||||
size of a minimal NixOS container went down from ~424 MiB in 16.03
|
minimal NixOS container went down from ~424 MiB in 16.03 to ~212 MiB in
|
||||||
to ~212 MiB in 16.09, while the closure size of Firefox went from
|
16.09, while the closure size of Firefox went from ~651 MiB to ~259 MiB.
|
||||||
~651 MiB to ~259 MiB.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>To improve security, packages are now <link
|
<para>
|
||||||
|
To improve security, packages are now
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/pull/12895">built
|
xlink:href="https://github.com/NixOS/nixpkgs/pull/12895">built
|
||||||
using various hardening features</link>. See the Nixpkgs manual
|
using various hardening features</link>. See the Nixpkgs manual for more
|
||||||
for more information.</para>
|
information.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Support for PXE netboot. See <xref
|
<para>
|
||||||
linkend="sec-booting-from-pxe" /> for documentation.</para>
|
Support for PXE netboot. See <xref
|
||||||
|
linkend="sec-booting-from-pxe" />
|
||||||
|
for documentation.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>X.org server 1.18. If you use the
|
<para>
|
||||||
<literal>ati_unfree</literal> driver, 1.17 is still used due to an
|
X.org server 1.18. If you use the <literal>ati_unfree</literal> driver,
|
||||||
ABI incompatibility.</para>
|
1.17 is still used due to an ABI incompatibility.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>This release is based on Glibc 2.24, GCC 5.4.0 and systemd
|
<para>
|
||||||
231. The default Linux kernel remains 4.4.</para>
|
This release is based on Glibc 2.24, GCC 5.4.0 and systemd 231. The default
|
||||||
|
Linux kernel remains 4.4.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
</itemizedlist>
|
<para>
|
||||||
|
The following new services were added since the last release:
|
||||||
<para>The following new services were added since the last release:</para>
|
</para>
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem><para><literal>(this will get automatically generated at release time)</literal></para></listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
|
|
||||||
<para>When upgrading from a previous release, please be aware of the
|
|
||||||
following incompatible changes:</para>
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>A large number of packages have been converted to use the multiple outputs feature
|
<para>
|
||||||
of Nix to greatly reduce the amount of required disk space, as
|
<literal>(this will get automatically generated at release time)</literal>
|
||||||
mentioned above. This may require changes
|
</para>
|
||||||
to any custom packages to make them build again; see the relevant chapter in the
|
|
||||||
Nixpkgs manual for more information. (Additional caveat to packagers: some packaging conventions
|
|
||||||
related to multiple-output packages
|
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/14766">were changed</link>
|
|
||||||
late (August 2016) in the release cycle and differ from the initial introduction of multiple outputs.)
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When upgrading from a previous release, please be aware of the following
|
||||||
|
incompatible changes:
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Previous versions of Nixpkgs had support for all versions of the LTS
|
<para>
|
||||||
|
A large number of packages have been converted to use the multiple outputs
|
||||||
|
feature of Nix to greatly reduce the amount of required disk space, as
|
||||||
|
mentioned above. This may require changes to any custom packages to make
|
||||||
|
them build again; see the relevant chapter in the Nixpkgs manual for more
|
||||||
|
information. (Additional caveat to packagers: some packaging conventions
|
||||||
|
related to multiple-output packages
|
||||||
|
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/14766">were
|
||||||
|
changed</link> late (August 2016) in the release cycle and differ from the
|
||||||
|
initial introduction of multiple outputs.)
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Previous versions of Nixpkgs had support for all versions of the LTS
|
||||||
Haskell package set. That support has been dropped. The previously provided
|
Haskell package set. That support has been dropped. The previously provided
|
||||||
<literal>haskell.packages.lts-x_y</literal> package sets still exist in
|
<literal>haskell.packages.lts-x_y</literal> package sets still exist in
|
||||||
name to aviod breaking user code, but these package sets don't actually
|
name to aviod breaking user code, but these package sets don't actually
|
||||||
contain the versions mandated by the corresponding LTS release. Instead,
|
contain the versions mandated by the corresponding LTS release. Instead,
|
||||||
our package set it loosely based on the latest available LTS release, i.e.
|
our package set it loosely based on the latest available LTS release, i.e.
|
||||||
LTS 7.x at the time of this writing. New releases of NixOS and Nixpkgs will
|
LTS 7.x at the time of this writing. New releases of NixOS and Nixpkgs will
|
||||||
drop those old names entirely. <link
|
drop those old names entirely.
|
||||||
|
<link
|
||||||
xlink:href="https://nixos.org/nix-dev/2016-June/020585.html">The
|
xlink:href="https://nixos.org/nix-dev/2016-June/020585.html">The
|
||||||
motivation for this change</link> has been discussed at length on the
|
motivation for this change</link> has been discussed at length on the
|
||||||
<literal>nix-dev</literal> mailing list and in <link
|
<literal>nix-dev</literal> mailing list and in
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/issues/14897">Github issue
|
<link
|
||||||
#14897</link>. Development strategies for Haskell hackers who want to rely
|
xlink:href="https://github.com/NixOS/nixpkgs/issues/14897">Github
|
||||||
on Nix and NixOS have been described in <link
|
issue #14897</link>. Development strategies for Haskell hackers who want to
|
||||||
|
rely on Nix and NixOS have been described in
|
||||||
|
<link
|
||||||
xlink:href="https://nixos.org/nix-dev/2016-June/020642.html">another
|
xlink:href="https://nixos.org/nix-dev/2016-June/020642.html">another
|
||||||
nix-dev article</link>.</para>
|
nix-dev article</link>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Shell aliases for systemd sub-commands
|
<para>
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/15598">were dropped</link>:
|
Shell aliases for systemd sub-commands
|
||||||
<command>start</command>, <command>stop</command>,
|
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/15598">were
|
||||||
<command>restart</command>, <command>status</command>.</para>
|
dropped</link>: <command>start</command>, <command>stop</command>,
|
||||||
|
<command>restart</command>, <command>status</command>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Redis now binds to 127.0.0.1 only instead of listening to all network interfaces. This is the default
|
<para>
|
||||||
behavior of Redis 3.2</para>
|
Redis now binds to 127.0.0.1 only instead of listening to all network
|
||||||
|
interfaces. This is the default behavior of Redis 3.2
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>/var/empty</literal> is now immutable. Activation script runs <command>chattr +i</command>
|
<literal>/var/empty</literal> is now immutable. Activation script runs
|
||||||
to forbid any modifications inside the folder. See <link xlink:href="https://github.com/NixOS/nixpkgs/pull/18365">
|
<command>chattr +i</command> to forbid any modifications inside the folder.
|
||||||
the pull request</link> for what bugs this caused.
|
See <link xlink:href="https://github.com/NixOS/nixpkgs/pull/18365"> the
|
||||||
</para>
|
pull request</link> for what bugs this caused.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Gitlab's maintainance script
|
<para>
|
||||||
<command>gitlab-runner</command> was removed and split up into the
|
Gitlab's maintainance script <command>gitlab-runner</command> was removed
|
||||||
more clearer <command>gitlab-run</command> and
|
and split up into the more clearer <command>gitlab-run</command> and
|
||||||
<command>gitlab-rake</command> scripts, because
|
<command>gitlab-rake</command> scripts, because
|
||||||
<command>gitlab-runner</command> is a component of Gitlab
|
<command>gitlab-runner</command> is a component of Gitlab CI.
|
||||||
CI.</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>services.xserver.libinput.accelProfile</literal> default
|
<para>
|
||||||
changed from <literal>flat</literal> to <literal>adaptive</literal>,
|
<literal>services.xserver.libinput.accelProfile</literal> default changed
|
||||||
as per <link xlink:href="https://wayland.freedesktop.org/libinput/doc/latest/group__config.html#gad63796972347f318b180e322e35cee79">
|
from <literal>flat</literal> to <literal>adaptive</literal>, as per
|
||||||
official documentation</link>.</para>
|
<link xlink:href="https://wayland.freedesktop.org/libinput/doc/latest/group__config.html#gad63796972347f318b180e322e35cee79">
|
||||||
|
official documentation</link>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>fonts.fontconfig.ultimate.rendering</literal> was removed
|
<para>
|
||||||
because our presets were obsolete for some time. New presets are hardcoded
|
<literal>fonts.fontconfig.ultimate.rendering</literal> was removed because
|
||||||
into FreeType; you can select a preset via <literal>fonts.fontconfig.ultimate.preset</literal>.
|
our presets were obsolete for some time. New presets are hardcoded into
|
||||||
You can customize those presets via ordinary environment variables, using
|
FreeType; you can select a preset via
|
||||||
<literal>environment.variables</literal>.</para>
|
<literal>fonts.fontconfig.ultimate.preset</literal>. You can customize
|
||||||
|
those presets via ordinary environment variables, using
|
||||||
|
<literal>environment.variables</literal>.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The <literal>audit</literal> service is no longer enabled by default.
|
<para>
|
||||||
Use <literal>security.audit.enable = true</literal> to explicitly enable it.</para>
|
The <literal>audit</literal> service is no longer enabled by default. Use
|
||||||
|
<literal>security.audit.enable = true</literal> to explicitly enable it.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>pkgs.linuxPackages.virtualbox</literal> now contains only the
|
<literal>pkgs.linuxPackages.virtualbox</literal> now contains only the
|
||||||
kernel modules instead of the VirtualBox user space binaries.
|
kernel modules instead of the VirtualBox user space binaries. If you want
|
||||||
If you want to reference the user space binaries, you have to use the new
|
to reference the user space binaries, you have to use the new
|
||||||
<literal>pkgs.virtualbox</literal> instead.
|
<literal>pkgs.virtualbox</literal> instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>goPackages</literal> was replaced with separated Go
|
<para>
|
||||||
applications in appropriate <literal>nixpkgs</literal>
|
<literal>goPackages</literal> was replaced with separated Go applications
|
||||||
categories. Each Go package uses its own dependency set. There's
|
in appropriate <literal>nixpkgs</literal> categories. Each Go package uses
|
||||||
also a new <literal>go2nix</literal> tool introduced to generate a
|
its own dependency set. There's also a new <literal>go2nix</literal> tool
|
||||||
Go package definition from its Go source automatically.</para>
|
introduced to generate a Go package definition from its Go source
|
||||||
|
automatically.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>services.mongodb.extraConfig</literal> configuration format
|
<para>
|
||||||
was changed to YAML.</para>
|
<literal>services.mongodb.extraConfig</literal> configuration format was
|
||||||
|
changed to YAML.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
PHP has been upgraded to 7.0
|
PHP has been upgraded to 7.0
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Other notable improvements:
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>Other notable improvements:</para>
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
<itemizedlist>
|
<para>
|
||||||
|
Revamped grsecurity/PaX support. There is now only a single general-purpose
|
||||||
<listitem><para>Revamped grsecurity/PaX support. There is now only a single
|
distribution kernel and the configuration interface has been streamlined.
|
||||||
general-purpose distribution kernel and the configuration interface has been
|
Desktop users should be able to simply set
|
||||||
streamlined. Desktop users should be able to simply set
|
<programlisting>security.grsecurity.enable = true</programlisting>
|
||||||
<programlisting>security.grsecurity.enable = true</programlisting> to get
|
to get a reasonably secure system without having to sacrifice too much
|
||||||
a reasonably secure system without having to sacrifice too much
|
functionality.
|
||||||
functionality.
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>Special filesystems, like <literal>/proc</literal>,
|
<para>
|
||||||
<literal>/run</literal> and others, now have the same mount options
|
Special filesystems, like <literal>/proc</literal>, <literal>/run</literal>
|
||||||
as recommended by systemd and are unified across different places in
|
and others, now have the same mount options as recommended by systemd and
|
||||||
NixOS. Mount options are updated during <command>nixos-rebuild
|
are unified across different places in NixOS. Mount options are updated
|
||||||
switch</command> if possible. One benefit from this is improved
|
during <command>nixos-rebuild switch</command> if possible. One benefit
|
||||||
security — most such filesystems are now mounted with
|
from this is improved security — most such filesystems are now mounted
|
||||||
<literal>noexec</literal>, <literal>nodev</literal> and/or
|
with <literal>noexec</literal>, <literal>nodev</literal> and/or
|
||||||
<literal>nosuid</literal> options.</para></listitem>
|
<literal>nosuid</literal> options.
|
||||||
|
</para>
|
||||||
<listitem><para>The reverse path filter was interfering with DHCPv4 server
|
</listitem>
|
||||||
operation in the past. An exception for DHCPv4 and a new option to log
|
<listitem>
|
||||||
packets that were dropped due to the reverse path filter was added
|
<para>
|
||||||
(<literal>networking.firewall.logReversePathDrops</literal>) for easier
|
The reverse path filter was interfering with DHCPv4 server operation in the
|
||||||
debugging.</para></listitem>
|
past. An exception for DHCPv4 and a new option to log packets that were
|
||||||
|
dropped due to the reverse path filter was added
|
||||||
<listitem><para>Containers configuration within
|
(<literal>networking.firewall.logReversePathDrops</literal>) for easier
|
||||||
<literal>containers.<name>.config</literal> is <link
|
debugging.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Containers configuration within
|
||||||
|
<literal>containers.<name>.config</literal> is
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/pull/17365">now
|
xlink:href="https://github.com/NixOS/nixpkgs/pull/17365">now
|
||||||
properly typed and checked</link>. In particular, partial
|
properly typed and checked</link>. In particular, partial configurations
|
||||||
configurations are merged correctly.</para></listitem>
|
are merged correctly.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The directory container setuid wrapper programs,
|
<para>
|
||||||
<filename>/var/setuid-wrappers</filename>, <link
|
The directory container setuid wrapper programs,
|
||||||
|
<filename>/var/setuid-wrappers</filename>,
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/pull/18124">is now
|
xlink:href="https://github.com/NixOS/nixpkgs/pull/18124">is now
|
||||||
updated atomically to prevent failures if the switch to a new
|
updated atomically to prevent failures if the switch to a new configuration
|
||||||
configuration is interrupted.</link></para>
|
is interrupted.</link>
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para><literal>services.xserver.startGnuPGAgent</literal>
|
<para>
|
||||||
has been removed due to GnuPG 2.1.x bump. See <link
|
<literal>services.xserver.startGnuPGAgent</literal> has been removed due to
|
||||||
|
GnuPG 2.1.x bump. See
|
||||||
|
<link
|
||||||
xlink:href="https://github.com/NixOS/nixpkgs/commit/5391882ebd781149e213e8817fba6ac3c503740c">
|
xlink:href="https://github.com/NixOS/nixpkgs/commit/5391882ebd781149e213e8817fba6ac3c503740c">
|
||||||
how to achieve similar behavior</link>. You might need to
|
how to achieve similar behavior</link>. You might need to <literal>pkill
|
||||||
<literal>pkill gpg-agent</literal> after the upgrade
|
gpg-agent</literal> after the upgrade to prevent a stale agent being in the
|
||||||
to prevent a stale agent being in the way.
|
way.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>
|
<para>
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/e561edc322d275c3687fec431935095cfc717147">
|
<link xlink:href="https://github.com/NixOS/nixpkgs/commit/e561edc322d275c3687fec431935095cfc717147">
|
||||||
Declarative users could share the uid due to the bug in
|
Declarative users could share the uid due to the bug in the script handling
|
||||||
the script handling conflict resolution.
|
conflict resolution. </link>
|
||||||
</link>
|
</para>
|
||||||
</para></listitem>
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<listitem><para>
|
<para>
|
||||||
Gummi boot has been replaced using systemd-boot.
|
Gummi boot has been replaced using systemd-boot.
|
||||||
</para></listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
<listitem><para>
|
<listitem>
|
||||||
|
<para>
|
||||||
Hydra package and NixOS module were added for convenience.
|
Hydra package and NixOS module were added for convenience.
|
||||||
</para></listitem>
|
</para>
|
||||||
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -3,153 +3,158 @@
|
|||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-18.09">
|
xml:id="sec-release-18.09">
|
||||||
|
<title>Release 18.09 (“Jellyfish”, 2018/09/??)</title>
|
||||||
|
|
||||||
<title>Release 18.09 (“Jellyfish”, 2018/09/??)</title>
|
<section xmlns="http://docbook.org/ns/docbook"
|
||||||
|
|
||||||
<section xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-18.09-highlights">
|
xml:id="sec-release-18.09-highlights">
|
||||||
|
<title>Highlights</title>
|
||||||
|
|
||||||
<title>Highlights</title>
|
<para>
|
||||||
|
In addition to numerous new and upgraded packages, this release has the
|
||||||
|
following highlights:
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>In addition to numerous new and upgraded packages, this release
|
<itemizedlist>
|
||||||
has the following highlights: </para>
|
<listitem>
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
<para>
|
||||||
User channels are now in the default <literal>NIX_PATH</literal>,
|
User channels are now in the default <literal>NIX_PATH</literal>, allowing
|
||||||
allowing users to use their personal <command>nix-channel</command>
|
users to use their personal <command>nix-channel</command> defined
|
||||||
defined channels in <command>nix-build</command> and
|
channels in <command>nix-build</command> and <command>nix-shell</command>
|
||||||
<command>nix-shell</command> commands, as well as in imports like
|
commands, as well as in imports like <code>import
|
||||||
<code>import <mychannel></code>.
|
<mychannel></code>.
|
||||||
</para>
|
</para>
|
||||||
<para>For example</para>
|
<para>
|
||||||
<programlisting>
|
For example
|
||||||
|
</para>
|
||||||
|
<programlisting>
|
||||||
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgsunstable
|
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgsunstable
|
||||||
$ nix-channel --update
|
$ nix-channel --update
|
||||||
$ nix-build '<nixpkgsunstable>' -A gitFull
|
$ nix-build '<nixpkgsunstable>' -A gitFull
|
||||||
$ nix run -f '<nixpkgsunstable>' gitFull
|
$ nix run -f '<nixpkgsunstable>' gitFull
|
||||||
$ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
$ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
</section>
|
<section xmlns="http://docbook.org/ns/docbook"
|
||||||
<section xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-18.09-new-services">
|
xml:id="sec-release-18.09-new-services">
|
||||||
|
<title>New Services</title>
|
||||||
|
|
||||||
<title>New Services</title>
|
<para>
|
||||||
|
The following new services were added since the last release:
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>The following new services were added since the last release:</para>
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para></para>
|
<para></para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
</section>
|
<section xmlns="http://docbook.org/ns/docbook"
|
||||||
<section xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-18.09-incompatibilities">
|
xml:id="sec-release-18.09-incompatibilities">
|
||||||
|
<title>Backward Incompatibilities</title>
|
||||||
|
|
||||||
<title>Backward Incompatibilities</title>
|
<para>
|
||||||
|
When upgrading from a previous release, please be aware of the following
|
||||||
|
incompatible changes:
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>When upgrading from a previous release, please be aware of the
|
<itemizedlist>
|
||||||
following incompatible changes:</para>
|
<listitem>
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.strict</literal> is removed. Use <literal>builtins.seq</literal> instead.
|
<literal>lib.strict</literal> is removed. Use
|
||||||
|
<literal>builtins.seq</literal> instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The <literal>clementine</literal> package points now to the free derivation.
|
The <literal>clementine</literal> package points now to the free
|
||||||
<literal>clementineFree</literal> is removed now and <literal>clementineUnfree</literal>
|
derivation. <literal>clementineFree</literal> is removed now and
|
||||||
points to the package which is bundled with the unfree <literal>libspotify</literal> package.
|
<literal>clementineUnfree</literal> points to the package which is bundled
|
||||||
|
with the unfree <literal>libspotify</literal> package.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The <literal>netcat</literal> package is now taken directly from OpenBSD's
|
The <literal>netcat</literal> package is now taken directly from OpenBSD's
|
||||||
<literal>libressl</literal>, instead of relying on Debian's fork. The new
|
<literal>libressl</literal>, instead of relying on Debian's fork. The new
|
||||||
version should be very close to the old version, but there are some minor
|
version should be very close to the old version, but there are some minor
|
||||||
differences. Importantly, flags like -b, -q, -C, and -Z are no longer
|
differences. Importantly, flags like -b, -q, -C, and -Z are no longer
|
||||||
accepted by the nc command.
|
accepted by the nc command.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
</section>
|
<section xmlns="http://docbook.org/ns/docbook"
|
||||||
<section xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="sec-release-18.09-notable-changes">
|
xml:id="sec-release-18.09-notable-changes">
|
||||||
|
<title>Other Notable Changes</title>
|
||||||
|
|
||||||
<title>Other Notable Changes</title>
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.attrNamesToStr</literal> has been deprecated. Use
|
<literal>lib.attrNamesToStr</literal> has been deprecated. Use more
|
||||||
more specific concatenation (<literal>lib.concat(Map)StringsSep</literal>)
|
specific concatenation (<literal>lib.concat(Map)StringsSep</literal>)
|
||||||
instead.
|
instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.addErrorContextToAttrs</literal> has been deprecated. Use
|
<literal>lib.addErrorContextToAttrs</literal> has been deprecated. Use
|
||||||
<literal>builtins.addErrorContext</literal> directly.
|
<literal>builtins.addErrorContext</literal> directly.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.showVal</literal> has been deprecated. Use
|
<literal>lib.showVal</literal> has been deprecated. Use
|
||||||
<literal>lib.traceSeqN</literal> instead.
|
<literal>lib.traceSeqN</literal> instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.traceXMLVal</literal> has been deprecated. Use
|
<literal>lib.traceXMLVal</literal> has been deprecated. Use
|
||||||
<literal>lib.traceValFn builtins.toXml</literal> instead.
|
<literal>lib.traceValFn builtins.toXml</literal> instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.traceXMLValMarked</literal> has been deprecated. Use
|
<literal>lib.traceXMLValMarked</literal> has been deprecated. Use
|
||||||
<literal>lib.traceValFn (x: str + builtins.toXML x)</literal> instead.
|
<literal>lib.traceValFn (x: str + builtins.toXML x)</literal> instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.traceValIfNot</literal> has been deprecated. Use
|
<literal>lib.traceValIfNot</literal> has been deprecated. Use
|
||||||
<literal>if/then/else</literal> and <literal>lib.traceValSeq</literal>
|
<literal>if/then/else</literal> and <literal>lib.traceValSeq</literal>
|
||||||
instead.
|
instead.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>lib.traceCallXml</literal> has been deprecated. Please complain
|
<literal>lib.traceCallXml</literal> has been deprecated. Please complain
|
||||||
if you use the function regularly.
|
if you use the function regularly.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The attribute <literal>lib.nixpkgsVersion</literal> has been deprecated in favor of
|
The attribute <literal>lib.nixpkgsVersion</literal> has been deprecated in
|
||||||
<literal>lib.version</literal>. Please refer to the discussion in
|
favor of <literal>lib.version</literal>. Please refer to the discussion in
|
||||||
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745">NixOS/nixpkgs#39416</link> for further reference.
|
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745">NixOS/nixpkgs#39416</link>
|
||||||
|
for further reference.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
</section>
|
||||||
</section>
|
|
||||||
</section>
|
</section>
|
||||||
|
Loading…
Reference in New Issue
Block a user