To that end, I have created a repository on GitHub for the task with a detailed readme file:

• https://github.com/barryo/nagios-plugins

As a starting point, there are four plugins available now:

The straw finally came when Nick forced my hand for a project we wanted to release through our work in INEX. I was pushing for Google Code but he had his heart set on GitHub. Now, in fairness, GitHub has some SVN bindings but after some research, I decided to dive right in.

Now, there’s both a steep learning curve but also a complete change of mindset required from centralised source code management (SCM) with SVN to the distributed model of Git. In the end, most projects will decide on a canonical Git repository anyway which pushes you slightly back towards centralised but there’s still a world of a difference.

So, what’s so good about Git? Well, lots. But first and foremost is it’s exceptionally powerful yet simple branching and merging that just works. And works fast – remember, with Git everything is local.

One work flow that used to kill me in SVN was that you’d be implementing feature X but someone needed bug Y fixed immediately involving some of the same code. Getting just the fix for Y in was tough and complicated. And branching in SVN isn’t quick or simple. In Git, I branch from the main development branch for every new feature, bug fix, etc and then merge what I need between them and back into develop when they’re ready to be pushed back to the agreed canonical repository.

I’ve been so impressed with Git that I’ve moved an open source project we created in Open Solutions over to Github: ViMbAdmin. I’ve also forced the rest of my team in Open Solutions over to Git and migrated a number of customer projects already. And we’re reaping productivity rewards!

How we work Git for projects was taken from this excellent post which I would fully recommend: A successful Git branching model.

Useful Git Links:

• Git for SVN Users: http://git.or.cz/course/svn.html
• Git SVN Comparison: https://git.wiki.kernel.org/index.php/GitSvnComparison
• Git’s own website: http://git-scm.com/
• Git Cheat Sheets: http://help.github.com/git-cheat-sheets/
• The excellent book Version Control with Git (from Amazon)

ViMbAdmin (pronounced vim-be-admin) is essentially a modern replacement for PostfixAdmin – a web based interface which will allow you to manage virtual mailboxes, virtual domains and aliases.

We have a live demo which you can access here. You can also browse screenshots by clicking the image on this page.

ViMbAdmin was written in PHP using our own web application framework which includes the Zend Framework, the Doctrine ORM and the Smarty templating system with JQuery on the frontend.

The decision to use Smarty, Doctrine and Zend unfortunately adds a bit of overhead for someone installing the product as they will also need to locate these third party libraries. Fortunately:

• many distributions include all three as packages now;
• if you take the svn install option then they will be also installed from external svn sources.

ViMbAdmin can work as a slot in replacement for Postfix Admin with a few MySQL ALTER statements.

Features

• Super admin(s) user level with full access;
• Admin(s) user level with access only to assigned domains and their mailboxes and aliases;
• Super admins can create and modify super admins and admins;
• JQuery Datatable throughout for quick in browser searching and pagination;
• Create, modify and purge domains including limited the number of mailboxes and aliases a non-super admin can create per-domain;
• Activate / deactivate admins, domains, mailboxes and aliases at the click of a button;
• Full logging;
• Facility for users (mailbox owners) to change their password;
• Forgotten Password / Password Reset function for admins;
• Very configurable including:
  • set default values for quotas, number of mailboxes and aliases for domain creation;
  • templated welcome and settings email for users;
  • either plain or MD5 mailbox password support.

We hope it’s of use to you!

In this first of a serious of articles where we delve into some of the hidden treasures in our ViMbAdmin application, we look at how to integrate Doctrine ORM with Zend – and specifically Zend_Application and Zend_Controller.

As all the code is available with the GPL license online, I didn’t over explain the set-up but I’d love some feedback on whether I’ve been too obscure for the article to be useful at all.

I recently came across ORM Designer and have quickly become a big fan. It’s interface is nice, it has excellent support for Doctrine including behaviors and I’ve ran through many update / export to YAML / create models from YAML cycles without issue.

I’d strongly recommend for anyone using Doctrine – plus there’s a 30 day evaluation without any limiting of functionality so you can examine it for yourselves.

These retrofits include installing virus and SPAM filters to protect both ourselves and the ISP customers but also to stop customers who have infected computers from spewing these emails out.

When everything’s up and appears to be working, I like to test both filtering systems to ensure they’re working. Quoting from eicar:

Using real viruses for testing in the real world is rather like setting fire to the dustbin in your office to see whether the smoke detector is working. Such a test will give meaningful results, but with unappealing, unacceptable risks.

Fortunately, test files exist for virus checkers and SpamAssassin:

• The EICAR standard anti-virus test file can be found here.
• SpamAssassin created the GTUBE (Generic Test for Unsolicited Bulk Email) for the same purpose and this can be found here.

We’re going to go that way, really fast. And if something gets in our way, we’ll turn.

• PHPUnit
• PhpDocumentor
• PHP_CodeSniffer

I hope to take a closer look at it in the near future for a new project we’re lining up at work (want to help us?).

Speaking of continuous integration, for another project we installed and look after a Hudson server for a customer who is developing a Java and Cocoa application – if you’re looking for a CI tool for a Java (or other) development project, this is definitely worth a look (easy installation, nice and intuitive interface and well featured).

The first problem is that AWS only distribute the tools as an RPM (really guys? I mean FFS). Convert and install with alien.

# apt-get install alien
# alien -k ec2-ami-tools.noarch.rpm
# dpkg -i ec2-ami-tools_1.3-15283_all.deb

Make sure you also install libopenssl-ruby.

Set your Ruby path as the RPM places them where RedHat expects to find them:

# export RUBYLIB="/usr/lib/site_ruby"

Now when you run the utility, you’ll probably get:

$ ec2-bundle-image -r ... -i ... -k ... -c ... -u ...
sh: Syntax error: Bad substitution

Aparently Ubuntu switched from invoking bash to dash for sh somewhere along the line. Just relink it (temporarily or permanently as suits):

# rm /bin/sh
# ln -s /bin/bash /bin/sh

And you should be good to go.

One other issue I encountered was that the permissions of the directories were for root only (i.e. /usr/local/aes, /usr/lib/site_ruby/ and /etc/aes). A very sloppy chmod a+rX on each of these will resolve that. Although I suspect it’s more to do with the fact that I used rpm2cpio and cpio rather than alien the first time around.

To this end, I have written a Nagios plugin which queries Asterisk’s manager interface and executes the pri show spans CLI command (this is Asterisk 1.4 by the way). The script then parses the output to ascertain whether a PRI is up or not.

The actual code to connect to the manager interface and execute the query is simply:

if( ( $astsock = fsockopen( $host, $port, $errno, $errstr, $timeout ) ) === false )
{
    echo "Could not connect to Asterisk manager: $errstr";
    exit( STATUS_CRITICAL );
}

fputs( $astsock, "Action: Login\r\n");
fputs( $astsock, "UserName: $username\r\n");
fputs( $astsock, "Secret: $password\r\n\r\n"); 

fputs( $astsock, "Action: Command\r\n");
fputs( $astsock, "Command: pri show spans\r\n\r\n");

fputs( $astsock, "Action: Logoff\r\n\r\n");

while( !feof( $astsock ) )
{
    $asttext .= fread( $astsock, 8192 );
}

fclose( $astsock );

if( strpos( $asttext, "Authentication failed" ) !== false )
{
    echo "Asterisk manager authentication failed.";
    exit( STATUS_CRITICAL );
}

This plugin is hard coded to English and expects to find Provisioned, Up, Active for a good PRI. For example, the Asterisk implementations that support the pri show spans command that I have access to return one of:

• PRI span 1/0: Provisioned, In Alarm, Down, Active
• PRI span 3/0: Provisioned, Up, Active

I’m actually running a slightly older version of Nagios at the moment, version 1.3. To integrate the plugin, first add the following command definition to an appropriate existing or new file under /etc/nagios-plugings/config/:

define command{
        command_name    check_asterisk_pri
        command_line    /usr/lib/nagios/plugins/check_asterisk_pri.php \\
             -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$ -w $ARG3$ \\
             -c $ARG4$ -n $ARG5$
}

where $ARG1$ is the Asterisk manager username and $ARG2$ is the password. $ARG3$ and $ARG4$ are the warning and critical thresholds respectively whereby if the number of available PRIs reaches one of these values, the appropriate error condition will be set. Lastly, $ARG5$ is the number of PRIs the plugin should expect to find.

NB: the command_line line above is split for readability but it should all be on the one line.

Now create a test for a host in an appropriate file in /etc/nagios/config/:

define service{
        use                             core-service
        host_name                       hostname.domain.ie
        service_description             Asterisk PRIs
        check_command                   check_asterisk_pri!user!pass!2!1!4
}

Ensure that your Nagios server has permissions to access the Asterisk server via TCP on the Asterisk manager port (5038 by default). If on a public network, this should be done via stunnel or a VPN for security reasons.

Lastly, you’ll need a user with the appropriate permissions and host allow statements in your Asterisk configuration (/etc/asterisk/manager.conf):

[username]
secret = password
deny=0.0.0.0/0.0.0.0
permit=1.2.3.4/255.255.255.255
read = command
write = command

The next version may include support for BRI and Zap FXO ports also. I also plan on a Cacti plug in to show the channels on each PRI (up – on a call, down, etc). In any case, updates will be posted here.

The plug in can be download from: http://www.opensolutions.ie/misc/check_asterisk_pri.php.txt