Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Adding new volumes to a LVM lukscrypt setup
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
abduct
Apprentice
Apprentice


Joined: 19 Mar 2015
Posts: 203

PostPosted: Sun Mar 18, 2018 7:06 pm    Post subject: Adding new volumes to a LVM lukscrypt setup Reply with quote

So I was following this article: https://wiki.gentoo.org/wiki/Full_Disk_Encryption_From_Scratch_Simplified#Configure_fstab and I was wondering if it was possible to add another drive to the LVM which unlocks under the same passphrase.

For instance I setup my main HDD as the article has, but I have a 32gb cache drive which I want to add to the LVM. My main drive is SDA while the 32gb cache drive is SDB.

I would like to partition it so that I have 4GB on the cache drive as SWAP and then the remaining size as additional storage which will be mounted for a VM (passing the unlocked /dev/mapper/ to QEMU if possible to allow for direct read/writes without having say a cow2 file.)

I want this cache drive encrypted
I want this cache drive to be unlocked with the same passphrase as my main drive at the same time at boot.

Is this possible?

Thanks.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13512

PostPosted: Sun Mar 18, 2018 7:52 pm    Post subject: Reply with quote

The technically correct, but practically useless answer is that yes, of course you can reuse the same passphrase on multiple drives. You just need to enter it once for each drive you want to unlock.

The practical answer is that you could do some tricks to capture the passphrase at entry and reuse it automatically, or you could avoid the whole problem by not combining the two drives in one LVM group. Nothing in your post explains why both drives need to be part of one LVM group. You could easily have a separate LUKS+LVM on each drive, with the limitation that you cannot span a logical volume across distinct LVM groups. If you don't make them part of one LVM, then you could store the unlock key for sdb in a filesystem on sda.
Back to top
View user's profile Send private message
abduct
Apprentice
Apprentice


Joined: 19 Mar 2015
Posts: 203

PostPosted: Sun Mar 18, 2018 8:13 pm    Post subject: Reply with quote

I simply didn't want to type two passphrases to unlock all my drives.

Although now that I think about it a bit more perhaps its not so bad.

How can I shrink my main volume that was created with `lvcreate -l 100%FREE -n home vg0' so that I can create a swap partition on that LVM.

Afterwards on my cache drive I will use the entire thing for an encrypted VM container that I will unlock when I want to use it.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13512

PostPosted: Sun Mar 18, 2018 8:47 pm    Post subject: Reply with quote

  • Make and verify a backup of all important data in the relevant LVM group. This conversion is safe if you do it right, but can cause data loss if you do it wrong.
  • Use the appropriate filesystem-specific tool (such as resize2fs for extN filesystems) to shrink the filesystem on /dev/mapper/vg0-home to create an unused area at the end of that block device. Some filesystems support shrinking in-place if unmounted. If not, you may need to remake the filesystem with a smaller size, which would discard all your data as a side effect.
  • Unmount the filesystem (if not already unmounted).
  • Verify filesystem integrity using fsck. If it does not come back clean, stop and ask for help.
  • Use LVM commands to shrink the block device /dev/mapper/vg0-home. Now the unused space from above is in LVM free space, rather than being allocated from an LVM perspective but outside the filesystem.
  • Verify filesystem integrity using fsck, again. This verifies that the filesystem does not exceed the bounds of its new smaller block device. If it does exceed those bounds, the filesystem cannot be used (until the device is grown) and creating any new volumes risks data loss. If the filesystem exceeds bounds, undo the LVM resize step. If you are unsure how to do this, stop and ask for help. This is the stage at which the risk of data loss is greatest.
  • Create new volume(s) as appropriate.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2968
Location: Germany

PostPosted: Sun Mar 18, 2018 11:56 pm    Post subject: Reply with quote

Hu wrote:
The practical answer is that you could do some tricks to capture the passphrase at entry and reuse it automatically


systemd actually has that feature, but not even every systemd distro uses it. multiple luks containers at boot is still a bit exotic, I guess.

I do it with LUKS encrypted keyfiles. I give the passphrase for the keys, and the keys in turn are used to open a bunch of containers. ( https://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile )

Basically it depends on your flavor of initramfs what is the best / easiest method to open multiple containers. Some of them can be convinced to do so without code changes. The condition is that there already is some form of multiple container handling at all (e.g. based on a crypttab).

With a cache drive, the problem is again different. If you encrypt the cache drive on its own, anything that is cached has to be re-encrypted. If you put the cache underneath the LUKS layer, it will cache the already-encrypted data.

I do not have personal experiences with caches (I prefer to use SSDs directly) so I do not know which is the better option.
Back to top
View user's profile Send private message
abduct
Apprentice
Apprentice


Joined: 19 Mar 2015
Posts: 203

PostPosted: Wed Mar 21, 2018 3:09 am    Post subject: Reply with quote

Hu wrote:
  • Make and verify a backup of all important data in the relevant LVM group. This conversion is safe if you do it right, but can cause data loss if you do it wrong.
  • Use the appropriate filesystem-specific tool (such as resize2fs for extN filesystems) to shrink the filesystem on /dev/mapper/vg0-home to create an unused area at the end of that block device. Some filesystems support shrinking in-place if unmounted. If not, you may need to remake the filesystem with a smaller size, which would discard all your data as a side effect.
  • Unmount the filesystem (if not already unmounted).
  • Verify filesystem integrity using fsck. If it does not come back clean, stop and ask for help.
  • Use LVM commands to shrink the block device /dev/mapper/vg0-home. Now the unused space from above is in LVM free space, rather than being allocated from an LVM perspective but outside the filesystem.
  • Verify filesystem integrity using fsck, again. This verifies that the filesystem does not exceed the bounds of its new smaller block device. If it does exceed those bounds, the filesystem cannot be used (until the device is grown) and creating any new volumes risks data loss. If the filesystem exceeds bounds, undo the LVM resize step. If you are unsure how to do this, stop and ask for help. This is the stage at which the risk of data loss is greatest.
  • Create new volume(s) as appropriate.


Thanks for the reply.

I successfully shrunk my home partition and created a swap partition inside the LVM.

I decided that I will just encrypt the entire 32gb msata drive as a VM drive that qemu will use.

My work flow was:

Code:
# Reboot into system rescue CD so nothing is mounted to be safe
cryptsetup luksOpen /dev/sda3 lvm # Unlock the LVM volume
lvscan # To see which partitions were created, their paths, and how large they were
lvresize --resizefs --size SIZE_TO_SET_TO /dev/mapper/vg0-home # Resize the lvm, I chose to change it from 400.25G to 390G
fsck -yM /dev/mapper/vg0-home # Came back clean
lvcreate -l 100%FREE -n swap vg0 # Use the remaining free space and allocate it all to swap (10.25G approx)
mkswap /dev/mapper/vg0-swap # Create the swap
mount /dev/mapper/vg0-root /mnt # Mount or laptops root file system so we can edit /etc/fstab
vi /mnt/etc/fstab
UUID=UUID-HERE-FROM-MKSWAP       swap      swap     default     0  0  # Add a fstab line so we can enable our swap at boot
umount /mnt # Unmount our root file system
cryptsetup luksClose LVM # Close our encrypted LVM just in case
shutdown -r now #Reboot into our own system
free -H # Check to see if the swap was enabled at boot


All went well, thanks guys.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum