[opensuse] Full disk encryption with RAID+LVM+LUKS on openSUSE 13.2?
I already installed laptops with openSUSE 13.2 and full-disk encryption on one hard drive. I used an UEFI boot partition (/boot/efi) and the filesystems / and /home (plus swap) on an encrypted LVM. This works. But now I have a server with three hard disks. I want to setup the same full-disk encryption with YaST like on the laptops. On the server I want to use LVM over RAID-5 (mdadm). Is this possible? (with YaST, manually nor not possible) Is there any detailed documentation for this? (Until now I am able to setup RAID-5 with YaST. But I do not find the option to encrypt the LVM volume group. Without a LVM volume group I can not use "/" as a mount point for LVM logical volumes. Encryption for the RAID 5 device /dev/md0 works. But this kind of setup may cause problems if I want to extend the LVM volume group later with additional RAID devices.) I also have a problem with unlocking the LUKS encryption. Unlocking with password works. But unlocking with USB stick does not work unfortunately. https://bugzilla.opensuse.org/show_bug.cgi?id=915849 Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 26, 2015 at 12:40 AM, Bjoern Voigt <bjoernv@arcor.de> wrote:
(Until now I am able to setup RAID-5 with YaST. But I do not find the option to encrypt the LVM volume group.
There's no way to encrypt VGs. You can encrypt LVs or PVs (the array) or md members (the drives).
Without a LVM volume group I can not use "/" as a mount point for LVM logical volumes.
I'm not sure what this means.
Encryption for the RAID 5 device /dev/md0 works. But this kind of setup may cause problems if I want to extend the LVM volume group later with additional RAID devices.)
Anything with layers increases the chances of some problem happening, including user error. You're proposing this: drive > md > luks > pv/vg > lv > fs growing means growing md, growing luks, extending PV, extending VG, resizing LV, resizing FS. or this: drive > luks > md > pv/vg > lv > fs growing means creating a new LUKS device, growing md, extending PV, extending VG, resizing LV, resizing FS. So it's exchanging growing LUKS volume, with creating a new LUKS volume. And you should have backups of LUKS headers. So I think really the first one is probably easier to manage. The simplest version would be: OPAL 2.0 SED drives > Btrfs raid5. Done. ZFS raid5 isn't easier when it comes to resizing, you basically have to rebuild it. But Btrfs raid5 means kernel 3.19 or higher as a minimum, and is in a bit of a gray area between stable and experimental, probably closer to stable. But... less tested so far. Sticking with LVM, ways to simplify: drive > PV > VG > raid5 LVs > LUKS> fs In this setup, drop mdadm and use LVM integrated RAID, and encrypt the LV. This is easier to grow, and also use different raid levels and choose encryption selectively. drive > luks > md > PV> VG > thin LV > fs In this setup, you essentially obviate the need to ever resize the fs by choosing a virtual size LV that's big enough such that you'd never grow the LV or FS. So all you have to do is encrypt a drive, grow the array, and extend the PV and VG. The risky part, growing the LV and fs is avoided.
I also have a problem with unlocking the LUKS encryption. Unlocking with password works. But unlocking with USB stick does not work unfortunately.
-- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy wrote:
On Thu, Mar 26, 2015 at 12:40 AM, Bjoern Voigt <bjoernv@arcor.de> wrote:
(Until now I am able to setup RAID-5 with YaST. But I do not find the option to encrypt the LVM volume group. There's no way to encrypt VGs. You can encrypt LVs or PVs (the array) or md members (the drives). Ok, thanks. So I probably also encrypted PVs on the laptops.
Without a LVM volume group I can not use "/" as a mount point for LVM logical volumes. I'm not sure what this means. If you select LUKS encryption and formatting (EXT 4 ...) for a filesystem in YaST, it refuses mountpoints like / and /root with an error message. (In theory it's possible to use LUKS encryption for "/" and "/home" etc. filesystems separately. Some argue, that this causes multiple password inputs. Buts this is not true, because some scripts can handle this with only one password input, if the passwords fits for all filesystems. But YaST refuses such setups. It's not clear, if a user can setup such a system manually. Probably he will see problems with Systemd, Dracut etc. and with YaST distribution upgrades.)
As a result I need LVM for full-disk encryption.
Encryption for the RAID 5 device /dev/md0 works. But this kind of setup may cause problems if I want to extend the LVM volume group later with additional RAID devices.) Anything with layers increases the chances of some problem happening, including user error.
You're proposing this: drive > md > luks > pv/vg > lv > fs growing means growing md, growing luks, extending PV, extending VG, resizing LV, resizing FS.
or this:
drive > luks > md > pv/vg > lv > fs growing means creating a new LUKS device, growing md, extending PV, extending VG, resizing LV, resizing FS. I know the first one. This is the setup, I want to use. And if LUKS encryption of LVM PVs is right, I already managed it correctly.
But I do not know the second setup. Is it possible with YaST? (I do not see an option to encrypt the whole drive. Wouldn't this cause problems with GPT partitioning / dual boot and with Grub2 booting?)
So it's exchanging growing LUKS volume, with creating a new LUKS volume. And you should have backups of LUKS headers. So I think really the first one is probably easier to manage.
The simplest version would be:
OPAL 2.0 SED drives > Btrfs raid5.
Done. ZFS raid5 isn't easier when it comes to resizing, you basically have to rebuild it. But Btrfs raid5 means kernel 3.19 or higher as a minimum, and is in a bit of a gray area between stable and experimental, probably closer to stable. But... less tested so far.
Sticking with LVM, ways to simplify:
drive > PV > VG > raid5 LVs > LUKS> fs In this setup, drop mdadm and use LVM integrated RAID, and encrypt the LV. This is easier to grow, and also use different raid levels and choose encryption selectively.
drive > luks > md > PV> VG > thin LV > fs In this setup, you essentially obviate the need to ever resize the fs by choosing a virtual size LV that's big enough such that you'd never grow the LV or FS. So all you have to do is encrypt a drive, grow the array, and extend the PV and VG. The risky part, growing the LV and fs is avoided. I know, that managing LVM offers professional features, but it's not so easy. I would like to avoid LVM, because I'm more familiar with normal GPT partition management including RAID and filesystem resizing. But without LVM I can not use full-disk encryption with YaST (see above).
Thanks for the ZFS and Btrfs tips. Btrfs would be an option. I am not sure about the stability and maintainability of Btrfs in openSUSE 13.2. I think, I will wait until next openSUSE release with this. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 26, 2015 at 3:52 PM, Bjoern Voigt <bjoernv@arcor.de> wrote:
Without a LVM volume group I can not use "/" as a mount point for LVM logical volumes. I'm not sure what this means. If you select LUKS encryption and formatting (EXT 4 ...) for a filesystem in YaST, it refuses mountpoints like / and /root with an error message. (In theory it's possible to use LUKS encryption for "/" and "/home" etc. filesystems separately. Some argue, that this causes multiple password inputs. Buts this is not true, because some scripts can handle this with only one password input, if the passwords fits for all filesystems. But YaST refuses such setups. It's not clear, if a user can setup such a system manually. Probably he will see problems with Systemd, Dracut etc. and with YaST distribution upgrades.)
I guess I understand no / encryption if a separate non-encrypted /boot isn't created. It's atypical for distros to support setting up GRUB to support LUKS unlock to load kernel and initramfs. But I don't think it's reasonable to make you use LVM just to get (mostly) full disk encryption, it should just encrypt each partition and use the same passphrase. Bug/feature request.
Encryption for the RAID 5 device /dev/md0 works. But this kind of setup may cause problems if I want to extend the LVM volume group later with additional RAID devices.) Anything with layers increases the chances of some problem happening, including user error.
You're proposing this: drive > md > luks > pv/vg > lv > fs growing means growing md, growing luks, extending PV, extending VG, resizing LV, resizing FS.
or this:
drive > luks > md > pv/vg > lv > fs
growing means creating a new LUKS device, growing md, extending PV, extending VG, resizing LV, resizing FS. I know the first one. This is the setup, I want to use. And if LUKS encryption of LVM PVs is right, I already managed it correctly.
But I do not know the second setup. Is it possible with YaST? (I do not see an option to encrypt the whole drive. Wouldn't this cause problems with GPT partitioning / dual boot and with Grub2 booting?)
Sorry. Insert "partition" between drive > luks. And I haven't actually tested it in yast, but it's a valid layout to separately encrypt a partition on each drive, and then each resulting identically sized dmcrypt device is made an md member device, then the md array is made a PV, and so on.
Thanks for the ZFS and Btrfs tips. Btrfs would be an option. I am not sure about the stability and maintainability of Btrfs in openSUSE 13.2. I think, I will wait until next openSUSE release with this.
It's a reasonable precaution, the 13.2 kernel is still on 3.16.x so I'd hold off on Btrfs raid5 until it gets a bit more testing. In any case, backups! -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 26 Mar 2015 21:44:14 -0600 Chris Murphy <lists@colorremedies.com> пишет:
I guess I understand no / encryption if a separate non-encrypted /boot isn't created. It's atypical for distros to support setting up GRUB to support LUKS unlock to load kernel and initramfs.
Actually this part works just fine in openSUSE. You can have /boot/grub2 on encrypted partition and YaST supports it (or better it does not complain :) ) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 26, 2015 at 3:52 PM, Bjoern Voigt <bjoernv@arcor.de> wrote:
Without a LVM volume group I can not use "/" as a mount point for LVM logical volumes. I'm not sure what this means. If you select LUKS encryption and formatting (EXT 4 ...) for a filesystem in YaST, it refuses mountpoints like / and /root with an error message. (In theory it's possible to use LUKS encryption for "/" and "/home" etc. filesystems separately. Some argue, that this causes multiple password inputs. Buts this is not true, because some scripts can handle this with only one password input, if the passwords fits for all filesystems. But YaST refuses such setups. It's not clear, if a user can setup such a system manually. Probably he will see problems with Systemd, Dracut etc. and with YaST distribution upgrades.) I guess I understand no / encryption if a separate non-encrypted /boot isn't created. It's atypical for distros to support setting up GRUB to support LUKS unlock to load kernel and initramfs. But I don't think it's reasonable to make you use LVM just to get (mostly) full disk encryption, it should just encrypt each partition and use the same passphrase.
Bug/feature request. Yes, /boot must be unencrypted. But unfortunately in openSUSE "/" can't be encrypted without LVM even if there is a separate /boot
Chris Murphy wrote: partition. I already discussed this issue with developers here some time ago. It's probably something, which should be done sometime. But I also don't know a distribution which can handle full-disk encryption without LVM. I don't know an existing feature request for this. But I wrote a feature request for the other issue. Please support this or write comments: Add support for unlocking LUKS root volumes during boot process via SSH https://features.opensuse.org/318809
Encryption for the RAID 5 device /dev/md0 works. But this kind of setup may cause problems if I want to extend the LVM volume group later with additional RAID devices.) Anything with layers increases the chances of some problem happening, including user error.
You're proposing this: drive > md > luks > pv/vg > lv > fs growing means growing md, growing luks, extending PV, extending VG, resizing LV, resizing FS.
or this:
drive > luks > md > pv/vg > lv > fs growing means creating a new LUKS device, growing md, extending PV, extending VG, resizing LV, resizing FS. I know the first one. This is the setup, I want to use. And if LUKS encryption of LVM PVs is right, I already managed it correctly.
But I do not know the second setup. Is it possible with YaST? (I do not see an option to encrypt the whole drive. Wouldn't this cause problems with GPT partitioning / dual boot and with Grub2 booting?) Sorry. Insert "partition" between drive > luks. And I haven't actually tested it in yast, but it's a valid layout to separately encrypt a partition on each drive, and then each resulting identically sized dmcrypt device is made an md member device, then the md array is made a PV, and so on. Now I have done this slightly different. I configured Host-Raid/Fake-RAID on one server. I can manage the RAID with "dmraid" and the BIOS. openSUSE 13.2 handled this without problems during installation. On top of the Fake-RAID I partitioned the RAID device like a single hard disk.
Thanks for the ZFS and Btrfs tips. Btrfs would be an option. I am not sure about the stability and maintainability of Btrfs in openSUSE 13.2. I think, I will wait until next openSUSE release with this. It's a reasonable precaution, the 13.2 kernel is still on 3.16.x so I'd hold off on Btrfs raid5 until it gets a bit more testing. In any case, backups! You are right.
Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Mar 27, 2015 at 4:48 PM, Bjoern Voigt <bjoernv@arcor.de> wrote:
Yes, /boot must be unencrypted. But unfortunately in openSUSE "/" can't be encrypted without LVM even if there is a separate /boot partition. I already discussed this issue with developers here some time ago. It's probably something, which should be done sometime. But I also don't know a distribution which can handle full-disk encryption without LVM. I don't know an existing feature request for this.
Fedora does.
Now I have done this slightly different. I configured Host-Raid/Fake-RAID on one server. I can manage the RAID with "dmraid" and the BIOS. openSUSE 13.2 handled this without problems during installation. On top of the Fake-RAID I partitioned the RAID device like a single hard disk.
dmraid? Are you sure? If this is Intel firmware RAID, the dmraid support is deprecated. It's all been moved to md/mdadm these days. Otherwise, it sounds fine. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy wrote:
On Fri, Mar 27, 2015 at 4:48 PM, Bjoern Voigt <bjoernv@arcor.de> wrote:
Yes, /boot must be unencrypted. But unfortunately in openSUSE "/" can't be encrypted without LVM even if there is a separate /boot partition. I already discussed this issue with developers here some time ago. It's probably something, which should be done sometime. But I also don't know a distribution which can handle full-disk encryption without LVM. I don't know an existing feature request for this. Fedora does. Thank you. I tried RAID-5 with 3 disks, unencrypted /boot partition and a standard (non-LVM) encrypted root-partition with Fedora 21. It works fine. Since Fedora also uses Systemd and Dracut (like openSUSE), it shouldn't be so hard to adapt the mechanisms.
I found several feature requests for encrypted non-LVM root partitions in openSUSE. Until now, there are not much votes for the feature requests. Please vote, if you like this feature: Ability to create encrypted partitions without using LVM https://features.opensuse.org/314850 Encryption - Installer needs more information and options https://features.opensuse.org/310279
Now I have done this slightly different. I configured Host-Raid/Fake-RAID on one server. I can manage the RAID with "dmraid" and the BIOS. openSUSE 13.2 handled this without problems during installation. On top of the Fake-RAID I partitioned the RAID device like a single hard disk. dmraid? Are you sure? If this is Intel firmware RAID, the dmraid support is deprecated. It's all been moved to md/mdadm these days.
Otherwise, it sounds fine. Thank you. I found a lot of outdated information regarding Fake-RAID.
Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/27/2015 10:25 PM, Chris Murphy wrote:
dmraid? Are you sure? If this is Intel firmware RAID, the dmraid support is deprecated. It's all been moved to md/mdadm these days.
This needs to be confirmed. This was the intent back mid-2013?, but after the mdraid failed to pickup hardware support for many of the dmraid chipsets, I believe dmraid continued active development. Checking.... The latest patchset to dmraid is less than 24 hours old. e.g.: [dm-devel] [RFC] [PATCH 0/7] fs: add blkdev name format specifier 3/31/15 -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 01 Apr 2015 22:49:22 -0500 "David C. Rankin" <drankinatty@suddenlinkmail.com> пишет:
On 03/27/2015 10:25 PM, Chris Murphy wrote:
dmraid? Are you sure? If this is Intel firmware RAID, the dmraid support is deprecated. It's all been moved to md/mdadm these days.
This needs to be confirmed. This was the intent back mid-2013?, but after the mdraid failed to pickup hardware support for many of the dmraid chipsets, I believe dmraid continued active development.
For Intel?
Checking....
The latest patchset to dmraid
Could you point to repository? The last version I'm aware of is 1.0.0.rc16-3, dated 2010.
is less than 24 hours old. e.g.:
[dm-devel] [RFC] [PATCH 0/7] fs: add blkdev name format specifier
Are you sure you do not confuse dmraid with device-mapper?
3/31/15
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Bjoern Voigt -
Chris Murphy -
David C. Rankin