[SOLVED] LVM ontop of encrypted file system - 2 drives
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Hi all, I know this is not strictly Slackware specific but as a Slacky I always get the answers from you guys so why change a winning formula :-)
So my 'master plan' is to have encrypted file system (cryptsetup) on two drives. Drive A is for the operating system and drive B is for backup of home dirs via a cron script. These encrypted drives will have LVM ontop for management.
So my question. How can I boot up on drive A (via lilo) and be prompted for one pw (for the encryption via cryptsetup) to unlock BOTH drive A and B before LVM initiates (which is across both drives)? I have an unencrypted partition for boot on drive A. Of course unlocking drive A is easy enough, just don't know how to do the two at the same time.
And if you want to know why not use mirroring via RAID. Well as I read somewhere the disadvantage of that is that whatever you do on one drive is immediately duplicated on the other drive. Accidentally delete a file, one is corrupted...... you loose it. So in that regard mirroring is not the most 'fool proof' backup strategy.
I think initrd can only unlock the root partition, drive A.
According to README_CRYPT.TXT, drive B would have to be unlocked later in the boot process using /etc/crypttab, as detailed in chapter "Encrypting your '/home' partition".
I only use passwords, but you can try using key files and putting both on the same plugged in USB key: drive A and drive B would find their respective key file and be unlocked when the time comes in the boot process.
Yes, I found it not very obvious how to set up multiple drives under the same password. I followed this link with multiple partitions on the same drive which comes to the same thing and it worked fine, one pw for all.
Alexx, yeah I was aware of that but surely just adding the second drive as a lv will leave that drive unencrypted?
Password unlocks drive A only then mount your LVMs (of which drive B is a part but unencrypted?)
If I understand it right LVM would pass data through crypt for drive A but write 'straight' to-drive for B.
Cendryon... yes that looks like the way to go. Only issue there would be having to enter the pw twice. Need to look into it a little more.
I think you're right, thinking about it a bit more using the link I gave implies all the encypted stuff in one partition. And using two separate encrypted partations even with the same password would be a real pain.
Only encrypt drive A ( all except /boot ) using the link I gave. Leave drive B unencrypted but use aespipe during backup to encrypt all the backup files individually so there are still hidden, the password would only be needed on drive A. This also has the advantage that if you subsequently copy the backups to removeable media they are still hidden. This is how I do backups to CD's once a month.
The initrd does support unlocking multiple devices. I had exactly the same requirement as you and wrote some code to add the feature, which found it's way into Slackware's official initrd script via Eric.
To unlock multiple devices from the initrd specify them on the -C option e.g. "-C /dev/sda2:/dev/sdb2". The downside of this approach is that it will prompt you for the password for each drive (doing anything else would have complicated the initrd code more than I wanted to and I also wanted to support the possibility of the passwords differing).
If you want to use both drives in the same volume group then you will have to use the above as both PVs will need to be available when the VG is activated.
If you are going to put the two drives in two different volumegroups then you can avoid the need to specify a second password by unlocking the first in the initrd as normal, and then use the crypttab and a key-file to unlock the second automatically. However, there's a catch. Crypttab processing in /etc/rc.d/rc.S runs after the LVM 'scan' code. The disk holding the secound volumegroup will still be locked when lvm scans for PVs. and it won't be available automatically. you'll need to add a second run of "vgscan --mknodes" and "vgchange -ay" to your system startup (perhaps via /etc/rc.d/rc.local). You'll probably also find that you won't be able to have fstab automount any of the filesystems on the second disk for the same reason. These issues were the motivation I had for rewriting the initrd code in the first place.
My advice would be to use the -C option to unlock both disks in the initrd and just live with the inconvenience of having to enter the password twice. Hopefully you don't boot all that often.
Please read the man page for mkinitrd... it is all explained there.
-C device list
A colon (:) delimited list of luks encrypted block devices to be
unlocked by the initrd using cryptsetup. All devices that must
be unlocked in order to access the root filesystem must be spec?
Each unlocked device will be assigned an automatically generated
luks device name of the form luks<device> where '<device>' will
be the basename of the encrypted device. e.g.
As a convenience to users, where -r specifies one of the device
names listed on the -C option it will be automatically adjusted
to use the correct luks device name. i.e.
"-C /dev/sda2 -r /dev/sda2" and
"-C /dev/sda2 -r /dev/mapper/lukssda2"
(Use with '-r' option).
Thanks for the replies. Thanks again Alien Bob, helped me out yet again. Also Gazl, that is of course exactly what is required.
Have been thinking about keeping the encryption on the second drive but ditching LVM as I don't really need it on that drive and it might simplify things too. (ie should the first drive fail/corrupt then it will make things easier to get at the backed up data on the second drive if it is not part of a LVM)