forked from Fachschaft/nixConfig
fixed Typos Gonne found see [#8]
This commit is contained in:
parent
8a87066837
commit
191083f526
1 changed files with 13 additions and 13 deletions
26
README.md
26
README.md
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue