Fix Kickstart boot arguments for multiple interfaces

The arguments to Kickstart to inform it of the NIC we booted from are more
complex than what we had encoded -- the BOOTIF argument is actually a
composite with two values:

  ${ARP HTYPE code}-${MAC with colons}

We were only supplying the MAC address, which meant that the installer was not
matching our boot interface correctly.  This updates that to (a) just get the
data directly from iPXE rather than our Razor server database, and (b) to pass
it with the "correct" extra information.

Technically, I just hard-coded "this is Ethernet" into the thing, which should
work fine since everything including wireless that users can reasonably boot
from to date is actually Ethernet as far as the kernel is concerned.
When this breaks for you, feel free to yell at me -- then tell me how to get
the right HTYPE code out of iPXE. ;)

[ptaswehla](https://github.com/ptaswehla) independently found and reported the
same thing, so due credit: that would have solved the problem too. :)

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Support RHEL better in the Puppet broker

At least some versions of RHEL report `redhatenterpriseserver` rather than
just `redhat` in the (mangled) output from lsb_release(1).  This updates the
broker to recognise that more robustly.

This closes #76, which reported that.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement node ID lookup from hardware ID details

This implements an API for a client to request their unique node ID, if
available, from the Razor server.  This allows the Windows client -- and any
future installer burdened by the same inability to get dynamic data fed
directly into it -- to hook up with the node definition.

That, in turn, allows it to enter the normal bootstrapping process without
having to dynamically generate an entire new Windows system image every time
we boot a node.  Probably a performance win. ;)

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
PowerShell script to build a WinPE Razor client image

This is a PowerShell script capable of building out a Razor client WinPE
image, which we will then use to access and run the network installer.

Right now it is able to put together enough of an image to prove that we can
build WinPE, and boot it successfully, to trigger our test client script.

Notes:
 * tested only on Windows 8.0 with ADK

Requirements:
 * Install the ADK *IN THE DEFAULT LOCATION ON DISK!*
   * c:\program files (x86)\...
 * Have PowerShell.  (I have the version that shipped with Windows 8.)
 * Run the script.  Bam.

Output:
 * A WIM file containing our modifications.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add wimboot 1.0.3 to the Windows installer

This adds the wimboot 1.0.3 binary to the Windows installer.  This is needed
to be able to boot the WIM image outfitted with the Razor client memory
efficiently, and works together with iPXE.

This was downloaded from the binary release available online at the iPXE
website: http://ipxe.org/wimboot#download

This is GPLv2 software, and source code for this binary is available at the
same location.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement a Windows installer using wimboot

This is implemented using the Windows 8 ADK and CD source; it presently works
to boot an image (named `razor-winpe.wim`) build by our client image
PowerShell script on the target machine.

Once there this has sufficient support to send a second stage PowerShell
script from the installer that will obtain the auto-install data, connect to
the specified SMB server, then fire up the Windows installer.

That uses an autoinstall XML file generated on the server, and manages
notification to the Razor server on completion and rebooting.  On first boot
the system should correctly proceed to process specialization and other
installer passes automatically with no further involvement from Razor.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
ESXi: add, and always use, encrypted password support

This updates the ESXi kickstart file to use encrypted passwords.  Since we can
robustly identify an encrypted password in the policy, we test for that and
either ship the pre-encrypted password, or encrypt it ourselves on the server.

That way the data crossing the wire, which is not secured, contains only a
reasonably secure password hash.  This is a step up from sending a plain-text
password, at the very least.

This also makes the root password from the policy actually *work* on ESXi,
replacing the previously hard-coded password.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
WIndows Commit
merged
mods2
Fix windows broker
windows broker fixes
Restart Computer
Merge branch 'master' of https://github.com/simonfuhrer/razor-server