Jan Klod wrote: > Sure, that is a better way! Previously superblock was encrypted too > (what information it contains?) Info about what component device that device is, and of what MD device. > But why should one write: > > losetup -d /dev/loop1 > mount -t ext3 /dev/md0 /mnt -o loop=/dev/loop1,encryption=AES128,gpgkey=/etc/foo.gpg > > insted of just: > > mount /dev/loop1 /mnt ? When mount is told to set up loop device, it also updates /etc/mtab so that umount knows to detach the loop device. Two ways of doing it: 1) mount -t ext3 /dev/md0 /mnt -o loop=/dev/loop1,encryption=AES128,gpgkey=/etc/foo.gpg umount /mnt or 2) losetup -e AES128 -K /etc/foo.gpg /dev/loop1 /dev/md0 mount -t ext3 /dev/loop1 /mnt umount /mnt losetup -d /dev/loop1 I prefer the first one. And when mount finds device and mount options from /etc/fstab file, you can shrink the commands to: mount /mnt umount /mnt > a) in checkroot init script after root partition has been checked insert > > ebegin "Starting multi disk array" > /sbin/mdadm -A /dev/md0 /dev/hda2 /dev/hdb4 If you are using MSDOS style partition tables, then you can change partition types using fdisk to type FD (Linux raid autodetect). In that case kernel will set up those MD devices automatically when kernel boots. Works ok for /boot and root file systems, root file system encrypted or not. At least lilo bootloader can be configured to be linux software RAID1 aware, and it will boot ok from either RAID1 component disk in case other RAID1 component disk has gone completely dead. I have tested this by disconnecting a disk. Not sure if lilo bootloader recovers from errors smaller than "dead disk", such as some reads completed ok and then some read errors. > echo "20+ character password" | losetup -p 0 -e AES128 -K /etc/foo.gpg /dev/loop1 /dev/md0 losetup has -P option that reads 65-line cleartext key file that isn't wrapped in gpg encryption. head -c 3705 /dev/random | uuencode -m - | head -n 66 | tail -n 65 >/etc/foo.txt losetup -e AES128 -P /etc/foo.txt /dev/loop1 /dev/md0 > How big vulnerability is that password written in init file? Root file system where those init scripts reside, must be encrypted. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
