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'],
        }
}

When installing Sendmail from the repository packages it is pretty much assumed that you will only be running one instance on a given server. If, like I had to recently, you want to maintain a number of sendmail configurations and process, but want to fit into the Debian rc script scheme, it takes a bit of work.

I’ve created a patch that can be run against the stock /etc/init.d/sendmail script to produce scripts like /etc/init.d/sendmail.mail1 to manage named instances of sendmail. There are a few things you need to know:

• The patched scripts expects to find the configuration for the named instances in /etc/mail/servers/instancename
• The script expects to be called sendmail.instancename
• Along with changing the INSTANCE= variable at the top of the script, be sure to change the comments so that the update-rc.d style daemon registration works if required. A global search and replace is probably your best bet.
• /etc/default/sendmail can be copied to /etc/default/sendmail.instancename and populated, if present or required.
• PID and lock files end up in /var/run/sendmail.instancename. You will need to edit your named instances sendmail.mc/cf to have the PID files created in the correct location. Spools end up in /var/spool/mqueue.instancename

The final piece of configuration required to make this mechanism work is to copy /etc/mail/sendmail.conf to /etc/mail/servers/instancename/sendmail.conf and to modify the MISC_PARMS variable:

MISC_PARMS="-C/etc/mail/servers/INSTANCENAME/sendmail.cf"

Substituting INSTANCENAME as required. This ensures that the correct configuration file is read from.

If you are binding your sendmail instances to different interfaces you might like to also modify the DAEMON_NETIF variable to have the instance watch the correct interface for state changes, if you have DAEMON_NETMODE set to something other than the default “Static”.

Apart from that the patched script does everything that you would expect and the various logged messages reflect the instance name. Managing individual instances then becomes a matter of:

$ sudo service sendmail.mail3 stop
$ sudo service sendmail.mail2 start

Easy as that.