Rework of the nix (the package manager) config #45

Merged
nerf merged 1 commit from nerf/nixConfig:nix-config into main 2024-10-16 15:06:08 +00:00
4 changed files with 36 additions and 19 deletions
Showing only changes of commit ec46a28278 - Show all commits

View file

@ -3,21 +3,28 @@ with lib; let
admins = { admins = {
nerf = { nerf = {
hashedPassword = "$y$j9T$SJcjUIcs3JYuM5oyxfEQa/$tUBQT07FK4cb9xm.A6ZKVnFIPNOYMOKC6Dt6hadCuJ7"; hashedPassword = "$y$j9T$SJcjUIcs3JYuM5oyxfEQa/$tUBQT07FK4cb9xm.A6ZKVnFIPNOYMOKC6Dt6hadCuJ7";
keys = [ sshKeys = [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEdA4LpEGUUmN8esFyrNZXFb2GiBID9/S6zzhcnofQuP nerf@nerflap2" "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEdA4LpEGUUmN8esFyrNZXFb2GiBID9/S6zzhcnofQuP nerf@nerflap2"
]; ];
nixKeys = [
"nerflap2-1:pDZCg0oo9PxNQxwVSQSvycw7WXTl53PGvVeZWvxuqJc="
];
}; };
gonne = { gonne = {
hashedPassword = "$6$EtGpHEcFkOi0yUWp$slXf0CvIUrhdqaoCrQ5YwtYu2IVuE1RGGst4fnDPRLWVm.lYx0ruvSAF2/vw/sLbW37ORJjlb0NHQ.kSG7cVY/"; hashedPassword = "$6$EtGpHEcFkOi0yUWp$slXf0CvIUrhdqaoCrQ5YwtYu2IVuE1RGGst4fnDPRLWVm.lYx0ruvSAF2/vw/sLbW37ORJjlb0NHQ.kSG7cVY/";
keys = [ sshKeys = [
"sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIAhwkSDISCWLN2GhHfxdZsVkK4J7JoEcPwtNbAesb+BZAAAABHNzaDo= Gonne" "sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIAhwkSDISCWLN2GhHfxdZsVkK4J7JoEcPwtNbAesb+BZAAAABHNzaDo= Gonne"
]; ];
nixKeys = [
"gonne.mathebau.de-1:FsXFyFiBFE/JxC9MCkt/WuiXjx5dkRI9RXj0FxOQrV0="
];
}; };
}; };
mkAdmin = name: { mkAdmin = name: {
hashedPassword, hashedPassword,
keys, sshKeys,
...
}: { }: {
"${name}" = { "${name}" = {
isNormalUser = true; isNormalUser = true;
@ -25,10 +32,12 @@ with lib; let
extraGroups = ["wheel"]; extraGroups = ["wheel"];
group = "users"; group = "users";
home = "/home/${name}"; home = "/home/${name}";
openssh.authorizedKeys = {inherit keys;}; openssh.authorizedKeys = {keys = sshKeys;};
inherit hashedPassword; inherit hashedPassword;
}; };
}; };
mkNixKeys = _: {nixKeys, ...}: nixKeys;
in { in {
users.users = mkMerge (mapAttrsToList mkAdmin admins); users.users = mkMerge (mapAttrsToList mkAdmin admins);
nix.settings.trusted-public-keys = lists.concatLists (mapAttrsToList mkNixKeys admins);
Outdated
Review

If someone knows a solution without mapAttrsToList let me know. It feels a bit like overkill. (esp. as we don't need the username here).

If someone knows a solution without `mapAttrsToList` let me know. It feels a bit like overkill. (esp. as we don't need the username here).
} }

View file

@ -5,18 +5,11 @@
}: { }: {
imports = [ imports = [
./admins.nix ./admins.nix
./nix_keys.nix ./nix.nix
./prometheusNodeExporter.nix ./prometheusNodeExporter.nix
../modules/impermanence.nix ../modules/impermanence.nix
]; ];
nix = {
extraOptions = ''
experimental-features = nix-command flakes
builders-use-substitutes = true
'';
};
networking = { networking = {
firewall = { firewall = {
# these shoud be default, but better make sure! # these shoud be default, but better make sure!

22
nixos/roles/nix.nix Normal file
View file

@ -0,0 +1,22 @@
{
nix = {
settings = {
Gonne marked this conversation as resolved Outdated
Outdated
Review

While part of nix.settings I would prefer to move these to admin.nix and leave a reference comment here. If we start our own builder we may start to trust it here.

While part of `nix.settings` I would prefer to move these to `admin.nix` and leave a reference comment here. If we start our own builder we may start to trust it here.
Outdated
Review

Yes let me think how to do this later

Yes let me think how to do this later
Gonne marked this conversation as resolved Outdated
Outdated
Review

Please add a comment here that nix.settings.trusted-public-keys is also (currently only) set in admin.nix.

Please add a comment here that `nix.settings.trusted-public-keys` is also (currently only) set in `admin.nix`.
# trusted-public-keys belonging to specific persons are set in rolse/admins.nix
trusted-public-keys = [];
experimental-features = [
"flakes"
"nix-command"
];
auto-optimise-store = true;
fallback = true;
builders-use-substitutes = true;
};
Gonne marked this conversation as resolved Outdated
Outdated
Review

typo

typo
Outdated
Review

And i messed up the grouping completely, dafuq

And i messed up the grouping completely, dafuq
Gonne marked this conversation as resolved Outdated
Outdated
Review

Please also set nix.gc.automatic = true.

Please also set `nix.gc.automatic = true`.
gc = {
automatic = true;
persistent = false;
Gonne marked this conversation as resolved Outdated
Outdated
Review

Please comment on why this is a good idea on / as tmpfs. Feels like it adds a garbage collection right after every restart compared to missed ones on downtime. I have no idea which we prefer.

Please comment on why this is a good idea on `/` as `tmpfs`. Feels like it adds a garbage collection right after every restart compared to missed ones on downtime. I have no idea which we prefer.
Outdated
Review

I don't think this is important. On true it will catch up missed runs when the machine was down, on false it will just start the timer
on boot. So if false we could run into the problem that we never garbage collect if we restarted a machine more then once per week.

And yes I didn't thought about where systemd stored this and it would need some impermanence, sigh

I don't think this is important. On true it will catch up missed runs when the machine was down, on false it will just start the timer on boot. So if false we could run into the problem that we never garbage collect if we restarted a machine more then once per week. And yes I didn't thought about where systemd stored this and it would need some impermanence, sigh
Outdated
Review

note for myself it is /var/lib/systemd/timers

note for myself it is `/var/lib/systemd/timers`
Outdated
Review

So de we want more persistency things, or risking to never garbage collect on machines that restart often.
The upside of this behavior would be that you never boot a new generation and run into a garbage collection that is scheduled
directly after. The more I think it is more sensible to have a week from last reboot and not from last garbage collect.

So de we want more persistency things, or risking to never garbage collect on machines that restart often. The upside of this behavior would be that you never boot a new generation and run into a garbage collection that is scheduled directly after. The more I think it is more sensible to have a week from last reboot and not from last garbage collect.
dates = "weekly";
options = "-d";
randomizedDelaySec = "5h";
};
};
}
Gonne marked this conversation as resolved Outdated
Outdated
Review

optimise = true, but never? Is that how the empty dates array works?

`optimise = true`, but never? Is that how the empty `dates` array works?
Outdated
Review

Yes, line 11 makes it optimise on store operations, but if i understood it correctly only if this option is true. Date can be used to make regular optimization runs. But this setup seemed to be more sensible to me as we don't have regular store operations. So we can
just do that when we update.

Yes, line 11 makes it optimise on store operations, but if i understood it correctly only if this option is true. Date can be used to make regular optimization runs. But this setup seemed to be more sensible to me as we don't have regular store operations. So we can just do that when we update.
Outdated
Review

The option auto-optimise-store is applied when something is built, but for me it feels like this setting needs to be set on the building system (e.g. my private config) rather than on our VMs. Furthermore it may slow down builds as well as downloads from remote builders significantly (Github comment).
The nix.optimise however configures a systemd timer that is run on the given dates. Nothing in its definition file gives me the impression that this interacts with auto-optimise-store. I think that this is what we actually want on our VMs.
Setting the dates empty gives an erroneous systemd-timer on my system.

The option `auto-optimise-store` is applied when something is built, but for me it feels like this setting needs to be set on the building system (e.g. my private config) rather than on our VMs. Furthermore it may slow down builds as well as downloads from remote builders significantly ([Github comment]( https://github.com/NixOS/nix/issues/6033#issuecomment-1615856506)). The `nix.optimise` however configures a `systemd` timer that is run on the given dates. Nothing in its [definition file](https://github.com/NixOS/nixpkgs/blob/nixos-24.05/nixos/modules/services/misc/nix-optimise.nix) gives me the impression that this interacts with `auto-optimise-store`. I think that this is what we actually want on our VMs. Setting the `dates` empty gives an erroneous systemd-timer on my system.
Outdated
Review

Hmm, i don't know how the nix store copy exactly works, my assumption was kind of that the target machine would optimize, when I copy to it. It will also substitute everything it can from cache, so local storage optimizations of the building machine shouldn't play a role. If it would then the cache would need this option.

For the second part I missread the documentation then, will fix that.

Hmm, i don't know how the nix store copy exactly works, my assumption was kind of that the target machine would optimize, when I copy to it. It will also substitute everything it can from cache, so local storage optimizations of the building machine shouldn't play a role. If it would then the cache would need this option. For the second part I missread the documentation then, will fix that.

View file

@ -1,7 +0,0 @@
{
imports = [];
nix.settings.trusted-public-keys = [
"nerflap2-1:pDZCg0oo9PxNQxwVSQSvycw7WXTl53PGvVeZWvxuqJc="
"gonne.mathebau.de-1:FsXFyFiBFE/JxC9MCkt/WuiXjx5dkRI9RXj0FxOQrV0="
];
}