On Wed, Aug 16, 2023 at 10:10:25AM +0200, Nicolas Graves wrote: > On 2023-08-14 16:41, Nicolas Graves wrote: > > >> - either not snapshotting the rootfs / at all, with the hypothesis that > >> we get it back entirely from config files. Is that possible ? Is there > >> information in / (I think of /etc in particular) that is saved, not > >> temporary and not managed by guix system that would justify that we > >> want to snapshot / at all? > >> This would allow to simply care about only a few "user data" > >> directories, and be sure to not miss anything when there's a need to > >> restore the state. > >> > >> I can't find easily a case of successful use of the second > >> configuration, but would be glad to find one, as well as some discussion > >> about what would be a recommended way to secure the state beyond > >> dotfiles. > > > > I've found some equivalent information on the NixOS side here : > > https://nixos.wiki/wiki/Impermanence > > > > Some (rare) directories indeed seem that would better be saved because > > their information is useful for the system, in the case of NixOS, it > > seems to be "/etc/nixos", "/etc/NetworkManager" (for system > > connections), "/var/log", "/var/lib". > > Thank you all for your answers! > > I actually managed to replicate the impermanence functionality by > creating btrfs subvolumes for "/etc/guix" "/etc/NetworkManager" > "/var/log" "/var/lib" "/var/guix" and 4 light patches (I'm currently > trying to remove one I think might be not necessary, will send them > here. They basically amount to create directories when they might not be > present or allowing the root "none" to pass to the mount call).
With impermanence I'd save /etc/ssh so you don't have to regenerate keys each time. Or perhaps look into SSH Certificate Authority if you want to go crazy with it. > This allows me to start with a tmpfs rootfs, and the only annoying thing > I experience not is that the root password is not set (the account > password is set though, since we can include that in the definition of > an os). Boot time is a bit higher since /etc/machine-id and some other > files have to be recreated, but that's not really noticeable. > > I don't know if I'll stick to this "impermanent" mode, but at least this > gives me the right information about what directories are worth > considering for snapshots (doesn't mean they are worth snapshotting), > and what a "precise" btrfs layout on Guix would have to consider. > > I guess it's possible to do the same with my home as well (thus only > saving actual data and not consecutive linking metadata), but that might > require some more time and fine-grained applications considerations. > > @Efraim : I don't have a /etc/guix/machines.scm to save (I don't have an > offloading deamon set for now), IIUC this means I could be doing as good > without "/etc/guix". What are the signing keys used for? The signing keys are used when offloading derivations to other machines. There's an example usage, with saving them for later, in the hurd-vm-service-type and the secret-root (by default in /etc/childhurd). > One weakness from this impermanence feature is that it's actually > application-dependent. For guix-system it's not very damaging (except if > we want very low-level optimizations, like setting nodatacow on > subvolumes with databases etc), but for guix-home, it makes things much > more difficult. @Andrew Tropin : maybe that's something we could in RDE in > a state-btrfs in (gnu home-services state) if we find a way to migrate > directories to subvolumes safely and reproducibly. > > -- > Best regards, > Nicolas Graves -- Efraim Flashner <efr...@flashner.co.il> רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
