So testing begins, and you would imagine given the above information that file-level recoveries for Linux would just work. Problem is it just doesn’t work out of the box, after hours of playing with settings and tick boxes and reading forum posts I finally found the solution I needed to get file-level recovery working.

Ok, so to get Linux backup working you need to add a registry entry on the Virtual Server iDataAgent proxy server (the documentation for which can be found here).

HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\VirtualServer

Then add the following DWORD value

LinuxMetadataSupport    REG_DWORD    0x00000001

Restart the Commvault agent on the VMWare server for good measure and now take your backup.

As for file system support it seems very limited. I have tested the following setups:

Ubuntu Host
sda1 /boot ext3
sda3 / reiserfs
sda4 /data ext4

Centos Host
LVM2 with partition formatted in ext3

The only file systems that backed up were the EXT3 file systems, LVM appears to be supported as well. One can only assume that EXT2 would be supported, but I haven’t tested this.

Overall this solution can only get better, as more file systems are supported and the option to backup the linux systems on a file level are brought into the GUI it can only get easier from here. Personally I plan on moving forward using the Virtual Server iDataAgent to backup all my VM’s that don’t have special applications on them (ie, database, AD, and Exchange).

I have updated the snapadm.pl file contained in my post and have also provided a download link here.

Download:

• snapadm.pl

Read on for more details:

diff snapadm.pl_.txt snapadm.pl_1.txt
181c181
<               my $result = `/sbin/zfs snapshot -r $SnapFS@_$class_name_$ztimestamp`;
---
>               my $result = `/sbin/zfs snapshot -r $SnapFS@$class_name_$ztimestamp`;

The snapshot being taken for the recursive option was incorrectly adding an _ (underscore) to the classname. This meant that when the isExpired method performs a regex search on the snapshot name then no match returns and therefore no snapshot gets destroyed.

Using several scripts to control rsync and the snapshots has allowed me to setup a system that has data retention periods applied and only uses the space on disk required to keep the changed files. Cloning a ZFS snapshot from a week ago (or even six months ago) allows you to create a synthetic full backup from the point in time the backup was taken.

To create my backup solution I had a spare Sun Thor x4540 storage system (the next model in line released after the Thumper storage systems). This system has 48 * 500gb SATA harddrives (with a fairly conservative disk setup gives about 16TB of usable disk space), the following solution could easily be implemented with any system that will support OpenSolaris as well as have enough disk space to fullfil the requirements.

I have created a Backup ZFS pool using all of the Thor’s 48 disks. This pools root ZFS system is mounted at /backup on the filesystem. Within this ZFS filesystem I created another filesystem /backup/rsync this will be where we will create all of the individual filesystems as our backup targets. You can do this with any pool, the important fact is having a ZFS filesystem called rsync (or whatever you wish really) and have ZFS filesystems under this point for each backup target.

root@backup-01:/# zpool list
NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
backup  19.0T  6.81T  12.2T    35%  ONLINE  -
rpool   14.9G  5.49G  9.38G    36%  ONLINE  -
root@backup-01:/#
root@backup-01:/#
root@backup-01:/#
root@backup-01:/# zfs list
NAME                                 USED  AVAIL  REFER  MOUNTPOINT
backup                              5.65T  9.90T  36.5K  /backup
backup/rsync                        3.29T  9.90T  53.1K  /backup/rsync
backup/rsync/dvc                    2.23T  9.90T  1.97T  /backup/rsync/dvc
backup/rsync/library                3.04G  9.90T   392M  /backup/rsync/library
backup/rsync/grp-core-cifs           451G  9.90T   436G  /backup/rsync/grp-core-cifs
backup/rsync/grp-web-frontend       7.56G  9.90T  7.50G  /backup/rsync/grp-web-frontend
backup/rsync/grp-web-mysql           632M  9.90T   254M  /backup/rsync/grp-web-mysql
rpool                               9.83G  4.82G  81.5K  /rpool
rpool/ROOT                          3.06G  4.82G    19K  legacy
rpool/ROOT/opensolaris              8.79M  4.82G  2.87G  /
rpool/ROOT/opensolaris-20100520-01  3.05G  4.82G  2.89G  /
rpool/dump                          2.22G  4.82G  2.22G  -
rpool/export                         122M  4.82G    21K  /export
rpool/export/home                    122M  4.82G    21K  /export/home
rpool/export/home/smithj             122M  4.82G   122M  /export/home/smithj
rpool/swap                          4.43G  9.15G   101M  -
root@backup-01:/#

Next step is creating the rsyncd.conf file for rsync and import the manifest for running the rsync service under OpenSolaris.

The rsyncd.conf file needs to be placed in /etc for rsync to automatically pickup the settings. You may use the following as a sample for your own rsyncd.conf

read only = yes
list = yes
uid = root
gid = root

[host-one]
path = /backup/rsync/host-one
read only = no
hosts allow = <<host-one IP Address>>
hosts deny = *

[host-two]
path = /backup/rsync/host-two
read only = no
hosts allow = <<host-two IP Address>>
hosts deny = *

I found the original manifest for rsync at http://hub.opensolaris.org/bin/view/Community+Group+smf/manifests, then made minor modifications to work out of the box. Download the modified rsync.xml file from the end of this article and put it in the /var/svc/manifests/network folder on your OpenSolaris server. Once you have done this you need to run a service import.

root@backup-01:/# svccfg import /var/svc/manifest/network/rsync.xml
root@backup-01:/# svcadm enable svc:/network/rsync:default

Then run the following to ensure there are no issues with the service

root@backup-01:/# svcs -x

When you want to add a new target for a host to backup remember to create a ZFS filesystem for that host and also add an entry into the rsyncd.conf file. Once you have updated your rsyncd.conf file you need to restart the service

root@backup-01:/# svcadm restart svc:/network/rsync:default

You can now rsync anything to your backup targets, a basic backup script for linux could be as simple as

rsync -a -v -v --progress --stats --delete --exclude "/proc" --exclude "/dev" --exclude "/sys" / backup-01::host-one

The final step is to implement a rotation/retention scheme using ZFS snapshots. The original download of snapadm.pl script came from Sun. I found a bug in this version of the script, the fixed version can be downloaded from the bottom of this article. Copy the snapadm.pl file to /usr/sbin and make the file executable.

The retention policy I have put into place is keep:

• 14 Daily Backups
• 4 Weekly Backups
• 6 Monthly Backups

To do this add the following to your root crontab

# Daily Backup - Keep 14 Days
0 12 * * * /usr/sbin/snapadm.pl -ret=14:0:0 -filesystem=backup/rsync -rec -cl=daily

# Weekly Backup - Keep 4 Weeks
0 13 * * 0 /usr/sbin/snapadm.pl -ret=28:0:0 -filesystem=backup/rsync -rec -cl=weekly

# Monthly Backup - Keep 6 Months
0 14 1 * * /usr/sbin/snapadm.pl -ret=182:0:0 -filesystem=backup/rsync -rec -cl=monthly

Each line contains a different backup type. Daily with a retention of 14 days. Weekly each Sunday with a retention of 28 days (4 weeks). Monthly on the first of the month with a retention of 182 days (half a year).

The Options for snapadm.pl used for the script

• -ret=Days:Hours:Minutes
• -filesystem=ZFS File System Path
• -rec – Recursively snapshot down the tree
• -cl – Class, just a way to label the backup type

The end result is the following list of snapshots

root@backup-01:~# zfs list -t snapshot
NAME                                                        USED  AVAIL  REFER  MOUNTPOINT
backup/rsync@daily_Thu_20100520_1445                      26.6K      -  33.2K  -
backup/rsync@daily_Fri_20100521_1200                          0      -  41.5K  -
backup/rsync@daily_Sat_20100522_1200                          0      -  41.5K  -
backup/rsync@daily_Sun_20100523_1200                          0      -  41.5K  -
backup/rsync@weekly_Sun_20100523_1300                         0      -  41.5K  -
backup/rsync@daily_Mon_20100524_1200                      28.2K      -  46.5K  -
backup/rsync@daily_Tue_20100525_1200                      26.6K      -  48.1K  -
backup/rsync@daily_Wed_20100526_1200                      26.6K      -  48.1K  -
backup/rsync@daily_Thu_20100527_1200                          0      -  48.1K  -
backup/rsync@daily_Fri_20100528_1200                          0      -  48.1K  -
backup/rsync@daily_Sat_20100529_1200                          0      -  53.1K  -
backup/rsync@daily_Sun_20100530_1200                          0      -  53.1K  -
backup/rsync@weekly_Sun_20100530_1300                         0      -  53.1K  -
backup/rsync@daily_Mon_20100531_1200                          0      -  53.1K  -
backup/rsync@daily_Tue_20100601_1200                          0      -  53.1K  -
backup/rsync@monthly_Tue_20100601_1400                        0      -  53.1K  -
backup/rsync@daily_Wed_20100602_1200                          0      -  53.1K  -
backup/rsync/dvc@daily_Tue_20100525_1200                   287K      -  2.06T  -
backup/rsync/dvc@daily_Wed_20100526_1200                  5.75G      -  2.07T  -
backup/rsync/dvc@daily_Thu_20100527_1200                  26.5G      -  2.02T  -
backup/rsync/dvc@daily_Fri_20100528_1200                  17.2G      -  2.00T  -
backup/rsync/dvc@daily_Sat_20100529_1200                  3.72M      -  1.97T  -
backup/rsync/dvc@daily_Sun_20100530_1200                      0      -  2.00T  -
backup/rsync/dvc@weekly_Sun_20100530_1300                     0      -  2.00T  -
backup/rsync/dvc@daily_Mon_20100531_1200                  27.3G      -  2.03T  -
backup/rsync/dvc@daily_Tue_20100601_1200                      0      -  1.97T  -
backup/rsync/dvc@monthly_Tue_20100601_1400                    0      -  1.97T  -
backup/rsync/dvc@daily_Wed_20100602_1200                   184K      -  1.96T  -
backup/rsync/library@daily_Fri_20100521_1200                  0      -  31.5K  -
backup/rsync/library@daily_Sat_20100522_1200                  0      -  31.5K  -
backup/rsync/library@daily_Sun_20100523_1200                  0      -  31.5K  -
backup/rsync/library@weekly_Sun_20100523_1300                 0      -  31.5K  -
backup/rsync/library@daily_Mon_20100524_1200              24.9K      -  31.5K  -
backup/rsync/library@daily_Tue_20100525_1200               390M      -   390M  -
backup/rsync/library@daily_Wed_20100526_1200               389M      -   389M  -
backup/rsync/library@daily_Thu_20100527_1200               384M      -   384M  -
backup/rsync/library@daily_Fri_20100528_1200               388M      -   388M  -
backup/rsync/library@daily_Sat_20100529_1200               388M      -   388M  -
backup/rsync/library@daily_Sun_20100530_1200                  0      -   389M  -
backup/rsync/library@weekly_Sun_20100530_1300                 0      -   389M  -
backup/rsync/library@daily_Mon_20100531_1200               391M      -   391M  -
backup/rsync/library@daily_Tue_20100601_1200                  0      -   392M  -
backup/rsync/library@monthly_Tue_20100601_1400                0      -   392M  -
backup/rsync/library@daily_Wed_20100602_1200              24.9K      -   391M  -
backup/rsync/grp-core-cifs@daily_Fri_20100521_1200        13.7M      -   301G  -
backup/rsync/grp-core-cifs@daily_Sat_20100522_1200         278M      -   435G  -
backup/rsync/grp-core-cifs@daily_Sun_20100523_1200            0      -   436G  -
backup/rsync/grp-core-cifs@weekly_Sun_20100523_1300           0      -   436G  -
backup/rsync/grp-core-cifs@daily_Mon_20100524_1200         373M      -   435G  -
backup/rsync/grp-core-cifs@daily_Tue_20100525_1200         501M      -   434G  -
backup/rsync/grp-core-cifs@daily_Wed_20100526_1200         486M      -   434G  -
backup/rsync/grp-core-cifs@daily_Thu_20100527_1200         492M      -   434G  -
backup/rsync/grp-core-cifs@daily_Fri_20100528_1200         439M      -   436G  -
backup/rsync/grp-core-cifs@daily_Sat_20100529_1200         500M      -   436G  -
backup/rsync/grp-core-cifs@daily_Sun_20100530_1200            0      -   436G  -
backup/rsync/grp-core-cifs@weekly_Sun_20100530_1300           0      -   436G  -
backup/rsync/grp-core-cifs@daily_Mon_20100531_1200         381M      -   436G  -
backup/rsync/grp-core-cifs@daily_Tue_20100601_1200            0      -   436G  -
backup/rsync/grp-core-cifs@monthly_Tue_20100601_1400          0      -   436G  -
backup/rsync/grp-core-cifs@daily_Wed_20100602_1200        38.1M      -   437G  -
backup/rsync/grp-web-frontend@daily_Fri_20100521_1200     4.57M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Sat_20100522_1200     4.95M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Sun_20100523_1200         0      -  7.49G  -
backup/rsync/grp-web-frontend@weekly_Sun_20100523_1300        0      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Mon_20100524_1200     5.44M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Tue_20100525_1200     5.59M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Wed_20100526_1200     5.45M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Thu_20100527_1200     5.43M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Fri_20100528_1200     5.57M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Sat_20100529_1200     5.56M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Sun_20100530_1200         0      -  7.50G  -
backup/rsync/grp-web-frontend@weekly_Sun_20100530_1300        0      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Mon_20100531_1200     5.56M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Tue_20100601_1200         0      -  7.50G  -
backup/rsync/grp-web-frontend@monthly_Tue_20100601_1400       0      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Wed_20100602_1200      179K      -  7.50G  -
backup/rsync/grp-web-mysql@daily_Thu_20100520_1445        35.7M      -   257M  -
backup/rsync/grp-web-mysql@daily_Fri_20100521_1200        29.4M      -   251M  -
backup/rsync/grp-web-mysql@daily_Sat_20100522_1200        29.6M      -   251M  -
backup/rsync/grp-web-mysql@daily_Sun_20100523_1200            0      -   251M  -
backup/rsync/grp-web-mysql@weekly_Sun_20100523_1300           0      -   251M  -
backup/rsync/grp-web-mysql@daily_Mon_20100524_1200        29.8M      -   251M  -
backup/rsync/grp-web-mysql@daily_Tue_20100525_1200        30.1M      -   251M  -
backup/rsync/grp-web-mysql@daily_Wed_20100526_1200        30.4M      -   252M  -
backup/rsync/grp-web-mysql@daily_Thu_20100527_1200        30.6M      -   252M  -
backup/rsync/grp-web-mysql@daily_Fri_20100528_1200        32.9M      -   254M  -
backup/rsync/grp-web-mysql@daily_Sat_20100529_1200        33.1M      -   254M  -
backup/rsync/grp-web-mysql@daily_Sun_20100530_1200            0      -   254M  -
backup/rsync/grp-web-mysql@weekly_Sun_20100530_1300           0      -   254M  -
backup/rsync/grp-web-mysql@daily_Mon_20100531_1200        33.3M      -   254M  -
backup/rsync/grp-web-mysql@daily_Tue_20100601_1200            0      -   254M  -
backup/rsync/grp-web-mysql@monthly_Tue_20100601_1400          0      -   254M  -
backup/rsync/grp-web-mysql@daily_Wed_20100602_1200        79.7K      -   254M  -
rpool/ROOT/opensolaris-20100520-01@install                  148M      -  2.82G  -
rpool/ROOT/opensolaris-20100520-01@2010-05-19-21:49:46     13.8M      -  2.87G  -
root@backup-01:~#

To do a file restore you need to make a ZFS Clone of the snapshot, this will allow you to copy the files required. The most important thing is that you MUST destroy the clone once you have finished the restore, failure to do so will result in the snapshot being unable to be deleted by the retention policy.

I certainly recommend reading the Solaris ZFS Administrators Guide and the ZFS Best Practices Guide. Both these guide certainly helped me understand ZFS and how to manage it.

Download:

• Rsync Manifest – rsync.xml
• Snapshot Admin Script – snapadm.pl

I have been waiting for the ESM tools for Exchange 2010 to hopefully work with Exchange 2003 but that hasn’t happened either. Although I did find a really quick and easy solution this morning after reading the following posts on TechNet (Exchange System Manager for exchange 2003)

You will need to download the Exchange System Manager for Windows Vista then use something like WinRAR to extract the contents.

You will also need to make sure you already have the RSAT tools installed (Remote Server Admin Tools)

Finally open up a Command Prompt as Administrator. Browse to the directory that contains the ESMVISTA.MSI file. Run the following:

ESMVISTA.MSI /q

Once this is done you should be able to open the “Active Directory and Computers” and edit an Exchange User with all the required email tabs.

BMC Updating… Please Do No Shutdown or PowerCycle System!

It would sit on this screen for 40 minutes before finally booting, you can imagine the frustration when you are trying to do work on a server and know that rebooting the thing will take 40 minutes.

Googling the problem didn’t yield many useful results.

After further investigation is was found the iLO software was causing the problem. We are now running on BIOS version O12 7/27/2009 one of the affected servers was running iLO firmware version 3.06. The latest version as of writing this is 3.11b and can be found on the DL160 G5 drivers page.

The update requires a bootable USB Key. Once the software has been downloaded and installed you should be presented with a webpage for Proliant Flash Update. For sanity it is best to open the folder location holding the HPQUSB.exe executable found in C:SWSetupSP44084ROMPaq USB Key. The reason for this is if you run the app from a webpage it will save to a temporary location then run the setup (what the setup does is format the USB key and put the bootable files on it and then copies everything else from the same directory onto the USB key) leaving undesired results.

Once the server was updated with the USB the next server boot took about 5 minutes and had the same message on the screen, you need to be patient at this point (cause I know I wanted to throw the server out the window). Then all of a sudden the fans spin down to normal operating speeds and all is well. Next reboot the server is happy and operational

After checking all the logs and putting pg_standby in debug mode there was still no clue as to why this was happening.

The archive_command on my master server was using

cp -i "%p" /var/lib/pgsql/slave/pg_logrestore/"%f"

I have read somewhere (I can’t remember where or when) that when you use cp to copy the WAL log the file appears in the destination without it being a complete copy so this got me to wondering if this was causing my problem. Knowing that RSync will use a temp file when copying and then rename the file once completed I thought I would give that a go.

My new archive_command is

rsync -q "%p" /var/lib/pgsql/slave/pg_logrestore/"%f"

Since making this change the standby server hasn’t triggered without reason and the problem appears to be fixed.

I kept getting the following error in my logs:

Aug 18 07:53:53 marvin postfix/smtpd[23938]: warning: SASL authentication
  failure: cannot connect to Courier authdaemond: No such file or directory
Aug 18 07:53:53 marvin postfix/smtpd[23938]: warning: localhost[127.0.0.1]:
  SASL LOGIN authentication failed: generic failure

After consulting with Google for at least an hour i finally hit upon a page that helped me.

I found the answer in the following howto Postfix w/o Maildrop. The authdaemon socket setup described on this page was slightly different to the usual suggestions (most help I found online suggested to create a hardlink to the socket file inside the Postfix chroot, this doesn’t work for Ubuntu cause the /var/run is on a different filesystem and a symlink didn’t work for me either). The following commands were taken directly from the howto listed above (all credit should go to the writer of that page).

/etc/init.d/courier-authdaemon stop
rm -rf /var/run/courier/authdaemon/
 /var/spool/postfix/var/run/courier/authdaemon/
mkdir -p /var/spool/postfix/var/run/courier/authdaemon/
ln -s /var/spool/postfix/var/run/courier/authdaemon/
 /var/run/courier/authdaemon
/etc/init.d/courier-authdaemon start
postfix reload

The end result is that Postfix is not reading/accessing a symlinked version of the authdaemon socket and everything works as expected.

Requirements

• PgFouine
• php
• Logrotate
• PostgreSQL setup to log to syslog (Tested with PostgreSQL 8.3 but should work with earlier versions)

PostgreSQL Setup

First you need to setup PostgreSQL to log to syslog. Set the following in your postgresql.conf

log_destination = 'syslog'

# Ensure that the following lines are REMMED out
#
# logging_collector
# log_directory
# log_filename
# log_truncate_on_rotation

You may set the “syslog_facility” and “syslog_ident” options if you wish, but i handle these items in the syslog-ng.conf file.

You will also need to tell Postgres what to log

client_min_messages = notice            # values in order of decreasing detail:
                                        #   debug5
                                        #   debug4
                                        #   debug3
                                        #   debug2
                                        #   debug1
                                        #   log
                                        #   notice
                                        #   warning
                                        #   error

log_min_messages = notice               # values in order of decreasing detail:
                                        #   debug5
                                        #   debug4
                                        #   debug3
                                        #   debug2
                                        #   debug1
                                        #   info
                                        #   notice
                                        #   warning
                                        #   error
                                        #   log
                                        #   fatal
                                        #   panic

log_error_verbosity = default           # terse, default, or verbose messages

log_min_error_statement = debug2        # values in order of decreasing detail:
                                        #   debug5
                                        #   debug4
                                        #   debug3
                                        #   debug2
                                        #   debug1
                                        #   info
                                        #   notice
                                        #   warning
                                        #   error
                                        #   log
                                        #   fatal
                                        #   panic (effectively off)

log_min_duration_statement = 200        # -1 is disabled, 0 logs all statements
                                        # and their durations, > 0 logs only
                                        # statements running at least this time.
log_line_prefix = '%t %d %u %h '

I have a fairly busy DB server so I am only interested in queries that take longer then 200ms. You will need to set this value to suit your needs, set it to low and you will produce many log lines, set it to high and you wont produce anything.

Syslog Setup

Next you need to setup syslog to log PostgreSQL to a different file (the following instruction will work for Syslog-ng on an OpenSUSE box, your milage may vary).

Setup a filter:

filter f_postgres   { match('^postgres'); };

And a Destination:

# PostgreSQL messages
destination postgres { file("/var/log/pgsql/postgresql.log"); };
log { source(src); filter(f_postgres); destination(postgres); flags(final); };

Scripts

Create the following as a script for bash. Ensure you setup the execute bit on the file ie “chmod +x pgfouine_process”.

#!/bin/bash

PGFOUINE="/srv/www/htdocs/pgfouine/pgfouine.php"
DATESTAMP=$(date +%G%m%d)
YEAR=$(date +%G)
MONTH=$(date +%m)
REPORTDIR="/srv/www/htdocs/reports"
PGSQLLOG="/var/log/pgsql/postgresql.log"

mkdir $REPORTDIR/$YEAR/$MONTH -p

php $PGFOUINE -file $PGSQLLOG > $REPORTDIR/$YEAR/$MONTH/$DATESTAMP.htm

You may customise this script to suit your needs depending on where you put the PgFouine files and where you want to store/serve your reports from. You may also with to send the report via email once it is generated, the sky is the limit (ok, sorry for the cliche).

Logrotate

To execute this script each time the log file is rotated put the following file into your /etc/logrotate.d directory.

/var/log/pgsql/postgresql.log {
    compress
    dateext
    rotate 99
    daily
    notifempty
    missingok
    create 640 postgres users
    copytruncate
    prerotate
        /var/lib/pgsql/bin/pgfouine_process
    endscript
}

The important thing for this is the prerotate section. This will run the script first before rotating the log file.

If you don’t have Logrotate setup you could easily run the pgfouine script on a daily basis with Cron.

There are two graphs added:

Bandwidth – Shows the current set bandwidth limit and usage figures for a Zone Access Point
Calls – Shows the number of calls both accepted or rejected by Bandwidth Management

To install just copy the “mitel_bwmgt_stats.xml” file into your cacti “resource/snmp_queries” directory. Then import the host template file into Cacti (Minimum Ver 0.8.7d). Once that is done you should be able to add the Mitel graphs to your monitored Mitel hosts.

Requirements

• Cacti – 0.8.7d
• SNMP Enabled on the Mitel Controller

Download

• Mitel Bandwidth Management Cacti Graphs

I have developed a script that will check the Mitel system via SNMP to check the current alarm level, if there is an alarm it will then make another SNMP call to the alarm categories table and list the current list of alarms as part of the alert. The script requires the perl module Net::SNMP and can be downloaded from the download section at the bottom of this post.

Usage:

Usage: ./check_mitel.pl hostname [snmp community: Defaults to "public"]
            [snmp port: Defaults to "161"]

Check Command Definition:

define command{
        command_name    mitelalarm
        command_line    $USER1$/check_mitel.pl $HOSTADDRESS$ $ARG1$
}

Service Template Definition:

define service {
        name mitelalarm
        use base
        check_command mitelalarm
        register 0
}

Service Definition (replace “public” with the SNMP Community set on your Mitel controller):

define service {
        use base
        service_description Mitel Alarm Check
        check_command mitelalarm!public
        host_name mitelcontroller1
}

Download:

• check_mitel.pl

I have also been working on Cacti graphs of the Bandwidth management details, more on that early next month .