On 04/10/2017 08:28 PM, Robert Nichols wrote: > On 04/10/2017 08:25 AM, Milan Broz wrote: >> On 04/10/2017 03:07 PM, 7heo wrote: >>> Hello all, >>> >>> I have a question regarding the deported headers in LUKS, and how >>> it can be used to simplify the setup of RAID over LUKS: >>> >>> The current way to automatically unlock all the drives used in a >>> Raid array seems to be to add the same key to all the drives in >>> the array. >>> >>> However that doesn't work with detached headers for obvious >>> reasons. The detached headers can apparently be used on any >>> number of devices/files at the same time, with one problem: they >>> all have the same UUID. I tried using the --uuid flag with >>> luksOpen without success. >> >> You cannot change UUID for activated LUKS device, UUID must match >> the header (otherwise libcryptsetup cannot handle many functions). > > No one is asking to change the UUID of an activated LUKS device. > Let's approach this in a different way: > > Is there any need for the detached header to remain available after > the LUKS device has been activated? That is, could I have the > detached header on a separate, removable device and, after activating > the LUKS device via that header, unmount that separate device and > lock it away in a safe? Would that interfere with access to the > activated device or interfere with a subsequent luksClose operation? Without detached header only some command will work (status will return only part of information) but luksClose will work always (intentionally - it is expected that user can close device without detached header). > I don't see any reason why it should, since "--header" is not > mentioned as an option for luksClose (and its aliases). Obviously, no > _other_ LUKS operation would be possible without that header. yes. > > When I try this in CentOS 7 (cryptsetup-1.7.2-1.el7) it seems to work > just fine. No, I didn't try any of the "not possible" operations. Cryptsetup status should print active device state, other commands requires LUKS header to operate. > Given that the above is possible, then why could one not modify the > UUID in that detached header and use it for a different device, given > that one accepts that luksClose is the only possible LUKS operation > on that orphaned active device? But that's exactly what I suggested :-) Copy header, change UUID in it, activate another device. In fact, I am actually not sure what was the initial problem now... The UUID is needed when you operate with device with signature (so it must have LUKS header). Here duplicates can cause problems. If there is no LUKS header on device (detached header), then there is no duplicity. And the activated device-mapper UUID is something else - it is constructed as LUKS prefix plus LUKS header UUID plus activated name (then cannot be the same). So you should be able to activate several devices with detached header even with the same UUID. Perhaps some script is just confused by this but it is possible... (Try it and check dmsetup info -c - you should see the UUID there.) IOW you can do: cryptsetup luksOpen /dev/device1 name1 --header <detached_LUKS_header> cryptsetup luksOpen /dev/device2 name2 --header <detached_LUKS_header> ... cryptsetup luksClose name1 cryptsetup luksClose name2 and it will work. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
