Installing Nagios on Ubuntu or Debian without Postfix

Posted by sam Wed, 17 Aug 2011 11:25:00 GMT

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

Starting a Rails instance automatically on boot on Ubuntu Server

Posted by sam Thu, 24 Mar 2011 15:24:00 GMT

Audience

The follow steps will allow you to start a Rails instance automatically on boot under an Ubuntu instance in the simplest possible way. If you know about alternative Rails servers, deployment architectures beyond “webserver + mod_proxy + Mongrel” and the like then you are not the intended audience for this post.

Below is the simplest possible thing you can do to start a Rails instance automatically when you reboot your Ubuntu server, in keeping with the startup scripts that are already there. I hope that this is useful for someone starting out.

Steps

  1. save the following script in a file called ‘rails’ within the /tmp directory
  2. edit the USER, PORT, RAILS_ROOT variables to suit your application
  3. run the following commands:
sudo cp /tmp/rails /etc/init.d
sudo update-rc.d rails defaults

Reboot and test.

Script

#! /bin/sh
### BEGIN INIT INFO
# Provides:          rails
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start a Rails instance
# Description:       Do the simplest thing possible in keeping with
#             upstart to spin up a single Rails instance.
### END INIT INFO

# Author: Sam Pointer 
#
# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
USER="myappuser"
PORT=3000
RAILS_ROOT="/home/myapp/current"
COMMAND="ruby script/server -e production -p $PORT -d"
DESCRIPTION="Rails instance"

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
    # Return
    #   0 if daemon has been started
    #   1 if daemon was already running
    #   2 if daemon could not be started
    su -c "cd $RAILS_ROOT && $COMMAND" $USER
}

case "$1" in
  start)
        [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESCRIPTION"
        do_start
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
esac

Running Multiple Sendmail Instances on a Debian-like System (Ubuntu 10.4 LTS Server)

Posted by sam Fri, 13 Aug 2010 11:15:00 GMT

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.

Aptana Studio Failing On Startup STU-4247

Posted by sam Fri, 24 Jul 2009 16:45:00 GMT

I’ve wasted quite a bit of time today due to a nasty bug manifesting itself in Aptana Studio. I’m using the 64 bit Linux standalone version.

I recently configured a new project. I installed the RadRails and Subclipse, updated my gems to Rails 2.3.2. Good to go. I checked the project out from Subversion, configured a server and continued development. The next time I started Aptana the VM dumped an hs_err_pid4272.log in my home directory..

The pertinent string is

tack: [0x00007fffb511f000,0x00007fffb531f000),  sp=0x00007fffb53191b0,  free space=2024k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgdk-x11-2.0.so.0+0x3a4d0]  gdk_window_process_updates+0xe0

The only way I can work around this is to remove my default workspace directory and start from scratch.

This is logged as a bug here on the Aptana support forums.

Looking at the hs_err_pid4849.log also attached to the ticket, you can see that his permgen is full, as Chris Williams says.

Heap
 def new generation   total 2944K, used 2180K [0x74090000, 0x743c0000, 0x75440000)
  eden space 2624K,  71% used [0x74090000, 0x74264d58, 0x74320000)
  from space 320K,  95% used [0x74370000, 0x743bc5d8, 0x743c0000)
  to   space 320K,   0% used [0x74320000, 0x74320000, 0x74370000)
 tenured generation   total 37824K, used 17682K [0x75440000, 0x77930000, 0x84090000)
   the space 37824K,  46% used [0x75440000, 0x76584b30, 0x76584c00, 0x77930000)
 compacting perm gen  total 29440K, used 29209K [0x84090000, 0x85d50000, 0x94090000)
   the space 29440K,  99% used [0x84090000, 0x85d167a8, 0x85d16800, 0x85d50000)
    ro space 8192K,  74% used [0x94090000, 0x94688b48, 0x94688c00, 0x94890000)
    rw space 12288K,  58% used [0x94890000, 0x94fa3df0, 0x94fa3e00, 0x95490000)

I tried amending my permgen to ensure that I wasn’t suffering from the same (possible) problem. I edited my AptanaStudio.ini and upped the –launcher.XXMaxPermSize value from 256m to 512m.

Heap
 PSYoungGen      total 125760K, used 59990K [0x00007f1b7a760000, 0x00007f1b83d10000, 0x00007f1ba5200000)
  eden space 114560K, 42% used [0x00007f1b7a760000,0x00007f1b7d715b18,0x00007f1b81740000)
  from space 11200K, 99% used [0x00007f1b83220000,0x00007f1b83d00048,0x00007f1b83d10000)
  to   space 16832K, 0% used [0x00007f1b81c30000,0x00007f1b81c30000,0x00007f1b82ca0000)
 PSOldGen        total 69056K, used 27327K [0x00007f1b25200000, 0x00007f1b29570000, 0x00007f1b7a760000)
  object space 69056K, 39% used [0x00007f1b25200000,0x00007f1b26caffe0,0x00007f1b29570000)
 PSPermGen       total 75840K, used 48917K [0x00007f1b05200000, 0x00007f1b09c10000, 0x00007f1b25200000)
  object space 75840K, 64% used [0x00007f1b05200000,0x00007f1b081c5500,0x00007f1b09c10000)

As you can see, its 64% full.

I’m using the following:

Java version "1.5.0_18"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_18-b02)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_18-b02, mixed mode)


Linux sam-desktop 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

I’d be very greatful to anyone who has any ideas what’s going here. Being primarily a production engineer and not a Java developer I did run strace on the thing, with -f to follow the children. Suffice to say I found myself bashing out a magic SysRq and ‘o’ combo.