Create a bootable ISO installer from your VMDK disk files

I've run into a situation where I need to distribute a VM as a bootable ISO image, not the usual VM descriptor file + disk image(s).

Getting this to work was a little hacky but not too hard. My idea was to create a rescue CD/DVD ISO image file with an automated installer and the target VM filesystem contents.

The overall process looks like this:

1. build your appliace as usual
2. use VDDK to extract the full filesystem contents of your VM to one or more archive files
3. extract the contents of a Linux rescue CD (sysresccd) to a temporary file tree
4. copy the VA filesystem archives to the root directory of the rescue cd files (isoroot)
5. drop in an installer shell script named "autorun" into the isoroot
6. roll up the new ISO image via mkisofs

First I downloaded sysresccd from http://www.sysresccd.org/Main_Page and VMware's virtual disk access application VDDK from http://www.vmware.com/support/developer/vddk/

I do all my development on Linux (CentOS5 amd64) so to install VDDK I first had to install fuse and fuse-lib via "yum -y install fuse fuse-lib". After that I could expand the VDDK compressed tarball and run its vmware installer.

The "autorun" script performs the following functions:

a. sanity checks the system using dmidecode (to make sure it's not going to wipe out your workstation hard drive by accident)
b. autopartitions the first hard drive it finds (sda) by piping partition data to fdisk
c. formats the new partitions
d. mounts the new parttions
e. transfers the filesystem contents from the compressed tar archives
f. verify file checksums to ensure the transfer wasn't corrupted
g. update fstab and other config files if necessary
h. reboots

The ISO image is only ~12MB more than the OVF/OVA due to good compression of the appliance filesystem contents in the ISO image. The bulk of sysresccd is hardly noticed.

Cool eh?

Renaming OVF files

Studio2 creates both OVF v0.9 and OVF/OVA 1.0 specification files for VI3 and vSphere4 support respectively. Unfortunately Studio2 uses hardcoded filename suffixes of "OVF09" and "OVF10" to describe the two which doesn't really mean anything to a user who's trying to decide which variant to download.

To correct this naming issue you can edit the suffix hardcodes easily enough. Login to your studio2 vm as root and edit the following file:

/opt/vmware/lib/build/VADK/Constants.pm:

Replace the following section:

#
# OVF/OVA filename constants. These must agree with mkovf.
#
use constant OVF09FILESUFFIX    => '_OVF09.ovf';
use constant OVF10FILESUFFIX    => '_OVF10.ovf';
use constant OVF10OVAFILESUFFIX => '_OVF10.ova';

...With:

#
# OVF/OVA filename constants. These must agree with mkovf.
#
#use constant OVF09FILESUFFIX    => '_OVF09.ovf';
#use constant OVF10FILESUFFIX    => '_OVF10.ovf';
#use constant OVF10OVAFILESUFFIX => '_OVF10.ova';
# hackingstudio improved filename suffixes: 
use constant OVF09FILESUFFIX    => '_VI3.ovf';
use constant OVF10FILESUFFIX    => '_vSphere4.ovf';
use constant OVF10OVAFILESUFFIX => '_vSphere4.ova';

And also edit the file /opt/vmware/share/mkovf, replacing:

#
# These must agree with the values in the build module Constants.pm
#
OVF09FILESUFFIX="_OVF09.ovf"
OVF10FILESUFFIX="_OVF10.ovf"

...With:

#
# These must agree with the values in the build module Constants.pm
#
#OVF09FILESUFFIX="_OVF09.ovf"
#OVF10FILESUFFIX="_OVF10.ovf"
# hackingstudio improved filename suffixes: 
OVF09FILESUFFIX="_VI3.ovf"
OVF10FILESUFFIX="_vSphere4.ovf"

And that's it. Nothing to restart, your next build will have OVF and OVA files that are named more intuitively for VMware users.

If anyone is using studio2 to create appliances for non-VMware platforms I'd love to hear about it in the comments, thanks.

Setting User Passwords Longer Than 8 Characters

When creating Red Hat/CentOS appliances using Studio & Studio2 the passwords accepted for root and user accounts are truncated to 8 characters as they're encrypted using the very limited crypt function.

To use md5 hashes instead you need to generate an md5 hash on an existing Linux system, like:

[root@will cli]# adduser tmpuser
[root@will cli]# passwd tmpuser
Changing password for user tmpuser.
New UNIX password: [enter a long password, over 8 chars]
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Then grab the hash:

[root@will cli]# grep tmpuser /etc/shadow
tmpuser:$1$PhmFj24Z$nu/7FF2813kKiEt2DWiB81:14623:0:99999:7:::

In this case we want: $1$PhmFj24Z$nu/7FF2813kKiEt2DWiB81

Escape the dollar signs with a \ character for each: \$1\$PhmFj24Z\$nu/7FF2813kKiEt2DWiB81

Now edit your build profile XML file for the appliance you are working on and change the vadk:passwordFormat value to "des" and the vadk:password value to the escaped hash.

for example:

<vadk:User vadk:username="myuser" vadk:password="\$1\$PhmFj24Z\$nu/7FF2813kKiEt2DWiB81" vadk:passwordFormat="des" vadk:fullname="My User" vadk:uid=""/>

Don't mind that the passwordFormat says "des" when in fact we're using md5 hashes, it's a goofy misnomer for "already encrypted, just use the specified string".

And build. Boot your new appliance and try to login with only the first 8 characters of the specified password, now you should be denied as the full password is respected.