Problem/Justification
(What is the problem you are trying to solve with this feature/improvement or why should it be considered?)
Absence of dm_mod prevents mounting LUKS encrypted drives for offline backup
Impact
(How is this feature going to impact all TrueNAS users? What are the benefits and advantages? Are there disadvantages?)
Impact: for normal user probably none
Benefits: you’re be able to mount LUKS drives for offline backups for example so you can have encrypted backup drives just laying anywhere
Disadvantages: none from what I can tell
User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)
User want’s to have offline backups that are encrypted and doesn’t want to write scripts for making gpg encrypted tars, so he makes a LUKS encrypted drive, which he mounts and rsyncs his backups there. Command line would be fine, but for the more average not so technical user who doesn’t want to mess with commandline a GUI solution would be nice.
I know, that TrueNAS is built around ZFS and I really like it, but it would be nice to have more options for encrypted offline backups just because of backward compatibility with legacy systems or just systems without zfs support. Given, that there are all nessesary tools present for LUKS except of that one kernel module…
Except that LUKS without a supported non-ZFS file system, would be less useful.
As an example, say iX starts supporting LUKS on SCALE. You start using EXT4 on top of LUKS. At some future date iX removes EXT4, (regardless of why). And since it was never an official supported file system, you have to jump through hoops to restore functionality.
What I am trying to say, is that the only supported file system at present is ZFS.
If you want X, Y or Z, (aka EXT2/3/4, XFS, FAT, or exFAT), make that clear TOO.
The targeted clients for TrueNAS, SCALE or Core, are Enterprise Data Center users. They want / need high reliability not extreme customizations. The result of this is more tightening down of SCALE's OS. For example, making certain mount points R/O, (Read Only) and not allowing out of normal update package installs.
iX did start work on a developer mode that does allow MANY things. However, the converse to that is any bugs would have to be repeated on a “clean” install to be sure that user did not corrupt their OS. And if developer mode ends up being required for the user, they can’t easily get assistance with bugs.
Ah I see, ye, I’d use ext4, but given that iX want’s to target enterprise then in that context it doesn’t make much sense. But it would be nice to have an option at least for setting up offline backups on single disks with encrypted zfs in GUI, so small businesses (my case) could do it.
On a tangent, I’m experiencing some issues with ACLs because it looks like TrueNAS is not built for it the way I use it (migrated from legacy fedora machine with a mess of ACLs)
Nothing prevents creating a ZFS encrypted pool on a single drive in the GUI, replicating to it, and then exporting the single drive pool.
The offline backup is readable by any system which can mount ZFS.
One thing to consider is that ZFS always encrypts per dataset. Even though the encryption root can be the same, a different underlying encryption key is always used. It is randomly generated when creating an encrypted dataset and cannot be changed. The user-facing key just allows ZFS to access that underlying key and makes it possible to easily change the user key (per dataset) without needing to re-encrypt it.
However, this means block cloning between encrypted datasets is impossible, as the underlying encryption key cannot be manually set.
With block cloning, you can instantly copy and/or move files between datasets on the same pool. This is not possible with encrypted datasets.*
With LUKS, the entire hard drive is encrypted as-is (and dataset names would be hidden, which can contain information like names).
This would make block cloning possible with encryption.
I’m not saying we really need LUKS in TrueNAS, just wanted to give my thoughts about a possible advantage.
*Note: Block cloning is only possible between encrypted datasets that share the same underlying encryption key, so only for snapshots, the original dataset, and clones of snapshots.
You can indeed snapshot an empty encrypted dataset, clone it to multiple datasets, and make block cloning work between those encrypted datasets, as they now share the same underlying encryption key. That’s not a good solution though due to multiple reasons though…
