Crypto during FAI install

[Michael Tautschnig]

[...]
> 
> I just tried 3.2.17+experimental4 and I see Parser.pm has some updated
> code if I search for :encrypt. Unfortunately, it still shows:
> 
> ERROR (line 17): Invalid file: Was expecting /\Z/ but found "raid1
> -:encrypt sda2,sdb2 - -" instead
> 
> I will run in debug mode and send you a private follow up message with
> that.
> 

From what I've seen so far and heard back, this should be fixed in
3.2.17+experimental5 and laters, but could you please check to make sure this is
indeed the case? Unfortunately, I haven't found the time to test this stuff
myself while fixing all the bugs, but others were as kind as to try each and
every version, and it seems that finally we got it.

> Also, my suggestion regarding XML, or some type of dependency ability,
> is due to the increase flexibility it would allow. For instance, if you
> wanted to setup DRBD replication, CLVM, GFS, or any of the other
> storage possibilities you could define it with a dependency tree. It
> allows you to stack your storage in any way you want, such as encrypted
> storage backing a DRBD device with LVM or CLVM running on it.
> 

Ok, that may indeed call for a more elaborate specification technique, but I'd
really like to get LVM/RAID to fully work before tackling all the others.

> I currently have a workaround for the encryption issue as follows:
> 
> # cat ./scripts/LAST/70-encryptmd2
> 
> #! /bin/bash
> 
> error=0 ; trap "error=$((error|1))" ERR
> 
> yes 'PassPhrase' | cryptsetup -q luksFormat /dev/md2 -c aes-cbc-essiv:sha256 -s 256 
> yes 'PassPhrase' | cryptsetup luksOpen /dev/md2 md2_crypt 
> pvcreate /dev/mapper/md2_crypt 
> vgcreate XenVM /dev/mapper/md2_crypt
> printf "md2_crypt /dev/md2  none luks\n" >> $target/etc/crypttab
> 
> exit $error
> 
> Which works for the XenVM VG. I haven't implemented it for the root
> partition yet, which is also my goal. I'm thinking another way to implement
> the root encryption is to create a 1 device root LVM VG, then create a md
> device that I encrypt, add the encrypted device to the LVM PV, then
> move all the LV resources to that encrypted device and add the original
> device back as a mirror to the encrypted md device. It would work, but is 
> a bit time consuming when this process can be done with the right initial 
> processing.
> 

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

-------------- 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/20090209/ba676427/attachment.bin