NixOS image as a flake about yubikey-guide HOT 14 CLOSED

I think this is awesome and could replace the yubikey-installer.nix. A few caveats:

1. Use nixos-23.11 instead of nixos-23.05, this should also allow replacing hopenpgp-tools hack.
2. having a versioned github.com:drduh/config is not awesome, because, if the maintainer changes them upstream, someone will need to run nix flake update in Yubikey-Guide, which is not great. The current approach does not have this problem.

@drduh do you have any thoughts about bundling those gpg config files there, possibly with some scripts to automate making them in sync?

from yubikey-guide.

1. Use nixos-23.11 instead of nixos-23.05, this should also allow replacing hopenpgp-tools hack.

I tried that but the package is still marked as broken in 23.11.

from yubikey-guide.

2. having a versioned github.com:drduh/config is not awesome, because, if the maintainer changes them upstream, someone will need to run nix flake update in Yubikey-Guide, which is not great. The current approach does not have this problem.

Fetching them on-demand makes the flake impure though, right? I don't see much of an issue with having to update it. At least it means the image will work as is (it does today!). So having an explicit update of the config file is much better IMO. Or we embed the file but that is equivalent, right? Both approach require you to touch the flake repository.

from yubikey-guide.

2. having a versioned github.com:drduh/config is not awesome, because, if the maintainer changes them upstream, someone will need to run nix flake update in Yubikey-Guide, which is not great. The current approach does not have this problem.

Fetching them on-demand makes the flake impure though, right? I don't see much of an issue with having to update it. At least it means the image will work as is (it does today!). So having an explicit update of the config file is much better IMO. Or we embed the file but that is equivalent, right? Both approach require you to touch the flake repository.

Eh, flake.lock is not meant to be committed! So this is not an issue, because everyone who tries to use it will get their own fresh copy.

from yubikey-guide.

Really? Okay this is surprising! I am new to the whole nix world and figured it is equivalent to a Cargo.lock or a yarn.lock :)

Without taking this too much off topic: If you don't commit the lock file, how are flakes any more reproducible than normal nix expressions?

from yubikey-guide.

Really? Okay this is surprising! I am new to the whole nix world and figured it is equivalent to a Cargo.lock or a yarn.lock :)

Without taking this too much off topic: If you don't commit the lock file, how are flakes any more reproducible than normal nix expressions?

Functionally it will be the same for the general use.

However, whoever wants to include the file to their repo (and build the same version as their current configuration) will now be able to.

The next possible step is committing the file to the repository and updating the flakes with, say, a github workflow to check that the image actually builds. But that sounds a bit too much now.

from yubikey-guide.

Really? Okay this is surprising! I am new to the whole nix world and figured it is equivalent to a Cargo.lock or a yarn.lock :)
Without taking this too much off topic: If you don't commit the lock file, how are flakes any more reproducible than normal nix expressions?

Functionally it will be the same for the general use.

However, whoever wants to include the file to their repo (and build the same version as their current configuration) will now be able to.

Ah I understand. I guess in this case, my repo (with just the flake in it) is more like a library that is meant to be an input to somebody's flake, right? Said flake would then have a lock-file to track the revisions.

The next possible step is committing the file to the repository

I would very much appreciate if we could move my code (modulo feedback) to this repository.

from yubikey-guide.

Ah I understand. I guess in this case, my repo (with just the flake in it) is more like a library that is meant to be an input to somebody's flake, right? Said flake would then have a lock-file to track the revisions.

Yes

The next possible step is committing the file to the repository

I would very much appreciate if we could move my code (modulo feedback) to this repository.

I'll poke at it and see if hopenpgp-tools can be salvaged (or if they are needed at all?).

I can suggest changes to the readme on how to run this, but that will be a 3-liner I suppose. I think you are the one deserving the credit to open the PR :)

from yubikey-guide.

I can suggest changes to the readme on how to run this, but that will be a 3-liner I suppose. I think you are the one deserving the credit to open the PR :)

Would we just add the flake file to this repository and then suggest in the readme to run it by pointing at it? Something like:

nix build github:drduh/YubiKey-Guide/contrib/nixos-setup-image#nixosConfigurations.yubikeyLive.config.system.build.isoImage

from yubikey-guide.

I can suggest changes to the readme on how to run this, but that will be a 3-liner I suppose. I think you are the one deserving the credit to open the PR :)

Would we just add the flake file to this repository and then suggest in the readme to run it by pointing at it? Something like:

nix build github:drduh/YubiKey-Guide/contrib/nixos-setup-image#nixosConfigurations.yubikeyLive.config.system.build.isoImage

Amazing idea. I just tried

$ nix  build --no-write-lock-file  github:motiejus/YubiKey-Guide/master#nixosConfigurations.yubikeyLive.config.system.build.isoImage

... and it went to SquashFS phase! Did not try booting it yet.

There is one part that's left unclear to me yet: how to replace fetchGit with "whatever is in this flake"? Specifically, this line:

https://github.com/drduh/YubiKey-Guide/compare/master...motiejus:YubiKey-Guide:motiejus-nixos?expand=1#diff-206b9ce276ab5971a2489d75eb1b12999d4bf3843b7988cbe8d687cfde61dea0R190

Once that's resolved, NixOS/nixpkgs#275209 is merged & backported, Yubikey-Guide will be in a much better position with regards to NixOS users. Thanks @thomaseizinger !

from yubikey-guide.

Worth mentioning: if you want to proceed with upstream changes in yubikey-guide, feel free to take everything from my previous comment and don't worry about attribution. Converting this to a flake is the real work that you should get full credit for.

from yubikey-guide.

Just got a reply from Nix folks at Matrix. Here is a diff that creates flake.nix and adjusts README.md: master...motiejus:YubiKey-Guide:master

from yubikey-guide.

I played around with the generated iso a bit. Some comments:

1. The default DE is Gnome, which was unusably slow on qemu. Since the flake no longer gives a choice, I think it's better to default to something lighter like xfce4 or lxde. But I wasn't able to find how to change it. Thoughts?
2. There was nothing on the desktop (there was in the previous yubikey-installer.nix). Or gnome didn't load it by the time I left.

from yubikey-guide.

I took @thomaseizinger 's fork, fixed a few issues and created #411. Works well for me, I would appreciate everyone interested in NixOS live image for it to have a go.

from yubikey-guide.