[Nix-dev] /etc/nixos/configuration.nix not versioned?

[Arnold Krille]

Hi,

On Fri, 16 Sep 2016 09:13:27 -0700 Wink Saville <wink at saville.com>
wrote:
> As a newbie I was playing around and last night I rolled back to an
> older configuration and realized that the configuration.nix file
> didn't rollback. I can now realize that configuration.nix has nothing
> to do with booting or running the system and it only builds the
> system.
> 
> But at the moment I have 20 variations of my system in
> /boot/loader/entries/* but only the "latest"
> /etc/nixos/configuration.nix. So how are people managing
> configuration.nix files and keeping them 'synchronized' with /boot/**/
> in particular /boot/loader/entries/* ?
> 
> What I've just done is put /etc/nixos into a git repository, but that
> puts the burden on me to keep it synchronized with the
> /boot/loader/entries. Hopefully there is a better way.

/etc/nixos/configuration.nix (and the files included there) is the one
place that nix can not manage for you. It could save a copy somewhere
within the activated profile. But it can not modify/move the file
itself.

Consider this:
* You have a working configuration
* You change configuration.nix
* You build the new config and switch to it (temporarily with
  'nixos-rebuilt test')
* You realize something is not working as expected and roll back to the
  next older version for the moment.
Now when nixos moves the configuration for you, you will be back to the
state before you started the config changes. You have no way of going
forward again and especially no way of modifying the forward
configuration and fixing it. Because its not there anymore…

What I am doing[1] is:
* there is /etc/nixos/nixconfig/ directory which is actually a git
  checkout.
* /etc/nixos/configuration.nix basically imports everything from within
  that nixconfig/<machine>/default.nix
* the nixconfig also has nixpkgs as submodule in git and uses that as
  source instead of any channels.

That way I have full control over which configuration should be
running. And also about which version of the nixpkgs is used.
I can run tests on the system-config before pushing the config to
master and rebuilding my server(s) into a non-working state.
I have master, staging and story-branches and can test the next
nixos-release in the tests of my systems before applying it to the
actual machines.

The combination of full system description, full control over the
package state and full testability is what makes my daily work-life
very miserable. Because I have this at home but not at work:-/

Have fun,

Arnold

[1] A bit outdated because my main repo is locally, but
https://github.com/kampfschlaefer/nixconfig has my systems config.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160916/12c2465d/attachment.sig>