Automatically deploy Dell OMSA with Puppet

I’m pretty sure that nowadays every sysadmin out there still managing bare metal hardware and in particulary Dell servers know and use Open Manage Server Administrator (OMSA), which is a very nice and convenient software. The problem with OMSA is that it can be a little cumbersome to install, with all it’s repos and packages (especially on not-officially-supported distros like Ubuntu, Debian or CentOS). As a Puppet user I am, I was looking for a decent module to install the most recent OMSA version on all my machines, but I didn’t find any.

So, I wrote this brand new Open Manage Server Administrator puppet module!

It sports Ubuntu & CentOS support, granular package install and SNMP integration.
If you want the SNMP integration, be sure that your /etc/snmp/snmpd.conf contains this lines:

view systemview included .
view systemview included .
smuxpeer .
smuxpeer .

As I said in the module’s README, you can enable all of these lines through Puppet snmp module only if you use this PR, otherwise you won’t have the second smuxpeer line (whose OID is the StorageServices one).

So, after installing the OMSA module with SNMP support, you can for example easily check all your hardware with this Zabbix template or, if you are a Nagios user, with this plugin


Puppet + Vagrant VS librarian-puppet

Only recently (call me old-fashioned) I’ve started working with Vagrant to first test my puppet manifests instead of committing everything, push to the puppet master and use test environments on live machines (VM or bare metal, doesn’t matter).
At the same time, I wanted to solve another outstanding problem I had with puppet: external modules. For months/years I’ve suffered from the pain of using git submodules to integrate external modules with the in-house ones, but enough is enough. Searching for a possible solution, I stumbled upon librarian-puppet which seemed to do everything I needed.

Following Librarian’s installation instructions, I moved my modules/ directory to a separate git repository and created a nice and tidy Puppetfile with all my modules (which at the moment were all internal modules). Nice, everything worked as expected, my modules were installed in my local puppet repo with `librarian-puppet install` and I can even add external modules from the Forge with all the dependencies automagically resolved. Happy unicorns are puking colorful rainbows and everything, buuuut…

What happens when I want to edit some internal module in my new, separated modules repository? And what about adding a new role with a couple of profiles that use external modules (defined in the Puppetfile)? BUMMER.

I have to commit everything in my puppet-modules repo and push it somewhere before testing it in Vagrant, because librarian-puppet doesn’t support raw directories. Moreover, I need to edit my Puppetfile with the new development branch!!

That’s not fine at all.

But thankfully both Vagrant and Puppet support more than one modules directory at once, so:

  • first, I’ve added back my in-house modules to the original puppet repo, under modules/
  • ┬áthen, I’ve set up librarian-puppet to use a different path to install the modules it manages:
librarian-puppet config path modules-contrib --global

(in my puppet repo, remeber to gitignore modules-contrib/!)

  • relevant fragment of my Vagrantfile:
    config.vm.provision :puppet do |puppet|
        puppet.manifests_path    = "#{$puppet_dir}/manifests"
        puppet.manifest_file     = "site.pp"
        puppet.module_path       = [ "#{$puppet_dir}/modules", "#{$puppet_dir}/modules-contrib"]
        puppet.hiera_config_path = "#{$puppet_dir}/hiera.yaml"
  • and finally, if you’re using like me a puppet master, add this line to puppet.conf:
    modulepath = /etc/puppet/modules:/etc/puppet/modules-contrib

Now, it’s just a matter of librarian-puppet install before provisioning Vagrant or just after pushing changes to the Puppet master.

HOWTO: install puppet-dashboard on Debian Squeeze

This should apply to Ubuntu Server as well (10.10, 11.04) but it’s tested to work 100% on Debian Squeeze 6.0.
Puppet Dashboard is a neat piece of software really useful if you ara managing a good number of hosts without Puppet.

First of all, install the required deps:

# aptitude install ruby rake dbconfig-common libdbd-mysql-ruby mysql-client rubygems libhttpclient-ruby1.8

you’ll probably have lots of them already installed if you are running Puppet master on the same host (which by the way is not mandatory).
Then, download and install the deb package:

# wget
# dpkg -i puppet-dashboard_1.2.0-1_all.deb

Enable the daemon editing the default file /etc/default/puppet-dashboard and then customize your database definition by editing /etc/puppet-dashboard/database.yml which should looks something like this:

database: puppet_dashboard
username: puppet_dashboard
password: secret_password
encoding: utf8
adapter: mysql

if you plan to use MySQL as a backend. Remember to create the database and grant the appropriate privileges to the user

GRANT ALL PRIVILEGES ON puppet_dashboard.* TO 'puppet_dashboard'@'%' IDENTIFIED BY 'secret_password';

Now we have to populate the database, Rails way

# cd /usr/share/puppet-dashboard/
# rake RAILS_ENV=production db:migrate

Now you can start /etc/init.d/puppet-dashboard and /etc/init.d/puppet-dashboard-workers and you should be already able to access http://your-host.yourdomain.tld:3000 and see the Puppet Dashboard.
You just have to do two thing more before you can see any actual data in it: enable report sending in the Puppet clients and tell Puppet Master to pull those reports to the Dashboard via HTTP.

So, edit /etc/puppet.pupept.conf on the clients (I suggest you to do it via puppet if you do not already have this setting in it) and add

# ... whatever you already have

and on the Master side

# ... whatever you already have
reports = store, http
reporturl = http://your-host.yourdomain.tld:3000/reports/upload

That’s it!