Off-grid nixpkgs feature

[Talleyrand-34]

Issue description

This would issue would be a discussion/feature request.

Right now,as far as I am concerned, you cannot use nixpkgs to update an offgrip nixos system because it depends on internet.

I think this is a problem for off-grid systems because there is no easy way to update. On the other hand there is creating an ISO for installing where you can go around this.

The feature would be something like "nixos-prefetch" that gets all the downloadable things needed for a configuration/flake.

On the target machine you specify this route as cache and you can update without internet.

Posible solutions

1. Create a new off-grid nixpkgs where urls are transformed into paths to the packages

2. On the target machine you specify to use that nixpkgs and the rebuild should not fail.

3. Download all packages
4. On the target machine place the packages on cache.nixos.org

Technical details

I am not an expert on nixos, I don't know the viability of this options. This issue is mainly to open discussion.

[jpds]

I recently discovered that @pete3n had typed up some notes (+other links) on this here:

• https://gist.github.com/pete3n/96a2ca4fecfe4a5c669f9580c306b80f

What you are going to require is a CI pipeline (which has access to the internet to pull down sources) that takes your [flake-based] system configurations and places the prebuilt derivations in your own self-hosted binary cache which your other machines pull down from. This pipeline would run every time there's a nix flake update to a new nixpkgs ref.

There's several options for serving the cache but personally, I like using attic for this:

• https://github.com/zhaofengli/attic/

I have a feature request for guidance on a full cache without internet here: https://github.com/zhaofengli/attic/issues/82

[unappetizing-morsel]

This should be filed as a bug in my opinion and bugs need steps to reproduce.

There are multiple distinct scenarios for using nixpkgs away from the Internet.

See #302443 and #302494 for examples of bugs I encountered in the specific scenario of 1) building with no Internet connection and 2) where the substituters and build machine haven't ever built specific packages before. That scenario is completely distinct from the scenario where a build machine or substituter has built the packages in question before. Also NixOS/nix#10276 and NixOS/nix#8216 are a limitation of Nix rather than nixpkgs when Nix over eagerly decides it won't attempt to substitute even if you have non-Internet substituters configured.

I would also point out that for being able to use nixpkgs away from the Internet, substituting pre-built packages is one approach but substituting the fixed-output downloads necessary to build everything yourself is another approach, one that may be more computationally expensive but has the potential to significantly save storage space while preserving one key part of an archival capability to reproduce packages and deployments in the distant future.

And nix channels and flakes are a separate dimension of this because even if you had an iso-like substituter, it would be useless without the Nix expression that evaluates to the package set itself, and for archival purposes you probably want multiple named channels (or flakes if you must) with garbage collection roots pinning everything for the current version of each channel so that you can safely garbage collect space that the channels of interest no longer reference. Though the safety of garbage collection there hinges on being able to know what a package from a channel references and Nix/nixpkgs might not be perfectly accurate in all cases there.

There is additionally more to this other than the Nix expression for the package set and the Nix store since as the Nix package manager software is developed more over time there is the possibility that a substituter prepared with an older version of Nix will not be compatible anymore. For archival purposes you also need to keep the specific version of the Nix package manager and the ability to install it into an environment it will run correctly in, such as retaining an architecture-specific iso for a Linux distro plus a snapshot of that distro's package repository if the iso wasn't built with exactly the right packages for Nix to install and run correctly under.

Lastly while "off-grid" does make sense as a way to describe this capability that Nix and nixpkgs are missing, "off-grid" is probably too ambiguous to describe a specific scenario as going "off-grid" with things built "on-grid" will show that the stateful nature of Nix and nixpkgs lets some things work when they would have failed without that prior state.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/potential-rfc-idea-expansion-of-the-dependency-tracking-system/43418/1

[pete3n]

@jpds thanks. I have been occupied by other work projects, but I have the end goal of being able to deploy and rebuild flake based NixOS system configurations on air-gapped systems. Proxies and SSH based deployments help where you are allowed to have internet connected systems deploy configurations to offline systems, but I have not found a way to do truly air-gapped deployments.

To give a comparison, I have previously used tools like Apt Offline https://github.com/rickysarraf/apt-offline for Debian based systems to update packages on air-gapped systems.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/a-bit-conflicted-about-nixos/44168/2