1 |
Frank Steinmetzger wrote: |
2 |
> Am Wed, Sep 14, 2022 at 08:55:26AM -0500 schrieb Dale: |
3 |
> |
4 |
>> I see the point but wasn't aware there was more than one way to do it |
5 |
>> with cryptsetup. It seems there is several options for this. I was |
6 |
>> pretty sure LVM was on bottom and mentioned it in my original post. |
7 |
> Indeed you did and it confused me at first. Then I gave it some thought and |
8 |
> concluded: why not? |
9 |
> |
10 |
> You do it like so: |
11 |
> Block device --, |
12 |
> Block device --+-- LVM --- LUKS --- File system |
13 |
> Block device --' |
14 |
> |
15 |
>> After reading your post, I got to wondering, did I do this the right |
16 |
>> way? |
17 |
> Your advantage: only one LUKS header to take care of. That means no extra |
18 |
> crypt management when adding or removing disks, except for resizing the |
19 |
> crypt volume. And there is only a single place of storage for your keys (in |
20 |
> case you ever need to change them). |
21 |
> |
22 |
> I’m not sure whether it’s the right™ way. It is *one* way. Perhaps there are |
23 |
> drawbacks that I can’t think of right now. |
24 |
|
25 |
By right way, I was talking about the way I moved things around. It |
26 |
seems to be working so I guess I did it the right way, for this setup |
27 |
anyway. I might have broke things if it was set up some other way. |
28 |
|
29 |
|
30 |
> |
31 |
> I would typically have done: |
32 |
> Block device --- LUKS --, |
33 |
> Block device --- LUKS --+-- LVM --- File system |
34 |
> Block device --- LUKS --' |
35 |
> |
36 |
> That’s how my NAS works at the moment (with ZFS instead of LVM + filesystem). |
37 |
> But that’s because ZFS didn’t have built-in encryption when I set it up some |
38 |
> years ago. These days I would do: |
39 |
> |
40 |
> Block device --, |
41 |
> Block device --+-- ZFS |
42 |
> Block device --' |
43 |
> |
44 |
> That’s it. :D Encryption, disk arrays and file system all in one shop. |
45 |
> |
46 |
>> So, I started looking to see how to tell for sure. I used several |
47 |
>> LVM type commands but didn't see anything that I recognized anyway. |
48 |
>> Keep in mind, I'm not real sure what I'm looking for either. Then I ran |
49 |
>> lsblk -f and found a clue that I've never noticed before. |
50 |
>> |
51 |
>> |
52 |
>> sdd |
53 |
>> |
54 |
>> └─sdd1 LVM2_member LVM2 001 |
55 |
>> pVnP2i-sj48-3co9-nJpa-9tQr-08pa-9JqASR |
56 |
>> └─crypt-crypt crypto_LUKS 2 |
57 |
>> 6e884aae-9377-49ef-a602-e13cba89a377 |
58 |
>> └─crypt ext4 1.0 crypt |
59 |
>> 76653316-329f-4747-8fed-fc9b1723bd14 3.5T 79% |
60 |
>> /home/dale/Desktop/Crypt |
61 |
>> |
62 |
>> |
63 |
>> I know that is going to be line wrapped and mess up things |
64 |
> You could have redacted the long UUIDs which aren’t relavant anyways. I write my mail in mutt and vim, thus I can rewrap paragraphs individually and at will. That way I can paint ASCII art, paste over-long console output or write one-line paragraphs like this one. ;-) |
65 |
|
66 |
I started to but thought it would cause yet another issue. ROFL |
67 |
|
68 |
>> but the part I noticed was the drive partition "sdd1" and "LVM2 member". |
69 |
>> On top of that is crypto. So, LVM is on bottom. If that is the case, my |
70 |
>> pvmove command should be moving what I think you call "raw data", doesn't |
71 |
>> matter if it is encrypted or not, right? |
72 |
> Yup. This kind of layering is one of the big beauty of Linux for me. It’s |
73 |
> all interchangable and layer X doesn’t care what layer X+1 is doing and vice |
74 |
> versa. |
75 |
> |
76 |
>> Just in case it matters, could I have done everything but the file system |
77 |
>> resize while it was closed? It seems it is basically encrypted on the |
78 |
>> layer just below the file system to me. |
79 |
> I think so, yes. |
80 |
> |
81 |
> |
82 |
> PS.: All your LVM threads made me embrace LVM on my PC when I recently |
83 |
> switched it from SATA to NVMe. And because after many years of ignorance, I |
84 |
> finally had an actual use case: my laptop’s root partition became too small |
85 |
> and I had to give it some space from the data partition. In my early Gentoo |
86 |
> years I didn’t use an initrd and didn’t want to, so LVM was never an option. |
87 |
> But when I set up the (then brand-new) laptop, I used Sakaki’s howto for |
88 |
> full-disk encryption, which used an initrd + LVM anyways. This saved the |
89 |
> SSD from a full reformat and rewrite. |
90 |
> |
91 |
|
92 |
|
93 |
I have to say, before I started using LVM, it was very hard to change |
94 |
storage up. As it is, /boot and / are on a traditional partition, no |
95 |
LVM. Everything else is on LVM. At the time, I was avoiding the init |
96 |
thingy. Since I have /usr separate, and /var, I ended up having to use |
97 |
one anyway but dracut came along. Only gave me a problem once so |
98 |
overall, pretty good. |
99 |
|
100 |
I'm not sure who got me started on LVM. Could be Alan who isn't on this |
101 |
list anymore, Neil or someone else. It's been a long long time ago. I |
102 |
tell you what tho, it has made things a LOT easier. I've read about |
103 |
btrfs(sp?). It could be the next big thing but I'll likely stick with |
104 |
LVM as long as it works for me. ZFS seems to be getting popular too. |
105 |
I'm not sure who is winning the race between them tho. I think they all |
106 |
each have their use case. |
107 |
|
108 |
My biggest thing, I couldn't find hardly anything to do that with it |
109 |
encrypted and what I did find was not very clear. I couldn't imagine it |
110 |
not being doable tho. After all, this is Linux. :-) |
111 |
|
112 |
I'm just glad it worked out and if anyone runs up on this thread, this |
113 |
additional info will help someone else. Now, people can see what the |
114 |
setup is. See if it matches what they have or not. |
115 |
|
116 |
Dale |
117 |
|
118 |
:-) :-) |
119 |
|
120 |
P. S. My second move is almost 90% done with pvmove. |