That’s why I proposed to integrate with Tailscale. Or we could just stick to giving the client a URL to contact and open a websocket or something like that. Then the sysadmin can figure out firewall punching and NAT traversal how they see fit, with Tailscale, a VPN or any other solution they already have.
You can look and parse the NixOS config, or use nix-tree. The first option may be harder to implement or incomplete, the latter exposes every derivation installed by the generation and doesn’t differenciate between applications and libraries (which may or may not be a good thing).
Depends on what compliance entails, but I would assume it is possible.
Yes.
That’s tricky. There’s nothing that prevents you from having 1000 accounts on a NixOS system, but I don’t know how well that would scale, storage-wise and build-time-wise. This requires more research.
I guess we and/or the sysadmin would have the choice ?
I tried it a bit ago, but the lack of documentation is really bad. I can’t really grasp what the project is about.
I guess that enrollment would be pretty manual at first: create the NixOS host like usual, switch to the new configuration, add the client’s hardware config and public key in the config, push and switch again, etc. I don’t know how far automated NixOS provision goes, but we probably can’t automate it tooo much.