Sam Pointer

If you install the default ‘nagios3’ package from the repositories on a Debian-based distribution, you wind up with a full copy of postfix installed. This is fine if you’re simply trying to get the thing to work, but as part of a wider infrastructure you most likely do not want a full-fledged MTA arbitrarily popping up on your Nagios host - an MTA that you have to administer, monitor (!), patch and most importantly secure.

The dependency  chain that causes postfix to be installed is:

nagios3 → nagios3-core → nagios3-common → bsd-mailx → default-mta | mail-transport-agent.

Why the package maintainers made bsd-mailx dependent on a fully-fledged MTA I will never know. Perhaps they wanted to ensure things “just worked”? It still seems a bit heavy handed to me, especially when one can configure .mailrc to point to a mailhost and be done with it.

In order to install nagios3 from the repositories and satisfy those dependencies without pulling in postfix you should install the ‘lsb-invalid-mta’ package, which provides ‘mail-transport-agent’ and satisfies the dependency chain above, in place of postfix. The package provides a sendmail binary that does nothing but return a non-zero return code, so you’ll never accidentally send mail from a local system, but you will have to configure your system to take advantage of a suitable MTA host.

Here is some puppet to install nagios3 without postfix:

# /etc/puppet/modules/nagios-server/manifests/init.pp
#
# Class: nagios-server
#
# This class maintains a Nagios server.
#
# Parameters:
#       None
#
# Requires:
#       nagios-server::install
#
class nagios-server {
        include nagios-server::install

        service { 'apache2':
                ensure => running,
                enable => true,
                require => Class['nagios-server::install'],
        }

        service { 'nagios3':
                ensure => running,
                enable => true,
                require => Class['nagios-server::install'],
        }
}

# /etc/puppet/modules/nagios-server/manifests/install.pp
#
# Class: nagios-server::install
#
# This class will install a Nagios server from the repo packages
#
# Parameters:
#       None
#
# Requires:
#       Nothing
#
class nagios-server::install {

        # Prevent nagios3-common->mailx dependency from pulling in an MTA.
        package { 'lsb-invalid-mta':
                ensure => present,
        }

        $packages = ['nagios3', 'nagios-images', 'nagios-plugins', 'nagios3-doc',]
        package { $packages:
                ensure => present,
                require => Package['lsb-invalid-mta'],
        }
}

Traditionally automated deployment on UNIX systems has been the domain of cobbled together shell scripts and bespoke solutions for each site. The power and scriptability of UNIX systems has, in this regard, worked against itself. Compared with the Windows world, which has traditionally been much harder to script, the ease at which the resourceful sysadmin can create a bunch of perl/shell scripts and cobble them together into a tangled mess of a "deployment system" invariably leads to a bloated and convoluted bespoke mess.

The Windows world has tackled the problem head-on by using native and proprietary package installers (and some novel outsiders such as AutoIt) to abstract the whole thing away behind a managed tool.

Enter the automated deployment system.

Now, let me be clear. I’m not talking about systems for deploying large farms of identical or managed boxes. I’m talking about a managed method of getting code, its dependencies, configuration and inevitable subsequent fixes through the various development and testing phases and into production in a managed manner. Tools to handle this job seem to be rather thin on the ground. I’ve managed to identify:

• Cfengine (and relatives such as Pcfengine)
• Fabric
• SmartFrog
• Puppet

All of these tools have their disadvantages, and being the healthy pessimist I am I’ll tackle those first. All apart from Cfengine require an external runtime or VM: ruby (Capistrano, Puppet), python (Fabric) or Java (SmartFrog). These may or may not be part of your server build (CoolStack on Solaris anyone?). Still I guess this is less brittle than the natively compiled Cfengine if you’re not using one of the supported platform variants and versions. It’s strange the ubiquitous perl 5 is missing from that list. Of the tools Capistrano and Fabric certainly have the least verbose of the various domain-specific languages these tools employ, a common trait shared by all. Of course, as the Puppet team states, creating GUIs for such infinitely configuarble tools is a nonsense task best left to those proprietary vendors selling new clothes to various large organisations.

Capistrano also seems to win out for the lower volume box situations, keeping closer to the traditional UNIX philosophy of building small tools to do one thing well. It does have a rails bias, however. Fabric claims to be bias free, but I’m not in a position to say one way or the other.

I would be interested to hear from anyone who has experience with any of these deployment tools, especially on Solaris and working with Java applications. How do you guys push your code into live in a managed way with easy rollback?