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>
puppet broker: use 'puppetagent' as the service for Fedora RPM's from PL

In the latest Puppet Labs RPM's for Fedora, the puppet agent service is
called 'puppetagent.service'. Since Fedora now also uses systemd, use
systemd native commands to enavble/start the service
Red Hat installer: fix handling of rc.local

The installer erroneously manipulated the file /etc/rc.local which is just
a symlink to /etc/rc.d/rc.local; the file that is run when a system boots
is /etc/rc.d/rc.local

The attempt in os_complete.erb to remove the line running post_install.sh
then turned the symlink /etc/rc.local into a file; that file had the line
running post_install.sh removed from it, but /etc/rc.d/rc.local still had
it in it. The end result was that /etc/rc.local looked correct, but
/etc/rc.d/rc.local was running razor_postinstall on every single boot.
Add support for Debian 7.2 multiarch netboot CD

This enhances the Debian installer to detect and (hopefully) support the new
Debian 7.2 multiarch installer CD image available as the default download link
on the debian.org homepage.

The biggest change is that this includes both an i386 and an AMD64 kernel, and
package set, on a single disk.  Optimally, this actually means that we can
detect at runtime what CPU instruction set the client supports and boot the
correct image.

This makes, I believe, this the first multi-arch capable installer.  Which the
rest of the system won't yet support, but so it goes...

This fixes issue #82, where https://github.com/eglute discovered and reported
the failure.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add broker information to collection policy detail
Better documentation about API navigation and compatibility

This enhances the documentation to try and be clearer about where we do, and
do not, promise users compatibility information, as well as how to use the
navigation tools available.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
/svc/boot: produce proper errors when params are bad

If we get a request without params, or one where none of the params are in
the lookup criteria configured in match_nodes_on, we need to complain
cleanly.

Before this change, either kind of request would lead to an internal server
error. Now it leads to a HTTP status code of 400 and a log entry that a bad
request was made.
Change logging so that we send all logs through TorqueBox::Logger

This changes all logging so that it goes through TorqueBox::Logger and
establishes a few categories that seem useful in picking the logging apart.

Currently, it's not possible to change the log levels other than editing
JBoss configuration; see https://issues.jboss.org/browse/TORQUE-1179

There's also a couple minor issues with logging that should be addressed
upstream to make logging more user-friendly:
https://issues.jboss.org/browse/TORQUE-1177 and
https://issues.jboss.org/browse/TORQUE-1178

This fixes https://github.com/puppetlabs/razor-server/issues/93