Stand Aside, Sysadmin

IBM ServeRAID Manager is needed for managing alerting for disks/arrays on IBM servers – it’s a bit of a pain to install manually, as you need to mess around with opening firewall ports and the like – so I thought I’d automate it using puppet.

Assuming you’ve already got puppet installed and running on your vSphere box (you’ll need to compile it elsewhere first as a toolchain is no longer available on vSphere) along with a patched version of facter
First you’d want to start out with a manifest that will only apply the classes based on the manufacturer – if you want, you could tie it down to specific model numbers, as this information is returned by the productname fact – on this server it looks like:

productname => IBM System x3650 -[7979KFG]-

In our environment, I was confident that any IBM server running ESX would need ServeRAID Manager installing, so I went with manufacturer => IBM.

class basenode::vmwareesx {
    include basenode
    include firewall::vmwareesx::puppetclient
        case $manufacturer {
            IBM : { include ibmserveraid::vmwareesx }
            default : {}
        }
}

Firstly our base configuration to be applied to any ESX box has:
basenode – which includes login banners, basic puppet configuration and a few other things that are common to all machines.

The second class in here is firewall::vmwareesx::puppetclient. This class applies firewall rules needed for puppet the ‘proper’ way, using XML configurations held in /etc/vmware/firewall – which will then be viewable from the vSphere Client:

Puppet Firewall Rules

A sample configuration for managing puppet is below:

<!-- Firewall configuration information for Puppet Client -->
<ConfigRoot>
  <service>
    <id>Puppet Client</id>
    <rule id='0000'>
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <port type='dst'>8140</port>
      <flags>-m state --state NEW</flags>
    </rule>
    <rule id='0001'>
      <direction>inbound</direction>
      <protocol>tcp</protocol>
      <port type='dst'>8139</port>
      <flags>-m state --state NEW</flags>
    </rule>
  </service>
</ConfigRoot>

To get these to show up in the vSphere Client, you need to restart the mgmt-vmware service – historically doing this has always caused issues – VM’s rebooting, servers rebooting.. Behaviour seems to have improved in recent versions, but it’s still not at the point where I’d recommend putting that in a puppet manifest.
Luckily, all we really care about for the purposes of this is what the service console can see – we can wait until the next server reboot for the rules to be viewable in the GUI.
From the console, available firewall rules can be refreshed with “esx-firewall -l”.

So, our basic class for managing puppet firewall rules would look like:

class firewall::vmwareesx::puppetclient {
	include firewall::vmwareesx::refreshservices

	file { "puppetClient.xml":
		ensure => present,
		owner => root,
		group => root,
		mode => 600,
		checksum => md5,
		notify => [ Exec["refresh_esx_firewall"], Exec["apply_esx_firewall_puppet_client"] ],
		source => "puppet:///files/vmware-firewall/etc/vmware/firewall/puppetClient.xml",
		path => "/etc/vmware/firewall/puppetClient.xml"
	}

	exec { "esxcfg-firewall -e 'Puppet Client'":
		path => "/usr/sbin:/usr/bin:/bin",
		alias => "apply_esx_firewall_puppet_client",
		refreshonly => true
	}
}

class firewall::vmwareesx::refreshservices {

	# Update services (only call if rule has been added/updated)
	exec { "esxcfg-firewall -l":
		path => "/usr/sbin:/usr/bin:/bin",
		alias => "refresh_esx_firewall",
		refreshonly => true,
	}
}

A combination of refreshonly => true on the commands, and checksum => md5 on the configuration file is enough to ensure that the commands will only be run if the xml file changes.

Configuration for the other firewall rules needed – firewall::vmwareesx::smtpclient and firewall::vmwareesx::ibmserveraid is done in exactly the same way (links are to github versions).

The final piece to this puzzle is the base class ibmserveraid::vmwareesx, referenced in the above basenode manifest for servers reporting manufacturer => IBM

# Class for IBM ServeRAID Manager Installs 
	
class ibmserveraid::vmwareesx {
	include firewall::vmwareesx::smtpclient                                                                                              
	include firewall::vmwareesx::ibmserveraid
	include firewall::vmwareesx::httpclient::enable
	case $architecture {
		x86_64 : {
			package { "RaidMan-9.00":
				ensure => installed,
				provider => rpm,
				require => Exec["apply_esx_firewall_http_client"],
				source => "http://puppet.example.com/pub/ibm-serveraid/RaidMan-9.00.x86_64.rpm",
				}
		}
	}
}

Notice here that all this does is pull the RPM down from a http server hosted on our puppetmaster. ESX does have it’s own package management system(based on yum?), but this is a closed system, only used by VMware for managing host updates as far as I’m aware.
There is also no service manifest defined here for controlling startup/shutdown of the serveraid daemon – as of version 9, the RPM installs and starts the daemon, adding it to the appropriate runlevels. I’m inclined to leave it this way at the moment, as although the service console is based on RHEL 5, in reality it’s a fairly customised environment and therefore any changes you do make should be as un-intrusive as possible – or otherwise face the possibilities of a) breaking something or b) invalidating that over-priced support warranty.

The final step is one that I havn’t managed to automate yet is configuring the Manager with SMTP gateway and mail recipients (or trap recipient if you’re that way inclined) – which as far as I can see the only way to do this is done remotely using a Manager installed on a machine with a GUI.

All of the files from these examples are available @github – I’ll be adding some more stuff over the coming weeks – If I ever get some free time..

I’d be interested to know of anyone else’s experience using puppet on ESX – I’ve seen a few examples of people using it in combination with the VIPerl API to manage deployment of machines, but very few people seem to be using it to manage the physical box.