I just set up a similar server over the weekend, and I can fill in some of the blanks.
nixos-infect is remarkably good at what it does. There are a few caveats not listed; the most important one is that the root superuser has the same SSH key as the one handed out by cloud-init or otherwise pre-populated. In my case, I had to connect to a Debian machine as the debian user and then alter /root/.ssh/authorized_keys prior to infection. Still, it worked better than trying to cook my own OpenStack-compatible image using nixos-generators, which made too-big images.
I don’t remember why I [created a flake] (I have some idea of what the advantages of flakes are, but it’s not clear to me if any of them are actually relevant in this case)…
The main advantage for me is code reuse; in this case, it’s mostly reuse of NixOS modules. I used to use a Nix channel to deliver NixOS modules, but channels don’t compose; with flakes, I’m able to mixin modules from the current flake, from side projects, and from upstreams. I can isolate the NixOS configuration required to turn a side project into a NixOS service, export that service as a NixOS module via my side project’s flake, and then depend on that flake in order to reuse the module. This also would have fixed the fetchTree problem later on.
nixos-rebuild can be invoked directly on the cloud machine, unless it lacks RAM. Also, /etc/nixos can be a git repository with a flake, and nixos-rebuild defaults to using the current hostname as a flake attribute. From an automatic-updates perspective, this allows for a very hacky-yet-direct workflow: git-pull into /etc/nixos and then nixos-rebuild with no arguments.
I switched to Caddy a while back from nginx because it automatically sets up Let’s Encrypt certificates.
This is four lines with nginx. Suppose our domain is “example.com”; then:
This works regardless of whether nginx is configured in the current NixOS module or another one; for example, I configured PeerTube using services.peertube, and then amended services.nginx to add TLS.
Regarding Nginx, I’ve come to dislike the ACME / Let’s Encrypt setup in NixOS for larger deployments. It works perfectly fine, but we have servers with dozens of HTTPS vhosts, and the way NixOS does this is to create systemd services and timers for each vhost. This makes the activation step slow and verbose.
But I should also say I don’t have experience with Caddy in larger deployments. I’m only running it on my small personal server so far.
It seems like Nix doesn’t always give you the line number in your code which caused the error, even if you use –show-trace. I’m not sure why this is.
Yes, that is because fetchTree is implemented using C++ (as it is a builtin) and there is no Nix code to point to.
Right now to deploy a new version of one of my services, I need to manually copy and paste the Git SHA of the new revision. There’s probably a better workflow but I’m not sure what it is.
Enter the magical world of flake inputs and flake = false; for any git/path/etc input.
Enter the magical world of flake inputs and flake = false; for any git/path/etc input.
Specifically, for anyone wondering, flake inputs to mutable refs like url = github:NixOS/nixpkgs-unstable, then nix flake lock to lock the input to the current rev of that ref, then nix flake lock --update-input X for updating the dependency in the lockfile.
Agreed. I have a machine on netcup.de that had a /boot which was too small to install the next generation after nixos-infect was done with it but with nixos-anywhere I was able to directly deploy my system configuration and also have disko reformat the partition to be bigger.
Because Nix has so much control over the OS, I think that if I tried to make any ad-hoc changes at all to my Nix system, Nix would just blow them away the next time I ran nixos-rebuild.
Correction: It would not if you installed them with nix-env -i, which is why it’s discouraged so much.
I just set up a similar server over the weekend, and I can fill in some of the blanks.
nixos-infect is remarkably good at what it does. There are a few caveats not listed; the most important one is that the
rootsuperuser has the same SSH key as the one handed out bycloud-initor otherwise pre-populated. In my case, I had to connect to a Debian machine as thedebianuser and then alter/root/.ssh/authorized_keysprior to infection. Still, it worked better than trying to cook my own OpenStack-compatible image using nixos-generators, which made too-big images.The main advantage for me is code reuse; in this case, it’s mostly reuse of NixOS modules. I used to use a Nix channel to deliver NixOS modules, but channels don’t compose; with flakes, I’m able to mixin modules from the current flake, from side projects, and from upstreams. I can isolate the NixOS configuration required to turn a side project into a NixOS service, export that service as a NixOS module via my side project’s flake, and then depend on that flake in order to reuse the module. This also would have fixed the
fetchTreeproblem later on.nixos-rebuildcan be invoked directly on the cloud machine, unless it lacks RAM. Also,/etc/nixoscan be a git repository with a flake, andnixos-rebuilddefaults to using the current hostname as a flake attribute. From an automatic-updates perspective, this allows for a very hacky-yet-direct workflow: git-pull into/etc/nixosand thennixos-rebuildwith no arguments.This is four lines with nginx. Suppose our domain is “example.com”; then:
This works regardless of whether nginx is configured in the current NixOS module or another one; for example, I configured PeerTube using
services.peertube, and then amendedservices.nginxto add TLS.Regarding Nginx, I’ve come to dislike the ACME / Let’s Encrypt setup in NixOS for larger deployments. It works perfectly fine, but we have servers with dozens of HTTPS vhosts, and the way NixOS does this is to create systemd services and timers for each vhost. This makes the activation step slow and verbose.
But I should also say I don’t have experience with Caddy in larger deployments. I’m only running it on my small personal server so far.
regarding
nixos-infect: checkout nixos-anywhere sometime (if you’re not already familiar with it).ime it’s more reliable & easier to customize than the lustrating installer that
nixos-infectuses.Yes, that is because fetchTree is implemented using C++ (as it is a builtin) and there is no Nix code to point to.
Enter the magical world of flake inputs and
flake = false;for any git/path/etc input.Specifically, for anyone wondering, flake inputs to mutable refs like
url = github:NixOS/nixpkgs-unstable, thennix flake lockto lock the input to the current rev of that ref, thennix flake lock --update-input Xfor updating the dependency in the lockfile.On recent versions of Nix, updating has been replaced with
nix flake update [input].If the input is omitted all of the inputs get updated.
An alternative to nixos-infect is using nixos-anywhere with disko. I’ve personally had more luck with nixos-anywhere.
Agreed. I have a machine on netcup.de that had a /boot which was too small to install the next generation after nixos-infect was done with it but with nixos-anywhere I was able to directly deploy my system configuration and also have disko reformat the partition to be bigger.
Correction: It would not if you installed them with
nix-env -i, which is why it’s discouraged so much.[Comment from banned user removed]