GroundWork: Enabling TLS certificate login

By default, GroundWork supports authentication by password, with a native or LDAP backend. However, using our existing grid certificates would be much easier. Here's how: (We'll assume you're already using SSL to connect, which means your /usr/local/groundwork/apache2/conf/extra/http-ssl.conf is setup and ready to go)

1. Edit /usr/local/groundwork/nagios/etc/htpasswd.users, adding lines for your DN a la:
   /C=AU/O=APACGrid/OU=The University of Melbourne/CN=Tom Fifield:xxj31ZMTZzkVA
   
   
2. Edit /usr/local/groundwork/apache2/conf/httpd.conf, following the directions to 'Uncomment to disable Guava Single Sign On" and then paste in
   SSLRequireSSL
   SSLVerifyClient require
   SSLVerifyDepth 5
   SSLCACertificatePath /etc/grid-security/certificates/
   SSLOptions +FakeBasicAuth
   SSLVerifyClient require
   Order allow,deny
   Allow from all
   AuthUserFile /usr/local/groundwork/nagios/etc/htpasswd.users
   AuthType Basic
   AuthName "Nagios: YOUR CERTIFICATE MUST BE REGISTERED"
   Require valid-user
   in the many Directory sections that are involved.
   
   
3. Use groundwork to tell nagios to let us in:
   Login to groundwork using your normal username and password, go to Control and Nagios CGI configuration. Next, append the DNs you added to the htpasswd file to the necessary permissions sections. Save and restart.

Laying down the GroundWork

Without a doubt, Nagios is a great way to monitor hosts and services on the grid. But those of us who've ever edited the convoluted configuration files by hand know the joy of getting syntax errors and a overload of falsely-triggered alert emails enough to go on an office-destroying rampage. Thankfully, there are several good solutions out there in the form of frameworks.

At Australia-ATLAS we use Groundwork.

Far more fully featured than 'configuration generators' like NagiosAdmin(German), Lilac(alpha) and ignoramus(lacking), Groundwork wraps nagios entirely and is very stable.

Groundwork uses a MySQL backend to manage all of the configuration before it is committed (the standard .cfg files are eventually fed to nagios) which makes the interface smooth to use. Existing users of nagios take heart - it is well supported to load previously painstakingly produced .cfg files into Groundwork through the 'Load' functionality. In this way, scripts written to automatically generate workernode host instances can still be used - though this can also be done using Groundwork's 'clone host' tool.

Groundwork also takes care of all the mundane things like, the nagios daemon itself, managing users, roles and add-on packages.


All that sounds like a bit of an ad. Why would a time-starved grid admin move to groundwork?

Configuration is easier.

You no longer need to remember anything: all of the options you have are in a drop-down box or multi-select list. That also means no more typos! Finding any host, service, command or profile is a two-click operation. You tend to use groups more because they're so much simpler to create - instead of adding them to every host in a file, you just select them from a list.

There is a couple of times when the improved robustness of Groundwork can be a little annoying. For example, when you update a service check, you need to remember to deploy it to hosts/hostgroups otherwise you can commit changes and wonder why nothing has changed.

However, these are small in comparison with the improved productivity you gain.

So why not give Groundwork a try - you can get it at http://www.groundworkopensource.com/.