fai and cryptsetup

[Patrick Schoenfeld]

Hi Michael,

On Sat, Sep 25, 2010 at 10:29:38PM +0200, Michael Tautschnig wrote:
> This is intentional and documented in the setup-storage man page, last stanza of
> "CAVEATS" (at the very end of the man page). 

Yes I know. I should have made it more clear that this wasn't meant as a
moaning about how it is, just an objective explanation of the facts.

> The simple reason is that it is
> hard to guess where the keyfile should be put.

Indeed.

> > 3. Booting from a cryptoroot with a keyfile seems to be problematic
> > anyway. At least I haven't yet managed to get a working installation
> > with it (and don't want to invest much time in it as its not the wanted
> > goal anyway).
> > 
> 
> As far as I understood, the idea is to put a keyfile on removable media -
> doesn't that work as expected?

Not without stuffing the fai-profile additionally. It will be neccessary
to modify the crypttab so that a keyscript is specified which will load
the script from the stick, create the script, etc.
In my case this whole procedure wouldn't make sense after all because
the keyfile is only an intermediate step because of crypt-setup not
supporting anything else.

> 
> > What I'll now try to get a crypted fai installation bootable:
> > Add a script to add a new luksKey, a default passphrase and change the
> > crypttab so that it does not reference a keyfile. Then trigger initramfs
> > recreation.
> > 
> > Any other options (with setup-storage support itself, maybe?)
> > 
> 
> If you can describe a workflow that is fully non-interactive we could definitely
> improve setup-storage such as to cater for that. I have never used cryptsetup
> myself, hence the questions. But ideas are most welcome!

Well, it would be a nice start to be able to specify a passphrase in the
disk_config. Shouldn't be that hard, I guess.
On implementation side its possible to feed the passphrase with the aid
of yes to cryptsetup, e.g. something like this:

yes <passphrase>|cryptsetup luksAddKey ...

works like expected.

> For now, however, I'd suggest to add a hook partition.SOMECLASS.source that
> - changes the encryption to use a passphrase
> - edits the crypttab (which was generated by setup-storage)
> - moves crypttab to a proper location

For now I did it with a script (not a hook). Hook is probably the
better idea because it solves the problem before the initrd is
built for the first time.

It currently almost works. Fresh installed system now asks for the
passphrase, accepts it and unlocks the rootdev. Unfortunately the initrd
scripts don't seem to understand that it now has to re-initialize the
LVM volume groups so that the rootdev is actually available.

> To ensure the initramfs rebuild, you might need to add code to some script
> executed at the end, depending on whether update-initramfs is called during
> installation anyhow or not.

Well, it is, during kernel installation.

Best Regards,
Patrick