-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to prevent unmounting and exporting ZFS pool #278
Comments
I have the same use case. It's actually in disko here: haven't dug in yet to see how it could be bypassed. |
In the nixos-anywhere.sh at the end it also exports all ZFS pool, I don't think the Disko destroy script is currently used for that as that presumably deletes partitions? |
yeah i think I jumped the gun before I had to head out. I looked at that script and it tests for zpool command and does that recurive unmount. I'm on btrfs though so I dont think that's my issue. I decided I'm going to pre-provision fresh ssh keys and put them in sops before running nixos-anywhere with then the initial build will work and I won't have to come back after to update my secrets, rebuild, and redeploy. |
Yes |
Isn't it insecure to create secrets on one machine and copy them to another? |
Not if done correctly. If secrets are clear text and written to files, they should be written correctly permissioned to tmpfs (ram), or encrypted storage, network copied over a secure transport (ssh), and stored similarly on the remote. This isnt automated yet, and cloud-init is overwriting the keys I copy with |
With sops-nix, your local user can decrypt your servers secrets already, so also having the decryption key, doesn't change a lot. |
My personal preference these days is to generate just the age key for use in sops and have the ssh key just be a secret like everything else. Than you can rotate both independently and also deploy secrets to machines without an ssh service running. In clan we have then a facts module generating the actual ssh key for each host automatically: https://git.clan.lol/clan/clan-core/src/commit/0f95bfd279b12865382f0ffd3459086090217fa1/clanModules/sshd/default.nix#L22 and store the results back into sops-nix automatically. In clan we also wired up update and install commands in a way that they automatically provision secrets. For nixos-anywhere, we also use the --extra-files argument: https://git.clan.lol/clan/clan-core/src/commit/0f95bfd279b12865382f0ffd3459086090217fa1/pkgs/clan-cli/clan_cli/machines/install.py#L60 This implementation also uses a temporary directory as mentioned by @sedlund |
I have a use-case in which I have a persistent directory (with contents) that must be present on the host before the reboot happens. The Preventing unmounting would make this workflow possible/easy, by extracting the archive into |
I just tried to use nixos-anywhere for a new server and noticed it now unmounts and exports the ZFS pool.
I need these to stay mounted though so that I can copy over the SSH keys for SOPS.
An option to prevent that would be nice, like no-reboot, maybe no-u(n)mount?
The text was updated successfully, but these errors were encountered: