Support full disk LUKS #550
Comments
|
I have done some experiments using LUKS and wanted to share my experiences: |
|
@schakrava Could we change the title of this issue from:-
We will also need the "cryptsetup" program installed which is available in the current repos. Just noting so it doesn't get missed. |
|
@halemmerich Thanks for your pointers / input / sharing on this and as you found there are a few mechanisms within Rockstor that will require modification to support LUKS encrypted disks. Some work has already been done towards this and my current task involves another by way of issue #1320 "Revise internal use and format of device names". Once that issue is resolved I was hoping to come back to his issue and work through the required changes. Those elements that have been improved in order to more easily accommodate LUKS include longer device names (now 64 chars) and the addition of a generic 'role' field within the Disk's db model. I like the serial as mount point idea by the way, may have to use that. |
|
@phillxnet , I've assigned the issue to you. I am wondering if that will give you the permission to change the title. Could you please try? |
|
@schakrava Thanks, but still no edit button by title. |
|
@schakrava Cheers. |
|
Note to consider the effect of the smartctl calls on LUKS mapped devices ie update smart get_base_device / get_base_device_byid / or get_dev_options to account for LUKS device names so that the base device is passed to smartctl if required. Please update the following forum thread with significant development on this issue: |
|
Please update the following forum thread with significant development on this issue: |
|
Hi!, will this support the following use case?:
It's an usual layout and I'm currently running that on openSUSE Leap 42.1, looking forward to migrate the disks to Rockstor... |
|
Please also update the following forum thread on significant development on this issue: |
|
Please also update the following forum thread on significant development: |
|
In revisiting this issue I think it best if we first tidy up the recently added disk role field which is the intended mechanism to signal the requirement to change the file system access point from that of the raw device to that of it's /dev/mapper LUKS mount point. Once this task is complete we will have a better basis on which to support LUKS mount / device name re-direction in a cleaner fashion. I intend to link the disk role subsystem improvements issue to this issue so that the enhancements in that area can be tracked and to establish the dependency. |
|
I am again working on this issue given it's indicated core dependencies have now been merged. |
|
Update on sub issues found: When installing Rockstor and selecting anaconda's build in encrypt my data option we get the following with 3.8.16-1: which equates to our rockstor_rockstor pool existing in it's own LUKS drive: But there are problems on our Disks page: However things improve some what with the recent changes to disk management in #1622 : So some attention is require here obviously as previous 'special case' treatment for the root partition/drive is now showing it's short comings. I intend to have a look at improving this behaviour as part of this issue. The root cause here is that the installer works by encrypting 2 partitions but we predominantly address disks bar prior special root disk assessment that in this case fails. Given the above points it may be pertinent to initially address password during power on for all LUKS volumes as a stepping stone ie following the installer default /etc/crypttab format of: Where none signifies manual password entry on power up. At a later date this could be enhanced to include keyfile generation and management. This may also fit in better with current btrfs development on partial disk count capabilities as each disk is individually unlocked in turn, however currently no default pool mount is achievable until all members are unlocked. But this 'unlock via Rockstor Web-UI' element would also require some attention on #1547 "insufficient use of btrfs device scan" as currently 'btrfs device scan' is only run on boot and until LUKS encrypted volumes are unlocked they are not visible to the btrfs subsystems as available pool members. |
Also ensure we avoid making changes to custom (non native) crypttab configurations, even during a LUKS config page submit when viewing these settings. Require a config change prior to defaulting to native keyfile creation.
Since we have partnered LUKS format with our existing wipe on this page we should add this key function to the page title.
|
Noting a thread on the linux-btrfs mailing list re strange interplay between systemd and keyfile activated LUKS containers upon subsequent format: |
Previously we had an unused placeholder of dm-name-uuid. Replace with output from: 'cryptsetup status dev-name' as a dict/json. The 'openLUKS' role signifies open LUKS volumes.
When our dual mode LUKS page is viewing an Open LUKS Volume, display the role value which equates to a slightly tailored cyptsetup status dev-name output where the backing device listed is converted to a by-id name.
|
Newly added Open LUKS Volume info table: A little more user facing text to add (as detailed in tasks above) and some more testing and I hope to be at pull request prep / review stage. Note the Open LUKS Volume info page added here also suffer from the same issue as indicated in #1130 for detached devices. Linking here as the two behaviours share the same cause which can be addressed in the referenced issue: ie that of missing name reference due to dynamic renaming of detached devices. |
Plus minor text enhancements for clarity.
Actively used by LUKS additions moving forward.
|
Last minute problem detected, suspect this is related to occasional device name change: |
|
Prior to 'udev trigger' kick we have: |
|
Tasks related to Open LUKS volume format changes affecting block device mapping and udev reporting of both the LUKS container and the consequent open LUKS volume.
After an extended period (ie around 24 minutes in given example) the /dev/dm-* and consequent /dev/mapper/luks- are restored:
|
Add info logging when failing over to 'mount by dev' from 'mount by label' and specify the dev names as we go. Add error logging on missing devices.
|
It appears that the auto generated (by systemd-cryptsetup-generator) systemd service file for each crypto block device (based on it's /etc/crypttab entry if any) in: is what is being auto run whenever we 'wipefs -a' a btrfs formatted Open LUKS volume: results in equivalent observed systemd logging: And we again now have missing /dev/dm-* and /dev/mapper/luks-* entries. |
As our 'source of truth' is /etc/crypttab but systemd generators now abstract the contents to /var/run/systemd/generators we should ensure that systemd re-generates the abstraction in a timely manner.
Less flexible than original but serves our current use. Required as upstream --template option is broken for all input cases.
When a full dev fs exists on an Open LUKS Volume and that fs is wiped via wipefs -a, systemd tears down the entire mapped block device. Re-assert there after by starting the associated generator service if it exists.
Intermittent failure of udev to update fstype, label, and uuid of dev after pool creation (1-2 times in 10) was observed for a luks mapped device. After this udev call no similar failures were observed. Also prior to patch many mount by label fails were observed with consequent fail-over mounts by dev, but with no consequent dev info updates the pool was not recognized by our UI. Where as after this patch no failures to mount by label were observed in the test scenarios. This same treatment has already been applied to adding disks to an existing pool in pr rockstor#1607 commit: 0358560
|
Given our NAS remit we favour headless operation and given LUKS volumes are closed upon wipe we must favour and recommend auto authentication via keyfile. Also add systemd command info for those favouring a non keyfile / command line management approach.
Best we point out "Auto unlock via keyfile" and location of this config with icon repeats to improve affordance and ease first time configuration.
No description provided.
The text was updated successfully, but these errors were encountered: