[SOLVED]-full disc encryption or just /home?

[FizzyWidget]

After the last failure to install gentoo on to my raid10 server/backup, i haven't touched it, seems one of the drives was bad, and that the way described to install grub onto a raid system may have wiped the partition table, but I am thinking of trying again, if you encrypt a system would you advise encrypting everything, or just the files that will be kept in home, is there any reason to encrypt, I have a fear of my systems being stolen as the house was robbed before, and seeing as i have a lot of personal stuff on here, I don't really wont people getting it, bank stuff, invoices etc etc.

I am not that great a gentoo user but am willing to try to learn, i know grub can boot from raid but i dont want to spend all that time again only for it to fail on me.

Can anyone offer some tips on how to install grub to a raid10 /boot which will contain 4 drives /sda1/b1/c1/d1, I am also guessing I will need an initramfs, but i dont know how to include raid in it, it works for the laptop but not sure how to add raid, and if i am advised to encrypt all the drives i am unsure how to proceed with that as i will have to use lvm on root.

This all seems so complicated but I am guessing to someone more knowledgeable it will be as simple as doing a non encrypted raid install.

My only other option may be to use one of those hold your hand distros, or (gasp) stick with windows home server

[frostschutz]

the way described to install grub onto a raid system may have wiped the partition table

Wow. You did something wrong, then.

if you encrypt a system would you advise encrypting everything

Yes.

swap, /tmp, logfiles in various places, bash command history in /root/.bash, databases in /var, etc. etc. there are so many things outside of /home to consider it's easier to just encrypt everything and be done with it.

i know grub can boot from raid

Grub does not even have to know about RAID. You can make a /boot partition with RAID 1 (simple mirroring over four drives), with 0.90 metadata for /boot, you can even use old raid unaware Grub 1 to boot. You install Grub on all four drives (so it still boots regardless which drive fails), each grub sees a single disk with a single /boot partition (as that's what is there when it's mirrored) and loads the kernel. Grub is done at that point, kernel is booting.

Initializing the RAID and the rest of your system is then the job of the kernel and initramfs, grub no longer involved.

My only other option may be to use one of those hold your hand distros, or (gasp) stick with windows home server

Use whatever makes you happy! Gentoo requires more know-how than others, and RAID and encryption certainly don't make things easier.

[gabrielg]

I recently installed Gentoo on an HP Microserver with RAID 10, no encryption. I couldn't be bothered with creating a partition for booting, so I plugged a USB stick for that. Genkernel and initramfs did the rest. I can't be happier.

I would encrypt the whole thing, yes, I didn't do in this case because I don't think I have physical security problems (and if I ever do, well, there isn't much there... all my very sensitive information is encrypted with Truecrypt anyway).

Shame that your last install was a failure, there are plenty of guides out there and you certainly have to go through them and get what is appropriate for you. When you have a plan of what you'll do, and if I have done it, I'll be happy to point you in the direction of the guides I used, or give you tips if I did it many times.

[cach0rr0]

I am also guessing I will need an initramfs, but i dont know how to include raid in it, it works for the laptop but not sure how to add raid

you should not need to use lvm, unless you happen to want to use lvm
as to adding raid to an initramfs, all that entails is:

-having the requisite tools in your initramfs (e.g. mdadm and anything it needs - compile statically so you dont have to copy craploads of libraries)
-having a few lines in the initramfs's "init" script that do the job of assembling your raid array.

For the second item mentioned there, it's easier than it sounds.

When you did your install with whichever livecd, you would have certainly typed a handful of commands to assemble the raid array.
You simply need to add these same commands to "init" inside your initramfs.

this is a guide ive put together, and while it doesnt go into specific details of RAID, the only additional steps for adding RAID into the mix are the two ive listed above (e.g. copy required binaries/tools, add the right commands to 'init'). I've linked directly to the 'init' crafting section, for this reason:

if you look at the line where i call cryptsetup luksOpen, all you would need to do is put your RAID commands right above that (e.g. mdadm --assemble blah)
and then instead of doing an luksOpen to /dev/sda2, you'd be doing an luksOpen of say, /dev/md0 (or whatever is correct for you)

it is not as difficult as it sounds. Just requires a bit of reading

as to what to encrypt: if you dont encrypt everything, youve encrypted nothing. If anything is unencrypted - especially swap - someone will find a way to get at data you dont want them to have

HTH

[FizzyWidget]

Thanks for the replies, as to doing something wrong and it wiping the partitions, it suggested putting grub into /dev/sda1/b1/c1/d1 yet after googling other places they say to put it in /dev/mdx - so i will try that

My current initramfs

Code: Select all

#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev
#for a french azerty keyboard
loadkmap < /etc/kmap-us
rescue() {
   echo "Dropping to rescue shell" >&2
   /bin/sh </dev/tty1 >/dev/tty1 2>&1
}
/bin/cryptsetup luksOpen /dev/sda2 gentoo || rescue
/bin/lvm pvscan || rescue
/bin/lvm vgscan || rescue
/bin/lvm vgchange -ay vg || rescue
mount -r /dev/mapper/vg-root /newroot || rescue
CMDLINE=`cat /proc/cmdline`
umount /dev
umount /sys
umount /proc
exec /bin/busybox switch_root /newroot /sbin/init ${CMDLINE}

i did have an updated one to load mdadm, but lost it will look at your guide in a bit cach0rr0, I thought if you used encryption you were required to use lvm as it uses /dev/mapper - guess i misunderstood

edit: I think after reading your guide I have a rough idea of what to do, meds have kicked in so I wont be doing anything on it today

[cach0rr0]

I thought if you used encryption you were required to use lvm as it uses /dev/mapper - guess i misunderstood

i think i know where this confusion comes from

the cryptsetup *package* in portage, depends on the lvm2 *package*

Code: Select all

hplaptop ~ # equery depends lvm2
 * These packages depend on lvm2:
net-fs/nfs-utils-1.2.6 (nfsv41 ? sys-fs/lvm2)
sys-block/gparted-0.13.1 (dmraid ? >=sys-fs/lvm2-2.02.45)
sys-block/parted-3.1 (device-mapper ? >=sys-fs/lvm2-2.02.45)
sys-fs/cryptsetup-1.4.3 (static-libs ? >=sys-fs/lvm2-2.02.64[static-libs(+)])
                        (>=sys-fs/lvm2-2.02.64)
                        (static ? >=sys-fs/lvm2-2.02.64[static-libs(+)])

that does not mean you have to make/use LVM on your disks in order to use crypto

in other words, that's a portage thing, not a disk thing. The lvm2 package in portage provides the device-mapper libraries/bits/pieces. But that just means the package has to be emerged - you dont have to lvm your disks in order to use crypto (I certainly dont!)

And just generally speaking, if you can luksFormat it, you can use it. So, for example, you can 'luksFormat /dev/md1', which would just mean your initramfs had to:

-first assemble your drives to create /dev/md1
-second, cryptsetup luksOpen /dev/md1 crypt-root || rescue
-third, mount -o ro /dev/mapper/crypt-root /mnt/root || rescue
-fourth, unmount proc/sys/dev
-fifth, exec switch_root /mnt/root /sbin/init

(assuming for demonstration purposes your root is /dev/md1 )

[FizzyWidget]

ah, now that does help clear up some issues, so if i am following you correctly (which i am probably not ), my init should look something like

Code: Select all

#!/bin/sh 
mount -t proc proc /proc 
mount -t sysfs sysfs /sys 
mount -t devtmpfs devtmpfs /dev 
#for a french azerty keyboard 
loadkmap < /etc/kmap-us 
rescue() { 
   echo "Dropping to rescue shell" >&2 
   /bin/sh </dev/tty1 >/dev/tty1 2>&1 
} 
/bin/mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
/bin/mdadm --assemble /dev/md1 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
/bin/mdadm --assemble /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
/bin/mdadm --assemble /dev/md3 /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4
/bin/cryptsetup luksOpen /dev/md0 gentoo-boot || rescue
mount -o ro /dev/mapper/gentoo-boot /boot || rescue
/bin/cryptsetup luksOpen /dev/md1 gentoo-root || rescue
mount -o rw /dev/mapper/gentoo-swap / || rescue
/bin/cryptsetup luksOpen /dev/md2 gentoo-swap || rescue
mount -o rw /dev/mapper/gentoo-root / || rescue
/bin/cryptsetup luksOpen /dev/md3 gentoo-root || rescue
mount -o rw /dev/mapper/gentoo-root / || rescue
/bin/cryptsetup luksOpen /dev/md4 gentoo-home || rescue
mount -o rw /dev/mapper/gentoo-home /home || rescue
CMDLINE=`cat /proc/cmdline` 
umount /dev 
umount /sys 
umount /proc 
exec /bin/busybox switch_root /newroot /sbin/init ${CMDLINE}

My apologies if I am making this harder than it appears, as I said before, I have never used raid on linux before and am easily confused

[cach0rr0]

only two small things

Code: Select all

/bin/cryptsetup luksOpen /dev/md0 gentoo-boot || rescue
mount -o ro /dev/mapper/gentoo-boot /boot || rescue

this part is unnecessary, and broken actually. If your /boot is encrypted, where is grub supposed to find your kernel and initramfs?

when people say "encrypt they whole disk" they really mean "encrypt root, encrypt everything but /boot"

so /boot must not be encrypted

it can, however, be raid

The other one is the mounting root as 'rw'
This should not be done within the initramfs - the init system will do this for you after you've done the switch_root and execute /sbin/init
meaning, it will handle remounting root as rw

the same is true of /home and /swap

Basically, the initramfs exists solely to get root taken care of. - the init system, or scripts rather (/etc/init.d/mdadm , /etc/init.d/dmcrypt, etc, and their config files in /etc/conf.d/) will take care of the rest.

You *might* run into an issue where openrc doesn't know whether you're running luks atop raid, or running raid atop luks - i dont know if it is intelligent enough to figure this out on its own. But for the time being I would leave out those pieces, and just do something like:

Code: Select all

#!/bin/busybox sh 
mount -t proc proc /proc 
mount -t sysfs sysfs /sys 
mount -t devtmpfs devtmpfs /dev 
#for a french azerty keyboard 
loadkmap < /etc/kmap-us 
rescue() { 
   echo "Dropping to rescue shell" >&2 
   /bin/sh </dev/tty1 >/dev/tty1 2>&1 
} 

# assemble root
/bin/mdadm --assemble /dev/md1 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2 
# unlock root
/bin/cryptsetup luksOpen /dev/md1 gentoo-root || rescue 
# mount root ro
mount -o ro /dev/mapper/gentoo-root / || rescue

CMDLINE=`cat /proc/cmdline` 
umount /dev 
umount /sys 
umount /proc 
exec /bin/busybox switch_root /newroot /sbin/init ${CMDLINE}

again, things like swap and home can be assembled and decrypted by the init system, just by editing the requisite configuration files - the need for the initramfs exists because the tools the init system uses to do this reside on root, so root must be accessible before they can work their magic.

[FizzyWidget]

do you mean that i should use dmcrypt to open the other raid drives? Is there a way I could do that automatically, instead of having to putting in the passcode 4 times?

[cach0rr0]

do you mean that i should use dmcrypt to open the other raid drives? Is there a way I could do that automatically, instead of having to putting in the passcode 4 times?

basically meaning that the init script provided for openrc can do the job of decrypting everything *but* root
root has to be unlocked and mounted (ro) in order for those init scripts to even be accessible - and *that* is why the need for an initramfs, that is, if root is encrypted.



the bigger point, is that you dont need to worry about /home within your initramfs. Your initramfs is for getting root unlocked, and making its tools available, period.

for everything else, have a peek at /etc/conf.d/dmcrypt - once root is unlocked and mounted, the initramfs has done all it needs to do in order to hand things over to the init system

to avoid entering a passphrase multiple times, use a keyfile for things like /home
something like:

Code: Select all

target=gentoo-home
source='/dev/md4'
key='/full/path/to/homecrypt.key'

target=gentoo-swap
source='/dev/md2'
key='/full/path/to/swapcrypt.key'

in /etc/conf.d/dmcrypt

home.key and swap.key can just be random. something like

Code: Select all

head -c64 /dev/urandom | base64 > /homecrypt.key
head -c64 /dev/urandom | base64 > /swapcrypt.key

then when you do your luksFormat, instead of adding a passphrase, add the correct key
you could even use *both* a random key, and then a passphrase as a backup
meaning, when you're first setting up the device, you just specify a passphrase as per usual

and then later do a 'cryptsetup luksAddKey' to add your keyfile - either your passphrase, or your keyfile, can be used to unlock

the trick is of course, that for your keyfile to be accessible in the above example, root must already be unlocked.

If this is a concern, you could keep your key file(s) on a thumb drive, so that if the thumb drive is not inserted, the volumes are not unlocked
you would still be able to, if you lost the thumb drive, get in using your passphrase, luksAddKey again to add a new key, change /etc/conf.d/dmcrypt, done and dusted.

But i may be getting a bit far off on a tangent there. Sometimes offering too many options to start with can be a cumbersome thing...

[FizzyWidget]

Thanks, well explained in such an easy to understand manner, even for a pleb like me, it doesnt seem as scary now, I will boot the pc and get swap up using a passphrase and then move to a key after.

One last question, seeing as this PC will be headless, how would be the best way to get it to email me should something go wrong with the raid, would i need to install a sntp server on there? ISP has rules about that, other than me checking the logs every few days, or is there a simpler method?

[cach0rr0]

One last question, seeing as this PC will be headless, how would be the best way to get it to email me should something go wrong with the raid, would i need to install a sntp server on there? ISP has rules about that, other than me checking the logs every few days, or is there a simpler method?

you'd need an MUA (mail client), not necessarily an MTA (mail server)
meaning, sending mail only, not receiving email - you will have no service listening on port 25, but you may have a client connecting to someone else's server on port 25.

should just entail installing something like ssmtp (which can email your gmail account, for example) and then setting the right email value in mdadm.conf

that is from memory, i have not done mdadm in some time. If I try to get too specific I will step on my dick most assuredly.

EDIT: worth pointing out - the mail facility will not help you of course, if it is the root volume that fails to assemble on boot, for example. It can monitor and warn/alert while the system is up and running, but it requires a working network and the files needed to send mail, among other things, which will not be available inside the initramfs, as they are on your rootfs. Once you mount and switch_root it should do the job just dandy

[FizzyWidget]

Thanks!!! all is working now and it boots all I have to do is guess when to put the passwd in as its a head less server going to gzip up all the conf files so if I need to re-install (which I prob will as i will mess something up) i will have all the files i need without all the messing about.