Crypto during FAI install

[Michael Tautschnig]

Hi Doug,

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

I finally got around to try your config and on my system the parser nicely
accepted it. Could you please retry using experimental9 and report back? In case
it still fails while parsing, please supply the error message and attach your
config file (please don't paste it, there may be some strange whitespace issue).
Thanks!

> 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.
> 

I think we should really get that done using setup-storage, without any need for
manual hacks.

> 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. 
> 

We discussed this and we also looked at the code. At that time it seemed easier
to do it ourselves, but that may have changed. I'm well aware that we duplicate
lots of stuff here, but I still think that we must handle at lot more cases than
in d-i because we just can never ask the user. But I'm very much open to
suggestions and ideas what could be improved, be it code changes or
picking/using stuff from d-i.

> 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. 
> 

Although I've thought about using these, I've never worked with DRBD/GFS/OCFS,
so I'm just lacking all the necessary experience. Still, that shouldn't be a
show-stopper. If you can come up with a script (much like you did for the
encryption stuff) that gives an idea of the necessary steps we might be able to
get all this done.

> 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. 
> 

Yes :-)))

Best,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20090212/d1fb9b50/attachment.bin