Update LUKS formatting for systemd
Fix LUKS initialisation
EC2 backend: don't barf in destroy() if there is no instance
Fix LUKS initialisation
Allow <charon> to be overriden using -I for easier development
Automatically create RAID-0 volumes

The option ‘deployment.autoRaid0’ causes an LVM-based RAID-0 logical
volume to be created automatically on top of the specified physical
volumes.

Example usage (with EC2):

  deployment.ec2.blockDeviceMapping."/dev/xvdg".size = 100;
  deployment.ec2.blockDeviceMapping."/dev/xvdh".size = 100;

  deployment.autoRaid0.fnord.devices = [ "/dev/xvdg" "/dev/xvdh" ];

  fileSystems =
    [ { mountPoint = "/data";
        autoFormat = true;
        device = "/dev/fnord/fnord";
        fsType = "ext4";
      }
    ];
Merge branch 'master' into systemd
Order the create-raid0 service before the mkfs service
Move LUKS support to a separate (non-EC2-specific) module

Actually, we should probably move this to NixOS and unify it with the
LUKS support in the initrd.
Generalise ‘charon send-keys’ to support sending arbitrary secrets

The new option ‘deployment.keys’ allows specifying arbitrary secrets
that will be stored in /run/keys.  For example, to prevent an SSL
private key from being stored on a web server, you can do:

  services.httpd.sslServerKey = "/run/keys/server.key";
  deployment.storeKeysOnMachine = false;
  deployment.keys."server.key" = builtins.readFile ./ssl/server.key;

Here, the file ‘server.key’ will not be stored persistently on the
target machine, and after a reboot, the httpd service won't start
until you've run ‘charon send-keys’.
Add new instance types
auto-luks.nix: Use deployment.keys
Fix support for auto-generated LUKS keys
‘fileSystems’ is an attribute set now
Always emit a "<hostname>-encrypted" alias for 127.0.0.1
Factor out common Nix flags
Grmbl laziness grmbl
Keep track of the Charon database schema version

The singleton table SchemaVersion contains the current version.  This
is the same scheme used by Hydra.
Rename the Machines table to Resources

This is in preparation of issues #64 and #65.
Refactoring: Add a ResourceState superclass

ResourceState is the superclass of all state classes. Currently this is
just MachineState and its subclasses, but in the future there will be
others such as EC2 keypairs and SQS queues. All resources should implement
the create() and destroy() methods.