3 ms·
You've discussed why a zpool account has a relatively high minimum in the past [1]. Basically because you need a persistent isolated vm/bhyve with sshd listenin
by infogulch 4y ago
You've discussed why a zpool account has a relatively high minimum in the past [1]. Basically because you need a persistent isolated vm/bhyve with sshd listening on its own ip and separate zfs and zpool for each customer.
It's still fuzzy to me specifically why a dedicated 'vm' is necessary. You don't need a dedicated ssh ip for normal 'shell' accounts, and certainly you still provide security and privacy for these customers. Is it because zfs doesn't have fine-grained permissions to allow doing zfs send/recv actions on one's own datasets/volumes without also giving access to other customers' data? Or is it because send/recv workloads just consume more compute resources in general?
[1]: https://news.ycombinator.com/item?id=27994369#28000100 https://news.ycombinator.com/item?id=27994369#28000100
- rsync 4y agoI myself am still fuzzy as to why we need a VM but it is, indeed, due to the permissions that ZFS requires to do a 'zfs destroy' ... which you need in order to manage your own snapshots. So, basically, you need to be root to fully manage your own zpool ... and if you need to be root, you need to be in a VM. In our case, we use bhyve and we have had very good success. We have this on very good authority - Allan Jude of Klara Systems has helped us audit the entire setup and there is not, unfortunately, a lighter way to do it.
- infogulch 4y agoThank you for clarifying! From zfs-allow.8 docs Example 2 [1] it looks like it should be possible, but I guess there are important details omitted from that document that make such a design nonviable in your case. I'm glad to hear that you are using system designs vetted by zfs experts. [1]: https://openzfs.github.io/openzfs-docs/man/8/zfs-allow.8.html#EXAMPLES https://openzfs.github.io/openzfs-docs/man/8/zfs-allow.8.htm...