Crypto during FAI install

[Doug Spencer]

Michael -

Experimental5 had the same issue as experimental4 when I tried it
yesterday. 

You are correct that an encrypted install requires /boot to be
unencrypted. The rest of the disk besides /boot can be encrypted. The
initrd needs the items to ask for the key during boot and unlock the
encrypted storage. 

If the standard disk configuration procedure doesn't work, I'm planning
on implementing root volume encryption via a finish script by allowing
FAI to create the root VG on a non-encrypted partition, creating a
single device MD partition on my second disk, encrypting that
partition, adding the encrypted device to the LVM PV, then doing a
pvmove to migrate everything from the unencrypted disk, removing the
unencrypted disk, and finally mirroring to become a RAID1.

Once I get this project deployed, I would be glad to help resolve some
of the issues in FAI. Looking over the code, there seems to be a lot of
cleanup that can be done. Many of the issues with FAI appear to stem
from having a lot of code to handle special cases that could be
generalized to create a better and more flexible installation
framework. 

Perhaps integrating with the standard Debian installer code would be a
viable option for configuring storage? The Debian code seems to be
reasonably flexible and works well. It would allow you to have at least
the disk configuration options a manual install allows. 

I'm working on using FAI for building a fully functional, encrypted,
RAID1 internally mirrored, DRBD between nodes, high availability
cluster with either GFS2 or OCFS2 for cluster storage. Ideally, I want
to be able to take a new system, add it to the DHCP configuration and
have it setup by FAI with all the configuration completed. In the
process of approaching that ideal configuration, I've found a few
places that can be improved within FAI, storage setup is one of the
more problematic. FAI is quite a bit nicer than doing a manual install
each time, though. At this point, it's just a matter of how much more
of that process I really want to automate to get it deployed. 

In my planned configuration, if a system or disk were to go missing,
the data contained on them would be inaccessible, yet it has enough
redundancy that hardware failure should not cause an unscheduled
outage. With a non-encrypted root VG, the possibility exists for
encryption passwords to be saved to the swap partition or elsewhere
within the disk allowing access to someone who shouldn't have access.
With backups and a good FAI build profile, recovering from an issue to
a secured and configured installation should be quick and easy. 

Thanks,
Doug

On Mon, 9 Feb 2009 21:49:21 +0100
Michael Tautschnig <mt at debian.org> wrote:

> 
> You'll need an unencrypted /boot, don't you. I don't use the encryption stuff
> yet, so I might have missed some important part while implementing it, but other
> than bugs there should be nothing that stops you from doing all this using
> current setup-storage. Of course it is quite likely that there are bugs, but we
> can definitely fix those if you could try the above experimental builds.
> 
> Thanks for your help and ideas,
> Michael