yeah but from a University IT Admin standpoint NixOS would just be so much easier to maintain and set up. you literally would just need one config file to slap on all the machines. Install the OS, clone the config, rebuild, walk away and go to the next computer. Program causing issues and needs to be removed? cool edit the config, push it to the repo, clone it to all the machines, rebuild.
Install the OS, clone the config, rebuild, walk away and go to the next computer.
Honestly, I’d automate it to be even fewer operations. The Windows process is already down to only four keystrokes, and three of them are just to boot into PXE. The fourth is just a pause to make sure every computer has booted into Clonezilla (Debian preloaded with the cloning software and my own scripts, pulled from a TFTP server) before they start pulling the Windows image and the network becomes saturated.
If it ever comes to pass, there will be an extensive evaluation to determine which tool is best suited for the job and the environment. The Prime Directive applies: we must not disrupt classes that are in progress or about to start unless they specifically ask for something.
Support for atomic updates is one feature that I won’t compromise on, and while Ansible will definitely be part of the toolkit (on that note: fuck WinRM, all my homies hate WinRM), its idempotent model on its own is not enough to guarantee disruption-free deployments. If the process fails for any reason, the system must roll back to its last functional state. I don’t know if Nix can do that, but when it becomes relevant (so probably never in my professional capacity), I will find the right tool.
Yes, and that is one of the tools that would be evaluated. My immediate problem is that it requires a working OS to rollback to the last filesystem snapshot if the configuration change (which is still not atomic) is interrupted.
The area where filesystem-level snapshots would be amazing is the /home partition, whenever a teacher asks the computer to be cleaned before an exam.
maybe the snapshot could be rolled back by a PXE bootable system. but for the second part, btrfs can do snapshots per subvolume, so if you could create a subvolume on user creation that could work
I personally would use Ansible over Nix since Ansible is way more proven
yeah but from a University IT Admin standpoint NixOS would just be so much easier to maintain and set up. you literally would just need one config file to slap on all the machines. Install the OS, clone the config, rebuild, walk away and go to the next computer. Program causing issues and needs to be removed? cool edit the config, push it to the repo, clone it to all the machines, rebuild.
I don’t know of any organization using it though
Don’t reinvent the wheel. Ansible is well proven and works on many systems.
You also could use Fog
You would just be cloning the 1 install anyway.
Honestly, I’d automate it to be even fewer operations. The Windows process is already down to only four keystrokes, and three of them are just to boot into PXE. The fourth is just a pause to make sure every computer has booted into Clonezilla (Debian preloaded with the cloning software and my own scripts, pulled from a TFTP server) before they start pulling the Windows image and the network becomes saturated.
If it ever comes to pass, there will be an extensive evaluation to determine which tool is best suited for the job and the environment. The Prime Directive applies: we must not disrupt classes that are in progress or about to start unless they specifically ask for something.
Support for atomic updates is one feature that I won’t compromise on, and while Ansible will definitely be part of the toolkit (on that note: fuck WinRM, all my homies hate WinRM), its idempotent model on its own is not enough to guarantee disruption-free deployments. If the process fails for any reason, the system must roll back to its last functional state. I don’t know if Nix can do that, but when it becomes relevant (so probably never in my professional capacity), I will find the right tool.
(for the record, that is not my downvote)
Btrfs and snapshots could help with atomicity, did you consider that?
Yes, and that is one of the tools that would be evaluated. My immediate problem is that it requires a working OS to rollback to the last filesystem snapshot if the configuration change (which is still not atomic) is interrupted.
The area where filesystem-level snapshots would be amazing is the
/homepartition, whenever a teacher asks the computer to be cleaned before an exam.maybe the snapshot could be rolled back by a PXE bootable system. but for the second part, btrfs can do snapshots per subvolume, so if you could create a subvolume on user creation that could work