Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part II

In Part 2 of this series we are going to deploy our virtual ESX host in a VMware Workstation 6.5 virtual machine. We will utilize the UDA setup that we created in the first part to this series. If you haven’t setup your UDA you will want to do so before proceeding. Make sure you check out the sample deployment scripts available on our download page. In this example I am deploying VMware ESX 3.5 Update 4 in VMware Workstation 6.5 build 126130.



Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part I

In this series I am going to walk you through setting up the Ultimate Deployment Appliance (UDA) and VMware Workstation 6.5 to test Automated ESX Deployment Scripts (kickstart).  The same principals that you will learn in this video also apply to using the UDA in a physical environment. The UDA is a very powerful appliance and I have found many uses for it. Using it as a medium to quickly and effectively test deployment scripts that I develop is just one.

Even in environments where the UDA is not allowed it can still be utilized. I regularly carry a 5 port gigabit switch which I can use to connect to my laptop to up to (4) servers to quickly deploy up to (4) ESX hosts at a time.



Ken’s Networking Tips…and Cracking the ESX Root Password

First…Ken Cline started a blog about a month ago. It has some nice tips for networking, so check it out. My eyes were opened after reading his post about accepting default settings. I know the post is almost a month old, but I have that reading narclepsy thing. It is still a very important thing to read. My philosophy is similar to Ken’s:

Just because you CAN do something does not mean you SHOULD do it.

I guess I picked up the habit of creating a slightly complicated way of connection two pNICs to a vSwitch for redundant connections for the Management Network and VMotion Network. I think this came from the old school (ESX 2.x) way of doing things. Ken’s methods are far easier to set up and manage.

Now…on to cracking the root password on an ESX server….

VMware just released a KB article about how to change a “forgotten” root password. WOW. Pretty simple.. Anyone who knows a smidgen about Linux could have helped here. It was even a part of the RedHat test back in the day when I took it.

First off, there should be no reason to need this if proper security and change control practices are followed. Passwords should be changed regularly and they should be kept somewhere. That somewhere should be secure. ‘Nuff said.

Second…And this is the biggie…. If you follow security best practices, this method will be rendered USELESS. The boot loader (Grub in this case) should be secured properly to protect from this sort of attack. Yes, I used the “A” word here. Unauthorized entry into single user mode is an attack. If Grub is secured properly, you will need to know a password to enter the append or edit modes. This password is just as important as the root password and proper security and change control practices should also be followed here.

OK…Now your server boot loader is “secure”.  The root password is fracked and you don’t know the grub password… Now what? Enter the rescue CD. A live Linux CD, like DSL or Knoppix will allow you to boot into a Linux session and mount your boot partition and edit the grub.conf file. Now, you can boot the server and append the boot loader line to exit single user mode. Or, you can mount the root partition, chroot and change the root password that way. It is less than simple, but we are talking about “attacking” a server and changing the root password. How do I prevent the “Live CD Attack”? Use a BIOS password and set the server so it does not boot from external media. This password should also follow the security and change control practices.

Next..”cracking” the BIOS password. In a few words: DIP switch 5. Most servers have a bank of DIP switches. Flip one of them and the BIOS password is disabled. How do you avoid this? Lock the server. I have and HP key that opens any HP cabinet and a few Dell keys that do the same thing….

I am going to stop now. I am not a computer security expert by any means. I just use common sense. Three thousand years ago, I worked for an alarm company. I could get into any “secured’ alarm cabinet and shut them down. My philosophy back then was:

Locks are for honest people…

Back to the original intent of the password thing. Use common sense. The method VMware posts for resetting a lost root password should not be possible. It all falls down to common sense and the use of good security and change control best practices. Many attacks come from within. Locks and security measures will only slow someone down and hopefully trigger that alarm system to notify someone of the attack.

Deploying Automted Kickstart Scripts Over HTTP

Originally I was going to cover all the various options for initiating your automated kickstart installation as “Automated Deployment of ESX Hosts Part IV”, but I have since decided to cover each method individually as there is a lot to cover and it makes more sense to break them out.

In this post I am going to cover deploying your servers over the network utilizing HTTP. To begin you will need a few things in place for this to work.  Below is a list of what you will need:

  • Web Server to hosts the kickstart files and optionally your ESX installation.
  • ESX Installation media or ISO’s for all versions of ESX you plan to deploy
  • Your kickstart script

The first thing we need to do is setup our web server so we can host our kickstart files and optionally our installation files.  You can utilize apache, IIS, or whatever your favorite web server is for hosting HTTP.  You will need to configure a folder under your web server root for the files to be stored.  Below is my recommended structure.

-webroot
—deployment
——ESX35U1
——ESX35U2
——ESX35U3
——ESX35U4
——kickstart

Once the folder structure is created we need to copy the contents of the installation media to the respective folder. To do this you will literally copy everything on the CD and place it in the folder. Then next you will need to copy your kickstart.cfg files to the kickstart folder.

Once you have all the files uploaded to the web server it is a good idea to use your web browser to test that you are able to access them.

As part of our kickstart we define where we are going to be installing from with the following line replacing server_IP with your server IP address and ESX25U4 with the version you would like to install.

url –url http://server_IP/deployment/ESX35U4

If you wanted to pull just your kickstart.cfg files form the http server but install from the local CD media you would replace the above string with “cdrom” to let the kickstart know to look to the cdrom drive for the installation media.

Now that we have our web server up, our installation copied to our webserver, and our kickstart.cfg files on the server we can kick off our kickstart installation.

To do this we need to boot the server from the installation CD. You can boot from the CD in the cdrom drive or remote mounted over a lights out port like iLo, DRAC, or RSA. If you are going to remote mount the CD over a lights out connection you can use a much smaller portion of the ESX CD.

On your ESX installation media there is an iso file named boot.iso located under the “images” folder on the CD. You can extract that ISO image which is roughly 4mb and remote mount that to your server for the boot process if you intend to install over HTTP.

OK so now we boot off of our media either the full ESX CD or the boot.iso image and when the ESX installation screen appears we need to tell the installation where to find the kickstart file. There are a couple of options for this which are below:

If you are using dhcp then your installation string will look similar to the below string:

esx append ip=dhcp ksdevice=eth0 network ks=http://server_name/deployment/kickstart/kickstart.cfg

If you are not using dhcp it would like similar to the follow string:

esx append ip=192.168.1.2 netmask=255.255.255.0 gateway=192.168.1.1 ksdevice=eth0 network ks=http://Server_IP/deployment/kickstart/kickstart.cfg

The statement ksdevice=eth0 tells anaconda (the installer) to use the eth0 interface for the install. I recommend always using eth0 for your installs. ESX will by default make the install interface the Service Console interface. So it will become the interface that is assigned to vSwitch0.

If you are using a seperate kickstart file for each server then you can call each one by name. If you are using a script like the one I discuss here then you will only need to have one kickstart file.

Hal’s New PowersHell Book!

If you want to learn something about PowersHell and the VI Toolkit for Winders, the community forum is the best spot right now. Hal Rottenberg is one of the pillars of that section of the forums. Always glad to help figure out your code when things are not working and always ready to explain what the heck is going on with it. I think he taught me most of the things that I know about the VI Toolkit.

Well he has written a book called “Managing VMware Infrastructure with Windows PowerShell” Stop over to his blog and pre order the book. I am sure it will become a valuable asset in your tech library.

What are you waiting for? Get out your credit card!

ESX 3.x Deployment Script # 3

This script is very similar to ESX 3.x Deployment Script #1, but I made a handy change. I built this script to allow for easier modification for each ESX host you want to deploy. Once you change all the settings you need changed there is one important area where you will add information about all your ESX hosts.

Below if the area that you will need to be concerned with:

if ['hostname -s' == "esxhost1" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

You will create this if statement for each of your esxhosts you want to deploy. Once you setup each servers information in this area all you need to do is change the hostname to match the server you are deploying and that is it. If you use dhcp to set the initial installation IP and it is able to resolve to the appropriate hostname then you won’t even have to change the script.

For example if you change this line:

network --device eth0 --bootproto static --ip [SC IP ADDRESS] --netmask [SC NETMASK] --gateway [SC GATEWAY] --nameserver [NAMESERVERS comma serperated] --hostname [HOSTNAME] --addvmportgroup=0

to the following:

network --device eth0 --bootproto dhcp

and then add the following setting the appropriate IP addresses and hostnames:

if ['hostname -s' == "esxhost1" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

if ['hostname -s' == "esxhost2" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

and you setup each ESX server in dhcp and DNS you will never need to modify this script. You need to ensure that the DNS and gateway that the server initially get’s from DHCP are correct. If you are doing this on a different subnet then what you will be running your ESX server on then you will need to do this a little differently. This can be done with my ESX 3.x Deployment Script #2.

I have included a script with this code included in our download section.

VI Toolkit powershell simple script #4 – VM Information

This is a good powershell script for tacking virtual machine inforamtion for change management. It will output the vm’s name, the host it is on, the powerstate, Memory, Number of CPU’s, IP address, and FQDN to a csv file.


$IPprop = @{ Name = "IP Address"; Expression = { $_.Guest.IpAddress } }
$HostNameProp = @{ Name = "Hostname"; Expression = { $_.Guest.Hostname } }
Get-VM | select name, host, powerstate, MemoryMB, numCPU, $IPprop, $HostNameProp | export-csv c:vm_info.csv

The Open Cloud Manifesto

The Open Cloud Manifesto was released the other day. The list of supporters is pretty impressive and the non-present are typical. I actually read the manifesto last night on my Blackberry during my daughter’s piano lesson. It was a nice read, even though the site does not have a mobile format.

The idea of cloud computing is apon us. Are you ready for it?

What Would You Like to See Changed in the VMware VM Backup Guide?

As you already know, I posted a generic VCB Proven Practice Guide on VI:OPS. I refer people to this doc frequently.

A recent community discussion regarding the VCB Documentation was visited by a VMware employee or two and the question was posed: “Could you suggest areas of improvement for this guide.”I posted a lengthy response this morning. This might be your chance to comment on the VCB documentation. I am posting the link in hopes of you responding to the question. Hopefully, the comments are considered.

Go over to the VI:OPS site and suggest changes to my doc as well!

Fixed: VMware Tools status shows as not running after running VMware Consolidated Backup

A while back I mentioned that VMware Tools would appear to change to a not running status after a VCB Snapshot was taken. Vmware said a fix would be forthcoming in ESX U4. VMegalodon posted on the communities this morning that he is running VC 2.5U3 and ESX 3.5 U4 (Which is probably a bad combination…) and the VMware Tools issue appears to be corrected.

So, what are you waiting for?? Get to upgrading!

Thanks VMegalodon!