antipaucity

In conjunction with the customized PXE process I wrote about previously, it could be highly desirable to be able to return a server to the unprovisioned server pool in HP’s Server Automation.

This is a specifically-Linux procedure: though I’m sure something similar can be done with Windows^*.

run an ad-hoc script against a target server that contains the following:

dd if=/dev/zero of=/dev/sda bs=512 count=1
sleep 1
nohup reboot

This will erase the MBR and partition table, and then reboot the server.

Before it reboots, however, you need to deactivate and delete the server from SA – otherwise it will not register correctly.

If you’ve already enabled (or not disabled) PXE booting, when it reboots, it will pick the default entry off the PXE menu, skipping the hard drive as there is no valid boot record available to it.

Why would you want to do this?

Well, let’s say you’re doing a lot of build testing (verifying ks.cfg or unattend.xml files, for example) – this could be useful.

Or, maybe you want to get your build process completely streamlined and you’re working with the MBC functionality in SA – again, rapid recycling of machines is highly desirable.

In a later post I’ll discuss freeing the VM from SA in the process (ie, removing it from the ESXi host to fully release resources).

^{*_{In fact, you may be able to run fdisk /mbr on a Windows server – but I haven’t tried.}}

I recently found a very helpful nugget with regards to OS Provisioning with HP’s Server Automation product.

OS Prov is most typically done using PXE (or the similar bootp process). SA provides a PXE server that gives a boot menu to network-booted systems. That menu contains a variety of choices: linux, windows, winpe, etc.

In most environments, one particular OS will be dominant, and typically one particular version of that OS – whether it be RHEL 5 x64 or Windows 2008 R2, it’s usually just one that makes up the lion’s^* share of systems on the network.

If you know that you will be provisioning, say, Windows 2008 R2 90% of the time, it would be nice to not have to always have to pick it manually from the PXE boot menu.

Here’s what you need to do to make that happen (presuming you want to use Build Plans):

Edit the following file:

/opt/opsware/boot/tftpboot/pxelinux.cfg/default

For example, if you have this at the beginning of the file:

"prompt 1
default local
timeout 100
display pxelinux.msg
implicit 0"

Change it to this for the OGFS version of winpe64:

"prompt 1
default winpe64-ogfs
timeout 100
display winpe64-ogfs.msg
implicit 0"

You can use the above process – modified, of course – for any of the available boot images.

^{*_{And if you’re provisioning Mac OS X 10.7, “Lion” makes up all the share}}

The absolute coolest feature of HP’s Server Automation suite is the OGSH (or OGFS) – the Opsware Global SHell (or FileSystem).

I worked for Opsware before HP acquired them, and the OGSH was a new feature to the product (then called Opsware SAS (Server Automation System)). It’s a fuse module that gives a [limited] bash interface to the managed environment by presenting a live query/view into the database, and, ultimately, allowing manipulation of managed servers in the environment.

For example, to access a list of all managed servers, you login to global shell, then

cd /opsw/Server/@

The ‘@’ sign is used to indicate you are “there” – at the limit of that particular filter (in this case, “Server”).

Since it’s bash, you can run most common *nix utilities and commands. But the one that’s most handy, in my opinion, is rosh – the Remote Opsware SHell.

Remote shell opens an authenticated, logged session to a remote machine (*nix or Windows – doesn’t matter), based on your user’s/group’s permissions. For testing purposes, I always configure one group (and add myself) that can connect using root for *nix machines (and Administrator on Windows).

The basic command to connect to a machine is:

rosh -l [username] -n [machine]

You can also pass commands to rosh like it was an ssh session:

rosh -l [username] -n [machine] '[command]'

For the fullest power of rosh, though, use it in a script or loop. For example:

for sn in *; do rosh -l root -n $sn 'uptime ; uname -a'; done

That will remote shell into every server in the current view, using standard shell expansion of the splat (*), and run uptime and uname -a, printing the results to screen. That particular command is handy for quick-and-dirty reports on the managed environment to see

• which servers are up, and which aren’t
• how long they’ve been up

In addition to rosh, global shell provides a near-complete exposing of the SA API (which is also accessible via Java, web services, and Python (using the “PyTwist” bindings written to access the Java interfaces).