Luke Granger-Brown
57725ef3ec
git-subtree-dir: third_party/nixpkgs git-subtree-split: 76612b17c0ce71689921ca12d9ffdc9c23ce40b2
125 lines
4.3 KiB
Markdown
125 lines
4.3 KiB
Markdown
# Changing the Configuration {#sec-changing-config}
|
|
|
|
The file `/etc/nixos/configuration.nix` contains the current
|
|
configuration of your machine. Whenever you've [changed
|
|
something](#ch-configuration) in that file, you should do
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild switch --use-remote-sudo
|
|
```
|
|
|
|
to build the new configuration as your current user, and as the root user,
|
|
make it the default configuration for booting. `switch` will also 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)
|
|
automatically. `nixos-rebuild` only runs a `daemon-reload` for each user with running
|
|
user services.
|
|
:::
|
|
|
|
::: {.warning}
|
|
Applying a configuration is an action that must be done by the root user, so the
|
|
`switch`, `boot` and `test` commands should be ran with the `--use-remote-sudo`
|
|
flag. Despite its odd name, this flag runs the activation script with elevated
|
|
permissions, regardless of whether or not the target system is remote, without
|
|
affecting the other stages of the `nixos-rebuild` call. This allows unprivileged
|
|
users to rebuild the system and only elevate their permissions when necessary.
|
|
|
|
Alternatively, one can run the whole command as root while preserving user
|
|
environment variables by prefixing the command with `sudo -E`. However, this
|
|
method may create root-owned files in `$HOME/.cache` if Nix decides to use the
|
|
cache during evaluation.
|
|
:::
|
|
|
|
You can also do
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild test --use-remote-sudo
|
|
```
|
|
|
|
to build the configuration and switch the running system to it, but
|
|
without making it the boot default. So if (say) the configuration locks
|
|
up your machine, you can just reboot to get back to a working
|
|
configuration.
|
|
|
|
There is also
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild boot --use-remote-sudo
|
|
```
|
|
|
|
to build the configuration and make it the boot default, but not switch
|
|
to it now (so it will only take effect after the next reboot).
|
|
|
|
You can make your configuration show up in a different submenu of the
|
|
GRUB 2 boot screen by giving it a different *profile name*, e.g.
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild switch -p test --use-remote-sudo
|
|
```
|
|
|
|
which causes the new configuration (and previous ones created using
|
|
`-p test`) to show up in the GRUB submenu "NixOS - Profile 'test'".
|
|
This can be useful to separate test configurations from "stable"
|
|
configurations.
|
|
|
|
A repl, or read-eval-print loop, is also available. You can inspect your configuration and use the Nix language with
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild repl
|
|
```
|
|
|
|
Your configuration is loaded into the `config` variable. Use tab for autocompletion, use the `:r` command to reload the configuration files. See `:?` or [`nix repl` in the Nix manual](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-repl.html) to learn more.
|
|
|
|
Finally, you can do
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild build
|
|
```
|
|
|
|
to build the configuration but nothing more. This is useful to see
|
|
whether everything compiles cleanly.
|
|
|
|
If you have a machine that supports hardware virtualisation, you can
|
|
also test the new configuration in a sandbox by building and running a
|
|
QEMU *virtual machine* that contains the desired configuration. Just do
|
|
|
|
```ShellSession
|
|
$ nixos-rebuild build-vm
|
|
$ ./result/bin/run-*-vm
|
|
```
|
|
|
|
The VM does not have any data from your host system, so your existing
|
|
user accounts and home directories will not be available unless you have
|
|
set `mutableUsers = false`. Another way is to temporarily add the
|
|
following to your configuration:
|
|
|
|
```nix
|
|
{
|
|
users.users.your-user.initialHashedPassword = "test";
|
|
}
|
|
```
|
|
|
|
*Important:* delete the \$hostname.qcow2 file if you have started the
|
|
virtual machine at least once without the right users, otherwise the
|
|
changes will not get picked up. You can forward ports on the host to the
|
|
guest. For instance, the following will forward host port 2222 to guest
|
|
port 22 (SSH):
|
|
|
|
```ShellSession
|
|
$ QEMU_NET_OPTS="hostfwd=tcp:127.0.0.1:2222-:22" ./result/bin/run-*-vm
|
|
```
|
|
|
|
allowing you to log in via SSH (assuming you have set the appropriate
|
|
passwords or SSH authorized keys):
|
|
|
|
```ShellSession
|
|
$ ssh -p 2222 localhost
|
|
```
|
|
|
|
Such port forwardings connect via the VM's virtual network interface.
|
|
Thus they cannot connect to ports that are only bound to the VM's
|
|
loopback interface (`127.0.0.1`), and the VM's NixOS firewall
|
|
must be configured to allow these connections.
|