Chris Murphy wrote:
On Thu, Mar 26, 2015 at 12:40 AM, Bjoern Voigt
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