From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Mon, 10 Apr 2017 20:43:24 +0200 (CEST) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cxe2x-0003RU-OW for dm-crypt@saout.de; Mon, 10 Apr 2017 20:28:15 +0200 From: Robert Nichols Date: Mon, 10 Apr 2017 13:28:14 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: Re: [dm-crypt] Detached headers, multiple drives and UUIDs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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? 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. 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. 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? -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.