mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-23 15:33:13 +00:00
Merge master into haskell-updates
This commit is contained in:
github-actions[bot]
GitHub
commit
8e64bf5a22
@ -34,4 +34,4 @@ buildContainer {
|
||||
|
||||
- `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
|
||||
|
||||
- `readonly` makes the container\'s rootfs read-only if it is set to true. The default value is false `false`.
|
||||
- `readonly` makes the container's rootfs read-only if it is set to true. The default value is false `false`.
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Compiling without AVX support {#compiling-without-avx-support}
|
||||
|
||||
Especially older CPUs don\'t support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
|
||||
Especially older CPUs don't support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
|
||||
|
||||
On the affected hardware errors like `Illegal instruction` will occur. In those cases AVX support needs to be disabled:
|
||||
|
||||
|
||||
@ -199,7 +199,7 @@ It’s important to test any executables generated by a build when you change or
|
||||
|
||||
### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}
|
||||
|
||||
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
|
||||
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
|
||||
|
||||
## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Usage {#sec-pkgs-nix-gitignore-usage}
|
||||
|
||||
`pkgs.nix-gitignore` exports a number of functions, but you\'ll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
|
||||
`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
|
||||
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
@ -30,7 +30,7 @@ gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
|
||||
gitignoreSource = gitignoreFilterSource (_: _: true);
|
||||
```
|
||||
|
||||
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it\'s blacklisted by either your filter or the gitignoreFilter.
|
||||
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
|
||||
|
||||
If you want to make your own filter from scratch, you may use
|
||||
|
||||
|
||||
@ -73,7 +73,7 @@ There are also two ways to try compiling a package which has been marked as unsu
|
||||
}
|
||||
```
|
||||
|
||||
The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g. `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what \"ought\" means exactly. That is left to the package maintainer.
|
||||
The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g. `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what "ought" means exactly. That is left to the package maintainer.
|
||||
|
||||
## Installing unfree packages {#sec-allow-unfree}
|
||||
|
||||
|
||||
@ -212,6 +212,21 @@ runTests {
|
||||
expected = [ "1" "2" "3" ];
|
||||
};
|
||||
|
||||
testPadVersionLess = {
|
||||
expr = versions.pad 3 "1.2";
|
||||
expected = "1.2.0";
|
||||
};
|
||||
|
||||
testPadVersionLessExtra = {
|
||||
expr = versions.pad 3 "1.3-rc1";
|
||||
expected = "1.3.0-rc1";
|
||||
};
|
||||
|
||||
testPadVersionMore = {
|
||||
expr = versions.pad 3 "1.2.3.4";
|
||||
expected = "1.2.3";
|
||||
};
|
||||
|
||||
testIsStorePath = {
|
||||
expr =
|
||||
let goodPath =
|
||||
|
||||
@ -46,4 +46,19 @@ rec {
|
||||
builtins.concatStringsSep "."
|
||||
(lib.take 2 (splitVersion v));
|
||||
|
||||
/* Pad a version string with zeros to match the given number of components.
|
||||
|
||||
Example:
|
||||
pad 3 "1.2"
|
||||
=> "1.2.0"
|
||||
pad 3 "1.3-rc1"
|
||||
=> "1.3.0-rc1"
|
||||
pad 3 "1.2.3.4"
|
||||
=> "1.2.3"
|
||||
*/
|
||||
pad = n: version: let
|
||||
numericVersion = lib.head (lib.splitString "-" version);
|
||||
versionSuffix = lib.removePrefix numericVersion version;
|
||||
in lib.concatStringsSep "." (lib.take n (lib.splitVersion numericVersion ++ lib.genList (_: "0") n)) + versionSuffix;
|
||||
|
||||
}
|
||||
|
||||
@ -4151,6 +4151,12 @@
|
||||
githubId = 1365692;
|
||||
name = "Will Fancher";
|
||||
};
|
||||
emattiza = {
|
||||
email = "nix@mattiza.dev";
|
||||
github = "emattiza";
|
||||
githubId = 11719476;
|
||||
name = "Evan Mattiza";
|
||||
};
|
||||
emmabastas = {
|
||||
email = "emma.bastas@protonmail.com";
|
||||
matrix = "@emmabastas:matrix.org";
|
||||
|
||||
@ -415,7 +415,7 @@ printBuildSummary
|
||||
<> ["","*:arrow_heading_up:: The number of packages that depend (directly or indirectly) on this package (if any). If two numbers are shown the first (lower) number considers only packages which currently have enabled hydra jobs, i.e. are not marked broken. The second (higher) number considers all packages.*",""]
|
||||
<> footer
|
||||
where
|
||||
footer = ["*Report generated with [maintainers/scripts/haskell/hydra-report.hs](https://github.com/NixOS/nixpkgs/blob/haskell-updates/maintainers/scripts/haskell/hydra-report.sh)*"]
|
||||
footer = ["*Report generated with [maintainers/scripts/haskell/hydra-report.hs](https://github.com/NixOS/nixpkgs/blob/haskell-updates/maintainers/scripts/haskell/hydra-report.hs)*"]
|
||||
totals =
|
||||
[ "#### Build summary"
|
||||
, ""
|
||||
|
||||
@ -75,7 +75,7 @@ necessary).
|
||||
|
||||
Packages in Nixpkgs sometimes provide systemd units with them, usually
|
||||
in e.g `#pkg-out#/lib/systemd/`. Putting such a package in
|
||||
`environment.systemPackages` doesn\'t make the service available to
|
||||
`environment.systemPackages` doesn't make the service available to
|
||||
users or the system.
|
||||
|
||||
In order to enable a systemd *system* service with provided upstream
|
||||
@ -87,9 +87,9 @@ systemd.packages = [ pkgs.packagekit ];
|
||||
|
||||
Usually NixOS modules written by the community do the above, plus take
|
||||
care of other details. If a module was written for a service you are
|
||||
interested in, you\'d probably need only to use
|
||||
interested in, you'd probably need only to use
|
||||
`services.#name#.enable = true;`. These services are defined in
|
||||
Nixpkgs\' [ `nixos/modules/` directory
|
||||
Nixpkgs' [ `nixos/modules/` directory
|
||||
](https://github.com/NixOS/nixpkgs/tree/master/nixos/modules). In case
|
||||
the service is simple enough, the above method should work, and start
|
||||
the service on boot.
|
||||
@ -98,8 +98,8 @@ the service on boot.
|
||||
differently. Given a package that has a systemd unit file at
|
||||
`#pkg-out#/lib/systemd/user/`, using [](#opt-systemd.packages) will
|
||||
make you able to start the service via `systemctl --user start`, but it
|
||||
won\'t start automatically on login. However, You can imperatively
|
||||
enable it by adding the package\'s attribute to
|
||||
won't start automatically on login. However, You can imperatively
|
||||
enable it by adding the package's attribute to
|
||||
[](#opt-systemd.packages) and then do this (e.g):
|
||||
|
||||
```ShellSession
|
||||
@ -113,7 +113,7 @@ If you are interested in a timer file, use `timers.target.wants` instead
|
||||
of `default.target.wants` in the 1st and 2nd command.
|
||||
|
||||
Using `systemctl --user enable syncthing.service` instead of the above,
|
||||
will work, but it\'ll use the absolute path of `syncthing.service` for
|
||||
will work, but it'll use the absolute path of `syncthing.service` for
|
||||
the symlink, and this path is in `/nix/store/.../lib/systemd/user/`.
|
||||
Hence [garbage collection](#sec-nix-gc) will remove that file and you
|
||||
will wind up with a broken symlink in your systemd configuration, which
|
||||
|
||||
@ -17,7 +17,7 @@ services.kubernetes = {
|
||||
};
|
||||
```
|
||||
|
||||
Another way is to assign cluster roles (\"master\" and/or \"node\") to
|
||||
Another way is to assign cluster roles ("master" and/or "node") to
|
||||
the host. This enables apiserver, controllerManager, scheduler,
|
||||
addonManager, kube-proxy and etcd:
|
||||
|
||||
|
||||
@ -82,61 +82,68 @@ boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
|
||||
sets the kernel's TCP keepalive time to 120 seconds. To see the
|
||||
available parameters, run `sysctl -a`.
|
||||
|
||||
## Customize your kernel {#sec-linux-config-customizing}
|
||||
## Building a custom kernel {#sec-linux-config-customizing}
|
||||
|
||||
The first step before compiling the kernel is to generate an appropriate
|
||||
`.config` configuration. Either you pass your own config via the
|
||||
`configfile` setting of `linuxKernel.manualConfig`:
|
||||
You can customize the default kernel configuration by overriding the arguments for your kernel package:
|
||||
|
||||
```nix
|
||||
custom-kernel = let base_kernel = linuxKernel.kernels.linux_4_9;
|
||||
in super.linuxKernel.manualConfig {
|
||||
inherit (super) stdenv hostPlatform;
|
||||
inherit (base_kernel) src;
|
||||
version = "${base_kernel.version}-custom";
|
||||
|
||||
configfile = /home/me/my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
};
|
||||
```
|
||||
|
||||
You can edit the config with this snippet (by default `make
|
||||
menuconfig` won\'t work out of the box on nixos):
|
||||
|
||||
```ShellSession
|
||||
nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkg-config ncurses ];})'
|
||||
```
|
||||
|
||||
or you can let nixpkgs generate the configuration. Nixpkgs generates it
|
||||
via answering the interactive kernel utility `make config`. The answers
|
||||
depend on parameters passed to
|
||||
`pkgs/os-specific/linux/kernel/generic.nix` (which you can influence by
|
||||
overriding `extraConfig, autoModules,
|
||||
modDirVersion, preferBuiltin, extraConfig`).
|
||||
|
||||
```nix
|
||||
mptcp93.override ({
|
||||
name="mptcp-local";
|
||||
|
||||
pkgs.linux_latest.override {
|
||||
ignoreConfigErrors = true;
|
||||
autoModules = false;
|
||||
kernelPreferBuiltin = true;
|
||||
extraStructuredConfig = with lib.kernel; {
|
||||
DEBUG_KERNEL = yes;
|
||||
FRAME_POINTER = yes;
|
||||
KGDB = yes;
|
||||
KGDB_SERIAL_CONSOLE = yes;
|
||||
DEBUG_INFO = yes;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
enableParallelBuilding = true;
|
||||
See `pkgs/os-specific/linux/kernel/generic.nix` for details on how these arguments
|
||||
affect the generated configuration. You can also build a custom version of Linux by calling
|
||||
`pkgs.buildLinux` directly, which requires the `src` and `version` arguments to be specified.
|
||||
|
||||
extraConfig = ''
|
||||
DEBUG_KERNEL y
|
||||
FRAME_POINTER y
|
||||
KGDB y
|
||||
KGDB_SERIAL_CONSOLE y
|
||||
DEBUG_INFO y
|
||||
'';
|
||||
});
|
||||
To use your custom kernel package in your NixOS configuration, set
|
||||
|
||||
```nix
|
||||
boot.kernelPackages = pkgs.linuxPackagesFor yourCustomKernel;
|
||||
```
|
||||
|
||||
Note that this method will use the common configuration defined in `pkgs/os-specific/linux/kernel/common-config.nix`,
|
||||
which is suitable for a NixOS system.
|
||||
|
||||
If you already have a generated configuration file, you can build a kernel that uses it with `pkgs.linuxManualConfig`:
|
||||
|
||||
```nix
|
||||
let
|
||||
baseKernel = pkgs.linux_latest;
|
||||
in pkgs.linuxManualConfig {
|
||||
inherit (baseKernel) src modDirVersion;
|
||||
version = "${baseKernel.version}-custom";
|
||||
configfile = ./my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
}
|
||||
```
|
||||
|
||||
::: {.note}
|
||||
The build will fail if `modDirVersion` does not match the source's `kernel.release` file,
|
||||
so `modDirVersion` should remain tied to `src`.
|
||||
:::
|
||||
|
||||
To edit the `.config` file for Linux X.Y, proceed as follows:
|
||||
|
||||
```ShellSession
|
||||
$ nix-shell '<nixpkgs>' -A linuxKernel.kernels.linux_X_Y.configEnv
|
||||
$ unpackPhase
|
||||
$ cd linux-*
|
||||
$ make nconfig
|
||||
```
|
||||
|
||||
## Developing kernel modules {#sec-linux-config-developing-modules}
|
||||
|
||||
When developing kernel modules it\'s often convenient to run
|
||||
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 `mellanox` drivers.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
In some cases, it may be desirable to take advantage of commonly-used,
|
||||
predefined configurations provided by nixpkgs, but different from those
|
||||
that come as default. This is a role fulfilled by NixOS\'s Profiles,
|
||||
that come as default. This is a role fulfilled by NixOS's Profiles,
|
||||
which come as files living in `<nixpkgs/nixos/modules/profiles>`. That
|
||||
is to say, expected usage is to add them to the imports list of your
|
||||
`/etc/configuration.nix` as such:
|
||||
|
||||
@ -30,7 +30,7 @@ to your NixOS configuration. For instance, if you remove a user from
|
||||
[](#opt-users.users) and run nixos-rebuild, the user
|
||||
account will cease to exist. Also, imperative commands for managing users and
|
||||
groups, such as useradd, are no longer available. Passwords may still be
|
||||
assigned by setting the user\'s
|
||||
assigned by setting the user's
|
||||
[hashedPassword](#opt-users.users._name_.hashedPassword) option. A
|
||||
hashed password can be generated using `mkpasswd`.
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ While X11 (see [](#sec-x11)) is still the primary display technology
|
||||
on NixOS, Wayland support is steadily improving. Where X11 separates the
|
||||
X Server and the window manager, on Wayland those are combined: a
|
||||
Wayland Compositor is like an X11 window manager, but also embeds the
|
||||
Wayland \'Server\' functionality. This means it is sufficient to install
|
||||
Wayland 'Server' functionality. This means it is sufficient to install
|
||||
a Wayland Compositor such as sway without separately enabling a Wayland
|
||||
server:
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ second password to login can be redundant.
|
||||
|
||||
To enable auto-login, you need to define your default window manager and
|
||||
desktop environment. If you wanted no desktop environment and i3 as your
|
||||
your window manager, you\'d define:
|
||||
your window manager, you'd define:
|
||||
|
||||
```nix
|
||||
services.xserver.displayManager.defaultSession = "none+i3";
|
||||
@ -110,7 +110,7 @@ maintained but may perform worse in some cases (like in old chipsets).
|
||||
|
||||
The second driver, `intel`, is specific to Intel GPUs, but not
|
||||
recommended by most distributions: it lacks several modern features (for
|
||||
example, it doesn\'t support Glamor) and the package hasn\'t been
|
||||
example, it doesn't support Glamor) and the package hasn't been
|
||||
officially updated since 2015.
|
||||
|
||||
The results vary depending on the hardware, so you may have to try both
|
||||
@ -162,7 +162,7 @@ with other kernel modules.
|
||||
|
||||
AMD provides a proprietary driver for its graphics cards that is not
|
||||
enabled by default because it's not Free Software, is often broken in
|
||||
nixpkgs and as of this writing doesn\'t offer more features or
|
||||
nixpkgs and as of this writing doesn't offer more features or
|
||||
performance. If you still want to use it anyway, you need to explicitly
|
||||
set:
|
||||
|
||||
@ -215,7 +215,7 @@ US layout, with an additional layer to type some greek symbols by
|
||||
pressing the right-alt key.
|
||||
|
||||
Create a file called `us-greek` with the following content (under a
|
||||
directory called `symbols`; it\'s an XKB peculiarity that will help with
|
||||
directory called `symbols`; it's an XKB peculiarity that will help with
|
||||
testing):
|
||||
|
||||
```nix
|
||||
@ -249,7 +249,7 @@ The name (after `extraLayouts.`) should match the one given to the
|
||||
|
||||
Applying this customization requires rebuilding several packages, and a
|
||||
broken XKB file can lead to the X session crashing at login. Therefore,
|
||||
you\'re strongly advised to **test your layout before applying it**:
|
||||
you're strongly advised to **test your layout before applying it**:
|
||||
|
||||
```ShellSession
|
||||
$ nix-shell -p xorg.xkbcomp
|
||||
@ -313,8 +313,8 @@ prefer to keep the layout definitions inside the NixOS configuration.
|
||||
|
||||
Unfortunately, the Xorg server does not (currently) support setting a
|
||||
keymap directly but relies instead on XKB rules to select the matching
|
||||
components (keycodes, types, \...) of a layout. This means that
|
||||
components other than symbols won\'t be loaded by default. As a
|
||||
components (keycodes, types, ...) of a layout. This means that
|
||||
components other than symbols won't be loaded by default. As a
|
||||
workaround, you can set the keymap using `setxkbmap` at the start of the
|
||||
session with:
|
||||
|
||||
@ -323,7 +323,7 @@ services.xserver.displayManager.sessionCommands = "setxkbmap -keycodes media";
|
||||
```
|
||||
|
||||
If you are manually starting the X server, you should set the argument
|
||||
`-xkbdir /etc/X11/xkb`, otherwise X won\'t find your layout files. For
|
||||
`-xkbdir /etc/X11/xkb`, otherwise X won't find your layout files. For
|
||||
example with `xinit` run
|
||||
|
||||
```ShellSession
|
||||
|
||||
@ -31,8 +31,8 @@ enabled. To enable Thunar without enabling Xfce, use the configuration
|
||||
option [](#opt-programs.thunar.enable) instead of simply adding
|
||||
`pkgs.xfce.thunar` to [](#opt-environment.systemPackages).
|
||||
|
||||
If you\'d like to add extra plugins to Thunar, add them to
|
||||
[](#opt-programs.thunar.plugins). You shouldn\'t just add them to
|
||||
If you'd like to add extra plugins to Thunar, add them to
|
||||
[](#opt-programs.thunar.plugins). You shouldn't just add them to
|
||||
[](#opt-environment.systemPackages).
|
||||
|
||||
## Troubleshooting {#sec-xfce-troubleshooting .unnumbered}
|
||||
@ -46,7 +46,7 @@ Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with db
|
||||
```
|
||||
|
||||
This is caused by some needed GNOME services not running. This is all
|
||||
fixed by enabling \"Launch GNOME services on startup\" in the Advanced
|
||||
fixed by enabling "Launch GNOME services on startup" in the Advanced
|
||||
tab of the Session and Startup settings panel. Alternatively, you can
|
||||
run this command to do the same thing.
|
||||
|
||||
|
||||
@ -149,7 +149,7 @@ multiple modules, or as an alternative to related `enable` options.
|
||||
|
||||
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 (sddm, gdm \...).
|
||||
module file per display manager backend (sddm, gdm ...).
|
||||
|
||||
There are two approaches we could take with this module structure:
|
||||
|
||||
|
||||
@ -92,11 +92,11 @@ merging is handled.
|
||||
: A free-form attribute set.
|
||||
|
||||
::: {.warning}
|
||||
This type will be deprecated in the future because it doesn\'t
|
||||
This type will be deprecated in the future because it doesn't
|
||||
recurse into attribute sets, silently drops earlier attribute
|
||||
definitions, and doesn\'t discharge `lib.mkDefault`, `lib.mkIf`
|
||||
definitions, and doesn't discharge `lib.mkDefault`, `lib.mkIf`
|
||||
and co. For allowing arbitrary attribute sets, prefer
|
||||
`types.attrsOf types.anything` instead which doesn\'t have these
|
||||
`types.attrsOf types.anything` instead which doesn't have these
|
||||
problems.
|
||||
:::
|
||||
|
||||
@ -222,7 +222,7 @@ Submodules are detailed in [Submodule](#section-option-types-submodule).
|
||||
- *`specialArgs`* An attribute set of extra arguments to be passed
|
||||
to the module functions. The option `_module.args` should be
|
||||
used instead for most arguments since it allows overriding.
|
||||
*`specialArgs`* should only be used for arguments that can\'t go
|
||||
*`specialArgs`* should only be used for arguments that can't go
|
||||
through the module fixed-point, because of infinite recursion or
|
||||
other problems. An example is overriding the `lib` argument,
|
||||
because `lib` itself is used to define `_module.args`, which
|
||||
@ -236,7 +236,7 @@ Submodules are detailed in [Submodule](#section-option-types-submodule).
|
||||
In such a case it would allow the option to be set with
|
||||
`the-submodule.config = "value"` instead of requiring
|
||||
`the-submodule.config.config = "value"`. This is because
|
||||
only when modules *don\'t* set the `config` or `options`
|
||||
only when modules *don't* set the `config` or `options`
|
||||
keys, all keys are interpreted as option definitions in the
|
||||
`config` section. Enabling this option implicitly puts all
|
||||
attributes in the `config` section.
|
||||
@ -324,7 +324,7 @@ Composed types are types that take a type as parameter. `listOf
|
||||
: Type *`t1`* or type *`t2`*, e.g. `with types; either int str`.
|
||||
Multiple definitions cannot be merged.
|
||||
|
||||
`types.oneOf` \[ *`t1 t2`* \... \]
|
||||
`types.oneOf` \[ *`t1 t2`* ... \]
|
||||
|
||||
: Type *`t1`* or type *`t2`* and so forth, e.g.
|
||||
`with types; oneOf [ int str bool ]`. Multiple definitions cannot be
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
Modules that are imported can also be disabled. The option declarations,
|
||||
config implementation and the imports of a disabled module will be
|
||||
ignored, allowing another to take it\'s place. This can be used to
|
||||
ignored, allowing another to take its 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.
|
||||
|
||||
@ -14,7 +14,7 @@ relative to the modules path (eg. \<nixpkgs/nixos/modules> for nixos).
|
||||
This example will replace the existing postgresql module with the
|
||||
version defined in the nixos-unstable channel while keeping the rest of
|
||||
the modules and packages from the original nixos channel. This only
|
||||
overrides the module definition, this won\'t use postgresql from
|
||||
overrides the module definition, this won't use postgresql from
|
||||
nixos-unstable unless explicitly configured to do so.
|
||||
|
||||
```nix
|
||||
@ -35,7 +35,7 @@ nixos-unstable unless explicitly configured to do so.
|
||||
|
||||
This example shows how to define a custom module as a replacement for an
|
||||
existing module. Importing this module will disable the original module
|
||||
without having to know it\'s implementation details.
|
||||
without having to know its implementation details.
|
||||
|
||||
```nix
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
@ -9,10 +9,10 @@ can be declared. File formats can be separated into two categories:
|
||||
`{ foo = { bar = 10; }; }`. Other examples are INI, YAML and TOML.
|
||||
The following section explains the convention for these settings.
|
||||
|
||||
- Non-nix-representable ones: These can\'t be trivially mapped to a
|
||||
- Non-nix-representable ones: These can't be trivially mapped to a
|
||||
subset of Nix syntax. Most generic programming languages are in this
|
||||
group, e.g. bash, since the statement `if true; then echo hi; fi`
|
||||
doesn\'t have a trivial representation in Nix.
|
||||
doesn't have a trivial representation in Nix.
|
||||
|
||||
Currently there are no fixed conventions for these, but it is common
|
||||
to have a `configFile` option for setting the configuration file
|
||||
@ -24,7 +24,7 @@ can be declared. File formats can be separated into two categories:
|
||||
an `extraConfig` option of type `lines` to allow arbitrary text
|
||||
after the autogenerated part of the file.
|
||||
|
||||
## Nix-representable Formats (JSON, YAML, TOML, INI, \...) {#sec-settings-nix-representable}
|
||||
## Nix-representable Formats (JSON, YAML, TOML, INI, ...) {#sec-settings-nix-representable}
|
||||
|
||||
By convention, formats like this are handled with a generic `settings`
|
||||
option, representing the full program configuration as a Nix value. The
|
||||
|
||||
@ -19,7 +19,7 @@ $ nix-shell
|
||||
nix-shell$ make
|
||||
```
|
||||
|
||||
Once you are done making modifications to the manual, it\'s important to
|
||||
Once you are done making modifications to the manual, it's important to
|
||||
build it before committing. You can do that as follows:
|
||||
|
||||
```ShellSession
|
||||
|
||||
@ -71,7 +71,7 @@ The meaning of each part is as follows.
|
||||
- This `imports` list enumerates the paths to other NixOS modules that
|
||||
should be included in the evaluation of the system configuration. A
|
||||
default set of modules is defined in the file `modules/module-list.nix`.
|
||||
These don\'t need to be added in the import list.
|
||||
These don't need to be added in the import list.
|
||||
|
||||
- The attribute `options` is a nested set of *option declarations*
|
||||
(described below).
|
||||
|
||||
@ -165,7 +165,7 @@ The following methods are available on machine objects:
|
||||
`get_screen_text_variants`
|
||||
|
||||
: Return a list of different interpretations of what is currently
|
||||
visible on the machine\'s screen using optical character
|
||||
visible on the machine's screen using optical character
|
||||
recognition. The number and order of the interpretations is not
|
||||
specified and is subject to change, but if no exception is raised at
|
||||
least one will be returned.
|
||||
@ -177,7 +177,7 @@ The following methods are available on machine objects:
|
||||
`get_screen_text`
|
||||
|
||||
: Return a textual representation of what is currently visible on the
|
||||
machine\'s screen using optical character recognition.
|
||||
machine's screen using optical character recognition.
|
||||
|
||||
::: {.note}
|
||||
This requires [`enableOCR`](#test-opt-enableOCR) to be set to `true`.
|
||||
@ -350,8 +350,8 @@ machine.wait_for_unit("xautolock.service", "x-session-user")
|
||||
This applies to `systemctl`, `get_unit_info`, `wait_for_unit`,
|
||||
`start_job` and `stop_job`.
|
||||
|
||||
For faster dev cycles it\'s also possible to disable the code-linters
|
||||
(this shouldn\'t be committed though):
|
||||
For faster dev cycles it's also possible to disable the code-linters
|
||||
(this shouldn't be committed though):
|
||||
|
||||
```nix
|
||||
{
|
||||
@ -370,7 +370,7 @@ For faster dev cycles it\'s also possible to disable the code-linters
|
||||
|
||||
This will produce a Nix warning at evaluation time. To fully disable the
|
||||
linter, wrap the test script in comment directives to disable the Black
|
||||
linter directly (again, don\'t commit this within the Nixpkgs
|
||||
linter directly (again, don't commit this within the Nixpkgs
|
||||
repository):
|
||||
|
||||
```nix
|
||||
|
||||
@ -23,7 +23,7 @@ $ nix-collect-garbage
|
||||
this unit automatically at certain points in time, for instance,
|
||||
every night at 03:15:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nix.gc.automatic = true;
|
||||
nix.gc.dates = "03:15";
|
||||
</programlisting>
|
||||
|
||||
@ -31,7 +31,7 @@ $ ping -c1 10.233.4.2
|
||||
address. This can be accomplished using the following configuration
|
||||
on the host:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.nat.enable = true;
|
||||
networking.nat.internalInterfaces = ["ve-+"];
|
||||
networking.nat.externalInterface = "eth0";
|
||||
@ -45,7 +45,7 @@ networking.nat.externalInterface = "eth0";
|
||||
If you are using Network Manager, you need to explicitly prevent it
|
||||
from managing container interfaces:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -42,7 +42,7 @@ $ systemd-cgls
|
||||
process would get 1/1001 of the cgroup’s CPU time.) You can limit a
|
||||
service’s CPU share in <literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.services.httpd.serviceConfig.CPUShares = 512;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -57,7 +57,7 @@ systemd.services.httpd.serviceConfig.CPUShares = 512;
|
||||
<literal>configuration.nix</literal>; for instance, to limit
|
||||
<literal>httpd.service</literal> to 512 MiB of RAM (excluding swap):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.services.httpd.serviceConfig.MemoryLimit = "512M";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
following specifies that there shall be a container named
|
||||
<literal>database</literal> running PostgreSQL:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
containers.database =
|
||||
{ config =
|
||||
{ config, pkgs, ... }:
|
||||
@ -29,7 +29,7 @@ containers.database =
|
||||
However, they cannot change the network configuration. You can give
|
||||
a container its own network as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
containers.database = {
|
||||
privateNetwork = true;
|
||||
hostAddress = "192.168.100.10";
|
||||
|
||||
@ -85,21 +85,21 @@ Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
|
||||
Packages in Nixpkgs sometimes provide systemd units with them,
|
||||
usually in e.g <literal>#pkg-out#/lib/systemd/</literal>. Putting
|
||||
such a package in <literal>environment.systemPackages</literal>
|
||||
doesn't make the service available to users or the system.
|
||||
doesn’t make the service available to users or the system.
|
||||
</para>
|
||||
<para>
|
||||
In order to enable a systemd <emphasis>system</emphasis> service
|
||||
with provided upstream package, use (e.g):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.packages = [ pkgs.packagekit ];
|
||||
</programlisting>
|
||||
<para>
|
||||
Usually NixOS modules written by the community do the above, plus
|
||||
take care of other details. If a module was written for a service
|
||||
you are interested in, you'd probably need only to use
|
||||
you are interested in, you’d probably need only to use
|
||||
<literal>services.#name#.enable = true;</literal>. These services
|
||||
are defined in Nixpkgs'
|
||||
are defined in Nixpkgs’
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/modules">
|
||||
<literal>nixos/modules/</literal> directory </link>. In case the
|
||||
service is simple enough, the above method should work, and start
|
||||
@ -111,8 +111,8 @@ systemd.packages = [ pkgs.packagekit ];
|
||||
unit file at <literal>#pkg-out#/lib/systemd/user/</literal>, using
|
||||
<xref linkend="opt-systemd.packages" /> will make you able to
|
||||
start the service via <literal>systemctl --user start</literal>,
|
||||
but it won't start automatically on login. However, You can
|
||||
imperatively enable it by adding the package's attribute to
|
||||
but it won’t start automatically on login. However, You can
|
||||
imperatively enable it by adding the package’s attribute to
|
||||
<xref linkend="opt-systemd.packages" /> and then do this (e.g):
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -129,7 +129,7 @@ $ systemctl --user enable syncthing.service
|
||||
</para>
|
||||
<para>
|
||||
Using <literal>systemctl --user enable syncthing.service</literal>
|
||||
instead of the above, will work, but it'll use the absolute path
|
||||
instead of the above, will work, but it’ll use the absolute path
|
||||
of <literal>syncthing.service</literal> for the symlink, and this
|
||||
path is in <literal>/nix/store/.../lib/systemd/user/</literal>.
|
||||
Hence <link linkend="sec-nix-gc">garbage collection</link> will
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
If you find yourself repeating yourself over and over, it’s time to
|
||||
abstract. Take, for instance, this Apache HTTP Server configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.virtualHosts =
|
||||
{ "blog.example.org" = {
|
||||
@ -29,7 +29,7 @@
|
||||
the only difference is the document root directories. To prevent
|
||||
this duplication, we can use a <literal>let</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
let
|
||||
commonConfig =
|
||||
{ adminAddr = "alice@example.org";
|
||||
@ -55,7 +55,7 @@ in
|
||||
You can write a <literal>let</literal> wherever an expression is
|
||||
allowed. Thus, you also could have written:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.virtualHosts =
|
||||
let commonConfig = ...; in
|
||||
@ -74,7 +74,7 @@ in
|
||||
of different virtual hosts, all with identical configuration except
|
||||
for the document root. This can be done as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.virtualHosts =
|
||||
let
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
network configuration not covered by the existing NixOS modules. For
|
||||
instance, to statically configure an IPv6 address:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.localCommands =
|
||||
''
|
||||
ip -6 addr add 2001:610:685:1::1/64 dev eth0
|
||||
|
||||
@ -28,7 +28,7 @@ $ cd nixpkgs
|
||||
manual. Finally, you add it to
|
||||
<xref linkend="opt-environment.systemPackages" />, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ pkgs.my-package ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -45,7 +45,7 @@ environment.systemPackages = [ pkgs.my-package ];
|
||||
Hello</link> package directly in
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages =
|
||||
let
|
||||
my-hello = with pkgs; stdenv.mkDerivation rec {
|
||||
@ -62,13 +62,13 @@ environment.systemPackages =
|
||||
Of course, you can also move the definition of
|
||||
<literal>my-hello</literal> into a separate Nix expression, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ (import ./my-hello.nix) ];
|
||||
</programlisting>
|
||||
<para>
|
||||
where <literal>my-hello.nix</literal> contains:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
with import <nixpkgs> {}; # bring all of Nixpkgs into scope
|
||||
|
||||
stdenv.mkDerivation rec {
|
||||
@ -98,7 +98,7 @@ Hello, world!
|
||||
need to install <literal>appimage-run</literal>: add to
|
||||
<literal>/etc/nixos/configuration.nix</literal>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ pkgs.appimage-run ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<para>
|
||||
The NixOS configuration file generally looks like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ option definitions
|
||||
@ -21,7 +21,7 @@
|
||||
the name of an option and <literal>value</literal> is its value. For
|
||||
example,
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ services.httpd.enable = true;
|
||||
@ -44,7 +44,7 @@
|
||||
<literal>true</literal>. This means that the example above can also
|
||||
be written as:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ services = {
|
||||
@ -96,7 +96,7 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
|
||||
<para>
|
||||
Strings are enclosed in double quotes, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.hostName = "dexter";
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -107,7 +107,7 @@ networking.hostName = "dexter";
|
||||
Multi-line strings can be enclosed in <emphasis>double single
|
||||
quotes</emphasis>, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.extraHosts =
|
||||
''
|
||||
127.0.0.2 other-localhost
|
||||
@ -135,7 +135,7 @@ networking.extraHosts =
|
||||
These can be <literal>true</literal> or
|
||||
<literal>false</literal>, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.enable = true;
|
||||
networking.firewall.allowPing = false;
|
||||
</programlisting>
|
||||
@ -149,7 +149,7 @@ networking.firewall.allowPing = false;
|
||||
<para>
|
||||
For example,
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 60;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -171,7 +171,7 @@ boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 60;
|
||||
Sets were introduced above. They are name/value pairs enclosed
|
||||
in braces, as in the option definition
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
fileSystems."/boot" =
|
||||
{ device = "/dev/sda1";
|
||||
fsType = "ext4";
|
||||
@ -189,13 +189,13 @@ fileSystems."/boot" =
|
||||
The important thing to note about lists is that list elements
|
||||
are separated by whitespace, like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
List elements can be any other type, e.g. sets:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
||||
</programlisting>
|
||||
</listitem>
|
||||
@ -211,7 +211,7 @@ swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
||||
through the function argument <literal>pkgs</literal>. Typical
|
||||
uses:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages =
|
||||
[ pkgs.thunderbird
|
||||
pkgs.emacs
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
a dependency on GTK 2. If you want to build it against GTK 3, you
|
||||
can specify that as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -46,7 +46,7 @@ environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
|
||||
the package, such as the source code. For instance, if you want to
|
||||
override the source code of Emacs, you can say:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [
|
||||
(pkgs.emacs.overrideAttrs (oldAttrs: {
|
||||
name = "emacs-25.0-pre";
|
||||
@ -72,7 +72,7 @@ environment.systemPackages = [
|
||||
everything depend on your customised instance, you can apply a
|
||||
<emphasis>global</emphasis> override as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nixpkgs.config.packageOverrides = pkgs:
|
||||
{ emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
|
||||
};
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
adding the following line to <literal>configuration.nix</literal>
|
||||
enables the Mozilla Thunderbird email application:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ pkgs.thunderbird ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<literal>/dev/disk/by-label/data</literal> onto the mount point
|
||||
<literal>/data</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
fileSystems."/data" =
|
||||
{ device = "/dev/disk/by-label/data";
|
||||
fsType = "ext4";
|
||||
|
||||
@ -6,14 +6,14 @@
|
||||
both IPv4 and IPv6 traffic. It is enabled by default. It can be
|
||||
disabled as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.enable = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
If the firewall is enabled, you can open specific TCP ports to the
|
||||
outside world:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -26,7 +26,7 @@ networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||
<para>
|
||||
To open ranges of TCP ports:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.allowedTCPPortRanges = [
|
||||
{ from = 4000; to = 4007; }
|
||||
{ from = 8000; to = 8010; }
|
||||
|
||||
@ -62,7 +62,7 @@ Platform Vendor Advanced Micro Devices, Inc.
|
||||
<xref linkend="opt-hardware.opengl.extraPackages" /> enables
|
||||
OpenCL support:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
rocm-opencl-icd
|
||||
];
|
||||
@ -85,7 +85,7 @@ hardware.opengl.extraPackages = [
|
||||
enable OpenCL support. For example, for Gen8 and later GPUs, the
|
||||
following configuration can be used:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
intel-compute-runtime
|
||||
];
|
||||
@ -162,7 +162,7 @@ GPU1:
|
||||
makes amdvlk the default driver and hides radv and lavapipe from
|
||||
the device list. A specific driver can be forced as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
pkgs.amdvlk
|
||||
];
|
||||
@ -206,7 +206,7 @@ $ nix-shell -p libva-utils --run vainfo
|
||||
Modern Intel GPUs use the iHD driver, which can be installed
|
||||
with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
intel-media-driver
|
||||
];
|
||||
@ -215,7 +215,7 @@ hardware.opengl.extraPackages = [
|
||||
Older Intel GPUs use the i965 driver, which can be installed
|
||||
with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
vaapiIntel
|
||||
];
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
interfaces. However, you can configure an interface manually as
|
||||
follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.interfaces.eth0.ipv4.addresses = [ {
|
||||
address = "192.168.1.2";
|
||||
prefixLength = 24;
|
||||
@ -16,7 +16,7 @@ networking.interfaces.eth0.ipv4.addresses = [ {
|
||||
Typically you’ll also want to set a default gateway and set of name
|
||||
servers:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.defaultGateway = "192.168.1.1";
|
||||
networking.nameservers = [ "8.8.8.8" ];
|
||||
</programlisting>
|
||||
@ -32,7 +32,7 @@ networking.nameservers = [ "8.8.8.8" ];
|
||||
The host name is set using
|
||||
<xref linkend="opt-networking.hostName" />:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.hostName = "cartman";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -10,21 +10,21 @@
|
||||
<xref linkend="opt-networking.interfaces._name_.tempAddress" />. You
|
||||
can disable IPv6 support globally by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.enableIPv6 = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
You can disable IPv6 on a single interface using a normal sysctl (in
|
||||
this example, we use interface <literal>eth0</literal>):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernel.sysctl."net.ipv6.conf.eth0.disable_ipv6" = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
As with IPv4 networking interfaces are automatically configured via
|
||||
DHCPv6. You can configure an interface manually:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.interfaces.eth0.ipv6.addresses = [ {
|
||||
address = "fe00:aa:bb:cc::2";
|
||||
prefixLength = 64;
|
||||
@ -34,7 +34,7 @@ networking.interfaces.eth0.ipv6.addresses = [ {
|
||||
For configuring a gateway, optionally with explicitly specified
|
||||
interface:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.defaultGateway6 = {
|
||||
address = "fe00::1";
|
||||
interface = "enp0s3";
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
way is to enable and configure cluster components appropriately by
|
||||
hand:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes = {
|
||||
apiserver.enable = true;
|
||||
controllerManager.enable = true;
|
||||
@ -21,24 +21,24 @@ services.kubernetes = {
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
Another way is to assign cluster roles ("master" and/or
|
||||
"node") to the host. This enables apiserver,
|
||||
Another way is to assign cluster roles (<quote>master</quote> and/or
|
||||
<quote>node</quote>) to the host. This enables apiserver,
|
||||
controllerManager, scheduler, addonManager, kube-proxy and etcd:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes.roles = [ "master" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
While this will enable the kubelet and kube-proxy only:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes.roles = [ "node" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
Assigning both the master and node roles is usable if you want a
|
||||
single node Kubernetes cluster for dev or testing purposes:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes.roles = [ "master" "node" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
option <literal>boot.kernelPackages</literal>. For instance, this
|
||||
selects the Linux 3.10 kernel:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelPackages = pkgs.linuxKernel.packages.linux_3_10;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -48,7 +48,7 @@ zcat /proc/config.gz
|
||||
<xref linkend="sec-customising-packages" />). For instance, to
|
||||
enable support for the kernel debugger KGDB:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nixpkgs.config.packageOverrides = pkgs: pkgs.lib.recursiveUpdate pkgs {
|
||||
linuxKernel.kernels.linux_5_10 = pkgs.linuxKernel.kernels.linux_5_10.override {
|
||||
extraConfig = ''
|
||||
@ -69,7 +69,7 @@ nixpkgs.config.packageOverrides = pkgs: pkgs.lib.recursiveUpdate pkgs {
|
||||
automatically by <literal>udev</literal>. You can force a module to
|
||||
be loaded via <xref linkend="opt-boot.kernelModules" />, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -77,7 +77,7 @@ boot.kernelModules = [ "fuse" "kvm-intel" "coretemp&quo
|
||||
root file system), you can use
|
||||
<xref linkend="opt-boot.initrd.kernelModules" />:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.kernelModules = [ "cifs" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -88,7 +88,7 @@ boot.initrd.kernelModules = [ "cifs" ];
|
||||
Kernel runtime parameters can be set through
|
||||
<xref linkend="opt-boot.kernel.sysctl" />, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -96,65 +96,82 @@ boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
|
||||
available parameters, run <literal>sysctl -a</literal>.
|
||||
</para>
|
||||
<section xml:id="sec-linux-config-customizing">
|
||||
<title>Customize your kernel</title>
|
||||
<title>Building a custom kernel</title>
|
||||
<para>
|
||||
The first step before compiling the kernel is to generate an
|
||||
appropriate <literal>.config</literal> configuration. Either you
|
||||
pass your own config via the <literal>configfile</literal> setting
|
||||
of <literal>linuxKernel.manualConfig</literal>:
|
||||
You can customize the default kernel configuration by overriding
|
||||
the arguments for your kernel package:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
custom-kernel = let base_kernel = linuxKernel.kernels.linux_4_9;
|
||||
in super.linuxKernel.manualConfig {
|
||||
inherit (super) stdenv hostPlatform;
|
||||
inherit (base_kernel) src;
|
||||
version = "${base_kernel.version}-custom";
|
||||
|
||||
configfile = /home/me/my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
You can edit the config with this snippet (by default
|
||||
<literal>make menuconfig</literal> won't work out of the box on
|
||||
nixos):
|
||||
</para>
|
||||
<programlisting>
|
||||
nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkg-config ncurses ];})'
|
||||
</programlisting>
|
||||
<para>
|
||||
or you can let nixpkgs generate the configuration. Nixpkgs
|
||||
generates it via answering the interactive kernel utility
|
||||
<literal>make config</literal>. The answers depend on parameters
|
||||
passed to
|
||||
<literal>pkgs/os-specific/linux/kernel/generic.nix</literal>
|
||||
(which you can influence by overriding
|
||||
<literal>extraConfig, autoModules, modDirVersion, preferBuiltin, extraConfig</literal>).
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
mptcp93.override ({
|
||||
name="mptcp-local";
|
||||
|
||||
<programlisting language="nix">
|
||||
pkgs.linux_latest.override {
|
||||
ignoreConfigErrors = true;
|
||||
autoModules = false;
|
||||
kernelPreferBuiltin = true;
|
||||
|
||||
enableParallelBuilding = true;
|
||||
|
||||
extraConfig = ''
|
||||
DEBUG_KERNEL y
|
||||
FRAME_POINTER y
|
||||
KGDB y
|
||||
KGDB_SERIAL_CONSOLE y
|
||||
DEBUG_INFO y
|
||||
'';
|
||||
});
|
||||
extraStructuredConfig = with lib.kernel; {
|
||||
DEBUG_KERNEL = yes;
|
||||
FRAME_POINTER = yes;
|
||||
KGDB = yes;
|
||||
KGDB_SERIAL_CONSOLE = yes;
|
||||
DEBUG_INFO = yes;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
See <literal>pkgs/os-specific/linux/kernel/generic.nix</literal>
|
||||
for details on how these arguments affect the generated
|
||||
configuration. You can also build a custom version of Linux by
|
||||
calling <literal>pkgs.buildLinux</literal> directly, which
|
||||
requires the <literal>src</literal> and <literal>version</literal>
|
||||
arguments to be specified.
|
||||
</para>
|
||||
<para>
|
||||
To use your custom kernel package in your NixOS configuration, set
|
||||
</para>
|
||||
<programlisting language="nix">
|
||||
boot.kernelPackages = pkgs.linuxPackagesFor yourCustomKernel;
|
||||
</programlisting>
|
||||
<para>
|
||||
Note that this method will use the common configuration defined in
|
||||
<literal>pkgs/os-specific/linux/kernel/common-config.nix</literal>,
|
||||
which is suitable for a NixOS system.
|
||||
</para>
|
||||
<para>
|
||||
If you already have a generated configuration file, you can build
|
||||
a kernel that uses it with
|
||||
<literal>pkgs.linuxManualConfig</literal>:
|
||||
</para>
|
||||
<programlisting language="nix">
|
||||
let
|
||||
baseKernel = pkgs.linux_latest;
|
||||
in pkgs.linuxManualConfig {
|
||||
inherit (baseKernel) src modDirVersion;
|
||||
version = "${baseKernel.version}-custom";
|
||||
configfile = ./my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
}
|
||||
</programlisting>
|
||||
<note>
|
||||
<para>
|
||||
The build will fail if <literal>modDirVersion</literal> does not
|
||||
match the source’s <literal>kernel.release</literal> file, so
|
||||
<literal>modDirVersion</literal> should remain tied to
|
||||
<literal>src</literal>.
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
To edit the <literal>.config</literal> file for Linux X.Y, proceed
|
||||
as follows:
|
||||
</para>
|
||||
<programlisting>
|
||||
$ nix-shell '<nixpkgs>' -A linuxKernel.kernels.linux_X_Y.configEnv
|
||||
$ unpackPhase
|
||||
$ cd linux-*
|
||||
$ make nconfig
|
||||
</programlisting>
|
||||
</section>
|
||||
<section xml:id="sec-linux-config-developing-modules">
|
||||
<title>Developing kernel modules</title>
|
||||
<para>
|
||||
When developing kernel modules it's often convenient to run
|
||||
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 <literal>mellanox</literal> drivers.
|
||||
</para>
|
||||
@ -181,7 +198,7 @@ $ make -C $dev/lib/modules/*/build M=$(pwd)/drivers/net/ethernet/mellanox module
|
||||
available kernel version <emphasis>that is supported by
|
||||
ZFS</emphasis> like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
boot.kernelPackages = pkgs.zfs.latestCompatibleLinuxPackages;
|
||||
}
|
||||
|
||||
@ -30,7 +30,7 @@ Enter passphrase for /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d: ***
|
||||
at boot time as <literal>/</literal>, add the following to
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.luks.devices.crypted.device = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";
|
||||
fileSystems."/".device = "/dev/mapper/crypted";
|
||||
</programlisting>
|
||||
@ -39,7 +39,7 @@ fileSystems."/".device = "/dev/mapper/crypted";
|
||||
located on an encrypted partition, it is necessary to add the
|
||||
following grub option:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.loader.grub.enableCryptodisk = true;
|
||||
</programlisting>
|
||||
<section xml:id="sec-luks-file-systems-fido2">
|
||||
@ -67,7 +67,7 @@ Added to key to device /dev/sda2, slot: 2
|
||||
compatible key, add the following to
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.luks.fido2Support = true;
|
||||
boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";
|
||||
</programlisting>
|
||||
@ -77,7 +77,7 @@ boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200
|
||||
protected, such as
|
||||
<link xlink:href="https://trezor.io/">Trezor</link>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.luks.devices."/dev/sda2".fido2.passwordLess = true;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
other modules by including them from
|
||||
<literal>configuration.nix</literal>, e.g.:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ imports = [ ./vpn.nix ./kde.nix ];
|
||||
@ -28,7 +28,7 @@
|
||||
<literal>vpn.nix</literal> and <literal>kde.nix</literal>. The
|
||||
latter might look like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ services.xserver.enable = true;
|
||||
@ -50,7 +50,7 @@
|
||||
you want it to appear first, you can use
|
||||
<literal>mkBefore</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelModules = mkBefore [ "kvm-intel" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -70,7 +70,7 @@ The unique option `services.httpd.adminAddr' is defined multiple times, in `/etc
|
||||
When that happens, it’s possible to force one definition take
|
||||
precedence over the others:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -93,7 +93,7 @@ services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
|
||||
<xref linkend="opt-services.xserver.enable" /> is set to
|
||||
<literal>true</literal> somewhere else:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ environment.systemPackages =
|
||||
@ -137,7 +137,7 @@ nix-repl> map (x: x.hostName) config.services.httpd.virtualHosts
|
||||
below would have the same effect as importing a file which sets
|
||||
those options.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
let netConfig = hostName: {
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
To facilitate network configuration, some desktop environments use
|
||||
NetworkManager. You can enable NetworkManager by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.networkmanager.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -15,7 +15,7 @@ networking.networkmanager.enable = true;
|
||||
All users that should have permission to change network settings
|
||||
must belong to the <literal>networkmanager</literal> group:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.alice.extraGroups = [ "networkmanager" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -36,7 +36,7 @@ users.users.alice.extraGroups = [ "networkmanager" ];
|
||||
used together if desired. To do this you need to instruct
|
||||
NetworkManager to ignore those interfaces like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.networkmanager.unmanaged = [
|
||||
"*" "except:type:wwan" "except:type:gsm"
|
||||
];
|
||||
|
||||
@ -4,12 +4,12 @@
|
||||
In some cases, it may be desirable to take advantage of
|
||||
commonly-used, predefined configurations provided by nixpkgs, but
|
||||
different from those that come as default. This is a role fulfilled
|
||||
by NixOS's Profiles, which come as files living in
|
||||
by NixOS’s Profiles, which come as files living in
|
||||
<literal><nixpkgs/nixos/modules/profiles></literal>. That is
|
||||
to say, expected usage is to add them to the imports list of your
|
||||
<literal>/etc/configuration.nix</literal> as such:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
imports = [
|
||||
<nixpkgs/nixos/modules/profiles/profile-name.nix>
|
||||
];
|
||||
|
||||
@ -30,7 +30,7 @@
|
||||
the interface with MAC address
|
||||
<literal>52:54:00:12:01:01</literal> using a netword link unit:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.network.links."10-wan" = {
|
||||
matchConfig.PermanentMACAddress = "52:54:00:12:01:01";
|
||||
linkConfig.Name = "wan";
|
||||
@ -43,7 +43,7 @@ systemd.network.links."10-wan" = {
|
||||
<para>
|
||||
Alternatively, we can use a plain old udev rule:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.udev.initrdRules = ''
|
||||
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
|
||||
ATTR{address}=="52:54:00:12:01:01", KERNEL=="eth*", NAME="wan"
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<para>
|
||||
Secure shell (SSH) access to your machine can be enabled by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.openssh.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -16,7 +16,7 @@ services.openssh.enable = true;
|
||||
You can declaratively specify authorised RSA/DSA public keys for a
|
||||
user as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.alice.openssh.authorizedKeys.keys =
|
||||
[ "ssh-dss AAAAB3NzaC1kc3MAAACBAPIkGWVEt4..." ];
|
||||
</programlisting>
|
||||
|
||||
@ -54,7 +54,7 @@ SHA256:yjxl3UbTn31fLWeyLYTAKYJPRmzknjQZoyG8gSNEoIE my-user@workstation
|
||||
<link linkend="opt-fileSystems">fileSystems</link> option. Here’s
|
||||
a typical setup:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
system.fsPackages = [ pkgs.sshfs ];
|
||||
|
||||
@ -80,7 +80,7 @@ SHA256:yjxl3UbTn31fLWeyLYTAKYJPRmzknjQZoyG8gSNEoIE my-user@workstation
|
||||
well, for example you can change the default SSH port or specify a
|
||||
jump proxy:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
options =
|
||||
[ "ProxyJump=bastion@example.com"
|
||||
@ -92,7 +92,7 @@ SHA256:yjxl3UbTn31fLWeyLYTAKYJPRmzknjQZoyG8gSNEoIE my-user@workstation
|
||||
It’s also possible to change the <literal>ssh</literal> command
|
||||
used by SSHFS to connect to the server. For example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
options =
|
||||
[ (builtins.replaceStrings [" "] ["\\040"]
|
||||
|
||||
@ -25,7 +25,7 @@
|
||||
Apache HTTP, setting
|
||||
<xref linkend="opt-services.httpd.adminAddr" /> appropriately:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.httpd.enable = true;
|
||||
services.httpd.adminAddr = ...;
|
||||
networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||
@ -40,7 +40,7 @@ networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||
<literal>.authz</literal> file describing access permission, and
|
||||
<literal>AuthUserFile</literal> to the password file.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.httpd.extraModules = [
|
||||
# note that order is *super* important here
|
||||
{ name = "dav_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_dav_svn.so"; }
|
||||
@ -106,7 +106,7 @@ $ htpasswd -s PASSWORD_FILE USER_NAME
|
||||
<literal>ACCESS_FILE</literal> will look something like the
|
||||
following:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
[/]
|
||||
* = r
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
states that a user account named <literal>alice</literal> shall
|
||||
exist:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.alice = {
|
||||
isNormalUser = true;
|
||||
home = "/home/alice";
|
||||
@ -36,7 +36,7 @@ users.users.alice = {
|
||||
<xref linkend="opt-users.users" /> and run nixos-rebuild, the user
|
||||
account will cease to exist. Also, imperative commands for managing
|
||||
users and groups, such as useradd, are no longer available.
|
||||
Passwords may still be assigned by setting the user's
|
||||
Passwords may still be assigned by setting the user’s
|
||||
<link linkend="opt-users.users._name_.hashedPassword">hashedPassword</link>
|
||||
option. A hashed password can be generated using
|
||||
<literal>mkpasswd</literal>.
|
||||
@ -45,7 +45,7 @@ users.users.alice = {
|
||||
A user ID (uid) is assigned automatically. You can also specify a
|
||||
uid manually by adding
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
uid = 1000;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -55,7 +55,7 @@ uid = 1000;
|
||||
Groups can be specified similarly. The following states that a group
|
||||
named <literal>students</literal> shall exist:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.groups.students.gid = 1000;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -5,11 +5,12 @@
|
||||
display technology on NixOS, Wayland support is steadily improving.
|
||||
Where X11 separates the X Server and the window manager, on Wayland
|
||||
those are combined: a Wayland Compositor is like an X11 window
|
||||
manager, but also embeds the Wayland 'Server' functionality. This
|
||||
means it is sufficient to install a Wayland Compositor such as sway
|
||||
without separately enabling a Wayland server:
|
||||
manager, but also embeds the Wayland <quote>Server</quote>
|
||||
functionality. This means it is sufficient to install a Wayland
|
||||
Compositor such as sway without separately enabling a Wayland
|
||||
server:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
programs.sway.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -21,7 +22,7 @@ programs.sway.enable = true;
|
||||
be able to share your screen, you might want to activate this
|
||||
option:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
xdg.portal.wlr.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -9,13 +9,13 @@
|
||||
<para>
|
||||
NixOS will start wpa_supplicant for you if you enable this setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.wireless.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
NixOS lets you specify networks for wpa_supplicant declaratively:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.wireless.networks = {
|
||||
echelon = { # SSID with no spaces or special characters
|
||||
psk = "abcdefgh";
|
||||
@ -49,7 +49,7 @@ network={
|
||||
psk=dca6d6ed41f4ab5a984c9f55f6f66d4efdc720ebf66959810f4329bb391c5435
|
||||
}
|
||||
</programlisting>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.wireless.networks = {
|
||||
echelon = {
|
||||
pskRaw = "dca6d6ed41f4ab5a984c9f55f6f66d4efdc720ebf66959810f4329bb391c5435";
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
The X Window System (X11) provides the basis of NixOS’ graphical
|
||||
user interface. It can be enabled as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -13,7 +13,7 @@ services.xserver.enable = true;
|
||||
and <literal>intel</literal>). You can also specify a driver
|
||||
manually, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.videoDrivers = [ "r128" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -25,7 +25,7 @@ services.xserver.videoDrivers = [ "r128" ];
|
||||
<literal>xterm</literal> window. Thus you should pick one or more of
|
||||
the following lines:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.desktopManager.plasma5.enable = true;
|
||||
services.xserver.desktopManager.xfce.enable = true;
|
||||
services.xserver.desktopManager.gnome.enable = true;
|
||||
@ -42,14 +42,14 @@ services.xserver.windowManager.herbstluftwm.enable = true;
|
||||
LightDM. You can select an alternative one by picking one of the
|
||||
following lines:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.sddm.enable = true;
|
||||
services.xserver.displayManager.gdm.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
You can set the keyboard layout (and optionally the layout variant):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.layout = "de";
|
||||
services.xserver.xkbVariant = "neo";
|
||||
</programlisting>
|
||||
@ -57,7 +57,7 @@ services.xserver.xkbVariant = "neo";
|
||||
The X server is started automatically at boot time. If you don’t
|
||||
want this to happen, you can set:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.autorun = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -70,7 +70,7 @@ services.xserver.autorun = false;
|
||||
On 64-bit systems, if you want OpenGL for 32-bit programs such as in
|
||||
Wine, you should also set the following:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.driSupport32Bit = true;
|
||||
</programlisting>
|
||||
<section xml:id="sec-x11-auto-login">
|
||||
@ -88,16 +88,16 @@ hardware.opengl.driSupport32Bit = true;
|
||||
<para>
|
||||
To enable auto-login, you need to define your default window
|
||||
manager and desktop environment. If you wanted no desktop
|
||||
environment and i3 as your your window manager, you'd define:
|
||||
environment and i3 as your your window manager, you’d define:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.defaultSession = "none+i3";
|
||||
</programlisting>
|
||||
<para>
|
||||
Every display manager in NixOS supports auto-login, here is an
|
||||
example using lightdm for a user <literal>alice</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.lightdm.enable = true;
|
||||
services.xserver.displayManager.autoLogin.enable = true;
|
||||
services.xserver.displayManager.autoLogin.user = "alice";
|
||||
@ -122,8 +122,8 @@ services.xserver.displayManager.autoLogin.user = "alice";
|
||||
<para>
|
||||
The second driver, <literal>intel</literal>, is specific to Intel
|
||||
GPUs, but not recommended by most distributions: it lacks several
|
||||
modern features (for example, it doesn't support Glamor) and the
|
||||
package hasn't been officially updated since 2015.
|
||||
modern features (for example, it doesn’t support Glamor) and the
|
||||
package hasn’t been officially updated since 2015.
|
||||
</para>
|
||||
<para>
|
||||
The results vary depending on the hardware, so you may have to try
|
||||
@ -131,14 +131,14 @@ services.xserver.displayManager.autoLogin.user = "alice";
|
||||
<xref linkend="opt-services.xserver.videoDrivers" /> to set one.
|
||||
The recommended configuration for modern systems is:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.videoDrivers = [ "modesetting" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
If you experience screen tearing no matter what, this
|
||||
configuration was reported to resolve the issue:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.videoDrivers = [ "intel" ];
|
||||
services.xserver.deviceSection = ''
|
||||
Option "DRI" "2"
|
||||
@ -159,14 +159,14 @@ services.xserver.deviceSection = ''
|
||||
enabled by default because it’s not free software. You can enable
|
||||
it as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.videoDrivers = [ "nvidia" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
Or if you have an older card, you may have to use one of the
|
||||
legacy drivers:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.videoDrivers = [ "nvidiaLegacy390" ];
|
||||
services.xserver.videoDrivers = [ "nvidiaLegacy340" ];
|
||||
services.xserver.videoDrivers = [ "nvidiaLegacy304" ];
|
||||
@ -181,11 +181,11 @@ services.xserver.videoDrivers = [ "nvidiaLegacy304" ];
|
||||
<para>
|
||||
AMD provides a proprietary driver for its graphics cards that is
|
||||
not enabled by default because it’s not Free Software, is often
|
||||
broken in nixpkgs and as of this writing doesn't offer more
|
||||
broken in nixpkgs and as of this writing doesn’t offer more
|
||||
features or performance. If you still want to use it anyway, you
|
||||
need to explicitly set:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.videoDrivers = [ "amdgpu-pro" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -199,14 +199,14 @@ services.xserver.videoDrivers = [ "amdgpu-pro" ];
|
||||
Support for Synaptics touchpads (found in many laptops such as the
|
||||
Dell Latitude series) can be enabled as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.libinput.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
The driver has many options (see <xref linkend="ch-options" />).
|
||||
For instance, the following disables tap-to-click behavior:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.libinput.touchpad.tapping = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -222,7 +222,7 @@ services.xserver.libinput.touchpad.tapping = false;
|
||||
applications look similar to GTK ones, you can use the following
|
||||
configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
qt5.enable = true;
|
||||
qt5.platformTheme = "gtk2";
|
||||
qt5.style = "gtk2";
|
||||
@ -244,10 +244,10 @@ qt5.style = "gtk2";
|
||||
<para>
|
||||
Create a file called <literal>us-greek</literal> with the
|
||||
following content (under a directory called
|
||||
<literal>symbols</literal>; it's an XKB peculiarity that will help
|
||||
<literal>symbols</literal>; it’s an XKB peculiarity that will help
|
||||
with testing):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
xkb_symbols "us-greek"
|
||||
{
|
||||
include "us(basic)" // includes the base US keys
|
||||
@ -263,7 +263,7 @@ xkb_symbols "us-greek"
|
||||
<para>
|
||||
A minimal layout specification must include the following:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.extraLayouts.us-greek = {
|
||||
description = "US layout with alt-gr greek";
|
||||
languages = [ "eng" ];
|
||||
@ -279,7 +279,7 @@ services.xserver.extraLayouts.us-greek = {
|
||||
<para>
|
||||
Applying this customization requires rebuilding several packages,
|
||||
and a broken XKB file can lead to the X session crashing at login.
|
||||
Therefore, you're strongly advised to <emphasis role="strong">test
|
||||
Therefore, you’re strongly advised to <emphasis role="strong">test
|
||||
your layout before applying it</emphasis>:
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -312,7 +312,7 @@ $ echo "$(nix-build --no-out-link '<nixpkgs>' -A xorg.xkeyboardconfig
|
||||
interest, then create a <literal>media-key</literal> file to hold
|
||||
the keycodes definitions
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
xkb_keycodes "media"
|
||||
{
|
||||
<volUp> = 123;
|
||||
@ -322,7 +322,7 @@ xkb_keycodes "media"
|
||||
<para>
|
||||
Now use the newly define keycodes in <literal>media-sym</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
xkb_symbols "media"
|
||||
{
|
||||
key.type = "ONE_LEVEL";
|
||||
@ -333,7 +333,7 @@ xkb_symbols "media"
|
||||
<para>
|
||||
As before, to install the layout do
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.extraLayouts.media = {
|
||||
description = "Multimedia keys remapping";
|
||||
languages = [ "eng" ];
|
||||
@ -352,18 +352,18 @@ services.xserver.extraLayouts.media = {
|
||||
<para>
|
||||
Unfortunately, the Xorg server does not (currently) support
|
||||
setting a keymap directly but relies instead on XKB rules to
|
||||
select the matching components (keycodes, types, ...) of a layout.
|
||||
This means that components other than symbols won't be loaded by
|
||||
select the matching components (keycodes, types, …) of a layout.
|
||||
This means that components other than symbols won’t be loaded by
|
||||
default. As a workaround, you can set the keymap using
|
||||
<literal>setxkbmap</literal> at the start of the session with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.sessionCommands = "setxkbmap -keycodes media";
|
||||
</programlisting>
|
||||
<para>
|
||||
If you are manually starting the X server, you should set the
|
||||
argument <literal>-xkbdir /etc/X11/xkb</literal>, otherwise X
|
||||
won't find your layout files. For example with
|
||||
won’t find your layout files. For example with
|
||||
<literal>xinit</literal> run
|
||||
</para>
|
||||
<programlisting>
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<para>
|
||||
To enable the Xfce Desktop Environment, set
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.desktopManager.xfce.enable = true;
|
||||
services.xserver.displayManager.defaultSession = "xfce";
|
||||
</programlisting>
|
||||
@ -11,7 +11,7 @@ services.xserver.displayManager.defaultSession = "xfce";
|
||||
Optionally, <emphasis>picom</emphasis> can be enabled for nice
|
||||
graphical effects, some example settings:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.picom = {
|
||||
enable = true;
|
||||
fade = true;
|
||||
@ -36,8 +36,8 @@ services.picom = {
|
||||
<xref linkend="opt-environment.systemPackages" />.
|
||||
</para>
|
||||
<para>
|
||||
If you'd like to add extra plugins to Thunar, add them to
|
||||
<xref linkend="opt-programs.thunar.plugins" />. You shouldn't just
|
||||
If you’d like to add extra plugins to Thunar, add them to
|
||||
<xref linkend="opt-programs.thunar.plugins" />. You shouldn’t just
|
||||
add them to <xref linkend="opt-environment.systemPackages" />.
|
||||
</para>
|
||||
</section>
|
||||
@ -54,9 +54,10 @@ Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with db
|
||||
</programlisting>
|
||||
<para>
|
||||
This is caused by some needed GNOME services not running. This is
|
||||
all fixed by enabling "Launch GNOME services on startup"
|
||||
in the Advanced tab of the Session and Startup settings panel.
|
||||
Alternatively, you can run this command to do the same thing.
|
||||
all fixed by enabling <quote>Launch GNOME services on
|
||||
startup</quote> in the Advanced tab of the Session and Startup
|
||||
settings panel. Alternatively, you can run this command to do the
|
||||
same thing.
|
||||
</para>
|
||||
<programlisting>
|
||||
$ xfconf-query -c xfce4-session -p /compat/LaunchGNOME -s true
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
these dependencies into account and order the snippets accordingly.
|
||||
As a simple example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
system.activationScripts.my-activation-script = {
|
||||
deps = [ "etc" ];
|
||||
# supportsDryActivation = true;
|
||||
|
||||
@ -18,7 +18,7 @@
|
||||
<para>
|
||||
This is an example of using <literal>warnings</literal>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, ... }:
|
||||
{
|
||||
config = lib.mkIf config.services.foo.enable {
|
||||
@ -42,7 +42,7 @@
|
||||
assertion is useful to prevent such a broken system from being
|
||||
built.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, ... }:
|
||||
{
|
||||
config = lib.mkIf config.services.syslogd.enable {
|
||||
|
||||
@ -43,7 +43,7 @@
|
||||
<literal>/etc/os-release</literal> in order to bake it into a
|
||||
unified kernel image:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, ... }: {
|
||||
boot.bootspec.extensions = {
|
||||
"org.secureboot.osRelease" = config.environment.etc."os-release".source;
|
||||
|
||||
@ -30,7 +30,7 @@
|
||||
type-checked <literal>settings</literal> attribute</link> for a more
|
||||
complete example.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ lib, config, ... }: {
|
||||
|
||||
options.settings = lib.mkOption {
|
||||
@ -52,7 +52,7 @@
|
||||
<para>
|
||||
And the following shows what such a module then allows
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
# Not a declared option, but the freeform type allows this
|
||||
settings.logLevel = "debug";
|
||||
@ -72,7 +72,7 @@
|
||||
Freeform attributes cannot depend on other attributes of the same
|
||||
set without infinite recursion:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
# This throws infinite recursion encountered
|
||||
settings.logLevel = lib.mkIf (config.settings.port == 80) "debug";
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
Sometimes NixOS modules need to be used in configuration but exist
|
||||
outside of Nixpkgs. These modules can be imported:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
{
|
||||
@ -23,18 +23,18 @@
|
||||
Nixpkgs NixOS modules. Like any NixOS module, this module can import
|
||||
additional modules:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
# ./module-list/default.nix
|
||||
[
|
||||
./example-module1
|
||||
./example-module2
|
||||
]
|
||||
</programlisting>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
# ./extra-module/default.nix
|
||||
{ imports = import ./module-list.nix; }
|
||||
</programlisting>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
# NIXOS_EXTRA_MODULE_PATH=/absolute/path/to/extra-module
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
Each of the meta-attributes must be defined at most once per module
|
||||
file.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, pkgs, ... }:
|
||||
{
|
||||
options = {
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
hasn’t been declared in any module. An option declaration generally
|
||||
looks like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
options = {
|
||||
name = mkOption {
|
||||
type = type specification;
|
||||
@ -127,7 +127,7 @@ options = {
|
||||
For example:
|
||||
</para>
|
||||
<anchor xml:id="ex-options-declarations-util-mkEnableOption-magic" />
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
lib.mkEnableOption "magic"
|
||||
# is like
|
||||
lib.mkOption {
|
||||
@ -142,7 +142,7 @@ lib.mkOption {
|
||||
<para>
|
||||
Usage:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
mkPackageOption pkgs "name" { default = [ "path" "in" "pkgs" ]; example = "literal example"; }
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -177,7 +177,7 @@ mkPackageOption pkgs "name" { default = [ "path" "in&qu
|
||||
Examples:
|
||||
</para>
|
||||
<anchor xml:id="ex-options-declarations-util-mkPackageOption-hello" />
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
lib.mkPackageOption pkgs "hello" { }
|
||||
# is like
|
||||
lib.mkOption {
|
||||
@ -188,7 +188,7 @@ lib.mkOption {
|
||||
}
|
||||
</programlisting>
|
||||
<anchor xml:id="ex-options-declarations-util-mkPackageOption-ghc" />
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
lib.mkPackageOption pkgs "GHC" {
|
||||
default = [ "ghc" ];
|
||||
example = "pkgs.haskell.packages.ghc92.ghc.withPackages (hkgs: [ hkgs.primes ])";
|
||||
@ -222,7 +222,7 @@ lib.mkOption {
|
||||
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 (sddm, gdm ...).
|
||||
manager backend (sddm, gdm …).
|
||||
</para>
|
||||
<para>
|
||||
There are two approaches we could take with this module
|
||||
@ -287,7 +287,7 @@ lib.mkOption {
|
||||
<emphasis role="strong">Example: Extensible type placeholder
|
||||
in the service module</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.enable = mkOption {
|
||||
description = "Display manager to use";
|
||||
type = with types; nullOr (enum [ ]);
|
||||
@ -299,7 +299,7 @@ services.xserver.displayManager.enable = mkOption {
|
||||
<literal>services.xserver.displayManager.enable</literal> in
|
||||
the <literal>gdm</literal> module</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.enable = mkOption {
|
||||
type = with types; nullOr (enum [ "gdm" ]);
|
||||
};
|
||||
@ -310,7 +310,7 @@ services.xserver.displayManager.enable = mkOption {
|
||||
<literal>services.xserver.displayManager.enable</literal> in
|
||||
the <literal>sddm</literal> module</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.xserver.displayManager.enable = mkOption {
|
||||
type = with types; nullOr (enum [ "sddm" ]);
|
||||
};
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
Option definitions are generally straight-forward bindings of values
|
||||
to option names, like
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config = {
|
||||
services.httpd.enable = true;
|
||||
};
|
||||
@ -21,7 +21,7 @@ config = {
|
||||
another option, you may need to use <literal>mkIf</literal>.
|
||||
Consider, for instance:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config = if config.services.httpd.enable then {
|
||||
environment.systemPackages = [ ... ];
|
||||
...
|
||||
@ -34,7 +34,7 @@ config = if config.services.httpd.enable then {
|
||||
value being constructed here. After all, you could also write the
|
||||
clearly circular and contradictory:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config = if config.services.httpd.enable then {
|
||||
services.httpd.enable = false;
|
||||
} else {
|
||||
@ -44,7 +44,7 @@ config = if config.services.httpd.enable then {
|
||||
<para>
|
||||
The solution is to write:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config = mkIf config.services.httpd.enable {
|
||||
environment.systemPackages = [ ... ];
|
||||
...
|
||||
@ -55,7 +55,7 @@ config = mkIf config.services.httpd.enable {
|
||||
of the conditional to be <quote>pushed down</quote> into the
|
||||
individual definitions, as if you had written:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config = {
|
||||
environment.systemPackages = if config.services.httpd.enable then [ ... ] else [];
|
||||
...
|
||||
@ -72,7 +72,7 @@ config = {
|
||||
option defaults have priority 1500. You can specify an explicit
|
||||
priority by using <literal>mkOverride</literal>, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.openssh.enable = mkOverride 10 false;
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -94,7 +94,7 @@ services.openssh.enable = mkOverride 10 false;
|
||||
<literal>mkOrder 500</literal> and
|
||||
<literal>mkOrder 1500</literal>, respectively. As an example,
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.firmware = mkBefore [ myFirmware ];
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -117,7 +117,7 @@ hardware.firmware = mkBefore [ myFirmware ];
|
||||
to be merged together as if they were declared in separate
|
||||
modules. This can be done using <literal>mkMerge</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config = mkMerge
|
||||
[ # Unconditional stuff.
|
||||
{ environment.systemPackages = [ ... ];
|
||||
|
||||
@ -81,14 +81,14 @@
|
||||
<para>
|
||||
Two definitions of this type like
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
str = lib.mkDefault "foo";
|
||||
pkg.hello = pkgs.hello;
|
||||
fun.fun = x: x + 1;
|
||||
}
|
||||
</programlisting>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
str = lib.mkIf true "bar";
|
||||
pkg.gcc = pkgs.gcc;
|
||||
@ -98,7 +98,7 @@
|
||||
<para>
|
||||
will get merged to
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
str = "bar";
|
||||
pkg.gcc = pkgs.gcc;
|
||||
@ -152,13 +152,13 @@
|
||||
<warning>
|
||||
<para>
|
||||
This type will be deprecated in the future because it
|
||||
doesn't recurse into attribute sets, silently drops
|
||||
earlier attribute definitions, and doesn't discharge
|
||||
doesn’t recurse into attribute sets, silently drops
|
||||
earlier attribute definitions, and doesn’t discharge
|
||||
<literal>lib.mkDefault</literal>,
|
||||
<literal>lib.mkIf</literal> and co. For allowing arbitrary
|
||||
attribute sets, prefer
|
||||
<literal>types.attrsOf types.anything</literal> instead
|
||||
which doesn't have these problems.
|
||||
which doesn’t have these problems.
|
||||
</para>
|
||||
</warning>
|
||||
</listitem>
|
||||
@ -453,7 +453,7 @@
|
||||
<literal>_module.args</literal> should be used instead
|
||||
for most arguments since it allows overriding.
|
||||
<emphasis><literal>specialArgs</literal></emphasis>
|
||||
should only be used for arguments that can't go through
|
||||
should only be used for arguments that can’t go through
|
||||
the module fixed-point, because of infinite recursion or
|
||||
other problems. An example is overriding the
|
||||
<literal>lib</literal> argument, because
|
||||
@ -477,7 +477,7 @@
|
||||
instead of requiring
|
||||
<literal>the-submodule.config.config = "value"</literal>.
|
||||
This is because only when modules
|
||||
<emphasis>don't</emphasis> set the
|
||||
<emphasis>don’t</emphasis> set the
|
||||
<literal>config</literal> or <literal>options</literal>
|
||||
keys, all keys are interpreted as option definitions in
|
||||
the <literal>config</literal> section. Enabling this
|
||||
@ -668,7 +668,7 @@
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>types.oneOf</literal> [
|
||||
<emphasis><literal>t1 t2</literal></emphasis> ... ]
|
||||
<emphasis><literal>t1 t2</literal></emphasis> … ]
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -732,7 +732,7 @@
|
||||
<emphasis role="strong">Example: Directly defined
|
||||
submodule</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
options.mod = mkOption {
|
||||
description = "submodule example";
|
||||
type = with types; submodule {
|
||||
@ -752,7 +752,7 @@ options.mod = mkOption {
|
||||
<emphasis role="strong">Example: Submodule defined as a
|
||||
reference</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
let
|
||||
modOptions = {
|
||||
options = {
|
||||
@ -787,7 +787,7 @@ options.mod = mkOption {
|
||||
<emphasis role="strong">Example: Declaration of a list of
|
||||
submodules</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
options.mod = mkOption {
|
||||
description = "submodule example";
|
||||
type = with types; listOf (submodule {
|
||||
@ -807,7 +807,7 @@ options.mod = mkOption {
|
||||
<emphasis role="strong">Example: Definition of a list of
|
||||
submodules</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config.mod = [
|
||||
{ foo = 1; bar = "one"; }
|
||||
{ foo = 2; bar = "two"; }
|
||||
@ -827,7 +827,7 @@ config.mod = [
|
||||
<emphasis role="strong">Example: Declaration of attribute sets of
|
||||
submodules</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
options.mod = mkOption {
|
||||
description = "submodule example";
|
||||
type = with types; attrsOf (submodule {
|
||||
@ -847,7 +847,7 @@ options.mod = mkOption {
|
||||
<emphasis role="strong">Example: Definition of attribute sets of
|
||||
submodules</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
config.mod.one = { foo = 1; bar = "one"; };
|
||||
config.mod.two = { foo = 2; bar = "two"; };
|
||||
</programlisting>
|
||||
@ -878,7 +878,7 @@ config.mod.two = { foo = 2; bar = "two"; };
|
||||
<emphasis role="strong">Example: Adding a type
|
||||
check</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
byte = mkOption {
|
||||
description = "An integer between 0 and 255.";
|
||||
type = types.addCheck types.int (x: x >= 0 && x <= 255);
|
||||
@ -889,7 +889,7 @@ byte = mkOption {
|
||||
<emphasis role="strong">Example: Overriding a type
|
||||
check</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nixThings = mkOption {
|
||||
description = "words that start with 'nix'";
|
||||
type = types.str // {
|
||||
|
||||
@ -3,8 +3,8 @@
|
||||
<para>
|
||||
Modules that are imported can also be disabled. The option
|
||||
declarations, config implementation and the imports 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
|
||||
module will be ignored, allowing another to take its 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>
|
||||
@ -19,10 +19,10 @@
|
||||
This example will replace the existing postgresql module with the
|
||||
version defined in the nixos-unstable channel while keeping the rest
|
||||
of the modules and packages from the original nixos channel. This
|
||||
only overrides the module definition, this won't use postgresql from
|
||||
only overrides the module definition, this won’t use postgresql from
|
||||
nixos-unstable unless explicitly configured to do so.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
{
|
||||
@ -40,9 +40,9 @@
|
||||
<para>
|
||||
This example shows how to define a custom module as a replacement
|
||||
for an existing module. Importing this module will disable the
|
||||
original module without having to know it's implementation details.
|
||||
original module without having to know its implementation details.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
@ -19,10 +19,10 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Non-nix-representable ones: These can't be trivially mapped to a
|
||||
Non-nix-representable ones: These can’t be trivially mapped to a
|
||||
subset of Nix syntax. Most generic programming languages are in
|
||||
this group, e.g. bash, since the statement
|
||||
<literal>if true; then echo hi; fi</literal> doesn't have a
|
||||
<literal>if true; then echo hi; fi</literal> doesn’t have a
|
||||
trivial representation in Nix.
|
||||
</para>
|
||||
<para>
|
||||
@ -42,8 +42,7 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="sec-settings-nix-representable">
|
||||
<title>Nix-representable Formats (JSON, YAML, TOML, INI,
|
||||
...)</title>
|
||||
<title>Nix-representable Formats (JSON, YAML, TOML, INI, …)</title>
|
||||
<para>
|
||||
By convention, formats like this are handled with a generic
|
||||
<literal>settings</literal> option, representing the full program
|
||||
@ -318,7 +317,7 @@
|
||||
used, along with some other related best practices. See the
|
||||
comments for explanations.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ options, config, lib, pkgs, ... }:
|
||||
let
|
||||
cfg = config.services.foo;
|
||||
@ -391,7 +390,7 @@ in {
|
||||
<emphasis role="strong">Example: Declaring a type-checked
|
||||
<literal>settings</literal> attribute</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
settings = lib.mkOption {
|
||||
type = lib.types.submodule {
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ $ nix-shell
|
||||
nix-shell$ make
|
||||
</programlisting>
|
||||
<para>
|
||||
Once you are done making modifications to the manual, it's
|
||||
Once you are done making modifications to the manual, it’s
|
||||
important to build it before committing. You can do that as
|
||||
follows:
|
||||
</para>
|
||||
|
||||
@ -32,7 +32,7 @@
|
||||
In <xref linkend="sec-configuration-syntax" />, we saw the following
|
||||
structure of NixOS modules:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ option definitions
|
||||
@ -50,7 +50,7 @@
|
||||
<emphasis role="strong">Example: Structure of NixOS
|
||||
Modules</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{
|
||||
@ -90,7 +90,7 @@
|
||||
This <literal>imports</literal> list enumerates the paths to
|
||||
other NixOS modules that should be included in the evaluation of
|
||||
the system configuration. A default set of modules is defined in
|
||||
the file <literal>modules/module-list.nix</literal>. These don't
|
||||
the file <literal>modules/module-list.nix</literal>. These don’t
|
||||
need to be added in the import list.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -146,7 +146,7 @@
|
||||
<emphasis role="strong">Example: NixOS Module for the
|
||||
<quote>locate</quote> Service</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
with lib;
|
||||
@ -208,7 +208,7 @@ in {
|
||||
<emphasis role="strong">Example: Escaping in Exec
|
||||
directives</emphasis>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, lib, pkgs, utils, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<para>
|
||||
A NixOS test is a module that has the following structure:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
|
||||
# One or more machines:
|
||||
@ -58,14 +58,14 @@
|
||||
Tests that are part of NixOS are added to
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/all-tests.nix"><literal>nixos/tests/all-tests.nix</literal></link>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hostname = runTest ./hostname.nix;
|
||||
</programlisting>
|
||||
<para>
|
||||
Overrides can be added by defining an anonymous module in
|
||||
<literal>all-tests.nix</literal>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hostname = runTest {
|
||||
imports = [ ./hostname.nix ];
|
||||
defaults.networking.firewall.enable = false;
|
||||
@ -87,7 +87,7 @@ nix-build -A nixosTests.hostname
|
||||
Outside the <literal>nixpkgs</literal> repository, you can
|
||||
instantiate the test by first importing the NixOS library,
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
let nixos-lib = import (nixpkgs + "/nixos/lib") { };
|
||||
in
|
||||
|
||||
@ -255,7 +255,7 @@ start_all()
|
||||
<listitem>
|
||||
<para>
|
||||
Return a list of different interpretations of what is
|
||||
currently visible on the machine's screen using optical
|
||||
currently visible on the machine’s screen using optical
|
||||
character recognition. The number and order of the
|
||||
interpretations is not specified and is subject to change,
|
||||
but if no exception is raised at least one will be returned.
|
||||
@ -276,7 +276,7 @@ start_all()
|
||||
<listitem>
|
||||
<para>
|
||||
Return a textual representation of what is currently visible
|
||||
on the machine's screen using optical character recognition.
|
||||
on the machine’s screen using optical character recognition.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
@ -630,10 +630,10 @@ machine.wait_for_unit("xautolock.service", "x-session-user")
|
||||
<literal>stop_job</literal>.
|
||||
</para>
|
||||
<para>
|
||||
For faster dev cycles it's also possible to disable the
|
||||
code-linters (this shouldn't be committed though):
|
||||
For faster dev cycles it’s also possible to disable the
|
||||
code-linters (this shouldn’t be committed though):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
skipLint = true;
|
||||
nodes.machine =
|
||||
@ -650,10 +650,10 @@ machine.wait_for_unit("xautolock.service", "x-session-user")
|
||||
<para>
|
||||
This will produce a Nix warning at evaluation time. To fully
|
||||
disable the linter, wrap the test script in comment directives to
|
||||
disable the Black linter directly (again, don't commit this within
|
||||
disable the Black linter directly (again, don’t commit this within
|
||||
the Nixpkgs repository):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
testScript =
|
||||
''
|
||||
# fmt: off
|
||||
@ -665,7 +665,7 @@ machine.wait_for_unit("xautolock.service", "x-session-user")
|
||||
Similarly, the type checking of test scripts can be disabled in
|
||||
the following way:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
skipTypeCheck = true;
|
||||
nodes.machine =
|
||||
@ -700,25 +700,37 @@ with foo_running:
|
||||
<literal>polling_condition</literal> takes the following
|
||||
(optional) arguments:
|
||||
</para>
|
||||
<para>
|
||||
<literal>seconds_interval</literal>
|
||||
</para>
|
||||
<para>
|
||||
: specifies how often the condition should be polled:
|
||||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>seconds_interval</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
specifies how often the condition should be polled:
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<programlisting language="python">
|
||||
@polling_condition(seconds_interval=10)
|
||||
def foo_running():
|
||||
machine.succeed("pgrep -x foo")
|
||||
</programlisting>
|
||||
<para>
|
||||
<literal>description</literal>
|
||||
</para>
|
||||
<para>
|
||||
: is used in the log when the condition is checked. If this is not
|
||||
provided, the description is pulled from the docstring of the
|
||||
function. These two are therefore equivalent:
|
||||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>description</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is used in the log when the condition is checked. If this is
|
||||
not provided, the description is pulled from the docstring
|
||||
of the function. These two are therefore equivalent:
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<programlisting language="python">
|
||||
@polling_condition
|
||||
def foo_running():
|
||||
@ -739,7 +751,7 @@ def foo_running():
|
||||
<literal>extraPythonPackages</literal>. For example, you could add
|
||||
<literal>numpy</literal> like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
extraPythonPackages = p: [ p.numpy ];
|
||||
|
||||
|
||||
@ -62,7 +62,7 @@ $ nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd
|
||||
can create the following file at
|
||||
<literal>modules/installer/cd-dvd/installation-cd-graphical-gnome-macbook.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, ... }:
|
||||
|
||||
{
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
</para>
|
||||
<warning>
|
||||
<para>
|
||||
This command doesn't start/stop
|
||||
This command doesn’t start/stop
|
||||
<link linkend="opt-systemd.user.services">user services</link>
|
||||
automatically. <literal>nixos-rebuild</literal> only runs a
|
||||
<literal>daemon-reload</literal> for each user with running user
|
||||
@ -64,8 +64,8 @@
|
||||
<para>
|
||||
which causes the new configuration (and previous ones created using
|
||||
<literal>-p test</literal>) to show up in the GRUB submenu
|
||||
<quote>NixOS - Profile 'test'</quote>. This can be useful to
|
||||
separate test configurations from <quote>stable</quote>
|
||||
<quote>NixOS - Profile <quote>test</quote></quote>. This can be
|
||||
useful to separate test configurations from <quote>stable</quote>
|
||||
configurations.
|
||||
</para>
|
||||
<para>
|
||||
@ -94,7 +94,7 @@ $ ./result/bin/run-*-vm
|
||||
unless you have set <literal>mutableUsers = false</literal>. Another
|
||||
way is to temporarily add the following to your configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.your-user.initialHashedPassword = "test";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
<literal>/mnt/etc/nixos/configuration.nix</literal> to keep the
|
||||
internet accessible after reboot.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.proxy.default = "http://user:password@proxy:port/";
|
||||
networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";
|
||||
</programlisting>
|
||||
|
||||
@ -53,7 +53,7 @@ $ . $HOME/.nix-profile/etc/profile.d/nix.sh # …or open a fresh shell
|
||||
Switch to the NixOS channel:
|
||||
</para>
|
||||
<para>
|
||||
If you've just installed Nix on a non-NixOS distribution, you
|
||||
If you’ve just installed Nix on a non-NixOS distribution, you
|
||||
will be on the <literal>nixpkgs</literal> channel by default.
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -78,11 +78,11 @@ $ nix-channel --add https://nixos.org/channels/nixos-version nixpkgs
|
||||
Install the NixOS installation tools:
|
||||
</para>
|
||||
<para>
|
||||
You'll need <literal>nixos-generate-config</literal> and
|
||||
You’ll need <literal>nixos-generate-config</literal> and
|
||||
<literal>nixos-install</literal>, but this also makes some man
|
||||
pages and <literal>nixos-enter</literal> available, just in case
|
||||
you want to chroot into your NixOS partition. NixOS installs
|
||||
these by default, but you don't have NixOS yet..
|
||||
these by default, but you don’t have NixOS yet..
|
||||
</para>
|
||||
<programlisting>
|
||||
$ nix-env -f '<nixpkgs>' -iA nixos-install-tools
|
||||
@ -105,7 +105,7 @@ $ nix-env -f '<nixpkgs>' -iA nixos-install-tools
|
||||
mounting steps of <xref linkend="sec-installation" />
|
||||
</para>
|
||||
<para>
|
||||
If you're about to install NixOS in place using
|
||||
If you’re about to install NixOS in place using
|
||||
<literal>NIXOS_LUSTRATE</literal> there is nothing to do for
|
||||
this step.
|
||||
</para>
|
||||
@ -118,18 +118,18 @@ $ nix-env -f '<nixpkgs>' -iA nixos-install-tools
|
||||
$ sudo `which nixos-generate-config` --root /mnt
|
||||
</programlisting>
|
||||
<para>
|
||||
You'll probably want to edit the configuration files. Refer to
|
||||
You’ll probably want to edit the configuration files. Refer to
|
||||
the <literal>nixos-generate-config</literal> step in
|
||||
<xref 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
|
||||
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 language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.loader.grub.extraEntries = ''
|
||||
menuentry "Ubuntu" {
|
||||
search --set=ubuntu --fs-uuid 3cc3e652-0c1f-4800-8451-033754f68e6e
|
||||
@ -215,21 +215,21 @@ $ sudo `which nixos-generate-config`
|
||||
</programlisting>
|
||||
<para>
|
||||
Note that this will place the generated configuration files in
|
||||
<literal>/etc/nixos</literal>. You'll probably want to edit the
|
||||
<literal>/etc/nixos</literal>. You’ll probably want to edit the
|
||||
configuration files. Refer to the
|
||||
<literal>nixos-generate-config</literal> step in
|
||||
<xref linkend="sec-installation" /> for more information.
|
||||
</para>
|
||||
<para>
|
||||
You'll likely want to set a root password for your first boot
|
||||
using the configuration files because you won't have a chance to
|
||||
You’ll likely want to set a root password for your first boot
|
||||
using the configuration files because you won’t have a chance to
|
||||
enter a password until after you reboot. You can initialize the
|
||||
root password to an empty one with this line: (and of course
|
||||
don't forget to set one once you've rebooted or to lock the
|
||||
don’t forget to set one once you’ve rebooted or to lock the
|
||||
account with <literal>sudo passwd -l root</literal> if you use
|
||||
<literal>sudo</literal>)
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.root.initialHashedPassword = "";
|
||||
</programlisting>
|
||||
</listitem>
|
||||
@ -262,7 +262,7 @@ $ sudo chown -R 0:0 /nix
|
||||
</para>
|
||||
<para>
|
||||
<literal>/etc/NIXOS_LUSTRATE</literal> tells the NixOS bootup
|
||||
scripts to move <emphasis>everything</emphasis> that's in the
|
||||
scripts to move <emphasis>everything</emphasis> that’s in the
|
||||
root partition to <literal>/old-root</literal>. This will move
|
||||
your existing distribution out of the way in the very early
|
||||
stages of the NixOS bootup. There are exceptions (we do need to
|
||||
@ -290,12 +290,12 @@ $ sudo chown -R 0:0 /nix
|
||||
<note>
|
||||
<para>
|
||||
Support for <literal>NIXOS_LUSTRATE</literal> was added in
|
||||
NixOS 16.09. The act of "lustrating" refers to the
|
||||
wiping of the existing distribution. Creating
|
||||
NixOS 16.09. The act of <quote>lustrating</quote> refers to
|
||||
the wiping of the existing distribution. Creating
|
||||
<literal>/etc/NIXOS_LUSTRATE</literal> can also be used on
|
||||
NixOS to remove all mutable files from your root partition
|
||||
(anything that's not in <literal>/nix</literal> or
|
||||
<literal>/boot</literal> gets "lustrated" on the
|
||||
(anything that’s not in <literal>/nix</literal> or
|
||||
<literal>/boot</literal> gets <quote>lustrated</quote> on the
|
||||
next boot.
|
||||
</para>
|
||||
<para>
|
||||
@ -307,14 +307,14 @@ $ sudo chown -R 0:0 /nix
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
Let's create the files:
|
||||
Let’s create the files:
|
||||
</para>
|
||||
<programlisting>
|
||||
$ sudo touch /etc/NIXOS
|
||||
$ sudo touch /etc/NIXOS_LUSTRATE
|
||||
</programlisting>
|
||||
<para>
|
||||
Let's also make sure the NixOS configuration files are kept once
|
||||
Let’s also make sure the NixOS configuration files are kept once
|
||||
we reboot on NixOS:
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -331,7 +331,7 @@ $ echo etc/nixos | sudo tee -a /etc/NIXOS_LUSTRATE
|
||||
<warning>
|
||||
<para>
|
||||
Once you complete this step, your current distribution will no
|
||||
longer be bootable! If you didn't get all the NixOS
|
||||
longer be bootable! If you didn’t get all the NixOS
|
||||
configuration right, especially those settings pertaining to
|
||||
boot loading and root partition, NixOS may not be bootable
|
||||
either. Have a USB rescue device ready in case this happens.
|
||||
@ -349,7 +349,7 @@ sudo /nix/var/nix/profiles/system/bin/switch-to-configuration boot
|
||||
<listitem>
|
||||
<para>
|
||||
If for some reason you want to revert to the old distribution,
|
||||
you'll need to boot on a USB rescue disk and do something along
|
||||
you’ll need to boot on a USB rescue disk and do something along
|
||||
these lines:
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -367,7 +367,7 @@ sudo /nix/var/nix/profiles/system/bin/switch-to-configuration boot
|
||||
loader.
|
||||
</para>
|
||||
<para>
|
||||
And of course, if you're happy with NixOS and no longer need the
|
||||
And of course, if you’re happy with NixOS and no longer need the
|
||||
old distribution:
|
||||
</para>
|
||||
<programlisting>
|
||||
@ -376,7 +376,7 @@ sudo rm -rf /old-root
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It's also worth noting that this whole process can be automated.
|
||||
It’s also worth noting that this whole process can be automated.
|
||||
This is especially useful for Cloud VMs, where provider do not
|
||||
provide NixOS. For instance,
|
||||
<link xlink:href="https://github.com/elitak/nixos-infect">nixos-infect</link>
|
||||
|
||||
@ -54,7 +54,7 @@ nix-build -A kexec.x86_64-linux '<nixpkgs/nixos/release.nix>'
|
||||
running Linux Distribution.
|
||||
</para>
|
||||
<para>
|
||||
Note it’s symlinks pointing elsewhere, so <literal>cd</literal> in,
|
||||
Note its symlinks pointing elsewhere, so <literal>cd</literal> in,
|
||||
and use <literal>scp * root@$destination</literal> to copy it over,
|
||||
rather than rsync.
|
||||
</para>
|
||||
@ -69,7 +69,7 @@ nix-build -A kexec.x86_64-linux '<nixpkgs/nixos/release.nix>'
|
||||
instead of the default installer image, you can build your own
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ modulesPath, ... }: {
|
||||
imports = [
|
||||
(modulesPath + "/installer/netboot/netboot-minimal.nix")
|
||||
|
||||
@ -110,15 +110,15 @@ diskutil unmountDisk diskX
|
||||
sudo dd if=<path-to-image> of=/dev/rdiskX bs=4m
|
||||
</programlisting>
|
||||
<para>
|
||||
After <literal>dd</literal> completes, a GUI dialog "The disk
|
||||
you inserted was not readable by this computer" will pop up,
|
||||
which can be ignored.
|
||||
After <literal>dd</literal> completes, a GUI dialog <quote>The
|
||||
disk you inserted was not readable by this computer</quote> will
|
||||
pop up, which can be ignored.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Using the 'raw' <literal>rdiskX</literal> device instead of
|
||||
<literal>diskX</literal> with dd completes in minutes instead of
|
||||
hours.
|
||||
Using the <quote>raw</quote> <literal>rdiskX</literal> device
|
||||
instead of <literal>diskX</literal> with dd completes in minutes
|
||||
instead of hours.
|
||||
</para>
|
||||
</note>
|
||||
<orderedlist numeration="arabic" spacing="compact">
|
||||
|
||||
@ -11,8 +11,8 @@
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem>
|
||||
<para>
|
||||
Add a New Machine in VirtualBox with OS Type "Linux / Other
|
||||
Linux"
|
||||
Add a New Machine in VirtualBox with OS Type <quote>Linux /
|
||||
Other Linux</quote>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -38,7 +38,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Click on Settings / System / Acceleration and enable
|
||||
"VT-x/AMD-V" acceleration
|
||||
<quote>VT-x/AMD-V</quote> acceleration
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -58,25 +58,25 @@
|
||||
There are a few modifications you should make in configuration.nix.
|
||||
Enable booting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.loader.grub.device = "/dev/sda";
|
||||
</programlisting>
|
||||
<para>
|
||||
Also remove the fsck that runs at startup. It will always fail to
|
||||
run, stopping your boot until you press <literal>*</literal>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.checkJournalingFS = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
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 "Add" icon). Add the following to the
|
||||
click on the <quote>Add</quote> icon). Add the following to the
|
||||
<literal>/etc/nixos/configuration.nix</literal> to auto-mount them.
|
||||
If you do not add <literal>"nofail"</literal>, the system
|
||||
will not boot properly.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ...} :
|
||||
{
|
||||
fileSystems."/virtualboxshare" = {
|
||||
|
||||
@ -345,12 +345,12 @@ OK
|
||||
<!-- legacy anchor -->
|
||||
</para>
|
||||
<para>
|
||||
Here's an example partition scheme for UEFI, using
|
||||
Here’s an example partition scheme for UEFI, using
|
||||
<literal>/dev/sda</literal> as the device.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
You can safely ignore <literal>parted</literal>'s
|
||||
You can safely ignore <literal>parted</literal>’s
|
||||
informational message about needing to update /etc/fstab.
|
||||
</para>
|
||||
</note>
|
||||
@ -415,12 +415,12 @@ OK
|
||||
<!-- legacy anchor -->
|
||||
</para>
|
||||
<para>
|
||||
Here's an example partition scheme for Legacy Boot, using
|
||||
Here’s an example partition scheme for Legacy Boot, using
|
||||
<literal>/dev/sda</literal> as the device.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
You can safely ignore <literal>parted</literal>'s
|
||||
You can safely ignore <literal>parted</literal>’s
|
||||
informational message about needing to update /etc/fstab.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
@ -128,7 +128,7 @@ nixos https://nixos.org/channels/nixos-unstable
|
||||
You can keep a NixOS system up-to-date automatically by adding the
|
||||
following to <literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
system.autoUpgrade.enable = true;
|
||||
system.autoUpgrade.allowReboot = true;
|
||||
</programlisting>
|
||||
@ -145,7 +145,7 @@ system.autoUpgrade.allowReboot = true;
|
||||
contains a different kernel, initrd or kernel modules. You can
|
||||
also specify a channel explicitly, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
system.autoUpgrade.channel = https://nixos.org/channels/nixos-22.11;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
@ -79,7 +79,7 @@
|
||||
the NixOS configuration. For instance, if a package
|
||||
<literal>foo</literal> provides systemd units, you can say:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.packages = [ pkgs.foo ];
|
||||
}
|
||||
@ -88,7 +88,7 @@
|
||||
to enable those units. You can then set or override unit options
|
||||
in the usual way, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.services.foo.wantedBy = [ "multi-user.target" ];
|
||||
systemd.services.foo.serviceConfig.MemoryLimit = "512M";
|
||||
@ -105,7 +105,7 @@
|
||||
NixOS configuration requires unfree packages from Nixpkgs, you
|
||||
need to enable support for them explicitly by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
nixpkgs.config.allowUnfree = true;
|
||||
}
|
||||
@ -123,7 +123,7 @@
|
||||
The Adobe Flash player is no longer enabled by default in the
|
||||
Firefox and Chromium wrappers. To enable it, you must set:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
nixpkgs.config.allowUnfree = true;
|
||||
nixpkgs.config.firefox.enableAdobeFlash = true; # for Firefox
|
||||
@ -136,7 +136,7 @@
|
||||
The firewall is now enabled by default. If you don’t want this,
|
||||
you need to disable it explicitly:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
networking.firewall.enable = false;
|
||||
}
|
||||
|
||||
@ -370,7 +370,7 @@
|
||||
documentation</link> for details. If you wish to continue to use
|
||||
httpd 2.2, add the following line to your NixOS configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.package = pkgs.apacheHttpd_2_2;
|
||||
}
|
||||
|
||||
@ -9,12 +9,12 @@
|
||||
<para>
|
||||
The <link xlink:href="http://haskell.org/">Haskell</link>
|
||||
packages infrastructure has been re-designed from the ground up
|
||||
("Haskell NG"). NixOS now distributes the latest
|
||||
(<quote>Haskell NG</quote>). NixOS now distributes the latest
|
||||
version of every single package registered on
|
||||
<link xlink:href="http://hackage.haskell.org/">Hackage</link> --
|
||||
well in excess of 8,000 Haskell packages. Detailed instructions
|
||||
on how to use that infrastructure can be found in the
|
||||
<link xlink:href="https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure">User's
|
||||
<link xlink:href="https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure">User’s
|
||||
Guide to the Haskell Infrastructure</link>. Users migrating from
|
||||
an earlier release may find helpful information below, in the
|
||||
list of backwards-incompatible changes. Furthermore, we
|
||||
@ -23,8 +23,8 @@
|
||||
Haskell</link> release since version 0.0 as well as the most
|
||||
recent <link xlink:href="http://www.stackage.org/">Stackage
|
||||
Nightly</link> snapshot. The announcement
|
||||
<link xlink:href="https://nixos.org/nix-dev/2015-September/018138.html">"Full
|
||||
Stackage Support in Nixpkgs"</link> gives additional
|
||||
<link xlink:href="https://nixos.org/nix-dev/2015-September/018138.html"><quote>Full
|
||||
Stackage Support in Nixpkgs</quote></link> gives additional
|
||||
details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -42,7 +42,7 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
system.autoUpgrade.enable = true;
|
||||
}
|
||||
@ -432,7 +432,7 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
system.stateVersion = "14.12";
|
||||
}
|
||||
@ -464,7 +464,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Steam now doesn't need root rights to work. Instead of using
|
||||
Steam now doesn’t need root rights to work. Instead of using
|
||||
<literal>*-steam-chrootenv</literal>, you should now just run
|
||||
<literal>steam</literal>. <literal>steamChrootEnv</literal>
|
||||
package was renamed to <literal>steam</literal>, and old
|
||||
@ -523,7 +523,7 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
fileSystems."/shiny" = {
|
||||
device = "myshinysharedfolder";
|
||||
@ -534,15 +534,15 @@
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>
|
||||
"<literal>nix-env -qa</literal>" no longer discovers
|
||||
Haskell packages by name. The only packages visible in the
|
||||
global scope are <literal>ghc</literal>,
|
||||
<quote><literal>nix-env -qa</literal></quote> no longer
|
||||
discovers Haskell packages by name. The only packages visible in
|
||||
the global scope are <literal>ghc</literal>,
|
||||
<literal>cabal-install</literal>, and <literal>stack</literal>,
|
||||
but all other packages are hidden. The reason for this
|
||||
inconvenience is the sheer size of the Haskell package set.
|
||||
Name-based lookups are expensive, and most
|
||||
<literal>nix-env -qa</literal> operations would become much
|
||||
slower if we'd add the entire Hackage database into the top
|
||||
slower if we’d add the entire Hackage database into the top
|
||||
level attribute set. Instead, the list of Haskell packages can
|
||||
be displayed by running:
|
||||
</para>
|
||||
@ -566,13 +566,13 @@ nix-env -f "<nixpkgs>" -iA haskellPackages.pandoc
|
||||
<para>
|
||||
Previous versions of NixOS came with a feature called
|
||||
<literal>ghc-wrapper</literal>, a small script that allowed GHC
|
||||
to transparently pick up on libraries installed in the user's
|
||||
to transparently pick up on libraries installed in the user’s
|
||||
profile. This feature has been deprecated;
|
||||
<literal>ghc-wrapper</literal> was removed from the
|
||||
distribution. The proper way to register Haskell libraries with
|
||||
the compiler now is the
|
||||
<literal>haskellPackages.ghcWithPackages</literal> function. The
|
||||
<link xlink:href="https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure">User's
|
||||
<link xlink:href="https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure">User’s
|
||||
Guide to the Haskell Infrastructure</link> provides more
|
||||
information about this subject.
|
||||
</para>
|
||||
@ -593,7 +593,7 @@ nix-env -f "<nixpkgs>" -iA haskellPackages.pandoc
|
||||
have a function attribute called <literal>extension</literal>
|
||||
that users could override in their
|
||||
<literal>~/.nixpkgs/config.nix</literal> files to configure
|
||||
additional attributes, etc. That function still exists, but it's
|
||||
additional attributes, etc. That function still exists, but it’s
|
||||
now called <literal>overrides</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -662,7 +662,7 @@ infinite recursion encountered
|
||||
<literal>lib</literal>, after adding it as argument of the
|
||||
module. The following module
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
with pkgs.lib;
|
||||
@ -677,7 +677,7 @@ with pkgs.lib;
|
||||
<para>
|
||||
should be modified to look like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, lib, ... }:
|
||||
|
||||
with lib;
|
||||
@ -695,7 +695,7 @@ with lib;
|
||||
replaced by <literal>(import <nixpkgs> {})</literal>. The
|
||||
following module
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
let
|
||||
@ -712,7 +712,7 @@ in
|
||||
<para>
|
||||
should be modified to look like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
let
|
||||
@ -748,7 +748,7 @@ in
|
||||
<literal>/etc/ssh/moduli</literal> file with respect to the
|
||||
<link xlink:href="https://stribika.github.io/2015/01/04/secure-secure-shell.html">vulnerabilities
|
||||
discovered in the Diffie-Hellman key exchange</link> can now
|
||||
replace OpenSSH's default version with one they generated
|
||||
replace OpenSSH’s default version with one they generated
|
||||
themselves using the new
|
||||
<literal>services.openssh.moduliFile</literal> option.
|
||||
</para>
|
||||
|
||||
@ -378,7 +378,7 @@
|
||||
You will need to add an import statement to your NixOS
|
||||
configuration in order to use it, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
imports = [ <nixpkgs/nixos/modules/services/misc/gitit.nix> ];
|
||||
}
|
||||
@ -395,7 +395,7 @@
|
||||
to be built in. All modules now reside in
|
||||
<literal>nginxModules</literal> set. Example configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nginx.override {
|
||||
modules = [ nginxModules.rtmp nginxModules.dav nginxModules.moreheaders ];
|
||||
}
|
||||
@ -403,7 +403,7 @@ nginx.override {
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>s3sync</literal> is removed, as it hasn't been
|
||||
<literal>s3sync</literal> is removed, as it hasn’t been
|
||||
developed by upstream for 4 years and only runs with ruby 1.8.
|
||||
For an actively-developer alternative look at
|
||||
<literal>tarsnap</literal> and others.
|
||||
@ -411,7 +411,7 @@ nginx.override {
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>ruby_1_8</literal> has been removed as it's not
|
||||
<literal>ruby_1_8</literal> has been removed as it’s not
|
||||
supported from upstream anymore and probably contains security
|
||||
issues.
|
||||
</para>
|
||||
@ -439,7 +439,7 @@ nginx.override {
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>Ctrl+Alt+Backspace</literal> key combination no
|
||||
longer kills the X server by default. There's a new option
|
||||
longer kills the X server by default. There’s a new option
|
||||
<literal>services.xserver.enableCtrlAltBackspace</literal>
|
||||
allowing to enable the combination again.
|
||||
</para>
|
||||
@ -457,7 +457,7 @@ nginx.override {
|
||||
<literal>/var/lib/postfix</literal>. Old configurations are
|
||||
migrated automatically. <literal>service.postfix</literal>
|
||||
module has also received many improvements, such as correct
|
||||
directories' access rights, new <literal>aliasFiles</literal>
|
||||
directories’ access rights, new <literal>aliasFiles</literal>
|
||||
and <literal>mapFiles</literal> options and more.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -468,7 +468,7 @@ nginx.override {
|
||||
continue to work, but print a warning, until the 16.09 release.
|
||||
An example of the new style:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
fileSystems."/example" = {
|
||||
device = "/dev/sdc";
|
||||
@ -497,7 +497,7 @@ nginx.override {
|
||||
<para>
|
||||
There are also Gutenprint improvements; in particular, a new
|
||||
option <literal>services.printing.gutenprint</literal> is added
|
||||
to enable automatic updating of Gutenprint PPMs; it's greatly
|
||||
to enable automatic updating of Gutenprint PPMs; it’s greatly
|
||||
recommended to enable it instead of adding
|
||||
<literal>gutenprint</literal> to the <literal>drivers</literal>
|
||||
list.
|
||||
@ -524,7 +524,7 @@ nginx.override {
|
||||
used input method name, <literal>"ibus"</literal> for
|
||||
ibus. An example of the new style:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
i18n.inputMethod.enabled = "ibus";
|
||||
i18n.inputMethod.ibus.engines = with pkgs.ibus-engines; [ anthy mozc ];
|
||||
@ -533,7 +533,7 @@ nginx.override {
|
||||
<para>
|
||||
That is equivalent to the old version:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
programs.ibus.enable = true;
|
||||
programs.ibus.plugins = with pkgs; [ ibus-anthy mozc ];
|
||||
@ -545,7 +545,7 @@ nginx.override {
|
||||
<literal>services.udev.extraRules</literal> option now writes
|
||||
rules to <literal>99-local.rules</literal> instead of
|
||||
<literal>10-local.rules</literal>. This makes all the user rules
|
||||
apply after others, so their results wouldn't be overridden by
|
||||
apply after others, so their results wouldn’t be overridden by
|
||||
anything else.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -587,7 +587,7 @@ $TTL 1800
|
||||
point to exact folder where syncthing is writing to. Example
|
||||
configuration should look something like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.syncthing = {
|
||||
enable = true;
|
||||
@ -632,8 +632,8 @@ error: path ‘/nix/store/*-broadcom-sta-*’ does not exist and cannot be creat
|
||||
The <literal>services.xserver.startGnuPGAgent</literal> option
|
||||
has been removed. GnuPG 2.1.x changed the way the gpg-agent
|
||||
works, and that new approach no longer requires (or even
|
||||
supports) the "start everything as a child of the
|
||||
agent" scheme we've implemented in NixOS for older
|
||||
supports) the <quote>start everything as a child of the
|
||||
agent</quote> scheme we’ve implemented in NixOS for older
|
||||
versions. To configure the gpg-agent for your X session, add the
|
||||
following code to <literal>~/.bashrc</literal> or some file
|
||||
that’s sourced when your shell is started:
|
||||
@ -670,7 +670,7 @@ export GPG_TTY
|
||||
</programlisting>
|
||||
<para>
|
||||
The <literal>gpg-agent(1)</literal> man page has more details
|
||||
about this subject, i.e. in the "EXAMPLES" section.
|
||||
about this subject, i.e. in the <quote>EXAMPLES</quote> section.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -78,7 +78,7 @@
|
||||
LTS Haskell package set. That support has been dropped. The
|
||||
previously provided <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 contain the versions
|
||||
but these package sets don’t actually contain the versions
|
||||
mandated by the corresponding LTS release. Instead, 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
|
||||
@ -119,7 +119,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Gitlab's maintainance script <literal>gitlab-runner</literal>
|
||||
Gitlab’s maintainance script <literal>gitlab-runner</literal>
|
||||
was removed and split up into the more clearer
|
||||
<literal>gitlab-run</literal> and <literal>gitlab-rake</literal>
|
||||
scripts, because <literal>gitlab-runner</literal> is a component
|
||||
@ -164,7 +164,7 @@
|
||||
<para>
|
||||
<literal>goPackages</literal> was replaced with separated Go
|
||||
applications in appropriate <literal>nixpkgs</literal>
|
||||
categories. Each Go package uses its own dependency set. There's
|
||||
categories. Each Go package uses its own dependency set. There’s
|
||||
also a new <literal>go2nix</literal> tool introduced to generate
|
||||
a Go package definition from its Go source automatically.
|
||||
</para>
|
||||
@ -192,7 +192,7 @@
|
||||
interface has been streamlined. Desktop users should be able to
|
||||
simply set
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
security.grsecurity.enable = true;
|
||||
}
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The default desktop environment now is KDE's Plasma 5. KDE 4
|
||||
The default desktop environment now is KDE’s Plasma 5. KDE 4
|
||||
has been removed
|
||||
</para>
|
||||
</listitem>
|
||||
@ -560,7 +560,7 @@
|
||||
Parsoid service now uses YAML configuration format.
|
||||
<literal>service.parsoid.interwikis</literal> is now called
|
||||
<literal>service.parsoid.wikis</literal> and is a list of
|
||||
either API URLs or attribute sets as specified in parsoid's
|
||||
either API URLs or attribute sets as specified in parsoid’s
|
||||
documentation.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -581,7 +581,7 @@
|
||||
<literal>service.nylon</literal> is now declared using named
|
||||
instances. As an example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.nylon = {
|
||||
enable = true;
|
||||
@ -594,7 +594,7 @@
|
||||
<para>
|
||||
should be replaced with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.nylon.myvpn = {
|
||||
enable = true;
|
||||
@ -615,7 +615,7 @@
|
||||
<link xlink:href="https://nixos.org/nixpkgs/manual/#sec-overlays-install">
|
||||
overlays</link>. For example, the following code:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
in
|
||||
@ -624,7 +624,7 @@ in
|
||||
<para>
|
||||
should be replaced by:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
in
|
||||
@ -647,7 +647,7 @@ in
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>local_recipient_maps</literal> is not set to empty
|
||||
value by Postfix service. It's an insecure default as stated
|
||||
value by Postfix service. It’s an insecure default as stated
|
||||
by Postfix documentation. Those who want to retain this
|
||||
setting need to set it via
|
||||
<literal>services.postfix.extraConfig</literal>.
|
||||
@ -669,7 +669,7 @@ in
|
||||
<listitem>
|
||||
<para>
|
||||
The socket handling of the <literal>services.rmilter</literal>
|
||||
module has been fixed and refactored. As rmilter doesn't
|
||||
module has been fixed and refactored. As rmilter doesn’t
|
||||
support binding to more than one socket, the options
|
||||
<literal>bindUnixSockets</literal> and
|
||||
<literal>bindInetSockets</literal> have been replaced by
|
||||
@ -729,7 +729,7 @@ in
|
||||
improves visual consistency and makes Java follow system font
|
||||
style, improving the situation on HighDPI displays. This has a
|
||||
cost of increased closure size; for server and other headless
|
||||
workloads it's recommended to use
|
||||
workloads it’s recommended to use
|
||||
<literal>jre_headless</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -26,10 +26,10 @@
|
||||
The module option
|
||||
<literal>services.xserver.xrandrHeads</literal> now causes the
|
||||
first head specified in this list to be set as the primary
|
||||
head. Apart from that, it's now possible to also set
|
||||
head. Apart from that, it’s now possible to also set
|
||||
additional options by using an attribute set, for example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ services.xserver.xrandrHeads = [
|
||||
"HDMI-0"
|
||||
{
|
||||
@ -543,7 +543,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Radicale's default package has changed from 1.x to 2.x.
|
||||
Radicale’s default package has changed from 1.x to 2.x.
|
||||
Instructions to migrate can be found
|
||||
<link xlink:href="http://radicale.org/1to2/"> here
|
||||
</link>. It is also possible to use the newer version by
|
||||
@ -582,7 +582,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>flexget</literal>'s state database cannot be upgraded
|
||||
<literal>flexget</literal>’s state database cannot be upgraded
|
||||
to its new internal format, requiring removal of any existing
|
||||
<literal>db-config.sqlite</literal> which will be
|
||||
automatically recreated.
|
||||
@ -590,9 +590,9 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>ipfs</literal> service now doesn't ignore the
|
||||
<literal>dataDir</literal> option anymore. If you've ever set
|
||||
this option to anything other than the default you'll have to
|
||||
The <literal>ipfs</literal> service now doesn’t ignore the
|
||||
<literal>dataDir</literal> option anymore. If you’ve ever set
|
||||
this option to anything other than the default you’ll have to
|
||||
either unset it (so the default gets used) or migrate the old
|
||||
data manually with
|
||||
</para>
|
||||
@ -651,16 +651,16 @@ rmdir /var/lib/ipfs/.ipfs
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>cc-wrapper</literal>'s setup-hook now exports a
|
||||
<literal>cc-wrapper</literal><quote>s setup-hook now exports a
|
||||
number of environment variables corresponding to binutils
|
||||
binaries, (e.g. <literal>LD</literal>,
|
||||
<literal>STRIP</literal>, <literal>RANLIB</literal>, etc).
|
||||
This is done to prevent packages' build systems guessing,
|
||||
which is harder to predict, especially when cross-compiling.
|
||||
However, some packages have broken due to this—their build
|
||||
systems either not supporting, or claiming to support without
|
||||
adequate testing, taking such environment variables as
|
||||
parameters.
|
||||
This is done to prevent packages</quote> build systems
|
||||
guessing, which is harder to predict, especially when
|
||||
cross-compiling. However, some packages have broken due to
|
||||
this—their build systems either not supporting, or claiming to
|
||||
support without adequate testing, taking such environment
|
||||
variables as parameters.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -688,10 +688,10 @@ rmdir /var/lib/ipfs/.ipfs
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
grsecurity/PaX support has been dropped, following upstream's
|
||||
grsecurity/PaX support has been dropped, following upstream’s
|
||||
decision to cease free support. See
|
||||
<link xlink:href="https://grsecurity.net/passing_the_baton.php">
|
||||
upstream's announcement</link> for more information. No
|
||||
upstream’s announcement</link> for more information. No
|
||||
complete replacement for grsecurity/PaX is available
|
||||
presently.
|
||||
</para>
|
||||
@ -794,7 +794,7 @@ FLUSH PRIVILEGES;
|
||||
<para>
|
||||
Modules can now be disabled by using
|
||||
<link xlink:href="https://nixos.org/nixpkgs/manual/#sec-replace-modules">
|
||||
disabledModules</link>, allowing another to take it's place.
|
||||
disabledModules</link>, 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.
|
||||
@ -808,7 +808,7 @@ FLUSH PRIVILEGES;
|
||||
provided by fontconfig-penultimate, replacing
|
||||
fontconfig-ultimate; the new defaults are less invasive and
|
||||
provide rendering that is more consistent with other systems
|
||||
and hopefully with each font designer's intent. Some
|
||||
and hopefully with each font designer’s intent. Some
|
||||
system-wide configuration has been removed from the Fontconfig
|
||||
NixOS module where user Fontconfig settings are available.
|
||||
</para>
|
||||
|
||||
@ -16,9 +16,9 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Platform support: x86_64-linux and x86_64-darwin since release
|
||||
time (the latter isn't NixOS, really). Binaries for
|
||||
time (the latter isn’t NixOS, really). Binaries for
|
||||
aarch64-linux are available, but no channel exists yet, as
|
||||
it's waiting for some test fixes, etc.
|
||||
it’s waiting for some test fixes, etc.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -495,11 +495,11 @@
|
||||
<para>
|
||||
The propagation logic has been changed. The new logic, along
|
||||
with new types of dependencies that go with, is thoroughly
|
||||
documented in the "Specifying dependencies" section
|
||||
of the "Standard Environment" chapter of the nixpkgs
|
||||
manual. The old logic isn't but is easy to describe:
|
||||
dependencies were propagated as the same type of dependency no
|
||||
matter what. In practice, that means that many
|
||||
documented in the <quote>Specifying dependencies</quote>
|
||||
section of the <quote>Standard Environment</quote> chapter of
|
||||
the nixpkgs manual. The old logic isn’t but is easy to
|
||||
describe: dependencies were propagated as the same type of
|
||||
dependency no matter what. In practice, that means that many
|
||||
<literal>propagatedNativeBuildInputs</literal> should instead
|
||||
be <literal>propagatedBuildInputs</literal>. Thankfully, that
|
||||
was and is the least used type of dependency. Also, it means
|
||||
@ -541,7 +541,7 @@
|
||||
Previously, if other options in the Postfix module like
|
||||
<literal>services.postfix.useSrs</literal> were set and the
|
||||
user set config options that were also set by such options,
|
||||
the resulting config wouldn't include all options that were
|
||||
the resulting config wouldn’t include all options that were
|
||||
needed. They are now merged correctly. If config options need
|
||||
to be overridden, <literal>lib.mkForce</literal> or
|
||||
<literal>lib.mkOverride</literal> can be used.
|
||||
@ -626,7 +626,7 @@
|
||||
if <literal>config.networking.domain</literal> is set,
|
||||
<literal>matomo.${config.networking.hostName}</literal> if
|
||||
it is not set. If you change your
|
||||
<literal>serverName</literal>, remember you'll need to
|
||||
<literal>serverName</literal>, remember you’ll need to
|
||||
update the <literal>trustedHosts[]</literal> array in
|
||||
<literal>/var/lib/matomo/config/config.ini.php</literal>
|
||||
as well.
|
||||
@ -793,7 +793,7 @@
|
||||
<para>
|
||||
<literal>services.btrfs.autoScrub</literal> has been added, to
|
||||
periodically check btrfs filesystems for data corruption. If
|
||||
there's a correct copy available, it will automatically repair
|
||||
there’s a correct copy available, it will automatically repair
|
||||
corrupted blocks.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -830,7 +830,7 @@
|
||||
<para>
|
||||
In order to have the previous default configuration add
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.xserver.displayManager.lightdm.greeters.gtk.indicators = [
|
||||
"~host" "~spacer"
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
<para>
|
||||
For example
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
programs.firejail = {
|
||||
enable = true;
|
||||
@ -523,8 +523,8 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>netcat</literal> package is now taken directly
|
||||
from OpenBSD's <literal>libressl</literal>, instead of relying
|
||||
on Debian's fork. The new version should be very close to the
|
||||
from OpenBSD’s <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 differences.
|
||||
Importantly, flags like -b, -q, -C, and -Z are no longer
|
||||
accepted by the nc command.
|
||||
@ -533,7 +533,7 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>services.docker-registry.extraConfig</literal>
|
||||
object doesn't contain environment variables anymore. Instead
|
||||
object doesn’t contain environment variables anymore. Instead
|
||||
it needs to provide an object structure that can be mapped
|
||||
onto the YAML configuration defined in
|
||||
<link xlink:href="https://github.com/docker/distribution/blob/v2.6.2/docs/configuration.md">the
|
||||
@ -543,7 +543,7 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>gnucash</literal> has changed from version 2.4 to
|
||||
3.x. If you've been using <literal>gnucash</literal> (version
|
||||
3.x. If you’ve been using <literal>gnucash</literal> (version
|
||||
2.4) instead of <literal>gnucash26</literal> (version 2.6) you
|
||||
must open your Gnucash data file(s) with
|
||||
<literal>gnucash26</literal> and then save them to upgrade the
|
||||
@ -695,7 +695,7 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
A NixOS system can now be constructed more easily based on a
|
||||
preexisting invocation of Nixpkgs. For example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
inherit (pkgs.nixos {
|
||||
boot.loader.grub.enable = false;
|
||||
@ -791,7 +791,7 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<para>
|
||||
An example usage of this would be:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, ... }:
|
||||
|
||||
{
|
||||
@ -874,7 +874,7 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
The <literal>programs.screen</literal> module provides allows
|
||||
to configure <literal>/etc/screenrc</literal>, however the
|
||||
module behaved fairly counterintuitive as the config exists,
|
||||
but the package wasn't available. Since 18.09
|
||||
but the package wasn’t available. Since 18.09
|
||||
<literal>pkgs.screen</literal> will be added to
|
||||
<literal>environment.systemPackages</literal>.
|
||||
</para>
|
||||
@ -920,7 +920,7 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<para>
|
||||
NixOS option descriptions are now automatically broken up into
|
||||
individual paragraphs if the text contains two consecutive
|
||||
newlines, so it's no longer necessary to use
|
||||
newlines, so it’s no longer necessary to use
|
||||
<literal></para><para></literal> to start a new
|
||||
paragraph.
|
||||
</para>
|
||||
|
||||
@ -29,9 +29,9 @@
|
||||
<para>
|
||||
By default,
|
||||
<literal>services.xserver.desktopManager.pantheon</literal>
|
||||
enables LightDM as a display manager, as pantheon's screen
|
||||
enables LightDM as a display manager, as pantheon’s screen
|
||||
locking implementation relies on it. Because of that it is
|
||||
recommended to leave LightDM enabled. If you'd like to
|
||||
recommended to leave LightDM enabled. If you’d like to
|
||||
disable it anyway, set
|
||||
<literal>services.xserver.displayManager.lightdm.enable</literal>
|
||||
to <literal>false</literal> and enable your preferred
|
||||
@ -39,8 +39,8 @@
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
Also note that Pantheon's LightDM greeter is not enabled by
|
||||
default, because it has numerous issues in NixOS and isn't
|
||||
Also note that Pantheon’s LightDM greeter is not enabled by
|
||||
default, because it has numerous issues in NixOS and isn’t
|
||||
optimal for use here yet.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -200,7 +200,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>ntp</literal> module now has sane default
|
||||
restrictions. If you're relying on the previous defaults,
|
||||
restrictions. If you’re relying on the previous defaults,
|
||||
which permitted all queries and commands from all
|
||||
firewall-permitted sources, you can set
|
||||
<literal>services.ntp.restrictDefault</literal> and
|
||||
@ -342,7 +342,7 @@
|
||||
preserved when also setting interface specific rules such as
|
||||
<literal>networking.firewall.interfaces.en0.allow*</literal>.
|
||||
These rules continue to use the pseudo device
|
||||
"default"
|
||||
<quote>default</quote>
|
||||
(<literal>networking.firewall.interfaces.default.*</literal>),
|
||||
and assigning to this pseudo device will override the
|
||||
(<literal>networking.firewall.allow*</literal>) options.
|
||||
@ -360,9 +360,9 @@
|
||||
presence of <literal>services.sssd.enable = true</literal>
|
||||
because nscd caching would interfere with
|
||||
<literal>sssd</literal> in unpredictable ways as well. Because
|
||||
we're using nscd not for caching, but for convincing glibc to
|
||||
we’re using nscd not for caching, but for convincing glibc to
|
||||
find NSS modules in the nix store instead of an absolute path,
|
||||
we have decided to disable caching globally now, as it's
|
||||
we have decided to disable caching globally now, as it’s
|
||||
usually not the behaviour the user wants and can lead to
|
||||
surprising behaviour. Furthermore, negative caching of host
|
||||
lookups is also disabled now by default. This should fix the
|
||||
@ -374,7 +374,7 @@
|
||||
setting the <literal>services.nscd.config</literal> option
|
||||
with the desired caching parameters.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.nscd.config =
|
||||
''
|
||||
@ -453,7 +453,7 @@
|
||||
with its control field set to <literal>sufficient</literal>
|
||||
instead of <literal>required</literal>, so that password
|
||||
managed only by later PAM password modules are being executed.
|
||||
Previously, for example, changing an LDAP account's password
|
||||
Previously, for example, changing an LDAP account’s password
|
||||
through PAM was not possible: the whole password module
|
||||
verification was exited prematurely by
|
||||
<literal>pam_unix</literal>, preventing
|
||||
@ -497,11 +497,11 @@
|
||||
<link xlink:href="https://matrix.org/blog/2019/02/05/synapse-0-99-0/">the
|
||||
last version to accept self-signed certificates</link>. As
|
||||
such, it is now recommended to use a proper certificate
|
||||
verified by a root CA (for example Let's Encrypt). The new
|
||||
verified by a root CA (for example Let’s Encrypt). The new
|
||||
<link linkend="module-services-matrix">manual chapter on
|
||||
Matrix</link> contains a working example of using nginx as a
|
||||
reverse proxy in front of <literal>matrix-synapse</literal>,
|
||||
using Let's Encrypt certificates.
|
||||
using Let’s Encrypt certificates.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -682,7 +682,7 @@
|
||||
<link xlink:href="options.html#opt-services.ndppd.enable">all
|
||||
config options</link> provided by the current upstream version
|
||||
as service options. Additionally the <literal>ndppd</literal>
|
||||
package doesn't contain the systemd unit configuration from
|
||||
package doesn’t contain the systemd unit configuration from
|
||||
upstream anymore, the unit is completely configured by the
|
||||
NixOS module now.
|
||||
</para>
|
||||
|
||||
@ -82,13 +82,13 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
We've updated to Xfce 4.14, which brings a new module
|
||||
We’ve updated to Xfce 4.14, which brings a new module
|
||||
<literal>services.xserver.desktopManager.xfce4-14</literal>.
|
||||
If you'd like to upgrade, please switch from the
|
||||
If you’d like to upgrade, please switch from the
|
||||
<literal>services.xserver.desktopManager.xfce</literal> module
|
||||
as it will be deprecated in a future release. They're
|
||||
incompatibilities with the current Xfce module; it doesn't
|
||||
support <literal>thunarPlugins</literal> and it isn't
|
||||
as it will be deprecated in a future release. They’re
|
||||
incompatibilities with the current Xfce module; it doesn’t
|
||||
support <literal>thunarPlugins</literal> and it isn’t
|
||||
recommended to use
|
||||
<literal>services.xserver.desktopManager.xfce</literal> and
|
||||
<literal>services.xserver.desktopManager.xfce4-14</literal>
|
||||
@ -125,7 +125,7 @@
|
||||
</itemizedlist>
|
||||
<para>
|
||||
With these options we hope to give users finer grained control
|
||||
over their systems. Prior to this change you'd either have to
|
||||
over their systems. Prior to this change you’d either have to
|
||||
manually disable options or use
|
||||
<literal>environment.gnome3.excludePackages</literal> which
|
||||
only excluded the optional applications.
|
||||
@ -138,7 +138,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Orthogonal to the previous changes to the GNOME 3 desktop
|
||||
manager module, we've updated all default services and
|
||||
manager module, we’ve updated all default services and
|
||||
applications to match as close as possible to a default
|
||||
reference GNOME 3 experience.
|
||||
</para>
|
||||
@ -295,7 +295,7 @@
|
||||
<literal>services.xserver.desktopManager.mate</literal>
|
||||
Note Mate uses
|
||||
<literal>programs.system-config-printer</literal> as it
|
||||
doesn't use it as a service, but its graphical interface
|
||||
doesn’t use it as a service, but its graphical interface
|
||||
directly.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -347,7 +347,7 @@
|
||||
<literal>services.prometheus.alertmanager.user</literal> and
|
||||
<literal>services.prometheus.alertmanager.group</literal> have
|
||||
been removed because the alertmanager service is now using
|
||||
systemd's
|
||||
systemd’s
|
||||
<link xlink:href="http://0pointer.net/blog/dynamic-users-with-systemd.html">
|
||||
DynamicUser mechanism</link> which obviates these options.
|
||||
</para>
|
||||
@ -366,7 +366,7 @@
|
||||
The <literal>services.nzbget.configFile</literal> and
|
||||
<literal>services.nzbget.openFirewall</literal> options were
|
||||
removed as they are managed internally by the nzbget. The
|
||||
<literal>services.nzbget.dataDir</literal> option hadn't
|
||||
<literal>services.nzbget.dataDir</literal> option hadn’t
|
||||
actually been used by the module for some time and so was
|
||||
removed as cleanup.
|
||||
</para>
|
||||
@ -475,7 +475,7 @@
|
||||
Make sure you set the <literal>_netdev</literal> option for
|
||||
each of the file systems referring to block devices provided
|
||||
by the autoLuks module. Not doing this might render the system
|
||||
in a state where it doesn't boot anymore.
|
||||
in a state where it doesn’t boot anymore.
|
||||
</para>
|
||||
<para>
|
||||
If you are actively using the <literal>autoLuks</literal>
|
||||
@ -667,7 +667,7 @@
|
||||
instead of depending on the catch-all
|
||||
<literal>acme-certificates.target</literal>. This target unit
|
||||
was also removed from the codebase. This will mean nginx will
|
||||
no longer depend on certificates it isn't explicitly managing
|
||||
no longer depend on certificates it isn’t explicitly managing
|
||||
and fixes a bug with certificate renewal ordering racing with
|
||||
nginx restarting which could lead to nginx getting in a broken
|
||||
state as described at
|
||||
@ -687,8 +687,8 @@
|
||||
<literal>services.xserver.desktopManager.xterm</literal> is
|
||||
now disabled by default if <literal>stateVersion</literal> is
|
||||
19.09 or higher. Previously the xterm desktopManager was
|
||||
enabled when xserver was enabled, but it isn't useful for all
|
||||
people so it didn't make sense to have any desktopManager
|
||||
enabled when xserver was enabled, but it isn’t useful for all
|
||||
people so it didn’t make sense to have any desktopManager
|
||||
enabled default.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -696,7 +696,7 @@
|
||||
<para>
|
||||
The WeeChat plugin
|
||||
<literal>pkgs.weechatScripts.weechat-xmpp</literal> has been
|
||||
removed as it doesn't receive any updates from upstream and
|
||||
removed as it doesn’t receive any updates from upstream and
|
||||
depends on outdated Python2-based modules.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -744,11 +744,11 @@
|
||||
<literal>services.gitlab.secrets.dbFile</literal>,
|
||||
<literal>services.gitlab.secrets.otpFile</literal> and
|
||||
<literal>services.gitlab.secrets.jwsFile</literal>). This was
|
||||
done so that secrets aren't stored in the world-readable nix
|
||||
store, but means that for each option you'll have to create a
|
||||
file with the same exact string, add "File" to the
|
||||
end of the option name, and change the definition to a string
|
||||
pointing to the corresponding file; e.g.
|
||||
done so that secrets aren’t stored in the world-readable nix
|
||||
store, but means that for each option you’ll have to create a
|
||||
file with the same exact string, add <quote>File</quote> to
|
||||
the end of the option name, and change the definition to a
|
||||
string pointing to the corresponding file; e.g.
|
||||
<literal>services.gitlab.databasePassword = "supersecurepassword"</literal>
|
||||
becomes
|
||||
<literal>services.gitlab.databasePasswordFile = "/path/to/secret_file"</literal>
|
||||
@ -791,7 +791,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>nodejs-11_x</literal> package has been removed as
|
||||
it's EOLed by upstream.
|
||||
it’s EOLed by upstream.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -961,7 +961,7 @@
|
||||
from the upstream default <literal>speex-float-1</literal> to
|
||||
<literal>speex-float-5</literal>. Be aware that low-powered
|
||||
ARM-based and MIPS-based boards will struggle with this so
|
||||
you'll need to set
|
||||
you’ll need to set
|
||||
<literal>hardware.pulseaudio.daemon.config.resample-method</literal>
|
||||
back to <literal>speex-float-1</literal>.
|
||||
</para>
|
||||
@ -1004,7 +1004,7 @@
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It's now possible to change configuration in
|
||||
It’s now possible to change configuration in
|
||||
<link xlink:href="options.html#opt-services.nextcloud.enable">services.nextcloud</link>
|
||||
after the initial deploy since all config parameters are
|
||||
persisted in an additional config file generated by the
|
||||
@ -1178,7 +1178,7 @@
|
||||
<link xlink:href="https://ceph.com/releases/v14-2-0-nautilus-released/">release
|
||||
notes</link> for details. The mgr dashboard as well as osds
|
||||
backed by loop-devices is no longer explicitly supported by
|
||||
the package and module. Note: There's been some issues with
|
||||
the package and module. Note: There’s been some issues with
|
||||
python-cherrypy, which is used by the dashboard and prometheus
|
||||
mgr modules (and possibly others), hence
|
||||
0000-dont-check-cherrypy-version.patch.
|
||||
|
||||
@ -73,7 +73,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
The graphical installer image starts the graphical session
|
||||
automatically. Before you'd be greeted by a tty and asked to
|
||||
automatically. Before you’d be greeted by a tty and asked to
|
||||
enter <literal>systemctl start display-manager</literal>. It
|
||||
is now possible to disable the display-manager from running by
|
||||
selecting the <literal>Disable display-manager</literal> quirk
|
||||
@ -93,7 +93,7 @@
|
||||
<link xlink:href="options.html#opt-services.xserver.desktopManager.pantheon.enable">services.xserver.desktopManager.pantheon.enable</link>,
|
||||
we now default to also use
|
||||
<link xlink:href="https://blog.elementary.io/say-hello-to-the-new-greeter/">
|
||||
Pantheon's newly designed greeter </link>. Contrary to NixOS's
|
||||
Pantheon’s newly designed greeter </link>. Contrary to NixOS’s
|
||||
usual update policy, Pantheon will receive updates during the
|
||||
cycle of NixOS 20.03 when backwards compatible.
|
||||
</para>
|
||||
@ -133,7 +133,7 @@
|
||||
option to improve support for upstream session files. If you
|
||||
used something like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.xserver.desktopManager.default = "xfce";
|
||||
services.xserver.windowManager.default = "icewm";
|
||||
@ -142,7 +142,7 @@
|
||||
<para>
|
||||
you should change it to:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.xserver.displayManager.defaultSession = "xfce+icewm";
|
||||
}
|
||||
@ -196,7 +196,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
UPower's configuration is now managed by NixOS and can be
|
||||
UPower’s configuration is now managed by NixOS and can be
|
||||
customized via <literal>services.upower</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -505,7 +505,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/71106">#71106</link>.
|
||||
</para>
|
||||
<para>
|
||||
We already don't support the global
|
||||
We already don’t support the global
|
||||
<link xlink:href="options.html#opt-networking.useDHCP">networking.useDHCP</link>,
|
||||
<link xlink:href="options.html#opt-networking.defaultGateway">networking.defaultGateway</link>
|
||||
and
|
||||
@ -522,7 +522,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
The stdenv now runs all bash with <literal>set -u</literal>,
|
||||
to catch the use of undefined variables. Before, it itself
|
||||
used <literal>set -u</literal> but was careful to unset it so
|
||||
other packages' code ran as before. Now, all bash code is held
|
||||
other packages’ code ran as before. Now, all bash code is held
|
||||
to the same high standard, and the rather complex stateful
|
||||
manipulation of the options can be discarded.
|
||||
</para>
|
||||
@ -558,7 +558,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
<literal>xfceUnstable</literal> all now point to the latest
|
||||
Xfce 4.14 packages. And in the future NixOS releases will be
|
||||
the latest released version of Xfce available at the time of
|
||||
the release's development (if viable).
|
||||
the release’s development (if viable).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -662,7 +662,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>dump1090</literal> derivation has been changed to
|
||||
use FlightAware's dump1090 as its upstream. However, this
|
||||
use FlightAware’s dump1090 as its upstream. However, this
|
||||
version does not have an internal webserver anymore. The
|
||||
assets in the <literal>share/dump1090</literal> directory of
|
||||
the derivation can be used in conjunction with an external
|
||||
@ -821,7 +821,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
is a <literal>loaOf</literal> option that is commonly used as
|
||||
follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
users.users =
|
||||
[ { name = "me";
|
||||
@ -836,7 +836,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
value of <literal>name</literal> as the name of the attribute
|
||||
set:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
users.users.me =
|
||||
{ description = "My personal user.";
|
||||
@ -890,7 +890,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
<listitem>
|
||||
<para>
|
||||
The<literal>services.buildkite-agent.openssh.publicKeyPath</literal>
|
||||
option has been removed, as it's not necessary to deploy
|
||||
option has been removed, as it’s not necessary to deploy
|
||||
public keys to clone private repositories.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -932,7 +932,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
The <literal>services.xserver.displayManager.auto</literal>
|
||||
module has been removed. It was only intended for use in
|
||||
internal NixOS tests, and gave the false impression of it
|
||||
being a special display manager when it's actually LightDM.
|
||||
being a special display manager when it’s actually LightDM.
|
||||
Please use the
|
||||
<literal>services.xserver.displayManager.lightdm.autoLogin</literal>
|
||||
options instead, or any other display manager in NixOS as they
|
||||
@ -940,7 +940,7 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
because it permitted root auto-login you can override the
|
||||
lightdm-autologin pam module like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
security.pam.services.lightdm-autologin.text = lib.mkForce ''
|
||||
auth requisite pam_nologin.so
|
||||
@ -962,13 +962,13 @@ See https://github.com/NixOS/nixpkgs/pull/71684 for details.
|
||||
auth required pam_succeed_if.so quiet
|
||||
</programlisting>
|
||||
<para>
|
||||
line, where default it's:
|
||||
line, where default it’s:
|
||||
</para>
|
||||
<programlisting>
|
||||
auth required pam_succeed_if.so uid >= 1000 quiet
|
||||
</programlisting>
|
||||
<para>
|
||||
not permitting users with uid's below 1000 (like root). All
|
||||
not permitting users with uid’s below 1000 (like root). All
|
||||
other display managers in NixOS are configured like this.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1004,7 +1004,7 @@ auth required pam_succeed_if.so quiet
|
||||
Additionally, some Postfix configuration must now be set
|
||||
manually instead of automatically by the Mailman module:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.postfix.relayDomains = [ "hash:/var/lib/mailman/data/postfix_domains" ];
|
||||
services.postfix.config.transport_maps = [ "hash:/var/lib/mailman/data/postfix_lmtp" ];
|
||||
@ -1051,14 +1051,14 @@ auth required pam_succeed_if.so quiet
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>*psu</literal> versions of oraclejdk8 have been
|
||||
removed as they aren't provided by upstream anymore.
|
||||
removed as they aren’t provided by upstream anymore.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>services.dnscrypt-proxy</literal> module has been
|
||||
removed as it used the deprecated version of dnscrypt-proxy.
|
||||
We've added
|
||||
We’ve added
|
||||
<link xlink:href="options.html#opt-services.dnscrypt-proxy2.enable">services.dnscrypt-proxy2.enable</link>
|
||||
to use the supported version. This module supports
|
||||
configuration via the Nix attribute set
|
||||
@ -1066,7 +1066,7 @@ auth required pam_succeed_if.so quiet
|
||||
or by passing a TOML configuration file via
|
||||
<link xlink:href="options.html#opt-services.dnscrypt-proxy2.configFile">services.dnscrypt-proxy2.configFile</link>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
# Example configuration:
|
||||
services.dnscrypt-proxy2.enable = true;
|
||||
@ -1093,7 +1093,7 @@ auth required pam_succeed_if.so quiet
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
sqldeveloper_18 has been removed as it's not maintained
|
||||
sqldeveloper_18 has been removed as it’s not maintained
|
||||
anymore, sqldeveloper has been updated to version
|
||||
<literal>19.4</literal>. Please note that this means that this
|
||||
means that the oraclejdk is now required. For further
|
||||
@ -1110,7 +1110,7 @@ auth required pam_succeed_if.so quiet
|
||||
the different lists of dependencies mashed together as one big
|
||||
list, and then partitioning into Haskell and non-Hakell
|
||||
dependencies, they work from the original many different
|
||||
dependency parameters and don't need to algorithmically
|
||||
dependency parameters and don’t need to algorithmically
|
||||
partition anything.
|
||||
</para>
|
||||
<para>
|
||||
@ -1123,7 +1123,7 @@ auth required pam_succeed_if.so quiet
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The gcc-snapshot-package has been removed. It's marked as
|
||||
The gcc-snapshot-package has been removed. It’s marked as
|
||||
broken for >2 years and used to point to a fairly old
|
||||
snapshot from the gcc7-branch.
|
||||
</para>
|
||||
@ -1158,7 +1158,7 @@ auth required pam_succeed_if.so quiet
|
||||
<listitem>
|
||||
<para>
|
||||
nextcloud has been updated to <literal>v18.0.2</literal>. This
|
||||
means that users from NixOS 19.09 can't upgrade directly since
|
||||
means that users from NixOS 19.09 can’t upgrade directly since
|
||||
you can only move one version forward and 19.09 uses
|
||||
<literal>v16.0.8</literal>.
|
||||
</para>
|
||||
@ -1181,7 +1181,7 @@ auth required pam_succeed_if.so quiet
|
||||
Existing setups will be detected using
|
||||
<link xlink:href="options.html#opt-system.stateVersion">system.stateVersion</link>:
|
||||
by default, nextcloud17 will be used, but will raise a
|
||||
warning which notes that after that deploy it's
|
||||
warning which notes that after that deploy it’s
|
||||
recommended to update to the latest stable version
|
||||
(nextcloud18) by declaring the newly introduced setting
|
||||
<link xlink:href="options.html#opt-services.nextcloud.package">services.nextcloud.package</link>.
|
||||
@ -1194,7 +1194,7 @@ auth required pam_succeed_if.so quiet
|
||||
get an evaluation error by default. This is done to ensure
|
||||
that our
|
||||
<link xlink:href="options.html#opt-services.nextcloud.package">package</link>-option
|
||||
doesn't select an older version by accident. It's
|
||||
doesn’t select an older version by accident. It’s
|
||||
recommended to use pkgs.nextcloud18 or to set
|
||||
<link xlink:href="options.html#opt-services.nextcloud.package">package</link>
|
||||
to pkgs.nextcloud explicitly.
|
||||
@ -1203,7 +1203,7 @@ auth required pam_succeed_if.so quiet
|
||||
</itemizedlist>
|
||||
<warning>
|
||||
<para>
|
||||
Please note that if you're coming from
|
||||
Please note that if you’re coming from
|
||||
<literal>19.03</literal> or older, you have to manually
|
||||
upgrade to <literal>19.09</literal> first to upgrade your
|
||||
server to Nextcloud v16.
|
||||
@ -1215,7 +1215,7 @@ auth required pam_succeed_if.so quiet
|
||||
Hydra has gained a massive performance improvement due to
|
||||
<link xlink:href="https://github.com/NixOS/hydra/pull/710">some
|
||||
database schema changes</link> by adding several IDs and
|
||||
better indexing. However, it's necessary to upgrade Hydra in
|
||||
better indexing. However, it’s necessary to upgrade Hydra in
|
||||
multiple steps:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
@ -1229,7 +1229,7 @@ auth required pam_succeed_if.so quiet
|
||||
when upgrading. Otherwise, the package can be deployed
|
||||
using the following config:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ pkgs, ... }: {
|
||||
services.hydra.package = pkgs.hydra-migration;
|
||||
}
|
||||
@ -1266,12 +1266,12 @@ $ hydra-backfill-ids
|
||||
<link xlink:href="options.html#opt-system.stateVersion">stateVersion</link>
|
||||
is set to <literal>20.03</literal> or greater,
|
||||
hydra-unstable will be used automatically! This will break
|
||||
your setup if you didn't run the migration.
|
||||
your setup if you didn’t run the migration.
|
||||
</para>
|
||||
</warning>
|
||||
<para>
|
||||
Please note that Hydra is currently not available with
|
||||
nixStable as this doesn't compile anymore.
|
||||
nixStable as this doesn’t compile anymore.
|
||||
</para>
|
||||
<warning>
|
||||
<para>
|
||||
@ -1281,7 +1281,7 @@ $ hydra-backfill-ids
|
||||
assertion error will be thrown. To circumvent this, you need
|
||||
to set
|
||||
<link xlink:href="options.html#opt-services.hydra.package">services.hydra.package</link>
|
||||
to pkgs.hydra explicitly and make sure you know what you're
|
||||
to pkgs.hydra explicitly and make sure you know what you’re
|
||||
doing!
|
||||
</para>
|
||||
</warning>
|
||||
@ -1319,7 +1319,7 @@ $ hydra-backfill-ids
|
||||
<para>
|
||||
To continue to use the old approach, you can configure:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.nginx.appendConfig = let cfg = config.services.nginx; in ''user ${cfg.user} ${cfg.group};'';
|
||||
systemd.services.nginx.serviceConfig.User = lib.mkForce "root";
|
||||
@ -1413,14 +1413,14 @@ $ hydra-backfill-ids
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you use <literal>sqlite3</literal> you don't need to do
|
||||
If you use <literal>sqlite3</literal> you don’t need to do
|
||||
anything.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you use <literal>postgresql</literal> on a different
|
||||
server, you don't need to change anything as well since
|
||||
server, you don’t need to change anything as well since
|
||||
this module was never designed to configure remote
|
||||
databases.
|
||||
</para>
|
||||
@ -1432,7 +1432,7 @@ $ hydra-backfill-ids
|
||||
older, you simply need to enable postgresql-support
|
||||
explicitly:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ ... }: {
|
||||
services.matrix-synapse = {
|
||||
enable = true;
|
||||
@ -1460,7 +1460,7 @@ $ hydra-backfill-ids
|
||||
<literal>nixos-unstable</literal> <emphasis>after</emphasis>
|
||||
the <literal>19.09</literal>-release, your database is
|
||||
misconfigured due to a regression in NixOS. For now,
|
||||
matrix-synapse will startup with a warning, but it's
|
||||
matrix-synapse will startup with a warning, but it’s
|
||||
recommended to reconfigure the database to set the values
|
||||
<literal>LC_COLLATE</literal> and <literal>LC_CTYPE</literal>
|
||||
to
|
||||
@ -1473,7 +1473,7 @@ $ hydra-backfill-ids
|
||||
<link xlink:href="options.html#opt-systemd.network.links">systemd.network.links</link>
|
||||
option is now respected even when
|
||||
<link xlink:href="options.html#opt-systemd.network.enable">systemd-networkd</link>
|
||||
is disabled. This mirrors the behaviour of systemd - It's udev
|
||||
is disabled. This mirrors the behaviour of systemd - It’s udev
|
||||
that parses <literal>.link</literal> files, not
|
||||
<literal>systemd-networkd</literal>.
|
||||
</para>
|
||||
@ -1486,8 +1486,8 @@ $ hydra-backfill-ids
|
||||
<para>
|
||||
Please note that mongodb has been relicensed under their own
|
||||
<link xlink:href="https://www.mongodb.com/licensing/server-side-public-license/faq"><literal> sspl</literal></link>-license.
|
||||
Since it's not entirely free and not OSI-approved, it's
|
||||
listed as non-free. This means that Hydra doesn't provide
|
||||
Since it’s not entirely free and not OSI-approved, it’s
|
||||
listed as non-free. This means that Hydra doesn’t provide
|
||||
prebuilt mongodb-packages and needs to be built locally.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
@ -722,7 +722,7 @@
|
||||
See
|
||||
<link xlink:href="https://mariadb.com/kb/en/authentication-from-mariadb-104/">Authentication
|
||||
from MariaDB 10.4</link>. unix_socket auth plugin does not use
|
||||
a password, and uses the connecting user's UID instead. When a
|
||||
a password, and uses the connecting user’s UID instead. When a
|
||||
new MariaDB data directory is initialized, two MariaDB users
|
||||
are created and can be used with new unix_socket auth plugin,
|
||||
as well as traditional mysql_native_password plugin:
|
||||
@ -730,7 +730,7 @@
|
||||
traditional mysql_native_password plugin method, one must run
|
||||
the following:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.mysql.initialScript = pkgs.writeText "mariadb-init.sql" ''
|
||||
ALTER USER root@localhost IDENTIFIED VIA mysql_native_password USING PASSWORD("verysecret");
|
||||
@ -755,7 +755,7 @@ services.mysql.initialScript = pkgs.writeText "mariadb-init.sql" ''
|
||||
allow MySQL to read from /home and /tmp directories when using
|
||||
<literal>LOAD DATA INFILE</literal>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.services.mysql.serviceConfig.ProtectHome = lib.mkForce "read-only";
|
||||
}
|
||||
@ -766,7 +766,7 @@ services.mysql.initialScript = pkgs.writeText "mariadb-init.sql" ''
|
||||
<literal>SELECT * INTO OUTFILE</literal>, assuming the mysql
|
||||
user has write access to <literal>/var/data</literal>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.services.mysql.serviceConfig.ReadWritePaths = [ "/var/data" ];
|
||||
}
|
||||
@ -864,7 +864,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
<para>
|
||||
<literal>buildGoModule</literal> now internally creates a
|
||||
vendor directory in the source tree for downloaded modules
|
||||
instead of using go's
|
||||
instead of using go’s
|
||||
<link xlink:href="https://golang.org/cmd/go/#hdr-Module_proxy_protocol">module
|
||||
proxy protocol</link>. This storage format is simpler and
|
||||
therefore less likely to break with future versions of go. As
|
||||
@ -885,7 +885,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
<literal>phantomJsSupport = true</literal> to the package
|
||||
instantiation:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.grafana.package = pkgs.grafana.overrideAttrs (oldAttrs: rec {
|
||||
phantomJsSupport = true;
|
||||
@ -941,24 +941,24 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
<para>
|
||||
If you used the
|
||||
<literal>boot.initrd.network.ssh.host*Key</literal> options,
|
||||
you'll get an error explaining how to convert your host keys
|
||||
you’ll get an error explaining how to convert your host keys
|
||||
and migrate to the new
|
||||
<literal>boot.initrd.network.ssh.hostKeys</literal> option.
|
||||
Otherwise, if you don't have any host keys set, you'll need to
|
||||
Otherwise, if you don’t have any host keys set, you’ll need to
|
||||
generate some; see the <literal>hostKeys</literal> option
|
||||
documentation for instructions.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Since this release there's an easy way to customize your PHP
|
||||
Since this release there’s an easy way to customize your PHP
|
||||
install to get a much smaller base PHP with only wanted
|
||||
extensions enabled. See the following snippet installing a
|
||||
smaller PHP with the extensions <literal>imagick</literal>,
|
||||
<literal>opcache</literal>, <literal>pdo</literal> and
|
||||
<literal>pdo_mysql</literal> loaded:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
environment.systemPackages = [
|
||||
(pkgs.php.withExtensions
|
||||
@ -973,7 +973,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
The default <literal>php</literal> attribute hasn't lost any
|
||||
The default <literal>php</literal> attribute hasn’t lost any
|
||||
extensions. The <literal>opcache</literal> extension has been
|
||||
added. All upstream PHP extensions are available under
|
||||
php.extensions.<name?>.
|
||||
@ -997,7 +997,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
The remaining configuration flags can now be set directly on
|
||||
the <literal>php</literal> attribute. For example, instead of
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
php.override {
|
||||
config.php.embed = true;
|
||||
@ -1008,7 +1008,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
<para>
|
||||
you should now write
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
php.override {
|
||||
embedSupport = true;
|
||||
@ -1062,7 +1062,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
writing to other folders, use
|
||||
<literal>systemd.services.nginx.serviceConfig.ReadWritePaths</literal>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.services.nginx.serviceConfig.ReadWritePaths = [ "/var/www" ];
|
||||
}
|
||||
@ -1076,7 +1076,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
docs</link> for details). If you require serving files from
|
||||
home directories, you may choose to set e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.services.nginx.serviceConfig.ProtectHome = "read-only";
|
||||
}
|
||||
@ -1093,7 +1093,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
<para>
|
||||
Replace a <literal>nesting.clone</literal> entry with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
specialisation.example-sub-configuration = {
|
||||
configuration = {
|
||||
@ -1104,7 +1104,7 @@ WHERE table_schema = "zabbix" AND COLLATION_NAME = "utf8_general_
|
||||
<para>
|
||||
Replace a <literal>nesting.children</literal> entry with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
specialisation.example-sub-configuration = {
|
||||
inheritParentConfig = false;
|
||||
@ -1162,7 +1162,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
<para>
|
||||
The <literal>systemd-networkd</literal> option
|
||||
<literal>systemd.network.networks.<name>.dhcp.CriticalConnection</literal>
|
||||
has been removed following upstream systemd's deprecation of
|
||||
has been removed following upstream systemd’s deprecation of
|
||||
the same. It is recommended to use
|
||||
<literal>systemd.network.networks.<name>.networkConfig.KeepConfiguration</literal>
|
||||
instead. See systemd.network 5 for details.
|
||||
@ -1174,7 +1174,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
<literal>systemd.network.networks._name_.dhcpConfig</literal>
|
||||
has been renamed to
|
||||
<link xlink:href="options.html#opt-systemd.network.networks._name_.dhcpV4Config">systemd.network.networks.<emphasis>name</emphasis>.dhcpV4Config</link>
|
||||
following upstream systemd's documentation change. See
|
||||
following upstream systemd’s documentation change. See
|
||||
systemd.network 5 for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1283,7 +1283,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
The
|
||||
<link xlink:href="https://github.com/okTurtles/dnschain">DNSChain</link>
|
||||
package and NixOS module have been removed from Nixpkgs as the
|
||||
software is unmaintained and can't be built. For more
|
||||
software is unmaintained and can’t be built. For more
|
||||
information see issue
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/issues/89205">#89205</link>.
|
||||
</para>
|
||||
@ -1350,7 +1350,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Radicale's default package has changed from 2.x to 3.x. An
|
||||
Radicale’s default package has changed from 2.x to 3.x. An
|
||||
upgrade checklist can be found
|
||||
<link xlink:href="https://github.com/Kozea/Radicale/blob/3.0.x/NEWS.md#upgrade-checklist">here</link>.
|
||||
You can use the newer version in the NixOS service by setting
|
||||
@ -1385,7 +1385,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
multi-instance config with an existing bitcoind data directory
|
||||
and user, you have to adjust the original config, e.g.:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.bitcoind = {
|
||||
enable = true;
|
||||
@ -1397,7 +1397,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
<para>
|
||||
To something similar:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.bitcoind.mainnet = {
|
||||
enable = true;
|
||||
@ -1447,7 +1447,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
the original SSL settings, you have to adjust the original
|
||||
config, e.g.:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.dokuwiki = {
|
||||
enable = true;
|
||||
@ -1458,7 +1458,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
<para>
|
||||
To something similar:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.dokuwiki."mywiki" = {
|
||||
enable = true;
|
||||
@ -1472,8 +1472,8 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
</programlisting>
|
||||
<para>
|
||||
The base package has also been upgraded to the 2020-07-29
|
||||
"Hogfather" release. Plugins might be incompatible
|
||||
or require upgrading.
|
||||
<quote>Hogfather</quote> release. Plugins might be
|
||||
incompatible or require upgrading.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -1492,7 +1492,7 @@ $ sudo /run/current-system/fine-tune/child-1/bin/switch-to-configuration test
|
||||
option is (<literal>/var/db/postgresql</literal>) and then
|
||||
explicitly set this value to maintain compatibility:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.postgresql.dataDir = "/var/db/postgresql";
|
||||
}
|
||||
@ -1587,7 +1587,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>security.rngd</literal> service is now disabled
|
||||
by default. This choice was made because there's krngd in the
|
||||
by default. This choice was made because there’s krngd in the
|
||||
linux kernel space making it (for most usecases) functionally
|
||||
redundent.
|
||||
</para>
|
||||
@ -1609,13 +1609,13 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
will be EOL (end of life) within the lifetime of 20.09</link>.
|
||||
</para>
|
||||
<para>
|
||||
It's necessary to upgrade to nextcloud19:
|
||||
It’s necessary to upgrade to nextcloud19:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
From nextcloud17, you have to upgrade to nextcloud18 first
|
||||
as Nextcloud doesn't allow going multiple major revisions
|
||||
as Nextcloud doesn’t allow going multiple major revisions
|
||||
forward in a single upgrade. This is possible by setting
|
||||
<link xlink:href="options.html#opt-services.nextcloud.package">services.nextcloud.package</link>
|
||||
to nextcloud18.
|
||||
@ -1623,7 +1623,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
From nextcloud18, it's possible to directly upgrade to
|
||||
From nextcloud18, it’s possible to directly upgrade to
|
||||
nextcloud19 by setting
|
||||
<link xlink:href="options.html#opt-services.nextcloud.package">services.nextcloud.package</link>
|
||||
to nextcloud19.
|
||||
@ -1685,7 +1685,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
<listitem>
|
||||
<para>
|
||||
The notmuch package moves its emacs-related binaries and emacs
|
||||
lisp files to a separate output. They're not part of the
|
||||
lisp files to a separate output. They’re not part of the
|
||||
default <literal>out</literal> output anymore - if you relied
|
||||
on the <literal>notmuch-emacs-mua</literal> binary or the
|
||||
emacs lisp files, access them via the
|
||||
@ -1736,11 +1736,11 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The cc- and binutils-wrapper's "infix salt" and
|
||||
The cc- and binutils-wrapper’s <quote>infix salt</quote> and
|
||||
<literal>_BUILD_</literal> and <literal>_TARGET_</literal>
|
||||
user infixes have been replaced with with a "suffix
|
||||
salt" and suffixes and <literal>_FOR_BUILD</literal> and
|
||||
<literal>_FOR_TARGET</literal>. This matches the autotools
|
||||
user infixes have been replaced with with a <quote>suffix
|
||||
salt</quote> and suffixes and <literal>_FOR_BUILD</literal>
|
||||
and <literal>_FOR_TARGET</literal>. This matches the autotools
|
||||
convention for env vars which standard for these things,
|
||||
making interfacing with other tools easier.
|
||||
</para>
|
||||
@ -1774,8 +1774,8 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
<literal>network-link-*</literal> units, which have been
|
||||
removed. Bringing the interface up has been moved to the
|
||||
beginning of the <literal>network-addresses-*</literal> unit.
|
||||
Note this doesn't require <literal>systemd-networkd</literal>
|
||||
- it's udev that parses <literal>.link</literal> files. Extra
|
||||
Note this doesn’t require <literal>systemd-networkd</literal>
|
||||
- it’s udev that parses <literal>.link</literal> files. Extra
|
||||
care needs to be taken in the presence of
|
||||
<link xlink:href="https://wiki.debian.org/NetworkInterfaceNames#THE_.22PERSISTENT_NAMES.22_SCHEME">legacy
|
||||
udev rules</link> to rename interfaces, as MAC Address and MTU
|
||||
@ -1825,7 +1825,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
you must include those directories into the
|
||||
<literal>BindPaths</literal> of the service:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
systemd.services.transmission.serviceConfig.BindPaths = [ "/path/to/alternative/download-dir" ];
|
||||
}
|
||||
@ -1835,7 +1835,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
<literal>transmission-daemon</literal> is now only available
|
||||
on the local network interface by default. Use:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.transmission.settings.rpc-bind-address = "0.0.0.0";
|
||||
}
|
||||
@ -1850,7 +1850,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
With this release <literal>systemd-networkd</literal> (when
|
||||
enabled through
|
||||
<link xlink:href="options.html#opt-networking.useNetworkd">networking.useNetworkd</link>)
|
||||
has it's netlink socket created through a
|
||||
has it’s netlink socket created through a
|
||||
<literal>systemd.socket</literal> unit. This gives us control
|
||||
over socket buffer sizes and other parameters. For larger
|
||||
setups where networkd has to create a lot of (virtual) devices
|
||||
@ -1873,7 +1873,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
</para>
|
||||
<para>
|
||||
Since the actual memory requirements depend on hardware,
|
||||
timing, exact configurations etc. it isn't currently possible
|
||||
timing, exact configurations etc. it isn’t currently possible
|
||||
to infer a good default from within the NixOS module system.
|
||||
Administrators are advised to monitor the logs of
|
||||
<literal>systemd-networkd</literal> for
|
||||
@ -1882,7 +1882,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
</para>
|
||||
<para>
|
||||
Note: Increasing the <literal>ReceiveBufferSize=</literal>
|
||||
doesn't allocate any memory. It just increases the upper bound
|
||||
doesn’t allocate any memory. It just increases the upper bound
|
||||
on the kernel side. The memory allocation depends on the
|
||||
amount of messages that are queued on the kernel side of the
|
||||
netlink socket.
|
||||
@ -1900,7 +1900,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
<para>
|
||||
This means that a configuration like this
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.dovecot2.mailboxes = [
|
||||
{ name = "Junk";
|
||||
@ -1912,7 +1912,7 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
<para>
|
||||
should now look like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.dovecot2.mailboxes = {
|
||||
Junk.auto = "create";
|
||||
@ -1934,8 +1934,8 @@ CREATE ROLE postgres LOGIN SUPERUSER;
|
||||
</para>
|
||||
<para>
|
||||
If you have an existing installation, please make sure that
|
||||
you're on nextcloud18 before upgrading to nextcloud19 since
|
||||
Nextcloud doesn't support upgrades across multiple major
|
||||
you’re on nextcloud18 before upgrading to nextcloud19 since
|
||||
Nextcloud doesn’t support upgrades across multiple major
|
||||
versions.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -235,9 +235,9 @@
|
||||
<para>
|
||||
The <literal>networking.wireless.iwd</literal> module now
|
||||
installs the upstream-provided 80-iwd.link file, which sets
|
||||
the NamePolicy= for all wlan devices to "keep
|
||||
kernel", to avoid race conditions between iwd and
|
||||
networkd. If you don't want this, you can set
|
||||
the NamePolicy= for all wlan devices to <quote>keep
|
||||
kernel</quote>, to avoid race conditions between iwd and
|
||||
networkd. If you don’t want this, you can set
|
||||
<literal>systemd.network.links."80-iwd" = lib.mkForce {}</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -245,7 +245,7 @@
|
||||
<para>
|
||||
<literal>rubyMinimal</literal> was removed due to being unused
|
||||
and unusable. The default ruby interpreter includes JIT
|
||||
support, which makes it reference it's compiler. Since JIT
|
||||
support, which makes it reference it’s compiler. Since JIT
|
||||
support is probably needed by some Gems, it was decided to
|
||||
enable this feature with all cc references by default, and
|
||||
allow to build a Ruby derivation without references to cc, by
|
||||
@ -330,7 +330,7 @@
|
||||
<literal>mediatomb</literal> package. If you want to keep the
|
||||
old behavior, you must declare it with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.mediatomb.package = pkgs.mediatomb;
|
||||
}
|
||||
@ -341,7 +341,7 @@
|
||||
service declaration to add the firewall rules itself before,
|
||||
you should now declare it with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.mediatomb.openFirewall = true;
|
||||
}
|
||||
@ -368,7 +368,7 @@
|
||||
<link xlink:href="options.html#opt-services.uwsgi.capabilities">services.uwsgi.capabilities</link>.
|
||||
The previous behaviour can be restored by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.uwsgi.user = "root";
|
||||
services.uwsgi.group = "root";
|
||||
@ -427,7 +427,7 @@
|
||||
<para>
|
||||
<link xlink:href="options.html#opt-networking.wireguard.interfaces">networking.wireguard.interfaces.<name>.generatePrivateKeyFile</link>,
|
||||
which is off by default, had a <literal>chmod</literal> race
|
||||
condition fixed. As an aside, the parent directory's
|
||||
condition fixed. As an aside, the parent directory’s
|
||||
permissions were widened, and the key files were made
|
||||
owner-writable. This only affects newly created keys. However,
|
||||
if the exact permissions are important for your setup, read
|
||||
@ -527,7 +527,7 @@ $ slapcat -F $TMPDIR -n0 -H 'ldap:///???(!(objectClass=olcSchemaConfig))'
|
||||
this directory are guarded to only run if the files they
|
||||
want to manipulate do not already exist, and so will not
|
||||
re-apply their changes if the IMDS response changes.
|
||||
Examples: <literal>root</literal>'s SSH key is only added if
|
||||
Examples: <literal>root</literal>’s SSH key is only added if
|
||||
<literal>/root/.ssh/authorized_keys</literal> does not
|
||||
exist, and SSH host keys are only set from user data if they
|
||||
do not exist in <literal>/etc/ssh</literal>.
|
||||
@ -550,9 +550,9 @@ $ slapcat -F $TMPDIR -n0 -H 'ldap:///???(!(objectClass=olcSchemaConfig))'
|
||||
configures Privoxy, and the
|
||||
<literal>services.tor.client.privoxy.enable</literal> option
|
||||
has been removed. To enable Privoxy, and to configure it to
|
||||
use Tor's faster port, use the following configuration:
|
||||
use Tor’s faster port, use the following configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
opt-services.privoxy.enable = true;
|
||||
opt-services.privoxy.enableTor = true;
|
||||
@ -628,7 +628,7 @@ $ slapcat -F $TMPDIR -n0 -H 'ldap:///???(!(objectClass=olcSchemaConfig))'
|
||||
exporter no longer accepts a fixed command-line parameter to
|
||||
specify the URL of the endpoint serving JSON. It now expects
|
||||
this URL to be passed as an URL parameter, when scraping the
|
||||
exporter's <literal>/probe</literal> endpoint. In the
|
||||
exporter’s <literal>/probe</literal> endpoint. In the
|
||||
prometheus scrape configuration the scrape target might look
|
||||
like this:
|
||||
</para>
|
||||
@ -689,7 +689,7 @@ http://some.json-exporter.host:7979/probe?target=https://example.com/some/json/e
|
||||
<literal>mpich</literal> instead of the default
|
||||
<literal>openmpi</literal> can now be achived like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
self: super:
|
||||
{
|
||||
mpi = super.mpich;
|
||||
@ -790,7 +790,7 @@ self: super:
|
||||
for any device that the kernel recognises as an hardware RNG,
|
||||
as it will automatically run the krngd task to periodically
|
||||
collect random data from the device and mix it into the
|
||||
kernel's RNG.
|
||||
kernel’s RNG.
|
||||
</para>
|
||||
<para>
|
||||
The default SMTP port for GitLab has been changed to
|
||||
@ -850,7 +850,7 @@ self: super:
|
||||
kodiPackages.inputstream-adaptive and kodiPackages.vfs-sftp
|
||||
addons:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
environment.systemPackages = [
|
||||
pkgs.kodi
|
||||
@ -867,7 +867,7 @@ self: super:
|
||||
and as a result the above configuration should now be written
|
||||
as:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
environment.systemPackages = [
|
||||
(pkgs.kodi.withPackages (p: with p; [
|
||||
@ -893,7 +893,7 @@ self: super:
|
||||
<literal>services.minio.dataDir</literal> changed type to a
|
||||
list of paths, required for specifiyng multiple data
|
||||
directories for using with erasure coding. Currently, the
|
||||
service doesn't enforce nor checks the correct number of paths
|
||||
service doesn’t enforce nor checks the correct number of paths
|
||||
to correspond to minio requirements.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -910,7 +910,7 @@ self: super:
|
||||
<literal>dvorak-programmer</literal> in
|
||||
<literal>console.keyMap</literal> now instead of
|
||||
<literal>dvp</literal>. In
|
||||
<literal>services.xserver.xkbVariant</literal> it's still
|
||||
<literal>services.xserver.xkbVariant</literal> it’s still
|
||||
<literal>dvp</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -954,7 +954,7 @@ self: super:
|
||||
supported.
|
||||
</para>
|
||||
<para>
|
||||
Furthermore, Radicale's systemd unit was hardened which might
|
||||
Furthermore, Radicale’s systemd unit was hardened which might
|
||||
break some deployments. In particular, a non-default
|
||||
<literal>filesystem_folder</literal> has to be added to
|
||||
<literal>systemd.services.radicale.serviceConfig.ReadWritePaths</literal>
|
||||
@ -991,7 +991,7 @@ self: super:
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="https://www.gnuradio.org/">GNURadio</link>
|
||||
has a <literal>pkgs</literal> attribute set, and there's a
|
||||
has a <literal>pkgs</literal> attribute set, and there’s a
|
||||
<literal>gnuradio.callPackage</literal> function that extends
|
||||
<literal>pkgs</literal> with a
|
||||
<literal>mkDerivation</literal>, and a
|
||||
@ -1027,7 +1027,7 @@ self: super:
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="https://kodi.tv/">Kodi</link> has been
|
||||
updated to version 19.1 "Matrix". See the
|
||||
updated to version 19.1 <quote>Matrix</quote>. See the
|
||||
<link xlink:href="https://kodi.tv/article/kodi-19-0-matrix-release">announcement</link>
|
||||
for further details.
|
||||
</para>
|
||||
@ -1098,9 +1098,9 @@ self: super:
|
||||
<listitem>
|
||||
<para>
|
||||
The default-version of <literal>nextcloud</literal> is
|
||||
nextcloud21. Please note that it's <emphasis>not</emphasis>
|
||||
nextcloud21. Please note that it’s <emphasis>not</emphasis>
|
||||
possible to upgrade <literal>nextcloud</literal> across
|
||||
multiple major versions! This means that it's e.g. not
|
||||
multiple major versions! This means that it’s e.g. not
|
||||
possible to upgrade from nextcloud18 to nextcloud20 in a
|
||||
single deploy and most <literal>20.09</literal> users will
|
||||
have to upgrade to nextcloud20 first.
|
||||
@ -1122,7 +1122,7 @@ self: super:
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
NixOS now emits a deprecation warning if systemd's
|
||||
NixOS now emits a deprecation warning if systemd’s
|
||||
<literal>StartLimitInterval</literal> setting is used in a
|
||||
<literal>serviceConfig</literal> section instead of in a
|
||||
<literal>unitConfig</literal>; that setting is deprecated and
|
||||
@ -1158,7 +1158,7 @@ self: super:
|
||||
users to declare autoscan media directories from their nixos
|
||||
configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.mediatomb.mediaDirectories = [
|
||||
{ path = "/var/lib/mediatomb/pictures"; recursive = false; hidden-files = false; }
|
||||
@ -1255,8 +1255,8 @@ self: super:
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>services.dnscrypt-proxy2</literal> module now
|
||||
takes the upstream's example configuration and updates it with
|
||||
the user's settings. An option has been added to restore the
|
||||
takes the upstream’s example configuration and updates it with
|
||||
the user’s settings. An option has been added to restore the
|
||||
old behaviour if you prefer to declare the configuration from
|
||||
scratch.
|
||||
</para>
|
||||
@ -1298,7 +1298,8 @@ self: super:
|
||||
<para>
|
||||
The zookeeper package does not provide
|
||||
<literal>zooInspector.sh</literal> anymore, as that
|
||||
"contrib" has been dropped from upstream releases.
|
||||
<quote>contrib</quote> has been dropped from upstream
|
||||
releases.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -1317,7 +1318,7 @@ self: super:
|
||||
now always ensures home directory permissions to be
|
||||
<literal>0700</literal>. Permissions had previously been
|
||||
ignored for already existing home directories, possibly
|
||||
leaving them readable by others. The option's description was
|
||||
leaving them readable by others. The option’s description was
|
||||
incorrect regarding ownership management and has been
|
||||
simplified greatly.
|
||||
</para>
|
||||
@ -1518,7 +1519,7 @@ self: super:
|
||||
been dropped. Users that still want it should add the
|
||||
following to their system configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.gvfs.package = pkgs.gvfs.override { samba = null; };
|
||||
}
|
||||
|
||||
@ -642,7 +642,7 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.paperless-ng.extraConfig = {
|
||||
# Provide languages as ISO 639-2 codes
|
||||
@ -723,7 +723,7 @@ Superuser created successfully.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>erigon</literal> ethereum node has moved it’s
|
||||
The <literal>erigon</literal> ethereum node has moved its
|
||||
database location in <literal>2021-08-03</literal>, users
|
||||
upgrading must manually move their chaindata (see
|
||||
<link xlink:href="https://github.com/ledgerwatch/erigon/releases/tag/v2021.08.03">release
|
||||
@ -737,7 +737,7 @@ Superuser created successfully.
|
||||
insecure. Out-of-tree modules are likely to require
|
||||
adaptation: instead of
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
users.users.foo = {
|
||||
isSystemUser = true;
|
||||
@ -747,7 +747,7 @@ Superuser created successfully.
|
||||
<para>
|
||||
also create a group for your user:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
users.users.foo = {
|
||||
isSystemUser = true;
|
||||
|
||||
@ -714,7 +714,7 @@
|
||||
<literal>programs.msmtp.*</literal> can be used instead for an
|
||||
equivalent setup. For example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
# Original ssmtp configuration:
|
||||
services.ssmtp = {
|
||||
@ -847,7 +847,7 @@
|
||||
<literal>config.nixpkgs.config.allowUnfree</literal> are
|
||||
enabled. If you still want these fonts, use:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
fonts.fonts = [
|
||||
pkgs.xorg.fontbhlucidatypewriter100dpi
|
||||
@ -942,7 +942,7 @@
|
||||
<para>
|
||||
Before:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.matrix-synapse = {
|
||||
enable = true;
|
||||
@ -977,7 +977,7 @@
|
||||
<para>
|
||||
After:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.matrix-synapse = {
|
||||
enable = true;
|
||||
@ -1143,7 +1143,7 @@
|
||||
<para>
|
||||
Before:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.keycloak = {
|
||||
enable = true;
|
||||
httpPort = "8080";
|
||||
@ -1157,7 +1157,7 @@
|
||||
<para>
|
||||
After:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.keycloak = {
|
||||
enable = true;
|
||||
settings = {
|
||||
|
||||
@ -1082,7 +1082,7 @@ services.github-runner.serviceOverrides.SupplementaryGroups = [
|
||||
removed. This option was an association of environment
|
||||
variables for Grafana. If you had an expression like
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.grafana.extraOptions.SECURITY_ADMIN_USER = "foobar";
|
||||
}
|
||||
@ -1096,7 +1096,7 @@ services.github-runner.serviceOverrides.SupplementaryGroups = [
|
||||
For the migration, it is recommended to turn it into the
|
||||
INI format, i.e. to declare
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.grafana.settings.security.admin_user = "foobar";
|
||||
}
|
||||
|
||||
@ -23,6 +23,13 @@
|
||||
<section xml:id="sec-release-23.05-new-services">
|
||||
<title>New Services</title>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="https://akkoma.social">Akkoma</link>, an
|
||||
ActivityPub microblogging server. Available as
|
||||
<link xlink:href="options.html#opt-services.akkoma.enable">services.akkoma</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="https://github.com/akinomyoga/ble.sh">blesh</link>,
|
||||
|
||||
@ -13,7 +13,7 @@ booting, and try to realise the configuration in the running system
|
||||
(e.g., by restarting system services).
|
||||
|
||||
::: {.warning}
|
||||
This command doesn\'t start/stop [user services](#opt-systemd.user.services)
|
||||
This command doesn't start/stop [user services](#opt-systemd.user.services)
|
||||
automatically. `nixos-rebuild` only runs a `daemon-reload` for each user with running
|
||||
user services.
|
||||
:::
|
||||
@ -51,7 +51,7 @@ GRUB 2 boot screen by giving it a different *profile name*, e.g.
|
||||
```
|
||||
|
||||
which causes the new configuration (and previous ones created using
|
||||
`-p test`) to show up in the GRUB submenu "NixOS - Profile \'test\'".
|
||||
`-p test`) to show up in the GRUB submenu "NixOS - Profile 'test'".
|
||||
This can be useful to separate test configurations from "stable"
|
||||
configurations.
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ The first steps to all these are the same:
|
||||
|
||||
1. Switch to the NixOS channel:
|
||||
|
||||
If you\'ve just installed Nix on a non-NixOS distribution, you will
|
||||
If you've just installed Nix on a non-NixOS distribution, you will
|
||||
be on the `nixpkgs` channel by default.
|
||||
|
||||
```ShellSession
|
||||
@ -49,10 +49,10 @@ The first steps to all these are the same:
|
||||
|
||||
1. Install the NixOS installation tools:
|
||||
|
||||
You\'ll need `nixos-generate-config` and `nixos-install`, but this
|
||||
You'll need `nixos-generate-config` and `nixos-install`, but this
|
||||
also makes some man pages and `nixos-enter` available, just in case
|
||||
you want to chroot into your NixOS partition. NixOS installs these
|
||||
by default, but you don\'t have NixOS yet..
|
||||
by default, but you don't have NixOS yet..
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -f '<nixpkgs>' -iA nixos-install-tools
|
||||
@ -70,7 +70,7 @@ The first steps to all these are the same:
|
||||
refer to the partitioning, file-system creation, and mounting steps
|
||||
of [](#sec-installation)
|
||||
|
||||
If you\'re about to install NixOS in place using `NIXOS_LUSTRATE`
|
||||
If you're about to install NixOS in place using `NIXOS_LUSTRATE`
|
||||
there is nothing to do for this step.
|
||||
|
||||
1. Generate your NixOS configuration:
|
||||
@ -79,12 +79,12 @@ The first steps to all these are the same:
|
||||
$ sudo `which nixos-generate-config` --root /mnt
|
||||
```
|
||||
|
||||
You\'ll probably want to edit the configuration files. Refer to the
|
||||
You'll probably want to edit the configuration files. Refer to the
|
||||
`nixos-generate-config` step in [](#sec-installation) for more
|
||||
information.
|
||||
|
||||
Consider setting up the NixOS bootloader to give you the ability to
|
||||
boot on your existing Linux partition. For instance, if you\'re
|
||||
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 `configuration.nix`:
|
||||
|
||||
@ -152,15 +152,15 @@ The first steps to all these are the same:
|
||||
```
|
||||
|
||||
Note that this will place the generated configuration files in
|
||||
`/etc/nixos`. You\'ll probably want to edit the configuration files.
|
||||
`/etc/nixos`. You'll probably want to edit the configuration files.
|
||||
Refer to the `nixos-generate-config` step in
|
||||
[](#sec-installation) for more information.
|
||||
|
||||
You\'ll likely want to set a root password for your first boot using
|
||||
the configuration files because you won\'t have a chance to enter a
|
||||
You'll likely want to set a root password for your first boot using
|
||||
the configuration files because you won't have a chance to enter a
|
||||
password until after you reboot. You can initialize the root password
|
||||
to an empty one with this line: (and of course don\'t forget to set
|
||||
one once you\'ve rebooted or to lock the account with
|
||||
to an empty one with this line: (and of course don't forget to set
|
||||
one once you've rebooted or to lock the account with
|
||||
`sudo passwd -l root` if you use `sudo`)
|
||||
|
||||
```nix
|
||||
@ -186,7 +186,7 @@ The first steps to all these are the same:
|
||||
bootup scripts require its presence).
|
||||
|
||||
`/etc/NIXOS_LUSTRATE` tells the NixOS bootup scripts to move
|
||||
*everything* that\'s in the root partition to `/old-root`. This will
|
||||
*everything* that's in the root partition to `/old-root`. This will
|
||||
move your existing distribution out of the way in the very early
|
||||
stages of the NixOS bootup. There are exceptions (we do need to keep
|
||||
NixOS there after all), so the NixOS lustrate process will not
|
||||
@ -201,10 +201,10 @@ The first steps to all these are the same:
|
||||
|
||||
::: {.note}
|
||||
Support for `NIXOS_LUSTRATE` was added in NixOS 16.09. The act of
|
||||
\"lustrating\" refers to the wiping of the existing distribution.
|
||||
"lustrating" refers to the wiping of the existing distribution.
|
||||
Creating `/etc/NIXOS_LUSTRATE` can also be used on NixOS to remove
|
||||
all mutable files from your root partition (anything that\'s not in
|
||||
`/nix` or `/boot` gets \"lustrated\" on the next boot.
|
||||
all mutable files from your root partition (anything that's not in
|
||||
`/nix` or `/boot` gets "lustrated" on the next boot.
|
||||
|
||||
lustrate /ˈlʌstreɪt/ verb.
|
||||
|
||||
@ -212,14 +212,14 @@ The first steps to all these are the same:
|
||||
ritual action.
|
||||
:::
|
||||
|
||||
Let\'s create the files:
|
||||
Let's create the files:
|
||||
|
||||
```ShellSession
|
||||
$ sudo touch /etc/NIXOS
|
||||
$ sudo touch /etc/NIXOS_LUSTRATE
|
||||
```
|
||||
|
||||
Let\'s also make sure the NixOS configuration files are kept once we
|
||||
Let's also make sure the NixOS configuration files are kept once we
|
||||
reboot on NixOS:
|
||||
|
||||
```ShellSession
|
||||
@ -233,7 +233,7 @@ The first steps to all these are the same:
|
||||
|
||||
::: {.warning}
|
||||
Once you complete this step, your current distribution will no
|
||||
longer be bootable! If you didn\'t get all the NixOS configuration
|
||||
longer be bootable! If you didn't get all the NixOS configuration
|
||||
right, especially those settings pertaining to boot loading and root
|
||||
partition, NixOS may not be bootable either. Have a USB rescue
|
||||
device ready in case this happens.
|
||||
@ -247,7 +247,7 @@ The first steps to all these are the same:
|
||||
Cross your fingers, reboot, hopefully you should get a NixOS prompt!
|
||||
|
||||
1. If for some reason you want to revert to the old distribution,
|
||||
you\'ll need to boot on a USB rescue disk and do something along
|
||||
you'll need to boot on a USB rescue disk and do something along
|
||||
these lines:
|
||||
|
||||
```ShellSession
|
||||
@ -264,14 +264,14 @@ The first steps to all these are the same:
|
||||
This may work as is or you might also need to reinstall the boot
|
||||
loader.
|
||||
|
||||
And of course, if you\'re happy with NixOS and no longer need the
|
||||
And of course, if you're happy with NixOS and no longer need the
|
||||
old distribution:
|
||||
|
||||
```ShellSession
|
||||
sudo rm -rf /old-root
|
||||
```
|
||||
|
||||
1. It\'s also worth noting that this whole process can be automated.
|
||||
1. It's also worth noting that this whole process can be automated.
|
||||
This is especially useful for Cloud VMs, where provider do not
|
||||
provide NixOS. For instance,
|
||||
[nixos-infect](https://github.com/elitak/nixos-infect) uses the
|
||||
|
||||
@ -30,7 +30,7 @@ This will create a `result` directory containing the following:
|
||||
These three files are meant to be copied over to the other already running
|
||||
Linux Distribution.
|
||||
|
||||
Note it's symlinks pointing elsewhere, so `cd` in, and use
|
||||
Note its symlinks pointing elsewhere, so `cd` in, and use
|
||||
`scp * root@$destination` to copy it over, rather than rsync.
|
||||
|
||||
Once you finished copying, execute `kexec-boot` *on the destination*, and after
|
||||
|
||||
@ -56,12 +56,12 @@ select the image, select the USB flash drive and click "Write".
|
||||
sudo dd if=<path-to-image> of=/dev/rdiskX bs=4m
|
||||
```
|
||||
|
||||
After `dd` completes, a GUI dialog \"The disk
|
||||
you inserted was not readable by this computer\" will pop up, which can
|
||||
After `dd` completes, a GUI dialog "The disk
|
||||
you inserted was not readable by this computer" will pop up, which can
|
||||
be ignored.
|
||||
|
||||
::: {.note}
|
||||
Using the \'raw\' `rdiskX` device instead of `diskX` with dd completes in
|
||||
Using the 'raw' `rdiskX` device instead of `diskX` with dd completes in
|
||||
minutes instead of hours.
|
||||
:::
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user