morph
morph copied to clipboard
A Question on morph and nix.autoUpgrade
Hello,
I would like to know how morph and nix.autoUpgrade work together. Say I have a box A which I have an old /etc/nixos/configuration.nix in place and I have updated it with nix.autoUpgrade.enable = true; with morph from a remote box.
What should I expect the autoUpgrade function to do? Will it go and upgrade the machine via the old in-place /etc/nixos/configuration.nix or the current config derivation is stored in remote nix store and it will be re-eval'd to apply the autoUpgrade?
thnx, evrim.
Hi @evrim ,
Since nix.autoUpgrade
just runs nixos-rebuild switch --upgrade
, nixos-rebuild by default will use the NIX_PATH to search for a nixos-config, defaulting to /etc/nixos/configuration.nix.
Morph doesn't copy your configuration to the remote host automatically or anything, hence - by default - nixos-rebuild
won't work with morph'ed hosts unless you manually do things to make it work, e.g. maintain a clone of your config on the box itself or redirect the search-path for nixos-rebuild to some remote config location.
Hope this answered your question. :)
Hey there,
Thanks for the quick answer. Are there any unit/timer definitions somewhere for morph that I can employ for a nix.autoUpgrade replacement on my local machine?
evrim.
What I usually do is, I get rid of channels and /etc/nixos
when I use morph and system.autoUpgrade
.
Something like this:
{ config, lib, pkgs, ... }:
let
nixpkgsVersion = (import <nixpkgs> { }).lib.version;
nixpkgsChannel = builtins.substring 0 5 nixpkgsVersion;
nixosConfig =
let
repo = pkgs.nix-gitignore.gitignoreSource [ ] ../..;
configDir = "${repo}/deployments/${config.networking.hostName}";
in
pkgs.writeText "configuration.nix" ''
{ ... }: {
imports = [
${configDir}/hardware-configuration.nix
${configDir}/configuration.nix
];
}
'';
in
{
nix.nixPath =
let
nixpkgsUrl = "https://releases.nixos.org/nixos/${nixpkgsChannel}/nixos-${nixpkgsVersion}/nixexprs.tar.xz";
in
lib.mkForce [
"nixpkgs=${nixpkgsUrl}"
"nixos-config=${nixosConfig}"
];
system.autoUpgrade.enable = true;
systemd.services.nixos-upgrade.environment.NIX_PATH =
let
nixpkgsUrl = "https://nixos.org/channels/nixos-${nixpkgsChannel}/nixexprs.tar.xz";
nixPath = [
"nixpkgs=${nixpkgsUrl}"
"nixos-config=${nixosConfig}"
];
in
lib.mkForce (builtins.concatStringsSep ":" nixPath);
}
The idea is to have pinned channels (via url) in NIX_PATH and always the latest channel (via url) during update.
Please note:
- I recently changed/refactored this, so it might be full of bugs.
- Also, this only works if your config repo (or directory) has the same layout as mine, for which it copies the config of all deployments to each machine, so make sure to not have any secrets in there.
Thnx for your clever solution. It led me thinking.
{ config, lib, pkgs, ... }@args:
let repo = pkgs.nix-gitignore.gitignoreSource [] ./..;
nixos-config = "${repo}/network/${config.networking.hostName}/default.nix";
nixPath = [ "nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos"
"nixos-config=${nixos-config}"
"nixpkgs-overlays=${repo}/modules/overlays-compat/compat/"
"/nix/var/nix/profiles/per-user/root/channels/nixos"
];
in {
nix.nixPath = lib.mkForce nixPath;
system.autoUpgrade.enable = true;
systemd.services.nixos-upgrade.environment.NIX_PATH = lib.mkForce (builtins.concatStringsSep ":" nixPath);
}
This solution actually works if you always update the system via morph. However, there are drawbacks:
- It is impossible to use nixos-rebuild locally on the machine since nix-gitignore.gitignoreSource path will grow indefinetly.
- etc environment is updated every time I run nixos-rebuild switch locally on the machine,
- there is no way to see whether there is something new or not.
Other than these above, everything seem to work. The solution I believe is making a pkg of nixos-config git, push it and refer to it. This way, the config paths will be the same contrary to what nix.gitignore does and nixos-rebuild switch will work as expected on the local machine.
Hm, I thought I could find a fixpoint for the configs yet no luck. Any ideas?
Thanks for finding the issue with the growing store path. I had that one before and fixed it in an earlier version. But now I created that bug again.
Fixing this should work if we create a pkg for nixos-config. I like that idea.
I stopped trying to create a fixpoint. The issue at the moment is, that a new config is always built form the old one, so it's basically a chain. But for me the config repo is really tiny and it gets cleaned up after some weeks anyway.
Things that might work:
- A hack like "always link the current nixos config to /etc/nixos in e.g. an activation script".
- Find a way to do something like: If it's a store path, use it directly, if not, use gitignoreSource. Maybe I'll find some time to investigate this idea.
Finally I got it working. Basically the derivation outputs its path to config for the next time. Meh, spent so many hours on this :( Let's see whether the GC has any love for us.
2 let
5 repo = if (config ? deployment)
6 then pkgs.callPackage ../pkg.nix {hostname = config.networking.hostName;}
7 else config.nixos-config-in-store;
31 in {
33 environment.etc."nixos".source = repo;
34 system.autoUpgrade.enable = true;
35 }
1 {hostname, pkgs, stdenv, lib, ...}:
6 with lib;
7 let path = "/etc/nixos/network/${hostname}/default.nix";
8 in stdenv.mkDerivation {
9 name = "nixos-config-core";
10 version = "1.0";
11 src = ./.;
17 builder = pkgs.writeText "builder.sh" ''
18 #!/bin/sh
19 source $stdenv/setup
20 mkdir -p $out
21 cp -r $src/* $out/
22 rm $out/result || true
23 rm $out/configuration.nix || true
24 cat > $out/configuration.nix << EOF
25 {config, lib, ...}@args: {
26 options = {
27 nixos-config-in-store = lib.mkOption {
28 type = lib.types.str;
29 default = "$out";
30 };
31 };
32 imports = [ "${path}" ];
33 }
34 EOF
35 '';
36 }
Just add the following that will prevent GC collecting the nixos-config.
environment.systemPackages = [ repo ];
Hope we'll never have to deal with this again. evrim.