| 1 |
Rich Freeman wrote: |
| 2 |
> On Sat, Apr 16, 2022 at 6:39 PM Dale <rdalek1967@×××××.com> wrote: |
| 3 |
>> Neil Bothwick wrote: |
| 4 |
>>> Use /dev/disks/by/partlabel/foo or /dev/disks/by-partuuid/bar. |
| 5 |
>>> |
| 6 |
>> That's even more typing than /dev/sdk. Some things I do easily by using |
| 7 |
>> tab completion and all. When mounting, I let fstab remember the UUID |
| 8 |
>> for it. |
| 9 |
> That's what copy/paste is for. How often are you editing your |
| 10 |
> crypttab anyway? This way when you move drives around they still |
| 11 |
> work. |
| 12 |
|
| 13 |
What is crypttab? I type in the command manually. It's what the howtos |
| 14 |
showed. I can't find a crypttab file. This may make things easier. My |
| 15 |
usual names are 8tb, 6tb and pri, short for private. Ran out of other |
| 16 |
names. ROFL |
| 17 |
|
| 18 |
|
| 19 |
> |
| 20 |
>> It's not like UUIDs are made to remember either. |
| 21 |
> blkid is your friend. |
| 22 |
> |
| 23 |
> This is for config files, not random mounting/unmounting. I use the |
| 24 |
> dynamic device nodes all the time if I'm just plugging a drive in and |
| 25 |
> looking at it. However, if I'm going to put it in a config file I use |
| 26 |
> a persistent ID so that I'm not running into breakage anytime things |
| 27 |
> change. |
| 28 |
> |
| 29 |
> When I'm setting it up it is just a few extra seconds to look up the |
| 30 |
> UUID and copy/paste it. When the system randomly breaks I have to go |
| 31 |
> digging through logs and config files to figure out what went wrong. |
| 32 |
> It pays for me to spend a little more time on getting my config right |
| 33 |
> when everything is fresh in my head, because when I'm troubleshooting |
| 34 |
> it will take a little while just to figure out what I did when I set |
| 35 |
> it up. |
| 36 |
> |
| 37 |
> Here is an example of one of my cryptsetup files: |
| 38 |
> cd1 UUID="1cbd5860-3469-41f7-8658-acd83d1957a0" /cd1.key |
| 39 |
> |
| 40 |
> (This is using a random key stored in a file, which works for this |
| 41 |
> particular situation. Obviously the drive is only as secure as that |
| 42 |
> file.) |
| 43 |
> |
| 44 |
> The corresponding drive blkid output is: |
| 45 |
> /dev/sdb1: UUID="1cbd5860-3469-41f7-8658-acd83d1957a0" |
| 46 |
> TYPE="crypto_LUKS" PARTUUID="a4a383a8-24c2-f74b-94d8-ca4ffc366327" |
| 47 |
> |
| 48 |
> Oh, and look at that - the first drive I set up on this system is |
| 49 |
> actually the second drive that got assigned a device name. It was |
| 50 |
> probably /dev/sda1 when I first set it up, and I added another drive |
| 51 |
> since then. |
| 52 |
> |
| 53 |
> The contained drive shows up as: |
| 54 |
> /dev/mapper/cd1: UUID="a2721813-4d10-4f69-ab2a-4beb0d6e95d7" TYPE="ext4" |
| 55 |
> |
| 56 |
> (No LVM here - this is storage for a distributed filesystem so the |
| 57 |
> volume management is effectively above the filesystem level. I can |
| 58 |
> add other drives to the cluster and they're in the pool, and if I want |
| 59 |
> to move data off this drive I can just edit a config file and the data |
| 60 |
> will be moved while online. The encryption is mainly so that if a |
| 61 |
> drive fails I don't have to worry about anybody recovering data from |
| 62 |
> it.) |
| 63 |
> |
| 64 |
|
| 65 |
|
| 66 |
I use passwords here. I just type in sdk1 and it worked before this |
| 67 |
drive move. I never tried to go any further than the howtos I found |
| 68 |
about using cryptsetup. No clue on the file. I don't see one here and |
| 69 |
don't recall reading about it either. Gonna google on that a bit. |
| 70 |
|
| 71 |
Interesting. |
| 72 |
|
| 73 |
Dale |
| 74 |
|
| 75 |
:-) :-) |
Archives