1. 31
  1.  

  2. 6

    I love Christine’s posts :)

    1. 5

      I’m curious how people think of morph vis a vis the nixops tool - is one obviously better than the other for managing several NixOS machines?

      1. 10

        All of them suck. Morph is at least tolerable for my needs.

        EDIT: the main reason I don’t like nixops is that it’s built on Python 2 and doesn’t really scale well to machines managed by multiple humans. Morph is a simpler tool without as much persistent state and it’s made with a language toolchain that isn’t obsolete.

        1. 3

          I started using nixops. It has some support for provisioning machines that I liked. When that broke, I used morph. It can’t do provisioning but than maybe also had less chance of breaking?

          I had some trouble making Auto-updates possible with morph - I ended up with a pretty weird hack.

          1. 2

            I’ve been looking at doing some horrifying hack in locally hosted CI to get auto-updates working on my servers, so that seems par for the course! What hack are you using?

            1. 1

              To be honest, when I look at the code that I used, I am not fully confident that it still works :)

              The idea is to setup a “normal” nixos configuration (in configuration.nix) and use nixos for auto-updating. + separating some bigger derivations out of that into their own “source” derivations.

              In my morph config, I am using configuration.nix in a pretty, ahem, rough way by merging it with my other morph config (health checks etc) like this: ...} // (import ./configuration.nix { inherit config pkgs; })

              I hope that makes sense.

              My supposed auto-update (minimally censored to exclude the host/blog name) functionality that import via imports in configuration.nix:

              {pkgs, lib, ...}:
              {
                system.autoUpgrade = {
                  enable = true;
                  channel = https://nixos.org/channels/nixos-unstable;
                  allowReboot = true;
                  dates = "20:25";
                };
              
                environment.etc = {
                  "nixos/configuration_nix" =
                  let myPath = ../.;
                      configPath =
                        if lib.canCleanSource myPath
                        then lib.sourceByRegex myPath [ ''^nix(/.*)?$'' ''^subdir(/.*\.nix)?$'' ]
                        else myPath;
              
                      # By separating the sources into a separate derivation, we do not need to copy
                      # the whole blog over whenever any nix config changes.
                      config = pkgs.runCommandNoCCLocal "config-with-sources" {} ''
                        mkdir $out
                        cp -R ${configPath}/* $out
                        chmod +w $out/subdir
                        ln -s ${./blog} $out/subdir/blog
                      '';
                  in
                  {
                    target = "nixos/configuration.nix";
                    text = "import ${builtins.trace "using ${config}" config}/subdir/configuration.nix";
                  };
                };
              }
              

              So here you go, there is probably a much better simpler way.

      2. 5

        If there was better support on public clouds, I’d be using NixOS all the time, this totally kills Ansible and other configuration management solutions.

        1. 5

          There’s actually a terraform module that you can use to load configuration into NixOS machines. It’s been on my list to write about it, but I want to use it in production a bit more before I commit to writing about it.

          1. 3

            Which platforms does it work (well) on? I’m using this script to bootstrap Hetzner servers, and I wouldn’t mind something a bit less manually involved.

            1. 3

              I can’t find the comment. A nice lobster user pointed me at nix-infect and I use it with Terraform like this:

              resource "hcloud_server" "mon2" {
                image       = "debian-10"
                keep_disk   = true
                name        = "mon2"
                server_type = "cx21"
                ssh_keys    = local.hcloud_keys
                backups     = false
              
                user_data = <<EOF
                #cloud-config
                runcmd:
                  - curl https://raw.githubusercontent.com/zimbatm/nixos-infect/3e9d452fa6060552a458879b66d8eea1334d93d2/nixos-infect | NIX_CHANNEL=nixos-20.09 bash 2>&1 | tee /tmp/infect.log
                EOF
              }
              
              1. 1

                I’ve only tested it with AWS, but as far as I understand it should work fine with Google Cloud and just about anything else as long as you have a NixOS system on it.

            2. 4

              Vultr lets you upload an ISO and install from that.

              Edit: They even have an existing nixos ISO you can use!

              1. 4

                I usually make my own NixOS ISO that will automatically install NixOS on the machine with something like this that I really need to write a blogpost on.

                1. 3

                  Nice! Though as a NixOS beginner it might be easier to start out with an existing ISO. :D

                  1. 4

                    Granted, but being able to assimilate a new system in about 3 minutes is a fun party trick :D

                    1. 3

                      Heck yes! I look forward to your post about it!

                      1.  

                        And just like that, I had to build an ISO! Thanks for pointing me at your repo, it was very helpful! :D

                    2. 3

                      I wonder how hard it would be to extend this solution to create a ZFS-based installation.

                      I’d love to have a way of automatically installing NixOS onto one of OVH’s US-based servers. I’m thinking the best way to do this would be either PXE or a variation on this kexec-based solution.

                      1. 2

                        Not very! You’d just mess with the part that configures disks and mounting. I don’t use ZFS in my VMs however it should be easy to do. I would also suggest messing with how it defines the disk in question. I’m going to set something up with ZFS zraid1 groups for when I do installation on my homelab once I get the rack ordered in July (depending on how the research for my homelab goes, I currently have a spreadsheet of hardware I’d want (a bunch of used 2U servers) but I really need to wait until I move to be sure that the new place has space for it.

                  2. 1

                    NixOS + packer gives you a decent story, and then you can set userdata to finish off your images on first boot. I wrote about it here: http://jackkelly.name/blog/archives/2020/08/30/building_and_importing_nixos_amis_on_ec2/

                  3. 3

                    How mature is the Nix tooling story? I’d like to migrate from my current solution for side projects (some bespoke shell tooling), however I’m a little afraid if I invest the time to do it right that it’ll be obsolete in months or require lots of maintenance.

                    1. 1

                      There are still some growing pains, the biggest upcoming change will be Nix Flakes and the new nix 2.0 CLI. Flakes is currently in Beta(?) I dunno, it’s not default yet, but it’s easily install-able. The CLI is there now, but it’s not fully fleshed out yet, so you have to go back to nix- instead of nix sometimes.

                      I’m still fairly new, but so far it all seems stable enough.

                    2. 3

                      Good timing, I was going to switch from NixOps to Morph because I didn’t want to deal with state!