nerf/nixConfig
1
0
Fork 0
forked from Fachschaft/nixConfig
Code Pull requests Activity

fixed Typos Gonne found see [#8]

Browse source
This commit is contained in:
Dennis Frieberg 2023-10-02 11:47:52 +02:00
parent 3cac8d6b14
commit b76ae185b6
Signed by: nerf
GPG key ID: 42DED0E2D8F04FB6
1 changed files with 13 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
README.md
View file

@ -26,7 +26,7 @@ git+file:///home/nerf/git/nixConfig?ref=refs%2fheads%2fnyarlathtop&rev=9d0eb7492
└───packages
└───x86_64-linux
```
we can see there is an output called `nixosConfigurations.nyarlathotep`. Which contains the configuration of the machine
we can see there is an output called `nixosConfigurations.nyarlathotep` which contains the configuration of the machine
called nyarlathotep. `nixosConfigurations` is special in that sense, that `nixos-rebuild` will automatically look
for this key and assume how it is structured. The interesting part for us is the derivation `config.system.build.toplevel`.
Its closure contains the whole system and the resulting derivation a script that changes the current system to
@ -57,10 +57,10 @@ via ssh. We could just run:
```
$ nix copy -s --to <however you setup your ssh stuff> .#nixosConfigurations.<name>.config.system.build.toplevel
```
This will evaluate the flake again to get the store path of the given derivation. If we want to avoid this
This will evaluate the flake again to get the store path of the given derivation. If we want to avoid this,
we might supply the corresponding store path directly.
The `-s` is important it makes the target machine substitute all derivations it can (by default from chache.nixos.org).
The `-s` is important: it makes the target machine substitute all derivations it can (by default from chache.nixos.org).
So you only upload configuration files and self build things.
To be able to copy things to a machine they need to be signed by someone trusted. Additional trusted nix keys are handled
@ -79,15 +79,15 @@ details consider the `--help` output of that script. The storepath (or at least
is exactly the same it was on your machine.
If you have a `nixos-rebuild` available on your system it can automatize these things with the `--flake` and
If you have a `nixos-rebuild` available on your system, it can automatize these things with the `--flake` and
`--target-host` parameters. But there are some pitfalls so look at the `nixos-rebuild` documentation beforehand.
### On the machine
clone this repository to `/etc/nixos/` and `nixos-rebuild boot` or `nixos-rebuild switch` that will select
Clone this repository to `/etc/nixos/` and `nixos-rebuild boot` or `nixos-rebuild switch` that will select
the appropriate machine based on hostname.
If the hostname is not correct, or you don't want to clone this flake you can also use the `--flake` parameter.
If the hostname is not correct, or you don't want to clone this flake, you can also use the `--flake` parameter.
In any case, to switch the system configuration you will need to have root privileges on the target machine.
@ -140,7 +140,7 @@ or service setup, after the reboot.
## How to write a new machine configuration
At best you take a first look at already existing configurations. But here are a few guidelines.
At best, you take a first look at already existing configurations. But here are a few guidelines.
Make a new folder in `/nixos/machines`. The name of the folder should match the hostname of your
machine. The only technically required file in there is `configuration.nix`. So create it.
@ -163,7 +163,7 @@ imports = [
system.stateVersion = "<state version at time of install>";
}
```
the import of `../../roles` loads all the nice default setup that all these machines have in common. There the
The import of `../../roles` loads all the nice default setup that all these machines have in common. There the
impermanence configuration is loaded as well as ssh, sops, shared user configuration and much more.
The other two imports are suggestions how you should organize your configuration but not enforced by anything.
In your hardware
@ -171,11 +171,11 @@ configuration you should basically only write you filesystem layout and your hos
is already taken care of by `../../roles`.
As of moment of writing `network.nix` should contain ip, nameserver and default gateway setup. As parts of
this is constant across all systems this will undergo refactor soon.
this is constant across all systems and will undergo refactor soon.
I would recommend to split your configuration into small files you import. If this is something machine specific (like
tied to your ip address hostname) put it into the machine directory. If it is not put it into `/nixos/roles/` if it
is not but has options to set put it in `/nixos/modules`.
tied to your ip address hostname), put it into the machine directory. If it is not, put it into `/nixos/roles/` if it
is not but has options to set, put it in `/nixos/modules`.
## How this flake is organized
@ -198,8 +198,8 @@ those as nixos configurations, and populates the flake.
network configuration. And service configuration that are too closely interwoven with the rest of that machine (for example
mailserver configuration depends heavily on network settings). It also
contains the root configuration for that machine called `configuration.nix`. This file usually only includes other modules.
These `configuration.nix` files are almost usual nix configurations. The only difference is, that they take as an extra argument
the flake inputs. This allows them to load modules from these flakes. For example nyarlathotep loads the simple-nixos-mailserver
These `configuration.nix` files are almost usual nix configurations. The only difference is that they take as an extra argument
the flake inputs. This allows them to load modules from these flakes. For example, nyarlathotep loads the simple-nixos-mailserver
module that way.
#### roles