fighting the lack of good ideas

defaulting pxe boots with hpsa

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:


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 🙂

ogsh/ogfs for fun and profit

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).