[dm-crypt] persistent naming: add ID in addition to UUID

[dm-crypt] persistent naming: add ID in addition to UUID

[ilf]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Cryptsetup currently allows "LUKS UUID in the format UUID=<uuid>. 
Translation to real device name uses symlinks in /dev/disk/by-uuid 
directory", as quoted from man/cryptsetup.8.

Is there a reason why other persistent block device naming schemes are 
not supported? I for one would love to use by-id, "a unique name 
depending on the hardware serial number": 
https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-id_and_by-path

I am aware of the difference addressing hardware and LUKS header, but in 
my use case, I actually *do* want to address hardware in crypttab at al.

Thanks, and keep up the good work!

-- 
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
		-- Eine Initiative des Bundesamtes für Tastaturbenutzung

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [dm-crypt] persistent naming: add ID in addition to UUID

[Sven Eschenberg]

On Sun, July 26, 2015 19:02, ilf wrote:
> Cryptsetup currently allows "LUKS UUID in the format UUID=<uuid>.
> Translation to real device name uses symlinks in /dev/disk/by-uuid
> directory", as quoted from man/cryptsetup.8.
>
> Is there a reason why other persistent block device naming schemes are
> not supported? I for one would love to use by-id, "a unique name
> depending on the hardware serial number":
> https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-id_and_by-path
>
> I am aware of the difference addressing hardware and LUKS header, but in
> my use case, I actually *do* want to address hardware in crypttab at al.
>
Since you want to use crypttab anyway, is there any particular reason not
to use /dev/disk/by-id/<identifier>? As UUID=<uuid> needs proper symlinks
anyway, it is rather a handy shorthand at the commandline.

> Thanks, and keep up the good work!
>
> --
> ilf
>

-Sven

Re: [dm-crypt] persistent naming: add ID in addition to UUID

[ilf]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Sven Eschenberg:
> Since you want to use crypttab anyway, is there any particular reason not 
> to use /dev/disk/by-id/<identifier>?

You are comlpetely right, that works and I should probably use that.

> As UUID=<uuid> needs proper symlinks anyway, it is rather a handy 
> shorthand at the commandline.

Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the 
UUID is supported as well, using UUID=<luks_uuid>". So adding an ID= 
option would make this more consistent.

-- 
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
		-- Eine Initiative des Bundesamtes für Tastaturbenutzung

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [dm-crypt] persistent naming: add ID in addition to UUID

[Milan Broz]

On 07/27/2015 09:26 PM, ilf wrote:
> Sven Eschenberg:
>> Since you want to use crypttab anyway, is there any particular reason not 
>> to use /dev/disk/by-id/<identifier>?
> 
> You are comlpetely right, that works and I should probably use that.
> 
>> As UUID=<uuid> needs proper symlinks anyway, it is rather a handy 
>> shorthand at the commandline.
> 
> Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the 
> UUID is supported as well, using UUID=<luks_uuid>". So adding an ID= 
> option would make this more consistent.

Actually I added UUID=<..> to cryptsetup to mainly easily implement
scripts doing the similar action as fstab/crypttab UUID= mount.
(fstab allows LABEL and UUID but not ID; also LUKS has no label)

Not sure if adding ID is worth to do this, it is really just
shortcut to udev symlink. Note that UUID is read from header and has
always the same format.

ID can be crazy combination of characters, sometimes even dynamic
(not everything is hw-serial based, see DM devices for example).
(I remember several bugs for multipath/SCSI devices where hw-based ID contains
binary data and must be properly escaped for symlink name...)

Milan

Re: [dm-crypt] persistent naming: add ID in addition to UUID

[Sven Eschenberg]

On Mon, July 27, 2015 21:49, Milan Broz wrote:
> On 07/27/2015 09:26 PM, ilf wrote:
>> Sven Eschenberg:
>>> Since you want to use crypttab anyway, is there any particular reason
>>> not
>>> to use /dev/disk/by-id/<identifier>?
>>
>> You are comlpetely right, that works and I should probably use that.
>>
>>> As UUID=<uuid> needs proper symlinks anyway, it is rather a handy
>>> shorthand at the commandline.
>>
>> Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the
>> UUID is supported as well, using UUID=<luks_uuid>". So adding an ID=
>> option would make this more consistent.
>
> Actually I added UUID=<..> to cryptsetup to mainly easily implement
> scripts doing the similar action as fstab/crypttab UUID= mount.
> (fstab allows LABEL and UUID but not ID; also LUKS has no label)
>

Sorry to correct you here, but fstab supports all libblkid properties,
which are amongst UUID and LABEL some more (PARTLABEL and PARTUUID for GPT
work quite well ;-) ). And even UUID and LABEL need libblkid support,
otherwise they won't work in fstab.

> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Regards

-Sven

Re: [dm-crypt] persistent naming: add ID in addition to UUID

[Sven Eschenberg]

On Mon, July 27, 2015 21:26, ilf wrote:
> Sven Eschenberg:
>> Since you want to use crypttab anyway, is there any particular reason
>> not
>> to use /dev/disk/by-id/<identifier>?
>
> You are comlpetely right, that works and I should probably use that.
>
>> As UUID=<uuid> needs proper symlinks anyway, it is rather a handy
>> shorthand at the commandline.
>
> Well, the man-page for crypttab(5) in Debian and Derivatives sais, "the
> UUID is supported as well, using UUID=<luks_uuid>". So adding an ID=
> option would make this more consistent.

Still, if the man page is correct, cryptsetup only uses the symlink, so
once your inode manager screws up, there's no gain in not using the
symlink directly. In contrast /etc/fstab (mount and friends) supports UUID
(and some more) by exploiting libblkid functionality, thus they do not
depend on proper inode creation. In this case it does make a whole lot of
sende to use UUID=<UUID> and friends.

>
> --
> ilf
>
> Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
> 		-- Eine Initiative des Bundesamtes für Tastaturbenutzung

Reagrds

-Sven